소크라테스 봇 만들기 — Why 체인으로 AI에게 내 의도 학습시키기

지난번 Skills 글에 이어, Claude를 조금 더 적극적으로 활용해보기 위해 이것저것 시도하고 있다.

사장님 마인드라는 게 결국 '자동사냥'을 원하는 거 아닌가.

버튼 하나 누르면 알아서 사냥하고, 알아서 템 줍고.
나는 가끔 접속해서 결과만 확인하면 되는.
AI 코딩 에이전트를 쓰면서도 똑같은 마음이었다. "알아서 좀 잘 해줘."

근데 문제는, 그 '알아서'가 내 마음에 들어야 한다는 거다.

AI는 '천재 신입'이다.
시키면 뭐든 해내는데, 우리 회사가 뭐 하는 곳인지, 내가 왜 이 작업을 시키는 건지는 하나도 모른다.
게다가 퇴근하면 오늘 한 일을 싹 잊어먹는다. 일을 하다 말고 갑자기 퇴사해버리기도 한다.
그러면 새로 들어온 신입한테 처음부터 다시 설명해야 한다. 매일 아침 새 사람이 출근하는 셈.

그래서 핵심은 이거다. 내가 알고 있는 맥락과 AI가 인지할 수 있는 범위 사이의 간극을 좁혀야 한다.
그 간극이 넓으면, AI는 엉뚱한 방향으로 열심히 달려간다.

그 간극을 좁히기 위해 하나의 Skill을 만들어봤다.

소크라테스 봇

이름은 "Why 체인". 원리는 단순하다.

AI가 내 요청을 받으면 바로 실행하지 않고, 끝없이 "왜?"를 물어서 내가 진짜 원하는 게 뭔지 스스로 알게 만드는 것이다.
소크라테스가 제자들한테 했던 것처럼.
답을 주는 게 아니라, 질문을 통해 답에 도달하게 하는 것.

왜 이게 필요한가

"블로그 디자인을 바꾸고 싶어"라고 말했다고 치자.

보통의 AI는 듣자마자 디자인 시안을 뽑기 시작한다.
근데 Why 체인은 이렇게 간다:

"지금 디자인에서 어떤 부분이 마음에 안 드세요?"
— "전체적으로 밋밋해서."

"어떤 느낌으로 바뀌면 좋겠다는 이미지가 있으세요?"
— "내 글의 분위기를 더 잘 담았으면 좋겠어."

"지금 디자인이 글의 어떤 면을 못 살리고 있다고 느끼세요?"
— "글은 깊이가 있는데 디자인이 가벼워 보여서, 읽기 전에 이탈하는 것 같아."

"그 독자들이 머물러서 궁극적으로 어떤 경험을 했으면 좋겠어요?"
— "내 생각에 공감하고, 자기 생각도 정리하는 시간을 가졌으면."

"디자인을 바꾸고 싶다"에서 출발했는데, 질문을 거치니 진짜 원하는 건 "독자가 글의 깊이를 신뢰하고 머무를 수 있는 공간"이었다.
이걸 모른 채 디자인만 예쁘게 바꿨으면 또 불만족이었을 거다.

실제로 어떻게 만들었나

Claude Code의 Skill 기능을 썼다.
AI한테 특정 상황에서 따를 행동 규칙을 적어주는 매뉴얼 같은 것.
세 단계로 작동한다.

Phase 1 — Why 체인.
AI가 바로 실행 대신 질문을 시작한다.
한 턴에 질문 하나씩, "왜요?"를 기계적으로 반복하는 게 아니라 상황에 맞게 변주한다.
목표가 불분명하면 "성공하면 어떤 모습인가요?"를,
선택의 이유가 궁금하면 "다른 방법 대신 이걸 택한 이유가 있나요?"를 묻는 식.
핵심 동기에 도달할 때까지 최소 3회 이상.
Phase 2 — 싱크 확인.
AI가 "당신의 표면 요청은 이거였고, 파고들어 보니 핵심 동기는 이거더라"고 요약한다.
내가 "맞아"라고 승인해야만 다음 페이즈를 진행한다.
Phase 3 — 계획 수립.
그제야 실행 계획을 세우는데, 표면 요청이 아니라 Phase 1에서 발견한 핵심 동기를 중심으로 세운다.

매번 Why를 돌리기엔 귀찮아

그래서 경량 버전도 만들었다.

모든 작업 요청에 대해 AI가 바로 실행 대신 한 문장으로 의도를 확인한다.
"이런 방향이 맞을까요?" 한 줄.
맞으면 바로 실행, 아니면 한번 더 확인.

근데 두 번 연속으로 내 의도를 잘못 파악하면?
자동으로 풀버전 Why 체인이 발동된다.

명확한 요청에는 확인 없이 바로 실행, 모호한 요청에서만 확인이 붙으니까 생각보다 방해가 안 된다.
자동사냥 세팅을 효율적으로 잡아놓은 느낌으로.

적용해보니

실제로 학원 시스템 개발에 써봤다.
"중등 시험 결과페이지에 AI 피드백을 넣고 싶어"라고 요청했는데, AI가 바로 구현에 들어가는 대신 한 문장으로 확인을 했다:

"현재 논술 가이드만 나오는 것을 개선하여, AI를 통해 전체 시험에 대한 종합 피드백을 생성하는 기능을 만들고 싶다 — 이 방향이 맞을까요?"

이 한 턴의 확인만으로도 내가 "논술 가이드를 고치고 싶은 건지", 혹은 "전체 피드백 시스템을 새로 만들고 싶은 건지"가 명확해진다.

기록이 곧 설계도다

그리고 이 Why 체인의 과정 — 질문과 답변, 수정과 확인의 기록 — 이게 사라지면 안 된다.

AI는 퇴근하면 다 잊으니까, 이 기록이 프로젝트에 남아 있어야 한다.
좋았든 안 좋았든, 시행착오를 겪었든, 나랑 언쟁만 계속했든.
다 남겨두면 새로운 AI가 투입되더라도 "이 프로젝트에서 이 사람이 진짜 원하는 건 이거구나"를 바로 파악할 수 있다.

조선왕조실록이 왜 귀한가.
잘한 일만 적어서가 아니라, 못한 일까지 다 적었기 때문이다.
AI와의 대화 기록도 마찬가지다.
왜 이런 결정을 내렸는지, 어떤 대안을 왜 포기했는지.
이게 다 남아 있으면 AI가 교체되든 프로젝트가 리셋되든 재건축이 가능하다.

설계도가 많은 사람이 이긴다.

결국 AI를 잘 쓴다는 건, 코딩을 잘하거나 프롬프트를 잘 쓰는 게 아니라 내가 뭘 원하는지 정확히 아는 것에서 시작하는 것 같다.

그리고 그걸 모를 때는, 알 때까지 파고드는 과정을 만들어두는 것.