APC 플랜: 지속 가능한 작업을 채팅에서 분리하기

APC 플랜이 존재하는 이유는 단 하나입니다. 어떤 작업은 세션(session)은 종료되더라도 살아남아야 하지만, 그 작업을 만들어낸 소음(noise)까지 살아남아서는 안 되기 때문입니다.

이것이 바로 APC와 APX 사이의 깔끔한 구분입니다.
APC는 휴대 가능한 컨텍스트 계층(portable context layer)으로, 저장소(repo)와 함께 이동해야 하는 프로젝트 소유의 사실(facts)을 보유합니다.
APX는 일상적인 런타임(runtime) 및 툴링(tooling) 계층으로, 세션, 트랜스크립트(transcripts), 메모(scratch notes), 로컬 상태(local state), 그리고 결론에 도달하기까지의 모든 주고받는 과정과 같은 지저분한 작업들을 보유합니다.

실수는 간단합니다. 사람들이 너무 적게 남기거나, 너무 많이 남기는 것입니다.
만약 최종 코드 디프(code diff)만 남긴다면, 그 변경을 안전하게 만든 추론(reasoning) 과정을 잃게 됩니다.
만약 가공되지 않은 채팅 내용을 저장소에 쏟아붓는다면, 나중에 아무도 신뢰할 수 없는 소음, 개인 데이터, 그리고 미완성된 아이디어들을 가져오게 됩니다.
.apc/plans/는 그 중간 경로입니다.

좋은 APC 플랜은 트랜스크립트(transcript)도 아니고 작업 보드(task board)도 아닙니다. 그것은 향후 작업을 위해 특정 질문에 답을 주는 지속 가능한 산출물(durable artifact)입니다.
명세(spec)는 그곳에 무엇이 속해야 하는지 명확하게 규정하고 있습니다:

• 승인되었거나 나중에 여전히 유용한 구현 계획(implementation plans)
• 마이그레이션 계획(migration plans)
• 릴리스 계획(release plans)
• 다음 단계가 포함된 조사 요약(investigation summaries)
• 미결정 사항 및 제약 조건(open decisions and constraints)

작아 보일 수 있지만, 이는 강력한 규칙입니다.
이는 원래의 세션이 종료된 후에도 계획이 유용하게 유지됨을 의미합니다.
또한 다른 도구, 다른 머신, 또는 다른 기여자가 전체 대화를 다시 재생(replaying)할 필요 없이 작업을 이어받을 수 있음을 의미합니다.

구체적인 예시가 도움이 될 것입니다.
인증 체크(auth checks)를 서비스에서 게이트웨이(gateway)로 이동한다고 가정해 봅시다.
APX 세션 동안 당신은 세 가지 설계를 탐색하고, 두 가지를 거절하며, 몇 가지 엣지 케이스(edge cases)를 테스트할 수 있습니다.
그 과정은 일시적이고 종종 소음이 발생하므로 APX 런타임 상태(runtime state)에 속해야 합니다.
하지만 최종적으로 공유된 결정은 다릅니다:

---
title: "Auth migration"
status: active
...

해당 파일은 긴 대화를 실행 가능한 무언가로 압축해주기 때문에 유지할 가치가 있습니다.
그것은 미래의 기여자에게 프로젝트가 무엇을 결정했는지, 무엇이 여전히 중요한지, 그리고 다음에 무엇이 일어나야 하는지를 알려줍니다.
기여자에게 대화 기록 (transcript)을 신뢰하라고 요구하지 않습니다.
대신 그들에게 현재의 계약 (contract)을 제공합니다.

이것이 더 깊은 핵심입니다: APC 플랜은 사고의 흐름 (thought streams)을 저장하기 위한 것이 아닙니다.
그것은 이미 리포지토리 (repo) 내에서 자리를 잡을 자격을 갖춘 결정들을 저장하기 위한 것입니다.
그렇기에 플랜은 검토 가능하고 (reviewable), 차이점 비교가 가능하며 (diffable), 이식 가능합니다 (portable).
플랜은 다른 프로젝트 산출물 (artifact)과 마찬가지로 코드 리뷰 (code review)를 거칠 수 있습니다.
가공되지 않은 세션 (raw session)은 그럴 수 없습니다.

여기서 APX도 여전히 중요합니다. 왜냐하면 APX는 일상적인 작업이 일어나는 곳이기 때문입니다.
APX는 세션을 수집하고, 로컬 감사 추적 (audit trail)을 유지하며, 유용한 부분을 복구할 수 있도록 돕는 런타임 (runtime)입니다.
하지만 APX가 지속적인 프로젝트 의도 (project intent)를 위한 쓰레기통이 되어서는 안 됩니다.
깔끔한 워크플로우 (workflow)는 다음과 같습니다: APX에서 작업하고, 안정적인 사실들을 추출한 다음, 그것들이 팀에게 안전하고 유용해졌을 때 APC에 작성하는 것입니다.

이 규칙을 적용하는 방법은 간단합니다:

• 현재 세션에만 필요하다면, APX에 유지하세요.
• 나중에 프로젝트 전체에 필요할 수 있다면, APC에 넣으세요.
• 아직 모호하다면, 결정이 확정될 때까지 로컬에 유지하세요.

플랜은 프로젝트가 어떻게 진행되어 왔는지 기억하게 만드는 APC의 부분입니다.
모든 대화가 영구적인 기록을 남길 가치가 있는 것은 아닙니다.
하지만 모든 지속적인 결정은 머물 곳이 필요합니다.