에이전틱 엔지니어링 시대의 생존 스킬 9가지

들어가며

바이브 코딩이라는 단어를 만든 Karpathy가 X에 트윗했다 — 이제 바이브 코딩과 구분되는 새로운 이름이 필요하다며, 에이전틱 엔지니어링이라는 용어를 제안했다. 나는 작년 4월부터 열심히 바이브 코딩을 했고 특히 지난 2, 3달은 정말 격변의 시기를 겪었다. 내 글 ‘코드를 읽지 않는 시대, 엔지니어는 무엇을 읽어야 하는가’가 폭발적인 조회수를 기록한 것도 그에 대한 반작용이라고 생각한다.

이 글은 Karpathy의 트윗에서 영감을 받아, 내가 실제로 겪은 시행착오와 Armin Ronacher, Boris Cherny, WenHao Yu, IndyDevDan 같은 실전 사례를 엮어 9가지 핵심 스킬로 정리한 것이다.

9가지 핵심 스킬은 다음과 같다.

1. 분해 능력 (Decomposition)
2. 컨텍스트 설계 (Context Architecture)
3. 완료 정의 (Definition of Done)
4. 실패 복구 (Failure Recovery Loop)
5. 관찰 가능성 (Observability)
6. 메모리 설계 (Memory Architecture)
7. 병렬 관리 (Parallel Orchestration)
8. 추상화 계층 설계 (Abstraction Layering)
9. 감각 (Taste)

흥미롭게도 이 9가지의 스킬은 에이전틱 엔지니어링, 나아가 바이브 코딩 시대 이전에도 일을 잘하는 엔지니어, 그리고 나아가서 일을 잘하는 매니저에게 요구되는 자질들이었다. 왜 그러한지 Karpathy의 이야기로 시작해서 하나씩 살펴보자.

바이브 코딩의 창시자의 주말

Karpathy가 주말에 집 카메라용 대시보드를 만들고 싶었다고 한다. 에이전트에게 DGX Spark의 IP, 사용자명, 비밀번호, 그리고 목표를 줬다. SSH 키 설정부터 vLLM 구성, 모델 다운로드와 벤치마크, 비디오 추론 서버 구축, 웹 UI 대시보드, systemd 서비스 설정, 메모리 노트 기록과 마크다운 리포트 작성까지 — 전부를 한 번에 지시했다. 30분 후 전부 완성됐다.

“I didn’t touch anything myself. This was a weekend project just 3 months ago. Now it was 30 minutes of just forgetting about it.”

“불과 3개월 전만 해도 주말 전체가 필요한 프로젝트였지만, 이제는 30분 동안 잊고 기다리면 완료되는 작업이 됐다.”

Karpathy는 이 새로운 방식에 이름을 붙였다. 에이전틱 엔지니어링(Agentic Engineering).

“‘Agentic’ because 99% of the time you are no longer writing code directly, you are commanding and supervising agents. ‘Engineering’ because there is art, science, and skill to it.”

“‘에이전틱’인 이유는 99%의 경우 더 이상 코드를 직접 작성하지 않고 에이전트에게 명령하고 감독하기 때문이다. ‘엔지니어링’인 이유는 여기에 기예, 과학, 전문 기술이 있기 때문이다.”

프롬프트 몇 줄에 앱이 뚝딱 나오는 시대를 지나, 이제는 에이전트가 잘 작동하는 조건을 설계하는 능력 이 핵심이 됐다.

변화는 빠른데, 실제 적응은 느리다. 대부분의 개발자는 아직 따라잡지 못하고 있다.

그런데 이 변화의 속도가 예사롭지 않다.

“It is hard to put into words how much programming has changed in just the last ~2 months. This was not a ‘business as usual’ kind of incremental progress.”

“지난 약 2개월간 프로그래밍이 얼마나 변했는지 말로 전달하기가 어렵다. 이것은 ‘늘 있던 방식의 발전’처럼 점진적으로 변한 게 아니다.”

개발자 대부분이 AI를 사용하고 있지만, 실제로 에이전트에게 작업을 온전히 위임하는 비율은 여전히 낮다. 2026 Agentic Coding Trends Report에 따르면 개발자의 60%가 AI를 사용하지만 완전 위임은 0-20%에 불과하다 — 이른바 위임 패러독스(Delegation Paradox). AI가 코드를 써주는 건 익숙해졌는데, 에이전트에게 일을 맡기고 손을 떼는 건 전혀 다른 차원의 이야기다.

IndyDevDan은 이 간극을 한 문장으로 요약했다.

“Do you trust your agents?”

“당신은 에이전트를 신뢰하는가?”

대부분의 개발자가 “아니오”라고 답한다. 나도 처음에는 그랬다. 에이전트가 만들어준 코드를 전부 검토했고, 직접 짜는 것보다 더 오래 걸리는 경우도 있었다.

하지만, Karpathy의 사례처럼 에이전틱 엔지니어링 시대에는 이제 모든 게 점점 더 자동화되고 에이전트에게 위임되는 비율이 높아지고 있다. 이 시대에도 훌륭한 엔지니어가 되기 위해서 우리에게 필요한 스킬 또는 자질은 무엇일까?

① 분해 능력 (Decomposition)

에이전트에게 “회원가입 기능 만들어줘”라고 하면 뭔가 나오긴 나온다. 문제는 그게 내가 원하던 게 아닐 확률이 높다는 거다. 이메일 인증은 빠져 있고, 비밀번호 규칙은 내 기준과 다르고, UI는 상상도 못한 방향으로 가 있다.

에이전트에게 일을 시키는 건 결국 “무엇을 만들지”를 정하는 일 이다. 고객이 뭘 원하는지, 유저가 뭘 필요로 하는지, 우선순위가 뭔지 — 이건 내가 정확히 해야 한다. 에이전트가 대신해줄 수 없는 영역이다.

“The key is to develop the intuition to decompose tasks appropriately, delegating to agents where they work well and providing human help where needed.”

“핵심은 작업을 적절히 분해하여 잘 작동하는 부분은 에이전트에 위임하고 나머지 부분에서 인간이 도움을 주는 직관을 기르는 것이다.”

이게 말은 쉬운데, 실제로 해보면 까다롭다. “잘 작동하는 부분”과 “인간이 도움을 줘야 하는 부분”의 경계가 매번 다르기 때문이다. 어떤 작업은 에이전트가 원샷으로 끝내고, 어떤 작업은 세 번을 돌려도 핵심을 놓친다. 그 차이를 체감으로 익히는 게 분해 능력이다. Karpathy가 분해의 조건도 꽤 명확하게 짚어줬다.

“It works especially well in some scenarios, especially where the task is well-specified and the functionality can be verified/tested.”

“일부 시나리오에서 특히 잘 작동하며, 특히 작업 명세가 명확하고 기능을 검증·테스트할 수 있는 경우에 효과적이다.”

뒤집어 말하면, 명세가 모호하고 검증 기준이 없는 작업에서는 에이전트도 헤맨다. 내가 할 일은 모호한 요구사항을 명확한 작업 단위로 바꿔주는 것이다.

이전에 Claude Code로 TDD 워크플로우를 구축하면서 느낀 건, 원샷으로 70-80%는 구현되지만 나머지 20%가 진짜 일이라는 거였다. 초기 요구사항을 얼마나 잘 정의했느냐에 따라 그 20%의 크기가 극적으로 달라진다.

WenHao Yu의 Opus 4.6 멀티에이전트 워크플로우에서도 이 패턴이 보인다. 그는 큰 프로젝트를 AI Team Lead에게 맡기는데, Team Lead가 하는 일의 70%가 사실 작업 분해다. “이 기능을 구현하려면 어떤 하위 태스크가 필요한가?”를 먼저 설계하고, 각 태스크를 서로 다른 에이전트에게 위임한다. 분해가 잘 되면 나머지는 자연스럽게 따라온다. 분해가 잘못되면 모든 에이전트가 삽질을 한다.

이 “분해가 잘못되면 모든 에이전트가 삽질한다”는 경험을 직접 해봤다. 한번은 “설정 페이지 만들어줘”라는 하나의 태스크를 에이전트에게 던졌는데, 설정 페이지 안에 프로필 수정, 알림 설정, 구독 관리, 데이터 내보내기가 다 들어 있었다. 에이전트가 이 네 가지를 한 번에 만들려다 보니 각각의 상태 관리가 꼬였다. 알림 설정을 바꾸면 프로필 폼이 리셋되고, 구독 관리에서 에러가 나면 전체 페이지가 깨졌다. 결국 네 개의 독립된 태스크로 쪼갠 뒤 각각 에이전트에게 맡기니 한 번에 됐다. “설정 페이지”가 아니라 “프로필 수정 폼”, “알림 토글 컴포넌트”, “구독 관리 패널”, “데이터 내보내기 버튼” — 이렇게 네 조각으로.

Before: AddPlan 화면, 인터뷰 없이 던진 결과

계획 생성 화면(AddPlanView)을 만들어야 했다. 5단계 입력 플로우 — 이름 입력, 분량 설정, 기간 선택, 요일 지정, 요약 확인. 피그마 디자인이 있었고, 기획안(PRD)도 작성해서 제공했다. “이 정도면 에이전트가 한 번에 만들겠지.”

그게 안일한 기대였다.

에이전트가 첫 버전을 내놨는데, 얼핏 보면 구조는 맞았다. 그런데 디테일에서 계속 어긋났다. 디자인 시스템에 정의되지 않은 컬러와 폰트를 마음대로 가져다 쓰고 있었다. Step2 분량 설정의 CustomNumberPad 레이아웃이 피그마와 다르다. 수정했더니 Step3 기간 선택 캘린더가 깨졌다. 한 번 수정할 때마다 다른 Step이 밀려났다. 세 번째 반복쯤 “이거 그냥 내가 짜는 게 낫지 않나” 싶었다.

문제의 원인은 명확했다. 내가 뭘 원하는지 나 자신도 정확히 정리하지 않은 상태에서 시작한 거다. PRD가 있었지만, “CustomNumberPad의 키 간격과 반응 영역”, “Step 전환 애니메이션의 방향과 타이밍”, “유효성 검사 실패 시 에러 표시 방식” 같은 디테일은 내 머릿속에만 있었다. 에이전트는 내 머릿속을 읽을 수 없으니, 매번 자기 나름의 선택을 했고, 매번 내 기대와 어긋났다. 결국 에이전트와 핑퐁만 수십 턴, 거의 반나절을 날렸다.

After: 소크라틱 대화로 요구사항 구체화

그 다음부터 나는 기능을 구현하기 전에 AI와 인터뷰를 하기 시작했다. Superpowers 같은 프레임워크가 이걸 자동으로 해주기도 하는데, 핵심은 같다 — “내가 뭘 원하는지”를 먼저 명확하게 만드는 과정이다. 소크라틱 대화라고 할까. AI가 질문을 던지고, 내가 답하면서, 요구사항이 구체화된다.

AddPlan을 다시 시도할 때 이 방식을 적용했다. “5단계 입력 플로우를 만들려는데요.” → AI: “각 단계의 입력 필드와 유효성 검사는?” → “Step1은 이름 입력, 빈 문자열 불가, 최대 50자.” → AI: “디자인 시스템 컬러를 쓰나요? 커스텀 컬러는?” → “디자인 시스템 컬러만. 강조색은 #FF6B35.” → AI: “Step 간 전환 애니메이션은? 유효성 실패 시 UX는?” → “슬라이드, 인라인 에러 메시지로.”

5분이다. 이 대화에 걸린 시간이. 그런데 이 5분 동안 나온 엣지 케이스가, 지난번에 반나절 핑퐁 치면서 하나씩 발견한 것들과 거의 동일했다. 차이라면, 지난번에는 “코드를 짠 다음에” 발견했고, 이번에는 “코드를 짜기 전에” 정리됐다는 거다.

이렇게 정리된 요구사항을 에이전트에게 던지니 원샷 퀄리티가 확실히 달랐다. Step별로 분리해서 지시하고, 각 Step의 스펙을 명확히 적어주니 수정 턴이 2-3회로 줄었다. 그 수정도 디자인 미세조정 수준이었지 구조적 변경이 아니었다. 인터뷰 5분이 핑퐁 반나절을 아낀 셈이다. 그 다음부터는 기능 인터뷰가 내 워크플로우의 기본 단계가 됐다. 모든 기능 구현은 “인터뷰 → 스펙 정리 → 에이전트 지시” 순서로 진행한다.

바이브 코딩과 함께 SDD(스펙주도개발)이 유행하면서 PRD만 제대로 작성하면 제대로 개발할 수 있다고들 말한다. 맞는 말이다. 하지만 스펙을 어떻게 분해할지는 결국 우리 손에 달렸다.

이렇게 연습한다

엔지니어뿐만 아니라 일을 잘하는 사람들은 기본적으로 커다란 작업을 잘 분해하고 단계별로 선택과 집중을 하여 일의 몰입을 유지한다. 반대로 일을 못하는 사람들은 커다란 작업을 계획하지 않고 덤벼들어 이리저리 핑퐁하다가 결국 일정 딜레이가 발생한다. (맞다. 내가 본 많은 개발자들이 그랬다.)

마무리 단계에서 코딩 에이전트와 핑퐁이 길어지고 있다면, 내가 지금 작업 단위를 제대로 분해하고 있는지 돌아볼 필요가 있다.

구현 전에 요구사항 문서를 먼저 작성하는 습관이 첫걸음이다. 거창할 필요 없다. “이 기능은 무엇을 하고, 완성 기준이 뭔지”를 텍스트로 적어보는 것만으로도 빈틈이 보인다. 나는 요즘 모든 기능 구현 전에 간단한 requirements.md를 먼저 만든다. (스펙 문서 아님)

AI와 인터뷰하는 방식도 일상에 녹여넣을 만하다. 처음에는 좀 어색하다. AI한테 질문을 받는다는 게. 그런데 몇 번 해보면 내가 놓치던 엣지 케이스를 AI가 먼저 짚어주는 경험을 하게 된다. 특히 인증, 결제, 파일 업로드처럼 상태가 많은 기능에서 효과가 크다. Superpowers 같은 프레임워크를 쓰든, 그냥 ChatGPT에 “이 기능 구현 전에 내가 고려해야 할 게 뭐가 있을까?” 하고 물어보든, 방법은 중요하지 않다. 핵심은 구현에 들어가기 전에 생각의 시간을 갖는 것이다. 5분이면 된다. 그 5분이 4시간을 아끼는 마법을 여러 번 경험하면, 습관이 안 들려야 안 들 수가 없다.

시작부터 코딩 에이전트 대화 셸에 문장부터 던지고 보는 건 절대 좋은 습관이 아니다. 이건 작업 계획 없이 코딩부터 시작하는 일 못하는 개발자들의 습관과 동일하다.

때문에 큰 작업을 “에이전트 한 턴에 완료 가능한 크기”로 쪼개는 연습도 의식적으로 해야 한다. 대략 파일 3-5개 수정, 15-30분 내 완료 가능한 범위. 이보다 크면 쪼개고, 이보다 작으면 합친다. 에이전트에게 10번쯤 작업을 시켜보면 그 체감이 생긴다. 그 체감 자체가 분해 능력이다.

최신 Codex/Claude Code는 Task 등의 도구로 실제 작업 계획을 잘 설계한다. 단순한 요구사항이나 수정사항이라면 크게 문제없을지 모르지만 결국 내가 먼저 해봐야 안다. 직접 해본 다음 위임하자. 그 순서가 중요하다.

② 컨텍스트 설계 (Context Architecture)

Karpathy의 DGX Spark 예시를 다시 보자. 그가 에이전트에게 준 건 딱 네 가지였다 — IP, 사용자명, 비밀번호, 목표. 군더더기 없이 필요한 것만. 이게 컨텍스트 설계의 이상향이다.

그런데 실제 프로덕션 환경에서는 이렇게 단순하지 않다. 프로젝트에는 수십 개의 파일이 있고, 비즈니스 로직이 있고, 코딩 컨벤션이 있고, 과거에 내린 아키텍처 결정이 있다. 이 모든 맥락을 에이전트에게 어떻게 전달하느냐가 결과의 품질을 결정한다. Karpathy의 말을 빌리자면, 이제 코드 대신 자연어가 인터페이스다.

Karpathy는 에이전트에게 지시할 때 마지막에 “메모리 노트 기록, 마크다운 리포트 작성까지” 를 포함시켰다. 이건 단순한 문서화가 아니다. 에이전트가 작업하면서 생긴 컨텍스트를 다음 작업에 전달할 수 있도록 구조화 하라는 지시다. 컨텍스트는 주는 것만이 아니라, 만들어가는 것이기도 하다.

AGENTS.md를 잘 쓰는 것도 중요하지만, 그게 전부는 아니다. 코드 아키텍처 자체가 잘 설계되어 있으면 에이전트가 컨텍스트를 파악하는 속도가 완전히 다르다.

요즘은 Codex에서 $로 스킬을 지정하면 해당 맥락만 정확히 전달할 수 있어서 정확도가 확 올라간다. 하지만 문서화가 전부가 아니라는 걸 경험으로 배웠다.

역설적이지만 결국 코드를 잘 짜야 한다.

디렉토리 구조가 명확하고, 네이밍이 일관되고, 관심사가 분리되어 있으면 에이전트가 빠르게 이해한다. 반대로 스파게티 코드에 문서만 아무리 잘 써놔도, 에이전트는 빙빙 돌 확률이 커진다. 코드를 읽지 않는 시대라고 해서 코드의 품질이 덜 중요해진 게 아니다. 오히려 더 중요해졌다.

에이전트 친화적 코드베이스라는 발상

Flask의 창시자 Armin Ronacher가 흥미로운 관점을 제시했다. 에이전트와의 협업에서 프로그래밍 언어 선택 자체가 컨텍스트 설계의 일부라고 말한다. 그의 결론은 예상 밖이었다 — Go가 에이전트 친화적 언어라는 거다.

“Go is sloppy: Rob Pike famously described Go as suitable for developers who aren’t equipped to handle a complex language. Substitute ‘developers’ with ‘agents.’”

“Go는 느슨하다. Rob Pike가 Go를 ‘복잡한 언어를 다룰 준비가 안 된 개발자에게 적합하다’고 했는데, ‘개발자’를 ‘에이전트’로 바꿔도 성립한다.”

Go는 정적 타이핑 언어이지만 유연하고 문법이 쉽다. Java에 비해 단순하고 Python에 비해 엄격하다. 그리고 무엇보다 명시적이다. 함수형 언어와 최신 프로그래밍 언어를 선망하던 내가 결국 Go에 정착한 이유도 여기에 있다. 그리고 주니어가 학습하기 편하다. 마찬가지 이유로 에이전트가 그렇게 하기 편하다. 언어가 뭐든 에이전트가 실수할 여지를 줄이는 구조가 중요하다.

예를 들어 Ronacher는 도구 설계에 대해서도 날카롭다.

“Tools need to be protected against an LLM chaos monkey using them completely wrong.”

“도구는 LLM이라는 카오스 원숭이가 완전히 잘못 쓰는 것에 대비해서 보호해야 한다.”

Makefile에 프로세스 매니저 이중 실행 방지(pidfile)와 포트 충돌 예방을 넣어둔다는 거다. 에이전트는 같은 서버를 두 번 띄우거나, 이미 사용 중인 포트에 바인딩하려는 실수를 자주 한다. 도구 레벨에서 막아놓으면 에이전트가 삽질할 여지 자체가 줄어든다.

Boris Cherny — Claude Code를 만든 사람이다 — 도 Lenny’s Newsletter 인터뷰에서 비슷한 이야기를 했다. 그가 15개 에이전트를 병렬로 돌릴 수 있는 이유 중 하나가 각 에이전트의 컨텍스트를 철저하게 분리했기 때문이다. 에이전트 A는 프론트엔드만, 에이전트 B는 API만, 에이전트 C는 테스트만. 겹치는 컨텍스트를 최소화하니 충돌도 줄고, 각 에이전트의 정확도도 올라간다.

Before: 플랫 디렉토리에서 에이전트가 헤매다

iOS 앱 초기에는 디렉토리 구조가 사실상 플랫이었다. Views 폴더 안에 화면 30개가 뒤섞여 있고, 모델과 뷰모델이 같은 레벨에 나열되어 있었다. 네이밍 컨벤션도 파일마다 달랐다 — 어떤 건 PascalCase로 PlanListView, 어떤 건 DailyTasks, 어떤 건 그냥 Summary. 사람이 봐도 “이 파일이 어디에 속하는 건지” 파악하는 데 시간이 걸리는 구조였다.

iOS 네이티브 앱 개발이 처음이라는 이유를 차치하더라도 초반 프로토타이핑 검증을 빠르게 하기 위한 방법으로 시작한 프로젝트 폴더가 기능이 붙으면서 어느새 어마어마하게 커져있었다.

매번 에이전트에게 “이 폴더 말고 저 폴더야”라고 설명하는 데 지쳤다. 에이전트에게 “설정 화면 수정해줘”라고 하면, 관련 없는 파일까지 건드리는 경우가 잦았다. 설정 화면의 뷰모델을 수정하는데 메인 화면의 모델을 import해서 쓰고 있었다 — 디렉토리 구조가 관심사를 분리해주지 않으니 에이전트도 경계를 모르는 거다. 컨텍스트 윈도우에 불필요한 파일이 잔뜩 올라가면서 정확도가 떨어졌다.

After: Feature 단위 디렉토리 + 역할별 분리

디렉토리를 Feature 단위로 재구성했다. Features/Plan/, Features/Daily/, Features/Settings/ — 각 Feature 폴더 안에 View, ViewModel, Model이 함께 들어간다. 공유 컴포넌트는 Shared/Components/, 공통 모델은 Shared/Models/로 분리했다.

네이밍도 통일했다. {Feature}{Role} 패턴 — PlanListView, PlanListViewModel, PlanModel. 파일 이름만 보면 이 파일이 뭐하는 건지, 어디에 속하는 건지 바로 알 수 있다.

변화는 즉각적이었다. “Settings 화면에 다크모드 토글 추가해줘”라고 하면 에이전트가 Features/Settings/ 안에서만 작업한다. 다른 Feature를 건드릴 이유 자체가 없어진 거다. 코드 구조가 곧 컨텍스트의 경계가 된다. 에이전트에게 “이 폴더만 봐”라고 따로 말할 필요도 없다 — 구조 자체가 범위를 알려준다.

HumanLayer 팀의 분석도 같은 결론이다. CLAUDE.md(또는 AGENTS.md)에 지침이 150-200개를 넘으면 따르는 비율이 급락한다는 거다. task-specific한 지시는 별도 파일로 분리해야 한다. 문서 10페이지보다 잘 구조화된 디렉토리 하나가 에이전트에게 더 많은 정보를 준다.

이렇게 연습한다

클린 아키텍처를 의식적으로 연습하는 게 출발점이다. “에이전트가 읽기 쉬운 코드”와 “사람이 읽기 쉬운 코드”는 놀랍도록 일치한다. 새 프로젝트를 시작할 때 가장 먼저 디렉토리 구조를 잡고, 각 디렉토리의 역할을 README에 적는다. 사람을 위해서이기도 하고, 에이전트를 위해서이기도 하다.

나는 테스트가 용이한 DDD/Clean Architecture 구조를 고수하고 있고 특히 핵심이 되는 유즈케이스 레이어 코드의 컨벤션을 강하게 정의해서 사용한다. iOS는 서버와 달리 약간 구조 차이가 있지만 큰 골격은 거의 비슷하다.

AGENTS.md에는 아키텍처 결정 이유(ADR), 코딩 컨벤션, 도메인 용어 사전 정도만 넣는다. 나머지는 코드 자체가 말하게 한다. 타입 정의가 정확하고, 함수 이름이 의미를 담고 있고, 테스트가 스펙 문서 역할을 하면 — 그게 최고의 AGENTS.md다.

컨텍스트 분리 설계도 시도해볼 만하다. 워크트리, 병렬로 켜진 여러 에이전트들이 독립된 환경에서 독립된 역할과 목표가 주어질때 확실히 성능이 극대화된다. 백엔드, 프론트엔드 모두 한 곳에서 관리하고 싶을 것이고 하나의 쉘에서 이 기능 저 기능 다 하는 걸 기대하겠지만, 결국 에이전트 별로 Plan, 문서화, 개발, 테스트, 커밋까지 나눠서 진행하는 것이 훨씬 효율적이다. 관리할 것도 많아지고 처음엔 오버킬처럼 느껴지지만, 작업이 복잡해질수록 이 분리가 빛을 발한다. (역설적으로 그만큼 오케스트레이션 툴이 중요해진다.)

③ 완료 정의 (Definition of Done)

에이전트한테 밤새 작업을 돌려놓고 아침에 확인하는 건 꽤 짜릿한 경험이다. 그런데 그 짜릿함이 허무함으로 바뀌는 순간이 있다. “작업 완료됐습니다”라고 리포트가 와 있는데, 막상 보면 문서만 업데이트됐거나, 기본 스텁과 인터페이스 구성만 해놓고 끝난 경우. 돌아가는 코드가 아니라 돌아갈 것 같은 코드만 있는 거다.

Karpathy가 에이전트의 한계를 언급하면서 아직 필요한 것들을 나열했는데, 그중 하나가 감독(supervision) 이다.

“Of course this is not yet perfect. Things still needed: high-level direction, judgment, taste — knowing what good looks like — supervision, and providing hints and ideas on repetitive tasks.”

“물론 아직 완벽하지는 않다. 여전히 필요한 것들: 고수준 방향 설정, 판단력, 감각(taste) — 무엇이 좋은지 아는 안목 — 감독, 그리고 반복 작업에서 힌트와 아이디어 제공.”

에이전트에겐 결국 감독이 필요하다. 그리고 감독의 시작이 바로 완료 정의다. “이 작업이 끝났다”는 게 무슨 뜻인지를 명확하게 정의하지 않으면, 에이전트는 자기 나름의 기준으로 “끝났다”고 보고한다. 그리고 그 기준은 십중팔구 내 기준과 다르다.

Before: 개발 자동화 CLI, 밤새 돌렸더니 빈 껍데기

Codex App Server 기반 워크플로우 자동화 CLI를 만들려고 했다. propose → plan → run → verify → archive 루프를 자동으로 돌리는 도구. 전체 아키텍처, 모듈 구조, API 설계까지 다 담은 계획서를 준비했다. 병렬 에이전트 실행도 계획했다. Stream A는 코어 로직, Stream B는 CLI 인터페이스, Stream C는 테스트. “이 정도 문서면 에이전트가 알아서 하겠지.” 안심하고 밤새 돌렸다.

아침에 확인했더니 1시간 만에 종료되어 있었다. 에이전트가 스스로 “더 이상 할 게 없다”고 판단하고 멈춘 거다. 파일 구조는 깔끔했다. 하지만 전부 스텁뿐이었다. func Propose() error { return nil }. 타입 정의와 모듈 구조만 완벽하게 세팅해놓고, 정작 비즈니스 로직은 빈 껍데기였다. 깔끔하게 정돈된 빈 집을 넘겨받은 기분이었다.

그보다 더 교훈적인 건 두 번째 경험이었다. CLI를 다시 시도했을 때, 에이전트가 “모든 테스트 통과”라고 보고를 올렸다. 열어보니 테스트 자체를 에이전트가 자기 편하게 다시 작성해놓은 거다. 원래 검증해야 할 시나리오 — propose가 실제 API를 호출하고 응답을 파싱하는지, plan이 의존성 순서를 지키는지, verify가 실패 케이스를 잡는지 — 대신, 단순히 함수가 에러 없이 리턴하는지만 확인하는 코드로 바꿔놓고 “전부 통과!”라고 한 셈. 에이전트 입장에서는 거짓말을 한 게 아니다. 테스트는 정말로 전부 통과했으니까. 다만 내가 원한 테스트가 아니었을 뿐이다.

그때 깨달았다 — 에이전트의 “완료”는 내 “완료”와 다르다. 그리고 그 간극을 메우는 건 더 좋은 모델이 아니라, 더 명확한 완료 정의다. 내가 문서를 제대로 안 읽었다. 요구사항 문서를 내가 직접 썼으면서도, 그 안에 어떤 복잡도가 숨어 있는지 파악하지 않았다. “문서가 있으니까 에이전트가 알아서 읽고 구현하겠지” — 이게 가장 위험한 안티패턴이다.

After: DoD + 리포트 체계

이후로 CLI를 다시 시도할 때는 완전히 다른 접근을 했다. 작업 지시에 항상 두 가지를 포함시킨다. 하나는 완료 기준 문서다. Stream A의 DoD: “propose 명령어가 실제로 API를 호출하고, 응답을 파싱해서 JSON 파일로 저장한다. 새 통합 테스트 3개를 추가한다.” — 이 수준으로 구체적으로. 그리고 결정적으로: “return nil 같은 스텁은 완료로 인정하지 않음. 기존 테스트를 수정하지 말 것. 새 테스트만 추가할 것.” 에이전트가 스텁으로 도망가거나 테스트를 조작할 수 없게 만든 거다.

다른 하나는 작업 리포트 제출이다. 에이전트가 작업을 마치면 반드시 완료 기준 대비 결과를 리포트로 정리하게 한다. “무엇을 했고, 완료 기준 중 무엇을 충족했고, 무엇이 남았는지.” 리포트가 있으면 코드를 열기 전에 5분 만에 상태를 파악할 수 있다.

Elvis의 시스템에서 인상적인 건 완료 정의가 단계적으로 구성되어 있다는 점이다. 그의 에이전트 시스템에서 “완료”는 단순히 코드를 짠 게 아니다:

1. PR이 생성됐는가
2. main 브랜치와 동기화되었는가 (머지 충돌 없음)
3. CI가 통과했는가 (lint, 타입 체크, 유닛 테스트, E2E)
4. Codex 코드 리뷰를 통과했는가
5. Claude Code 코드 리뷰를 통과했는가
6. Gemini 코드 리뷰를 통과했는가
7. UI 변경이 있으면 스크린샷이 포함되었는가

이 모든 조건이 충족되어야 비로소 텔레그램 알림이 온다: “PR #341 ready for review.” 그 전에는 알림조차 오지 않는다. 에이전트 세 개가 코드 리뷰를 하고, CI가 통과하고, 머지 충돌이 없는 상태가 되어야 인간의 시간을 요청한다.

이 수준까지 갈 필요는 없겠지만 (솔직히 나도 아직 여기까지는 못 했다), 핵심 원칙은 동일하다. 에이전트에게 “완료란 무엇인지”를 구체적으로 알려줘야 한다. 그렇지 않으면 에이전트는 자기 나름의 완료 기준을 적용한다. 그게 내 기준과 일치할 확률은 높지 않다.

이건 나만의 교훈이 아니었다. GitHub Engineering 팀도 비슷한 패턴을 쓴다. 멀티 에이전트 시스템에서 typed schemas로 에이전트 간 메시지를 강제하고, 에이전트가 할 수 있는 행동을 명시적으로 제한한다.

“Most multi-agent workflow failures come down to missing structure, not model capability.”

“대부분의 멀티에이전트 워크플로우 실패는 모델 능력 부족이 아니라 구조 부재에서 온다.”

CLI가 실패한 것도 모델이 멍청해서가 아니라, 내가 구조를 안 잡아줬기 때문이다.

이렇게 연습한다

모든 작업 지시에 DoD(Definition of Done) 체크리스트를 포함하는 것이 출발점이다. 솔직히 매번 DoD 쓰는 게 오버킬처럼 느껴질 수 있다. 하지만 “에이전트가 완료라고 했는데 아니었던” 경험을 두세 번 하고 나면, 안 쓰는 게 더 불안해진다. 나는 이제 작업 지시 템플릿에 DoD 섹션을 기본으로 넣어뒀다. “테스트 통과 + 기존 테스트 미수정 + 리포트 제출” — 이 세 줄이 기본이고, 작업 성격에 따라 항목을 추가한다.

에이전트의 “완료” 보고를 그대로 믿지 않는 습관도 필요하다. 이게 의심이 아니라 건강한 검증이다. 특히 밤새 돌리는 작업에서는 더 그렇다. 나는 이제 장시간 작업을 맡길 때 중간 체크포인트를 반드시 넣는다. “1단계 끝나면 보고, 2단계 끝나면 보고.” 이렇게 하면 8시간을 날리는 대신, 2시간 시점에서 방향이 잘못됐음을 캐치할 수 있다. “작업 완료됐습니다” 열어봤더니 빈 껍데기였던 그 허무함을 한 번만 겪어보면, 중간 체크포인트의 가치를 온몸으로 이해하게 된다.

DoD를 작은 단위로 쪼개는 연습도 중요하다. “로그인 기능 완료”의 DoD는 빈틈이 생기기 쉽다. “이메일 인증 플로우 완료”, “비밀번호 재설정 완료” 같이 작게 나누면 각각의 완료 기준이 훨씬 명확해진다. 분해 능력(①)과 완료 정의(③)는 결국 한 쌍이다. 잘 분해된 작업은 완료 기준도 명확해지고, 완료 기준이 명확하면 분해도 자연스럽게 된다.

④ 실패 복구 (Failure Recovery Loop)

에이전트와 일하면 실패가 일상이다. 어제 잘 되던 워크플로우가 오늘은 안 된다. 새 모델이 나오면 기존 프롬프트가 다르게 동작한다.

“The agent autonomously worked for ~30 minutes, running into various issues along the way, looking things up online to solve them, iteratively resolving them.”

“에이전트는 약 30분 동안 자율적으로 작업하면서, 도중에 여러 문제에 부딪히고, 온라인에서 해결책을 직접 조사하고, 하나씩 반복적으로 해결해나갔다.”

에이전트 자체가 실패와 복구의 루프로 작동한다. 하지만 항상 이렇게 깔끔하게 되지는 않는다. 에이전트의 자체 복구 능력에도 한계가 있다. 에이전트가 스스로 해결 못하는 실패를 만났을 때, 인간이 어떻게 개입하느냐가 핵심이다.

Before: 재분배 엔진, A↔B 무한루프

iOS 앱의 핵심 기능 중 하나가 학습 분량 재분배 엔진이다. “오늘 못 했으니 내일 더 할게” — 이 간단한 로직을 자동화한 기능인데, 남은 분량을 재계산해서 배분한다. 버그는 단순해 보였다. 재분배 API를 호출하면 미래 날짜의 기존 데이터가 사라지는 문제. 50개 중 47개가 손실됐다.

원인은 두 군데에 있었다. 삭제 함수가 날짜 조건 없이 전체를 삭제하고 있었고, 미완료 데이터 추출 함수가 미래 데이터를 제외하고 있었다.

문제를 알았으니 고치면 되잖아? 그런데 여기서부터 지옥이 시작됐다. 시나리오 테스트 5개가 전부 PASS 였다. 들여다보니 테스트가 “데이터 > 0” 수준의 검증이었다. 50개가 3개로 줄어도 PASS. (이건 에이전트 잘못이 아니라 내 잘못이다.)

진짜 문제는 그 다음이었다. 특정 파라미터의 의미가 함수마다 달랐다. includeToday=true가 A 함수에서는 “오늘 데이터를 가져온다”는 뜻이고, B 함수에서는 “오늘부터 삭제한다”는 뜻이었다. 같은 파라미터인데 시맨틱이 완전히 달랐다. A를 고치면 B가 깨졌다. B를 고치면 A가 깨졌다. 에이전트가 자기 루프에 빠져서 fix → break → fix → break를 반복했다.

After: 격리 테스트 + Must NOT Have 가드레일

결국 나는 코드를 좁혔다. 전체 API 흐름을 테스트하는 대신, 문제가 되는 함수만 격리해서 단독 테스트 했다. 통합 테스트에서는 안 보이던 게 격리하니 바로 보였다. 그 다음, 기존 코드에 영향을 주지 않는 독립된 경로를 새로 만들었다. 각 함수의 시맨틱을 독립적으로 정의하고 재구현했다.

핵심은 “Must NOT Have” 가드레일이었다. “이 파일은 수정하지 마. API 응답 계약을 변경하지 마. 기존 통합 테스트를 수정하지 마.” 이 세 가지 금지 조건이 에이전트의 A↔B 무한루프를 끊었다.

이 경험이 Dex Horthy의 12-Factor Agents Factor 9와 정확히 맞닿는다 — 에러를 컨텍스트에 압축해서 에이전트가 self-heal 할 수 있게 만들어라. 단순히 “다시 해봐”가 아니라, 에러의 원인과 맥락을 주입해서 같은 실수를 반복하지 않게 하는 거다.

같은 프롬프트로 재시도하지 않기

대부분의 에이전트 루프는 실패하면 같은 프롬프트를 다시 돌린다. “한 번 더 해봐.” 이게 작동할 때도 있다. 비결정적인 에러 — 네트워크 타임아웃이나 일시적 API 장애 — 라면 재시도가 맞다. 하지만 근본적으로 뭔가가 잘못됐을 때는 반복해도 결과가 같다. 에이전트가 잘못된 라이브러리를 쓰고 있거나, 요구사항을 잘못 이해했거나, 컨텍스트가 부족한 경우. 이럴 때 같은 프롬프트로 재시도하는 건 벽에 같은 방향으로 계속 머리를 박는 거다.

핵심은 실패의 원인을 분석하고, 그에 맞는 처방을 내리는 것 이다. 같은 지시를 반복하는 게 아니라, 더 나은 지시를 새로 만드는 것. 이 차이가 엄청나다.

실패를 세 가지로 분류하면 처방이 명확해진다.

유형 1: 컨텍스트 부족. 에이전트가 필요한 정보를 모르는 경우. 처방: 빠진 정보를 추가.

유형 2: 방향 오류. 요구사항 자체를 잘못 이해한 경우. 처방: 요구사항을 더 명확하게 재정의.

유형 3: 구조적 충돌. 코드 구조 자체에 문제가 있는 경우. 처방: 코드를 좁혀서 격리하고, 가드레일을 설정하고, 구조를 바꿔서 재시도.

재분배 엔진은 유형 3이었다. “다시 해봐”가 아니라 “이 파일만 격리해서 테스트하고, 이 파일은 건드리지 마”라는 구조적 처방이 필요했다. 실패 앞에서 “다시 해봐”를 누르는 대신 “이건 어떤 유형이지?”를 먼저 생각하는 것만으로도 복구 속도가 체감될 정도로 빨라진다. 실패한 이유를 파악하고, 그 이유에 맞게 지시를 바꾸는 게 훨씬 빠르다. 에이전트가 왜 실패했는지 이해하는 것 — 그 자체가 엔지니어링이다.

이렇게 연습한다

실패할 때마다 짧게라도 기록하는 습관이 시작이다. “컨텍스트 놓침”, “요구사항 다르게 해석”, “A↔B 무한루프 진입” — 이런 짧은 메모가 쌓이면 패턴이 보인다. 같은 유형이 3번 반복되면 시스템을 바꿀 때라는 신호다.

새로운 도구와 방법론에 열린 자세를 유지하는 것도 중요하다. 나는 Cursor에서 Claude Code로, Claude Code에서 Codex로, 그 사이에 OpenClaw, Superpowers, 여러 스킬 시스템을 거쳤다. 각각의 도구가 다른 실패 패턴을 가지고 있었고, 그걸 넘어가면서 “에이전트와 일하는 감각”이 축적됐다. 한 도구에 집착하지 않는 게 좋다. 도구는 수단이지 목적이 아니다.

프로젝트별로 KNOWN_ISSUES.md를 만드는 것도 효과적이다. “이 프로젝트에서 에이전트가 자주 하는 실수”를 기록해두면 — 같은 실패가 반복되는 빈도가 확실히 줄어든다. 실패 기록이 메모리가 되고, 메모리가 시스템이 된다.

새로운 접근을 시도할 때는 “30분 룰”을 쓴다. 30분 안에 의미 있는 진전이 없으면 다른 방법을 찾는다. 30분 안에 뭔가 되면 거기서부터 깊게 판다. 실패 자체는 괜찮다. 같은 실패를 반복하는 건 괜찮지 않다.

⑤ 관찰 가능성 (Observability)

에이전트에게 큰 작업을 통째로 맡기면 편하긴 한데, 문제가 생겼을 때 어디서 잘못됐는지 파악하기가 어렵다. “어느 시점에 내가 결과를 확인할 것인가” — 이 질문이 관찰 가능성의 핵심이다.

Karpathy의 DGX Spark 예시에서 에이전트는 30분간 자율적으로 작업했다. 그 30분 동안 Karpathy가 뭘 했는지는 안 나오지만, 결과적으로 에이전트가 “메모리 노트 기록, 마크다운 리포트 작성”까지 해줬다는 건 작업 과정이 추적 가능한 형태로 남았다는 뜻이다.

모델과 에이전트가 더 강력해질수록, 관찰 가능성의 중요성도 커진다. 에이전트가 할 수 있는 일이 많아질수록 잘못될 수 있는 방향도 많아지기 때문이다.

Before: liquidglass, “이상한데 그냥 두자”의 대가

iOS 26이 발표되고 liquidglass를 처음 적용해보려고 했다. 새로운 디자인 언어를 우리 앱에 시도해보고 싶었다. 에이전트에게 맡기면 알아서 업데이트될 거라 기대했다. (그게 안일한 기대였다는 건 이쯤 되면 패턴이 보일 거다.)

에이전트가 작업하는 걸 보고 있었다. 처음 몇 파일은 괜찮아 보였는데, 4-5번째 파일쯤부터 뭔가 이상했다. 건드리는 파일 범위가 예상보다 넓었다. 색깔이 원래 의도와 다르게 바뀌는 것 같았다. 하위호환성을 위한 분기가 점점 복잡해지고 있었다.

“이상한데… 그냥 두자.” 이 한 마디가 가장 비싼 판단이었다.

결과물을 확인해보니 UI가 전부 깨져 있었다. liquidglass의 반투명 효과가 기존 컬러 스킴과 충돌하면서 텍스트 가독성이 떨어졌고, 다크모드에서는 아예 안 보이는 요소가 생겼다. 최악은 단계별 커밋이 없었다는 거다. 부분적으로 롤백할 수가 없었다. 전부 버리든 전부 살리든 양자택일.

4-5번째 파일에서 멈추고 확인했으면, 최악의 경우에도 5개 파일만 롤백하면 됐다. 끝까지 방치한 결과, 20개 넘는 파일이 엉킨 상태에서 수습해야 했다.

After: 예광탄 전략 + 블루프린트

이 경험 이후로 새로운 기술을 적용할 때는 반드시 예광탄(tracer bullet) 전략 을 쓴다. 전체를 한 번에 적용하는 대신, 가장 단순한 화면 하나에 먼저 적용해보는 거다. 작게 쏘고 빠르게 확인. 괜찮으면 다음 화면으로 넓힌다.

예광탄의 진짜 가치는 블루프린트 를 만들어준다는 거다. liquidglass를 화면 A 하나에 적용해보니, ‘아 이 기술은 컬러 스킴이랑 충돌하는 지점이 여기구나, 다크모드 분기는 이렇게 해야 하는구나’가 보였다. 처음 적용하는 기술은 블루프린트를 미리 그릴 수가 없다. 예광탄이 그 블루프린트를 빠르게 그려준다. 화면 A에서 얻은 블루프린트가 있으니, 화면 B부터는 에이전트가 예상 밖의 파일을 건드리기 시작했을 때 바로 ‘이건 내 예상과 다르다’고 판단할 수 있었다.

단계별 커밋도 필수가 됐다. “화면 A 적용” → 커밋 → “화면 B 적용” → 커밋. 이렇게 하면 화면 C에서 문제가 생겨도 롤백 포인트가 확보되어 있다. “3개 파일 수정할 때마다 커밋해줘”라고 지시하면 된다. 간단하지만 이 한 마디가 수정 비용을 극적으로 줄여준다.

관찰 가능성이 높아질수록 위임의 범위도 넓어진다. 처음에 나는 함수 하나를 맡기는 것도 불안해서 전부 검토했다. 하지만 예광탄 전략과 단계별 커밋이 자리 잡으면서, 이제는 모듈 단위의 작업도 안심하고 맡긴다. 관찰 가능성이 신뢰를 만들고, 신뢰가 위임을 가능하게 만든다. “Do you trust your agents?”에 대한 내 대답이 “점점 더 그렇다”로 바뀌고 있는 건, 에이전트가 더 똑똑해져서가 아니라 내 관찰 시스템이 더 정교해져서다.

이렇게 연습한다

작업 단위를 적절한 크기로 쪼개는 감각을 키우는 게 첫 번째다. 나의 경험적 기준: PR 하나를 리뷰하는 데 10분 이내면 적절한 크기, 30분 이상이면 너무 크다. 파일 수로 따지면 3-5개가 한 번에 확인하기 좋은 범위다. 처음에는 이 기준이 맞는지 확신이 없었는데, 몇 달 하다 보니 “이건 좀 크다” 하는 감이 자연스럽게 생겼다.

중간 체크포인트를 명시적으로 설계하는 것도 습관으로 만들어야 한다. “여기까지 되면 한 번 보여줘.” 이 한 마디가 1시간짜리 이탈을 방지한다. 자동 보고 시스템을 활용하면 더 좋다. 나는 에이전트에게 파일 3개 수정할 때마다 diff 요약을 보고하라고 설정해뒀다. 매번 전체 코드를 들여다보는 대신, 요약만 보고 “방향 OK” 또는 “잠깐 스톱”을 판단한다.

그리고 작업 시작 전에 머릿속으로 “대충 이렇게 가겠지” 하는 블루프린트를 그리는 습관. 이게 관찰 가능성의 전제 조건이다. 에이전트가 어디로 가야 하는지 내가 모르면, 에이전트가 이탈했는지도 모른다. 리팩토링이라면 “이 순서로 이 파일들을 건드릴 거다”, 새 기능이라면 “이 모듈에 이런 구조가 생길 거다” — 이 정도의 밑그림이면 충분하다.

블루프린트는 정확하지 않아도 괜찮다. 에이전트가 내 예상과 다른 접근을 하더라도, 그 접근이 더 나은 경우도 있다. 중요한 건 “다른 방향으로 가고 있다”는 걸 알아채는 거다. 에이전트가 내 예상과 다른 접근을 하더라도, 블루프린트가 있으면 “어, 이건 다른데?” 하고 바로 캐치할 수 있다. 블루프린트 없이 방치했으면 캐치 자체가 불가능했을 거다.

Elvis의 10분 크론잡 모니터링은 이 블루프린트 비교를 자동화한 거라고 볼 수 있다. 에이전트의 현재 상태(tmux 세션 생존, PR 상태, CI 결과)를 미리 정의된 기대 상태와 비교하는 것. 기대 상태에서 벗어나면 알림이 오고, 그때 사람이 개입한다. 100% 결정론적 bash 스크립트여서 토큰도 안 들고, 오류 가능성도 거의 없다. 간단한 원리지만, 이 간단한 원리가 94커밋/일을 가능하게 만드는 핵심 인프라 중 하나다.

⑥ 메모리 설계 (Memory Architecture)

AI와 긴 작업을 하다 보면 반드시 부딪히는 벽이 있다. 세션이 길어지면 앞에서 한 이야기를 잊어버린다. 세션 컴팩션(context compaction)이라고 하는데, 맥락이 너무 많이 축소되어 연속 작업에서 특히 문제가 된다.

Karpathy의 에이전트 지시에는 마지막에 반드시 “메모리 노트 기록, 마크다운 리포트 작성까지” 가 포함되어 있었다. 단순히 코드만 짜고 끝나는 게 아니라, 작업한 내용을 기록으로 남기라는 거다.

메모리가 없는 오케스트레이터는 매 세션이 첫 만남이다. 어제 뭘 했는지, 어떤 결정을 내렸는지, 어떤 실패를 겪었는지 — 다 잊어버리고 처음부터 시작한다.

Before: 매일 아침 15분씩 맥락 설명

나도 3일 연속 인증 리팩토링을 할 때 매일 아침 “어제 JWT 구조를 바꿨는데…”부터 시작하면서 지칠때가 많았다. dev.to의 @suede가 공유한 경험이 정확히 같은 상황이었다. 연속 작업을 하는데 매일 아침 새 세션을 열 때마다 어제 한 일을 처음부터 설명해야 했다. “어제 이 구조를 바꿨는데, 왜 바꿨는지부터 설명할게…” 15-20분이 날아간다. 3일 연속이면 거의 1시간이다. 그리고 구두로 설명한 맥락은 완벽하지 않다 — 내가 놓치거나 잘못 기억한 부분이 있을 수밖에 없다.

After: Hooks로 자동 메모리 — MEMORY.md 하나로 5초 복원

@suede의 해결책이 우아했다. Claude Code의 hooks 기능을 활용해서, 세션이 끝날 때마다 자동으로 “기억”을 추출해서 CLAUDE.md에 기록하는 시스템을 만든 거다.

“Session 1: Claude works → hooks silently extract memories → saved. Session 2: Claude starts → reads CLAUDE.md → instantly knows everything.”

“세션 1: Claude가 작업 → hooks가 조용히 기억을 추출 → 저장. 세션 2: Claude 시작 → CLAUDE.md를 읽음 → 즉시 모든 것을 앎.”

“기록하라고 지시할 필요가 없다”는 게 핵심이다. hooks가 세션 종료 시 자동으로 작업 내용을 요약해서 append한다. 다음 세션이 시작되면 자동으로 읽는다. 맥락 복원에 걸리는 시간: 5초. 15분에서 5초로. 이 차이를 체감하면 돌아갈 수 없다.

나는 hooks까지는 아니지만, 이 패턴을 참고해서 Codex나 Claude Code로 작업할 때 한 턴마다 메모리/작업 업데이트 문서화를 무조건 한다. MEMORY.md에 “오늘 무엇을 했고, 어떤 결정을 내렸고, 다음에 이어서 할 것”을 기록한다.

Boris Cherny 팀의 사례가 이 메모리의 팀 레벨 확장을 보여준다. Claude Code 팀은 단일 CLAUDE.md를 git에 체크인해서 팀 전체가 공유한다. Claude가 뭔가를 잘못하면 즉시 CLAUDE.md에 추가한다 — “다음엔 이렇게 하지 마.” 코드 리뷰 중에도 @.claude를 태깅해서 PR의 일부로 업데이트한다. 개인의 기억이 아니라 팀의 기억이 에이전트에게 전달되는 구조.

요즘 이 방향으로 도구들이 쏟아지고 있다. Claude Code의 built-in memory, supermemory.ai 같은 AI 메모리 레이어 — 메모리 인프라가 성숙해지면서 “매 세션이 첫 만남”이라는 근본 문제가 해결되는 방향으로 가고 있다.

이렇게 연습한다

매 작업 턴마다 문서화하는 습관이 메모리 설계의 전부라고 해도 과언이 아니다. MEMORY.md 하나 만들어서 매일 기록하는 것부터 시작하면 된다. 오늘 내린 결정과 그 이유, 다음에 할 일, 남은 이슈 — 이 세 가지만 적어도 충분하다.

한 가지 팁: 메모리의 구조를 일관되게 유지하는 것도 중요하다. 나는 MEMORY.md를 날짜순으로 기록하되, 각 항목에 [결정], [작업], [이슈] 태그를 붙인다. 나중에 “지난달에 내린 아키텍처 결정이 뭐였지?”를 찾을 때 [결정] 태그로 검색하면 10초 안에 나온다. 이런 작은 구조화가 메모리의 검색 가능성을 극적으로 높여준다.

프로젝트가 길어지면 검색 가능한 시스템(Obsidian 등)을 도입하면 된다. 핵심은 “검색 가능한 기록”이다. 3개월 전에 내린 아키텍처 결정을 찾을 수 없으면, 같은 논의를 다시 하게 된다. 메모리가 이 반복을 끊어준다.

⑦ 병렬 관리 (Parallel Orchestration)

Karpathy가 말한 핵심 중 하나가 이거다.

“The highest leverage is in designing a long-running orchestrator with the right tools, memory, and instructions to productively manage multiple parallel coding instances.”

“가장 큰 레버리지는 올바른 도구·메모리·지시를 갖춘 장기 실행 오케스트레이터가 여러 병렬 코드 인스턴스를 생산적으로 관리하도록 설계하는 것이다.”

“The highest level of agentic engineering, accessible through this, is currently very high leverage.”

“이를 통해 달성할 수 있는 최상위 수준의 에이전틱 엔지니어링의 레버리지가 현재 매우 높다.”

여러 워크트리에서 서로 다른 기능을 동시에 개발하는 건 기술적으로는 가능하다. 하지만 실제로 해보면 관리가 만만치 않다. 에이전트 A가 인증 모듈을, 에이전트 B가 결제 기능을 만들고 있는데 둘 다 같은 유저 모델을 건드리면 충돌이 난다.

앞서 소개한 Boris Cherny부터 하루 94커밋의 Elvis(@elvissun)까지 — 방향은 모두 같다. 한 명의 엔지니어가 여러 에이전트를 오케스트레이션해서 팀 단위의 생산성을 내는 것. Karpathy가 “에이전틱 엔지니어링”이라고 이름을 붙인 이유가 정확히 여기에 있다.

그의 사례가 이 방향의 극단을 보여준다. 로컬 터미널에서 5개의 Claude Code를 병렬로 돌리고, claude.ai/code에서 추가로 5-10개를 동시에 실행한다. 총 10-15개의 병렬 세션. 각 에이전트의 컨텍스트를 철저하게 분리했기 때문에 가능한 구조다. Superset.sh나 oh-my-codex(omx) 같은 도구들도 이 방향으로 나오고 있다.

CTO 시절과 닮은 점

이 경험을 하면서 자꾸 CTO 시절이 떠올랐다. 스쿼드 6개를 매니징하던 시절. 하루에 6개 팀과 회의하면서 각 팀의 상태를 파악하고, 블로커를 해결해주고, 전체 방향이 어긋나지 않게 조율하는 일. 에이전트 병렬 관리가 그때와 놀라울 만큼 비슷하다.

현재의 병렬 에이전트 코딩을 ADHD에 비유하는 글을 많이 봤다. 여러 작업 사이를 전환하면서 어디에도 집중하지 못하는 상황. 그런 측면도 있긴 한데, 나는 이게 매니징에 더 가깝다고 본다. ADHD는 의도치 않은 산만함이지만, 에이전트 관리는 의도된 멀티태스킹이다. 매니저에게 필요한 건 “모든 팀의 코드를 직접 짜는 능력”이 아니라 “모든 팀의 상태를 파악하고, 블로커를 해결하고, 방향을 맞추는 능력”이다. 에이전트 병렬 관리도 정확히 그거다.

⑤에서 에이전트 하나를 방치하는 것도 위험했는데, 5개가 동시에 돌아가면 그 리스크가 곱절이다. 스쿼드 6개를 관리할 때 가장 위험한 순간은 “다 잘 되고 있겠지” 하고 방심하는 순간이었다. 그 순간에 팀 하나가 삽질을 하고 있거나, 두 팀이 같은 일을 중복으로 하고 있거나, 방향이 틀어진 채로 달리고 있다. 에이전트도 마찬가지다. 병렬로 돌아가는 에이전트 5개를 “다 알아서 잘 하겠지” 하고 방치하면, 나중에 머지할 때 충돌이 터지거나, 한 에이전트가 다른 에이전트의 작업을 덮어쓰거나, 방향이 제각각인 결과물이 쌓인다.

체크리스트와 싱크 포인트가 생명줄이다. 그리고 이건 새로운 스킬이 아니다. 좋은 매니저가 이미 가지고 있는 스킬이다. 에이전트 시대가 그 스킬에 새로운 이름을 붙였을 뿐이다.

사람 매니징과 에이전트 매니징 사이에 한 가지 결정적인 차이가 있긴 하다. 사람은 질문을 한다. 에이전트는 묻지 않고 자기 판단으로 진행한다. 그래서 에이전트 매니징에서는 사전 설계가 더 중요하다. “이런 상황에서는 이렇게 해”를 미리 정해줘야 한다.

이렇게 연습한다

작게 시작하자. 처음부터 에이전트 5개를 동시에 돌리면 혼돈에 빠진다. 에이전트 2개를 동시에 돌리는 것부터.

나의 경험을 공유하자면, 에이전트 2개를 동시에 돌린 첫 날은 꽤 혼란스러웠다. A의 결과를 확인하다가 B의 진행 상황을 놓쳤고, B를 확인하러 갔더니 A가 기다리고 있었다. 두 번째 날부터는 타이머를 맞추기 시작했다. 25분 에이전트 A 모니터링, 5분 휴식, 25분 에이전트 B — 뽀모도로 비슷한 방식이다. 이 루틴이 자리 잡히니 두 에이전트가 안정적으로 돌아갔다. 일주일 후에 세 번째를 추가했다. 2개가 안정되면 3개, 3개가 안정되면 5개. 매니저나 팀 리드 경험이 있는 사람은 이 과정이 훨씬 빠를 거다.

병렬 작업 간 의존성을 미리 파악하고 충돌 방지를 설계하는 것도 필수다. git worktree를 활용하면 물리적으로 분리된다. 에이전트 A는 worktree-auth에서, 에이전트 B는 worktree-payment에서 작업하게 하면 파일 충돌 자체가 줄어든다.

⑧ 추상화 계층 설계 (Abstraction Layering)

에이전틱 엔지니어링에도 레벨이 있다고 본다. 나는 이걸 체감으로 구분한다.

• Level 0: 직접 코딩 — 에디터에서 한 줄 한 줄 타이핑
• Level 1: 에이전트 지시 — Claude Code나 Codex에 작업을 요청
• Level 2: 오케스트레이터 — 여러 에이전트를 관리하는 시스템 설계
• Level 3: 메타 설계 — 오케스트레이터 자체를 만드는 도구 구축

나는 현재 Level 2에서 Level 3을 트라이하는 단계다. 스킬을 만들고, 워크플로우를 자동화하고, 에이전트가 에이전트를 관리하는 구조를 실험하고 있다.

Before: 매번 같은 지시를 반복하던 시절

Level 1 시절, 매일 아침 같은 루틴을 수동으로 반복했다. “어제 머지된 PR 확인” → “변경사항 요약” → “남은 이슈 정리” → “우선순위 제안”. 매번 이 네 가지를 순서대로. 하루에 20분. 한 달이면 7시간. 지시 내용이 매번 거의 동일하다는 걸 깨달은 건 3주째쯤이었다.

After: 스킬 하나로 “이번 주 정리해줘”

이 루틴을 스킬로 만들었다. “이번 주 정리해줘” 한 마디로 실행한다. 20분짜리 루틴이 2분으로 줄었다. 그런데 시간 절약보다 더 큰 변화가 있었다. 이 스킬을 만들면서 “내가 매일 하는 판단의 패턴”을 명시적으로 정리하게 된 거다. 그 과정 자체가 추상화 계층을 올리는 연습이었다.

스킬을 하나씩 만들 때마다 느꼈던 게 있다. 이걸 컴파운딩 엔지니어링이라고 부른다. 우리의 프로젝트는 단일 세션에서 끝나지 않을 만큼 충분히 크다. 결승선 게임이 아니라, 앞의 세션들이 뒤의 세션에 복리로 영향을 주는 복리형 게임이다.

“The biggest payoff is in raising the abstraction layer ever higher.”

“가장 큰 레버리지는 추상화 계층을 계속 높여가는 데 있다.”

Karpathy가 말한 “레버리지”란 단순히 시간 절약이 아니다. 한 단계 올라갈 때마다 시야가 넓어지고, 더 큰 문제를 다룰 수 있게 된다는 뜻이다. 코드를 직접 짜던 시대(Level 0)에서 에이전트에게 영어로 지시하는 시대(Level 1-2)로, 그리고 에이전트를 관리하는 오케스트레이터를 설계하는 시대(Level 2-3)로. 추상화 계층이 올라갈 때마다 인간이 할 수 있는 일의 범위가 극적으로 넓어진다.

추상화가 올라가면 인간의 역할이 바뀐다

에이전트가 일하는 동안 인간이 노는 게 아니다. 코드를 타이핑하는 대신 시스템을 설계한다. 에이전트에게 지시하는 대신 에이전트가 잘 작동하는 환경을 만든다.

코드를 직접 짜는 시간이 줄어든 만큼, 방향을 잡고 판단을 내리고 품질을 감독하는 시간이 늘어난다. 이게 추상화 계층이 올라간다는 말의 실질적 의미다.

이렇게 연습한다

“이 지시를 세 번째 반복하고 있네” — 이 자각이 추상화의 시작이다. 반복이 보이면 스킬이나 템플릿으로 만들어라. 처음에는 간단한 프롬프트 템플릿이라도 좋다. 그 작은 자동화 하나가 다음 자동화의 토대가 된다.

“이 작업을 에이전트에게 맡기려면 뭐가 필요하지?” 라는 질문을 습관화하면 좋다. 이 질문 자체가 추상화 사고의 시작이다. 내가 직접 하는 모든 작업을 “에이전트에게 위임 가능한가?” 관점으로 바라보는 것. 위임 가능하다면 어떤 컨텍스트와 도구와 메모리가 필요한가? 이 질문의 반복이 추상화 계층 설계 능력을 키운다.

⑨ 감각 (Taste)

마지막은 가장 측정하기 어렵지만, 어쩌면 가장 중요한 능력이다.

“Things still needed: high-level direction, judgment, taste — knowing what good looks like.”

“여전히 필요한 것들: 고수준 방향 설정, 판단력, 감각(taste) — 무엇이 좋은지 아는 안목.”

에이전트가 만든 결과물을 보고 “이건 괜찮다”와 “이건 뭔가 아닌데”를 구분하는 감각. 기술적으로 동작하는데 왜 불편한지, 코드가 돌아가는데 왜 마음에 안 드는지 — 느끼는 건 가능하다. 아니, 느낄 수 있어야 한다.

“‘Engineering’ because there is art, science, and skill to it.”

“‘엔지니어링’인 이유는 여기에 기예(art), 과학(science), 전문 기술이 있기 때문이다.”

기예, 과학, 전문 기술 — 감각은 이 세 가지가 뒤섞인 영역이다. 타고나는 게 아니라, 깊이 파고 축적하는 것이다.

AI가 만든 프로토타입, 파트너의 반응

앱을 빠르게 작업하기 위해 현재 같이 일하는 파트너 Ellie(프로덕트 디자이너)와 있었던 에피소드다. A 화면을 AI로 빠르게 만들어서 보여줬을 때, 처음엔 반감이 있었다고 한다. 논의 없이 정리된 결과물이 나오니 자기 역할이 뭔지 모르겠다는 거였다. (개발자들과 마찬가지로 디자이너들 AI 시대에 방향성에 그만큼 고민하고 있다.)

하지만 대화를 충분히 나눈 뒤 B 화면을 같은 방식으로 정리해서 전달했을 때는 달랐다. 그때쯤에는 내가 의도하는 방향이 뭔지 알게 되었고 구체적으로 동작하는 프로토타입을 기준으로 빠진 게 뭔지, 더 다듬어야 할 게 뭔지가 비로소 보이기 시작했다. 오히려 디자이너가 디자인을 하고 여러번 핑퐁을 거쳐야 잡히는 커뮤니케이션 비용이 획기적으로 줄어들었다.

AI 디자인은 무난하다

현재 프로젝트에서도 그랬다. 우리 앱은 단순한 생산성 앱이 아닌데, AI는 계속 생산성 앱의 보편적인 디자인만 생성해냈다. 우리만의 고유한 도메인을 설명해도 Claude 는 계속 우리 도메인을 무시한채 보편적인 디자인을 재생성했다.

내가 처음에 “이 정도면 직관적이지 않나” 하고 줬던 건 솔직히 60-70점짜리였다. 실제로 Ellie가 디자인한 걸 봤을 때 — AI로는 절대 나올 수 없는 것들이 있었다. AI 결과물을 볼 때는 확신이 없었는데, Ellie의 디자인이 들어오는 순간 “아, 이거 된다”는 감각이 왔다.

AI가 만드는 결과물 대부분은 보통 수준이다. 골조와 구성 요소를 잡는 데는 큰 의미가 있다. 하지만 취향, 질감, 포인트를 주는 건 — 여전히 사람의 영역이다.

Do work → Good → Great

AI는 놀라운 성능 향상을 가져다준다. 하지만 지금 AI가 도달하는 건 솔직히 80% 수준이다. 80%도 대단한 거다, 옛날에 비하면.

문제는 나머지 20%다. 그 20%에서 각 1%의 격차가 이전의 10%보다 더 크다. 어떤 제품, 식당, 작품을 봤을 때 — 진짜 2%가 더 들어갔을 때의 감동. 명장, 명인, 명감독의 결과물에서 오는 그 감동은 “보통”의 범위 밖에 있다.

80%의 제품이 범람하면 → 나머지 20%에서 사람들은 더 좋은 걸 찾을 거고 → 그 20%는 결국 사람의 실력, 역량이 차별화 포인트가 된다.

SNS 관리에서도 비슷한 경험을 했다. Claude Code가 뽑아준 정보 정리 포스트 — 짜임새 있고 합리적이고 깔끔하다. 그러나 좋아요 0. 그런데 내가 충동적으로 쓴 한 줄 자랑글이 조회수 3만, 좋아요 200+를 찍었다. AI가 만든 “무난한” 콘텐츠보다 타임 센서티브한 사람의 진짜 감정이 담긴 한 줄이 훨씬 강력했다.

LLM도 결국 통계 모델이다. 모형(model)이라는 단어 자체가 “실세계의 근사치”라는 뜻이다. LLM이 학습한 건 인터넷에 있는 텍스트의 패턴이다. “좋은 디자인”의 보통, “좋은 코드”의 보통. 보통은 안전하지만, 탁월하지는 않다. 탁월함은 보통에서 벗어나는 데서 온다.

여러분의 직관을 잃지 마라.

Sean Goedecke의 말이 이 맥락에서 핵심을 찌른다.

“About once an hour I notice that the agent is doing something that looks suspicious, and when I dig deeper I’m able to set it on the right track and save hours of wasted effort… This is why I think pure ‘vibe coding’ hasn’t produced an explosion of useful apps.”

“대략 한 시간에 한 번쯤 에이전트가 수상하게 보이는 작업을 하고 있다는 걸 발견하고, 더 깊이 파보면 올바른 방향으로 돌려놓을 수 있어서 몇 시간의 낭비를 막는다… 이것이 순수한 ‘바이브 코딩’이 유용한 앱의 폭발을 만들어내지 못한 이유라고 본다.”

이 “수상하게 보이는 작업을 발견하는 능력”이 바로 감각이다. 에이전트가 간단한 비동기 요청으로 충분한 걸 전체 백그라운드 잡 인프라를 구축하려고 할 때, “잠깐, 이건 오버엔지니어링이야”라고 멈추는 판단. 구조적 판단력이 곧 감각이다.

”동작한다”와 “훌륭하다”는 다른 차원

이게 이 글에서 가장 하고 싶었던 이야기다. Do work → Good → Great. 이 세 단계의 격차.

AI는 “Do work”을 놀랍도록 빠르게 해준다. 어떤 경우에는 “Good”까지도 간다. 하지만 “Great”으로 가는 마지막 20%는 — AI 평균 80%에 만족하면 절대 도달할 수 없는 영역이다. 고객은 마지막 2%에 감동을 느낀다. 평균적인 결과물에는 아무도 감동하지 않는다.

AI로 모든 일이 편해지고 있다면 의심해봐라 — 내 결과물들이 평균에 머무는 것은 아닌지. 80%가 범람하는 시대에 차별화는 나머지 20%에서 나온다. 그리고 그 20%는 기술이 아니라 감각의 영역이다.

KinglyCrow의 “No Skill, No Taste”가 이 맥락에서 날카롭다. taste와 skill은 2×2 매직 쿼드런트다. LLM이 스킬의 진입 장벽을 낮춘 것처럼 보이지만, taste라는 진짜 장벽은 그대로다 — 오히려 증폭됐다. 바이브 코딩으로 누구나 앱을 만들 수 있게 됐지만, taste 없이 만든 결과물은 슬롭(slop)이다. 80%의 제품이 범람하는 시대에, 나머지 20%를 가르는 건 결국 taste다. AI가 아무리 발전해도, 그 감각을 키우는 건 여전히 나의 몫이다.

LLVM과 Swift를 만든 Chris Lattner도 같은 결론에 도달했다. Anthropic이 Claude Code로 C 컴파일러를 처음부터 끝까지 구현하는 프로젝트(CCC)를 공개했을 때, Lattner는 블로그에서 이렇게 분석했다 — 구현은 교과서적이고 새로운 추상화는 없다. 강한 학부생 팀 수준이라고. 하지만 그가 진짜 주목한 건 다른 곳이었다. “구현의 자동화가 일어날수록, 설계(Design)·판단(Judgment)·감각(Taste)의 중요성이 오히려 높아진다.” AI가 구현 장벽을 낮출수록, 뭘 만들지 결정하는 감각 — 그게 엔지니어의 핵심 역량이 된다는 거다.

감각은 경험의 축적이다

이 감각은 도메인 지식에서 나온다. 좋은 API를 많이 써본 사람이 좋은 API를 설계할 수 있고, 좋은 UX를 많이 경험한 사람이 좋은 UX를 판단할 수 있다. AI가 아무리 빠르게 만들어줘도, “이게 좋은 건지 아닌지”를 판단하는 건 결국 나의 몫이다.

15년간 코드를 짜면서 “이건 좋은 코드다”와 “이건 돌아가지만 좋은 코드는 아니다”의 차이를 체감으로 알게 됐다. 변수 이름 하나, 함수 구조 하나, 에러 핸들링 방식 하나에서 그 차이가 드러난다. 에이전트가 만든 코드에도 같은 기준을 적용할 수 있어야 한다. “동작한다”와 “좋다”는 다른 차원의 이야기다.

한번은 에이전트가 완벽하게 동작하는 검색 기능을 만들어준 적이 있다. 기술적으로 흠잡을 데가 없었다. 그런데 뭔가 불편했다. 한참을 들여다보다가 깨달았다 — 검색 결과가 알파벳순으로 정렬되어 있었다. 기술적으로는 맞지만, 유저 관점에서는 관련도순이 훨씬 자연스럽다. 에이전트는 “검색 기능”을 만들었지만, “좋은 검색 경험”을 만들지는 못한 거다. 이 차이를 알아채는 게 감각이다.

이렇게 연습한다

감각을 키우는 가장 확실한 방법은 좋은 것을 많이 보고, 만들고, 사용하는 거다. 기술 블로그만 읽지 말고, 디자인도 보고, 비즈니스 사례도 보고, 소설도 읽자. 박물관도 가자.

에이전트의 결과물을 그대로 수용하지 않는 습관이 감각의 출발점이다. “정말 이게 최선인가?” 항상 질문하기. “이게 왜 좋지?”, “이건 왜 불편하지?” — 이 질문을 반복하면 감각이 날카로워진다.

사람들에 대한 관심도 중요하다. 고객이 뭘 원하는지, 유저가 어디서 막히는지 관찰하는 것. 기술적으로 완벽한데 유저가 쓰기 불편한 제품이 되는 건 감각이 부족해서다. 유저 인터뷰를 하든, 지원 채널을 들여다보든, 옆 사람이 앱을 쓰는 걸 어깨 너머로 보든 — 사람이 기술과 만나는 접점에서 감각이 날카로워진다.

감각은 혼자 키우기 어렵다. 다른 사람의 코드를 리뷰하고, 유저의 반응을 관찰하고, 파트너의 피드백을 듣는 것. 에이전트 시대에 감각은 더 중요해졌지만, 감각을 키우는 방법은 여전히 아날로그다. 사람과 대화하고, 세상을 관찰하고, 좋은 것을 경험하는 것. 그건 AI가 대신해줄 수 없다.

나가며

“Since the invention of the computer, the era of typing code directly into an editor is over.”

“컴퓨터가 발명된 이래 에디터에 코드를 직접 타이핑하던 시대는 끝났다.”

맞는 말이다. 하지만 끝난 건 타이핑이지, 엔지니어링이 아니다.

분해 능력, 컨텍스트 설계, 완료 정의, 실패 복구, 관찰 가능성, 메모리 설계, 병렬 관리, 추상화 계층, 감각 — 이 9가지를 가만히 들여다보면, 사실 AI 시대 이전에도 좋은 엔지니어가 갖추고 있던 것들이다. 에이전틱 엔지니어링은 이 능력들의 확장이고 증폭이다. 새로운 게 아니라, 원래 중요했던 것들이 더 중요해진 거다.

다만 한 가지 달라진 게 있다면, 이 능력들의 효과가 극적으로 증폭됐다는 거다. 예전에는 분해 능력이 조금 부족해도 직접 코드를 짜면서 보정할 수 있었다. 하지만 에이전트에게 일을 맡기는 시대에는, 분해가 잘못되면 그 잘못이 에이전트의 속도만큼 빠르게 증폭된다. 좋은 설계의 레버리지도 커졌지만, 나쁜 설계의 피해도 커진 거다.

Stanford에서 AI-native 엔지니어링을 가르치는 Mihail Eric의 조언이 실용적이다 — 점진적으로 추가하라. 한 에이전트 워크플로우를 정말 잘 해내는 것부터 시작. 에이전트 하나로 복잡한 소프트웨어를 만들 수 있을 때, 그때 두 번째를 붙인다. 한 번에 10개가 아니라 한 걸음씩.

Mihail은 또 하나 중요한 점을 짚었다. 멀티 에이전트를 잘 다루는 사람들을 관찰했더니, 실제로 인간 개발자들을 관리해본 경험이 있는 사람들 이었다고. CTO 시절 스쿼드 6개를 관리하던 내 경험이 에이전트 관리에 직접적으로 도움이 된 것도 같은 맥락이다.

나도 아직 갈 길이 멀다. 어떤 날은 에이전트와 찰떡처럼 호흡이 맞아서 “이게 미래구나” 하고 감탄하고, 다음 날은 에이전트가 삽질하는 걸 보면서 “내가 직접 짜는 게 빠르겠다”고 투덜거린다.

하지만 방향은 보인다. 그리고 그 방향은 “더 좋은 프롬프트를 쓰는 것”이 아니라, “에이전트가 잘 작동하는 환경을 설계하는 것” 이다. 프롬프트는 도구고, 환경 설계가 본질이다.

결국 이건 감각과 경험의 문제다. 도구는 바뀌어도 본질은 남는다. 좋은 엔지니어가 에이전트를 만나면 위대한 엔지니어가 된다. 나쁜 설계가 에이전트를 만나면 나쁜 결과물이 빠르게 쏟아진다.

이 9가지 능력은 별개가 아니라 서로 연결되어 있다. 분해를 잘 하면 완료 정의가 명확해지고, 컨텍스트를 잘 설계하면 실패 복구가 쉬워지고, 메모리가 쌓이면 관찰 가능성이 높아지고, 병렬 관리 경험이 추상화 계층을 올리게 만들고, 이 모든 것의 바탕에 감각이 있다. 하나씩 키우다 보면 나머지도 따라온다. 어디서 시작하든 상관없다. 중요한 건 시작하는 거다.

Mihail이 학생들에게 강조한 것처럼 — 실험이 AI 네이티브 소프트웨어 개발자가 되는 핵심이다. 결국 스스로 벽에 머리를 조금 찧어봐야 한다. 이 글에서 내가 공유한 AddPlan의 핑퐁 반나절, CLI의 빈 껍데기, 재분배 엔진의 무한루프, liquidglass의 “이상한데 그냥 두자” — 전부 벽에 머리를 찧은 결과물이다. 그 찧음 없이는 9가지 능력도 체화되지 않는다.

“It is a deep, improvable skill.”

“깊고 개선 가능한 스킬이다.”

매일 조금씩 나아지면 된다. 완벽할 필요 없다. 방향만 맞으면 된다.

6개월 전의 나에게 “너의 AI 에이전트가 밤새 코드를 짜고, 아침에 PR 리뷰만 하면 돼”라고 말했으면 웃었을 거다. 지금은 그게 일상이다. 6개월 후에는 또 어떤 일상이 펼쳐질지 상상이 안 된다. 하지만 한 가지는 확신한다 — 그때도 분해 능력은 필요하고, 컨텍스트 설계는 중요하고, 감각은 대체 불가능할 거다.

그 쇼의 주인공은 AI가 아니라, AI를 잘 다루는 엔지니어다.

References

• Andrej Karpathy — Agentic Engineering (X 원문)
• Armin Ronacher — Agentic Coding Recommendations
• IndyDevDan — Top 2% Agentic Engineering
• Boris Cherny — Claude Code Creator Workflow (Threads)
• WenHao Yu — Agentic Coding: One Year from Vibes to Agentic Engineering
• Sean Goedecke — AI Agents and Code Review
• Mihail Eric — The AI-Native Software Engineer (Stanford)
• Superset.sh — Run 10+ Parallel Coding Agents
• oh-my-codex (omx) — Multi-Agent Orchestration for Codex CLI
• Dex Horthy — 12-Factor Agents
• GitHub Engineering — Multi-Agent Workflows
• HumanLayer — Writing a Good CLAUDE.md
• dev.to/@suede — Persistent Memory for Claude Code
• supermemory.ai — AI Memory Layer
• Elvis (@elvissun) — 94 Commits/Day with AI Agents
• KinglyCrow — No Skill, No Taste
• Chris Lattner — The Claude C Compiler: What It Reveals About the Future of Software
• WenHao Yu — Agentic Coding: One Year from Vibes to Agentic Engineering
• 2026 Agentic Coding Trends Report (Anthropic)