AI 어시스턴트는 이제 우리의 일상적인 코딩 루틴의 핵심 부분이 되었습니다. 하지만 이들과 작업할 때 가장 큰 어려움은 컨텍스트 손실(context loss)과 LLM이 하나의 사소한 기능을 구현하기 위해 코드베이스의 절반을 재작성하려는 경향, 즉 '환각(hallucinate)' 현상입니다.

Copilot-cli를 사용하면서 저는 이러한 정확히 같은 문제들을 해결하는 견고한 워크플로우를 개발했습니다. 이 글에서는 생성 품질을 극적으로 향상시키는 두 가지 필수 도구와 Copilot의 행동을 엄격하게 통제하는 일련의 규칙(시스템 프롬프트)을 공유하겠습니다.

1단계. 코딩보다 계획부터: rfc-cli

가장 흔한 실수는 Copilot에게 바로 코드를 작성해달라고 요청하는 것입니다. 명확한 계획 없이는 AI가 전체적인 그림을 금방 놓치게 됩니다. 그래서 제가 채팅창을 열고 프롬프트를 작성하기 전에 가장 먼저 하는 일은 RFC(Request for Comments)를 작성하는 것입니다.

이를 관리하기 위해 저는 rfc-cli를 사용합니다. 이 도구는 리포지토리 내부에서 아키텍처 디자인 기록과 RFC를 관리하도록 설계된 훌륭한 CLI 도구입니다.

저의 RFC 워크플로우:

1. 생성(Creation): rfc-cli new를 사용하여 새 문서를 초기화합니다.
2. 초안 작성(Drafting): 아키텍처, 목표, 계획된 변경 사항을 스케치합니다.
3. 수명 주기(Lifecycle): 이 문서는 상태 기계(state machine)를 엄격하게 따릅니다: draft → review → accepted → implemented. 단계를 건너뛰는 것은 불가능합니다.
4. 검증(Validation): 변경 사항이 있을 때마다 rfc-cli check NNNN으로 문서 구조를 검증합니다.

게다가 모든 RFC는 프로젝트 리포지토리 내부에 직접 저장됩니다. 이는 프로젝트 이력에 엄청난 장점입니다. 팀원들(그리고 6개월 후의 미래의 저)은 언제든지 돌아가서 각 기술적 결정이 정확히 어떻게 그리고 왜 내려졌는지 이해할 수 있습니다.

Copilot이 작업을 수행할 때, 이미 참조할 수 있는 accepted RFC가 존재합니다. 이는 기능이 어떻게 구축되어야 하는지에 대한 추측이나 논쟁을 완전히 제거해 줍니다.

2단계. AI의 기억 상실 극복하기: mem-cli

Copilot-cli는 훌륭하지만, 컨텍스트 창(context window)이 무한하지는 않습니다. 새로운 세션을 시작할 때마다, 이전에 결정했던 내용, 데이터베이스 스키마의 특성, 또는 팀의 로컬 코딩 규칙 등을 잊어버립니다.

세션 간 상태를 유지하기 위해 저는 mem-cli를 사용합니다. 이것은 장기 메모리 계층(long-term memory layer) 역할을 하는 간단하지만 믿을 수 없을 만큼 효과적인 MCP (Model Context Protocol) 서버입니다.

개발 중 중요한 세부 사항이 떠오를 때마다(예: "항상 포트 8080을 사용하라" 또는 "컴포넌트 X는 수정하지 마라, 현재 리라이팅 중이다"), 저는 이 사실을 mem-cli에 저장합니다. Copilot은 이 메모리를 동적으로 조회하여 프로젝트의 실제 상태를 파악하고 최신 정보를 유지합니다.

3단계. Copilot 규칙서 (System Prompt)

마지막으로, 하지만 결코 덜 중요한 것은 아닙니다. 바로 게임의 규칙입니다. 저는 Copilot에게 위반해서는 안 되는 엄격한 일련의 지침을 제공합니다. 저의 시스템 프롬프트(system prompt)는 세 가지 주요 블록으로 나뉩니다:

🛠 코드 (Code)

LLM의 가장 큰 문제는 과도한 엔지니어링(over-engineering)입니다. Copilot이 '너무 창의적'이 되는 것을 막기 위해, 저는 엄격한 경계를 설정합니다:

• 미니멀리즘: 어떤 변경 사항이라도 작업을 해결하는 데 필요한 절대적인 최소한이어야 합니다. 관련 없는 파일에 부작용 수정은 금지합니다.
• 주도권 행사 금지 (No Initiative): 아키텍처를 변경하지 말고, 기존 컴포넌트를 복제하지 마십시오(재사용하세요!). 또한 명확하고 충분히 정당화된 이유 없이 새로운 라이브러리나 의존성을 추가하지 마십시오.
• 품질: 어떤 경우에도 코드 중복을 피하십시오.

🌿 Git 워크플로우 (Git Workflow)

여기에 있는 모든 것은 한계까지 자동화됩니다. Copilot은 제가 브랜치와 릴리스를 어떻게 관리하는지(Rust 기반 프로젝트용으로 설정됨) 정확히 알고 있습니다:

1. main 브랜치에 직접 커밋 금지: 항상 별도의 브랜치에서 작업합니다. 새 브랜치를 생성하기 전에 main 브랜치에 pre_ 접두사를 붙여 태그를 지정해야 합니다.
2. 세분화된 작업 단위: 각 기능은 자체 브랜치를 가집니다. 각 하위 작업은 서브 브랜치를 갖습니다 (형식: phase-N/X.Y-설명).
3. 품질 게이트(Quality Gates): 모든 git commit 전에 테스트를 실행합니다. main으로 병합하기 전에는 전체 스위트(build + test + lint)를 실행해야 합니다. main/master 브랜치는 항상 녹색 상태(green)이며 배포 가능해야 합니다.
4. 릴리스: --no-ff 옵션을 사용하여 병합합니다. main 브랜치로 병합하기 전에 Cargo.toml에서 버전을 올리고, CHANGELOG.md에 상세한 변경 로그 항목을 작성해야 합니다 (영어로). 병합 후에는 해당 커밋에 vX.Y.Z 태그를 지정합니다.

🧠 작업 방식(Working Style)

• 자율성(Autonomy): Copilot이 매 단계마다 허락을 요청하는 것(_예: