[한영자막] 금융 에이전트의 병목은 당신이다

URL: https://www.youtube.com/watch?v=J86SNqUsFBs 날짜: 2026-08-07 채널: Tech Bridge

---

메타데이터

• 원 영상 제목(영문): The Bottleneck in Your Financial Agent Is You (한영자막 버전)
• 채널: Tech Bridge
• 재생시간: 13:42
• 발표자: 오디토리아 AI(Auditoria AI, 자막상 "시단트 이마니"로 표기됨 — ASR 오인식 가능성 있는 인명, 원문 정확 표기는 영상 참조) — 오디토리아 AI 데이터 과학자
• 발표 맥락: 인공지능 엔지니어 세계 박람회(AI Engineer World's Fair) 세션. "하네스 엔지니어링(Harness Engineering)" 트랙과 "금융 분야 AI(Finance AI)" 트랙 사이에 위치한 발표
• 자막 소스: YouTube 자동 생성 한국어 자막(ASR 기반, 일부 용어 오인식 가능성 있어 문맥으로 보정)
• 처리 날짜: 2026-08-07

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==프로덕션 금융 에이전트를 구축할 때 가장 큰 병목은 모델·GPU·프레임워크가 아니라, 사람이 개발 루프 안에 남아 모든 것을 직접 조율해야 한다는 사실 그 자체다.==

• 데모는 쉽게 만들 수 있지만, 실제 운영 환경에 배포되고 신규 고객이 온보딩되는 순간부터는 완전히 다른 문제가 시작된다
• "더 나은 모델", "더 빠른 GPU", "더 나은 프레임워크"를 기다리는 것은 답이 아니며, 진짜 답은 개발 루프 속도(dev loop speed)다
• 하위 에이전트(subagent) · 작업 트리(worktree) · 기술(skill) · MCP 연결 · 최소 UX라는 4가지 요소를 결합하면 개발자 생산성을 극적으로 높일 수 있지만, 금융처럼 규제가 강한 산업에서는 여전히 "누가 검토하고 누가 책임지는가"라는 조직적 병목이 남는다
• 세션의 결론은 "루프에서 자기 자신을 빼는 방법(getting yourself out of the loop)" — 목표를 부여하고 잊어버리는 자율 에이전트, 재귀적 자기 개선, 백그라운드에서 고객 세션을 학습하는 "꿈꾸는" 에이전트로 이어진다

발표자는 금융 상담사(에이전트)의 업무 진행에 있어 가장 큰 걸림돌이 바로 "당신"이라는 도발적인 제목으로 시작해, 데모와 프로덕션 사이의 간극을 개발 루프 속도의 문제로 재정의한다. 이어서 하위 에이전트·작업 트리·기술·최소 UX라는 4가지 실무 요소를 소개하고, 금융 산업 특유의 규제·책임 소재 문제를 짚은 뒤, 마지막으로는 사람이 개발 루프에서 점점 빠지고 에이전트가 목표 기반으로 자율 운영되는 미래상을 제시한다.

---

1. 데모와 프로덕션 사이의 간극

이 세션의 전체 내용은 개발자 도구 안의 병목 현상을 파악하는 것을 목표로 한다.

1.1. 문제 제기: 왜 데모는 프로덕션에서 무너지는가

1. 금융 상담사 업무의 가장 큰 걸림돌은 "당신"

   1. 도발적인 제목: 발표자는 청중이 병목이라는 뜻은 아니라고 해명하면서도, 청중이 개발 중인 내부 도구와 그 도구를 활용해 프로덕션 에이전트를 구축하는 방법에 대해 이야기하고 싶다고 밝힘
   2. 발표자 소개: 오디토리아 AI에서 데이터 과학자로 근무하며, 금융 분야의 생산(production) 에이전트를 구축. 청중 중 CFO가 있다면 세션 후 대화를 나누고 싶다고 언급
   3. 세션 포지셔닝: "하네스 엔지니어링" 트랙과 "금융 분야 AI" 트랙 사이에 위치한 발표이며, 발표의 주요 내용은 개발자 도구 내의 병목 현상을 파악하는 것

2. 데모 vs. 파일럿 vs. 프로덕션의 단계별 격차

   1. 박람회의 화려한 데모들: 인공지능 엔지니어 세계 박람회에서 멋진 데모를 많이 봤지만, 이러한 데모 버전이 파일럿 단계로 전환되고 신규 고객 온보딩이 시작되면 상담원(에이전트)들은 이러한 미래 데이터를 전혀 볼 수 없게 됨
   2. 운영 버그의 현실: 실제 운영 환경에서 발생하는 버그는 매우 많고, 운영상의 버그는 시간 단위로 발생하는 것이 엄연한 사실
   3. 코드 작성 자체는 쉬움: 코드를 작성하는 것은 매우 쉽고, 요즘에는 멋진 데모 버전을 만들어서 많은 사람들에게 보여주는 것이 아주 쉬워졌음 — 그래서 "그렇다면 왜 이러한 데모 버전이 실제 운영 환경에서 제대로 작동하지 않는가"라는 질문이 남음

1.2. 흔한 (잘못된) 답과 진짜 답

1. 흔히 제시되는, 그러나 틀린 답들 (풍자적 나열)

   1. 모델 탓: "더 나은 모델이 필요하신가요? Fable 5는 어떨까요?"
   2. 하드웨어 탓: "아니면 더 빠른 GPU가 필요하신가요?"
   3. 프레임워크 탓: "더 나은 프레임워크가 필요하신가요? 아마도. 혹은 RL 루프가 제대로 작동하지 않는 것일 수도 있습니다"
   4. "기다리면 해결된다"는 마인드셋 비판: "3개월 반만 기다리면 시장에 새로운 모델이 출시될 것이다", "1년 정도만 기다리면 새로운 칩이 나올 것이다, 우리는 더 빠른 GPU를 보유하고 있다", "코드를 작성하는 것은 쉬우니 매일 새로운 프레임워크를 접하게 되고, 프레임워크를 수시로 바꿀 수 있다" — 발표자는 이런 식의 대응을 반어적으로 나열하며 진짜 원인이 아님을 지적

2. 진짜 답: 개발 루프 속도(Dev Loop Speed)

   1. 모델 성능은 기하급수적으로 증가하지만, 그것만으로는 운영상의 버그를 실시간으로 해결할 수 없음
   2. 개발자들은 개발 과정을 자동화하기 위해 매일 많은 시간을 투자해야 한다는 것이 핵심이며, 이러한 운영상의 버그를 실시간으로 어떻게 해결할 수 있는지에 대한 답이 곧 개발 루프 속도
   3. 세션의 목표 제시: 발표자가 말하는 기본 요소는 네 가지이며, 청중 모두 반복문(loop)에 대해 생각해봐야 하고, 세션이 끝날 때쯤에는 실제 운영 환경에 적용 가능한 코드를 연결할 수 있기를 바란다고 밝힘

---

2. 프로덕션 에이전트를 위한 4가지 기본 요소

2.1. 요소 1 — 하위 에이전트(Subagent)와 작업 트리(Worktree)

1. 하위 에이전트로 "군대"를 거느리기

   1. 하네스 무관 활용 가능: 요즘에는 어떤 하네스(harness)를 사용하든 새로운 하위 요원(subagent)을 생성할 수 있으며, 이를 군대처럼 거느릴 수 있음
   2. 작업 트리 = 당신의 가장 좋은 친구: 작업 트리(worktree)를 서로 격리된 폴더라고 생각하면 되며, 이 폴더들 안에 에이전트가 생성하는 모든 코드가 기록됨

2. 병렬 실행과 독립성

   1. 병렬 작업 트리: 이러한 작업 트리들이 병렬로 실행되도록 하는 것이 목표
   2. 독립적 임무 수행: 하위 요원들은 독립적인 임무를 수행하며 같은 것을 두고 다투지 않음

2.2. 요소 2 — 기술(Skills)

1. 조직의 비밀 레시피
   1. 기술 = 비밀 레시피: 기술(skill)은 조직의 비밀 레시피이므로, 다양한 기술을 갖추도록 해야 함
   2. 일관된 워크플로 보장: 이러한 기술을 상담원(에이전트)에게 제공하기 시작하면, 상담원들은 어떤 프로덕션 버그가 발생하더라도 항상 올바르고 적절한 워크플로를 사용하여 해결하게 됨

2.3. 요소 3 — MCP·타사 서버 연결

1. 어디에든 연결 가능한 도구 생태계
   1. MCP 도구 폭증: 현재 시장에 많은 MCP 도구가 출시되는 것을 목격해왔음
   2. 범용 연결성: 에이전트가 어떤 MCP 도구든, 어떤 타사 서버든 연결할 수 있고, 고객 데이터를 원하는 어떤 시스템에든 저장할 수 있음

2.4. 요소 4 — 최소 UX(Minimal UX)와 조율 비용

1. 하위 담당자가 많아질수록 커지는 조율 비용

   1. 조율 부담 증가: 결국 하위 담당자가 많으면 조율해야 할 업무도 많아지므로, 최소한의 사용자 경험(UX)이 핵심
   2. 관리자 관점의 스케일 예시: 맥북에 48GB RAM이 있다면 50개의 활성 작업 트리를 동시에 운영할 수 있으며, 즉 50개의 활성 하위 에이전트가 서로 다른 작업을 독립적으로 수행

2. 작업의 출처: QA 티켓 → 작업 트리 → 하위 에이전트

   1. 작업 트리로 티켓 매핑: 예를 들어 출시 예정인 소프트웨어에 대해 QA팀이 보고한 버그가 많다고 가정하면, 모든 지라(Jira) 티켓은 별도의 작업 트리로 생각할 수 있음
   2. 에이전트가 재귀적으로 하위 에이전트 생성: 서로 다른 작업 트리는 별도의 에이전트가 처리하며, 이러한 에이전트는 특정 작업을 해결하기 위해 여러 하위 에이전트를 다시 생성할 수 있음
   3. 대기열이 필요 없는 이유: 에이전트가 당신보다 훨씬 더 잘 처리해줄 것이기 때문에 작업을 대기열에 추가할 필요가 없음

3. 1~9단계 워크플로 데모: QA 버그 티켓 → 프로덕션 배포

   1. 1단계 요구사항 분석: QA팀에서 버그 티켓을 많이 보고했다고 가정하면, 마법처럼 에이전트가 요구사항을 분석
   2. 2단계 근본 원인 분석: 근본 원인 분석(root cause analysis)을 수행
   3. 3단계 정보 수집 및 저장: 모든 추적 정보와 로그를 수집하고, 이 모든 정보를 별도의 작업 트리에 저장
   4. 4단계 TDD: TDD(테스트 주도 개발)를 수행
   5. 5단계 수정 구현 및 로컬 E2E 테스트: 수정 사항을 구현하고, 로컬 시스템에서 실행하기 때문에 테스트 스크립트를 작성해 로컬에서 엔드투엔드 테스트를 수행
   6. 6단계 PR 생성 및 팀 리뷰: PR을 생성하고 검토를 위해 팀에 제출
   7. 7단계 마스터 브랜치 병합: 검토 후 해당 코드를 마스터 브랜치에 병합
   8. 8단계 빌드·배포·스테이징 검증: 병합 후 Docker 이미지를 빌드하고 개발 환경에 배포·테스트한 뒤, 다시 빌드한 이미지를 스테이징 환경으로 전송·테스트·배포
   9. 9단계 QA 팀 재확인: 그런 다음 QA 팀에 돌아가서 "자, 여기 있습니다. 테스트해 보세요"라고 말함

4. 청중 질의응답: 사람이 꼭 필요한 단계는 어디인가

   1. 발표자의 답: 1단계(요구사항 정의)와 9단계(최종 검증)에서만 사람이 필요하고, 그 사이의 단계들은 에이전트가 훨씬 더 잘 처리할 수 있다고 봄
   2. 사람 개입이 필요한 이유: 에이전트가 수행하는 작업을 사람이 직접 확인해야 하고, 작업이 스테이징 환경으로 전달된 후 최종 검증을 위해 사람이 다시 한번 확인해야 함
   3. 최소 UX의 필요성: 사람들은 간결한 사용자 경험을 좋아하기 때문에 최소한의 UX가 필요함

5. 실제 대시보드 사례: 하나의 위젯으로 모든 것을 확인

   1. 위젯에 통합된 요소들: 프로덕션 에이전트 소프트웨어의 모든 Kubernetes 서비스·파드·예제, 모든 로그(시스템 로그 포함), 모든 Jira 티켓, 모든 GitHub PR, 그리고 맨 아래 Cloud Code 세션까지 표시하는 프로젝트 대시보드 — 기본적으로 맥OS 위젯 형태
   2. 여러 창이 필요 없는 워크플로: 이 모든 작업을 하기 위해 여러 창을 열 필요가 없으며, 개발자는 소프트웨어 개발 주기에서 다양한 일을 하는 것을 좋아하므로 위젯 하나만으로 여러 가지 일을 처리 가능
   3. "목 돌림 횟수" 비유: 그래프에서 보이듯 한 번의 변경을 위해 필요한 "목 돌림 횟수(컨텍스트 스위칭 횟수)"가 급격히 줄어듦 — 보통 개발자들은 책상 위에 모니터를 두세 개씩 놓고 목을 계속 돌려가며 여러 에이전트를 조종하지만, 이 위젯 하나로 그 필요성을 줄일 수 있다는 취지

---

3. 금융 산업 특유의 병목: 규제와 책임 소재

3.1. 규제 산업에서 하위 에이전트 팀을 운영하는 법

1. 오디토리아의 도메인: 금융

   1. 규제 환경: 오디토리아는 금융 분야에서 일하며, 지금 금융 분야에서는 많은 규제와 정책이 시행되고 있음
   2. 핵심 질문: 그렇다면 금융 부문에서 하위 에이전트 팀을 조직적으로 운영하려면 어떤 모습이어야 하는가

2. AI 없이 진행되는 기존 승인 프로세스

   1. 사람에 의한 코드 검토: 인공지능을 배제한다면 일반적으로는 사람이 코드를 검토
   2. SOX 규정 준수 및 관리자 승인: SOX(사베인스-옥슬리법) 규정 준수에 따라 관리자(컨트롤러)가 승인하며, 에이전트 간 검토(agent-to-agent review)를 거치게 됨

3. 책임 소재 문제

   1. "클라우드 탓" 불가: 만약 문제가 발생한다면 책임은 누구에게 있는가 — 운영 환경에서 문제가 발생하면 클라우드 탓으로 돌릴 수 없으며, 뭔가 잘못된 것임이 명확해야 함
   2. 실시간 버그 수정 시나리오의 병목: 여러 하위 에이전트를 가지고 있고 이러한 도구를 사용해 실시간으로 버그를 수정한다고 가정할 때, 진짜 병목은 이 모든 다양한 작업을 직접 조율해야 하기 때문에 요구되는 "인간의 주의력"임
   3. 결론: 금융 부문에서 빠르게 움직이고 업계를 혁신하는 것은 (일반 소프트웨어 개발과는) 완전히 다른 차원의 문제

---

4. 루프에서 자기 자신을 빼는 방법 (Getting Yourself Out of the Loop)

4.1. 지금까지의 전제와 그 전제가 흔들리는 이유

1. 기존 전제: 지금까지는 에이전트가 무엇을 하는지 확인하고, 최종적으로 에이전트의 작업 결과를 검증하는 데에도 사람이 필요하다고 말해왔음
2. 전제가 흔들리는 배경: 하지만 요즘 에이전트와 모델 기능이 자체적으로 개선되면서 Fable 5, Mythos 5, GPT 5.6 같은 (가상의 차세대) 제품들이 나오게 됨 — 그렇다면 내부 개발자 역량 강화 시스템에서 이러한 재귀적 자기 개선(recursive self-improvement)이 이루어지면 어떤 모습일지 질문을 던짐

4.2. 재귀적 자기 개선 시나리오

1. 모든 생산 실패는 입력값이 된다

   1. 핵심 원칙: 모든 생산(production) 실패는 (에이전트 개선을 위한) 입력값이 됨
   2. 셀프 개발 루프 설정: 셀프 개발자 도구를 매일 자동화하고, 에이전트가 스스로 업그레이드하도록 요청한다고 가정 — 루프가 계속 실행되도록 두면 하루나 이틀 정도 지나 버그 보고서 5~6건을 해결
   3. 병목 자기 진단·자기 제거: 상담원(에이전트)에게 이 과정의 모든 병목 현상을 분석해달라고 요청해 목록을 만들고, 이러한 병목 현상을 매일 조금씩 제거해 나가면 됨

2. 한 달 후의 모습: 한 문장 자동화 시스템

   1. 입력 최소화: 한 달 후, 단 한 문장만 입력하고 "이 버그를 수정해 주세요"라고 말하는 아주 훌륭한 자체 자동화 시스템을 갖추게 되었다고 가정
   2. 전 과정 자동 실행: 그러면 에이전트가 실행되어 모든 데이터베이스 시스템에 연결하고, 모든 로그·추적 정보·티켓을 가져와 Jira에서 QA 파이프라인으로 전송 및 마이그레이션
   3. 사람의 해방: 이 시점에서 사람은 휴가를 예약하거나 재택근무를 할 수도 있음

4.3. 목표(Goal) 기반 자율성

1. "목표를 부여하고 잊어버리기"라는 질문

   1. 청중 대상 질문: 덜 응시하고(stare) 더 많이 배송(ship)하면 어떤 일이 일어날지, 요즘 얼마나 많은 사람이 에이전트에게 목표를 부여할 수 있다는 사실을 알고 있는지 질문 — "목표를 세우고 나서 잊어버리면 됩니다"
   2. 청중 반응: 손을 든 사람이 아무도 없었고, 발표자는 "감사해요"라며 넘어감(유머러스한 순간)

2. 목표 + 반복문(loop) 결합 사례

   1. 데이터 불일치 목표 설정 예시: "이 보고서에 데이터 불일치가 있다"는 목표를 설정하면 됨 — 실제 운영 환경에서 발생하는 버그의 경우 소스 데이터가 에이전트가 생성한 데이터와 일치하지 않는 문제가 흔함
   2. 조사·반복 작업 설정: 이 문제를 해결하겠다는 목표를 세우고 조사해본 뒤 반복 작업(iteration loop)을 설정하면 됨
   3. 원격 모니터링 가능성: 요즘은 스마트폰으로도 (에이전트 작업 상황을 확인하며) 노트북을 닫을 수도 있다는 언급으로, 사람이 실시간 상주할 필요가 줄어듦을 시사

4.4. "꿈꾸는" 백그라운드 에이전트

1. 고객 세션 패턴 학습

   1. 전제: 많은 고객이 실제 소프트웨어를 사용하고 있고, 그들이 동일한 패턴을 반복하며 동일한 문제에 직면하고 있다고 가정
   2. 꿈(Dream) 비유: 에이전트가 마치 사람이 꿈꾸는 것처럼 백그라운드에서 작동하여, 고객이 사용하는 모든 세션을 수집하고 이를 시스템이 활용해 자체 업그레이드할 수 있는 데이터 포인트 세트로 압축하도록 하는 것

2. 모든 요소를 조합했을 때의 최종 그림

   1. 완전한 이탈 가능성: 이러한 모든 기능(하위 에이전트, 재귀적 자기개선, 목표+반복문, 꿈꾸는 백그라운드 에이전트)을 조합하면 기본적으로 모든 상황에서 완전히 벗어날 수 있음
   2. 단, 개발자의 업무 방식 변화 전제: 앞서 말했듯 개발자들은 소프트웨어 개발 수명 주기(SDLC) 동안 매우 다양한 일을 하며, 오전 9시부터 오후 5시까지 책상에 앉아 코드만 작성하는 방식은 더 이상 통용되지 않음

---

5. 세션 요약 정리 (발표자 자체 정리)

1. 병렬 작업 트리 위의 하위 담당자 팀: 여러 하위 담당자로 구성된 팀이 병렬 작업 트리에서 작업할 수 있음
2. 기술·조직 운영 비법·고객 맞춤 레시피: 여러분은 기술, 조직 운영 비법, 고객 맞춤형 레시피를 가질 수 있고, 이 모든 것을 담당자(에이전트)에게 줄 수 있음
3. 범용 연결성: 에이전트는 모든 타사 서버(로깅 시스템, 인증 게이트웨이 등)에 연결할 수 있음
4. 최소 UX로 압축: 이 모든 것을 하나의 화면에 압축해서 보여주는 이유는 최소한의 사용자 경험(UX)이 핵심이기 때문
5. 자율성을 위한 목표 + 반복 작업: 자율성을 위한 목표와 반복 작업을 설정할 수 있으며, 특정 작업을 대리인(에이전트)이 훨씬 더 잘 처리할 수 있다고 생각되면 대리인에게 보내주면 됨
6. 검증자는 항상 사람: 검증자(validator)는 항상 사람이어야 하지만, 사람의 주의력은 매우 제한적이기 때문에 처리량(throughput)에 한계를 두어서는 안 됨

---

주요 발언 모음

"금융 상담사의 업무 진행에 있어 가장 큰 걸림돌은 바로 당신입니다."

"그렇다면 이러한 데모 버전이 실제 운영 환경에서 제대로 작동하지 않는 이유는 무엇일까요? 모델 때문인가요? 더 나은 모델이 필요하신가요?"

"정답은 개발 루프 속도입니다."

"당신은 그들(하위 에이전트)을 군대처럼 거느릴 수 있습니다. 그리고 나무(작업 트리)는 당신의 가장 좋은 친구입니다."

"에이전트가 당신보다 훨씬 더 잘 처리해 줄 것이기 때문에 작업을 대기열에 추가할 필요가 없습니다."

"1단계와 9단계에서만 사람이 필요하고, 그 사이의 단계들은 에이전트가 훨씬 더 잘 처리할 수 있다고 봅니다."

"운영 환경에서 문제가 발생하면 클라우드 탓으로 돌릴 수 없습니다. 뭔가 잘못됐어요."

"모든 생산 실패는 입력값이 됩니다."

"요즘 여러분 중 얼마나 많은 분들이 에이전트에게 목표를 부여할 수 있다는 사실을 알고 계십니까? 목표를 세우고 나서 잊어버리면 됩니다."

"검증자는 항상 사람이어야 하지만, 사람의 주의력은 매우 제한적이기 때문에 처리량에 한계를 두어서는 안 됩니다."

핵심 데이터 & 수치

• 48GB RAM 맥북 기준 동시 작업 트리 수: 50개의 활성 작업 트리 = 50개의 활성 하위 에이전트가 서로 다른 작업을 독립적으로 수행 가능
• 워크플로 단계 수: QA 버그 티켓 접수부터 스테이징 배포까지 총 9단계로 구조화, 그중 사람 개입은 1단계(요구사항 정의)와 9단계(최종 검증) 단 2곳
• 자기개선 루프 소요 기간: 하루~이틀의 자동화 루프로 버그 보고서 5~6건 해결, 이를 매일 반복하면 한 달 후 "한 문장 입력"만으로 작동하는 자체 자동화 시스템 도달(발표자의 가상 시나리오)
• 규제 근거: 금융 산업에서는 SOX(사베인스-옥슬리법) 규정 준수에 따른 관리자(컨트롤러) 승인 및 에이전트 간 검토가 필수로 요구됨

결론 및 시사점

1. 개발 루프 속도가 진짜 병목이다: 더 나은 모델·GPU·프레임워크를 기다리는 것은 해답이 아니며, 프로덕션 버그를 실시간으로 처리할 수 있는 개발 루프 자체의 속도를 높이는 것이 핵심이다.
2. 4가지 요소(하위 에이전트·작업 트리, 기술, MCP 연결, 최소 UX)를 결합하라: 이 조합을 통해 QA 버그 티켓 하나가 접수되는 순간부터 스테이징 배포까지 대부분의 단계를 에이전트가 자동으로 처리할 수 있으며, 사람은 요구사항 정의와 최종 검증이라는 두 지점에만 집중하면 된다.
3. 금융처럼 규제가 강한 산업은 별개의 문제다: 코드 검토, SOX 규정 준수, 관리자 승인, 에이전트 간 검토, 책임 소재 등 조직적·법적 병목은 기술적 자동화만으로 해결되지 않으며, 이 지점에서 진짜 병목은 다시 "인간의 주의력을 요구하는 직접 조율"로 돌아온다.
4. 장기적으로는 "루프에서 자신을 빼는" 방향으로 진화한다: 재귀적 자기 개선, 목표 기반 자율 루프, 백그라운드에서 고객 세션을 학습하는 "꿈꾸는" 에이전트를 결합하면 사람이 개발 루프 대부분에서 벗어날 수 있지만, 검증자(validator) 역할만큼은 항상 사람이 맡아야 하며 이때도 사람의 제한된 주의력이 시스템 전체의 처리량을 제약하지 않도록 설계해야 한다.
5. 개발자의 역할 자체가 바뀐다: 오전 9시부터 오후 5시까지 자리에 앉아 코드만 작성하는 개발자상은 더 이상 유효하지 않으며, 개발자는 소프트웨어 개발 수명 주기 전반에 걸쳐 다양한 역할(조율, 목표 설정, 검증)을 수행하는 방향으로 이동한다.