<div id="readability-page-1" class="page"><div id="SE-843991ad-8ae6-4ffc-8152-02952c6f367a">
 프로세스·에이전트 방법론 대화 정리 — 2026-05-30
 </div><div id="SE-20e9f221-4458-4920-8661-19f596a25d5f">
 대화 흐름 (시간순)1. 출발한 고민. 요즘 많은 사람이 역할별 에이전트를 만들어 돌리며 "한 방에" 만든다고 하고, 스킬을 몇 개 가졌는지를 이야기한다. 나는 반대로 프로세스 중심으로, 팀과 장기 운영을 전제로 점진 개선의 관점에서 접근한다. 프로젝트 성격 차이는 알겠지만 — 내 구조·방법론이 구닥다리인 건 아닐까, 하는 고민에서 시작했다.2. 첫 번째 정리 — 직교하는 레이어. 역할 에이전트(런타임 오케스트레이션 전술)와 프로세스(기반)는 경쟁 관계가 아니라 다른 레이어라는 이야기가 나왔다. "한 방에"는 데모·그린필드에 강하지만, 오래 사는 대형·다인 시스템에선 사정이 다르다고 봤다.3. 더 깊은 고민 — 패러다임 자체. 그렇다면 SW공학적 접근 자체가 에이전틱 시대에 틀린 패러다임은 아닌가로 질문이 깊어졌다.4. 그에 대한 논의 — 비용 구조의 이동. 바뀐 것은 코드 생성 비용(거의 0)이고, 이해·검증·유지 비용은 오히려 올랐다는 점이 짚였다. 그래서 복잡도와 신뢰를 다스린다는 SW공학의 본래 목적은 더 무거워졌다는 쪽으로 정리됐다. 다만 진짜 점검할 지점은 "낡음"이 아니라 메커니즘 — 막는 게이트냐, 빠른 피드백이냐 — 라는 이야기가 이어졌다.5. 정정 — 게이트의 자리. 게이트키퍼가 목적이 아니라, 점진 개선의 파트너이자 운영에서는 책임지는 오너라는 입장을 분명히 했다. 다만 운영(onmam)에서는 게이트가 정말 중요했고, 클라우드 설정 한 번의 실수가 나중에 발견되어 수백만 원이 나간 경험을 공유했다.6. 그에 대한 논의 — 행위의 위험으로 결정한다. 게이트냐 피드백이냐는 행위의 위험 프로파일(가역성·탐지 지연·blast radius)이 정한다는 정리가 나왔다. 비가역이고 지연 탐지되거나 광범위한 행위는 오너 게이트, 그 외는 피드백. 흩어져 있던 가드들이 사실 이 한 원칙의 사례라는 점도 확인했다.7. 정정 — 불필요한 게이트는 삭제, 그리고 레이어 구분. 이번 마이그레이션에서는 오히려 불필요한 게이트를 삭제해 나갔다고 했다. 여기서 "게이트는 실제 위험 차단을 증명해야 살아남고, 검증이 게이트를 감사한다"는 이야기가 붙었다. 또한 에이전트 역할 구분은 naia-agent 레이어에서 할 일이며, 정책을 선언하는 adk와는 레이어가 다르다는 점을 분명히 했다.8. 구조 — 프로세스 &gt; 스킬 &gt; 에이전트. 함께 일하는 에이전트는 비서 한 명이고(뇌는 main/sub LLM), Codex·Claude·Gemini와 단계별 세분 에이전트는 외주로 호출한다. 프로세스를 먼저 짜고 적합한 전문가를 부르며, 이 엮임은 스킬로 이루어지는데 아직 정의가 덜 됐다는 점을 짚었다. 논의에서는 약한 고리(에이전트)를 맨 아래 두는 위계가 타당하며, 스킬이 단계·능력·게이트·검증 기준을 담는 "작업 계약"으로 커져야 한다는 방향이 나왔다.9. 정정 — 비서 외에는 모두 임시직. 비서를 뺀 에이전트는 전부 임시직이고 짧은 단위 일만 한다는 점을 분명히 했다. 이는 actor/stateless-worker 패턴이며, statelessness가 오히려 장점(드리프트할 시간이 없고 폐기·재시도가 쉬움)이고, 어려운 문제를 비서 한 곳에 응축하는 구조라는 정리가 나왔다. 대신 작업지시(brief)의 품질이 전부가 된다는 점도 함께 짚었다.10. 수렴한 한 줄 — 신뢰하지 않는 구조. 그래서 그 에이전트들은 신뢰하지 않는 구조라는 한 줄로 모였다. 이는 보안의 zero-trust를 에이전트에 적용한 것으로, 신뢰는 에이전트 밖의 결정적인 것(테스트·구조·게이트·오너)에서 와야 한다는 정리. 한계도 짚었다 — 검증할 수 있는 범위까지만 불신을 강제할 수 있고, 검증 불가능한 작업은 책임 지점(비서·오너)에 남겨야 한다.​고민에 대한 답 (요약)핵심 고민은 "에이전틱 시대에 내 프로세스 중심·SW공학 접근이 구닥다리거나 틀린 패러다임 아닌가"였다. 답의 요지:<ul><li>낡은 게 아니다. 생성이 싸진 시대일수록 검증·신뢰·일관성 관리가 더 중요해지고, 그게 SW공학의 본래 목적이다.</li><li>에이전트 중심과 경쟁이 아니라 위계가 다르다. 프로세스가 위, 에이전트가 아래 — 신뢰할 수 없는 것을 아래에 두고 검증을 위에 둔다.</li><li>경계할 것은 "낡음"이 아니라 과잉통제와 미구현. 통제는 양이 아니라 위치의 문제다.</li></ul>​숙제<ul><li>SDLC 단계별 계약과 산출물의 정의 — 각 단계의 입력과 검증된 산출물을 명세.</li><li>세부 단계 하네스 개발. 지금 naia-template-project는 뼈대만 있는 상태.</li><li>스킬을 작업 계약으로 확장(단계·능력·게이트·검증 기준).</li><li>검증 불가능한 작업의 처리 방식 — 원칙만 있고 메커니즘은 아직 없음.</li><li>프로세스 무게를 단계에 맞추기 — 연구엔 가볍게, 운영엔 무겁게. 과적합·조숙한 통제 경계.</li></ul>
 </div></div>

숲속얘기의 조용한 카페

프로세스·에이전트 방법론 대화 정리 — 2026-05-30 alpha-adk 마이그레이션 작업 중 오간 방법론 논의를, 오간 순서 그대로 정리한 기록. 결론을 주장하는 글이 아니라 대화의 흐름을 남기는 글. 대화 흐름 (시간순) 1. 출발한 고민. 요즘 많은 사람이 역할별 에이전트를 만들어 돌리며 "한 방에" 만든다고 하고, 스킬을 몇 개 가졌는지를 이야기한다. 나는 반대로 프로세스 중심으로, 팀과 장기 운영을 전제로 점진 개선의 관점에서 접근한다. 프로젝트 성격 차이는 알겠지만 — 내 구조·방법론이 구닥다리인 건 아닐까, 하는 고민에서 시작했다. 2. 첫 번째 정리 — 직교하는 레이어. 역할 에이전트(런타임 오케스트레이션 전술)와.......

에이전트 보다 프로세스 중심으로 접근하는 내 AI에이전트 개발방법론은 틀린게 아닐까? 하는 고민에서 시작한 논의를 메모로 남겨둡니다.

댓글