몇 년 전만 해도 15개 소프트웨어 프로젝트를 동시에 진지하게 리뷰한다는 생각은 비현실적으로 느껴졌을 것이다. 15개 repository를 열어 대충 보는 얘기가 아니다. 실제 운영하는 프로젝트를 버그, 잘못된 가정, SEO 문제, 번역 오류, 현지화 불일치, 누락된 테스트, regression, 그리고 시스템의 나머지 부분과 더 이상 맞지 않는 오래된 코드까지 반복해서 점검하는 것을 말한다.
병목은 타이핑 속도가 아니었다. 주의력이었다. 프로젝트마다 역사와 규칙, edge case가 있고, 잘못 보이지만 의도적으로 존재하는 코드가 있다. 제대로 된 review는 읽고, 검색하고, 비교하고, check를 실행한 뒤에야 무엇을 바꿔야 하는지 판단할 수 있다.
Codex는 이런 반복 작업의 비용 구조를 바꿨다. repository를 첫 번째로 훑고, reference를 따라가고, 관련 파일을 살펴보고, 의심스러운 pattern을 찾고, 테스트 아이디어를 제안하고, 예전에는 내가 하나씩 열어보던 영역을 조사하는 데 도움을 준다. 최종 결정이 자동화되는 것은 아니다. 결정을 내리기 전 가장 비싼 조사 과정이 훨씬 빨라지는 것이다.
내가 가장 중요하게 생각하는 원칙은 간단하다. Codex를 써서 나를 review loop에서 빼는 것이 아니라, 내가 리뷰할 수 있는 범위를 넓힌다.
진짜 병목은 코딩이 아니라 반복
한 프로젝트만 유지할 때는 놀랄 만큼 많은 context를 기억할 수 있다. 프로젝트가 많아지면 그 방식은 확장되지 않는다. 같은 종류의 일이 계속 반복된다.
- 서로 다른 component에서 비슷한 버그 찾기;
- refactor 후 오래된 call site가 남았는지 확인하기;
- 행동이 바뀐 뒤 테스트 검토하기;
- metadata, 언어 규칙, heading, internal link 불일치 찾기;
- localization key와 번역 내용 비교하기;
- 빠진 error handling과 edge case 찾기;
- “작은” 변경이 예상보다 많은 파일을 건드렸는지 확인하기;
- 각각은 단순하지만 합치면 시간을 많이 먹는 diff 읽기.
화려한 일은 아니다. 하지만 전부 중요하다. 같은 종류의 review를 여러 codebase에서 반복하면 비용이 매우 커진다.
AI coding agent가 내게 가장 유용한 부분이 바로 여기다. 검색 공간의 반복적인 부분을 대신 처리해서 나는 판단에 더 많은 주의를 쓸 수 있다.
처음부터 모든 것을 고치라고 하지 않는다
나쁜 결과를 얻기 쉬운 방법 중 하나는 “프로젝트 전체를 리뷰하고 전부 고쳐줘” 같은 큰 작업을 주는 것이다. 효율적으로 보이지만 discovery, 우선순위, architecture, implementation, validation을 하나의 통제되지 않은 task에 섞는다.
단계를 나누면 훨씬 나은 결과가 나온다.
inspect → explain findings → prioritize → change → validate → review diff먼저 agent가 관련 영역을 이해하고 무엇을 찾았는지 설명하길 원한다. 구체적인 파일 경로, 영향받는 코드, 왜 의심스러운지, 어떤 영향이 가능한지가 필요하다. 수정은 그 다음이다.
AI는 아주 자신 있게 틀릴 수 있기 때문이다. 불필요해 보이는 코드가 오래된 브라우저, payment edge case, migration path, 혹은 한 파일만 봐서는 알 수 없는 business rule 때문에 존재할 수 있다. 먼저 inspect하면 잘못된 가정이 거대한 diff로 커지기 전에 멈출 수 있다.
Finding은 판결이 아니라 단서로 본다
좋은 Codex review는 “17개 문제를 찾았습니다”로 끝나지 않는다. 숫자 자체는 거의 의미가 없다. 중요한 것은 evidence다.
실제로 행동할 수 있는 finding이라면 다음을 알고 싶다.
- 문제가 어디에 있는가;
- 왜 문제인가;
- 어떤 동작이 실패할 수 있는가;
- 결론에 얼마나 확신해야 하는가;
- 어떤 check로 확인하거나 반박할 수 있는가;
- 가장 작은 안전한 fix는 무엇인가.
특히 security, SEO, business logic에서 중요하다. Agent가 조사할 지점을 알려줄 수는 있지만 security처럼 들리는 설명이 곧 검증된 취약점은 아니다. SEO warning이 바로 ranking 문제는 아니다. 이상한 조건이 자동으로 dead code도 아니다.
AI는 후보를 찾는 비용을 줄인다. 무엇이 진짜인지 결정하는 것은 여전히 검증이다.
Workflow를 신뢰할 수 있게 만드는 것은 validation loop
코드 생성은 AI-assisted development에서 가장 눈에 띄는 부분이지만 production에서 중요한 것은 validation이다.
변경 뒤에는 codebase가 답을 줘야 한다. 프로젝트에 따라 다음을 사용할 수 있다.
- TypeScript 또는 다른 compiler/type checker;
- lint;
- unit/integration test;
- build check;
- 오래된 이름이나 call site에 대한 targeted search;
- 최종 diff 수동 review;
- 사용자에게 보이는 동작의 수동 검증.
정확한 command보다 loop 자체가 중요하다. Agent가 가정을 만들고, repository가 evidence를 반환하고, 다음 결정이 그 evidence를 기반으로 이루어진다.
그래서 AI-assisted work에서는 강한 타입 시스템이 있는 프로젝트를 특히 좋아한다. 별도 글에서 TypeScript가 실제 software delivery에서 Codex와 잘 맞는 이유를 썼다. 타입은 많은 잘못된 가정을 즉시 machine-readable feedback으로 바꿔준다.
AI와 특히 잘 맞는 review 영역
버그와 regression
Agent는 여러 파일을 지나가는 값을 추적하고 callers를 확인하고 비슷한 구현을 비교하고 서로 맞지 않는 branch를 찾을 수 있다. 증상의 근원을 좁히는 데 유용하다. 하지만 결론을 믿기 전에 나는 실제 동작을 재현하거나 다른 방식으로 검증한다.
테스트
동작이 바뀌었는데 test coverage가 따라오지 않은 부분을 찾고, edge case를 제안하고, 기존 테스트가 실제로 무엇을 보호하는지 설명하는 데 AI가 유용하다. 사용자 행동이 아니라 구현 디테일만 검사하는 테스트도 드러낼 수 있다.
SEO
Technical SEO에는 consistency work가 많다. metadata, language alternate, indexability, internal link, template, sitemap generation, redirect, page-level convention 등이 있다. Agent는 큰 codebase 전체에서 이런 규칙을 내가 route마다 직접 여는 것보다 빠르게 비교할 수 있다. 하지만 기술적 올바름과 콘텐츠가 실제로 ranking을 받을 가치가 있는지는 별개로 본다.
현지화와 번역
다국어 제품에서 가장 반복적인 영역 중 하나다. AI는 key를 비교하고, 누락값을 찾고, 잘못된 언어 혼합을 감지하고, placeholder를 확인하고, locale 간 구조가 어긋난 지점을 보여줄 수 있다. 큰 translation object를 손으로 보는 것보다 빠르지만 중요한 copy는 여전히 사람의 판단이 필요하다.
Refactoring 이후 일관성
큰 refactor는 지루한 이유로 자주 깨진다. 오래된 import 하나가 남고, route 하나가 예전 field name을 쓰고, test fixture 하나가 옛 shape를 유지한다. Repository-wide search와 변경 의도를 이해하는 agent의 조합이 특히 유용하다.
Parallel work는 task가 독립적일 때만 도움 된다
많은 agent를 켜고 동시에 모든 것을 바꾸게 하는 것은 매력적이다. throughput을 높일 수 있지만 conflict와 서로 다른 가정도 같이 늘릴 수 있다.
나는 parallelism을 coordination 문제로 본다. 독립적인 audit은 좋은 후보다. 한 프로젝트는 localization을 확인하고 다른 프로젝트는 test review를 할 수 있고, 서로 다른 repository를 동시에 조사할 수도 있다. 같은 architecture를 공유 계획 없이 두 agent가 다시 쓰는 것은 완전히 다른 문제다.
병렬성이 높아질수록 경계가 중요하다. 명확한 project, task, definition of done, 그리고 따로 review할 수 있는 result가 필요하다.
목표는 실행 중인 agent 수를 최대화하는 것이 아니라 유용하고 검증 가능한 progress를 최대화하는 것이다.
맹목적으로 위임하지 않는 것
- Architecture 결정: 모델은 선택지를 제안할 수 있지만 장기 trade-off는 repository 밖의 context에 달릴 수 있다.
- Security 결론: finding은 검증, threat context, 때로는 전문 도구가 필요하다.
- Business rule: 코드는 내부적으로 일관돼도 잘못된 제품 동작을 구현할 수 있다.
- 큰 파괴적 refactor: 거대한 diff는 이해하기 어렵고 부주의하게 승인하기 쉽다.
- Production deployment: test가 통과했다고 운영 risk가 사라지는 것은 아니다.
- Final review: 내 이름을 붙이기 전에 무엇이 바뀌었는지 알고 싶다.
AI가 이런 영역에서 쓸모없어서가 아니다. 그럴듯하지만 틀린 답의 비용이 특히 높은 영역이기 때문이다.
AI review는 static analysis를 대체하지 않는다
Codex를 compiler, linter, test, scanner, monitoring의 대체품으로 보지도 않는다. 이런 도구는 AI가 가지지 못한 장점이 있다. 범위가 좁고, deterministic하며, 반복 가능하다.
가장 강한 workflow는 둘을 결합한다. Codex는 context를 보고 어디를 볼지 제안할 수 있다. Static tool은 정확한 규칙을 강제한다. Test는 동작을 검증한다. Log와 monitoring은 현실에서 무엇이 일어나는지 보여준다. Human review는 이 모든 신호를 product intent와 연결한다.
이 feedback systems가 없다면 AI를 더 신뢰하는 것이 아니라 덜 신뢰할 것이다.
가장 큰 생산성 향상은 attention 배분이 좋아지는 것
“Codex가 시간을 절약한다”라고 말하기 쉽지만 내게는 그보다 큰 변화다.
소프트웨어 개발에서 희소한 자원은 keystroke가 아니라 고품질 attention이다. AI coding agent 이전에는 그 attention의 큰 부분이 반복적인 discovery에 쓰였다. 같은 pattern 검색, 비슷한 파일 읽기, reference 추적, 변경이 모두 반영됐는지 확인, 다른 repository에서 동일한 audit 반복.
이제는 first-pass work를 더 많이 agent에게 맡기고, 내 attention은 자동화하기 어려운 판단에 남겨둘 수 있다. finding이 중요한가? fix가 architecture에 맞는가? UX가 좋아지는가? risk가 허용 가능한가? 정말 ship하고 싶은가?
그래서 여러 프로젝트를 유지하고 review하는 감각이 달라졌다. review를 덜 하는 것이 아니다. 기계적인 부분이 모든 예산을 먹지 않기 때문에 더 많이 review할 수 있는 경우가 많다.
내가 신뢰하는 workflow
- 좁은 review 목표를 정한다. Bug, test, SEO, localization, refactor 등 구체적인 영역.
- Edit 전에 inspect시킨다. 먼저 evidence와 영향 위치가 필요하다.
- Finding을 우선순위화한다. 모든 이론적 문제를 수정할 필요는 없다.
- 변경 범위를 제한한다. 작고 일관된 diff가 검증하기 쉽다.
- Machine check를 실행한다. Typecheck, lint, test, build, search 또는 프로젝트별 validation.
- Diff를 직접 읽는다. 불필요한 rewrite, 잘못된 가정, 빠진 edge case, scope 밖 변경을 찾는다.
- 중요한 동작을 검증한다. 특히 users, money, security, SEO, production infrastructure.
- 그 뒤 다음 프로젝트로 간다. Parallelism은 유용하지만 미해결 불확실성이 전파되면 안 된다.
15개 프로젝트가 더 이상 15배의 review 일처럼 느껴지지 않는다
Codex가 15개 프로젝트를 단순하게 만든 것도, 책임을 없앤 것도 아니다. 바꾼 것은 scale과 반복 effort의 관계다.
더 깊은 first pass, 더 넓은 consistency check, 더 많은 test idea, 더 systematic한 audit을 할 수 있고, 모든 파일을 내가 직접 찾아다니는 데 모든 시간을 쓰지 않아도 된다. 그만큼 남은 attention을 여전히 개발자가 필요한 결정에 쓸 수 있다.
내가 가치 있다고 보는 AI-assisted development는 이런 형태다. autopilot도 아니고, 맹목적 신뢰도 아니고, “뭔가 통과할 때까지 코드를 생성”하는 것도 아니다. Machine-scale inspection과 human-scale judgment를 더 짧은 loop로 연결하는 것이다.
이것이 내가 보는 Codex의 진짜 leverage다. Review를 없애는 것이 아니라, 예전에는 유지하기 어려웠던 규모에서도 진지한 review를 가능하게 만든다.