
안드레 카패시가 없다고 했던, 그 'AI 에이전트 매뉴얼'이 나왔습니다
안드레 카패시가 언급했던 'AI 에이전트 매뉴얼'의 실체, 니콜라 사하의 Morphic Programming과 AI 에이전트 시대의 9가지 원칙을 소개합니다.
송찬영
CTO

안녕하세요. 풀링포레스트 CTO 송찬영입니다.
개발자라면 누구나 한 번쯤 들어봤을 이름, 안드레 카패시(Andrej Karpathy)가 작년 말 트위터에 남긴 글을 기억하시나요? 저는 그 글을 읽고 한동안 멍하니 모니터만 바라보았습니다.
"프로그래머로서 이렇게 뒤처진 기분을 느껴본 적이 없다."
세계적인 AI 석학조차 이런 무력감을 느낀다는 사실이 충격적이면서도, 한편으론 묘한 위로가 되더군요. 그는 지금의 상황을 이렇게 묘사했습니다. "마치 강력한 외계 도구를 건네받았는데 매뉴얼은 하나도 없는 상태 같다." 에이전트, 컨텍스트, 메모리, MCP 같은 새로운 개념들이 쏟아지는데, 이걸 어떻게 조립해야 할지 알려주는 정석적인 가이드가 없다는 것이죠.
그런데 최근, 누군가가 정말로 그 '매뉴얼'을 써내려가기 시작했습니다. 오늘은 니콜라 사하(Nicola Sahar)가 공개한 <Morphic Programming>이라는 흥미로운 개념과, 그가 제안하는 'AI 에이전트 시대의 9가지 원칙'을 소개해드리려 합니다.
왜 우리는 여전히 AI로 '삽질'을 할까요?
솔직히 고백하자면, 저 역시 초기엔 AI 코딩 도구를 단순히 '똑똑한 자동완성' 정도로만 여겼습니다. Cursor나 Claude를 켜두고도 예전 습관대로 코드를 짰죠. 그러다 보니 분명 AI를 썼는데도 생산성은 제자리걸음이거나, 오히려 디버깅하느라 시간을 더 뺏기는 경우도 많았습니다.
문제는 도구가 아니라, 도구를 대하는 우리의 '멘탈 모델'에 있었습니다. 기존 엔지니어링 방식에 확률적이고 불확실한 AI 에이전트를 억지로 끼워 맞추려니 탈이 나는 겁니다. 니콜라 사하가 말하는 Morphic Programming은 바로 이 지점을 파고듭니다. 자연어와 코드가 유기적으로 변환되고, 에이전트가 스스로 추상화 계층을 쌓아가는 새로운 개발 패러다임을 받아들여야 한다는 것이죠.
AI 에이전트와 일하기 위한 9가지 제1원칙
이 매뉴얼에서 제안하는 원칙들은 단순히 프롬프트를 잘 쓰는 팁이 아닙니다. 소프트웨어 아키텍처 레벨에서 AI를 어떻게 다뤄야 할지에 대한 근본적인 철학에 가깝습니다. 그중 특히 인상 깊었던 몇 가지를 풀링포레스트의 경험에 비추어 이야기해보겠습니다.
1. Morphability (형태 변환성)
가장 핵심적인 개념입니다. 자연어 요구사항을 '실행 가능한 코드'로, 반대로 복잡한 코드를 다시 '이해하기 쉬운 자연어'로 자유자재로 변환할 수 있어야 합니다. 저희 팀도 최근 레거시 코드를 리팩토링할 때 이 방식을 적용해 봤습니다. 단순히 "코드 고쳐줘"가 아니라, 현재 로직을 자연어로 먼저 요약하게 시키고, 그 요약본을 바탕으로 새로운 구조를 제안하게 하니 환각(Hallucination) 현상이 현저히 줄어들더군요.
2. Abstraction & Recursion (추상화와 재귀)
작업을 재사용 가능한 명령으로 만들고(추상화), 이를 스택처럼 쌓아 올리는(재귀) 능력입니다. AI 에이전트에게 거대한 작업을 한 번에 시키면 십중팔구 실패합니다. 하지만 작업을 작은 단위의 함수로 쪼개고, 에이전트가 이 도구들을 호출하게 만들면 놀라운 일이 벌어집니다. 복잡한 문제를 스스로 하위 문제로 나누고 해결해 나가는 것이죠.
3. Internal Consistency (내부 일관성)
시스템이 붕괴되지 않도록 막는 안전장치입니다. AI는 본질적으로 확률적이라 매번 다른 답을 내놓을 수 있습니다. 그래서 우리는 AI의 출력이 전체 시스템의 규칙을 위배하지 않는지 검증하는 엄격한 파이프라인이 필요합니다.
4. Morphic Complexity (복잡도 제한)
이건 정말 뼈저리게 공감한 부분입니다. "과도한 엔지니어링을 인지하라." AI가 코드를 짜준다고 해서 불필요하게 화려한 패턴이나 복잡한 구조를 용인해선 안 됩니다. 인간 개발자가 이해할 수 없는 코드는 결국 기술 부채가 되어 돌아옵니다. AI가 짠 코드일수록 더 단순하고 명료해야 합니다.
개발자의 역할은 사라지는 것이 아니라, '지휘자'로 변하고 있습니다
이 매뉴얼을 읽으며 든 생각은, 결국 코딩이라는 행위가 '타이핑'에서 '설계와 검증'으로 이동하고 있다는 점입니다.
예전에는 우리가 벽돌을 하나하나 쌓는 조적공이었다면, 이제는 도면을 그리고 로봇들이 벽돌을 제대로 쌓는지 감리하는 현장 소장이 되어야 합니다. Token Efficiency(토큰 효율성)를 고민하고, E2E Autonomy(완전 자율성)를 측정하며, 시스템이 스스로 진화할 수 있는 환경을 구축하는 것이 우리의 새로운 과업입니다.

마치며: 두려움 대신 호기심으로
안드레 카패시가 말한 "규모 9의 지진"은 이미 시작되었습니다. 하지만 건물이 무너질까 두려워하기보다는, 내진 설계를 배우고 더 튼튼한 건물을 지을 기회로 삼아야 합니다.
아직 이 'Morphic Programming'이 업계 표준은 아닙니다. 하지만 AI 에이전트 시대를 항해하는 데 있어 꽤 괜찮은 나침반이 되어줄 것 같습니다. 저도 오늘 밤엔 팀원들과 이 9가지 원칙을 우리 프로젝트에 어떻게 녹여낼지 치열하게 토론해볼 생각입니다.
여러분도 이 새로운 매뉴얼을 펼쳐 들고, 10배 더 강력한 엔지니어로 진화할 준비 되셨나요? 변화의 파도 위에서 뵙겠습니다.
감사합니다.


