클로드 패블과 협업하며 미지 영역 발견하기
“지도는 영토가 아니다”라는 오랜 격언은 인공지능 코딩 에이전트인 클로드 패블 5(Claude Fable 5)와 협업할 때 특히 중요하게 다가온다. 우리가 에이전트에 제공하는 프롬프트, 스킬, 컨텍스트는 ‘지도’에 해당한다. 그러나 실제 작업이 이뤄지는 코드베이스, 현실 세계, 그 안의 제약 조건은 ‘영토’이다. 지도와 영토의 차이, 곧 우리가 미처 파악하지 못한 것들을 미지 영역(unknowns)이라 부른다.
지도와 영토, 그리고 미지 영역
작업 지시, 즉 ‘지도’는 우리가 에이전트에게 원하는 바를 담고 있다. 반면 ‘영토’는 코드가 실행되고 실제 결과가 만들어지는 환경이다. 이 둘 사이의 간극에서 미지 영역이 발생한다. 클로드는 미지 영역을 마주하면 우리가 무엇을 원하는지 가장 잘 추측해 결정을 내린다. 작업량이 많아질수록 클로드가 맞닥뜨릴 미지 영역 또한 늘어난다.
이러한 미지 영역을 명확히 하는 능력은 패블 같은 에이전트와 협업할 때 작업 품질을 결정하는 핵심 병목 지점이 된다. 단순히 미리 계획을 세우는 것만으로는 충분하지 않다. 미지 영역은 구현 과정 깊숙한 곳에서 발견되기도 하고, 때로는 문제 해결 방식을 완전히 바꿔야 할 필요를 제시하기도 한다.
패블과의 협업은 구현 전, 도중, 후에 걸쳐 미지 영역을 발견하는 반복적인 과정이다.
미지 영역의 네 가지 종류
우리가 클로드에게 문제를 제시할 때, 미지 영역은 크게 네 가지로 나뉜다. 에이전트 코딩 전문가들은 이러한 미지 영역이 상대적으로 적다. 이는 그들이 코드베이스와 모델 동작을 깊이 이해하며, 무엇을 원하는지 상세히 알기 때문이다. 그러나 그들 역시 미지 영역의 존재를 가정하고 작업한다. 미지 영역을 줄이고 계획하는 일은 에이전트 코딩의 핵심 능력이며, 클로드와 협업하며 길러진다.
아래 표는 미지 영역의 종류와 그 특징을 보여준다.
| 미지 영역의 종류 | 설명 |
|---|---|
| 인지된 인지 (Known Knowns) | 프롬프트에 명시된 내용, 에이전트에게 전달하는 정보이다. |
| 인지된 비인지 (Known Unknowns) | 아직 파악하지 못했지만, 그 사실을 인지하고 있는 영역이다. |
| 비인지된 인지 (Unknown Knowns) | 너무 당연해서 따로 기록하지 않지만, 결과물을 보면 바로 인식하는 영역이다. |
| 비인지된 비인지 (Unknown Unknowns) | 전혀 고려하지 못했던, 알지 못했던 지식이나 정보이다. |
클로드가 미지 영역을 발견하도록 돕기
클로드에게 지시를 내리는 것은 섬세한 균형이 필요하다. 지나치게 구체적이면 클로드는 지시를 곧이곧대로 따르느라 더 나은 방향 전환을 놓친다. 반대로 너무 모호하면 산업 모범 사례에 기댄 결정을 내리는데, 이는 실제 작업과 어긋나기 쉽다. 미지 영역을 고려하지 않으면, 어떤 길이 막힐지 어떤 길이 뚫릴지 모르는 상태에서 클로드가 길을 찾도록 강요하게 된다.
클로드는 코드베이스와 인터넷을 빠르게 탐색하며, 일반적인 주제에 대해 우리보다 훨씬 많은 지식을 갖춘다. 그래서 미지 영역을 더 빠르게 발견하도록 돕는다. 실패로부터 반복 학습하는 속도도 우리보다 빠르다. 이 과정에서 가장 중요한 부분은 클로드에게 작업의 시작점에 대한 맥락을 제공하는 것이다. 예를 들어, 현재 자신의 사고 과정이나 문제 및 코드베이스에 대한 경험을 알려주고, 마치 생각 파트너처럼 함께 작업하도록 유도한다.
아래에서 구현 전, 구현 중, 구현 후 단계에서 미지 영역을 발굴하는 데 사용하는 패턴들을 제시한다.
구현 전 미지 영역 발굴 전략
작업을 시작할 때, 자신의 블라인드 스팟(blindspots)을 이해하는 것은 매우 유용하다. 코드베이스의 새로운 부분에서 기능을 개발하거나 낯선 작업을 할 때는 비인지된 비인지가 많다. 어떤 질문을 해야 할지, 무엇이 좋은 결과인지, 어떤 선행 작업이 있었는지, 어떤 함정을 피해야 하는지조차 모르는 상태다.
블라인드 스팟 점검
클로드에게 비인지된 비인지를 찾아 설명해 달라고 요청한다. “블라인드 스팟 점검(blindspot pass)”이나 “비인지된 비인지(unknown unknowns)” 같은 단어를 직접 사용한다. 현재 자신의 상황과 지식을 클로드에게 알려주는 것이 중요하다.
예시 프롬프트:
- “새로운 인증 공급자를 추가하는 작업을 하는데, 이 코드베이스의 인증 모듈에 대해 아무것도 모른다. 관련 비인지된 비인지 영역을 파악하고 프롬프트를 더 잘 작성하도록 돕기 위해 블라인드 스팟 점검을 해달라.”
- “색 보정이 무엇인지 모르지만 이 비디오를 보정해야 한다. 색 보정에 대한 나의 비인지된 비인지 영역을 이해하도록 가르쳐 달라. 그래야 프롬프트를 더 잘 작성한다.”
브레인스토밍과 프로토타입
비인지된 인지 영역이 많은 경우, 즉 결과물을 봐야만 기준을 정의하는 경우, 클로드에게 브레인스토밍과 프로토타입 작업을 요청한다. 구현 중에 비인지된 인지를 발견하면 비용이 훨씬 크게 들기에, 프로토타입 단계에서 미리 식별하고 구체화하는 편이 낫다. 기능이나 사양의 작은 변화가 코드 구현에 큰 영향을 미치고, 에이전트가 이전 변경 사항을 되돌리기도 더 어렵다.
시각 디자인은 직접 보아야만 무엇을 원하는지 아는 영역이다. 이런 경우, 여러 가지 디자인 접근 방식을 요청한다. 모든 코딩 세션을 탐색 또는 브레인스토밍 단계로 시작하면 프로젝트의 범위를 정의하는 데 도움이 된다. 클로드는 종종 우리가 놓쳤을 고가치 접근 방식을 찾아내고, 너무 좁거나 넓은 범위를 설정하는 것을 막아준다.
예시 프롬프트:
- “이 데이터에 대한 대시보드를 원하지만, 시각적 감각이 없고 무엇이 가능한지 모른다. 내가 반응하도록 4가지 전혀 다른 디자인 방향으로 HTML 페이지를 만들어 달라.”
- “어떤 것도 연결하기 전에, 새로운 에디터 툴바를 가짜 데이터로 모의한 단일 HTML 파일을 만들어 달라. 실제 앱을 건드리기 전에 레이아웃에 반응하고 싶다.”
- “내 대략적인 문제는 사용자 이탈이다. 코드베이스를 검색하고, 가장 저렴한 방법부터 가장 야심 찬 방법까지 개입할 10가지 지점을 브레인스토밍해 달라. 내가 마음에 드는 것을 알려주겠다.”
인터뷰
충분한 브레인스토밍 후에도 여전히 미지 영역이 남는다. 이때는 클로드에게 남아있는 미지 영역이나 모호한 부분에 대해 인터뷰를 요청한다. 클로드에게 인터뷰를 요청할 때는 질문을 유도하도록 문제에 대한 맥락을 제공한다.
예시 프롬프트:
- “모호한 점에 대해 한 번에 한 질문씩 인터뷰해 달라. 나의 답변이 아키텍처를 바꿀 질문에 우선순위를 둬라.”
참조 자료 활용
때로는 원하는 것을 상세하게 설명하기 어렵다. 언어가 부족하거나 너무 복잡해서 시간이 오래 걸리기도 한다. 이때 가장 좋은 방법은 참조 자료를 제공하는 것이다. 다이어그램, 문서, 그림 등을 포함할 수 있지만, 최고의 참조는 소스 코드이다. 특정 방식으로 구현된 라이브러리나 마음에 드는 디자인 컴포넌트가 있다면, 패블에게 해당 폴더를 알려주고 찾고 있는 것을 지시하면 된다. 다른 언어로 되어 있어도 상관없다.
클로드 디자인(Claude Design)도 이러한 방식으로 작동한다. 파일을 직접 넘겨주지 않아도(물론 그렇게 할 수도 있다), 마음에 드는 웹사이트의 모듈을 가리키면 스크린샷만이 아니라 내부 코드를 읽어 마크업, 구조, 컴포넌트가 실제로 어떻게 구축되었는지 훨씬 풍부한 세부 정보를 얻는다.
예시 프롬프트:
- “vendor/rate-limiter에 있는 이 Rust 크레이트는 내가 원하는 정확한 백오프 동작을 구현한다. 이를 읽고 우리의 TypeScript API 클라이언트에 동일한 의미론을 재구현해 달라.”
구현 계획 검토
구현 준비가 되었다고 판단되면, 클로드에게 검토용 구현 계획을 작성하도록 요청한다. 이 계획은 변경될 가능성이 가장 높은 부분, 예를 들어 데이터 모델, 타입 인터페이스 또는 UX 흐름에 초점을 맞춘다. 클로드가 내가 실제로 수정해야 할 사항을 제시하도록 돕는다.
예시 프롬프트:
- “HTML 형식으로 구현 계획을 작성하되, 내가 가장 많이 조정할 결정 사항들(데이터 모델 변경, 새로운 타입 인터페이스, 사용자 대면 요소)을 먼저 제시해 달라. 기계적인 리팩토링은 맨 아래에 넣어라. 그 부분은 믿겠다.”
구현 중 미지 영역 관리
계획에 만족하면, 새로운 세션을 시작하고 모든 산출물을 프롬프트에 전달한다. 예를 들어, 사양 파일과 프로토타입을 전달하고 에이전트에게 구현을 요청한다.
그러나 아무리 많은 계획을 세워도 항상 숨어있는 비인지된 비인지가 존재한다. 에이전트는 작업 중에 코드에서 발견한 엣지 케이스로 인해 다른 접근 방식을 취하기도 한다. 이때 클로드 코드에게 임시 ‘implementation-notes.md’ (또는 .html) 파일을 유지하도록 요청한다. 여기에 내린 결정들을 기록해 다음 시도에서 학습한다.
예시 프롬프트:
- “implementation-notes.md 파일을 유지해 달라. 계획에서 벗어나게 하는 엣지 케이스를 발견하면 보수적인 선택을 하고, 이를 ‘Deviations’ 아래에 기록한 후 계속 진행해 달라.”
구현 후 미지 영역 해소
작업물을 출시하는 데 가장 중요한 부분 중 하나는 동의와 승인을 얻는 것이다. 최종 문서에 제안서와 설명 자료를 구축하면 다음과 같은 이점이 있다.
- 리뷰어들이 우리와 동일한 미지 영역에서 출발할 때 이해를 앞당긴다.
- 전문가들이 예상했을 미지 영역과 일반적인 실패 지점들을 우리가 고려했음을 확인할 때 승인을 앞당긴다.
예시 프롬프트:
- “프로토타입, 사양, 구현 노트를 하나의 문서로 묶어 슬랙에 게시하여 동의를 얻도록 해 달라. 데모 GIF를 맨 앞에 배치해 달라.”
퀴즈
긴 작업 세션 후, 클로드가 우리가 인식한 것보다 훨씬 많은 것을 달성하기도 한다. 코드 변경 사항(diffs)을 읽는 것만으로는 무슨 일이 일어났는지 충분히 이해하기 어렵다. 많은 동작이 기존 코드 경로에 의존하기 때문이다. 클로드에게 변경 사항에 대한 많은 맥락을 제공한 후 퀴즈를 요청하면 무슨 일이 일어났는지 이해하는 데 도움이 된다. 퀴즈를 완벽하게 통과한 후에만 병합한다.
예시 프롬프트:
- “이 변경에서 일어난 모든 것을 이해하고 싶다. 맥락, 통찰, 수행된 내용 등이 담긴 변경 사항에 대한 HTML 보고서를 읽고 이해하도록 만들어 달라. 그리고 맨 아래에 반드시 통과해야 하는 변경 사항에 대한 퀴즈를 넣어 달라.”
패블 출시 사례로 본 미지 영역 관리
패블(Fable) 출시 영상은 전적으로 클로드 코드로 편집되었다. 영상 편집은 필자에게 새로운 영역이었고 전문가는 아니었다.
먼저 알고 있던 것부터 시작했다. 클로드가 코드를 사용하여 비디오를 편집하고 전사할 수 있다는 사실은 알았지만, 정확성이 충분할지는 확신하지 못했다. 그래서 클로드에게 위스퍼(Whisper) 같은 전사 기술이 어떻게 작동하는지, FFmpeg를 사용하여 ‘음’이나 긴 침묵 같은 부분을 정확히 잘라내는지 설명해 달라고 요청했다.
말하는 단어에 맞춰 UI가 시간적으로 동기화되는 영상을 만들고 싶었지만, 클로드가 이를 해낼지 확신이 없었다. 그래서 클로드에게 리모션(Remotion)과 전사를 사용하여 프로토타입 비디오를 만들어 보고 작동하는지 확인해 달라고 요청했다.
마지막으로 영상이 다소 흐리게 보여 색 보정(color grading)의 결과임을 알았지만, 색 보정이 무엇인지는 제대로 알지 못했다. 첫 시도로 클로드에게 여러 가지 변형을 만들어 선택하게 하려 했지만, 무엇이 ‘좋은’ 색 보정인지조차 알지 못했다. 그래서 대신 클로드에게 색 보정에 대해 가르쳐 달라고 요청하여 나의 미지 영역을 발견했다.
지도와 영토의 일치
모델의 성능이 향상될수록 올바른 접근 방식으로 더 많은 일을 해낸다. 장기적인 작업이 잘못된 결과로 돌아온다면, 미지 영역을 정의하는 데 더 많은 시간을 할애하거나 클로드가 미지 영역을 헤쳐나가도록 구현 계획을 세워야 할 가능성이 높다.
모든 설명, 브레인스토밍, 인터뷰, 프로토타입, 참조 자료는 문제가 커지기 전에 우리가 몰랐던 것을 알아내는 저렴한 방법이다. 다음 프로젝트를 시작할 때 클로드에게 미지 영역을 찾는 것을 도와달라고 요청해 보자.
정보이론·엔트로피의 시선으로 보면
시스템 개발 과정에서 마주하는 미지 영역은 정보이론의 엔트로피와 구조적으로 닮았다. 엔트로피는 시스템의 불확실성이나 무질서도를 측정한다. 미지 영역을 파악하고 해소하는 과정은 곧 시스템의 불확실성을 줄이고 정보를 획득하는 행위다. 이는 정보 엔트로피를 낮춰 시스템을 예측 가능하고 안정적인 상태로 이끄는 과정과 정확히 맞닿는다.