매일 에이전트 (agents)를 사용한 지 몇 달이 지나자, 제가 항상 똑같은 말로 시작하고 있다는 사실을 깨달았습니다.

프로젝트 문서를 읽으세요. 로드맵을 확인하세요. 관련 없는 작업을 덮어쓰지 마세요. 현재 명령어를 사용하세요. 관련 테스트를 실행하세요. 증거를 캡처하세요. 실제로 저의 결정이 필요한 사항은 에스컬레이션 (escalate) 하세요.

문구는 바뀌었지만, 형태는 바뀌지 않았습니다. 저는 이미 제품 작업, 구현 (implementation), 연구, 테스트, 그리고 UI 리뷰 전반에 걸쳐 에이전트를 사용하고 있었습니다. 문제는 에이전트가 유용할 수 있느냐가 아니었습니다. 문제는 모든 새로운 세션이 시작될 때마다 제가 수동으로 동일한 작업 컨텍스트 (working context)를 다시 구축해야 한다는 점이었습니다.

검증 단계를 놓치면 작업이 증거를 생성하는 대신 요약에서 멈출 수 있습니다. 범위를 모호하게 남겨두면 에이전트가 잘못된 것에 대해 그럴듯한 버전을 만들 수도 있습니다. 에이전트는 받은 지침을 따르고 있었습니다. 중요한 프로세스는 단지 제 머릿속과 제가 붙여넣는 것을 기억해야 하는 텍스트 블록 안에만 존재했습니다.

그것은 더 이상 프롬프팅 (prompting) 문제처럼 느껴지지 않았습니다.

그것은 소프트웨어 문제처럼 느껴지기 시작했습니다.

프로세스를 기록했습니다

지난 3월, 기술 라이브러리 (skill library)를 공식화하거나 루프 (loops)를 구축하기 전에, 저는 아이디어에서 출시까지 작업이 어떻게 진행되기를 원하는지 기록하기 시작했습니다. 저는 이 파일들을 프로세스 문서 (process docs)라고 불렀습니다. 쉽게 말해, 이것들은 프로젝트와 함께 저장되는 개발 플레이북 (development playbook)이었습니다. 문제를 명확히 하고, 동작을 설계하며, 작업을 분해하고, 구현하고, 검증하며, 출시 준비가 되었는지 결정하는 방법이 담겨 있었습니다.

저는 공식적인 방법론을 채택한 것이 아니었습니다. 리뷰를 통해 시스템 문제를 발견했기 때문입니다: "완료 (done)"라는 의미가 빌드(build)의 시작과 끝에서 서로 다를 수 있다는 점이었습니다. 에이전트는 코드를 작성할 수 있었습니다. 불일치는 중요한 제품 및 품질 결정이 개별 대화 속에 남겨져 있다는 점에서 발생했습니다.

그래서 저는 구현이 시작되기 전에 그러한 결정들을 공개적인 영역으로 끌어내기 시작했습니다.

우리가 해결하려는 문제는 무엇인가? 범위(Scope)는 어디까지인가? 이 단계가 완료되었을 때 사용자는 무엇을 할 수 있어야 하는가? 어떤 엣지 케이스(Edge cases)가 중요한가? 무엇을 테스트해야 하는가? 작업이 앞으로 진행되기 전에 어떤 증거가 존재해야 하는가?

그 답변들이 설계(Design)가 되었고, 그다음에는 태스크 그래프(Task graph)가 되었습니다. 태스크 그래프는 각 작업(Task), 각 작업이 무엇에 의존하는지, 그리고 작업을 완료하기 위한 통과 또는 실패 조건(Pass-or-fail conditions)을 보여주는 작업 계획입니다. 작업은 코드가 존재한다고 해서 완료된 것이 아니었습니다. 수락 기준(Acceptance criteria)을 통과했을 때 비로소 완료되었습니다. 단계(Phase)는 모든 체크박스에 표시가 되었다고 해서 넘어가는 것이 아니었습니다. 구성 요소들이 함께 작동한 후에야 다음 단계로 넘어갔습니다.

다음 개정 단계에서는 검증 체인(Verification chain)을 명시적으로 만들었습니다. 유닛 테스트(Unit tests)와 계약 테스트(Contract tests)는 개별 요구사항을 확인했습니다. 통합 테스트(Integration tests)는 하나의 단계가 시스템으로서 작동하는지 확인했습니다. 엔드 투 엔드(End-to-end) 시나리오와 인간의 검토(Human review)는 사용자가 설계에서 약속했던 워크플로(Workflow)를 완료할 수 있는지 확인했습니다.

현재의 AI 용어로 말하자면, 그것은 이미 평가 레이어(Evaluation layer)였습니다. 태스크 그래프가 평가 그 자체는 아니었습니다. 그것은 검증 계획(Verification plan)이었습니다. 무엇이 참이어야 하는지, 어디에서 확인해야 하는지, 그리고 어떤 증거가 게이트(Gate)를 닫을(통과시킬) 것인지에 대한 계획이었습니다. 테스트와 검토가 그 증거를 만들어냈습니다.

이 플레이북(Playbook)은 엔지니어링적 판단(Engineering judgment)을 대체하지 않았습니다. 오히려 그 판단을 지속 가능하게 만들었습니다. 모호한 빌드(Builds)를 더 쉽게 식별할 수 있게 되었고, 근거 없는 완료 주장은 하기 더 어려워졌으며, 대화가 끝나거나 다른 에이전트(Agent)가 작업을 이어받더라도 품질 기준(Quality bar)이 더 이상 사라지지 않게 되었습니다.

인프라의 첫 번째 레이어는 자동화가 아니었습니다.

그것은 공유된 명확성(Shared clarity)이었습니다.

반복되는 프롬프트는 여전히 신호였다

개발 프로세스를 기록하는 것은 반복되는 절차들을 더 쉽게 파악할 수 있게 해주었습니다. 동일한 질문들이 계속해서 돌아왔습니다. 에이전트가 이 앱을 어떻게 시작하고 검증해야 하는가? 프론트엔드 리뷰(Frontend review)는 페이지가 렌더링되는지 여부를 넘어 무엇을 검사해야 하는가? 리서치 패스(Research pass)는 소스(Sources)와 날짜를 어떻게 기록해야 하는가?

각각은 반복 가능한 방법론을 가진, 인식 가능한 종류의 작업이었습니다. 그것은 결국 저를 기술(Skills)로 이끌었습니다.

공개된 Agent Skills standard는 에이전트가 특정 작업과 일치할 때 로드하는 지침(Instructions)과 지원 리소스(Supporting resources)가 담긴 휴대 가능한 폴더를 설명합니다. Claude Code의 skills documentation은 유용한 경험칙(Rule of thumb)을 제공합니다. 동일한 절차를 채팅창에 계속해서 붙여넣게 된다면, 하나의 스킬(Skill)을 만드라는 것입니다.

이는 제가 목격한 현상과 일치했습니다. 반복되는 프롬프트(Prompt)는 포착되지 않은 절차(Procedure)였습니다. 스킬은 지침, 스크립트, 예시, 그리고 성공 기준(Success criteria)을 하나의 유지 관리되는 장소에 담았습니다. 또한 스킬은 다음과 같은 유용한 질문들을 강제했습니다. 무엇이 이를 트리거(Trigger)해야 하는가? 무엇이 변할 수 있는가? 에이전트가 내리기에 안전한 결정은 무엇인가? 누가 이를 최신 상태로 유지하는가?

저장된 프롬프트는 단어를 보존합니다. 스킬은 재사용 가능한 작업 방식을 보존합니다.

개발 플레이북(Development playbook)과 스킬은 여전히 서로 다른 문제를 해결했습니다. 플레이북은 작업이 왜 존재하는지, 어떤 결과가 중요한지, 그리고 무엇이 완료된 것으로 간주되는지를 설명했습니다. 스킬은 에이전트가 반복되는 한 부분을 일관되게 실행하도록 도왔습니다. 리뷰 스킬(Review skill)은 리뷰를 개선할 수 있었습니다. 하지만 어떤 풀 리퀘스트(Pull request)가 가장 중요한지, 혹은 해당 변경 사항이 제품 목표를 지원하는지 여부를 결정할 수는 없었습니다.

스킬 또한 유지 관리되는 소프트웨어처럼 다뤄져야 했습니다. 명령(Commands)은 변경되고, 가정(Assumptions)은 만료됩니다. 공개된 스킬에 대한 연구에 따르면, 시스템 상태를 변경(Changing system state)할 수 있는 절차와 지속적인 프롬프트 인젝션 위험(Persistent prompt-injection risks)이 모두 발견되었습니다. 재사용은 가치 있지만, 소유권(Ownership), 권한(Permissions), 그리고 유지 관리(Maintenance)는 여전히 중요합니다.

완벽하게 유지 관리되는 스킬이라 할지라도 여전히 더 큰 한계가 있었습니다. 스킬은 에이전트에게 작업을 수행하는 방법을 알려줄 수는 있었지만, 어떤 작업이 중요한지는 알려줄 수 없었습니다.

프로젝트는 공유 메모리가 되었다

스킬은 변경 사항을 어떻게 리뷰할지는 설명할 수 있었지만, 어떤 변경 사항이 차단되었는지는 알 수 없었습니다. 스킬은 앱을 실행할 수는 있었지만, 어떤 동작이 조사 대상인지 알지 못했습니다. 그러한 답변에는 공유된 프로젝트 상태(Shared project state)가 필요했으며, 저장소(Repository)가 점차 그 역할을 맡게 되었습니다.

여기서 저장소(Repository)란 코드, 문서, 변경 이력이 존재하는 버전 관리(Version-controlled) 워크스페이스를 의미합니다. 실제 작업 과정에서 누락된 컨텍스트가 드러날 때마다 새로운 산출물(Artifact)이 등장했습니다.

온보딩 가이드(Onboarding guide)는 제품, 미션, 그리고 협업 규칙을 설명했습니다. 로드맵(Roadmap)은 우선순위를 기록했습니다. 설계 문서(Design docs)는 의도된 동작과 트레이드오프(Tradeoffs)를 포착했습니다. 태스크 그래프(Task graphs)는 버전을 의존적이고 테스트 가능한 단계로 전환했습니다. 이슈(Issues)는 세션 사이의 범위가 지정된 작업(Scoped work)을 전달했습니다. 풀 리퀘스트(Pull requests)는 변경 사항과 이를 검토하는 데 필요한 증거를 전달했습니다. 커맨드 맵(Command map)은 실행 및 테스트 지침을 최신 상태로 유지했습니다.

Git은 내구성이 있는 메모리 계층(Memory layer)이 되었고, GitHub은 작업 표면(Work surface)이 되었습니다.

문서는 더 이상 작업이 끝난 후에 작성되는 설명서가 아니었습니다. 그것들은 작업이 운영되는 방식의 일부였습니다. 에이전트(Agent)는 프로젝트 플레이북(Project playbook)을 읽고 무엇을 검사하고, 생성하고, 검증하며, 전달해야 하는지 알 수 있었습니다. 다음 에이전트는 이전의 대화 내용이 필요하지 않았습니다.

이 컨텍스트를 저장소에 유지해야 하는 또 다른 이유가 있었습니다. 바로 도구들이 계속 변한다는 점입니다.

저는 구현을 위해 한 에이전트를 사용하고, 리뷰를 위해 다른 에이전트를 사용하며, 시각적 검증을 위해 브라우저 기능이 있는 에이전트를 사용할 수도 있습니다. 운영 모델이 특정 제품의 비공개 메모리나 하나의 긴 대화에 의존할 수는 없었습니다.

Codex, Claude Code 또는 다른 도구이든, 하네스(Harness)가 에이전트를 실행합니다. 프로젝트는 작업이 어떻게 운영되는지를 설명해야 합니다.

이 지점에서 프롬프트는 저에게 인프라(Infrastructure)가 되었습니다. 대부분의 프롬프트는 프롬프트로 남아 있어야 합니다. 하지만 반복적이고 중대한 작업은 내구성이 있는 형태를 갖출 가치가 있었습니다. 즉, 품질 기준(Quality bar)을 위한 서면 프로세스, 반복되는 절차를 위한 기술, 그리고 다른 에이전트가 검사하고 이어갈 수 있는 프로젝트 상태(Project state)가 필요했습니다.

메모리가 움직임을 만들어내지는 않는다

이제 프로젝트는 미션을 설명하고, 프로세스를 기술하며, 결정을 보존하고, 현재 진행 중인 작업이 무엇인지 보여줄 수 있게 되었습니다. 하지만 그 파일들 중 어느 것도 스스로 깨어나지는 않았습니다.

오래된 풀 리퀘스트 (Pull Request)는 계속해서 오래된 상태로 남아 있을 수 있었습니다. 프로세스 실패가 기록은 되었지만 개선을 유도하지 못할 수도 있었습니다. 반복적인 역량 검토 (Capability Review)가 그 주기를 놓칠 수도 있었습니다. 시스템은 기억력을 가지고 있었지만, 그 기억이 행동으로 이어져야 할 시점을 알아차리는 것은 여전히 사람에게 달려 있었습니다.

그 지점에서 루프 (Loops)가 등장했습니다. 이는 에이전트 (Agents)를 바쁘게 만들기 위한 방법이 아니라, 반복되는 작업에 트리거 (Trigger), 명확한 결과물, 결과를 확인하는 방법, 중단 지점, 그리고 판단이 필요할 때의 인간의 결정을 부여하기 위한 방법이었습니다.

다음 단계는 통제권을 포기하지 않으면서 프로세스를 능동적으로 만드는 것이었습니다.

그것이 마지막 포스트의 주제입니다.