<div id="readability-page-1" class="page"><div><p><img src="https://devstarsj.github.io/assets/https://images.unsplash.com/photo-1518432031352-d6fc5c10da5a?w=1200&amp;q=80"></p><h2 id="어떤-경험">어떤 경험</h2><p>지난 두 달 가까이 B2B 트레이딩 시스템 개선 프로젝트를 진행했다. 이 프로젝트의 특징은 일이 항상 <strong>고객사의 메일</strong>로 시작된다는 것이었다.</p><p>처음의 워크플로우는 이랬다.</p><ol><li>고객이 메일을 보낸다.</li><li>메일 본문을 Claude Code(이하 CC) 세션에 붙여넣는다. CC가 “이런 요구사항이고, 이걸 확인해 달라는 요청입니다”라고 해석해 준다.</li><li>내가 지시를 얹는다 — “이건 A repo에서 처리해야 하고, 이건 B repo 소관이고, 저 데이터는 이 DB의 이 테이블을 봐야 해.”</li><li>작업이 끝나면 “고객에게 답장을 어떻게 쓰면 좋을까?”라고 묻고, 그 초안으로 회신을 보낸다.</li></ol><p>이 사이클을 <strong>같은 CC 세션 안에서</strong> 계속 반복했다. 그런데 몇 주가 지나자 이상한 일이 벌어졌다. 어느 순간부터는 메일 본문을 붙여넣기만 하면:</p><ul><li>알아서 요구사항을 정리하고,</li><li>어느 repo의 어느 코드를 고쳐야 하는지 스스로 찾아서 수정하고,</li><li>배포까지 마친 뒤,</li><li>배포 후 실제로 얼마나 개선됐는지 수치를 뽑아 검증하고,</li><li>고객이 “이것도 확인해 달라”고 덧붙인 항목은 관련 데이터를 조회해서 확인하고,</li><li>마지막으로 회신 메일 초안까지 작성해서,</li></ul><p>몇 시간에 걸친 작업을 통째로 끝낸 결과물을 내놓기 시작했다. 내 역할은 메일을 붙여넣는 것과, 결과를 검토하고 회신 버튼을 누르는 것 정도로 줄었다.</p><h2 id="왜-이게-가능했을까--skill이-아니라-context">왜 이게 가능했을까 — Skill이 아니라 Context</h2><p>처음에는 “스킬을 잘 만들어서”라고 생각할 수도 있는데, 이 세션에는 이 워크플로우를 위한 스킬이나 별도 자동화가 전혀 없었다. 이걸 가능하게 만든 건 두 가지다.</p><p><strong>첫째, 반복이 곧 학습이었다.</strong> 같은 세션에서 사이클을 반복하는 동안, 내가 3번 단계에서 얹어주던 지시들 — repo 구조, 데이터 위치, 테이블 스키마, 배포 절차, 고객의 말투와 관심사 — 이 전부 대화 컨텍스트에 쌓였다. 열 번째 메일이 도착했을 때 세션은 이미 “이 시스템의 요구사항이 어떤 형태로 오고, 어디를 고쳐서, 무엇으로 검증하고, 어떤 톤으로 회신하는지”를 전부 알고 있었다. 별도의 프롬프트 엔지니어링 없이, <strong>앞선 아홉 번의 사이클 자체가 few-shot 예제</strong>가 된 것이다.</p><p><strong>둘째, 핸드오프가 없었다.</strong> 요구사항 해석 → 구현 → 배포 → 검증 → 커뮤니케이션이 보통 조직에서는 서로 다른 사람(기획, 개발, 운영, CS)의 일이고, 단계마다 문서와 회의로 컨텍스트를 넘긴다. 그 전달 과정에서 정보가 깎여 나간다. 이 세션에는 그 손실이 0이었다. 배포를 한 주체가 검증 수치를 뽑았고, 코드를 고친 주체가 회신 메일을 썼다. “얼마나 개선됐는지”를 회신에 쓸 수 있었던 건, 개선 전 상태를 그 주체가 직접 봤기 때문이다.</p><p>정리하면 이 경험의 정체는: <strong>오래 유지된 세션은 온보딩이 끝난 동료가 된다.</strong> 그리고 온보딩된 동료의 가치는 개별 작업 능력이 아니라, 맥락을 이어붙이는 데서 나온다.</p><h2 id="그런데-이건-조직-설계-문제다">그런데 이건 조직 설계 문제다</h2><p>여기서 생각이 옆으로 번졌다.</p><p>예전에는 데이터 수집, 데이터 가공, API, 프론트엔드가 다 다른 사람의 일이었다. 메달리온 아키텍처로 치면 Bronze 수집 담당, Bronze→Silver 담당, Silver→Gold 담당이 나뉘어 있었다. 그런데 요즘은 모두가 코딩 에이전트를 쓰다 보니, <strong>한 사람이 이 일련의 과정을 수직으로 관통하는 경우가 많아졌다.</strong> 하나의 피처를 잡으면 B→S→G를 혼자 쭉 밀고 간다. 보통 피처 하나에 CC 세션 하나를 쓰니까, 위 경험처럼 단계 간 핸드오프 없이 앞의 상황을 다 아는 상태로 진행된다. 빠르다.</p><p>문제는 이게 여러 명으로 확장될 때다. 피처 A를 맡은 사람과 피처 B를 맡은 사람이 각자의 세션에서 각자의 방식으로 B→S→G를 구현하면, <strong>파이프라인 코드의 일관성이 유지되기 어렵다.</strong> 같은 레이어의 코드인데 네이밍이 다르고, 에러 처리가 다르고, 백필 전략이 다른 코드가 쌓인다.</p><p>소프트웨어 구조는 조직의 커뮤니케이션 구조를 닮는다는 콘웨이 법칙(Conway’s Law)이 있다. 에이전트 시대에는 이렇게 변주된다: <strong>파이프라인 코드의 구조는 세션의 토폴로지를 닮는다.</strong> 피처별로 세션을 나누면 피처 단위로는 응집돼 있지만 레이어 단위로는 파편화된 코드가 나오고, 레이어별로 세션을 나누면 그 반대가 된다. 세션을 어떻게 나눌 것인가가 사실상 새로운 조직도 그리기인 셈이다.</p><p>콘웨이 법칙에는 따름정리가 있다. 원하는 아키텍처가 있다면 조직을 그 아키텍처에 맞게 먼저 재편하라는 <strong>콘웨이 역전 전략(Inverse Conway Maneuver)</strong>. 에이전트 버전으로 옮기면 — 원하는 코드 구조가 있다면, 세션 토폴로지를 그 구조에 맞게 설계하라. 즉 세션을 어떻게 나눌지는 취향 문제가 아니라, 어떤 코드베이스를 얻고 싶은지에서 역산해야 하는 문제다.</p><p>사실 이 갈림길 자체가 소프트웨어 공학이 수십 년 다뤄온 익숙한 긴장의 재등장이다.</p><ul><li><strong>응집도와 결합도(Cohesion &amp; Coupling)</strong>: 수직 세션은 피처 응집도를, 수평 세션은 레이어 응집도를 최적화한다. 무엇을 기준으로 응집시킬 것인가는 모듈 설계의 가장 오래된 질문이다.</li><li><strong>Layered Architecture vs Vertical Slice Architecture</strong>: 레이어별 수평 분할이 전통적 계층형 아키텍처라면, 피처 단위로 전 계층을 관통해 묶는 Vertical Slice Architecture는 최근 10년의 반동이다. “변경은 대부분 피처 단위로 온다, 그러니 코드도 피처 단위로 묶자”는 논리인데, 세션도 정확히 같은 논리가 적용된다 — <strong>요구사항(고객 메일)은 언제나 피처 단위로 도착하지, 레이어 단위로 도착하지 않는다.</strong></li><li><strong>Feature Team vs Component Team</strong>, 그리고 Team Topologies의 <strong>Stream-aligned Team vs Platform Team</strong>: 애자일 조직론이 다뤄온 같은 구도다. 수직 세션은 스트림 정렬 팀, 수평 세션은 컴포넌트 팀의 에이전트 판이다. 조직론의 결론이 “기본은 스트림 정렬, 플랫폼은 그것을 받치는 역할”이었다는 점은 뒤의 결론에서 다시 만난다.</li></ul><h2 id="갈림길-수직-세션-vs-수평-세션">갈림길: 수직 세션 vs 수평 세션</h2><p>그래서 혼자 일한다는 전제로도 두 가지 방식이 갈린다.</p><p><strong>수직(피처별) 세션</strong> — 피처 하나당 세션 하나. 그 세션이 B→S→G를 전부 진행한다.</p><p><strong>수평(스테이지별) 세션</strong> — Bronze 수집 세션, B→S 세션, S→G 세션을 각각 장기 유지하면서, 새 피처가 생기면 각 세션에 그 피처를 전달한다.</p><p>각각 무엇을 얻고 잃는지 따져 보면:</p><table><thead><tr><th>&nbsp;</th><th>수직 (피처별 세션)</th><th>수평 (스테이지별 세션)</th></tr></thead><tbody><tr><td>단계 간 컨텍스트</td><td>완전 유지 — 핸드오프 0</td><td>매번 피처 컨텍스트를 다시 설명해야 함</td></tr><tr><td>레이어 내 일관성</td><td>약함 — 피처마다 스타일이 갈릴 수 있음</td><td>강함 — 같은 세션이 같은 레이어를 반복 작업</td></tr><tr><td>리드타임</td><td>짧음 — 한 흐름으로 완주</td><td>김 — 세션 3개를 순차로 거침</td></tr><tr><td>사람의 역할</td><td>검토자</td><td><strong>메시지 버스</strong> — 세션 간 전달을 사람이 수행</td></tr><tr><td>세션의 학습</td><td>피처 도메인에 깊어짐</td><td>레이어 기술에 깊어짐</td></tr><tr><td>병렬/협업 확장</td><td>사람 수만큼 자연 확장, 일관성 문제 심화</td><td>레이어당 세션이 병목이 됨</td></tr></tbody></table><p>표를 그려 놓고 보니, 이 구도가 낯익다. 수평 세션 방식에서 사람이 하는 일 — 피처 요구사항을 Bronze 세션에 설명하고, 그 결과를 요약해서 B→S 세션에 넘기고, 다시 S→G 세션에 넘기는 것 — 은 정확히 <strong>예전 조직에서 단계별 담당자 사이에 존재하던 핸드오프 비용의 재발명</strong>이다. 내가 두 달간의 경험에서 확인한 최대 강점(핸드오프 손실 0)을 스스로 버리는 구조다.</p><p>여기에 고전 법칙 두 개가 정확히 얹힌다.</p><p><strong>브룩스의 법칙(Brooks’ Law)</strong> — 『맨먼스 미신』의 “지연된 프로젝트에 인력을 추가하면 더 늦어진다”는, 커뮤니케이션 경로가 참여자 수의 제곱(n(n-1)/2)으로 늘기 때문이었다. 수평 세션 구조는 피처 하나를 완성하는 데 필요한 “참여자”를 1(세션 하나)에서 4(세션 셋 + 사람)로 늘린다. 각 경계마다 컨텍스트를 압축해 전달해야 하고, 압축은 곧 손실이다. 에이전트가 사람보다 싸고 빠르다고 해서 경로 수의 수학이 사라지지는 않는다.</p><p><strong>암달의 법칙(Amdahl’s Law)</strong> — 병렬화로 얻는 이득은 직렬 구간이 상한을 정한다. 수평 세션 구조에서 직렬 구간은 사람이다. 세 세션이 아무리 빨라도 “사람이 결과를 읽고 → 요약하고 → 다음 세션에 붙여넣는” 구간은 병렬화되지 않으며, 피처 수가 늘수록 이 직렬 구간이 전체 처리량의 상한이 된다. 두 달간의 이메일 세션이 강력했던 이유를 뒤집어 말하면, 그 세션에는 직렬 구간이 “메일 붙여넣기”와 “회신 버튼”밖에 없었다.</p><h3 id="그럼에도-수평이-맞는-경우">그럼에도 수평이 맞는 경우</h3><p>그렇다고 “수평 세션은 무조건 틀렸다”로 끝나면 거짓말이다. 실제로는 이런 조건에서 수평(스테이지별) 관리가 더 나은 선택이 된다.</p><ol><li><strong>레이어 자체가 깊은 전문 컨텍스트를 요구할 때.</strong> 예컨대 Bronze 수집이 수십 개 외부 소스의 인증·레이트리밋·장애 패턴 같은 노하우 덩어리라면, 그 노하우가 쌓인 장수 세션 하나가 피처 세션 N개가 각자 바닥부터 배우는 것보다 낫다. 이건 조직론에서 플랫폼 팀을 두는 이유와 같다.</li><li><strong>레이어가 곧 제품일 때.</strong> 파이프라인 프레임워크 자체를 개선하는 작업(스키마 검증 공통화, 백필 도구화)은 피처 단위로 쪼갤 수 없다. 이런 작업은 레이어 세션이 자연스러운 단위다.</li><li><strong>일관성 위반의 비용이 치명적일 때.</strong> 규제 보고용 데이터처럼 레이어 규칙 하나가 어긋나면 사고가 되는 영역은, 처리량을 희생하고라도 같은 세션(또는 같은 게이트)을 통과시키는 값을 치를 만하다.</li></ol><p>단, 이 경우에도 “장수 수평 세션”보다 나은 형태가 대부분 존재한다는 게 내 생각이다. 레이어 전문성이 세션의 기억으로만 존재하면 그 세션이 단일 장애점(SPOF)이 된다. 전문성을 <strong>스킬이나 서브에이전트로 패키징</strong>하면, 수직 피처 세션이 필요할 때 그 전문성을 호출해 쓰는 구조가 된다 — 수평의 지식을 수직의 흐름 안에서 소비하는 것. Team Topologies가 플랫폼 팀의 이상형을 “티켓 주고받는 조직”이 아니라 “스트림 팀이 셀프서비스로 쓰는 내부 제품”으로 정의한 것과 같은 이치다.</p><h3 id="판단-기준을-한-줄씩으로-줄이면">판단 기준을 한 줄씩으로 줄이면</h3><ul><li>요구사항이 피처 단위로 도착한다 → 수직</li><li>단계 간 정보량이 크고 압축이 어렵다(이번 경험처럼 “개선 전 상태를 아는 자가 회신을 써야 하는” 종류) → 수직</li><li>레이어 노하우가 깊고 재사용된다 → 그 노하우만 스킬/서브에이전트로 수평 패키징, 흐름은 수직 유지</li><li>레이어 자체를 만드는 작업이다 → 수평</li><li>일관성 위반이 곧 사고인 도메인이다 → 수평 게이트(리뷰/검증)를 머지 조건으로, 작업은 수직</li></ul><p>그렇다고 수직 세션의 일관성 문제가 사라지는 건 아니다. 그 문제는 실재하고, 여러 명으로 확장되는 순간 반드시 터진다.</p><h2 id="내-결론-세션은-수직으로-일관성은-저장소로">내 결론: 세션은 수직으로, 일관성은 저장소로</h2><p>핵심은 이것이다. <strong>수평 세션이 지키려는 “일관성”은 세션 컨텍스트에 담아둘 자산이 아니다.</strong></p><p>세션 컨텍스트는 휘발성이고, 공유가 안 되고, 컴팩션되면 뭉개지고, 세션이 죽으면 사라진다. 레이어의 컨벤션 — Bronze 수집 코드는 이런 구조, S→G 변환은 이런 네이밍, 에러 처리는 이 패턴 — 같은 것들은 세션의 기억이 아니라 <strong>repo의 아티팩트</strong>에 있어야 한다. 컨벤션의 단일 진실 공급원(Single Source of Truth)을 세션 밖에 두는 것, DRY 원칙을 코드가 아니라 “에이전트에게 주는 지식”에 적용하는 것이다. 구체적으로:</p><ul><li><strong>CLAUDE.md / 컨벤션 문서</strong>: 레이어별 코드 패턴, 네이밍, 디렉토리 구조를 명문화. 어느 세션이 열리든 같은 규칙 위에서 시작한다.</li><li><strong>스킬(skill) 또는 템플릿</strong>: “새 피처의 Bronze 수집 추가”가 반복 작업이라면, 그 절차 자체를 스킬로 만들어 모든 세션·모든 사람이 같은 절차를 쓰게 한다.</li><li><strong>레퍼런스 구현</strong>: 가장 잘 만든 피처 하나를 정본으로 지정하고 “이 구조를 따라라”라고 지시한다. 에이전트는 기존 코드 모방에 능하다.</li><li><strong>리뷰 게이트</strong>: 사람이든 리뷰 에이전트든, 레이어 일관성 관점의 리뷰를 머지 조건으로 둔다. 일관성은 작성 시점이 아니라 머지 시점에 강제하는 게 확장 가능하다.</li></ul><p>이렇게 일관성을 외재화하고 나면, 세션은 마음 놓고 수직으로 쓸 수 있다. 피처 하나당 세션 하나로 B→S→G를 관통시키되, 그 세션이 딛고 서는 바닥(컨벤션, 스킬, 레퍼런스)을 공유 자산으로 만드는 것. 사람이 여러 명이어도 같은 바닥 위에서 각자 수직으로 달리면 된다.</p><p>한 문장으로 줄이면: <strong>컨텍스트는 세션에, 컨벤션은 저장소에.</strong> 세션 토폴로지는 처리량을 위해 수직으로 나누고, 일관성은 세션이 아니라 코드베이스가 지키게 한다.</p><h2 id="덧붙여-오래된-세션은-스킬의-프로토타입이다">덧붙여: 오래된 세션은 스킬의 프로토타입이다</h2><p>처음의 경험담으로 돌아가면, 두 달짜리 세션이 스스로 익힌 것들 — 메일 해석 → repo 매핑 → 배포 → 수치 검증 → 회신 초안이라는 절차 — 은 사실 그 세션 안에 갇혀 있는 암묵지다. 세션이 컴팩션되거나 닫히면 사라지고, 동료에게 넘겨줄 수도 없다.</p><p>그래서 요즘은 이렇게 생각한다. <strong>장수 세션이 반복 끝에 안정적으로 수행하게 된 절차는, 스킬로 증류할 때가 됐다는 신호다.</strong> 세션의 학습은 공짜로 얻어지는 프로토타이핑이고, 그 결과물이 검증됐으면 명시적인 스킬/문서/자동화로 옮겨서 세션 밖으로 꺼내야 한다. 위에서 “일관성은 저장소로”라고 한 것과 같은 원리다 — 세션 컨텍스트는 발견의 공간이지, 보존의 공간이 아니다.</p><p>두 달 전의 나는 메일을 해석해 주는 것만으로도 신기해했는데, 지금은 세션을 어떻게 배치할지가 팀의 아키텍처 결정이 되는 시대를 고민하고 있다. 코딩 에이전트가 코드를 짜는 방식보다, 우리가 에이전트를 조직하는 방식이 더 큰 변수가 되어가는 것 같다. <br></p><div><p>이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :) </p></div></div></div>

Dev Note

어떤 경험
지난 두 달 가까이 B2B 트레이딩 시스템 개선 프로젝트를 진행했다. 이 프로젝트의 특징은 일이 항상 고객사의 메일로 시작된다는 것이었다.
처음의 워크플로우는 이랬다.
고객이 메일을 보낸다.
메일 본문을 Claude Code(이하 CC) 세션에 붙여넣는다. CC가 “이런 요구사항이고, 이걸 확인해 달라는 요청입니다”라고 해석해 준다.
내가 지시를 얹는다 — “이건 A repo에서 처리해야 하고, 이건 B repo 소관이고, 저 데이터는 이 DB의 이 테이블을 봐야 해.”
작업이 끝나면 “고객에게 답장을 어떻게 쓰면 좋을까?”라고 묻고, 그 초안으로 회신을 보낸다.
이 사이클을 같은 CC 세션 안에서 계속 반복했다. 그런데 몇 주가 지나자 이상한 일이 벌어졌다. 어느 순간부터는 메일 본문을 붙여넣기만 하면:
알아서 요구사항을 정리하고,
어느 repo의 어느 코드를 고쳐야 하는지 스스로 찾아서 수정하고,
배포까지 마친 뒤,
배포 후 실제로 얼마나 개선됐는지 수치를 뽑아 검증하고,
고객이 “이것도 확인해 달라”고 덧붙인 항목은 관련 데이터를 조회해서 확인하고,
마지막으로 회신 메일 초안까지 작성해서,
몇 시간에 걸친 작업을 통째로 끝낸 결과물을 내놓기 시작했다. 내 역할은 메일을 붙여넣는 것과, 결과를 검토하고 회신 버튼을 누르는 것 정도로 줄었다.
왜 이게 가능했을까 — Skill이 아니라 Context
처음에는 “스킬을 잘 만들어서”라고 생각할 수도 있는데, 이 세션에는 이 워크플로우를 위한 스킬이나 별도 자동화가 전혀 없었다. 이걸 가능하게 만든 건 두 가지다.
첫째, 반복이 곧 학습이었다. 같은 세션에서 사이클을 반복하는 동안, 내가 3번 단계에서 얹어주던 지시들 — repo 구조, 데이터 위치, 테이블 스키마, 배포 절차, 고객의 말투와 관심사 — 이 전부 대화 컨텍스트에 쌓였다. 열 번째 메일이 도착했을 때 세션은 이미 “이 시스템의 요구사항이 어떤 형태로 오고, 어디를 고쳐서, 무엇으로 검증하고, 어떤 톤으로 회신하는지”를 전부 알고 있었다. 별도의 프롬프트 엔지니어링 없이, 앞선 아홉 번의 사이클 자체가 few-shot 예제가 된 것이다.
둘째, 핸드오프가 없었다. 요구사항 해석 → 구현 → 배포 → 검증 → 커뮤니케이션이 보통 조직에서는 서로 다른 사람(기획, 개발, 운영, CS)의 일이고, 단계마다 문서와 회의로 컨텍스트를 넘긴다. 그 전달 과정에서 정보가 깎여 나간다. 이 세션에는 그 손실이 0이었다. 배포를 한 주체가 검증 수치를 뽑았고, 코드를 고친 주체가 회신 메일을 썼다. “얼마나 개선됐는지”를 회신에 쓸 수 있었던 건, 개선 전 상태를 그 주체가 직접 봤기 때문이다.
정리하면 이 경험의 정체는: 오래 유지된 세션은 온보딩이 끝난 동료가 된다. 그리고 온보딩된 동료의 가치는 개별 작업 능력이 아니라, 맥락을 이어붙이는 데서 나온다.
그런데 이건 조직 설계 문제다
여기서 생각이 옆으로 번졌다.
예전에는 데이터 수집, 데이터 가공, API, 프론트엔드가 다 다른 사람의 일이었다. 메달리온 아키텍처로 치면 Bronze 수집 담당, Bronze→Silver 담당, Silver→Gold 담당이 나뉘어 있었다. 그런데 요즘은 모두가 코딩 에이전트를 쓰다 보니, 한 사람이 이 일련의 과정을 수직으로 관통하는 경우가 많아졌다. 하나의 피처를 잡으면 B→S→G를 혼자 쭉 밀고 간다. 보통 피처 하나에 CC 세션 하나를 쓰니까, 위 경험처럼 단계 간 핸드오프 없이 앞의 상황을 다 아는 상태로 진행된다. 빠르다.
문제는 이게 여러 명으로 확장될 때다. 피처 A를 맡은 사람과 피처 B를 맡은 사람이 각자의 세션에서 각자의 방식으로 B→S→G를 구현하면, 파이프라인 코드의 일관성이 유지되기 어렵다. 같은 레이어의 코드인데 네이밍이 다르고, 에러 처리가 다르고, 백필 전략이 다른 코드가 쌓인다.
소프트웨어 구조는 조직의 커뮤니케이션 구조를 닮는다는 콘웨이 법칙(Conway’s Law)이 있다. 에이전트 시대에는 이렇게 변주된다: 파이프라인 코드의 구조는 세션의 토폴로지를 닮는다. 피처별로 세션을 나누면 피처 단위로는 응집돼 있지만 레이어 단위로는 파편화된 코드가 나오고, 레이어별로 세션을 나누면 그 반대가 된다. 세션을 어떻게 나눌 것인가가 사실상 새로운 조직도 그리기인 셈이다.
콘웨이 법칙에는 따름정리가 있다. 원하는 아키텍처가 있다면 조직을 그 아키텍처에 맞게 먼저 재편하라는 콘웨이 역전 전략(Inverse Conway Maneuver). 에이전트 버전으로 옮기면 — 원하는 코드 구조가 있다면, 세션 토폴로지를 그 구조에 맞게 설계하라. 즉 세션을 어떻게 나눌지는 취향 문제가 아니라, 어떤 코드베이스를 얻고 싶은지에서 역산해야 하는 문제다.
사실 이 갈림길 자체가 소프트웨어 공학이 수십 년 다뤄온 익숙한 긴장의 재등장이다.
응집도와 결합도(Cohesion & Coupling): 수직 세션은 피처 응집도를, 수평 세션은 레이어 응집도를 최적화한다. 무엇을 기준으로 응집시킬 것인가는 모듈 설계의 가장 오래된 질문이다.
Layered Architecture vs Vertical Slice Architecture: 레이어별 수평 분할이 전통적 계층형 아키텍처라면, 피처 단위로 전 계층을 관통해 묶는 Vertical Slice Architecture는 최근 10년의 반동이다. “변경은 대부분 피처 단위로 온다, 그러니 코드도 피처 단위로 묶자”는 논리인데, 세션도 정확히 같은 논리가 적용된다 — 요구사항(고객 메일)은 언제나 피처 단위로 도착하지, 레이어 단위로 도착하지 않는다.
Feature Team vs Component Team, 그리고 Team Topologies의 Stream-aligned Team vs Platform Team: 애자일 조직론이 다뤄온 같은 구도다. 수직 세션은 스트림 정렬 팀, 수평 세션은 컴포넌트 팀의 에이전트 판이다. 조직론의 결론이 “기본은 스트림 정렬, 플랫폼은 그것을 받치는 역할”이었다는 점은 뒤의 결론에서 다시 만난다.
갈림길: 수직 세션 vs 수평 세션
그래서 혼자 일한다는 전제로도 두 가지 방식이 갈린다.
수직(피처별) 세션 — 피처 하나당 세션 하나. 그 세션이 B→S→G를 전부 진행한다.
수평(스테이지별) 세션 — Bronze 수집 세션, B→S 세션, S→G 세션을 각각 장기 유지하면서, 새 피처가 생기면 각 세션에 그 피처를 전달한다.
각각 무엇을 얻고 잃는지 따져 보면:
 
      수직 (피처별 세션)
      수평 (스테이지별 세션)
    
단계 간 컨텍스트
      완전 유지 — 핸드오프 0
      매번 피처 컨텍스트를 다시 설명해야 함
    
레이어 내 일관성
      약함 — 피처마다 스타일이 갈릴 수 있음
      강함 — 같은 세션이 같은 레이어를 반복 작업
    
리드타임
      짧음 — 한 흐름으로 완주
      김 — 세션 3개를 순차로 거침
    
사람의 역할
      검토자
      메시지 버스 — 세션 간 전달을 사람이 수행
    
세션의 학습
      피처 도메인에 깊어짐
      레이어 기술에 깊어짐
    
병렬/협업 확장
      사람 수만큼 자연 확장, 일관성 문제 심화
      레이어당 세션이 병목이 됨
    
표를 그려 놓고 보니, 이 구도가 낯익다. 수평 세션 방식에서 사람이 하는 일 — 피처 요구사항을 Bronze 세션에 설명하고, 그 결과를 요약해서 B→S 세션에 넘기고, 다시 S→G 세션에 넘기는 것 — 은 정확히 예전 조직에서 단계별 담당자 사이에 존재하던 핸드오프 비용의 재발명이다. 내가 두 달간의 경험에서 확인한 최대 강점(핸드오프 손실 0)을 스스로 버리는 구조다.
여기에 고전 법칙 두 개가 정확히 얹힌다.
브룩스의 법칙(Brooks’ Law) — 『맨먼스 미신』의 “지연된 프로젝트에 인력을 추가하면 더 늦어진다”는, 커뮤니케이션 경로가 참여자 수의 제곱(n(n-1)/2)으로 늘기 때문이었다. 수평 세션 구조는 피처 하나를 완성하는 데 필요한 “참여자”를 1(세션 하나)에서 4(세션 셋 + 사람)로 늘린다. 각 경계마다 컨텍스트를 압축해 전달해야 하고, 압축은 곧 손실이다. 에이전트가 사람보다 싸고 빠르다고 해서 경로 수의 수학이 사라지지는 않는다.
암달의 법칙(Amdahl’s Law) — 병렬화로 얻는 이득은 직렬 구간이 상한을 정한다. 수평 세션 구조에서 직렬 구간은 사람이다. 세 세션이 아무리 빨라도 “사람이 결과를 읽고 → 요약하고 → 다음 세션에 붙여넣는” 구간은 병렬화되지 않으며, 피처 수가 늘수록 이 직렬 구간이 전체 처리량의 상한이 된다. 두 달간의 이메일 세션이 강력했던 이유를 뒤집어 말하면, 그 세션에는 직렬 구간이 “메일 붙여넣기”와 “회신 버튼”밖에 없었다.
그럼에도 수평이 맞는 경우
그렇다고 “수평 세션은 무조건 틀렸다”로 끝나면 거짓말이다. 실제로는 이런 조건에서 수평(스테이지별) 관리가 더 나은 선택이 된다.
레이어 자체가 깊은 전문 컨텍스트를 요구할 때. 예컨대 Bronze 수집이 수십 개 외부 소스의 인증·레이트리밋·장애 패턴 같은 노하우 덩어리라면, 그 노하우가 쌓인 장수 세션 하나가 피처 세션 N개가 각자 바닥부터 배우는 것보다 낫다. 이건 조직론에서 플랫폼 팀을 두는 이유와 같다.
레이어가 곧 제품일 때. 파이프라인 프레임워크 자체를 개선하는 작업(스키마 검증 공통화, 백필 도구화)은 피처 단위로 쪼갤 수 없다. 이런 작업은 레이어 세션이 자연스러운 단위다.
일관성 위반의 비용이 치명적일 때. 규제 보고용 데이터처럼 레이어 규칙 하나가 어긋나면 사고가 되는 영역은, 처리량을 희생하고라도 같은 세션(또는 같은 게이트)을 통과시키는 값을 치를 만하다.
단, 이 경우에도 “장수 수평 세션”보다 나은 형태가 대부분 존재한다는 게 내 생각이다. 레이어 전문성이 세션의 기억으로만 존재하면 그 세션이 단일 장애점(SPOF)이 된다. 전문성을 스킬이나 서브에이전트로 패키징하면, 수직 피처 세션이 필요할 때 그 전문성을 호출해 쓰는 구조가 된다 — 수평의 지식을 수직의 흐름 안에서 소비하는 것. Team Topologies가 플랫폼 팀의 이상형을 “티켓 주고받는 조직”이 아니라 “스트림 팀이 셀프서비스로 쓰는 내부 제품”으로 정의한 것과 같은 이치다.
판단 기준을 한 줄씩으로 줄이면
요구사항이 피처 단위로 도착한다 → 수직
단계 간 정보량이 크고 압축이 어렵다(이번 경험처럼 “개선 전 상태를 아는 자가 회신을 써야 하는” 종류) → 수직
레이어 노하우가 깊고 재사용된다 → 그 노하우만 스킬/서브에이전트로 수평 패키징, 흐름은 수직 유지
레이어 자체를 만드는 작업이다 → 수평
일관성 위반이 곧 사고인 도메인이다 → 수평 게이트(리뷰/검증)를 머지 조건으로, 작업은 수직
그렇다고 수직 세션의 일관성 문제가 사라지는 건 아니다. 그 문제는 실재하고, 여러 명으로 확장되는 순간 반드시 터진다.
내 결론: 세션은 수직으로, 일관성은 저장소로
핵심은 이것이다. 수평 세션이 지키려는 “일관성”은 세션 컨텍스트에 담아둘 자산이 아니다.
세션 컨텍스트는 휘발성이고, 공유가 안 되고, 컴팩션되면 뭉개지고, 세션이 죽으면 사라진다. 레이어의 컨벤션 — Bronze 수집 코드는 이런 구조, S→G 변환은 이런 네이밍, 에러 처리는 이 패턴 — 같은 것들은 세션의 기억이 아니라 repo의 아티팩트에 있어야 한다. 컨벤션의 단일 진실 공급원(Single Source of Truth)을 세션 밖에 두는 것, DRY 원칙을 코드가 아니라 “에이전트에게 주는 지식”에 적용하는 것이다. 구체적으로:
CLAUDE.md / 컨벤션 문서: 레이어별 코드 패턴, 네이밍, 디렉토리 구조를 명문화. 어느 세션이 열리든 같은 규칙 위에서 시작한다.
스킬(skill) 또는 템플릿: “새 피처의 Bronze 수집 추가”가 반복 작업이라면, 그 절차 자체를 스킬로 만들어 모든 세션·모든 사람이 같은 절차를 쓰게 한다.
레퍼런스 구현: 가장 잘 만든 피처 하나를 정본으로 지정하고 “이 구조를 따라라”라고 지시한다. 에이전트는 기존 코드 모방에 능하다.
리뷰 게이트: 사람이든 리뷰 에이전트든, 레이어 일관성 관점의 리뷰를 머지 조건으로 둔다. 일관성은 작성 시점이 아니라 머지 시점에 강제하는 게 확장 가능하다.
이렇게 일관성을 외재화하고 나면, 세션은 마음 놓고 수직으로 쓸 수 있다. 피처 하나당 세션 하나로 B→S→G를 관통시키되, 그 세션이 딛고 서는 바닥(컨벤션, 스킬, 레퍼런스)을 공유 자산으로 만드는 것. 사람이 여러 명이어도 같은 바닥 위에서 각자 수직으로 달리면 된다.
한 문장으로 줄이면: 컨텍스트는 세션에, 컨벤션은 저장소에. 세션 토폴로지는 처리량을 위해 수직으로 나누고, 일관성은 세션이 아니라 코드베이스가 지키게 한다.
덧붙여: 오래된 세션은 스킬의 프로토타입이다
처음의 경험담으로 돌아가면, 두 달짜리 세션이 스스로 익힌 것들 — 메일 해석 → repo 매핑 → 배포 → 수치 검증 → 회신 초안이라는 절차 — 은 사실 그 세션 안에 갇혀 있는 암묵지다. 세션이 컴팩션되거나 닫히면 사라지고, 동료에게 넘겨줄 수도 없다.
그래서 요즘은 이렇게 생각한다. 장수 세션이 반복 끝에 안정적으로 수행하게 된 절차는, 스킬로 증류할 때가 됐다는 신호다. 세션의 학습은 공짜로 얻어지는 프로토타이핑이고, 그 결과물이 검증됐으면 명시적인 스킬/문서/자동화로 옮겨서 세션 밖으로 꺼내야 한다. 위에서 “일관성은 저장소로”라고 한 것과 같은 원리다 — 세션 컨텍스트는 발견의 공간이지, 보존의 공간이 아니다.
두 달 전의 나는 메일을 해석해 주는 것만으로도 신기해했는데, 지금은 세션을 어떻게 배치할지가 팀의 아키텍처 결정이 되는 시대를 고민하고 있다. 코딩 에이전트가 코드를 짜는 방식보다, 우리가 에이전트를 조직하는 방식이 더 큰 변수가 되어가는 것 같다.

코딩 에이전트 시대의 콘웨이 법칙: 세션을 어떻게 나눌 것인가

댓글