코딩은 해결되었습니다. 하지만 팩토리는 그렇지 않습니다.

매우 주관적이며, 저의 개인적인 경험에 기반하고 있습니다. 처방전이 아니라 — 제 자신의 설정을 직접 사용(dogfooding)하면서 계속해서 깨달아가는 내용들을 정리한 노트일 뿐입니다. 저는 이제 막 표면을 긁고 있는 중이며, 아직 배울 것이 많이 남아 있습니다.

저는 멀티 레포지토리 (multi-repo) 개인 코드 팩토리를 구축하고 있습니다. 저는 미리 사양을 정해두지 않습니다. 매일 그것을 직접 사용하며(dogfooding) — 사용하면서 무언가 고장 나면 개선이나 수정을 요구하는 방식으로 운영합니다. 아키텍처 (architectural) 결정은 여전히 모델들이 맹목적으로 내릴 수 없기에, 매일 사용하는 과정이 시스템의 형태를 찾아가는 과정이 됩니다. 범위에 대한 두 가지 전제 조건과 네 가지 주장을 말씀드리겠습니다.

개인적이라는 것은 로컬(local)을 의미합니다 — 좋든 나쁘든 말이죠. 저는 이것을 개인적인 코드 팩토리라고 부르는데, 왜냐하면 이것은 제 노트북 외의 다른 곳에서 실행될 이유가 없기 때문입니다. 인증 레이어 (auth layer)도 없고, 감사 로그 (audit log)도 없으며, 에이전트 (agent)와 저의 git 원격 저장소 (remotes) 사이의 샌드박스 (sandbox)도 없습니다. 여기에는 저의 GitHub 토큰, GitLab 토큰, Slack 자격 증명, 그리고 저의 패스 스토어 (pass store)가 들어있습니다.

동전의 양면처럼, 로컬이라는 점은 이것을 스텔스(stealth) 상태로 만듭니다. 저는 회사 내의 누구에게도 폐를 끼치지 않고 이것을 사용할 수 있습니다. DevOps 팀에 무엇인가를 요청할 필요도 없고, 통과해야 할 IT 보안 검토도 없으며, 조율해야 할 팀 관행 위원회도 없고, 기다려야 할 중앙 인프라 (central infra)도 없습니다 — 그저 제가 직접 손으로 했을 일을 자동화할 뿐입니다. 이는 모든 외부 병목 현상을 제거하며, 제가 빠르게 실험할 수 있게 해주는 요소입니다.

단점은 같은 말을 반대로 한 것과 같습니다. 이것은 저의 것이기 때문에 다른 누구에게도 도움이 되지 않으며, GitLab이나 Slack에서 직접 실행되는 무언가만큼 효율적이지도 않습니다. 이것은 POC (Proof of Concept, 개념 증명)입니다. 만약 이것이 효과가 있는 것으로 판명된다면, 올바른 조치는 이를 실제 회사 인프라로 승격시키는 것입니다.

멀티 레포지토리(multi-repo)는 특정한 종류의 어려움을 의미합니다. 제 업무 방식이 그러하기 때문에 저는 멀티 레포지토리 환경에서 이를 실행합니다. 만약 당신의 코드가 단일 레포지토리 (single repo)에 있다면, 제가 이 시리즈에서 설명하는 많은 내용이 사라지거나 다르게 나타날 것입니다. 저는 멀티 레포지토리 케이스가 더 흥미롭다고 주장하는 것이 아닙니다 — 단지 제가 처한 상황이 그러할 뿐입니다.

1. 코딩은 해결되었습니다

코딩은 해결되었습니다 — Cherny의 표현이며, 저도 그가 옳다고 생각합니다. 네 가지 요소가 필요했고, 이들은 서로 다른 것입니다.

모델 (model): 코드를 작성할 수 있을 만큼 충분한 능력을 갖춘 것.

하네스 (harness): 모델이 단순히 텍스트를 출력하는 대신 행동할 수 있게 해주는 것 — 레포지토리를 읽고, 테스트를 실행하며, 반복하고, 수정하는 과정입니다. (저의 경우는 Claude Code를 사용하지만, 원칙이 특정 도구에 종속되지는 않습니다.)

결정론적 제약 (deterministic constraints) 기술 부채 대신 품질을 향해 출력이 수렴하도록 유지하는 체크 기능입니다. 저는 Python을 사용하므로, 저에게는 prek를 통해 실행되는 ruff, ty, tach와 더불어 gitleaks 및 프로젝트별 훅(hook) 스택이 그 역할을 합니다. 언어가 다르면 도구도 달라지겠지만, 핵심은 도구 체인이 아니라 제약 조건 그 자체입니다.

그리고 기술 (skills): 일반적인 코드베이스가 아닌, '이' 코드베이스에서 올바른 결정을 내릴 수 있도록 모델에게 비즈니스 및 프로젝트 지식을 제공하는 서술된 가이드라인입니다.

이 네 가지 중 하나라도 없으면 작동을 멈춥니다. 하지만 이 중 어느 것도 아키텍처가 '옳다'는 것을 보장하지는 않으며 — 이것이 다음 주장입니다.

2. 그 주변의 팩토리는 해결되지 않았으며, 이를 미리 지정할 수도 없습니다

그 주변의 팩토리(factory)는 해결되지 않았습니다. 저는 이를 사전에 지정할 수 있다고 생각하지 않습니다.

소프트웨어를 구축하고 배포해 주는 시스템을 얻는 데는 두 가지 방법이 있습니다. 첫째, 모든 에지 케이스(edge case), 모든 실패 모드, 모든 통합 사항을 포함한 명세(spec)를 작성하여 에이전트에게 전달하고 구축하게 하는 것입니다. 둘째, 매일 사용하면서 고장 나는 부분을 수정하는 것입니다.

저는 첫 번째 방법을 믿지 않습니다 — 적어도 시도하지는 않을 것입니다. 소프트웨어를 구축, 리뷰, 배포하는 시스템을 위한 명세는 결국 그 시스템 자체와 다를 바 없게 됩니다. 어떤 에지가 문제를 일으키는지 직접 겪어보기 전까지는 알 수 없기 때문입니다. 또한 그 내부의 아키텍처 결정은 여전히 모델이 맹목적으로 내릴 수 없으므로, 명세가 이 모든 것을 사전에 결정해야 합니다 — 저는 이 부분이 아직 작동할 것이라고 보지 않습니다.

결국 두 번째 방법만 남습니다.

3. Dogfooding은 이 모든 것이 작동하는 유일한 루프입니다

남은 것은 Dogfooding(자사 제품 사용)입니다. 즉, 매일 그것을 사용하고, 고장 나는 부분을 고치며, 내일도 계속 작동하도록 유지하는 것입니다.

Dogfooding은 그 어떤 명세(Spec)도 할 수 없는 세 가지 요소를 하나의 루프(Loop)로 융합합니다. 시스템이 작동하는지 검증하고, 잘못된 부분을 개선하며, 그 두 가지를 모두 수행할 수 있을 만큼 충분히 오랫동안 시스템을 가동하는 것입니다. 앞의 두 가지는 동일한 행위입니다. 사용해 봄으로써 검증하게 되고, 작동하지 않는 부분이 바로 당신이 고쳐야 할 부분입니다.

이러한 검증 과정을 덜 수동적으로 만들기 위해 두 부분으로 나뉩니다. 선제적(Proactive)인 절반은 에이전트(Agent)가 의도한 대로 '행동(Behave)'하는지 확인하는 테스트 스위트(Test suite)입니다. 올바른 도구를 선택했는지, 잘못된 도구를 피했는지 등을 확인하여, 행동 회귀(Behavior regression)가 며칠 동안 방치되는 대신 빨간색 테스트 결과로 나타나게 합니다. 저는 이제 막 이 작업들을 시작했습니다. 몇 가지 행동 시나리오와 그 주변의 결정론적 검사(Deterministic checks)를 구현 중이지만, 아직은 노이즈가 많아 전적으로 의존하지는 않습니다. 반응적(Reactive)인 절반은 잘못된 행동이 발생하는 즉시 이를 포착하여 거부하는 런타임 훅(Runtime hook)입니다. 이는 에이전트가 어떻게든 잘못된 행동을 할 때를 대비한 안전장치(Backstop)입니다. 저는 오늘날 이쪽에 훨씬 더 많이 의존하고 있습니다. 하지만 제가 필요로 하는 모든 안전장치는 선제적인 절반이 제때 잡아내지 못한 것들입니다. 만약 평가(Evals)와 에이전트가 충분히 훌륭했다면, 이러한 안전장치들은 무거운 짐(Dead weight)에 불과했을 것입니다. 아직은 그렇지 않기에, 저는 두 가지를 모두 유지합니다.

루프의 세 번째 요소는 전제 조건입니다. 자기 개선(Self-improvement)과 회복 탄력성(Resilience)은 동전의 양면과 같습니다. 가동이 중단되는 시스템은 스스로를 계속 개선할 수 없습니다. 만약 무엇이 더 중요한지 선택해야 한다면, 그것은 회복 탄력성입니다. 루프가 멈추는 순간 개선도 멈추기 때문입니다. 명세를 지정한다고 해서 이 두 가지를 얻을 수 있는 것은 아닙니다. 매일 그것을 실행하고, 고장 난 상태로 두기를 거부함으로써 두 가지를 모두 얻게 됩니다.

그렇다면 누가 이 루프를 조율(Orchestrate)할까요? 그것이 마지막 주장입니다.

4. 조율은 자동화할 마지막 요소입니다

조율은 인간의 영역으로 남는 부분처럼 보입니다. 전체적인 그림을 파악하고, 무엇에 먼저 주의를 기울일지 결정하며, 두 개의 스레드(Thread)가 같은 내용을 다루고 있음을 알아차리고, 무엇을 유지하고 무엇을 버릴지 결정하는 일 말입니다.

teatree에서는 대부분의 과정이 이미 저 없이도 실행됩니다. 군집(Swarm)이 아니라 전체적인 그림을 가진 하나의 오케스트레이터(Orchestrator)가 중재하며 실제 작업은 하위 에이전트(Sub-agents)에게 전달합니다. 여전히 제가 필요한 부분은 기본적으로 문제 해결(Troubleshooting)과 조종(Steering)이며, 행동 평가(Behavioral evals)가 없는 한 이 루프(Loop)를 완전히 닫을 수는 없을 것이라고 생각합니다.

시리즈의 나머지 구성

대략 일주일에 한 번씩 포스팅을 시도할 예정입니다. 각 포스팅은 제가 계속해서 실수하고 있으며, 덜 실수하기 위해 노력하고 있는 내용들입니다.

파트 1 — 소프트웨어 엔지니어링이 소프트웨어 아키텍처가 되다. 결정론적 제약 조건(Deterministic constraints)은 코드 품질을 해결합니다. 하지만 아키텍처가 옳은지 여부는 그 무엇도 해결할 수 없습니다. 그것은 인간의 몫으로 남아 있으며, 이를 검증할 게이트(Gate)는 존재하지 않습니다.
파트 2 — 기술(Skill)이 결코 준수되지 않는다고 가정할 때. 왜 제가 산문 형태의 가이드를 장식적인 것으로 취급하고 중요한 모든 것을 훅(Hook)으로 다루는지, 기술이 안정적으로 읽히지 않기 때문에 왜 메모리(Memory)를 발명해야 했는지, 그리고 에이전트가 실제로 계획대로 행동했는지 확인하는 테스트 스위트(Test suite)인 평가(Evals)를 어떻게 작성하기 시작했는지 — 즉, 훅이 개입하기 전에 기술이 무시되는 것을 어떻게 잡아내는지에 대해 다룹니다.
파트 3 — 스스로를 선택적 리뷰어로 만들기. 폐쇄 루프(Closed-loop) 부분으로, 시스템이 제 승인 없이도 무모하게 느껴지지 않으면서 PR(Pull Request)을 병합(Merge)할 수 있게 하는 놀라울 정도로 어려운 하위 문제(Subproblem)를 포함합니다.
파트 4 — 하나의 오케스트레이터, 다수의 루프. 왜 여러 세션 대신 많은 하위 에이전트를 가진 단일 세션을 실행하는지, 그 비용은 무엇인지, 그리고 제가 생각하는 솔직한 한계점은 무엇인지에 대해 다룹니다.
파트 5 — 데이터베이스 내의 FSM(Finite State Machine). 워크플로우 상태(Workflow state)가 메모리가 아닌 테이블에 저장되면서 동시성(Concurrency), 누수(Leaks), 충돌(Crashes)이 더 이상 두려운 대상이 아니게 된 과정 — 그리고 동일한 기반(Substrate)이 어떻게 여러 리포지토리(Repo)에 걸쳐 회복 탄력성(Resilience)과 분산 개선 메커니즘을 전달하는지에 대해 다룹니다.

마지막 포스트를 올릴 때까지 이 내용 중 일부는 제 생각이 바뀔 수도 있습니다. 그것이 바로 이 작업의 핵심입니다.