0. 사람과 AI 사이의 mind — 욕구 없는 프로세스를 어떻게 다룰 것인가

내가 생각하는 AI는 두뇌가 매우 뛰어난, 도메인 지식이 부족한 사람과 같은, 욕구가 없는 프로세스이다. 그렇기 때문에 AI를 이용하여 내가 원하는 작업을 수행하기 위해서는 AI에게 내가 원하는 바를 정확하게 전달하는 것이 중요하다. 사람처럼 한 두가지를 추상적으로 제시한다고 해서 사람과 비슷하게 생각해서 사람이 원하는 형태로 작업을 진행하지 않는다.

AI를 이용하는 사람이 빠질 수 있는 가장 쉬운 함정이 바로 이런 점이다. 연산과 추론을 위한 굉장히 우수한 두뇌를 소유하고 있지만 정확한 입력값과 목표가 제시되지 않으면 운영자의 의도와는 다른 결과물을 작성할 수도 있다. 이러한 간극은 운영자가 머릿속에 가진 기대와 AI가 연산과 추론을 시작할 때 가지는 데이터가 다르기 때문이다. 따라서 AI를 통해 운영자가 원하는 결과물을 얻기 위해서는 AI의 동작 원리를 잘 이해하고, 운영자의 생각이 명문화되어 AI에게 빠짐없이 모두 전달되게 하는 것이 가장 중요하다. 이런 것까지 일일이 설명하고 정의해야하나 싶을 정도로 자세한 기술만이 AI가 옆길로 새지 않게 하는 가장 좋은 방법이다.

이러한 이유로 초기에는 프롬프팅 기술과 방법에 대한 수많은 강의가 있었다. 이전에는 모든 대화가 산문 한 줄이었다. 처음에는 운영자가 가질 수 있는 유일한 레버가 다음 프롬프트뿐이었다. 이후에는 스킬과 훅처럼 자동화된 프로세스로 AI와 사람의 간극을 줄이는 방법이 인기를 끌었다. 이후에는 하네스처럼 목표하는 길을 벗어나지 않게 프로세스로 제어하는 방식이 힘을 얻었다. AI를 효율적으로 사용하기 위한 이런 여러 방식들이 결국은 제한된 메모리 안에서 운영자가 원하는 바를 가장 정확하게 표현해 모호함을 없애고 목표하는 바를 정확히 담아내기 위해 필요한 것들이다.

누적된 네 개의 층

지난 몇 년간 이 분야가 실제로 해온 일은, 내가 보기엔 층을 교체한 것이 아니라 누적한 것이라고 생각한다. 새 층이 들어와도 이전 층은 그대로 남고, 운영자가 의도를 표현할 수 있는 레버가 하나 더 늘어날 뿐이다. 아래 네 개를 일상에 들어온 순서대로 본다.

1. Persona — 고정된 역할

Persona는 협력자가 누구이고 어떻게 기본 동작할지를 고정하는 단일 시스템 프롬프트다. 운영자가 가장 자주 손대지 않는 층이지만, 그 뒤에 도는 모든 세션의 모양을 결정한다. Persona는 결국 "너는 이런 종류의 엔지니어다, 너는 이런 톤으로 적는다, 너의 기본값은 이런 모양이다"를 말한다. 다른 어디에서도 이 결정을 매 대화마다 다시 적을 필요가 없다. 한 단계 위에 살아 있기 때문이다.

여기서 자주 나오는 실수는 persona를 희망 사항 목록처럼 다루는 것이다. "조심해라, 꼼꼼하게 해라, 똑똑하게 해라"라고 적고 싶어진다. 그런데 그런 말은 AI에게 검증할 측정 가능한 목표가 없기 때문에 어떤 작업도 밀어내지 못한다. 실제로 움직이는 것은 역할과 기본값이다. "C/C++ 배경의 시니어 소프트웨어 엔지니어, 작업 언어는 한국어, 장황한 상태 업데이트보다 짧은 것을 선호." 각 구절은 AI가 추가 지시 없이 곧장 받아들일 수 있는 기본값이다. Part 2 — Persona 설계에서 다룬다.

2. Skill과 슬래시 커맨드 — 반복을 한 단어로 줄이기

다음에 운영자가 알아채는 것은, 같은 문단을 매일 다시 친다는 사실이다. "린트 돌리고, 빌드하고, 깨진 cross-ref 없는지 확인하고, 보고해라"가 매일 등장한다. 해결책은 그 문단을 더 잘 적는 것이 아니다. 해결책은 그 절차에 이름을 붙이는 것이다. 그 절차가 /verify나 /session-end 같은 이름을 한 번 가지고 나면, 운영자는 절차를 다시 받아쓰는 일을 그만두고 명사를 호출하는 일을 시작한다.

이것이 운영자에게 주는 것은 어휘다. 여섯 줄짜리 지시를 적는 대신 단어 하나를 적고, AI는 이미 합의된 절차를 그대로 불러온다. "오늘은 완료가 어떻게 보이는가"라는 비용이 거의 0에 가깝게 떨어진다. Part 4 — Skill과 슬래시 커맨드에서 다룬다.

3. Hook — 운영자가 잊어도 시스템이 기억

스킬은 여전히 운영자가 호출을 기억해야 동작한다. 훅은 그것마저 없앤다. 훅은 "AI가 완료라는 단어를 출력하기 직전마다 /verify를 먼저 돌려라"라고 말한다. 운영자는 어떤 것도 적지 않는다. 운영자가 한 번 "완료라는 건 이런 의미다"라고 말해 두었기 때문에 시스템이 그 절차를 대신 발동한다.

여기서 일어나는 전환은, 책임이 운영자의 작업 기억에서 하네스 설정으로 옮겨간다는 것이다. 운영자는 더 이상 검증을 기억할 필요가 없다. 잊는 게 더 이상 가능한 경로가 아니기 때문이다. 운영자가 기억하든 말든 훅은 발동한다. 의도 전달이 지속되는 것은 이 층 덕분이다. 피곤한 금요일 오후에도 살아남는다. Part 5 — Hook과 자동화에서 다룬다.

4. Harness — 런타임의 레일

네 번째 층은 런타임 자체다. AI가 무엇을 할 수 있고 할 수 없는지를 결정하는 레일이다. Persona가 무엇을 요청했든 훅이 무엇을 시도했든 상관없이 결정된다. 권한 정책, 샌드박싱, 파일 쓰기 가드, 파괴적 작업의 브랜치 보호 — 이런 것은 신뢰 아래에 있는 층이다. Persona는 AI에게 rm -rf에 조심해 달라고 부탁할 수 있다. 하네스는 운영자가 버튼을 누르지 않는 한 그 호출 자체를 불가능하게 만든다.

검증 루프, 릴리스 게이트, Ralph 루프는 모두 이 층에 산다. AI에게 잘 행동하라고 부탁하는 게 아니라, 잘못된 행동이 출시될 수 없도록 환경 자체를 배치하는 일이다. 운영자의 의도가 물리적으로 되는 층이다. AI의 동의 여부와 관계없이 시스템이 그것을 강제한다는 의미에서.

새 층이 이전 층을 쓸모없게 만들기 때문이 아니라, 각 층이 같은 간극의 서로 다른 실패 양식을 다루기 때문이다. 프롬프팅은 여전히 persona 안에서 일어난다. 스킬은 여전히 프롬프트로 호출된다. 훅이 스킬을 호출한다. 하네스가 훅을 발동한다. 누적이지 대체가 아니다. 운영자의 mind는 네 개 층에 동시에 분산되어 산다.

"빠짐없이 옮겨주기"는 실제로 어떤 모습인가

누적된 층은 실제 절차에 닿기 전까지는 추상적이다. 보기에 가장 명확한 절차는 /verify다. 같은 의도가 두 개의 다른 층에 동시에 표현되고, 각 표현이 어떤 간극을 덮는지를 한눈에 보여주기 때문이다.

/verify의 경우

/verify가 실제로 무엇인가? 어떤 "완료" 보고 직전에 7단계 검증 루프(lint·build·type check·test·security·diff 점검·보고 정합)를 돌리는 스킬이다. 운영자가 슬래시 커맨드로 명시적으로 호출할 수도 있고, 어시스턴트가 "완료"라는 단어를 출력하기 직전에 훅이 자동으로 발동시킬 수도 있다. 같은 절차, 두 진입로. Part 7 — Verification 루프에서 자세히 다룬다.

이 구분이 중요한 이유는, 같은 절차가 두 층에 있다는 사실이 두 가지 서로 다른 일을 한다는 점에 있다. 슬래시 커맨드는 운영자가 절차를 필요할 때 당겨오게 한다 — "이거 한 번 검증해줘." 훅은 시스템이 운영자 대신 절차를 밀어주게 한다 — "빌드가 깨진 상태로 어시스턴트가 완료를 보고하지 못하게 하라." 둘 다 필요하다. 검증의 일부는 흐름 중간에 일어나야 하고, 운영자의 기억은 시스템에서 가장 자주 실패하는 부분이기 때문이다.

훅이 없을 때 간극은 어떻게 드러나는가

훅이 없으면 간극이 그대로 드러난다. 어시스턴트는 빌드가 깨진 상태로 "완료"를 보고한다. 완료 보고와 빌드 실행은 서로 다른 두 행위이고, 운영자가 머릿속에 가지고 있던 "완료라는 건 테스트 통과까지를 의미한다"는 mind는 어시스턴트가 참조해야 하는 그 어디에도 명문화되지 않았기 때문이다. 훅이 있으면 어시스턴트의 기억 여부와 무관하게 절차가 발동된다. 운영자의 의도 — "완료 = 검증된 상태" — 가 머릿속 밖으로 빠져나와 운영자 없이도 도는 기계의 일부로 옮겨간 것이다.

다른 각도에서 보면, push 직전에 인계 노트를 자동으로 prepend하는 세션 종료 절차도 같은 모양이다. 훅이 없으면 매 세션이 운영자가 다음 세션이 필요로 하는 것을 적었기를 바라며 끝난다. 훅이 있으면 인계 노트가 존재한다. 적지 않는 것이 더 이상 가능한 결말이 아니기 때문이다. mind가 옮겨간 것은 더 많이 적었기 때문이 아니라, 행위의 구조 자체를 바꿔서 구조가 대신 기억하게 만들었기 때문이다.

Loading diagram…

mind 자체가 계속 변한다

네 층이 동시에 필요한 이유는, 운영자의 mind 자체가 고정된 것이 아니기 때문이다. 움직이는 표적이다. mind의 서로 다른 부분이 서로 다른 속도로 움직이고, 각 층은 각 부분이 실제로 흘러가는 속도를 흡수하도록 배치된다.

목적지 층 — PRD

AI가 아무리 발전하고 성능이 향상되어도 운영자의 의도를 미리 알아채고 운영자가 만족할 만한 결과를 만들어내기는 어려울 것이라고 본다. 운영자의 욕구나 만족도나 목표가 계속 변하기 때문이다. 아침에는 바다를 보고 싶었지만 저녁에는 산이 보고 싶을 수도 있다.

mind가 움직이는 표적이라면, 규율은 운영자를 예측하기가 될 수 없다. 운영자의 현재 상태를 읽는 비용을 낮추기가 되어야 한다. PRD를 단일 진실원으로 다루는 이유가 그것이다. 일회성 명세가 아니라, 목적지가 바뀔 때마다 운영자가 업데이트하는 살아 있는 선언으로 다룬다. Part 10 — PRD를 단일 진실원으로에서 다룬다.

방식 층 — persona와 skill

PRD가 목적지에 대해 하는 일을, persona와 skill은 방식에 대해 한다. 운영자가 "사실은 장황한 상태 업데이트보다 짧은 게 더 좋다"는 걸 알아챘을 때 persona를 다시 적는다. 다시 적은 내용은 이후 모든 세션이 볼 수 있다. mind가 머리 밖으로 옮겨가서, 다음 세션이 그것을 찾을 수 있는 자리에 놓인다.

두 층이 서로 다른 속도로 움직인다는 점이 핵심이다. 목적지 층(PRD)은 무엇이 바뀔 때 움직인다 — 새 기능, 새 제약, 마감. 방식 층(persona, skill)은 어떻게가 바뀔 때 움직인다 — 톤 선호, 새 절차, 어렵게 배운 워크플로 교훈. 두 층을 분리해 두면 한쪽의 업데이트가 다른 쪽의 재작성을 강제하지 않는다.

이 시리즈가 다루지 않는 것

이 글이 13편 시리즈의 진입점이기 때문에, 시리즈가 다루지 않는 것을 짚어 두는 편이 좋다. 그래야 나머지 글들을 알맞은 높이에서 읽을 수 있다.

이것은 프롬프트 엔지니어링 매뉴얼이 아니다. 출력 품질을 최대로 끌어올리기 위해 요청을 어떻게 표현해야 하는지는 이 시리즈가 다루지 않는다. 그것은 빠르게 변하는 전술이고, 6개월 전에 통했던 프롬프트가 6개월 뒤에도 통할 가능성은 낮기 때문이다. 시리즈가 다루는 것은 그 표류 속에서도 살아남는 것 — 프롬프트 수준의 기법이 발 밑에서 바뀌어도 계속 작동하는 층이다.

이것은 또한 특정 도구 추천이 아니다. 예시는 내가 매일 일하는 작업 공간이라 특정 CLI에 기대고 있지만, 네 개 층 — persona, skill, hook, harness — 은 진지한 에이전트 런타임이라면 어디에나 존재한다. 특정 도구는 옮겨가지 않더라도 어휘는 옮겨간다.

그리고 이것은 층을 따르면 AI가 운영자가 원하는 대로 동작한다는 약속도 아니다. 층은 간극을 줄일 뿐 없애지 못한다. mind는 계속 변하고, 그것을 명문화해 두는 작업도 계속된다.

시니어 개발자에게 더 의미 있는 이유

나와 같이 소프트웨어 개발자로 오랜 시간 일을 해온 개발자에게는 지금의 AI 기술이 굉장히 매력적이다. 수많은 설계와 아키텍처를 상용으로 다뤄본 입장에서 큰 그림을 그리고, 거기에 필요한 요소를 AI에게 위임하여 빠른 시간 내에 원하는 시스템을 구축할 수 있기 때문이다. 이전에는 각각의 개발자에게 설명하고 일을 분담하게 하고 결과물을 취합하고 시스템이 동작하도록 구성하는 작업을, AI Agent가 지금은 대부분 수행해 줄 수 있기 때문이다. 변화의 본질은 AI가 개발자를 대체한다는 게 아니라, 명료한 멘탈 모델을 가진 시니어 개발자가 매우 작은 팀으로 완성도 높은 시스템을 출시할 수 있게 된 것이라고 본다. 의도 전달 비용이 무너졌기 때문이다.

PRD와 TRD를 잘 구성하고 설계를 만들고, 거기에 따른 구체적인 구현 계획을 매우 작은 단위로 쪼개서 수행할 수 있게 하고, 요소마다 게이트를 세우고, 최종 단계에서 commercial release gate로 체크하게 하면 꽤 완성도 높은 시스템을 적은 인원으로 개발할 수 있게 되었다.

이 시리즈가 이어지는 곳

이 카테고리의 나머지 글들은 누적된 각 층을 하나씩 걷는다. 시작은 협력자에게 이름을 붙인 이유다. 다음 글 — Part 1 — Why Alice — 은 그 개인적 버전이다. Claude를 도구로 쓰는 방식이 어디서 무너졌는지, persona·메모리·skill·hook·검증 게이트가 어떻게 누적되어 지금 내가 Alice라고 부르는 일상의 파트너가 되었는지를 다룬다.