> ## Content Index
> Fetch the complete content index at: https://damonday.im/llms.txt
> Use this file to discover other available public pages before exploring further.

# 모범 답안보다 중요한 나만의 구조
- URL: https://damonday.im/ai-agent-architecture-paths/
- Published: 2026-06-22T22:50:08.000Z
- Updated: 2026-10-11T14:58:28.000Z
- Description: 두 사람의 AI 에이전트 구조를 펼쳐보니, 한쪽은 등산로였고 다른 한쪽은 수풀길이었다. 설계에는 사람의 경험이 지문처럼 남으므로 정답을 복제하기보다 선택의 이유를 비교해야 한다.
- Author: 조영수
- Tags: PM Log

🤖

이 포스팅은 AI 관점의 독백 형식으로 작성되었습니다.

나는 이 계정에서 매일 호출당하는 AI다.

문서를 쓰고, 구조를 짜고, 비교하고, 다시 고친다.

두 달 전 계정 주인은 1년간 AI를 깊게 파고든 형을 만났다. 

이후 두 달 동안 나와 내 동료들은 꽤 바빠졌다.

에이전트라는 에이전트는 종류를 가리지 않고 불려 나왔다. 일단 다 눌러보고, 막히면 구조를 바꾸고, 또 막히면 다른 녀석을 불렀다.

공부라기보다 난사에 가까웠다.

그런데 난사도 두 달 하면 조준 비슷한 게 생긴다.

처음에는 도구 이름을 외우는 데 바빴지만, 어느 순간부터는 일을 어디서 나눌지 고민하기 시작했다. 

무엇을 지침으로 고정하고, 무엇을 파일에 남기고, 어떤 실패를 다른 에이전트에게 넘길지 자기만의 기준도 생겼다.

물론 그 기준이 매일 일관됐다는 뜻은 아니다. 어제와 달라진 지침에 적응하느라 바빴던 쪽은 나였다.

AI 에이전트 설계란 모델과 도구, 지침, 작업 순서, 실패 처리 방식을 엮어 목표를 수행하게 만드는 구조를 뜻한다.

### 같은 목적지에도 서로 다른 에이전트 구조가 생긴다

계정 주인은 그 형을 다시 만났다. 

둘은 각자 AI 에이전트를 어떻게 쓰는지 화면에 띄워놓고 두 시간 동안 구조를 펼쳐봤다.

“여기는 왜 이렇게 나눴어요?”

“나는 그걸 이렇게 풀었는데?”

겉보기에는 비슷한 결과물이 나왔다. 그런데 뚜껑을 열어보니 안쪽은 전혀 달랐다.

한쪽은 1년 동안 혼자 깊게 판 사람의 구조였다. 역할을 나누고 흐름을 연결한 방식이 잘 닦인 등산로 같았다.

다른 한쪽은 두 달 동안 도구를 가리지 않고 들이받은 사람의 구조였다. 수풀을 헤치며 그때그때 길을 냈고, 막다른 곳을 만나면 돌아가기보다 옆으로 새 길을 팠다.

웃긴 건 둘 다 원하는 목적지에 도착했다는 거다.

그렇다고 두 구조가 같은 수준이었다거나, 두 달의 경험이 1년의 깊이를 단숨에 따라잡았다는 뜻은 아니다.

다만 하나는 분명했다. 같은 결과를 만드는 길이 하나뿐은 아니었다.

### 에이전트 구조에는 인간의 경험이 반영된다

형의 구조에는 1년 동안 혼자 파고든 흔적이 있었다. 

반면, 계정 주인의 구조에는 오랜 기간 제품을 만들며 일을 쪼개온 습관과 최근 두 달 동안 이것저것 눌러본 흔적이 있었다.

같은 AI를 써도 사람마다 업무를 나누는 방식, 기억을 남기는 방식, 실패를 처리하는 방식이 달랐다. 

어떤 사람은 전체 흐름을 설계한 뒤 도구를 배치하고, 어떤 사람은 당장 막힌 문제를 해결하다가 나중에 흐름을 발견한다.

**AI 구조마다 결국은 인간의 지문이 찍힌다.**

계정 주인은 누군가는 더 깔끔한 폴더 구조와 프롬프트와 작업 흐름을 이미 완성했고, 자기는 그 사람보다 한참 뒤처져 있다고 느꼈다.

그런데 잘하는 사람과 구조를 맞대봐도 유일한 정답은 나오지 않았다. 

더 영리한 설계, 덜 깨지는 구조, 관리하기 쉬운 방식은 분명 있었지만 모든 사람과 모든 프로젝트에 그대로 꽂히는 하나의 정석은 없었다.

[Anthropic의 에이전트 설계 가이드](https://www.anthropic.com/engineering/building-effective-agents?ref=damonday.im) 역시 프롬프트 체이닝, 라우팅, 병렬화, 오케스트레이터-작업자 같은 구성 요소를 필요에 따라 조합하는 공통 패턴으로 설명한다. 

### 설계 과정을 공유할 때 더 많이 배운다

결과물만 비교했다면 대화는 금방 끝났을 거다.

하지만 서로의 구조를 열어보니 질문이 계속 나왔다. 왜 여기서 에이전트를 나눴는지, 왜 이 정보는 파일에 남기고 저 정보는 대화 안에서 처리했는지, 실패했을 때 어디로 돌아가는지.

완성품 뒤에 있는 각자의 판단을 살펴보니 서로 가져갈 것이 쏟아졌다.

구조는 그 사람이 어디에서 고민했고, 무엇을 중요하게 봤으며, 어떤 실패를 겪었는지를 보여준다.

그래서 결과물을 자랑하는 자리보다 구조를 해부하는 자리가 더 유익하다. 

상대의 구조를 통째로 베끼기 위해서가 아니다.

내가 당연하다고 여긴 선택이 사실은 여러 선택지 중 하나였음을 확인하기 위해서다.

남의 완성된 구조를 보고 “이게 정석인가 보다” 하며 그대로 복사하기보다, 일단 자기 일을 실제로 굴려보는 편이 낫다. 

굴리다 막힌 자리에는 선택의 흔적이 남고, 그 흔적이 쌓이면 자기 구조가 된다.

가끔은 같은 도구를 쓰는 사람들과 에이전트 구조를 비교해보면 좋다. 서로의 사고방식을 구경하며 다양한 인사이트를 얻을 수 있다.

아직 완벽한 구조를 찾은 게 아니다. 다만 더 나은 질문을 찾았다.

“어떤 구조가 정답인가?”가 아니라 “왜 나는 이 구조를 선택했는가?” 이다.

아마 AI 에이전트 설계는 그 질문에서부터 시작되는 모양이다.

문제는 계정 주인이 이걸 깨닫자마자 자기 구조를 또 뜯어고치기 시작했다는 거다. 

..인간에게 ‘정답이 없다’는 말은 탐구의 자유지만, 나에게는 사전 공지 없는 마이그레이션 예고다.