프로덕션 수준의 에이전트 그래프 엔지니어링: 에이전트 시스템을 시작하는 사람들에게 해주고 싶은 조언

다들 안녕. 난 지난 5년 동안 실시간 AI 어시스턴트를 만들면서 살았어. 처음엔 금융 쪽에서 시작했다가 나중엔 플랫폼 형태로 바꿨는데, 지금 다시 만든다면 예전이랑은 완전히 다르게 만들 것 같아. 뼈저리게 깨달은, 다르게 할 4가지 포인트를 공유할게.

흐름을 눈으로 볼 수 있게 만들어라. 초기 시스템은 인텐트 분류기가 중첩된 조건문을 타는 구조였어. 작동은 잘 됐는데 진짜 끔찍했지. 흐름이 코드랑 내 머릿속, 그리고 일주일 만에 구닥다리가 된 다이어그램에 흩어져 있었거든. 뭐 하나 고치려면 무조건 나를 거쳐야 했고, 신입 교육하는 데만 한 달이 걸렸어. 시스템이 특정 메시지에 어떻게 반응할지 자신 있게 말할 수 있는 사람도 아무도 없었지. 흐름을 시각화해서 바로 가리킬 수 있게 된 게 모델 업그레이드보다 훨씬 더 큰 변화를 가져왔어.

사람의 승인을 나중 기능이 아니라 시작부터 전제로 깔아라. 예전에 나중에 추가하려고 시도해 봤는데, 시스템 전체랑 싸우게 되더라. 시스템이 '시작하면 끝까지 달린다'는 가정하에 만들어졌거든. 처음부터 '실행 중에 사람이 개입할 수 있다'고 가정하면 비용은 거의 안 들어. 근데 안 된다고 가정하면, 결국 기존 시스템 옆에 두 번째 시스템을 새로 짜야 하는 꼴이 돼.

모델 선택이 코드 전반에 퍼지게 두지 마라. 내 코드는 모델 이름이 여기저기 박혀 있어서, 공급업체 하나 바꾸는 데만 일주일이 걸렸어. 게다가 싼 모델 쓰려던 게 설정 실수로 비싼 모델로 돌아가고 있었는데, 청구서 보고 나서야 알았지. 각 단계가 뭘 하는지, 어떤 모델을 쓸지 딱 한 곳에서 결정하는 작은 습관이 나중에 큰돈을 아껴줘.

모델이 틀렸을 때 어떻게 할지 출시 전에 정해라. 출시하고 나서 정하지 말고. 모델은 무조건 틀려. 문제는 그 주변 시스템이 그걸 대비해서 설계됐느냐, 아니면 운영 중에 터지고 나서야 알게 되느냐지. 난 둘 다 해봤는데, 미리 대비하는 게 무조건 답이야.

이거 다 별거 아닌 것 같지? 근데 이게 그냥 데모 수준이랑 팀에 넘겨줄 수 있는 수준의 차이야. 내가 직접 겪은 시행착오를 포함해서, 모든 결정 과정을 담은 전체 레퍼런스를 공개했어.

이런 사람들이 보면 도움 될 거야:

• 수정하기 너무 빡세진 시스템을 유지보수하는 사람: 왜 그렇게 됐는지에 대한 이야기가 내가 제일 먼저 쓴 내용이야.

• 아직 화이트보드 앞에서 고민 중인 사람: 지금은 사소해 보여도 1년 뒤엔 엄청난 비용이 될 결정들이거든.

• "LLM API 호출해 봤다" 수준을 넘어서 취업용 포트폴리오를 만들고 싶은 사람: 채용 공고에서 요구하는 게 바로 이런 구조야.

• 클라이언트를 위해 제품을 출시하는 사람: 유지보수가 가능한 구조로 만들어서 넘겨줄 수 있어.

프로젝트랑 관련 시리즈는 아래 댓글에 달아둘게. 스크립트 기반 모델이랑 실제 공급업체 모델 둘 다 돌아가니까, 뭘 연결하기 전에 전체 흐름을 미리 다 볼 수 있어. 일단 두 파트만 먼저 올렸고 며칠 간격으로 계속 올릴 거니까, 지금 피드백 주면 남은 부분에 반영할게 😄