전체 글

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

Multica의 커뮤니티 반응, 기능, 멀티 디바이스/팀 협업 활용법을 정리하고 OpenHands, Devin, Claude Code GitHub Actions, Cline, Cursor Cloud Agents, Codex, Aider, SWE-agent와 비교한다.

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

레포, 논문, 뉴스, 블로그, 소셜 신호와 공모전/해커톤/설명회 같은 기회 정보를 자동으로 수집하고 계속 업데이트되는 지식으로 관리하기 위한 기술 정보 레이더 설계안.

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

Hermes Agent와 Codex CLI, Claude Code의 차이를 정리하고, GPT-5.5와 Claude Opus 4.7 기준으로 어떤 조합이 현실적인지 살펴본다.