AI 에이전트에게 코딩을 맡기다 보면, 지시가 조금이라도 모호하면 엉뚱한 방향으로 구현되거나, 반대로 너무 세세하게 지정하면 융통성이 없어지곤 한다.

우연히 YouTube에서 Anthropic의 블로그 기사 'A Field Guide to Claude Fable: Finding Your Unknowns'를 소개하는 영상을 보게 되었고, 내 안의 사고방식이 바뀌었다. 지시가 잘 되지 않는 것은 기술의 문제가 아니라, 내가 '무엇을 모르고 있는지'를 모르고 있기 때문이 아닐까라고 생각하게 된 것이다. 원문은 이 '미지(unknowns)'를 어떻게 찾아내는지에 대해 설명하고 있다.

이 기사에서는 원문의 내용을 나름대로 풀어서 소개하면서, 읽고 생각한 점을 적어보려 한다. 원문은 'AI에게 일을 잘 시키기 위한 기술'로서 쓰였지만, 내가 흥미롭다고 느낀 점은 이것은 AI라기보다 개발자 자신의 해상도에 관한 이야기다라는 점이었다.

※ 원문은 영어 기사이며, 여기서는 요점을 나름의 언어로 요약했다. 정확한 뉘앙스는 꼭 원문을 읽어보길 바란다!

원문에서는 AI와의 작업을 '지도(map)'와 '영토(territory)'의 비유로 설명하고 있다.

지도… 내가 AI에게 전달하는 것. 프롬프트(Prompt), 스킬(Skill), 컨텍스트(Context) -
영토… 실제로 작업이 일어나는 곳. 코드베이스(Codebase), 현실의 제약

이 지도와 영토의 **차이(gap)**가 'unknowns(미지)'이며, 아무래도 AI는 미지에 부딪히면 '아마 이렇게 해주길 원하겠지'라고 추측하여 판단하기 시작한다. 맡기는 태스크(Task)가 복잡할수록 부딪히는 미지는 늘어난다.

나는 예를 들어 이것을 자동차 내비게이션을 떠올리며 생각했다. '어디 어디에 가고 싶다'라고 주소를 입력하면, 내비게이션은 그 시점에서의 최적 경로를 알려준다. 하지만 내가 평소에 운전하는 길이 더 빨리 빠져나갈 수 있거나, 정체 구간에 빠졌을 때 작은 골목으로 빠져나갈 수 있는 경로까지는 제시해주지 못할 때가 있다. 그런 경우에는 내비게이션을 무시하고 내 판단대로 주행하곤 한다. (나뿐만이 아니겠지?)

여기서 내가 기억으로서 가지고 있는 '지름길에 대한 지식'은 아직 지도에 그려지지 않은 영토의 정보이다. AI도 마찬가지로, 그대로 두면 교과서적인 최적 경로밖에 내놓지 못한다. 나만이 알고 있는 지름길을 조금씩 알려주는 것―― 그것이 미지를 언어화하는 것이 아닐까 생각한다.

본문에서 조금 신경 쓰였던 한 문장이 있었다.

Claude Fable is the first model where I find the quality of the work is bottlenecked by my ability to clarify its unknowns.

(결과물의 질이 '내가 미지를 얼마나 명확하게 할 수 있는가'에 의해 병목 현상이 발생하는, 첫 번째 모델이다)

모델의 성능이 아니라, 지시하는 쪽의 '미지를 언어화하는 능력'이 상한선을 결정한다. 언뜻 보면 자사의 Fable을 자랑하는 것처럼 보일 수도 있지만, 그만큼 똑똑하게 사용하면 무엇이든 할 수 있는 모델이 세상에 나왔다는 방증이기도 하다고 생각한다.

원문에서는 문제를 4가지 '미지'로 분류하고 있다.

원문에 따르면, 에이전틱 코딩(Agentic coding)을 잘하는 사람은 이 미지가 '적은' 데다, 미지가 존재한다는 것 자체를 전제로 움직인다고 한다.

이 4가지 패턴에 나 자신을 각각 대입해 보면,

• 기지의 기지 (Known Knowns): 요구사항을 대략적으로 전달할 수 있다 (이슈가 있고, 그것을 전달하는 등). 하지만 세부 사항이 누락된다. 구현을 시작하고 나서야 "아, 이 부분은 지정하지 않았네"라고 되는 경우가 많다.
• 기지의 미지 (Known Unknowns): 판단하기 어려운 점은 **설계 이유 (Design Reason)**와 테스트·예외 처리 (Test/Exception Handling). 코드가 동작하는 것을 우선시하여, "왜 이 구성인가"에 대한 언어화를 건너뛰기 쉽다.
• 미지의 기지 (Unknown Knowns): AI 구현이 너무 빨라서 코드 자체를 제대로 읽지 못해, 이 부분이 **블랙박스 (Black Box)**가 되어 있다. 원래라면 보면 "이게 아니야"라고 알아차릴 수 있어야 하는 부분을, 애초에 보지 않아서 파악하지 못하고 있다 (프로젝트 규칙을 지키지 못하고 있다는 지적을 몇 번이나 받았는지...).
• 미지의 미지 (Unknown Unknowns): 머지(Merge)된 후에 버그로 지적받고 나서야 처음 깨닫는 경우가 많다. 아직 경험이 없는 것에 관해서는 특히 이것이 많다고 느끼고 있다.

원문의 본론은 미지를 찾아내는 구체적인 패턴 모음이다. 구현 단계별로 소개되어 있다. 요점만 정리한다.

어떤 수법이든 해결하고자 하는 방향은 같다. 미지를 "비용이 커지기 전"에, 저렴하게 찾아내는 것이다. 구현 단계에서 막힌 뒤에 깨달으면 수정 비용이 많이 들지만, 브레인스토밍이나 인터뷰는 실패하더라도 빨리 찾을 수 있어 대응하기 쉽다.

수법 중에서 나에게 가장 와닿았던 것은 구현 전의 Blind Spot Pass였다. 내가 AI에게 맡겨서 사고가 나는 경우는 대개 이해하고 있다고 착각하지만 실제로는 파악하지 못한 코드의 수정이나, "지금까지 이렇게 해왔으니까"라며 타성적으로 진행할 때가 많기 때문이다. 둘 다 "기지의 미지", "미지의 기지"가 많은 상황이다. 이때 미리 "내가 깨닫지 못하고 있는, 모호해진 전제들을 찾아내 줘"라고 부탁할 수 있다는 것은, 사고가 나기 전에 지도의 해상도를 높일 수 있다는 뜻이다.

반면 퀴즈는 좋은 수법이라고 생각하면서도 개인적으로는 그다지 선호하지 않는다. 솔직히 말하면, 퀴즈의 정답을 맞히기 위해서만 암기하게 될 것 같기 때문이다. 시험 전의 벼락치기와 마찬가지로, 테스트가 끝나면 잊어버린다. 내가 원하는 것은 "그 자리에서 외우는 것"보다, **"나중에 추적할 수 있는 것"**이다.

그렇게 생각하니 원문의 implementation-notes가 다르게 보인다. 원문에서는 "다음 구현을 위한 가벼운 메모"로 소개되어 있지만, 나의 맥락에서는 그것이 미래의 나를 위한 기억으로서 기능한다.

시간이 흐르면 내가 작성한 코드도 나에게 "미지의 땅"이 된다. "왜 이렇게 구현했는지"를 그 자리에서 AI에게 기록하게 해두면, 나중에 되돌아볼 때 당시의 판단을 추적할 수 있다.

그리고 이것은 나의 회고뿐만 아니라, 다른 사람이 구현한 내용을 인계받았을 때도 적용된다. 예를 들어, 프로젝트에서 떠난 사람이 작성한 기능에 손을 대게 되었다고 가정하자. 코드 자체는 AI에게 부탁하면 어느 정도 알기 쉽게 설명해 준다. 하지만 전제가 되는 "왜 이 라이브러리를 선택했는지", "왜 이 분기문을 굳이 추가했는지"까지는 설명해 주지 않는다. 그렇게 되면 우리는 "아마 이런 의도로 이렇게 했겠지"라고 추측할 수밖에 없다. 그 추측이 틀리면, 고쳤다고 생각한 것이 또 다른 버그를 낳는다. 만약 여기서 구현 의도를 정리한 문서가 남아 있다면, AI에게 그것을 전달하고 "이 판단의 배경을 설명해 줘"라고 물을 수 있다. 인계 과정의 "아마도"를 "과연 그렇군"으로 바꿀 수 있다.

하지만 문서를 준비한다고 해도 결국 읽히지 않는 경우가 많다. 하지만, AI라면 읽게 할 수 있다. "이 구현 노트(implementation note)를 바탕으로, 당시 왜 이런 설계로 했는지 설명해 줘"라고 물으면 된다. 독자를 인간에서 AI로 바꾼다고 생각하면, 기록을 남기는 수고로움도 납득이 간다.

• AI와의 작업의 어긋남 =
  unknowns (미지). 결과물의 질은 "자신이 미지를 얼마나 명확하게 할 수 있는가"에 의해 결정된다 - 미지는 4가지로 분류할 수 있다. 까다로운 것은 스스로 알아차릴 수 없는
  미지의 기지 (known unknowns) / 미지의 미지 (unknown unknowns) - 미지를 드러내는 수법은 구현의
  전·중·후에 있다 (blind spot pass, 인터뷰, 퀴즈 등) -
  구현 노트를 "미래의 자신과, 인계받는 사람을 위한 기억"으로서 남긴다고 하면, 독자를 인간에서 AI로 바꿀 수 있다.

원문의 마무리가 좋았기에, 나름대로 요약해 두려 한다. 미지를 찾기 위한 한 수(설명, 브레인스토밍, 인터뷰, 프로토타입, 참조)는 모두 "비용이 많이 들기 전에 저렴하게 끝내는" 투자다. 다음 프로젝트는, 우선 "나의 unknowns를 함께 찾아줘"라고 부탁하는 것부터 시작해 보고 싶다.