#AX-Engineering

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

개인에서 팀, 다시 조직으로 지식을 합치는 일의 어려움은 저장이 아니라 부분적 관점을 평탄화 없이 올리는 데 있다. 이건 중앙집중 문제가 아니라 federation 문제다. 업계가 파는 단일 진실 공급원(SSOT)이 아니라 단일 종합 공급원이 목표여야 하고, 자발적 수평 구조는 딜리버리 압력에 붕괴하므로(Spotify 길드 실패) 집계는 회의가 아니라 워크플로우에 배선돼야 한다

이 시리즈가 만든 모든 앞단 산출물(인테이크 양식, as-is 맵, 위임 결정, 데이터 계약, feed-forward ADR, federation 규칙)은 도구가 아니라 기질(substrate)에 산다. AI 코딩 도구는 소모 레이어이고, durable substrate는 데이터와 그것이 사는 open format, 접근을 중개하는 open protocol, 그리고 도메인 엔티티 모델이다. tool line이라는 멘탈 모델 하나와 세 가지 내구성 테스트로 정리한다

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

"우리 데이터를 AI-ready로 만들어 달라"는 청소 작업이 아니라 발굴 질문이다. Gartner조차 데이터는 사전에 일반적으로 AI-ready가 될 수 없고 용도가 정해져야 정의된다고 못 박는다. 데모 위의 마법 아래에는 빙산 같은 기반이 있고(Sculley), 업스트림 데이터 준비와 다운스트림 컨텍스트 엔지니어링은 같은 문제의 양 끝이며, 이미 만든 LLM Wiki와 ADR이 곧 그 조직의 AI-ready 데이터 프로덕트다

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로 승격된다