AI 자동화에서 진짜 어려운 것은 모델이 아니라 운영 구조다

AI를 여러 개 쓰기 시작하면 문제는 모델 성능보다 운영 구조로 옮겨간다.결과물이 어디에 쌓이고, 무엇이 정본이며, 누가 검증하는지가 정해져야 작업이 누적된다.이번 작업은 AI 런타임을 하나 더 만드는 일이 아니라, 반복 가능한 운영 spine을 만드는 일이었다.최근에 AI 에이전트 운영 구조를 다시 정리하는 작업을 했다.처음에는 특정 런타임 설계안을 검토하는 수준으로 시작했다. 하지만 실제로 내용을 뜯어보니 문제의 초점은 특정 에이전트가 아니었다. 더 큰 문제는 여러 AI 런타임이 같은 작업 환경을 공유할 때 생기는 운영 혼선이었다.Codex, Hermes, Claude, Copilot, Gemini 같은 도구를 함께 쓰면 각 도구는 나름의 결과물을 만든다. 그런데 그 결과물이 서로 다른 폴더에 쌓이고..

커스텀 에이전트를 만들며 배운 것들 – Part 10. 이 연재를 마치며

이 연재를 시작할 때 목표는 하나였다. 실패 과정을 기록하는 것.잘된 것만 쓰면 교훈이 없다. 왜 실패했는지, 어디서 막혔는지, 어떻게 틀렸는지를 쓰는 게 더 유용하다고 생각했다.10편을 마치며 되돌아본다.이 연재에서 말한 것들Part핵심1자동화는 실행이 아니라 판단을 보존하는 것2기능 분리는 연결 비용을 설계 밖으로 밀어낼 뿐3사고 계층 분리가 기능 분리보다 더 근본적인 기준4핸드오프는 데이터 전달이 아니라 판단 전달5에이전트를 늘릴수록 책임을 좁혀야 한다6경계가 없으면 시스템은 커질수록 안에서 무너진다7운영은 설계와 다른 문제다8처음부터 수정하기 쉬운 설계가 처음부터 완벽한 설계보다 낫다9구조가 스스로를 설명해야 한다아직 모르는 것들다음 세대 모델들이 나올수록 지금 이 설계가 얼마나 유효할지 모른다...

커스텀 에이전트를 만들며 배운 것들 – Part 9. 구조가 남고, 사람이 바뀌어도 돌아가게 되기까지

혼자 만든 시스템이 혼자만 운영할 수 있는 시스템이 된다면, 그건 자동화가 아니다.에이전트 시스템이 진짜 가치를 갖는 순간은, 만든 사람 없이도 작동할 때다.혼자만 아는 시스템의 문제시스템을 처음 만들면 모든 게 머릿속에 있다. 왜 이렇게 설계했는지, 어디서 주의해야 하는지, 어떤 상황에서 뭔가 이상한지.그런데 그 지식은 코드에 없다. 설정 파일에도 없다. 어디에도 없다.두 달 뒤 내가 다시 봐도 낯설다. 다른 사람이 보면 이해할 수 없다.구조가 스스로를 설명하게 만들기이 문제를 해결하려고 세 가지를 했다.에이전트마다 의도 문서 작성"이 에이전트는 무엇을 한다"가 아니라 "이 에이전트는 왜 이렇게 설계됐는가"를 기록했다. 결정의 근거, 고려했다 버린 선택지, 주의해야 할 엣지 케이스.변경 로그 구조화에이..

커스텀 에이전트를 만들며 배운 것들 – Part 8. 지금 다시 만든다면, 무엇을 다르게 할까

이 시스템을 처음부터 다시 만들 기회가 생긴다면, 뭘 다르게 할까.이 질문을 진지하게 생각해봤다. 아는 것들을 처음부터 알고 시작한다면.먼저 했을 것들자동화 범위를 먼저 정의했을 것이다처음에 "무엇을 자동화할 수 있는가"를 먼저 물었다. 다시 만든다면 "무엇을 자동화하지 않을 것인가"를 먼저 물었을 것이다.자동화의 범위를 정하는 건 포함할 것을 고르는 게 아니라 제외할 것을 고르는 일이다.운영을 설계에 포함했을 것이다설계를 완성하고 나서 운영을 생각했다. 다시 한다면, 운영 방식을 설계 단계에서 함께 정의했을 것이다.모니터링은 어떻게 할 것인가. 언제 사람이 개입할 것인가. 어떻게 업데이트할 것인가.판단 레이어를 첫 번째로 만들었을 것이다실행 에이전트들을 먼저 만들고 나중에 판단 레이어를 끼워 넣으려 했..

최근 게시글

티스토리툴바