개발 기록을 다시 보며 알게 된 AI와 일하는 방식

AI로 개발하면서 가장 먼저 보이는 결과는 코드입니다. 요청한 기능이 만들어지고, 오류가 수정되고, 화면이 달라집니다.

그래서 저도 처음에는 어떤 모델이 코드를 더 잘 작성하는지에 관심이 많았습니다. 결과가 마음에 들지 않으면 더 강한 모델을 선택하거나 프롬프트를 자세히 작성했습니다.

그런데 최근 작업을 돌아보니, 실제 개발 시간의 상당 부분은 코드를 작성하는 데 쓰이지 않았습니다.

지금 해야 할 일이 조사인지 구현인지 판단했습니다.
현재 코드와 문서 중 무엇이 정본인지 찾았습니다.
작업을 여러 범위로 나누거나 하나의 에이전트가 처리하도록 결정했습니다.
테스트가 통과해도 운영에 반영해도 되는지 따로 확인했습니다.
근거가 부족하면 구현하지 않고 멈췄습니다.

제가 사용하고 있던 것은 단순한 코딩 도구라기보다, 개발 공정을 운영하는 에이전트에 가까웠습니다.

Uber는 이것을 ‘Software Factory’라고 불렀습니다

Uber는 최근 Running a Software Factory Efficiently at Uber Scale이라는 글에서 자사의 AI 개발 운영 방식을 공개했습니다.

Uber에서는 PR의 70% 이상이 로컬 또는 클라우드 에이전트 작업으로 만들어집니다. 개발 과정에 3,600개가 넘는 에이전트 스킬이 있으며, 하루 실행 횟수는 3만 회가 넘습니다.

흥미로웠던 점은 규모보다 비용을 바라보는 방식이었습니다. Uber는 비용을 단순히 모델의 토큰 가격으로 보지 않았습니다.

전체 비용
= 사용자 수
× 사용자당 세션 수
× 세션당 대화 횟수
× 대화당 요청 수
× 요청당 토큰 수
× 토큰 가격

사용자와 작업량은 계속 늘리되, 에이전트가 헤매면서 발생시키는 대화와 요청, 불필요한 컨텍스트를 줄이는 방식이었습니다. 가장 저렴한 모델을 고르는 것보다 하나의 결과에 도달하기까지 낭비되는 과정을 줄이는 것에 가까웠습니다.

이 글을 읽고 궁금해졌습니다.

내가 실제로 사용하는 Codex도 이런 방식으로 움직이고 있을까?

설정 파일만 보고 판단하지 않고, 최근에 진행한 실제 작업 다섯 개를 다시 확인했습니다.

첫 번째 세션: 해결책을 바로 구현하지 않았습니다

한 서비스에서 데이터베이스 연결이 오래된 상태로 남아 시간 초과가 발생하고 있었습니다.

처음에는 관련 라이브러리를 최신 버전으로 올려보자는 해결책이 나왔습니다. 일반적으로 시도해볼 만한 방법이었지만, 에이전트는 버전 번호만 확인하고 구현하지 않았습니다.

공식 릴리스 노트와 GitHub 변경 내용을 확인하고, 실제 npm 패키지까지 내려받아 이전 버전과 실행 파일의 해시를 비교했습니다. 그 결과 새 버전에는 이 문제를 고치는 실행 코드가 없었습니다.

에이전트는 자신이 앞서 제안한 방법을 이렇게 정정했습니다.

“최신 버전으로 먼저 검증”은 우선순위에서 내려야 합니다. 두 릴리스 모두 이 문제를 고치는 런타임 변경이 없습니다.

이 세션에서 중요한 결과는 코드가 아니었습니다. 가능성이 낮은 해결책을 실제 변경 전에 제외하고, 캐시 갱신 경로에만 연결 수명을 분리하는 더 작은 방법으로 범위를 좁힌 것이 결과였습니다.

증상 확인
→ 실제 호출 경로 조사
→ 해결 후보 비교
→ 공식 변경 내역 확인
→ 패키지 실행 파일 비교
→ 잘못된 후보 제외
→ 권장안 수정

두 번째 세션: 잘못된 맥락을 발견하자 결론을 다시 냈습니다

Rona의 새로운 코칭 흐름을 검토할 때는 슬랙에서 오간 의견을 바탕으로 먼저 기획·개발 관점의 우려를 정리했습니다.

그런데 제가 “작업 브랜치의 정본 문서도 읽어봤어?”라고 다시 물었습니다. 확인 결과, 에이전트는 슬랙 대화만 읽었고 실제 브랜치 문서는 확인하지 않은 상태였습니다.

에이전트는 이전 답변을 방어하지 않았습니다. 원격 브랜치의 최신 커밋과 정본 문서를 다시 읽고, 앞선 문안은 그대로 공유하면 안 된다고 정정했습니다. 그리고 실제 설계에 이미 반영된 내용과 아직 남아 있는 저장 구조의 문제를 구분했습니다.

이 경험을 통해 모델의 추론 능력보다 먼저 확인해야 할 것이 있다는 점을 알게 됐습니다.

에이전트가 충분히 똑똑한가보다, 올바른 자료를 보고 있는가가 먼저였습니다.

Uber도 같은 모델에 같은 질문을 주고, 관련 맥락을 제공했을 때와 제공하지 않았을 때의 결과를 비교했습니다. 맥락이 있는 에이전트는 38초 만에 정확한 답을 찾았지만, 맥락이 없는 에이전트는 20분 동안 코드를 탐색하고 하위 에이전트까지 사용한 뒤 잘못된 결론을 냈습니다.

제 세션에서도 비슷한 일이 작은 규모로 일어났습니다. 코드, 원격 브랜치, 작업 문서, 과거 결정 가운데 어떤 자료를 먼저 찾아야 하는지가 결과를 바꿨습니다.

세 번째 세션: 큰 구현은 여러 작업대로 나뉘었습니다

포털의 접근 권한 정책을 일반화하는 작업은 한두 파일을 고치는 수준이 아니었습니다. 공개 목록, 게시글 상세, 관련 글, 시리즈, 외부 도구 조회처럼 같은 정책을 통과해야 하는 경로가 여러 곳에 흩어져 있었습니다.

이 작업에서 에이전트는 먼저 현재 기준 테스트 258개가 통과하는지 확인했습니다. 이후 공개 조회, 관련 글, 시리즈, 공통 정책과 같은 경계로 조사 범위를 나눴습니다.

각 범위에서는 코드부터 수정하지 않고, 새로운 비공개 공간이 노출되는 실패 테스트를 먼저 만들었습니다. 실패가 확인된 뒤 공통 정책을 최소한으로 수정하고, 마지막에 변경 내용을 합쳐 타입 검사와 린트, 데이터베이스 통합 테스트를 다시 실행했습니다.

과거 결정과 현재 코드 확인
→ 기준 테스트 확인
→ 노출 경로별 조사
→ 실패하는 회귀 테스트 작성
→ 최소 구현
→ 변경 통합
→ 타입·린트·통합 테스트
→ 우회 경로 재검토

모든 개발 요청에 이 절차가 적용되는 것은 아닙니다. 문구 한 줄을 바꾸는 작업에는 필요하지 않습니다. 여러 경로가 같은 권한 정책을 공유하는 작업이었기 때문에 에이전트가 조사와 구현을 나누고, 마지막에 통합 검증을 선택했습니다.

제가 작업 순서를 하나씩 지시한 것이 아니라, 요청과 위험 범위를 본 에이전트가 필요한 개발 흐름을 구성했습니다.

네 번째 세션: 준비가 끝나도 운영 반영은 멈췄습니다

스터디 운영 데이터를 새로운 구조로 옮기는 작업에서는 코드와 실행 패키지가 준비됐습니다. 로컬 검사와 체크섬 검증도 통과했습니다.

하지만 실제 운영 경로를 확인하자 여러 자동화가 동시에 같은 데이터를 작성할 가능성이 남아 있었습니다. 새 저장소에 데이터를 넣는 것과 기존 자동화를 끄는 순서도 확정되지 않았습니다.

에이전트는 로컬 준비가 끝났다는 이유로 작업을 완료했다고 보고하지 않았습니다.

로컬 준비 상태와 운영 적용 상태를 분리했습니다.
실제 운영 데이터 변경은 0건으로 유지했습니다.
충돌 가능성을 해결하기 전까지 NO-GO를 유지했습니다.
운영 변경은 명시적인 승인 이후에만 시작했습니다.

이 세션에서는 멈춘 것이 실패가 아니라 올바른 결과였습니다.

코딩 에이전트라면 준비된 코드를 실행하는 데 집중할 수 있습니다. 개발 공정을 운영하는 에이전트라면 지금 실행해도 되는지까지 판단해야 합니다.

다섯 번째 세션: 완료 조건도 작업 크기에 따라 달라졌습니다

개발 흐름을 정리하면서 여러 도구를 계속 추가하면 절차만 복잡해질 수 있다는 문제도 있었습니다.

그래서 하나의 상위 흐름이 요청을 분류하도록 두고, 큰 작업에만 별도의 완료 조건을 적용했습니다.

요구사항 확인
→ 필요한 경우 계획 검토
→ 구현
→ 리뷰와 QA
→ 반영 또는 배포
→ 실서비스 확인

인증, 결제, 마이그레이션, 운영 데이터처럼 결과를 빠뜨리면 위험한 작업에는 관찰 가능한 완료 조건을 적고 마지막에 다시 검증합니다. 반면 작은 수정과 단순한 설명에는 이 절차를 강제하지 않습니다.

새로운 검증 도구를 적용할 때도 기존 개발 흐름을 대체하지 않았습니다. 큰 작업의 완료 증거만 관리하는 보조 단계로 제한했고, 특정 커밋으로 고정한 뒤 전체 테스트 146개를 실행해 설치 상태를 확인했습니다.

다섯 세션에서 반복된 하나의 흐름

작업의 내용은 달랐지만, 반복되는 구조가 있었습니다.

결과 요청
→ 작업 성격과 위험 판단
→ 필요한 정본과 현재 상태 확인
→ 필요한 경우 작업 분리
→ 구현 또는 조사
→ 결과 검증
→ 완료·우려 있음·중단 상태 결정

제가 매번 “먼저 조사하고, 다음에는 테스트를 만들고, 마지막에는 배포를 확인해줘”라고 말하지는 않습니다. 에이전트가 작업 성격을 보고 필요한 단계에서 시작하고, 근거가 부족하면 다음 단계로 넘어가지 않습니다.

이 지점에서 제 개발 환경은 작은 Software Factory와 닮아 있었습니다.

하지만 아직 ‘효율적인’ 공장인지는 알 수 없었습니다

Uber와 비교하니 빠진 부분도 분명하게 보였습니다.

세션마다 실제로 사용한 토큰과 비용을 모으지 않았습니다.
어떤 작업에 어떤 모델이 가장 효율적인지 비교하지 않았습니다.
병합된 PR 한 건이나 해결된 장애 한 건의 비용을 측정하지 않았습니다.
에이전트가 잘못된 경로에서 사용한 요청과 시간을 자동으로 찾지 않았습니다.
세션에서 발견한 문제를 자동으로 스킬 개선까지 연결하지 않았습니다.

지금까지는 개발 공정이 안전하게 작동하는지를 먼저 만들었습니다. 하지만 그 공정이 얼마나 적은 비용과 시행착오로 결과에 도달하는지는 측정하지 않았습니다.

따라서 이번에 내린 결론은 “나도 Uber와 같은 Software Factory를 만들었다”가 아닙니다.

내 Codex는 이미 코드를 작성하는 도구를 넘어 개발 공정을 운영하고 있었습니다. 다만 개발 흐름은 만들었지만, 그 흐름의 효율은 아직 측정하지 않고 있었습니다.

다음 작업부터 네 가지를 기록해보려고 합니다

Uber처럼 정교한 비용 시스템을 바로 만들 필요는 없습니다. 우선 다음 네 가지부터 기록해보려고 합니다.

요청부터 검증된 결과까지 걸린 시간
사람이 방향을 다시 잡아준 횟수
잘못된 가설이나 구현을 되돌린 횟수
최종 상태가 완료, 우려 있음, 중단 가운데 무엇이었는지

이 정도만 기록해도 “더 강한 모델을 사용해서 좋아졌다”와 “에이전트가 덜 헤매서 좋아졌다”를 조금 더 정확하게 구분할 수 있습니다.

비슷하게 확인해보고 싶다면

이미 Codex나 다른 개발 에이전트를 사용하고 있다면, 새로운 도구부터 설치하기 전에 최근 작업 기록을 먼저 확인해볼 수 있습니다.

최근 완료한 개발 세션 5개를 확인해줘.

각 세션에서 다음 내용을 정리해줘.
- 사용자가 요청한 최종 결과
- 에이전트가 선택한 조사·구현·검증 단계
- 사람이 다시 방향을 잡아준 지점
- 구현하지 않고 멈춘 판단
- 실제로 확인한 완료 증거

공통으로 반복된 개발 흐름과 아직 측정하지 않는 항목을 구분해줘.

새로운 AI 개발 도구를 추가하는 것보다, 지금 사용하는 에이전트가 실제로 어떻게 일하고 있는지 확인하는 일이 먼저일 수 있습니다.

저는 최근 세션을 다시 보면서, AI에게 코딩만 맡기고 있지 않았다는 사실을 알게 됐습니다. 에이전트는 이미 조사하고, 작업을 나누고, 검증하고, 때로는 멈추면서 개발 공정을 운영하고 있었습니다.

이제 다음 질문은 어떤 모델이 코드를 더 잘 작성하는지가 아닙니다.

이 개발 공정은 검증된 결과에 얼마나 적은 시행착오로 도달하고 있을까요?

🔥<24기 AI 스터디> 얼리버드 신청하기 🔥