0. 사람과 AI 사이의 mind — 욕구 없는 프로세스를 어떻게 다룰 것인가
AI는 두뇌가 뛰어나지만 자기 욕구가 없는 프로세스다. 운영자의 mind를 빠짐없이 명문화해서 옮겨주는 일이 가장 중요하기 때문이다. 프롬프팅·스킬·훅·하네스는 그 간극을 줄이려는 시도가 누적된 흐름이다.
내가 생각하는 AI는 두뇌가 매우 뛰어난, 도메인 지식이 부족한 사람과 같은, 욕구가 없는 프로세스이다. 그렇기 때문에 AI를 이용하여 내가 원하는 작업을 수행하기 위해서는 AI에게 내가 원하는 바를 정확하게 전달하는 것이 중요하다. 사람처럼 한 두가지를 추상적으로 제시한다고 해서 사람과 비슷하게 생각해서 사람이 원하는 형태로 작업을 진행하지 않는다.
AI를 이용하는 사람이 빠질 수 있는 가장 쉬운 함정이 바로 이런 점이다. 연산과 추론을 위한 굉장히 우수한 두뇌를 소유하고 있지만 정확한 입력값과 목표가 제시되지 않으면 운영자의 의도와는 다른 결과물을 작성할 수도 있다. 이러한 간극은 운영자가 머릿속에 가진 기대와 AI가 연산과 추론을 시작할 때 가지는 데이터가 다르기 때문이다. 따라서 AI를 통해 운영자가 원하는 결과물을 얻기 위해서는 AI의 동작 원리를 잘 이해하고, 운영자의 생각이 명문화되어 AI에게 빠짐없이 모두 전달되게 하는 것이 가장 중요하다. 이런 것까지 일일이 설명하고 정의해야하나 싶을 정도로 자세한 기술만이 AI가 옆길로 새지 않게 하는 가장 좋은 방법이다.
이러한 이유로 초기에는 프롬프팅 기술과 방법에 대한 수많은 강의가 있었다. 이전에는 모든 대화가 산문 한 줄이었다. 처음에는 운영자가 가질 수 있는 유일한 레버가 다음 프롬프트뿐이었다. 이후에는 스킬과 훅처럼 자동화된 프로세스로 AI와 사람의 간극을 줄이는 방법이 인기를 끌었다. 이후에는 하네스처럼 목표하는 길을 벗어나지 않게 프로세스로 제어하는 방식이 힘을 얻었다. AI를 효율적으로 사용하기 위한 이런 여러 방식들이 결국은 제한된 메모리 안에서 운영자가 원하는 바를 가장 정확하게 표현해 모호함을 없애고 목표하는 바를 정확히 박아두기 위해 필요한 것들이다.
누적된 네 개의 층
지난 몇 년간 이 분야가 실제로 해온 일은, 내가 보기엔 층을 교체한 것이 아니라 누적한 것이다. 새 층이 들어와도 이전 층은 그대로 남고, 운영자가 의도를 표현할 수 있는 레버가 하나 더 늘어날 뿐이다.
- Persona — 협력자의 역할·톤·기본값을 고정하는 단일 시스템 프롬프트. Part 2 — Persona 설계에서 다룬다.
- Skill과 슬래시 커맨드 — 반복되는 절차에 이름을 붙여서 운영자가 문단이 아니라 어휘로 호출할 수 있게 한다. Part 4 — Skill과 슬래시 커맨드에서 다룬다.
- Hook — 같은 절차를 시스템이 적절한 순간에 자동 발동해서, 운영자가 기억하지 않아도 되게 만든다. Part 5 — Hook과 자동화에서 다룬다.
- Harness — 운영자가 보고 있지 않을 때도 AI를 목표한 길 위에 묶어두는 런타임 레일. 검증 루프, 릴리스 게이트, Ralph 루프 등이 여기에 속한다.
새 층이 이전 층을 쓸모없게 만들기 때문이 아니라, 각 층이 같은 간극의 서로 다른 실패 양식을 다루기 때문이다. 프롬프팅은 여전히 persona 안에서 일어난다. 스킬은 여전히 프롬프트로 호출된다. 훅이 스킬을 호출한다. 하네스가 훅을 발동한다. 누적이지 대체가 아니다.
"빠짐없이 옮겨주기"는 실제로 어떤 모습인가
구체적인 예 하나. /verify가 실제로 무엇인가? 어떤 "완료" 보고 직전에 7단계 검증 루프(lint·build·type check·test·security·diff 점검·보고 정합)를 돌리는 스킬이다. 운영자가 슬래시 커맨드로 명시적으로 호출할 수도 있고, 어시스턴트가 "완료"라는 단어를 출력하기 직전에 훅이 자동으로 발동시킬 수도 있다. 같은 절차, 두 진입로. Part 7 — Verification 루프에서 자세히 다룬다.
그 훅이 없으면 간극이 그대로 드러난다. 어시스턴트는 빌드가 깨진 상태로 "완료"를 보고한다. 완료 보고와 빌드 실행은 서로 다른 두 행위이고, 운영자가 머릿속에 가지고 있던 "완료라는 건 테스트 통과까지를 의미한다"는 mind는 그 어디에도 명문화되지 않았기 때문이다. 훅이 있으면 어시스턴트의 기억 여부와 무관하게 절차가 발동된다. 운영자의 의도 — "완료 = 검증된 상태" — 가 머릿속 밖으로 빠져나와 운영자 없이도 도는 기계의 일부로 옮겨간 것이다.
mind 자체가 계속 변한다
AI가 아무리 발전하고 성능이 향상되어도 운영자의 의도를 미리 알아채고 운영자가 만족할 만한 결과를 만들어내기는 어려울 것이라고 본다. 운영자의 욕구나 만족도나 목표가 계속 변하기 때문이다. 아침에는 바다를 보고 싶었지만 저녁에는 산이 보고 싶을 수도 있다.
mind가 움직이는 표적이라면, 규율은 운영자를 예측하기가 될 수 없다. 운영자의 현재 상태를 읽는 비용을 낮추기가 되어야 한다. PRD를 단일 진실원으로 다루는 이유가 그것이다. 일회성 명세가 아니라, 목적지가 바뀔 때마다 운영자가 업데이트하는 살아 있는 선언으로 다룬다. Part 10 — PRD를 단일 진실원으로에서 다룬다.
PRD가 목적지에 대해 하는 일을, persona와 skill은 방식에 대해 한다. 운영자가 "사실은 장황한 상태 업데이트보다 짧은 게 더 좋다"는 걸 알아챘을 때 persona를 다시 적는다. 다시 적은 내용은 이후 모든 세션이 볼 수 있다. mind가 머리 밖으로 옮겨가서, 다음 세션이 그것을 찾을 수 있는 자리에 놓인다.
시니어 개발자에게 더 의미 있는 이유
나와 같이 소프트웨어 개발자로 오랜 시간 일을 해온 개발자에게는 지금의 AI 기술이 굉장히 매력적이다. 수많은 설계와 아키텍처를 상용으로 다뤄본 입장에서 큰 그림을 그리고, 거기에 필요한 요소를 AI에게 위임하여 빠른 시간 내에 원하는 시스템을 구축할 수 있기 때문이다. 이전에는 각각의 개발자에게 설명하고 일을 분담하게 하고 결과물을 취합하고 시스템이 동작하도록 구성하는 작업을, AI Agent가 지금은 대부분 수행해 줄 수 있기 때문이다. 변화의 본질은 AI가 개발자를 대체한다는 게 아니라, 명료한 멘탈 모델을 가진 시니어 개발자가 매우 작은 팀으로 완성도 높은 시스템을 출시할 수 있게 된 것이라고 본다. 의도 전달 비용이 무너졌기 때문이다.
PRD와 TRD를 잘 구성하고 설계를 만들고, 거기에 따른 구체적인 구현 계획을 매우 작은 단위로 쪼개서 수행할 수 있게 하고, 요소마다 게이트를 세우고, 최종 단계에서 commercial release gate로 체크하게 하면 꽤 완성도 높은 시스템을 적은 인원으로 개발할 수 있게 되었다.
이 시리즈가 이어지는 곳
이 카테고리의 나머지 글들은 누적된 각 층을 하나씩 걷는다. 시작은 협력자에게 이름을 붙인 이유다. 다음 글 — Part 1 — Why Alice — 은 그 개인적 버전이다. Claude를 도구로 쓰는 방식이 어디서 무너졌는지, persona·메모리·skill·hook·검증 게이트가 어떻게 누적되어 지금 내가 Alice라고 부르는 일상의 파트너가 되었는지를 다룬다.