우연한 오케스트레이터

이 글은 에이전트 엔지니어링과 AI 주도 개발에 관한 시리즈의 첫 번째 글입니다. 다음 글은 3월 19일 O'Reilly Radar에서 찾아보세요.

AI와 소프트웨어 개발에 대한 과장된 홍보가 많다. 그리고 그것은 두 가지 부류로 나뉜다. 하나는 "우리는 모두 망했다. 클로드 코드(Claude Code) 같은 도구가 1년 안에 소프트웨어 엔지니어링을 구식으로 만들 것"이라고 말한다. 다른 하나는 "걱정하지 마라. 모든 것이 괜찮다. AI는 도구 상자의 또 다른 도구일 뿐"이라고 말한다. 둘 다 솔직하지 않다.

나는 실무자를 위해 소프트웨어 개발에 관해 20년 넘게 글을 써왔다. 코딩과 아키텍처부터 프로젝트 관리와 팀 역학까지 모든 것을 다루었다. 지난 2년간은 AI에 집중했다. 개발자들이 이 도구를 효과적으로 사용하도록 교육하고, 책과 기사, 보고서에서 무엇이 통하고 무엇이 통하지 않는지 작성했다. 그리고 계속 똑같은 문제에 부딪혔다. 경험이 풍부한 개발자가 이 도구를 실제로 어떻게 사용해야 하는지에 대해 일관된 답변을 내놓은 사람을 아직 찾지 못했다.

팁은 많고 과장된 이야기도 많지만 구조는 거의 없다. 실습하거나, 가르치거나, 비판하거나, 개선할 수 있는 것도 거의 없다. 나는 개발자들이 AI를 사용하여 다양한 수준의 성공을 거두며 일하는 것을 관찰해왔다. 그리고 우리가 이것을 하나의 독립된 학문으로 생각하기 시작해야 한다는 것을 깨달았다. 테슬라의 전 AI 총괄이자 오픈AI의 창립 멤버인 안드레이 카르파티(Andrej Karpathy)는 최근 AI 에이전트를 이용한 체계적인 개발을 위해 '에이전트 엔지니어링(agentic engineering)'이라는 용어를 제안했다. 애디 오스마니(Addy Osmani) 같은 다른 사람들도 동참하고 있다. 오스마니의 프레임은 AI 에이전트는 구현을 처리하지만 인간은 아키텍처를 소유하고 모든 diff를 검토하며 끊임없이 테스트한다는 것이다. 나는 그것이 옳다고 생각한다.

하지만 나는 지난 2년간 클로드 코드, 코파일럿(Copilot)의 에이전트 모드, 커서(Cursor) 등의 도구를 사용하는 방법을 개발자들에게 가르치며 많은 시간을 보냈다. 그리고 내가 계속 듣는 것은 그들이 이미 AI의 출력을 검토하고, 아키텍처를 유지하며, 테스트를 작성하고, 문서를 최신으로 유지하고, 코드베이스를 통제해야 한다는 것을 안다는 것이다. 그들은 이론적으로 하는 방법을 안다. 하지만 실제로 적용하려다가 막힌다. AI가 생성한 수천 줄의 코드를 실제로 어떻게 검토하는가? 여러 AI 도구에 걸쳐 몇 주간 작업할 때 아키텍처를 어떻게 일관되게 유지하는가? AI가 자신만만하게 틀렸을 때 어떻게 아는가?

그리고 에이전트 엔지니어링에 어려움을 겪는 것은 주니어 개발자뿐이 아니다. 나는 에이전트 도구로의 전환에 어려움을 겪는 시니어 엔지니어들과, 그것에 자연스럽게 적응하는 중급 개발자들을 만났다. 차이는 반드시 경력 햂数가 아니다. 그것은 그들이 AI 코딩 도구를 사용하여 효과적이고 구조화된 방식을 알아냈는지 여부다.

개발자가 에이전트 엔지니어링으로 무엇을 해야 하는지 아는 것과 그것을 일상 업무에 통합하는 방법을 아는 것 사이의 그 격차는 지금 많은 엔지니어에게 불안의 실제 원천이다.

그것이 이 시리즈가 채우려고 하는 격차다.

에이전트 엔지니어링에 대한 많은 과장된 이야기가 말하는 것과는 달리, 이런 종류의 개발은 개발자 전문 지식의 필요성을 없애지 않는다. 정반대다. AI 에이전트와 효과적으로 일하는 것은 실제로 개발자가 알아야 하는 것의 기준을 높인다. 나는 앞서 O'Reilly Radar에 "인지적 지름길의 역설(The Cognitive Shortcut Paradox)"이라는 글에서 그 경험 격차에 대해 썼다. AI 코딩 도구를 사용하여 가장 많은 것을 얻는 개발자는 좋은 소프트웨어가 어떻게 생겼는지 이미 알고 있으며, AI가 작성했는지 종종 알 수 있는 개발자들이다.

경험이 풍부한 개발자가 AI 도구를 운영할 때 가장 잘 작동한다는 생각은 내가 관찰한 모든 것과 일치했다. 그것은 사실처럼 들렸고, 나는 다른 개발자들이 이해할 수 있는 방식으로 그것을 증명하고 싶었다. 바로 소프트웨어를 만들어서.

그래서 나는 개발자가 따를 수 있도록 만든 에이전트 엔지니어링에 대한 구체적이고 실용적인 접근법을 만들기 시작했고, 그것을 테스트했다. AI가 모든 코드를 작성한다는 규칙을 가지고 처음부터 프로덕션 시스템을 만드는 데 사용했다. 나는 접근법을 스트레스 테스트할 만큼 충분히 복잡하고, 어려운 부분을 통해 나를 사로잡을 만큼 흥미로운 프로젝트가 필요했다. 내가 배운 모든 것을 적용하고 내가 여전히 모르는 것이 무엇인지 발견하고 싶었다.

그때 몬테카를로 시뮬레이션(Monte Carlo simulations)으로 돌아왔다.

실험

나는 어릴 때부터 몬테카를로 시뮬레이션에 매료되어 있었다. 아버지는 역학자(epidemiologist)이다. 그의 전체 경력은 지저분한 인구 데이터에서 패턴을 찾는 것이었다. 그것은 통계가 항상 우리 삶의 일부였다는 것을 의미했다(그리고 내가 매우 어린 나이에 SPSS를 배웠다는 것을 의미하기도 했다). 내가 아마 11살 때였을 것이다. 그는 술취한 선원 문제에 대해 말해주었다. 선원이 부두에 있는 술집을 나와서 매번 물 쪽이나 배 쪽으로 무작위로 발걸음을 내딛는다. 그는 물에 빠지는가 아니면 집에 가는가? 단일 실행으로는 알 수 없다. 하지만 시뮬레이션을 천 번 실행하면 노이즈에서 패턴이 나타난다. 개별 결과는 무작위지만, 집계는 예측 가능하다.

나는 TRS-80 컬러 컴퓨터 2에서 BASIC으로 그 시뮬레이션을 작성했던 것을 기억한다. 화면을 가로질러 비틀거리는 작고 각진 선원, 두 발 앞으로, 한 발 뒤로. 술취한 선원은 몬테카를로 시뮬레이션의 "헬로 월드"다.

몬테카를로는 분석적으로 풀 수 없는 문제를 위한 기법이다. 문제를 수백 번 또는 수천 번 시뮬레이션하고 집계 결과를 측정한다. 각 개별 실행은 무작위지만, 표본 크기가 커짐에 따라 통계는 실제 답으로 수렴한다. 그것은 핵물리학부터 금융 리스크, 인구 집단 간 질병 확산까지 모든 것을 모델링하는 한 가지 방법이다.

오늘날 평범한 영어로 설명하여 그런 종류의 시뮬레이션을 실행할 수 있다면 어떨까? 장난감 데모가 아니라 재현성을 위해 시드된 무작위성을 가진 수천 번의 반복이 있고, 출력이 검증되며, 결과가 실제로 사용할 수 있는 통계로 집계되는. 또는 LLM이 콘텐츠를 생성하고, 두 번째 LLM이 그것을 점수 매기고, 통과하지 못하는 것은 다시 시도하도록 보내지는 파이프라인.

나의 실험 목표는 옥토배치(Octobatch)라고 부르는 그 시스템을 만드는 것이었다. 지금 산업은 에이전트 엔지니어링의 새로운 실제 엔드투엔드 사례 연구를 끊임없이 찾고 있다. 나는 옥토배치가 바로 그 사례 연구가 되기를 원했다. 나는 가르치고 AI를 사용하여 작업하는 개발자들을 관찰하면서 배운 모든 것을 가져왔다. 처음부터 실제 시스템을 만들어 테스트했다. 그리고 그 교훈을 내가 AI 주도 개발(AI-driven development) 또는 AIDD라고 부르는 에이전트 엔지니어링에 대한 구조화된 접근법으로 바꿨다.

이것은 에이전트 엔지니어링이 실제로 어떻게 보이는지, 개발자에게 무엇을 요구하는지, 그리고 자신의 작업에 어떻게 적용할 수 있는지에 관한 시리즈의 첫 번째 글이다. 결과는 완전히 작동하고 잘 테스트된 애플리케이션이다. 수십 개의 파일에 걸쳐 약 21,000줄의 파이썬 코드로 구성되어 있으며, 완전한 사양, 거의 천 개의 자동화된 테스트, 그리고 양질의 통합 및 회귀 테스트 스위트가 뒷받침한다. 나는 클로드 Cowork를 사용하여 전체 프로젝트의 모든 AI 채팅을 검토했다. 그리고 7주에 걸쳐 약 75시간의 실제 개발 시간에 전체 애플리케이션을 구축한 것으로 밝혀졌다. 비교를 위해, 나는 작년에 블루 프린스(Blue Prince)를 하느라 보낸 시간의 절반 조금 넘는 시간에 옥토배치를 만들었다.

하지만 이 시리즈는 옥토배치에 관한 것만이 아니다. 나는 모든 수준에서 AI 도구를 통합했다. 아키텍처에서 협력하는 클로드와 제미니(Gemini), 구현을 작성하는 클로드 코드, 그들이 만드는 데 도움을 준 시스템에서 실행되는 파이프라인을 생성하는 LLM. 이 시리즈는 그 과정에서 내가 배운 것에 관한 것이다. 작동한 패턴, 가장 많은 것을 가르쳐준 실패, 그리고 그 모든 것을 묶어주는 오케스트레이션 마인드셋. 각 글은 실험에서 다른 교훈을 끄어온다. 검증 아키텍처부터 다중 LLM 조정, 프로젝트를 궤도에 유지한 가치까지.

에이전트 엔지니어링과 AI 주도 개발

대부분의 사람들이 AI를 사용하여 코드를 작성하는 것에 대해 말할 때, 그들은 두 가지 중 하나를 의미한다. 깃허브 코파일럿, 커서, 윈드서프(Windsurf) 같은 AI 코딩 어시스턴트. 이들은 자동 완성을 넘어 다중 파일 편집 세션을 실행하고 사용자 정의 에이전트를 정의할 수 있는 에이전트 도구로 발전했다. 또는 "바이브 코딩(vibe coding)"으로, 자연어로 원하는 것을 설명하고 돌아오는 것을 무엇이든 받아들이는 것.

이런 코딩 어시스턴트는 정말 인상적이며, 바이브 코딩은 정말 생산적일 수 있다. 하지만 실제 프로젝트에서 이 도구를 효과적으로 사용하면서 AI가 생성한 수천 줄의 코드에 걸쳐 아키텍처 일관성을 유지하는 것은 완전히 다른 문제다. AIDD는 그 문제를 해결하는 데 도움을 주는 것을 목표로 한다.

그것은 에이전트 엔지니어링에 대한 구조화된 접근법이다. AI 도구가 구현, 아키텍처, 심지어 프로젝트 관리의 상당 부분을 주도하지만, 루프에 있는 인간인 당신이 무엇을 만들지, 그것이 괜찮은지 결정한다. "구조"란 개발자가 배우고 따를 수 있는 일련의 실천 방식, AI의 출력이 실제로 좋은지 알 수 있는 방법, 프로젝트의 수명 동안 올바른 길을 유지하는 방법을 의미한다. 에이전트 엔지니어링이 학문이라면, AIDD는 그것을 실천하는 한 가지 방법이다.

AI 주도 개발에서 개발자는 제안을 그냥 받아들이거나 출력이 올바르기를 바라지 않는다. 그들은 특정 도구에 특정 역할을 할당한다. 아키텍처 계획을 위한 하나의 LLM, 코드 실행을 위한 다른 LLM, 구현을 위한 코딩 에이전트, 그리고 비전, 검증, 전체 시스템의 이해가 필요한 결정을 위한 인간. 그리고 "주도"라는 부분은 문자 그대로다. AI가 거의 모든 코드를 작성하고 있다.

옥토배치 실험에 대한 나의 기본 규칙 중 하나는 AI가 모든 것을 작성하도록 두는 것이었다. 나는 높은 코드 품질 기준을 가지고 있으며, 실험의 일부는 AIDD가 그 기준을 충족하는 시스템을 생성할 수 있는지 보는 것이었다. 인간이 무엇을 만들지 결정하고, 그것이 올바른지 평가하며, 시스템을 일관되게 유지하는 제약 조건을 관리한다.

모든 사람이 개발자가 얼마나 루프에 있어야 하는지에 동의하지는 않는다. 그리고 스펙트럼의 완전 자율 끝은 이미 경계적인 이야기를 만들어내고 있다. 앤트로픽의 니콜라스 칼리니(Nicholas Carlini)는 최근 16개의 클로드 인스턴스에 인간이 루프에 없는 상태에서 병렬로 C 컴파일러를 만들도록 지시했다. 2,000번의 세션과 20,000달러의 API 비용 후, 에이전트들은 리눅스 커널을 빌드할 수 있는 10만 줄의 컴파일러를 생성했지만 그 무엇의 바로 사용할 수 있는 대체품도 아니다. 그리고 16개의 에이전트 모두가 같은 버그에 막혔을 때, 칼리니가 다시 개입하여 작업을 분할해야 했다. 완전한 핸즈오프, 바이브 중심 접근 방식을 강력하게 옹호하는 사람들조차 그것은 너무 나아갔다고 부를 수 있다.

질문은 그 코드를 신뢰할 수 있게 만들기 위해 얼마나 많은 인간의 판단이 필요한지, 그리고 그 판단을 효과적으로 적용하는 데 도움이 되는 구체적인 실천 방식이 무엇인지다.

오케스트레이션 마인드셋

개발자가 에이전트 엔지니어링을 올바른 방식으로 생각하게 하려면, 그들이 사용하는 도구뿐만 아니라 AI를 사용하여 작업하는 방식을 생각하는 것부터 시작해야 한다. 그것이 내가 구조화된 접근법을 만들기 시작했을 때 시작한 곳이며, 그것이 내가 습관(habits)으로 시작한 이유다.

나는 이것을 위한 프레임워크를 개발했다. 센스-AI 프레임워크(Sens-AI Framework)라고 부르며, O'Reilly 리포트(AI와 함께 코딩하기 위한 비판적 사고 습관)와 Radar 시리즈로 출판되었다. 그것은 다섯 가지 실천 방식을 중심으로 구축되었다. 문맥 제공, 프롬프트 전에 연구하기, 문제를 정밀하게 프레이밍하기, 출력에 대해 의도적으로 반복하기, 그리고 AI가 생성하는 모든 것에 비판적 사고를 적용하기.

거기서 시작했는데, 습관은 당신이 작업하는 방식에 대해 생각하는 방식을 고정하는 것이기 때문이다. 그것 없이는 AI 주도 개발은 세밀하게 보면 무너지는 그럴듯해 보이는 코드를 생성한다. 그것과 함께라면 단일 개발자가 같은 시간에 혼자서 구축할 수 없는 시스템을 생성한다.

습관은 기초이지만 전체 그림은 아니다. AIDD는 또한 실천 방식(practices)(다중 LLM 조정, 문맥 파일 관리, 한 모델을 사용하여 다른 모델의 출력을 검증하는 것과 같은 구체적인 기술)과 가치(values)(그 실천 방식 뒤에 있는 원칙)를 가지고 있다. 스크럼이나 XP 같은 애자일 방법론을 사용해 봤다면, 그 구조는 꽤 익숙할 것이다. 실천 방식은 날마다 어떻게 작업하는지 알려주고, 습관은 실천 방식이 자동이 되도록 개발하는 반사 신경이다. 가치는 종종 이상하게 이론적으로 보이지만, 실천 방식이 명확한 답을 주지 않을 때 결정을 안내하기 때문에 퍼즐의 중요한 조각이다.

지금 에이전트 엔지니어링을 둘러싼 신흥 문화가 있다. 그리고 프로젝트에 가져오는 가치는 그 문화와 일치하거나 충돌한다. 가치가 어디서 오는지 이해하는 것이 실천 방식을 지속하게 만드는 것이다.

그 모든 것이 완전히 새로운 마인드셋으로 이어진다. 내가 오케스트레이션 마인드셋(the orchestration mindset)이라고 부르는 것. 이 시리즈는 옥토배치를 시험장으로 사용하여 네 가지 층을 모두 구축한다. 옥토배치는 AIDD의 의도적인 실험이었다. 나는 전체 접근법에 대한 테스트 사례로 프로젝트를 설계했다. 체계적인 AI 주도 워크플로가 무엇을 생성할 수 있고 어디서 무너질지 보기 위해서다. 그리고 실천 방식과 가치를 적용하고 개선하여 효과적이고 채택하기 쉽게 만들었다.

그리고 본능이든 우연이든, 나는 이 실험에 완벽한 프로젝트를 선택했다. 옥토배치는 배치 오케스트레이터다. 비동기 작업을 조정하고, 장애 전반의 상태를 관리하며, 파이프라인 단계 간의 의존성을 추적하고, 검증된 결과가 다른 쪽 끝에서 나오도록 보장한다. 그런 종류의 시스템은 설계하는 것이 재미있지만, 상태 머신, 재시도 로직, 충돌 복구, 비용 계산 같은 많은 세부 사항은 구현하기 지루할 수 있다. 그것은 패턴은 잘 알려져 있지만 구현은 반복적이고 오류가 발생하기 쉬운 작업의 정확한 종류이다. AIDD가 빛을 발해야 하는 곳이다.

오케스트레이션—일관된 결과를 향해 여러 독립적인 프로세스를 조정하는 작업—은 AIDD의 핵심 아이디어 중 하나로 발전했다. 나는 옥토배치가 배치 작업을 조정하는 것과 같은 방식으로 LLM을 조정하는 자신을 발견했다. 역할을 할당하고, 핸드오프를 관리하며, 출력을 검증하고, 장애에서 복구하는 것. 내가 만들고 있던 시스템과 그것을 만들기 위해 사용하던 프로세스는 같은 패턴을 따랐다.

시작할 때는 예상하지 못했지만, AI를 조정하는 시스템을 만드는 것은 AI를 조정하는 방법을 배우는 꽤 좋은 방법으로 밝혀졌다. 그것이 우연한 오케스트레이터의 우연한 부분이다. 그 평행선은 이 시리즈의 모든 글을 관통한다.

Radar를 이메일로 바로 받고 싶은가? 서브스택에서 우리와 함께하세요. 여기서 가입하세요.

배치로 가는 길

나는 완전한 엔드투엔드 몬테카를로 시뮬레이션으로 시작하며 옥토배치 프로젝트를 시작하지 않았다. 대부분의 사람들이 시작하는 곳에서 시작했다. 채팅 인터페이스에 프롬프트를 입력하는 것. 나는 프로젝트에 약간의 구조를 주기 위해 다양한 시뮬레이션과 생성 아이디어를 실험하고 있었고, 그중 몇 가지가 남았다. 블랙잭 전략 비교는 다단계 몬테카를로 시뮬레이션의 훌륭한 테스트 사례로 밝혀졌다. 롤플레잉 게임을 위한 NPC 대화 생성은 측정할 주관적 품질을 가진 창의적 워크로드를 주었다. 둘 다 같은 형태를 가졌다. 동일한 방식으로 처리되는 구조화된 입력 집합.

그래서 나는 손으로 하던 것을 자동화하는 간단한 스크립트를 클로드에게 작성하도록 했다. 그리고 제미니를 사용하여 작업을 다시 확인하고, 클로드가 내 요청을 정말로 이해했는지 확인하고, 환각을 수정했다. 작은 규모에서는 잘 작동했다. 하지만 100개 이상의 단위를 실행하기 시작하자, 계속 속도 제한에 부딪혔다. 제공자가 분당 수행할 수 있는 API 요청 수에 두는 제한.

그것이 나를 LLM 배치 API로 밀어붙인 것이다. 개별 프롬프트를 한 번에 하나씩 보내고 각 응답을 기다리는 대신, 주요 LLM 제공자는 모든 요청을 포함하는 파일을 한 번에 제출할 수 있는 배치 API를 제공한다. 제공자는 자신의 일정에 따라 처리한다. 결과를 기다리는 대신 즉시 받지는 못하지만 속도 제한을 걱정할 필요가 없다. 또한 50% 저렴하다는 것을 기쁘게 발견했고, 그때 토큰 사용량과 비용을 진지하게 추적하기 시작했다.

하지만 진짜 놀라움은 배치 API가 규모에서 실시간 API보다 더 잘 수행되었다는 것이었다. 파이프라인이 100 또는 200단위 표시를 넘어가자, 배치는 실시간보다 훨씬 빠르게 실행되기 시작했다. 제공자는 자신의 인프라에서 전체 배치를 병렬로 처리하므로, 왕복 지연 시간이나 속도 제한에 의해 병목이 생기지 않는다.

배치 API로의 전환은 규모에서 LLM API 호출을 조정하는 전체 문제를 생각하는 방식을 바꾸었고, 구성 가능한 파이프라인의 아이디어로 이어졌다. 단계를 함께 연결할 수 있다. 한 단계의 출력이 다음 단계의 입력이 될 수 있고, 전체 파이프라인을 시작하고 완료된 결과로 돌아올 수 있다.

배치 API로 전환하는 것은 나만이 아니었다. 2024년 4월과 2025년 7월 사이, 오픈AI, 앤트로픽, 구글은 모두 배치 API를 출시했으며, 동일한 가격 모델로 수렴했다. 비동기 처리의 대가로 실시간 요율의 50%. 아마 세 주요 AI 제공자가 모두 배치 API를 출시했다는 것을 눈치채지 못했을 것이다. 산업 대화는 에이전트, 도구 사용, MCP, 실시간 추론이 지배했다. 배치 API는 상대적으로 적은 팡파르와 함께 출시되었지만, LLM을 사용하는 방식에서 진정한 변화를 나타낸다. 그것들을 대화 파트너나 일회성 SaaS API로 취급하는 대신, 처리 인프라로 취급할 수 있다. 챗봇보다는 맵리듀스 작업에 더 가깝다. 구조화된 데이터와 프롬프트 템플릿을 주면, 그것은 모든 것을 처리하고 결과를 돌려준다.

중요한 것은 이제 속도 제한이나 연결 장애를 관리하지 않고도 규모에서 수만 번의 변환을 신뢰할 수 있게 실행할 수 있다는 것이다.

왜 오케스트레이션인가?

배치 API가 그토록 유용하다면, 요청을 제출하고 결과를 수집하는 for-루프를 작성하면 되지 않는가? 할 수 있다. 그리고 간단한 경우 for-루프가 있는 빠른 스크립트는 잘 작동한다. 하지만 더 큰 워크로드를 실행하기 시작하면 문제가 쌓이기 시작한다. 그 문제를 해결하는 것은 에이전트 엔지니어링에 대한 구조화된 접근법을 개발하는 가장 중요한 교훈 중 하나로 밝혀졌다.

첫째, 배치 작업은 비동기다. 작업을 제출하고 몇 시간 후에 결과가 돌아오므로, 스크립트는 제출된 것을 추적하고 완료를 폴링해야 한다. 스크립트가 중간에 충돌하면 그 상태를 잃는다.

둘째, 배치 작업은 부분적으로 실패할 수 있다. 요청의 97%가 성공하고 3%가 실패했을 수 있다. 코드는 어떤 3%가 실패했는지 파악하고, 그것들을 추출하고, 그 항목만 다시 제출해야 한다.

셋째, 한 단계의 출력이 다음 단계로 들어가는 다단계 파이프라인을 만들고 있다면, 단계 간의 의존성을 추적해야 한다.

넷째, 비용 계산이 필요하다. 수만 번의 요청을 실행할 때, 얼마나 썼는지 알고 싶다. 그리고 이상적으로는 배치를 처음 시작할 때 얼마나 쓸 것인지 알고 싶다.

이 모든 것은 에이전트 엔지니어링에서 하는 것과 직접적인 평행선을 가진다. 여러 AI 에이전트가 한 번에 하고 있는 작업을 추적하고, 코드 장애와 버그를 처리하고, AI 코딩 도구가 현재 문맥에 있는 한 부분만 보고 있을 때 전체 프로젝트가 일관되게 유지되도록 보장하고, 물러서서 더 넓은 프로젝트 관리 그림을 살펴보는 것.

이 모든 문제는 해결 가능하지만, 반복해서 해결하고 싶은 문제는 아니다(두 상황 모두에서—LLM 배치 작업을 조정하거나 AI 코딩 도구를 조정할 때). 코드에서 이 문제를 해결하는 것은 에이전트 엔지니어링에 대한 전체 접근법에 대한 몇 가지 흥미로운 교훈을 주었다. 배치 처리는 복잡성을 연결 관리에서 상태 관리로 이동시킨다. 실시간 API는 속도 제한과 재시도 때문에 어렵다. 배치 API는 무엇이 진행 중이고, 무엇이 성공했고, 무엇이 실패했고, 무엇이 다음인지 추적해야 하기 때문에 어렵다.

개발을 시작하기 전에, 나는 이 문제의 조합을 처리하는 기존 도구를 찾았다. 바퀴를 재발명하는 데 시간을 낭비하고 싶지 않았기 때문이다. 내가 필요한 작업을 수행하는 것을 찾지 못했다. 아파치 에어플로우(Apache Airflow)와 댑스터(Dagster) 같은 워크플로 오케스트레이터는 DAG와 작업 의존성을 관리하지만, 작업이 결정론적이라고 가정하며 프롬프트 템플릿 렌더링, 스키마 기반 출력 검증, 의미론적 품질 검사에 의해 트리거되는 재시도 로직 같은 LLM 특정 기능을 제공하지 않는다.

랭체인(LangChain)과 라마인덱스(LlamaIndex) 같은 LLM 프레임워크는 실시간 추론 체인과 에이전트 루프를 중심으로 설계되었다. 비동기 배치 작업 수명 주기를 관리하거나, 프로세스 충돌 전반의 상태를 지속하거나, 청크 수준에서 부분 장애 복구를 처리하지 않는다. 그리고 제공자 자신의 배치 API 클라이언트 라이브러리는 단일 배치에 대한 제출과 검색을 처리하지만, 다단계 파이프라인, 단계 간 검증, 또는 제공자에 구애받지 않는 실행은 처리하지 않는다.

내가 찾은 것 중 어떤 것도 세 주요 AI 제공자 전반의 제출과 폴링에서 검증, 재시도, 비용 추적, 충돌 복구에 이르는 다단계 LLM 배치 워크플로의 전체 수명 주기를 다루지 않았다. 그것이 내가 만든 것이다.

실험에서의 교훈

에이전트 엔지니어링과 AI 주도 개발에 관한 시리즈의 첫 번째 글로서, 이 글의 목표는 옥토배치 실험의 가설과 구조를 제시하는 것이다. 시리즈의 나머지는 그것에서 배운 교훈을 깊이 파고든다. 검증 아키텍처, 다중 LLM 조정, 작업에서 나타난 실천 방식과 가치, 그리고 그 모든 것을 묶어주는 오케스트레이션 마인드셋.

몇 가지 초기 교훈이 두드러지는데, 그것은 AIDD가 실제로 어떻게 보이는지, 그리고 왜 개발자 경험이 그 어느 때보다 중요한지를 보여주기 때문이다.

• 실행하고 데이터를 확인해야 한다. 몬테카를로 시뮬레이션의 "헬로 월드"인 술취한 선원을 기억하는가? 어느 시점에서 옥토배치를 통해 시뮬레이션을 실행했을 때 77.5%의 선원이 물에 빠지는 것을 나는 알아챘다. 무작위 보행의 결과는 50/50이어야 하므로 분명히 무언가 잘못되었다. 문제는 무작위 수 생성기가 순차적 시드 값으로 매 반복마다 다시 시드되어 실행 간에 상관관계 편향을 만들어냈다는 것이 밝혀졌다.

나는 즉시 문제를 식별하지 못했다. 클로드 코드를 테스트 러너로 사용하여 각 테스트를 생성하고 실행하고 결과를 로그하는 테스트를 여러 번 실행했다. 제미니가 결과를 보고 근본 원인을 찾았다. 클로드는 잘 작동하는 수정을 생각해내는 데 어려움을 겪었고, 파이프라인에 미리 시드된 무작위 수 값의 큰 목록이 있는 해결책을 제안했다. 제미니는 클로드와의 대화를 검토하여 해시 기반 수정을 제안했지만, 지나치게 복잡해 보였다. 문제를 이해하고 그들의 제안된 해결책을 거부한 후, 나는 최선의 수정이 두 AI의 제안보다 간단하다고 결정했다. 시뮬레이션 단위당 자연스럽게 그 순서를 통해 진행하는 지속적인 RNG. 나는 그 세 가지 옵션을 평가하기 위해 통계와 코드를 모두 이해해야 했다. 그럴듯해 보이는 출력과 올바른 출력은 같은 것이 아니며, 차이를 알 수 있는 전문 지식이 필요하다. (이 상황에 대해서는 시리즈의 다음 글에서 더 이야기하겠다.)

• LLM은 종종 복잡성을 과대평가한다. 어느 시점에서 분석 파이프라인에서 사용자 정의 수학 표현에 대한 지원을 추가하고 싶었다. 클로드와 제미니 모두 반대하며 말했다. "이것은 v1.0에 대한 범위 확장(scope creep)입니다" 그리고 "v1.1을 위해 아껴두세요." 클로드는 구현하는 데 3시간이 걸릴 것으로 추정했다. 코드베이스를 알고 있었기 때문에, 우리가 이미 asteval을 사용하고 있다는 것을 알고 있었다. asteval은 수학 표현과 간단한 파이썬 문을 위한 안전하고 미니멀리스틱한 평가기를 제공하는 파이썬 라이브러리로, 다른 곳에서 표현을 평가하기 위해 사용하고 있었다. 그래서 이것은 우리가 이미 다른 곳에서 사용하고 있는 라이브러리의 간단한 사용처럼 보였다. 두 LLM 모두 해결책이 실제보다 훨씬 복잡하고 시간이 많이 걸릴 것이라고 생각했다. 그것은 클로드 코드(클로드가 생성한)에 대한 두 번의 프롬프트와 구현에 총 약 5분이 걸렸다. 그 기능은 배포되어 도구를 훨씬 더 강력하게 만들었다. AI는 시스템의 아키텍처에 대한 내 문맥이 없었기 때문에 보수적이었다. 경험은 통합이 사소할 것이라고 말했다. 그 경험이 없었다면, 나는 그들을 듣고 5분 걸리는 기능을 연기했을 것이다.

• AI는 종종 코드를 추가하는 쪽으로 편향되어 있고, 삭제하는 쪽으로는 그렇지 않다. 생성적 AI는 놀랍게도 생성에 편향되어 있다. 그래서 내가 LLM에게 문제를 수정하도록 요청했을 때, 그들의 첫 번째 반응은 종종 코드를 더 추가하는 것이었다. 또 다른 층이나 또 다른 특수 경우를 추가하는 것. 전체 프로젝트에서 AI 중 하나가 물러서서 "이것을 뜯어내고 접근 방식을 다시 생각하라"고 말한 단 한 번도 생각나지 않는다. 가장 생산적인 세션은 내가 그 본능을 무시하고 단순함을 추구한 세션이었다. 이것은 경험 많은 개발자가 경력에 걸쳐 배우는 것이다. 가장 성공적인 변경은 종종 추가하는 것보다 더 많이 삭제한다. 우리가 자랑스러워하는 PR은 수천 줄의 코드를 삭제하는 PR이다.

• 아키텍처는 장애에서 나타났다. AI 도구와 나는 옥토배치의 핵심 아키텍처를 사전에 설계하지 않았다. 우리의 첫 번째 시도는 메모리 내 상태와 많은 희망을 가진 파이썬 스크립트였다. 작은 배치에서는 작동했지만 규모에서 무너졌다. 네트워크 문제는 처음부터 다시 시작하는 것을 의미했고, 잘못된 형식의 응답은 수동 분류가 필요했다. 시스템이 언제든 죽여도 살아남아야 한다는 제약 조건을 추가한 후 많은 것이 제자리에 들어왔다. 그 단일 요구 사항이 틱 모델(깨어나고, 상태를 확인하고, 작업하고, 지속하고, 종료), 진실의 원천으로서의 매니페스트 파일, 전체 충돌 복구 아키텍처로 이어졌다. 우리는 더 간단한 것을 하지 못하는 것을 반복하면서 설계를 발견했다.

• 개발 이력은 데이터셋이다. 나는 방금 옥토배치 프로젝트의 몇 가지 이야기를 들려주었고, 이 시리즈는 그것들로 가득 차 있을 것이다. 그 이야기의 모든 하나하나는 나, 클로드, 제미니 사이의 채팅 로그를 다시 검토하면서 나왔다. AIDD를 사용하면 모든 아키텍처 결정, 모든 잘못된 길, AI를 무시한 모든 순간과 AI가 당신을 수정한 모든 순간에 대한 완전한 기록이 있다. 매우 적은 개발 팀이 프로젝트 역사에서 그 수준의 충실도를 가진 적이 있다. 배운 교훈을 위해 그 로그를 채굴하는 것은 내가 찾은 가장 가치 있는 실천 방식 중 하나로 밝혀졌다.

프로젝트 말미에, 나는 이것이 클로드 코드에 특정한 것이 아닌지 확인하기 위해 커서로 전환했다. 개발 전반에 걸쳐 유지하던 동일한 문맥 파일을 사용하여 새로운 대화를 만들었고, 즉시 생산적인 세션을 부트스트랩할 수 있었다. 문맥 파일은 설계된 대로 정확히 작동했다. 내가 개발한 실천 방식은 다른 도구로 깨끗하게 이전되었다. 이 접근법의 가치는 습관, 문맥 관리, 그리고 대화에 가져오는 엔지니어링 판단에서 오며, 특정 제공자에서 오지 않는다.

이 도구는 엔지니어링이 어떻게 잘못될 수 있는지 이해하고 견고한 설계와 아키텍처 패턴을 알고, 그리고 코드의 모든 줄에 대한 통제를 놓아도 괜찮은 개발자에게 유리한 방향으로 세계를 움직이고 있다.

다음은 무엇인가

에이전트 엔지니어링은 구조가 필요하고, 구조는 그것을 실재하게 만드는 구체적인 사례가 필요하다. 이 시리즈의 다음 글은 옥토배치 자체를 다룬다. AI를 조정하는 방식이 AIDD가 개발자에게 하도록 요청하는 것과 놀랍도록 가까운 평행선이기 때문이다. 옥토배치는 다른 처리 단계에 역할을 할당하고, 그들 사이의 핸드오프를 관리하며, 그들의 출력을 검증하고, 그들이 실패할 때 복구한다. 그것은 그것을 만들 때 내가 따랐던 동일한 패턴이다. 클로드와 제미니에 역할을 할당하고, 그들 사이의 핸드오프를 관리하며, 그들의 출력을 검증하고, 그들이 잘못된 길로 갈 때 복구하는 것.

시스템이 어떻게 작동하는지 이해하는 것은 AI 주도 개발을 어떻게 조정하는지 이해하는 좋은 방법으로 밝혀진다. 아키텍처를 살펴보고, 프롬프트에서 결과까지 실제 파이프라인이 어떻게 보이는지 보여주고, 이 모든 아이디어를 테스트하는 300핸드 블랙잭 몬테카를로 시뮬레이션의 데이터를 제시하고, 그 모든 것을 사용하여 에이전트 엔지니어링과 AI 주도 개발에 직접 적용할 수 있는 아이디어를 보여줄 것이다.

이후의 글은 이 실험에서 배운 실천 방식과 아이디어를 더 깊이 탐구한다. 아키텍처에 대한 통제를 잃지 않고 여러 AI 모델을 어떻게 조정했는지, 내가 실제로 만들려고 했던 것에 대해 코드를 테스트했을 때 무슨 일이 일어났는지, 그리고 실행되는 코드와 의도한 것을 수행하는 코드 사이의 격차에 대해 배운 것.

그 과정에서, 실험은 내가 예상하지 못했던—그리고 내가 생각했던 것보다 더 중요한 것으로 밝혀진—다른 AI 모델이 코드를 보는 방식에 대한 몇 가지 발견을 만들어냈다.

게시 주제: AI & ML 게시 태그: