개발에 사용하는 에이전트 기술들

에이전트 기술이 무엇인지, 그리고 어떻게 자신만의 기술을 만드는지에 대한 게시물은 이미 많이 올라와 있습니다. 그래서 이 포스트에서는 제가 개발을 보조하기 위해 사용하는 다양한 기술들을 깊이 있게 다뤄보고자 합니다.

기술들 (The Skills)

Grill Me (나를 압박하라)

의사결정 트리의 각 분기를 해결하며 상호 이해에 도달할 때까지 계획이나 설계에 대해 사용자를 끊임없이 인터뷰합니다. 사용자가 계획을 스트레스 테스트하고 싶을 때, 자신의 설계에 대해 압박 질문을 받고 싶을 때, 또는 "grill me"라고 언급할 때 사용합니다.

저는 모든 규모가 큰 작업을 시작할 때 Matt Pocock이 만든 이 훌륭한 기술로 시작합니다. 이미 준비된 PRD(제품 요구 사항 문서) / 상세 작업 설명으로 시작하거나, 탐색(discovery) 목적으로 사용합니다. 그러면 에이전트는 언어와 기능적 요구 사항을 맞추기 위해 많은 질문을 던질 것이고, 이를 통해 후속 요청에서 환각 (hallucination) 현상이 덜 발생하게 됩니다.

에이전트의 질문에 답변할 준비가 잘 되어 있어야 합니다. 그렇지 않으면 "grill me" 세션이 아주 오랫동안 지속될 수 있습니다. 제가 충분히 상세하게 답변하지 않았을 때 에이전트가 50개가 넘는 질문을 던진 적도 있습니다.
추가로, 저는 정렬(alignment) 단계가 끝나면 PRD를 만들고 싶은지 저에게 프롬프트를 주도록 이 기술에 추가 요청을 넣었는데, 이것이 다음 기술로 이어집니다.

To PRD (PRD로 변환)

현재 대화 문맥을 PRD로 변환합니다. 사용자가 현재 문맥으로부터 PRD를 만들고 싶을 때 사용합니다.

이 기술은 단순히 현재의 대화를 가져와서 PRD를 생성합니다. 우리는 모든 정보가 포함된 상태로 새로운 컨텍스트 윈도우 (context window)를 쉽게 시작할 수 있도록 대화를 요약하기 위해 이 작업을 수행합니다.

To Issue (이슈로 변환)

계획, 사양(spec), 또는 PRD를 트레이서 불렛 (tracer-bullet) 수직 슬라이스를 사용하여 독립적으로 가져갈 수 있는 GitHub 이슈로 분할합니다. 사용자가 계획을 이슈로 변환하고 싶을 때, 구현 티켓을 생성하고 싶을 때, 또는 작업을 이슈로 세분화하고 싶을 때 사용합니다.

Matt Pocock의 또 다른 훌륭한 기술입니다. 저는 PRD나 계획 세션에 기반하여 이슈를 생성할 수 있도록 GitHub MCP를 사용하도록 이 기술을 약간 수정했습니다.
하지만 에이전트가 해당 작업들을 구현하게 하면 결과적으로 너무 많은 양의 코드가 생성된다는 것을 자주 발견했고, 그것이 제가 "to tasks" 기술을 추가한 이유입니다.

To Task (태스크로 변환)

GitHub MCP를 통해 단일 GitHub issue를 순차적인 작은 구현 태스크(implementation tasks) 목록으로 분해하고, 이를 자식 서브 이슈(child sub-issues)로 생성합니다.

이것은 단순히 To Issue 기술을 수정한 것입니다. 에이전트는 제공된 이슈를 기반으로 정보를 수집하고, 초기 이슈에 연결된 실행 가능한 작은 태스크들을 서브 이슈로 생성합니다. Implement 기술과 결합하면 평균 100~150라인 정도의 작은 풀 리퀘스트(Pull Requests, PR)로 이어지므로, 결과물을 이해하고 리뷰하기가 쉬워집니다.

Implement (구현)

Red-green-refactor 루프를 사용하여 태스크를 구현합니다. 사용자가 TDD(테스트 주도 개발)를 사용하여 기능을 구축하거나 버그를 수정하고자 할 때 사용합니다.

이것은 Matt의 Implement 기술을 수정한 버전입니다.
이 기술은 GitHub MCP를 통한 컨텍스트 수집 및 관련 코드 읽기를 통해 시작됩니다.
그 다음, 변경 사항을 격리하기 위해 새로운 브랜치(branch)를 체크아웃하며, 구현은 red-green-refactor 루프 내에서 수행됩니다.

Discovery (탐색)

새롭거나 익숙하지 않은 코드베이스를 분석하고 탐색하여 핫 패스(hot paths), 아키텍처 패턴(architectural patterns), 고복잡도 영역을 식별합니다. 사용자가 새로운 리포지토리(repository)를 이해하고 싶을 때, 빈번하게 수정되는 파일을 찾고 싶을 때, 코드 난이도를 평가하고 싶을 때, 또는 프로젝트의 특정 하위 디렉토리를 분석하고 싶을 때 사용합니다.

저는 이 기술을 다소 드물게 사용하지만, 몇 번 유용했던 적이 있습니다. 주로 복잡한 파일이나 로직을 강조해 주며, 전체 리포지토리 또는 특정 유스케이스(usecase)를 파악할 수 있도록 도와줍니다.

Plan Sprint (스프린트 계획)

범위를 조정하고, PRD(제품 요구 사항 문서)를 작성하며, GitHub 이슈를 생성하고, 이를 태스크로 분해함으로써 엔드 투 엔드(end-to-end)로 스프린트를 계획합니다. grill-me, prd, to-issue, to-task 기술을 오케스트레이션(orchestrate)합니다. 스프린트를 계획할 때, 스프린트 플래닝(sprint planning)을 할 때, 반복 주기(iteration)를 위해 작업을 확정할 때, 또는 GitHub에서 마일스톤(milestone)을 준비할 때 사용합니다.

이것은 마일스톤이나 스프린트 계획을 보조하고, 장기적인 관점에서 실행 가능한 항목들을 갖추기 위해 사용됩니다. 이 기술은 기존에 소개된 기술들의 존재 여부에 의존하며, 정의된 준비 게이트(readiness gates)에 따라 해당 기술들을 오케스트레이션합니다.

Summary (요약)

제가 가장 유용하다고 느낀 기술들은 기능(feature)이나 프로젝트의 계획(planning) 단계와 관련이 있습니다. LLM의 코드 구현(code implementation)은 여전히 규모가 큰 작업에서는 개선할 점이 많지만, 작업 단위가 작거나, 상용구(boilerplate)가 많거나, 혹은 다른 방식으로 게이트(gate)를 설정할 수 있는 경우에는 유용해집니다. 기술들을 직접 확인해 보시려면 저의 리포지토리(repository)를 여기에서 찾으실 수 있습니다.

또한, 이 워크플로우(workflow)의 많은 부분에 영감을 준 원본 리포지토리인 Matt Pocock의 skill 리포지토리도 꼭 확인해 보세요.