00:00:00자, 좋습니다.
00:00:02지금 가장 뛰어난 AI 모델은 무엇일까요?
00:00:04클로드, GPT, 제미나이 등등 많죠.
00:00:07솔직히 말씀드리면, 이건 잘못된 질문이라고 생각합니다.
00:00:11정말로, 완전히 잘못된 질문이에요.
00:00:14간단히 제 소개를 하자면, 저는 다니엘입니다.
00:00:168년 넘게 iOS 개발에 깊이 몸담아 왔죠.
00:00:20프리랜서로 시작해서 UI를 디자인하고,
00:00:24여러 클라이언트를 거치면서,
00:00:25다른 사람들의 아이디어를 구현해 주는 동안
00:00:27저만의 아이디어를 고민해 왔습니다.
00:00:28그러다 2025년 이후에 전적으로 1인 개발의 길로 들어섰죠.
00:00:33더 이상의 클라이언트도, 안전장치도 없이 말이죠.
00:00:36그 후로 15개가 넘는 앱을 직접 만들었고,
00:00:39모두 SwiftUI를 사용해 공개적으로 구축했습니다.
00:00:41그리고 지금은 제가 가진 모든 에너지를
00:00:44이 1인 스튜디오를
00:00:46실제로 지속 가능한 무언가로 만드는 데 쏟고 있습니다.
00:00:49단순히 빠르게 찍어내는 MVP나 AI가 대충 만든 결과물이 아니라,
00:00:52규모가 커져도 견딜 수 있는 진짜 앱을 만드는 것이죠.
00:00:55네, 그 모든 과정이,
00:00:57그 험난한 여정 전체가 CraftersLab에 담겨 있습니다.
00:01:00주소는 crafterslab.dev이고,
00:01:01흔한 튜토리얼 저장소나 AI 복제 공장이 아닙니다.
00:01:06진정한 저의 본거지이며,
00:01:08AI를 진짜 팀원처럼 활용하는 1인 개발자들을 위해 만들었습니다.
00:01:12막혔을 때 대충 눌러보고 운 좋게 답이 나오길 바라는
00:01:14자판기 같은 존재가 아니라요.
00:01:16만드는 일의 가치를 소중히 여기고,
00:01:18실력을 키워서 오래 지속될 결과물을
00:01:20진지하게 만들고 싶으시다면,
00:01:23네, 이곳이 편안하게 느껴지실 겁니다.
00:01:24그리고 혹시 아직 패트리온을 이용 중이시라면,
00:01:26정말 감사드리지만, 알려드릴 게 있습니다.
00:01:29모든 것이 crafterslab.dev로 옮겨졌습니다.
00:01:32이제 모든 멤버들이 그곳에 모여 있죠.
00:01:33함께 만들어 봅시다.
00:01:35제가 이런 생각을 하게 된 계기가 있습니다.
00:01:38최근에 한 연구 결과가 발표되었는데요.
00:01:41연구진이 "Epic's Agent"라는 벤치마크를 공개했습니다.
00:01:45사람들이 온라인에서 논쟁하는
00:01:49다른 모든 벤치마크와 이 벤치마크의 차이점은,
00:01:51코딩 퍼즐이나 객관식 문제가 아니라
00:01:55실제 전문적인 업무로 에이전트를 테스트한다는 점입니다.
00:01:58컨설턴트, 변호사, 분석가들이
00:02:03매일 실제로 수행하는 작업들을 말하죠.
00:02:05각 작업은 사람이 완료하는 데 약 1~2시간이 걸립니다.
00:02:08그래서 모든 주요 프런티어 모델들을 이 테스트에 투입했죠.
00:02:11가장 성적이 좋은 모델도 이러한 작업들을
00:02:13완수한 비율은 24% 정도였습니다. 4번 중 1번꼴이죠.
00:02:17동일한 모델로 8번을 시도한 후에도,
00:02:20성공률은 약 40%까지만 올라갔습니다.
00:02:23여기서 기억해야 할 점은, 이 모델들이
00:02:26모두가 열광하는 기존 벤치마크에서는
00:02:2990% 이상의 점수를 기록했다는 사실입니다.
00:02:32즉, 기존 벤치마크가 잘못되었거나
00:02:33우리가 엉뚱한 것을 측정하고 있다는 뜻이죠.
00:02:36저는 후자라고 생각합니다.
00:02:37자, 이제 우리에게 중요한 대목이 나옵니다.
00:02:41연구진은 에이전트들이 왜 실패했는지 분석했습니다.
00:02:46그 답은 모델이 멍청해서가 아니었습니다.
00:02:49모델들은 필요한 지식을 모두 갖추고 있었죠.
00:02:51문제를 추론하는 능력도 충분했습니다.
00:02:54실패의 원인은 거의 전적으로
00:02:56실행과 오케스트레이션(조정)에 있었습니다.
00:03:00에이전트들은 단계가 너무 많아지면 길을 잃었습니다.
00:03:02이미 실패한 방식인데도 다시 반복하곤 했죠.
00:03:05애초에 무엇을 하려고 했었는지조차
00:03:09까맣게 잊어버리는 것이었습니다.
00:03:11Claude Code나 Cursor를 매일 사용하는
00:03:141인 개발자라면 공감하실 겁니다.
00:03:18에이전트가 실패의 늪에 빠져서 똑같이 안 되는 일을
00:03:21세 번씩이나 반복해서 시도하고,
00:03:2320단계 전의 맥락을 완전히 잊어버리는 걸 지켜본 적이 있겠죠.
00:03:26Y te quedas ahí sentado como,
00:03:28"Opus 모델로 바꿔야 하나?"
00:03:30"다른 API 업체를 써야 하나?"
00:03:32하지만 데이터는 그것이 해결책이 아니라고 말합니다.
00:03:34모델 자체가 병목 현상의 원인이 아니라는 거죠.
00:03:36문제는 모델을 둘러싼 모든 환경에 있습니다.
00:03:38여기에 딱 맞는 단어가 하나 있는데요.
00:03:402025년을 에이전트가 정의했다면,
00:03:43이 단어가 2026년을 정의하게 될 것입니다.
00:03:46그 단어는 바로 '하네스(harness, 장치)'입니다.
00:03:47에이전트 하네스는 모델 주변의 모든 인프라를 의미합니다.
00:03:50모델이 무엇을 볼 수 있는지,
00:03:52어떤 도구에 접근할 수 있는지,
00:03:54일이 꼬였을 때 어떻게 복구하는지,
00:03:56긴 세션 동안 수행한 작업을 어떻게 추적하는지 같은 것들이죠.
00:03:59OpenAI는 최근에 실제로
00:04:02"하네스 엔지니어링"이라는 제목의 블로그 글을 올렸습니다.
00:04:04Anthropic도 장시간 작동하는 에이전트를 위한
00:04:07효과적인 하네스 구축 가이드를 발표했고요.
00:04:09최근 Meta가 인수한 AI 기업인 Manus는,
00:04:13자신들의 맥락(Context) 엔지니어링 교훈을 공유했습니다.
00:04:16그들은 전체 에이전트 프레임워크를
00:04:196개월 동안 다섯 번이나 새로 만들었죠. 다섯 번이나요.
00:04:22그리고 그들은 모두 똑같은 말을 하고 있습니다.
00:04:24진짜 엔지니어링의 핵심은 모델이 아니라
00:04:27하네스에 있다는 것을요.
00:04:28좋습니다. 그리고 이 부분은 솔직히 저를 놀라게 했는데요,
00:04:32왜냐하면 우리가 이 도구들로 무언가를 만들 때
00:04:34생각하는 방식과는 정반대였기 때문입니다.
00:04:38Vercel의 사례를 하나 들어보죠.
00:04:41그들에게는 텍스트를 SQL로 변환하는 에이전트가 있었습니다.
00:04:43질문을 던지면 SQL 쿼리를 작성해 주는 식인데,
00:04:46처음에는 보통 사람들이 에이전트를 만드는 방식으로 구축했습니다.
00:04:49다양한 전용 도구들을 제공했죠.
00:04:51데이터베이스 스키마를 이해하는 도구,
00:04:54쿼리를 작성하는 도구, 결과를 검증하는 도구 등을요.
00:04:58이 모든 것들을 감싸는 복잡한 오류 처리 로직까지
00:05:01더했을 때, 성공률은 약 80%였습니다.
00:05:04그러다 그들은 다소 파격적인 시도를 했습니다.
00:05:06도구의 80%를 그냥 다 제거해 버린 겁니다.
00:05:11에이전트에게 아주 기본적인 것들, 즉 배시(bash) 명령 실행,
00:05:15파일 읽기, 그리고 grep이나 cat 같은 표준 명령줄 도구만 줬습니다.
00:05:18여러분이나 제가 실제로 사용하는 바로 그런 도구들이죠.
00:05:20그랬더니 정확도가 80%에서 100%로 올라갔습니다.
00:05:25토큰 사용량은 40% 줄어들었고,
00:05:28속도는 3.5배나 빨라졌습니다.
00:05:31정말 놀랍지 않나요?
00:05:33그리고 그것을 만든 엔지니어가 한 말이
00:05:36제 뇌리에 강하게 박혔습니다.
00:05:38"모델은 점점 더 똑똑해지고 있고,
00:05:40컨텍스트 윈도우는 점점 더 커지고 있다.
00:05:42그렇다면 아마도 최고의 에이전트 아키텍처는
00:05:44아키텍처가 거의 없는 형태일지도 모른다."
00:05:46이건 모든 걸 뒤집는 발상입니다.
00:05:50보통 1인 개발자로 일하면서
00:05:54결과물의 신뢰성을 높이려고 할 때 본능적으로는,
00:05:57더 많은 도구와 가드레일,
00:06:01더 복잡한 라우팅 로직을 추가하려고 하거든요.
00:06:02구조가 더 견고해야 도움이 될 거라고 생각하지만,
00:06:04사실 그 도구들은 모델을 돕는 게 아니라
00:06:06오히려 방해하고 있었던 겁니다.
00:06:08이건 특이한 사례가 아닙니다.
00:06:10Manus 또한 똑같은 깨달음을 얻었습니다.
00:06:13그들은 에이전트 프레임워크 전체를
00:06:166개월 동안 다섯 번이나 새로 갈아엎었는데,
00:06:19가장 큰 성능 향상은
00:06:21기능을 추가했을 때가 아니라,
00:06:23기능을 뺏을 때 나타났습니다.
00:06:25복잡한 문서 검색 기능을 제거하고,
00:06:28화려한 라우팅 로직을 없앴으며,
00:06:29관리 에이전트를 단순하고 구조화된 인계 방식으로 바꿨습니다.
00:06:34반복할수록 시스템은 단순해졌고, 성능은 좋아졌죠.
00:06:37Claude Code로 장시간 작업하는
00:06:40모든 1인 개발자들이 들어야 할 핵심이 여기 있습니다.
00:06:42Manus는 자신들의 에이전트가 작업 하나당
00:06:45평균 50번의 도구 호출을 한다는 것을 발견했습니다.
00:06:49엄청나게 많은 단계죠.
00:06:50기술적으로 거대한 컨텍스트 윈도우를 지원하는
00:06:53모델이라고 할지라도,
00:06:54성능은 일정 시점을 지나면 떨어지기 마련입니다.
00:06:58모델이 갑자기 모든 걸 잊어버리는 건 아닙니다.
00:07:01중요한 신호가 노이즈(소음) 속에 묻혀버리는 것에 가깝죠.
00:07:04세션 초반에 주었던 중요한 지침들이
00:07:07수백 개의 중간 결과물 아래에 깔려버리는 겁니다.
00:07:10그래서 그들의 해결책은 아주 간단했습니다.
00:07:12파일 시스템을
00:07:14모델의 외부 메모리로 취급하기 시작한 거죠.
00:07:17모든 것을 컨텍스트 윈도우에 쑤셔 넣는 대신,
00:07:20에이전트가 핵심 정보를 파일에 기록하고
00:07:23필요할 때 다시 읽어오게 한 겁니다.
00:07:25Claude Code를 사용해 보셨다면,
00:07:27이미 이런 모습을 보셨을 겁니다.
00:07:29claude.md 파일, 할 일 목록, 진행 상황 추적 같은 것들이
00:07:34매일 여러분의 터미널에서 벌어지고 있는
00:07:36바로 그 패턴입니다.
00:07:37자, 아까 제가 모든 사람들이
00:07:40같은 생각으로 모이고 있다고 했던 거 기억하시나요?
00:07:44지금 가장 성공적인
00:07:45세 가지 에이전트 시스템을 살펴보면,
00:07:49완전히 다른 방향에서 출발했지만
00:07:51결국 모두 같은 지점에 도착했기 때문입니다.
00:07:53OpenAI의 Codex는 계층적인 접근 방식을 취합니다.
00:07:57계획을 짜는 오케스트레이터(조정자),
00:07:59개별 작업을 처리하는 실행자(executor),
00:08:02그리고 실패를 잡아내는 복구 계층이 있죠.
00:08:06매우 견고합니다.
00:08:07일을 맡겨두고 자리를 비워도 될 정도죠. 이것이 하나의 철학입니다.
00:08:09다른 하나는 제가 매일 사용하는 Claude Code입니다.
00:08:10이것의 핵심 도구는 말 그대로 딱 네 가지뿐입니다.
00:08:14파일 읽기, 파일 쓰기, 파일 수정,
00:08:16배시 명령 실행. 그게 전부예요.
00:08:19지능의 대부분은 모델 자체에 들어있고,
00:08:21하네스는 아주 최소한으로 유지됩니다.
00:08:23더 많은 기능이 필요할 때는 MCP나
00:08:25에이전트가 그때그때 배우는 기술을 통해 확장하죠.
00:08:28그리고 Manus는 제가
00:08:30'축소, 분산, 격리'라고 부르는 방식에 도달했습니다.
00:08:33적극적으로 컨텍스트를 줄이고, 파일 시스템을 메모리로 쓰며,
00:08:38무거운 작업은 보조 에이전트를 띄워 처리한 뒤
00:08:40요약본만 가져오는 방식이죠.
00:08:43완전히 다른 세 가지 접근 방식이지만,
00:08:45모두 동일한 통찰로 수렴하고 있습니다.
00:08:47모델보다 하네스가 더 중요하다는 사실입니다.
00:08:50그리고 1인 개발자들에게 이 사실은
00:08:52실제로 어디에 시간을 써야 하는지를
00:08:55완전히 바꿔놓습니다.
00:08:57시간을 쏟아야 할 분야가 달라집니다.
00:08:59우리에게 주어진 시간은 무한하지 않으니까요.
00:09:01레딧에서 클로드와 GPT 중
00:09:05뭐가 더 나은지 토론하느라 보내는 매시간은, 실제 개발을 하지 못하는 시간입니다.
00:09:08강화 학습의 창시자 중 한 명인
00:09:11리처드 서튼이 제안한
00:09:14"쓰라린 교훈(The Bitter Lesson)"이라는 개념이 있습니다.
00:09:16핵심 논거는 이렇습니다.
00:09:18컴퓨팅 파워와 함께 확장되는 접근 방식은
00:09:21결국 인간이 수작업으로 설계한 지식에
00:09:23의존하는 방식을 항상 이기게 되어 있다는 것이죠.
00:09:26이것을 지금 우리가 하는 일에 적용해 보면
00:09:27매우 구체적인 의미를 갖습니다.
00:09:29모델이 똑똑해질수록
00:09:31여러분의 하네스(harness)는 더 복잡해지는 게 아니라
00:09:33더 단순해져야 합니다.
00:09:34모델을 업그레이드할 때마다 직접 코딩한 로직이나
00:09:36커스텀 파이프라인을 계속 추가하고 있다면
00:09:40흐름을 거스르고 있는 셈입니다.
00:09:42솔직히 말씀드리면, 그런 과잉 설계가
00:09:44여러분의 에이전트가 자꾸 고장 나는 원인일 가능성이 큽니다.
00:09:47그래서 제가 제안하는 실제 시도해 볼 만한 방법들입니다.
00:09:49첫째, Vercel이 했던 실험을 직접 해보세요.
00:09:52이미 구축해 둔 에이전트가 있다면
00:09:54다 걷어내고 특수 도구들을 제거해 보십시오.
00:09:57기본적인 파일 접근권과 배시(bash) 터미널만 주고
00:10:00어떻게 되는지 지켜보세요.
00:10:02모델은 아마 여러분이 그 주변에 구축해 놓은
00:10:03도구 파이프라인보다 더 똑똑할 겁니다.
00:10:06둘째, 진행 상황 파일(progress file)을 추가하세요.
00:10:08에이전트가 매 단계가 끝날 때마다
00:10:10업데이트하는 할 일 목록을 유지하게 하세요.
00:10:13작업을 시작할 때 파일을 읽고,
00:10:15끝날 때 그 파일에 기록하는 방식입니다.
00:10:17이것이 바로 클로드 코드(Claude Code)가
00:10:19마크다운 파일을 활용해 수행하는 방식입니다.
00:10:20또한 Manish가 다섯 번의 완전한 재작성 끝에
00:10:22도달한 것과 같은 패턴이기도 하죠.
00:10:24저는 실제로 연구실에 제 에이전트 지침들과
00:10:26.md 템플릿을 포함해 이 모든 시스템을
00:10:29연결해 두었습니다. 궁금하시면 보여드릴 수 있어요.
00:10:33셋째, MCP와 '스킬(Skills)'에 대해 배우기 시작하세요.
00:10:37이것들은 모델이 외부 도구와 협업할 때
00:10:40일일이 하드코딩하지 않고도
00:10:42깔끔하고 표준화된 방식으로 작동하게 해줍니다.
00:10:44확장성은 이제 바로 여기서 나옵니다.
00:10:462025년이 에이전트의 해였다면,
00:10:50네, 어느 정도 실제로 그랬죠.
00:10:53하지만 2026년은 하네스의 해가 될 것이라고 생각합니다.
00:10:58똑같은 모델, 완전히 동일한 모델이라도
00:11:03클로드 코드에서 쓸 때와 커서(Cursor),
00:11:06또는 코덱스(CodeX)에서 쓸 때 완전히 다르게 작동합니다.
00:11:08그러니 코딩 에이전트를 사용하든 직접 만들든
00:11:11여러분의 하네스를 신중하게 선택하십시오.
00:11:14자, 여기까지 영상을 보고 계신다면
00:11:17정말 대단하신 분들입니다.
00:11:18지금 모델에 대한 논쟁이 매우 뜨겁다는 걸 압니다.
00:11:22매주 새로운 모델과 벤치마크가 쏟아지고,
00:11:24누가 왕좌를 차지했는지에 대한 글들이 올라오죠.
00:11:27하지만 실제로 이 기술들을 만드는
00:11:30기업들에서 나오는 데이터와 엔지니어링 결과는
00:11:32전혀 다른 곳을 가리키고 있습니다.
00:11:34승부처는 바로 하네스에 있습니다.
00:11:371인 개발자들에게는 정말 기쁜 소식입니다.
00:11:40더 나은 하네스를 만드는 일은
00:11:42다음 모델 출시를 기다릴 필요 없이
00:11:45오늘 당장 바로 시작할 수 있는 일이니까요.
00:11:47제가 .md 파일과 에이전트 워크플로우를
00:11:51어떻게 설정하고 실제로 활용하는지,
00:11:56제 앱들에 어떻게 연결하는지 더 깊이 알고 싶으시다면
00:11:59crafterslab.dev를 방문해 보세요.
00:12:02흔한 튜토리얼 더미나 AI 콘텐츠 공장이 아닙니다.
00:12:06AI를 진짜 팀 동료처럼 대하고 결과물의 품질을
00:12:09진심으로 고민하는 1인 개발자들을 위해
00:12:11제가 직접 만든 베이스캠프 같은 곳입니다.
00:12:13안으로 들어오시면 전체 워크스루와
00:12:15짧은 영상 강의들, 그리고 클로드 코드에서
00:12:19바로 사용할 수 있는 다양한 스킬들,
00:12:21여러분의 프로젝트에 즉시 적용 가능한
00:12:24다운로드 리소스들을 확인하실 수 있습니다.
00:12:26멤버들끼리 댓글로 의견을 나누고
00:12:29질의응답도 활발하게 이루어집니다.
00:12:30일방적인 정보 전달이 아니라 살아있는 소통의 장이죠.
00:12:34하지만 가장 핵심은 노션 팀 스페이스와
00:12:37저의 라이브 플레이북입니다. 제가 만드는
00:12:40모든 앱의 실제 개발 과정을 가장 가까이서 보실 수 있습니다.
00:12:42실제 프로젝트에 사용 중인 .md 파일들,
00:12:46프롬프트 라이브러리, 실시간으로 작성 중인 문서들,
00:12:49이면에서 돌아가는 모든 자동화 시스템까지 포함됩니다.
00:12:51카메라를 위해 다듬어진 게 아니라 실수까지 포함된 날 것 그대로의 과정입니다.
00:12:55con sus partes complicadas y todo, y su cerebro de Swift,
00:12:58수년간 구축해 온 Swift와 SwiftUI 큐레이션 라이브러리,
00:13:01심층적인 키노트와 제가 비용을 들여 수집한
00:13:04비공개 강연 자료들도 있습니다.
00:13:07공개된 학습 데이터에서는 찾아볼 수 없는
00:13:10수준 높은 자료들입니다.
00:13:11이것들은 제가 커스텀 MCP를 만들거나
00:13:16클로드 코드, 커서용 스킬을 설정할 때 실제로 쓰는 것들입니다.
00:13:20항상 실험하고 효과적인 것들을 공유하죠. 그리고 'Ops Lab'도 있어요.
00:13:23그곳에는 모든 AI 에이전트 지침과
00:13:25노션 템플릿, 클로드 코드 스킬,
00:13:28워크플로우, 자동화 설정들이 모두 모여 있습니다.
00:13:31가져다가 뜯어보고,
00:13:33완전히 망가뜨린 다음 여러분만의 방식으로 재구축해 보세요.
00:13:36핵심은 인디 개발자들의 스택을 서로 연결해서
00:13:38비록 혼자 키보드 앞에 앉아 있더라도
00:13:41결코 혼자 만드는 게 아니라는 점을 느끼게 하는 것입니다.
00:13:44커뮤니티가 아직 작고 혜택이 유지될 때
00:13:46지금이 합류하기 가장 좋은 시기입니다.
00:13:49거대한 익명 게시판보다는
00:13:52개발자들의 아지트 같은 느낌이 훨씬 강할 거예요.
00:13:55여러분을 그곳에서 꼭 뵙고 싶습니다.
00:13:57하네스에 대한 의견도 나누고
00:14:00여러분이 다음에 무엇을 만드시는지 저도 배우고 싶네요.
00:14:02계속해서 만들고, 실험하십시오.
00:14:05벤치마크 소음 때문에
00:14:08정작 중요한 본질을 놓치지 마세요.
00:14:10건승을 빕니다.
00:14:12감사합니다.