#ADR

인테이크와 데이터를 아무리 잘 갖춰도 사양은 100%를 못 덮는다. 고객은 결과를 봐야 비로소 "이것도 돼? 저건 왜 안 돼?"가 나온다. 이건 공정 실패가 아니라 25년 전 명명된 법칙(Boehm의 IKIWISI)이다. 빈틈을 싸게 드러내는 프로토타입 발굴, 과잉일반화 함정의 원리적 해법(좁은 코어 + 변화가 싼 구조), 그리고 빈틈과 경계 결정을 ADR로 흡수해 다음 인터뷰로 되먹이는 루프를 정리한다

무엇을 AI에 맡길지는 75년 된 function allocation 문제다. 하지만 AI 능력의 경계(jagged frontier)는 들쭉날쭉하고 보이지 않아 직관으로 미리 정할 수 없다. 2026년의 재정의는 명확하다. 위임은 능력이 아니라 검증 비용으로 정한다. 검증할 수 없는 건 맡기지 마라. 그리고 위임 결과를 결정 기록으로 남기면 보이지 않던 경계가 팀이 공유하는 지도가 된다

AX 프로젝트에서 고객도 개발자도 자기가 원하는 걸 모른다. 고전 요구공학은 이 문제를 40년 전에 암묵지 추출 기법으로 풀었고, Palantir는 같은 이유로 고객사에 엔지니어를 심었다. 고객이 AI를 만능으로 오해할수록 요구사항을 덜 말하게 되고, 그래서 인터뷰는 받아쓰기가 아니라 암묵지를 캐내는 컴파일 작업이 된다

AX 딜리버리의 가장 흔한 실패는 사람들이 회의실에서 설명하는 절차(Work-as-Imagined)를 자동화하고, 실제로 일이 되게 만드는 암묵적 적응(Work-as-Done)을 놓치는 것이다. IBM Watson과 McDonald's 드라이브스루가 그렇게 무너졌다. 현행 업무를 제대로 포착하는 도구상자(SIPOC, BPMN, CTA/CDM, process mining)와, 그 산출물이 Wiki/ADR로 흘러드는 방식을 정리한다

1편(인터뷰)과 2편(현행 업무)에서 캔 것을 복사해 쓰는 한 장짜리 AI 프로젝트 인테이크 양식으로 굳힌다. 고객과 개발자가 같은 양식의 다른 칸을 채우고, 각 칸은 출처가 분명한 디스커버리 도구(AI Canvas, ML Canvas, Event Storming, pre-mortem)의 산출물이며, 양식의 출력은 frontmatter를 가진 마크다운으로서 Wiki와 ADR로 승격된다

Slack, 회의록, 고객 문서, PR, Linear/Jira, AI 코딩 대화에서 생기는 의사결정을 Hermes Agent로 수집하고 프로젝트·팀·조직 단위 지식으로 통합하는 운영 모델을 정리한다.

Karpathy의 LLM Wiki 패턴에 ADR(Architecture Decision Records)을 결합해 개인 블로그를 누적 지식베이스로 발전시키는 방법. 패턴의 원전, 실제 사례 3종, 2026 연구 결과, 실패 모드와 스케일 한계까지 정리한다