00:00:00(경쾌한 음악)
00:00:02안녕하세요 여러분, 다들 잘 지내시죠?
00:00:23만나서 반갑습니다, 저는 덱스(Dex)입니다.
00:00:25방금 멋진 소개에서 언급된 것처럼,
00:00:27저는 한동안 에이전트 개발에 매진해 왔습니다.
00:00:29저희가 6월 AI 엔지니어 컨퍼런스에서 발표한 '12가지 요소 에이전트'는
00:00:32역대 최고의 강연 중 하나로 꼽혔습니다.
00:00:34상위 8위 정도였던 것 같은데,
00:00:356월 행사에서 가장 반응이 좋았던 강연 중 하나였죠.
00:00:38그때 컨텍스트 엔지니어링에 대해 슬쩍 언급했을지도 모르겠네요.
00:00:41오늘 제가 여기 온 이유와 드릴 말씀은 무엇일까요?
00:00:44지난 6월 AI 엔지니어 컨퍼런스에서 제가 가장 좋아했던
00:00:46발표 내용 중 하나에 대해 이야기하고 싶습니다.
00:00:47어제 이고르(Igor)로부터 최신 업데이트를 받으셨겠지만,
00:00:49제 슬라이드 수정이 허용되지 않아서,
00:00:50이고르가 6월에 했던 이야기를 중심으로 진행하겠습니다.
00:00:54기본적으로 모든 규모의 기업에 종사하는
00:00:56개발자 10만 명을 대상으로 설문조사를 했는데요.
00:00:58소프트웨어 엔지니어링에 AI를 사용할 때
00:01:00대부분의 경우,
00:01:01재작업이나 코드 베이스의 잦은 변경이 많이 발생한다는 사실을 발견했습니다.
00:01:04또한 복잡한 작업이나 기존에 구축된(brownfield)
00:01:07코드 베이스에서는 제대로 작동하지 않는다는 점도요.
00:01:08차트를 보시면 아시겠지만, 기본적으로
00:01:10배포량 자체는 훨씬 많아졌습니다.
00:01:11하지만 그중 상당 부분은 지난주에 배포한
00:01:14엉성한 코드를 다시 수정하는 작업일 뿐이죠.
00:01:15반면에, 완전히 새로 시작하는(greenfield)
00:01:18작은 Vercel 대시보드 같은 프로젝트라면
00:01:21AI가 아주 훌륭하게 작동할 겁니다.
00:01:25하지만 10년 된 자바(Java) 코드 베이스라면
00:01:28사정이 좀 다르겠죠.
00:01:29이건 저의 개인적인 경험과도 일치했습니다.
00:01:30수많은 창업자와 훌륭한 엔지니어들과 대화해본 결과,
00:01:32엉성한 코드가 너무 많고 기술 부채만 양산한다며,
00:01:35우리 코드 베이스에는 맞지 않는다고들 합니다.
00:01:37언젠가 모델이 더 발전하면 가능할지도 모르죠.
00:01:40하지만 그것이 바로 '컨텍스트 엔지니어링'이 필요한 이유입니다.
00:01:42현재의 모델에서 어떻게 최선의 결과를 끌어낼 수 있을까요?
00:01:44우리의 컨텍스트 윈도우를 어떻게 관리해야 할까요?
00:01:46저희는 지난 8월에 이 주제로 이야기를 나눴습니다.
00:01:48솔직히 고백할 것이 하나 있습니다.
00:01:49처음 클로드(Claude) 코딩 기능을 썼을 때는 별 감흥이 없었습니다.
00:01:53그냥 '음, 조금 낫네, 사용자 경험(UX)은 좋네' 정도였죠.
00:01:54하지만 그 이후로 저희 팀은 중요한 사실을 깨달았고,
00:01:56실제로 처리 효율을
00:01:592~3배가량 높일 수 있었습니다.
00:02:01생산량이 너무 많아져서 어쩔 수 없이
00:02:02협업 방식 자체를 바꿔야만 했습니다.
00:02:06소프트웨어를 만드는 방식의 모든 것을 재설계했죠.
00:02:073명의 팀원이 8주 동안 매달렸는데, 정말 힘든 과정이었습니다.
00:02:11하지만 문제를 해결한 지금, 다시는 예전으로 돌아가지 않을 겁니다.
00:02:12이것이 바로 '엉성함 없는 개발'의 핵심입니다.
00:02:14우리는 이 부분에서 어느 정도 성과를 거두었다고 생각합니다.
00:02:169월에 해커 뉴스(Hacker News)에서 큰 화제가 되기도 했죠.
00:02:18수천 명의 사람들이 깃허브(GitHub)에 방문해서
00:02:20저희의 '조사-계획-구현(Research-Plan-Implement)' 프롬프트 시스템을 가져갔습니다.
00:02:23우리가 의도치 않게 도달하게 된 목표는 이렇습니다.
00:02:25기존의 복잡한 코드 베이스에서도 잘 작동하는 AI가 필요하다는 것,
00:02:28복잡한 문제를 해결할 수 있어야 한다는 것,
00:02:31그리고 더 이상 엉성한 결과물을 만들지 않는 것입니다.
00:02:35또한 정신적 정렬(mental alignment)을 유지해야 했습니다.
00:02:38그게 무슨 의미인지는 잠시 후에 더 자세히 설명하겠습니다.
00:02:40물론 모든 것이 그렇듯, 가능한 한 많은 토큰을 활용하고 싶어 하죠.
00:02:42하지만 AI에 유의미하게 작업을 넘기는 것(offload)이
00:02:43정말 중요하고 강력한 레버리지가 됩니다.
00:02:44자, 이제 '코딩 에이전트를 위한 심화 컨텍스트 엔지니어링'을 시작하죠.
00:02:46먼저 이 개념의 틀을 잡아보겠습니다.
00:02:47코딩 에이전트를 사용하는 가장 미숙한 방법은
00:02:50무언가를 요청한 뒤 틀린 부분을 지적하고,
00:02:52계속해서 방향을 수정하며 끊임없이 되묻는 것입니다.
00:02:53그러다 컨텍스트가 꽉 차거나, 포기하거나, 좌절하게 되죠.
00:02:56우리는 좀 더 똑똑해질 필요가 있습니다.
00:02:58대부분의 사람들이 AI를 탐구하는 초기에 깨닫는 사실은,
00:03:01대화가 궤도에서 벗어났을 때
00:03:03그냥 새 컨텍스트 윈도우를 여는 것이 나을 수도 있다는 점입니다.
00:03:05이렇게 말하는 거죠. "좋아, 그 방향은 틀렸어. 다시 시작하자."
00:03:09"같은 프롬프트, 같은 작업이지만,
00:03:11이번에는 이 경로로 가보자."
00:03:13"저쪽은 안 되니까 가지 말고."
00:03:17그렇다면 언제 다시 시작해야 할지 어떻게 알까요?
00:03:21만약 이런 상황을 보게 된다면,
00:03:24(청중 웃음)
00:03:25그때가 바로 다시 시작할 때입니다, 그렇죠?
00:03:26클로드에게 제대로 못 하고 있다고 지적하면 이런 반응을 보이죠.
00:03:27우리는 이보다 더 영리해질 수 있습니다.
00:03:29제가 '의도적 압축(intentional compaction)'이라 부르는 방식입니다.
00:03:31작업이 순조롭든 아니든 상관없이,
00:03:34현재의 컨텍스트 윈도우 내용을
00:03:37마크다운 파일로 압축해 달라고 에이전트에게 요청하는 겁니다.
00:03:39당신은 이걸 검토하고 태그를 달 수 있죠.
00:03:41그러면 새 에이전트가 시작될 때,
00:03:45지루한 검색이나 코드 베이스 파악 과정을 거치지 않고
00:03:47곧바로 작업에 착수할 수 있습니다.
00:03:50압축에는 무엇이 들어갈까요?
00:03:53핵심 질문은 '컨텍스트 윈도우에서 무엇이 공간을 차지하는가?'입니다.
00:03:56파일 검색, 코드 흐름 파악,
00:03:59파일 수정 내역, 테스트 및 빌드 결과물 등이 있죠.
00:04:00만약 MCP가 JSON 데이터와 복잡한 ID들을
00:04:02컨텍스트 윈도우에 쏟아붓고 있다면 큰일입니다.
00:04:04그렇다면 무엇을 압축해야 할까요?
00:04:05구체적인 내용은 나중에 더 다루겠지만,
00:04:07이것이 아주 좋은 압축의 예시입니다.
00:04:09우리가 해결하려는 문제와 직결되는
00:04:11정확한 파일명과 줄 번호(line numbers)를 담는 것이죠.
00:04:13우리는 왜 이토록 컨텍스트에 집착할까요?
00:04:17LLM이 이 문제로 유튜브에서 비판을 받기도 했는데요.
00:04:20LLM은 비결정적이기 때문에 순수 함수는 아니지만,
00:04:22상태를 저장하지 않는 '스테이트리스(stateless)' 방식입니다.
00:04:25따라서 LLM의 성능을 높이는 유일한 방법은
00:04:26더 좋은 토큰을 입력해서
00:04:28더 좋은 토큰이 나오게 하는 것뿐입니다.
00:04:30매 루프마다 클로드나 다른 코딩 에이전트는
00:04:31다음에 사용할 도구를 선택합니다.
00:04:33수백 가지의 옳은 선택지가 있을 수도 있고,
00:04:34수백 가지의 틀린 선택지가 있을 수도 있습니다.
00:04:37하지만 다음에 무엇이 나올지에 영향을 주는 유일한 요소는
00:04:39지금까지 나눈 대화 내용뿐입니다.
00:04:42그래서 우리는 이 컨텍스트 윈도우를
00:04:45정확성, 완전성, 크기, 그리고 약간의 궤적(trajectory)에 최적화할 것입니다.
00:04:46여기서 '궤적'이 흥미로운 이유는 많은 사람이 이렇게 말하기 때문입니다.
00:04:49"에이전트에게 일을 시켰는데 틀렸어요."
00:04:51"그래서 수정해주고 야단을 쳤는데
00:04:52또 틀리길래 또 소리를 질렀죠."
00:04:53그러면 LLM은 이 대화 흐름을 보고 이렇게 생각합니다.
00:04:55"좋아, 내가 틀리고 인간이 화를 내고,
00:04:56또 내가 틀리고 인간이 화를 냈군."
00:04:58"그렇다면 이 대화에서 다음에 올 확률이 가장 높은 토큰은
00:05:00내가 또 틀려서
00:05:03인간이 다시 화를 내게 만드는 것이겠군."
00:05:05그러니 대화의 궤적에 유의하십시오.
00:05:07이걸 뒤집어서 생각해보면,
00:05:10최악의 상황은 잘못된 정보가 있는 것이고,
00:05:11그다음은 정보가 누락된 것, 그다음은 노이즈가 너무 많은 것입니다.
00:05:12수식을 좋아하신다면, 이런 식으로
00:05:13생각해볼 수 있는 간단한 수식이 있습니다.
00:05:16제프 헌틀리(Jeff Huntley)는 코딩 에이전트에 대해 많은 연구를 했습니다.
00:05:17그는 아주 적절하게 표현했죠.
00:05:18컨텍스트 윈도우를 많이 사용할수록
00:05:20결과는 더 나빠질 것이라고요.
00:05:21이것은 어떤 개념으로 이어지는데,
00:05:23저는 아주 학술적인 용어로 '멍청해지는 구역(dumb zone)'이라 부릅니다.
00:05:24자, 컨텍스트 윈도우가 있습니다.
00:05:25대략 16만 8천 개의 토큰을 쓸 수 있죠.
00:05:26일부는 출력과 압축을 위해 예약되어 있습니다.
00:05:29모델마다 다르겠지만,
00:05:31여기서는 클로드 코드를 예로 들겠습니다.
00:05:33보통 40% 지점부터는 작업의 종류에 따라
00:05:35수확 체감(diminishing returns)이 나타나기 시작합니다.
00:05:36코딩 에이전트에 너무 많은 MCP를 연결해두면,
00:05:39모든 작업이 이 '멍청해지는 구역'에서 이루어지게 되고
00:05:42결코 좋은 결과를 얻을 수 없습니다.
00:05:44사람들이 이 이야기를 많이 했으니
00:05:47저는 더 이상 언급하지 않겠습니다.
00:05:51상황에 따라 다르겠지만,
00:05:5140%는 작업 난이도에 따른 꽤 괜찮은 기준선입니다.
00:05:53다시 압축 이야기로 돌아가죠. 아니, 이제부터는
00:05:55'영리하게 멍청해지는 구역 피하기'라고 부르겠습니다.
00:05:56우리는 '서브 에이전트'를 활용할 수 있습니다.
00:05:59프런트엔드 에이전트, 백엔드 에이전트,
00:06:01QA 에이전트, 데이터 과학자 에이전트를 따로 두려 하신다면 제발 멈춰주세요.
00:06:03서브 에이전트의 목적은 직무를 의인화하는 것이 아닙니다.
00:06:05컨텍스트를 제어하기 위한 수단이죠.
00:06:07대규모 코드 베이스에서 특정 기능이
00:06:09어떻게 작동하는지 찾고 싶을 때,
00:06:10서브 에이전트를 지원하는 코딩 에이전트를 쓰거나
00:06:14직접 시스템을 구축해서 작업을 지시할 수 있습니다.
00:06:17기본적으로 "가서 이게 어떻게 돌아가는지 찾아봐"라고 시키는 거죠.
00:06:18그러면 새로운 컨텍스트 윈도우가 생성되어
00:06:21온갖 읽기, 검색, 탐색 과정을 수행하고
00:06:21전체 파일을 읽어 코드 베이스를 파악한 뒤,
00:06:22상위(parent) 에이전트에게
00:06:23아주 간결하고 명확한 메시지만을 돌려줍니다.
00:06:26"찾으시는 파일은 여기 있습니다"라고 말이죠.
00:06:28그러면 상위 에이전트는 그 파일 하나만 읽고 바로 작업을 시작할 수 있습니다.
00:06:31이 방식은 정말 강력합니다.
00:06:33이것들을 올바르게 다룬다면
00:06:37훌륭한 응답을 얻을 수 있고
00:06:39컨텍스트를 아주 효율적으로 관리할 수 있습니다.
00:06:44서브 에이전트보다 더 효과적이거나
00:06:47서브 에이전트 위에 얹을 수 있는 계층이 있는데,
00:06:49저는 이를 '빈번하고 의도적인 압축' 워크플로우라고 부릅니다.
00:06:51잠시 후에 '조사-계획-구현'에 대해 이야기하겠지만,” 핵심은
00:06:53컨텍스트 윈도우를 계속 작게 유지하는 것입니다.
00:06:55전체 워크플로우를 컨텍스트 관리 중심으로 구축하는 것이죠.
00:06:56조사, 계획, 구현의 세 단계로 나뉘며,
00:06:58우리는 내내 '스마트 구역'에 머물려고 노력할 것입니다.
00:07:00먼저 '조사' 단계는 시스템의 작동 방식을 이해하고
00:07:03적절한 파일을 찾는 과정입니다.
00:07:05이 과정에서 컨텍스트가 조금씩 쌓이기 시작하겠죠.
00:07:07하지만 여기서 핵심은 '계획' 단계로 넘어가기 전에
00:07:09지금까지의 조사 결과를 압축하는 것입니다.
00:07:13모든 검색 결과와 오류 메시지를 다 가져갈 필요는 없습니다.
00:07:14그저 "이 파일들이 관련이 있고, 이 로직을 고쳐야 한다"는 결론이면 충분하죠.
00:07:17그렇게 하면 '계획' 단계에서 에이전트는
00:07:20훨씬 더 명확한 정신적 모델을 가질 수 있습니다.
00:07:22마지막으로 '구현' 단계에 들어설 때는
00:07:23구체적인 수정 계획만 컨텍스트에 담습니다.
00:07:25이렇게 단계를 나눌 때마다 의도적으로 압축하면
00:07:29에이전트가 끝까지 똑똑함을 유지할 수 있습니다.
00:07:30또는 서브 에이전트 위에 구축된 레이어는
00:07:32제가 '빈번하고 의도적인 압축'이라 부르는 워크플로우입니다.
00:07:35잠시 후에 '조사-계획-구현'에 대해 이야기하겠지만,
00:07:37핵심은 여러분이 끊임없이
00:07:39컨텍스트 창을 작게 유지하는 것입니다.
00:07:41컨텍스트 관리를 중심으로 전체 워크플로우를 구축하는 거죠.
00:07:45그것은 조사, 계획, 구현의 세 단계로 나뉘며,
00:07:48우리는 내내 '스마트 존'에 머물려고 노력할 것입니다.
00:07:51조사 단계는 시스템이 어떻게 작동하는지 이해하고,
00:07:53적절한 파일을 찾으며,
00:07:55객관성을 유지하는 것에 관한 것입니다.
00:07:56여기 조사를 위해 사용할 수 있는 프롬프트가 있습니다.
00:07:58이것은 조사 프롬프트의 결과물입니다.
00:08:00이것들은 모두 오픈 소스입니다.
00:08:01가져가서 직접 테스트해 보실 수 있습니다.
00:08:04계획 단계에서는 정확한 단계를 개략적으로 설명합니다.
00:08:06파일명과 코드 스니펫도 포함할 것입니다.
00:08:08변경 사항마다 어떻게 테스트할 것인지에 대해
00:08:10매우 명확하게 작성할 것입니다.
00:08:11여기 좋은 계획용 프롬프트가 있습니다.
00:08:12이것은 저희가 만든 계획 중 하나입니다.
00:08:13실제 코드 스니펫이 들어 있습니다.
00:08:16그런 다음 구현 단계로 넘어갑니다.
00:08:17이런 계획서 중 하나를 읽어보셨다면,
00:08:17세상에서 가장 멍청한 모델이라도
00:08:20이걸 망치지는 않을 거라는 걸 쉽게 알 수 있습니다.
00:08:23그래서 우리는 그냥 계획대로 실행하며
00:08:24컨텍스트를 낮게 유지합니다.
00:08:26말씀드린 대로 계획 프롬프트는
00:08:27과정 중에서 가장 재미없는 부분입니다.
00:08:30저는 이것을 실제로 적용해보고 싶었습니다.
00:08:31저희와 함께 일하는, Boundary ML의 CEO인
00:08:34제 친구 Vaibhav와 팟캐스트를 진행하는데요.
00:08:37제가 말했죠. "너희의 30만 라인짜리 Rust 코드 베이스의
00:08:39프로그래밍 언어 수정을
00:08:41단 한 번의 시도로 고쳐볼게."
00:08:42에피소드 전체가 그 내용입니다.
00:08:45한 시간 반 정도 분량이죠.
00:08:46지금 다 설명하지는 않겠지만,
00:08:47우리는 수많은 조사를 수행했고
00:08:48결과가 좋지 않아 버리기도 했습니다.
00:08:49그다음 조사 없이 계획을 세워보고, 조사 후에도 세워보며
00:08:51모든 결과를 비교했습니다.
00:08:53즐거운 시간이었죠.
00:08:54그게 월요일 밤이었습니다.
00:08:55화요일 아침, 저희가 방송 중일 때
00:08:57그 회사의 CTO가 PR(풀 리퀘스트)을 확인했는데,
00:08:59제가 팟캐스트용 쇼로 한 건 줄은 몰랐습니다.
00:09:03그는 기본적으로 "네, 좋아 보이네요.
00:09:04다음 릴리스에 반영하겠습니다"라고 했습니다.
00:09:05CTO는 조금 어리둥절해했죠.
00:09:08여기 그 계획이 있습니다.
00:09:09어쨌든, 맞습니다. 확인되었습니다.
00:09:12기존(Brownfield) 코드 베이스에서도 '슬롭' 없이 잘 작동합니다.
00:09:14하지만 더 복잡한 문제도 해결할 수 있는지 보고 싶었습니다.
00:09:17Vaibhav는 여전히 약간 회의적이었거든요.
00:09:19그래서 토요일에 약 7시간 동안 앉아서
00:09:21BAML에 35,000라인의 코드를 배포했습니다.
00:09:24그중 하나는 일주일 후에 머지되었습니다.
00:09:26일부는 자동 생성된 코드이긴 합니다.
00:09:28동작을 업데이트하면,
00:09:29모든 골든 파일이 업데이트되는 식이죠.
00:09:31하지만 그날 우리는 정말 많은 코드를 보냈습니다.
00:09:33그는 1~2주일 치 업무를 7시간 만에 해냈다고 평가합니다.
00:09:36좋습니다, 우리는 복잡한 문제를 해결할 수 있습니다.
00:09:40물론 한계는 있습니다.
00:09:41제 친구 Blake와 함께 앉아서
00:09:42Parquet Java에서 Hadoop 종속성을 제거하려고 시도했습니다.
00:09:46Parquet Java가 뭔지 아신다면,
00:09:47커리어에서 대체 무슨 일이 있었길래
00:09:50그 지경까지 가셨는지 유감을 표합니다.
00:09:53결과는 좋지 않았습니다.
00:09:55여기 계획과 조사 내용이 있습니다.
00:09:57어느 시점에 우리는 모든 걸 버리고
00:09:58다시 화이트보드로 돌아갔습니다.
00:10:00위험 요소가 어디에 있는지 파악한 후에야
00:10:01우리는 실제로 다시 시작해야 했습니다.
00:10:03자, 이제 어떻게
00:10:05이것들을 맞춰나갈 것인가?
00:10:06이 지점에서 나중에 Jake가 이야기할
00:10:09흥미로운 점 하나를 짚고 넘어가겠습니다.
00:10:11사고(thinking)를 외주 주지 마세요.
00:10:13AI는 사고를 대체할 수 없습니다.
00:10:14그것은 당신이 한 생각, 혹은 생각의 부재를
00:10:17증폭시킬 뿐입니다.
00:10:19사람들이 묻습니다. "Dex, 이게
00:10:21명세 중심 개발(spec-driven development) 맞죠?"
00:10:23아니요, 명세 중심 개발은 망가졌습니다.
00:10:27개념이 아니라, 그 용어 자체가요.
00:10:30정의가 명확하지 않습니다.
00:10:33이분은 ThoughtWorks의 Brigetta입니다.
00:10:35많은 사람이 '명세(spec)'라고 말할 때
00:10:37그냥 더 자세한 프롬프트를 의미하곤 합니다.
00:10:39이 그림 기억하시는 분 계신가요?
00:10:41이게 어디서 나온 건지 아시는 분?
00:10:43아, 너무 옛날 거군요.
00:10:44에이전트의 시대는 오지 않을 것입니다.
00:10:46바로 '의미적 확산(semantic diffusion)' 때문이죠.
00:10:47Martin Fowler가 2006년에 이 말을 했습니다.
00:10:49좋은 정의를 가진 좋은 용어를 만들면
00:10:52모두가 흥분해서 달려듭니다.
00:10:53그리고 100명의 사람에게 100가지 다른 의미로
00:10:56사용되기 시작하면서 그 용어는 쓸모없어집니다.
00:10:59에이전트를 사람으로, 마이크로서비스로,
00:11:02챗봇으로, 혹은 워크플로우로 정의했었죠.
00:11:05Simon, 고맙습니다.
00:11:06다시 처음으로 돌아왔네요.
00:11:07에이전트는 그냥 루프 안에 있는 도구들일 뿐입니다.
00:11:09명세 중심 개발에도 이런 일이 일어나고 있습니다.
00:11:11원래 이 발표 서두에 Sean의 슬라이드를 넣으려 했지만,
00:11:15그게 사람들을 엉뚱한 것에
00:11:15집중하게 만들더군요.
00:11:17"코드는 잊으세요, 이제는 어셈블리 같은 겁니다.
00:11:19마크다운에만 집중하세요"라는 그의 생각은
00:11:21매우 멋진 아이디어지만, 사람들은 명세 중심 개발을
00:11:24더 나은 프롬프트나 PRD(제품 요구 사양서)를 쓰는 것이라 말합니다.
00:11:26때로는 검증 가능한 피드백 루프와
00:11:28백 프레셔를 사용하는 것이기도 하죠.
00:11:30어쩌면 Sean이 가르쳐준 것처럼
00:11:32코드를 어셈블리처럼 다루는 것일 수도 있습니다.
00:11:34하지만 많은 이들에게 그것은 코딩하는 동안
00:11:36그저 수많은 마크다운 파일을 사용하는 것에 불과합니다.
00:11:37혹은, 제가 지난주에 우연히 발견한 가장 황당한 경우는
00:11:39명세를 오픈 소스 라이브러리의 문서로 보는 것이었습니다.
00:11:43그래서 이제 끝났습니다.
00:11:44명세 중심 개발은 과대평가되었고, 이제는 쓸모없습니다.
00:11:48의미가 확산되어 버렸으니까요.
00:11:49그래서 현재 실제로 효과가 있는
00:11:52네 가지 전술적이고 실용적인 단계에 대해
00:11:55저희 내부와 수많은 사용자가 찾은 방법을 말씀드리려 합니다.
00:11:59먼저 조사를 통해 시스템이 어떻게 작동하는지 파악합니다.
00:12:02영화 "메멘토" 기억하시나요?
00:12:03Peter가 말했듯, 이것은
00:12:05컨텍스트 엔지니어링에 관한 최고의 영화입니다.
00:12:07주인공은 기억이 없는 상태로 깨어나,
00:12:09자신의 문신을 읽으며 자신이 누구인지와
00:12:11무엇을 하려 했는지 알아내야 합니다.
00:12:12에이전트를 온보딩하지 않으면, 에이전트는 정보를 지어낼 것입니다.
00:12:17이것은 여러분의 팀 구조를 아주 단순화한 것인데,
00:12:19대부분은 이보다 훨씬 복잡할 겁니다.
00:12:19대부분은 이보다 훨씬 큰 조직에 계시겠죠.
00:12:21하지만 여기 이 부분에서 작업을 하고 싶다고 가정해 봅시다.
00:12:23여러분은 모든 저장소(repo)에
00:12:26온보딩 자료를 넣을 수 있습니다.
00:12:27수많은 컨텍스트를 제공하는 거죠.
00:12:28여기 저장소가 있고, 어떻게 작동하는지 적어두는 겁니다.
00:12:29이것은 에이전트가 실제 작업을 시작하기 전에
00:12:32코드 베이스의 모든 컨텍스트를
00:12:34미리 볼 수 있도록 압축해 놓은 것입니다.
00:12:36문제는 이것이 너무 길어질 수 있다는 점입니다.
00:12:39코드 베이스가 정말 커지면,
00:12:41이 문서를 더 길게 만들거나
00:12:43정보를 누락시켜야만 합니다.
00:12:45그렇게 되면 여러분이 이걸 읽을 때,
00:12:48이 500만 라인짜리 거대한 모노레포의
00:12:49컨텍스트를 읽느라
00:12:52스마트 존의 에너지를 전부 써버리게 됩니다.
00:12:53정작 시스템 파악에 힘을 다 써서,
00:12:55덤 존에서 제대로 된 도구 호출을 할 수 없게 되죠.
00:12:57그래서 스택 아래로 이것을 쪼갤 수 있습니다.
00:13:02이걸 점진적 공개(progressive disclosure)라고 하죠.
00:13:04분할할 수 있다는 말입니다.
00:13:05각 저장소의 루트에 파일을 하나 두고,
00:13:08각 레벨마다 여러분이 일하는 위치에 따라
00:13:11추가적인 컨텍스트를
00:13:13제공하는 방식입니다.
00:13:15파일 자체는 '진실의 원천'이므로
00:13:17따로 문서화하지 않습니다.
00:13:18에이전트가 작업할 때,
00:13:19루트 컨텍스트를 가져오고
00:13:21하위 컨텍스트를 연이어 가져오게 합니다.
00:13:22특정 도구에 대해선 말하지 않겠지만,
00:13:23CloudMD나 Hoax 같은 것을 사용할 수 있겠죠.
00:13:24그렇게 하면 필요한 정보만 가져오기 때문에
00:13:26스마트 존에 여유가 충분히 남습니다.
00:13:28이 방법의 문제는 내용이 낡는다는 것입니다.
00:13:31새 기능을 출시할 때마다
00:13:33캐시를 무효화하고
00:13:35내부 문서의 많은 부분을 다시 작성해야 합니다.
00:13:38AI를 활용해 프로세스의 일부로
00:13:42이것을 업데이트할 수도 있겠죠.
00:13:43질문을 하나 해볼까요?
00:13:46실제 코드, 함수 이름, 주석, 문서 중에서
00:13:48이 차트의 Y축이 무엇인지
00:13:50맞혀보실 분 계신가요?
00:13:51- 슬롭요. - 슬롭.
00:13:57사실 이것은 코드 베이스의 각 부분에서
00:13:58발견할 수 있는 '거짓말'의 양입니다.
00:14:01업데이트를 프로세스에 넣을 수는 있겠지만,
00:14:03아마 안 하실 테니 추천하지 않습니다.
00:14:06저희가 선호하는 것은 '온디맨드 압축 컨텍스트'입니다.
00:14:08SCM 제공자나 JIRA, Linear와 관련된 기능을 만든다면
00:14:11약간의 방향성만 제시하면 됩니다.
00:14:14"이봐, 코드 베이스의 이쪽 부분으로
00:14:15갈 거야"라고 말이죠.
00:14:17그러면 좋은 조사 프롬프트나 슬래시 명령어가
00:14:18여러분의 의도를 파악해서,
00:14:21수많은 서브 에이전트를 가동해 코드 베이스를 수직으로 분석하고,
00:14:24실제 코드를 기반으로 한 진실된
00:14:27조사 문서 스냅샷을 만들어낼 것입니다.
00:14:30코드베이스 전반에 걸쳐 수직적 슬라이스를 실행하고 연구 문서를 작성합니다.
00:14:33이 문서는 실제 코드에 기반하여
00:14:35코드베이스에서 중요한 부분들만 정확하게 담아낸 스냅샷이 됩니다.
00:14:39우리는 진실을 압축하고 있는 것입니다.
00:14:41계획은 레버리지입니다.
00:14:43계획이란 의도를 압축하는 과정입니다.
00:14:45그리고 계획 단계에서 정확한 단계를 개략적으로 설명할 것입니다.
00:14:48연구 결과와 PRD, 버그 티켓 등
00:14:50무엇이든 가져와서
00:14:52계획을 세우고 계획 파일을 만듭니다.
00:14:54다시 한번 정보를 압축하는 거죠.
00:14:55여기서 잠시 멈추고 '정신적 정렬(Mental Alignment)'에 대해 이야기해 보겠습니다.
00:14:58코드 리뷰의 목적이 무엇인지 아시는 분 계신가요?
00:15:00바로 정신적 정렬, 사고의 일치입니다.
00:15:05내용이 맞는지 확인하는 등의 작업도 포함되지만,
00:15:08가장 중요한 것은 팀원 모두가
00:15:10코드베이스가 어떻게 변하고 있고 그 이유는 무엇인지에 대해
00:15:11어떻게 같은 이해도를 유지하느냐 하는 것입니다.
00:15:14매주 수천 줄의 Go 언어 코드를 읽을 수는 있겠죠.
00:15:17아니, 죄송합니다. 수천 줄은 못 읽겠네요.
00:15:18어렵긴 해도 할 수는 있겠지만,
00:15:19그러고 싶지는 않습니다.
00:15:20팀이 성장함에 따라 모든 코드는 리뷰를 거칩니다.
00:15:23코드를 읽지 않는다는 뜻이 아닙니다.
00:15:24하지만 팀의 기술 리더로서 저는
00:15:27계획서(Plans)를 읽는 것만으로도 최신 상태를 유지할 수 있습니다.
00:15:29그것만으로도 충분합니다.
00:15:30문제를 조기에 발견할 수 있고,
00:15:32시스템이 어떻게 진화하는지에 대한 이해를 유지할 수 있습니다.
00:15:35미첼(Mitchell)이 아주 좋은 글을 썼는데,
00:15:36PR(Pull Request)에 AMP 스레드를
00:15:38어떻게 포함시키는지에 대한 내용이었습니다. 이를 통해 단순히
00:15:41GitHub에 산더미처럼 쌓인 녹색 텍스트(코드 수정분)만 보는 게 아니라,
00:15:43정확한 단계와 프롬프트,
00:15:44그리고 마지막에 빌드를 실행해서 통과했다는 사실까지 확인할 수 있습니다.
00:15:46이것은 GitHub PR만으로는 불가능한 방식으로
00:15:49리뷰어를 여정에 동참시킵니다.
00:15:51이전보다 2~3배 더 많은 코드를
00:15:52배포하게 되는 상황에서는,
00:15:54팀원들이 같은 정보를 공유하도록
00:15:57어떤 단계를 거쳤고 수동 테스트는 어떻게 했는지
00:16:00보여줄 방법을 찾는 것이 여러분의 몫입니다.
00:16:01여러분의 목표는 레버리지이며, 따라서 모델이 실제로
00:16:04올바른 작업을 수행할 것이라는 높은 확신이 필요합니다.
00:16:06단순한 계획만 읽어서는 실제로 어떤 일이 벌어질지,
00:16:08어떤 코드 변경이 일어날지 알 수 없습니다.
00:16:11그래서 저희는 시간을 들여 계획에
00:16:14실제 변경될 코드 스니펫을 포함하도록 개선해 왔습니다.
00:16:17목표는 레버리지입니다.
00:16:18의도의 압축과
00:16:19신뢰할 수 있는 실행을 원하는 것이죠.
00:16:22저는 물리학을 전공했습니다.
00:16:23우리는 정점과 곡선의 중심을 지나는 선을 그리는 것을 좋아하죠.
00:16:28계획이 길어질수록 신뢰성은 높아지지만,
00:16:30가독성은 떨어집니다.
00:16:31여러분과 여러분의 팀, 코드베이스에 맞는
00:16:33최적의 지점이 있을 테니 그것을 찾아야 합니다.
00:16:35연구 결과와 계획을 리뷰할 때,
00:16:37그 내용이 훌륭하다면 정신적 정렬을 이룰 수 있습니다.
00:16:40생각하는 과정을 외부(AI)에만 맡기지 마세요.
00:16:42전에도 말했지만, 이건 마법이 아닙니다.
00:16:44완벽한 프롬프트 같은 건 없어요.
00:16:46여러분이 계획을 읽지 않는다면 작동하지 않을 것입니다.
00:16:50그래서 저희는 개발자가 에이전트와 소통하며
00:16:53생성되는 계획을 직접 확인하는 과정을 중심으로
00:16:55전체 프로세스를 구축했습니다.
00:16:56동료의 검토가 필요하다면
00:16:58누군가에게 보내서 이렇게 물어볼 수 있습니다.
00:16:58"이 계획이 맞아 보여?"
00:17:00"접근 방식이 올바른가?"
00:17:00"검토 순서가 적절해?"
00:17:03제이크(Jake)도 블로그에 아주 좋은 글을 썼는데,
00:17:05연구-계획-구현 단계가 가치 있는 이유는
00:17:07인간이 과정에 참여하여 정확성을 확인하기 때문입니다.
00:17:11이 발표에서 단 한 가지만 기억해야 한다면,
00:17:14잘못된 코드 한 줄은 그저 나쁜 코드 한 줄이지만,
00:17:17계획의 잘못된 부분 하나는 100줄의 나쁜 코드가 될 수 있다는 점입니다.
00:17:22시스템 작동 방식이나 위치에 대한 오해 같은
00:17:25잘못된 연구 결과 한 줄이 있다면,
00:17:27전체 작업이 엉망이 될 것입니다.
00:17:29모델을 완전히 잘못된 방향으로 보내게 되기 때문이죠.
00:17:31그래서 내부적으로나 사용자들과 협업할 때,
00:17:34저희는 인간의 노력과 집중력을 이 파이프라인에서
00:17:36가장 레버리지가 높은 부분으로 옮기려고 끊임없이 노력합니다.
00:17:39생각하는 것을 멈추지 마세요.
00:17:41그저 기분만 좋게 하려고 수많은 마크다운 파일을
00:17:43쏟아내기만 하는 도구들을 주의하십시오.
00:17:45여기서 특정 이름을 언급하지는 않겠습니다.
00:17:47때로는 이런 과정이 과할 수도 있습니다.
00:17:49제가 생각하는 방식은 이렇습니다.
00:17:51항상 전체 연구-계획-구현 과정이 필요한 것은 아닙니다.
00:17:54더 필요할 때도 있고, 덜 필요할 때도 있죠.
00:17:56버튼 색상을 바꾸는 정도라면,
00:17:57그냥 에이전트에게 말해서 시키면 됩니다.
00:18:00간단한 계획이나 작은 기능이라면 그렇게 하세요.
00:18:04여러 저장소에 걸친 중간 규모의 기능이라면
00:18:07연구를 한 번 수행한 뒤에 계획을 세우십시오.
00:18:09기본적으로 해결할 수 있는 문제의 난이도 상한선은
00:18:10이러한 컨텍스트 엔지니어링과 정보 압축에
00:18:13얼마나 공을 들이느냐에 따라 올라갑니다.
00:18:15더 복잡한 문제를 해결해야 한다면,
00:18:18아마 더 많은 작업을 해야 할 것입니다.
00:18:19컨텍스트 엔지니어링을 얼마나 사용해야 하는지
00:18:21많은 분들이 묻습니다.
00:18:23반복적인 경험이 필요합니다.
00:18:24계속해서 시행착오를 겪어야 합니다.
00:18:26반복하고 또 반복해야 하죠.
00:18:27때로는 너무 과하게, 때로는 너무 부족하게 할 수도 있습니다.
00:18:29도구 하나를 정해서 연습해 보세요.
00:18:32Claude나 Codex 등 여러 도구를 오가며
00:18:35지나치게 효율만 따지는 것은 추천하지 않습니다.
00:18:36저는 약어(Acronym)를 별로 좋아하지 않습니다.
00:18:40명세 기반 개발(Spec-driven dev)은 한계가 있다고 말씀드렸죠.
00:18:42연구-계획-구현이 정답이라고 생각하지는 않습니다.
00:18:44중요한 것은 정보 압축과 컨텍스트 엔지니어링,
00:18:47그리고 '스마트 존'에 머무르는 것입니다.
00:18:48하지만 사람들이 이걸 RPI라고 부르기 시작했고
00:18:50그걸 막을 방법이 없더군요.
00:18:52그러니 주의하세요. 완벽한 프롬프트도,
00:18:55만능 해결책(Silver bullet)도 없습니다.
00:18:56더 멋진 단어를 원하신다면
00:18:58'하네스 엔지니어링(Harness Engineering)'이라고 부를 수 있습니다.
00:19:00이는 컨텍스트 엔지니어링의 일부로,
00:19:01Codex, Claude, Cursor 등과 같은 도구의 통합 지점을
00:19:03어떻게 활용하고 통합할지,
00:19:05자신의 코드베이스를 어떻게 최적화할지에 관한 것입니다.
00:19:07그럼 다음 단계는 무엇일까요?
00:19:11코딩 에이전트 기술은 사실
00:19:12결국 보편화(Commoditized)될 것이라고 생각합니다.
00:19:13사람들은 이를 사용하는 법을 배우고 더 숙달될 것입니다.
00:19:15어려운 부분은 코드의 99%를 AI가 작성하는 세상에서
00:19:17팀과 SDLC(소프트웨어 개발 수명 주기) 워크플로우를
00:19:21어떻게 적응시키느냐 하는 점입니다.
00:19:24이걸 해결하지 못하면 곤란해질 것입니다.
00:19:26현재 일종의 격차가 벌어지고 있기 때문입니다.
00:19:27스태프 엔지니어들은 AI를 도입하지 않는데,
00:19:29자신들의 속도를 크게 높여주지 않는다고 느끼기 때문입니다.
00:19:31반면 주니어와 미들급 엔지니어들은
00:19:33부족한 기술을 보완하기 위해 AI를 많이 사용하죠.
00:19:35그러다 보면 저품질의 코드(Slop)가 생성되기도 하고,
00:19:36시니어 엔지니어들은 매주 그 코드를 치우느라
00:19:38AI를 점점 더 싫어하게 됩니다.
00:19:40지난주에 Cursor가 만든 코드를 정리해야 하니까요.
00:19:42이건 AI의 잘못이 아닙니다.
00:19:44미들급 엔지니어의 잘못도 아니죠.
00:19:46문화적 변화는 정말 어렵고,
00:19:48성공하려면 리더십 차원에서 이루어져야 합니다.
00:19:50회사의 기술 리더라면,
00:19:52도구 하나를 선택해 직접 경험해 보십시오.
00:19:54도움이 필요하시다면 저희는 채용 중입니다.
00:19:56모든 규모의 팀이 99% AI 생성 코드 시대로 빠르게 나아갈 수 있도록
00:19:59에이전트 기반 IDE를 만들고 있습니다.
00:20:03저희와 함께 일하고 싶으시다면 이야기 나누고 싶습니다.
00:20:06웹사이트를 방문하시거나 이메일을 보내주시고,
00:20:08복도에서 저를 찾아주세요.
00:20:09경청해 주셔서 대단히 감사합니다.
00:20:11(청중 박수)
00:20:13(경쾌한 전자 음악)