plans/workbench를 definition/jobs로 변경하게 된 과정

지난 글에서는 AI 리뷰에서 발견된 지적 사항을 모두 그 자리에서 수정하는 것이 아니라, Defer나 Observe와 같이 '나중에 재고할' 메커니즘을 도입했습니다.

게다가 리뷰를 통해 얻은 지식 자체를 Knowledge Base로 재활용하려고 했으나, 과거의 지식이 현재 설계 authority에까지 영향을 미치기 시작했기 때문에 이 계획은 철회했습니다.

그렇게 남은 것은,

지식을 무엇이든 기억하게 하는 것이 아니라, '나중에 처리할 작업'을 적절히 남겨두면 충분하지 않을까?

라는 생각이었습니다.

그 자리를 위해 사용하던 곳이 workbench/였습니다.

하지만 여기서 새로운 의문점이 생겼습니다.

여기에 있는 것은 더 이상 '작업대(workbench)'라고 부를 수 있는 것일까?

이번 글에서는 이로부터 AIDD Skeleton의 디렉터리 구성을 다음과 같이 변경한 경위를 작성합니다.

plans/ → definition/
workbench/ → jobs/

원래의 workbench/는 이름 그대로 작업대와 가까운 곳이었습니다.

workbench/
조사 메모
아이디어
...

그런데 실제 운영을 계속하다 보니, 그곳에는 다음과 같은 것들이 놓이게 되었습니다.

• 나중에 재고할 리뷰 지적 사항
• 진행 중인 작업
• 세션을 넘나드는 작업
• 핸드오프 대상
• 재개 조건이 있는 작업

더 이상 중심에 있는 것은 '작업 재료'가 아니라, 현재 또는 미래에 다룰 실제 작업 그 자체였습니다.

그래서 workbench/라는 이름을 재검토했고, 최종적으로 상당히 단순한,

jobs/

으로 변경하기로 했습니다.

공식적인 요구사항이나 설계를 보관하는 곳도 아니고, 단순히 메모를 두는 장소도 아닙니다.

수행해야 할 작업, 진행 중인 작업, 나중에 재개할 작업을 다루는 장소.

이라면 jobs가 가장 직관적이었습니다.

하지만,

plans/
jobs/

이렇게 나란히 놓으니 이번에는 또 다른 의문점이 생깁니다.

이름만 보면,

plans = 앞으로 할 일
jobs = 실제로 하는 일

처럼 보입니다.

하지만 실제 plans/에 있던 것은 다음과 같은 것들이었습니다.

• requirements
• design
• testing
• adopted decisions

이것은 단순한 예정 사항이 아닙니다.

채택된,

'이 프로젝트는 어떻게 되어야 하는가'

를 나타내는 정보입니다.

그래서 plans/도 재검토하여,

definition/

으로 변경하기로 했습니다.

결과적으로,

definition/
무엇을 만들 것인가
어떻게 되어야 하는가
...

라는 분리가 이루어졌습니다.

'계획과 작업'이 아니라, **'정의와 작업'**입니다.

이 변경 사항이 다음 커밋에 반영되었습니다.

• commit
  61bc922

docs: rename plans and workbench domains

해당 PR은 PR #37입니다.

여기서는 굳이 큰 의미 변화를 섞지 않았습니다.

우선,

plans → definition
workbench → jobs

라는 이름 변경만 먼저 수행하고, 그 후에 각자의 책임을 정리했습니다.

디렉터리명 변경과 규칙 변경을 한 번에 진행하면, Consumer 측에서 문제가 발생했을 때,

이름 변경 때문에 망가진 것인지
새로운 규칙 때문에 망가진 것인지
를 구분하기 어려워지기 때문입니다.

plans/라는 이름이라면 어느 정도 섞여 있어도 신경 쓰이지 않았던 정보가, definition/이라고 부르니 갑자기 부자연스럽게 보이기 시작합니다.

예를 들어,

• 현재 어떤 작업을 우선순위로 두고 있는지
• 다음에 무엇을 할지
• 일시적으로 무엇이 블록(block)하고 있는지

는 프로젝트 정의가 아닙니다.

반면,

• requirements
• design
• testing
• 현재 채택된 시스템 상태

는 definition 쪽에 속합니다.

이러한 정리를 진행한 것이 다음 커밋입니다.

54f5631

docs: move current state ownership into definition indexes

또한,

jobs/ 쪽도 단순히 이전 workbench/의 이름 변경처로만 남지 않았습니다.

d8f401e

docs: govern jobs index and change units

게다가,

33be412

docs: 활성(active) Job에 플러스 마커 사용

이를 통해 활성 Job 역시 이름만으로 식별할 수 있게 했습니다.

jobs/
+current-work/
_later-work.md

여기까지 오면,

definition/
이 프로젝트는 어떻게 되어야 하는가
jobs/
...

이라는 역할 분담이 상당히 명확해집니다.

처음에는,

workbench

라는 이름이 좀 아닌 것 같다는 수준의 이야기였습니다.

하지만 workbench → jobs로 바꾸자, 이번에는 plans와의 관계가 이상하게 보였고, plans → definition도 필요해졌습니다.

더 나아가 이름을 변경하면서,

'이것은 정말 definition인가', '이것은 Job 쪽에 있어야 하는 것 아닌가'와 같은 책임의 불일치(ズレ)까지 눈에 잘 띄게 되었습니다.

AI 에이전트가 읽는 리포지토리에서 디렉터리 이름은 단순한 정리용 라벨이 아닙니다.

그 자체로,

여기에 무엇이 있어야 하는지를 AI에게 전달하는 컨텍스트가 됩니다.

그래서, 이름과 실체가 어긋나기 시작하자, 이름뿐만 아니라 책임 그 자체를 재검토할 필요가 있었습니다.

앞으로는 jobs/는 active/inactive뿐만 아니라 parent/child나 handoff, lifecycle까지 갖게 될 것입니다.
거기는 다음 글에서 쓰려고 합니다.

AIDD Skeleton:

주요 변경 사항:

• PR #37
  https://github.com/joyrswd/AIDDSkeleton/pull/37 -
  61bc922

:docs: plans 및 workbench 도메인 이름 변경
https://github.com/joyrswd/AIDDSkeleton/commit/61bc92226dd3ed043fa61696b9dc96ba0d2e8ce5 -
54f5631

:docs: 현재 상태 소유권을 definition 인덱스로 이동
https://github.com/joyrswd/AIDDSkeleton/commit/54f5631d3572a0397b8e40e1ecc2666c0afdb1fb -
d8f401e

:docs: jobs 인덱스 관리 및 단위 변경
https://github.com/joyrswd/AIDDSkeleton/commit/d8f401e2eacdbbe2db22212b414b78f74d68b4ea -
33be412

:docs: 활성 Job에 플러스 마커 사용
※이 글은 필자 자신의 개발 경험・판단・문제의식을 바탕으로, 생성형 AI(ChatGPT)와의 대화를 통해 구성 및 문장화되었습니다.