AI 엔지니어링 에피소드 5편에서 얻은 배포(Shipping) 관행

데모는 저렴합니다. '배포한다(Shipping)'는 것은 당신이 검토한 것, 설계한 것, 측정했던 것을 말할 수 있고, 모델이 잘못되었을 때 누가 운영 책임을 지는지 명확히 할 수 있다는 의미입니다. 이 다섯 편의 에피소드는 이미 데모를 가지고 있고 실질적인 경험이 필요한 빌더에게 건네주고 싶은 세트입니다. 모든 에피소드의 스크립트와 챕터는 Chain of Thought episodes page에서 확인할 수 있습니다.

에이전트가 코드를 작성할 때 무엇을 검토해야 할까요?

Anush Elangovan은 AMD의 AI 소프트웨어 부사장으로서, AI가 코드 대부분을 작성하는 규모에서의 에이전트 우선 워크플로우를 설명합니다. 그는 10~12개의 Claude Code 에이전트를 병렬로 실행하고, 매주 65억 토큰을 소모하며, 25년 된 Slurm 대체 프로그램을 하룻밤 사이에 Rust로 재작성했습니다. 그는 일반적인 SDLC(Software Development Life Cycle)는 끝났다고 주장합니다. 그는 테스트를 새로운 코드 검토 방식으로 취급합니다. 나머지 내용은 한 문장으로 요약할 수 있습니다. 즉, 소프트웨어란 그저 토큰일 뿐입니다. 저는 이 테스트에 대한 주장을 운영 규칙으로 삼고 싶습니다. 그렇게 많은 코드가 기계적으로 작성되면, 모든 diff(차이점)를 읽는 것은 따라잡기 어렵습니다. 허용할 동작을 명시하는 테스트를 작성하고, 이를 게이트로 실행하며, 검토 시간을 그 테스트들에 할애해야 합니다. 하룻밤 사이에 재작성한 사례는 오래된 검토 프로세스가 준비되기 전에 토큰이 먼저 나타난다는 것을 상기시켜 줍니다. 소프트웨어를 토큰으로 취급하는 것은 여전히 통과하는 테스트의 정의를 소유하고 있을 때만 유효합니다.

모델을 선택하기 전에 무엇을 설계해야 할까요?

모델을 선택하기 전에 무엇을 설계해야 할까요?

Fireworks AI의 Head of AI Developer Relations인 Aishwarya Srinivasan은 대부분의 AI 에이전트가 시스템 아키텍처 대신 모델부터 역방향으로 구축된다고 주장합니다. 그녀가 설명하는 변화는 모델을 선택하는 것에서 시스템을 설계하는 것으로, 프롬프트 엔지니어링(prompt engineering)에서 컨텍스트 엔지니어링(context engineering)으로의 전환입니다. 그녀의 경험에 따르면, 프로덕션 에이전트는 여러 모델, 메모리 시스템, 도구 호출(tool calls)의 세심한 오케스트레이션과 평가 기반 개발(evaluation-driven development)을 필요로 합니다. 벤치마크만으로는 충분하지 않습니다. 그녀는 또한 자율성(autonomy)에 대한 인간 개입 루프(human-in-the-loop control), LLM-as-judge 검사, DeepSeek v3와 같은 오픈 소스 모델, 그리고 규제 환경에서의 컴플라이언스(compliance)에 대해서도 다룹니다. 제가 모델 이름을 붙이기 전에, 에이전트가 받는 컨텍스트, 호출할 수 있는 도구, 유지되는 메모리, 그리고 빌드를 실패시키는 평가를 문서로 작성합니다. 잘못된 행동을 되돌리는 비용이 많이 드는 곳에서는 사람이 루프 안에 머무릅니다. 이미 지정한 시스템 내부에서 모델은 교체될 수 있습니다.

'느낌 확인(vibe check)'부터 배포된 기능까지 어떻게 나아갈까요?

Vercel의 CTO인 Malte Ubl은 에이전트를 유연한 작업을 해결하기 위한 새로운 유형의 소프트웨어로 설명합니다. 이 에피소드는 데모와 배포된 기능 사이의 엔지니어링에 관한 것입니다. 그는 AI SDK와 AI Gateway를 포함하여 Vercel의 개발자 우선 스택을, 빠른 개념 증명(proof of concept)에서 신뢰할 수 있는 프로덕션 준비 애플리케이션으로 이동하는 방법으로 제시합니다. 저는 팀에게 다음과 같은 순서를 지킬 것을 요구할 것입니다. 사용자가 인식할 수 있는 문장 하나로 유연한 작업을 명명하십시오. 배포 환경에서 실행하려는 개발자 표면(developer surface) 위에서 개념 증명을 구축하십시오. 이는 그가 SDK와 게이트웨이에 부여하는 역할입니다. 이 결과를, 나머지 제품을 신뢰하는 것처럼 신뢰할 때 '배포된 것'으로 간주하십시오. 느낌 확인은 작업이 실제 사용자들을 견뎌내야 할 때 끝납니다.

메트릭을 신뢰하기 전에 무엇을 살펴봐야 할까요?

Parlance Labs의 Hamel Husain은 그가 보통 받는 첫 번째 질문이 어떤 도구를 사용할 것인지이며, 그것이 잘못된 질문이라고 말합니다. 이 에피소드는 신뢰할 수 있는 AI를 배포하는 엔지니어와 메트릭을 쫓는 엔지니어를 구분하는 사고방식에 관한 것입니다. 그는 허세 가득한 대시보드(vanity dashboards)와 다양한 메트릭의 집합이 잘못된 안정감을 조성하며, 이것은 도메인별 위험에 맞춰진 맞춤형 평가(evals)를 대체할 수 없다고 주장합니다. 그가 설명하는 원칙은 오류 분석(error analysis)입니다. 즉, 데이터를 직접 살펴보고, 실제 세계에서의 실패 사례를 찾고, 로그에서 정성적인 메모를 작성한 다음, 그 메모를 양적인 가드레일로 전환하는 것입니다. 이것이 그가 프로토타입을 프로덕션으로 가져가는 과정과 연결 짓는 실험 주기(experimentation loop)입니다. 저는 우리 자신의 로그에서 읽은 실패 사례를 지적할 수 있을 때까지 메트릭을 추가하지 않을 것입니다. 첫 번째 결과물은 도메인별 실패 목록이 짧게 나열된 것으로, 각각 예시와 해당 실패가 발생했을 때 실패하는 평가(eval)를 포함합니다. 도구는 기다릴 수 있습니다.

AI는 엔지니어링 팀에게 무엇을 남길까요?

Honeycomb의 공동 창업자이자 CTO이며 charity.wtf의 주역인 Charity Majors는 자신의 기사

• 테스트가 포함된 게이트 에이전트 작성 코드. Anush Elangovan은 일반적인 SDLC(Software Development Life Cycle)를 죽었다고 여기며 테스트를 새로운 코드 리뷰로 간주합니다.
• 모델에 커밋하기 전에 컨텍스트, 도구, 메모리, 평가 지표(evals)를 명시하세요. Aishwarya Srinivasan은 벤치마크만으로는 충분하지 않을 것이라고 경고합니다.
• '느낌 확인'(vibe check)에서 배포된 기능으로 이어지는 경로를 Malte Ubl이 설명하듯이, 유연한 작업을 개념 증명(proof of concept) 단계에서 유지할 스택의 신뢰할 수 있는 프로덕션 앱까지 가져가세요.
• 대시보드만 보고 믿지 말고 실제 실패 사례를 읽으세요. Hamel Husain은 다양한 지표들의 향연이 잘못된 안정감을 준다고 말합니다.
• 생성형 AI가 당신을 위해 구축해 주지 않을 것이라는 가정하에 팀을 관리하고 이끌어가세요. Charity Majors는 이러한 한계를 프로덕션 신뢰성과 가장 어려운 엔지니어링 문제와 연결시킵니다.

이 주제에 대한 더 많은 내용과 관련 에피소드는 Chain of Thought에서 확인할 수 있습니다. 이 링크는 이 에피소드를 참고했습니다.

에피소드 스크립트를 기반으로 AI의 도움을 받아 초안 작성됨.