클로드 페이블 탐구: 미지의 영역을 찾아서

클로드 코드와 작업할 때, 저는 종종 지도와 영토의 차이를 떠올립니다. 지도는 작업을 나타내는 것으로, 제가 클로드에게 제공하는 프롬프트와 기술, 그리고 맥락을 의미합니다. 반면 영토는 실제 작업이 이루어져야 하는 코드베이스와 현실 세계, 그리고 그 실제 제약 조건을 의미합니다. 지도와 영토의 차이는 제가 '미지의 영역'이라고 부르는 것입니다. 클로드가 미지의 영역에 부딪히면, 제가 원하는 것을 최선으로 추측하여 결정을 내려야 합니다. 작업이 많아질수록 클로드가 마주할 미지의 영역도 많아집니다. 클로드 페이블은 제가 미지의 영역을 명확히 할 수 있는 능력에 의해 작업의 질이 제한되는 첫 번째 모델입니다. 중요한 것은, 미리 계획하는 것만으로는 항상 충분하지 않다는 것입니다. 구현 과정에서 깊이 있는 미지의 영역을 발견할 수도 있고, 문제를 전혀 다른 방식으로 해결해야 한다는 사실을 미지의 영역이 가리킬 수도 있습니다. 페이블과 작업하는 것은 구현 전, 중, 후에 미지의 영역을 발견하는 반복적인 과정임을 알게 되었습니다.

미지의 영역 파악하기

클로드에게 문제를 제시할 때, 저는 이를 네 가지 방식으로 나누는 경향이 있습니다:

알려진 지식(Known Knowns): 기본적으로 프롬프트에 포함된 내용입니다. 에이전트에게 내가 원하는 것을 무엇이라고 말하는가?
알려진 미지(Known Unknowns): 아직 해결하지 못했지만, 해결하지 못했다는 것을 알고 있는 것.
미지의 지식(Unknown Knowns): 너무 명백해서 기록하지 않지만, 보면 알 수 있는 것.
미지의 미지(Unknown Unknowns): 전혀 고려하지 않은 것. 내가 알지 못하는 지식은 무엇인가? 어떤 것이 얼마나 훌륭할 수 있는지 알고 있는가?

최고의 에이전트 코더는 상대적으로 미지의 영역이 적습니다. 보리스나 자레드 같은 사람들이 프롬프트를 작성하는 것을 보면, 그들이 원하는 것을 상세히 알고 있다는 것이 분명합니다. 그들은 코드베이스와 모델의 행동에 깊이 동기화되어 있습니다. 그러나 그들도 미지의 영역을 가정합니다. 많은 면에서, 미지의 영역을 줄이고 계획하는 것은 에이전트 코딩의 기술입니다. 다행히도, 클로드와 함께 작업함으로써 이 기술을 향상시킬 수 있습니다.

클로드가 도와줄 수 있도록 하기

클로드에게 지시하는 것은 섬세한 균형을 필요로 합니다. 너무 구체적이면, 클로드는 전환이 더 적절할 때도 지시를 따릅니다. 너무 모호하면, 클로드는 종종 산업의 모범 사례를 기반으로 선택과 가정을 하게 되는데, 이는 작업에 맞지 않을 수 있습니다. 미지의 영역을 고려하지 않으면, 두 가지 방식 모두 실패하게 됩니다. 길이 장애물로 가득 찰 때와 길이 명확할 때를 알지 못하지만, 여전히 클로드가 방향을 바꾸기를 원합니다. 클로드는 미지의 영역을 더 빨리 발견하는 데 도움을 줄 수 있습니다. 클로드는 코드베이스와 인터넷을 매우 빠르게 검색할 수 있으며, 평균적인 주제에 대해 훨씬 더 많은 것을 알고 있습니다. 또한 실패에서 더 빨리 반복할 수 있습니다. 이 과정에서 가장 중요한 부분은 클로드에게 시작점에 대한 맥락을 제공하는 것입니다. 예를 들어, 생각의 진행 상황을 알려주고, 문제와 코드베이스에 대한 경험을 공개하며, 클로드가 생각의 파트너로서 함께 작업할 수 있도록 하는 것입니다.

미지의 영역을 발견하는 패턴

구현 전

블라인드 스팟 패스(Blind Spot Pass): 작업을 시작할 때 가장 유용한 것 중 하나는 자신의 블라인드 스팟을 이해하는 것입니다. 예를 들어, 코드베이스의 새로운 부분에 기능을 작성하거나, 디자인을 반복하는 것과 같은 익숙하지 않은 작업을 클로드가 도와줄 때, 많은 미지의 미지가 있을 가능성이 큽니다. 어떤 질문을 해야 할지, 무엇이 좋은 것인지, 어떤 역사적인 작업이 이루어졌는지, 어떤 함정을 피해야 하는지 모를 수 있습니다. 이러한 상황에서 클로드에게 미지의 미지를 찾아 설명해달라고 요청할 수 있습니다.

브레인스토밍과 프로토타입

브레인스토밍과 프로토타입: 많은 미지의 지식이 있는 영역에서 작업할 때, 클로드에게 브레인스토밍과 프로토타입을 요청하는 것을 좋아합니다. 프로토타이핑 초기에 미지의 지식을 식별하고 언어화하는 것은 매우 가치가 있습니다. 구현 중에 이를 발견하는 것은 상대적으로 비용이 많이 들 수 있습니다. 기능이나 사양의 작은 변화가 코드에서 크게 다른 구현을 초래할 수 있으며, 에이전트가 이전 변경 사항을 되돌리는 것이 더 어려울 수 있습니다.

인터뷰

인터뷰: 충분한 브레인스토밍을 한 후에도 여전히 미지가 남아 있을 수 있습니다. 이 경우 클로드에게 미지나 모호함에 대해 인터뷰를 요청합니다. 클로드에게 인터뷰를 요청할 때, 문제에 대한 맥락을 제공하여 질문을 안내하도록 합니다.

참고 자료

참고 자료: 때로는 원하는 것을 자세히 설명할 수 없습니다. 예를 들어, 언어가 부족하거나 너무 복잡해서 시간이 걸릴 수 있습니다. 이 경우 가장 좋은 접근 방식은 참고 자료입니다. 다이어그램, 문서 또는 그림을 포함할 수 있지만, 가장 좋은 참고 자료는 소스 코드입니다.

구현 계획

구현 계획: 구현할 준비가 되었다고 생각되면, 클로드에게 검토할 구현 계획을 작성해달라고 요청하는 경향이 있습니다. 계획은 데이터 모델, 타입 인터페이스, UX 흐름과 같이 변경 가능성이 높은 부분에 중점을 둡니다.

구현 중

구현 노트: 계획에 만족하면 새 세션을 만들고 모든 아티팩트를 프롬프트에 전달합니다. 이는 클로드에게 계획에서 수집한 모든 정보를 포함한 새로운 컨텍스트 창을 제공합니다.

구현 후

피치와 설명자: 무언가를 출시할 때 가장 중요한 부분 중 하나는 승인과 동의를 얻는 것입니다. 최종 문서에 피치와 설명자 아티팩트를 구축하면 이해를 가속화하고, 전문가들이 예상했던 미지의 영역과 일반적인 실패 지점을 고려했음을 보여줌으로써 승인을 가속화할 수 있습니다.
퀴즈: 긴 작업 세션 후, 클로드는 제가 예상했던 것보다 훨씬 더 많은 것을 달성했을 수 있습니다. 코드 차이를 읽는 것만으로는 무슨 일이 일어났는지 가볍게 이해할 수 있습니다. 클로드에게 변경 사항에 대해 퀴즈를 요청하여 제가 이해했는지 확인합니다. 퀴즈를 완벽히 통과한 후에만 병합합니다.

페이블의 출시

페이블의 출시 영상은 클로드 코드를 사용하여 처음부터 끝까지 편집되었습니다. 이는 저에게 새로운 분야였으며, 저는 결코 전문가가 아닙니다. 그래서 제가 알고 있는 것부터 시작했습니다. 클로드가 코드를 사용하여 비디오를 편집하고 전사할 수 있다는 것을 알고 있었지만, 그것이 충분히 정확한지는 확신하지 못했습니다. 클로드에게 Whisper와 같은 전사가 어떻게 작동하는지 설명해달라고 요청한 후, ffmpeg를 사용하여 '음'이나 큰 일시 중지를 정확하게 잘라낼 수 있는지 물었습니다. 저는 클로드에게 제가 말하는 단어와 타이밍이 맞는 UI를 만들고 싶었지만, 가능할지 확신하지 못했기 때문에 Remotion과 전사를 사용하여 프로토타입 비디오를 만들어달라고 요청했습니다. 마지막으로, 비디오 자체가 약간 흐릿해 보였는데, 이는 색 보정의 결과라는 것을 알았지만, 색 보정이 무엇인지 잘 몰랐습니다. 그래서 클로드에게 색 보정에 대해 가르쳐달라고 요청하여 미지를 발견했습니다.

지도와 영토의 일치

모델이 더 좋아질수록 올바른 접근 방식으로 더 많은 것을 달성할 수 있습니다. 장기적인 작업이 잘못되었을 때, 미지를 정의하는 데 더 많은 시간을 할애하거나 클로드와 함께 이를 통해 적응할 수 있는 구현 계획을 만들어야 할 가능성이 큽니다. 모든 설명자, 브레인스토밍, 인터뷰, 프로토타입, 참고 자료는 수정하기에 비용이 많이 들기 전에 알지 못했던 것을 알아내는 저렴한 방법입니다. 다음 프로젝트를 시작할 때 클로드에게 미지를 찾는 데 도움을 요청하세요.

파이랩 정리