2026-02-10

“코드는 훨씬 빨리 나오는데, 왜 출시 속도는 그대로일까?”

완주를 위한 오케스트레이션

일반적으로 서비스에서 한 번의 변경을 4단계로 진행
- 계획 → 구현 → 검증 → 설명
- AI 시대 전까지는, 구현이 가장 무거운 구간
- AI가 빠른 구현 및 반복 작업 해결 → 구현이 가벼워짐 → 검증, 설명의 중요성 상승
- 검증 : 해당 변경이 실제로 안전한지, 어떤 조건에서 깨지는지, 운영 상 문제 될 여지가 없는지?
- 설명 : 리뷰어가 납득 가능한 근거 및 맥락, 합의 가능한 선택지
구현이 빨라짐 → 코드 변경이 빈번하고 큰 단위로 발생
- 팀은 코드 개발 속도가 아닌, 확신을 만드는 속도로 변화
- 리뷰가 길어지는 이유 : 구성원들의 정보 부족
오케스트레이션 : 완주를 위해 역할을 나누는 방식 (좋은 AI 도구를 쓰는 기술 X)
- 계획 : 변경 목표, 제약, 영향 범위 고정
- 구현 : 빠른 개발 (AI 활용)
- 검증 : 자동화된 검증루프를 통한 기본 안전 수칙 제작
- 설명 : 리뷰어가 이해 가능한 형태로 요약

오케스트레이션 원리

AI에게 일을 맡기는 방식을 의미
일을 분할하고 역할을 구분하여, 계획부터 설명까지의 흐름이 하나의 맥락으로 동작하도록 하는 방식
도구 선택 : 가격, 보안 정책, 모델 선택, 팀의 인프라 제약에 따라 바뀔 수 있는 영역
역할이 정해진 AI가 일을 시작할 때의 문제
- 어떤 연결 방식으로 구현할 것인가?
- MCP(Model Context Protocol)의 등장
- 표준화된 연결 및 통제의 중요성 상승

오케스트레이션의 조건

에이전트는 일반적으로 빨리 끝내는 방향으로 움직임 → 팀이 의도한 경계를 말로만 정의하면 자주 무너짐 → 권한 및 프라이버시 침해 발생
팀이 먼저 정해야 하는 것 : ‘어떤 일을 더 맡길까?’ (X) → ‘어디까지 절대 못하게 할까?’ (O)
- 읽기는 넓게, 쓰기는 좁게 : 정책 문서/로그/코드 저장소 읽기 허용, 변경 최소화
- 큰 작업은 한 번 더 멈춤 : 데이터 수정/권한 변경 등 롤백이 어렵거나, 실시간 서비스 운영에 직결되는 부분은 사람 확인을 필수로 거칠 것
- 접근 기록 저장 : ‘무엇을 보고, 무엇을 바꿨는지’ 에 대한 흔적을 남겨서, 추후 롤백 및 문제점 추적 가능토록 할 것

검증 절차

실무에서 검증에 부담 느끼는 이유 : ‘테스트가 어려워서’ (X) → ‘검증에 필요한 근거가 흩어져 있어서’ (O)
AI가 가능한 검증 작업 보강
- 정책 문서와 구현이 상충하는 지점 (누락된 예외, 잘못된 조건 분기) 탐색
- 변경 영향 범위를 사전 정리 → 로그/트레이스에서 확인할 지표 제안
리뷰에서 바뀔 점
- 정상 동작 여부 확인 → 정책 및 사용자 경험 관점에서 선택의 타당성, 위험을 줄이는 방식 판단에 많은 시간 배분하기

개발자의 새 역할

results matching ""