책에 포함된 노트요즘 바이브 코딩: Codex로 일하는 개발자의 완전 가이드

PART 06-24. AI 시대 개발자의 일하는 법

2026-04-25Views 90약 10분생성형 AI 활용

Chapter 24. AI 시대 개발자의 일하는 법

AI 코딩 도구가 좋아질수록 개발자의 일이 사라질 것 같다고 느끼는 순간이 있다. 그런데 실무에서는 조금 다른 일이 벌어진다. 코드 한 줄을 직접 쓰는 시간은 줄어드는데, 무엇을 만들지 정하고, 어디까지 맡길지 경계를 긋고, 결과를 검수하는 시간은 오히려 더 중요해진다.

핵심은 단순하다. 도구를 잘 쓰는 법보다 더 중요한 것은, 그 도구 때문에 내 일이 어떻게 바뀌는지 이해하는 것이다. Codex를 잘 다루는 사람은 프롬프트를 화려하게 쓰는 사람이 아니라, 일을 잘게 나누고, 맥락을 정리하고, 검증 루프를 설계하는 사람이다.

PART 06-24. AI 시대 개발자의 일하는 법

코드를 쓰는 사람에서, 일을 설계하는 사람으로

OpenAI가 Codex를 실무형 에이전트로 다루는 방식에서 가장 인상적인 표현은 이것이다. 소프트웨어 팀의 주된 일이 더 이상 코드를 직접 쓰는 것만이 아니라, 환경을 설계하고, 의도를 명확히 적고, 신뢰할 수 있는 피드백 루프를 만드는 일로 옮겨간다는 점이다.¹ 이 문장을 조금 풀어 말하면, 개발자의 중심 업무가 구현에서 운영 가능한 위임으로 이동하고 있다는 뜻이다.

예전 개발자가 직접 벽돌을 쌓는 사람이었다면, 이제의 개발자는 공정표를 짜고, 작업자에게 지시하고, 검사표로 결과를 확인하는 현장소장에 가깝다. 벽돌을 아예 안 쌓는다는 뜻은 아니다. 다만, 언제 직접 쌓고 언제 맡길지 판단하는 능력이 훨씬 중요해진다.

Codex 같은 에이전트가 강해질수록 개발자의 일은 대략 아래처럼 바뀐다.

예전의 중심 업무	지금 더 중요해진 업무
함수 직접 구현	작업 범위 정의
버그를 손으로 추적	재현 조건과 로그를 정리해 에이전트에 위임
코딩 스타일 통일	AGENTS.md, Skills, 정책 파일로 작업 방식 표준화
테스트를 나중에 추가	검증 기준을 먼저 선언
PR 리뷰에서 문법 지적	아키텍처, 리스크, 제품 의도 검토

이 변화는 단지 사용자 입장의 느낌이 아니다. Codex 관련 역할 설명에서도 반복해서 등장하는 키워드는 성능, 지연 시간, 신뢰성, 비용, 용량, 실사용 피드백 루프, 그리고 "연구 성능을 실제 유용성으로 바꾸는 일"이다.² 다시 말해, 이제 좋은 개발자는 코드를 많이 생산하는 사람이라기보다, 에이전트가 실제 환경에서 유용하게 일하도록 만드는 사람이다.

에이전트 매니저의 네 가지 책임

에이전트 시대의 개발자는 팀장 비슷한 일을 한다. 사람 대신 AI에게도 일을 맡기지만, 책임은 여전히 사람에게 남아 있다. 그래서 실무에서 중요한 책임은 네 가지로 정리할 수 있다.

일을 잘게 나누는 책임
맥락과 제약을 문서로 남기는 책임
검증 기준을 먼저 정의하는 책임
결과를 승인하거나 되돌리는 책임

첫째, 일을 잘게 나눠야 한다. "회원가입 만들어줘"는 너무 크다. "Next.js + Supabase 프로젝트에서 이메일 매직 링크 로그인 UI 추가, 로그인 성공 시 /dashboard 리다이렉트, 실패 시 토스트 표시, 기존 테스트는 깨지지 않게 유지" 정도는 되어야 에이전트가 덜 헤맨다.

둘째, 맥락과 제약을 문서화해야 한다. 이 책에서 계속 강조한 AGENTS.md, Skills, Plugins, Automations는 단순한 편의 기능이 아니다. 팀이 축적한 판단 기준을 에이전트가 재사용할 수 있게 만드는 장치다. 사람이 바뀌어도 팀의 일하는 방식이 남는다는 뜻이다.

셋째, 검증 기준을 먼저 정해야 한다. 테스트 통과, 타입 에러 0개, Lighthouse 점수, API 응답 시간, 롤백 절차 여부 같은 기준이 없으면 에이전트는 "대충 그럴듯한 결과"를 낸다. AI가 만든 결과물이 특히 위험한 이유가 여기 있다. 그럴듯함과 정답은 다르다.

넷째, 최종 승인 책임은 여전히 사람에게 있다. 에이전트는 제안할 수 있지만, 배포 사고의 책임을 대신 져주지는 않는다. 그래서 실무에서 중요한 질문은 "AI가 할 수 있나?"가 아니라 "내가 이 결과를 승인할 근거가 충분한가?"다.

사양을 정확히 쓰는 능력이 새로운 기술이 된다

AI 시대에 가장 비싸지는 역량 중 하나는 놀랍게도 타이핑 속도가 아니다. 사양 작성력이다.

여기서 말하는 사양은 거창한 문서만 뜻하지 않는다. 작업 요청서, 이슈 설명, PRD, 구현 계획서, 테스트 조건, 수용 기준까지 전부 포함한다. 쉽게 말해, "무엇을 어떻게 끝내면 완료인가"를 명확하게 적는 능력이다.

연구에서도 요구사항 생성, 리팩터링, 품질 개선 같은 소프트웨어 엔지니어링 작업에서 프롬프트 패턴과 명확한 구조화가 성능 차이를 만든다고 설명한다.³ 즉, AI에게 일을 잘 맡기는 능력은 감이 아니라 기술이다.

좋은 사양은 대개 다음 요소를 가진다.

목적: 왜 이 작업을 하는가
범위: 어디까지 바꾸고 어디는 건드리지 않는가
입력과 출력: 어떤 파일, 화면, API가 바뀌는가
제약: 사용 기술, 성능, 보안, 디자인 규칙
검증: 완료를 무엇으로 판단하는가

예를 들어, 나쁜 요청은 이렇다.

"결제 페이지 좀 개선해줘."

좋은 요청은 이렇게 바뀐다.

"Next.js + Supabase 기반 결제 페이지에서 모바일 화면 기준 이탈률을 줄이기 위해 CTA를 상단에 고정해 달라. Stripe 결제 로직은 변경하지 말고, UI 레이아웃과 에러 메시지 문구만 수정한다. 기존 Playwright 결제 성공 시나리오와 실패 시나리오는 통과해야 하며, 한글 텍스트 줄바꿈이 깨지지 않게 확인한다."

두 요청의 차이는 문장 길이가 아니다. 판단 가능한 조건의 유무다. 에이전트는 마음을 읽지 못한다. 대신 조건을 읽는다.

실무에서 사양 작성력이 중요한 이유는 세 가지다.

첫째, 속도가 빨라진다. 에이전트가 첫 시도부터 덜 엉뚱하게 움직인다. 둘째, 비용이 줄어든다. 되돌리기와 재시도가 줄어든다. 셋째, 팀 협업이 쉬워진다. 사람과 AI가 같은 문서를 기준으로 움직일 수 있다.

결국 앞으로의 개발자는 "잘 만든다" 이전에 "잘 정의한다"를 배워야 한다. 정의가 부정확하면 구현 속도가 아무리 빨라도 전체 팀은 느려진다.

코드 리뷰 능력이 더 비싸지는 이유

많은 사람이 AI가 코드를 잘 쓰게 되면 리뷰의 가치가 떨어질 거라고 생각한다. 실제로는 반대다. 코드 작성이 쉬워질수록, 리뷰는 더 비싸진다.

이유는 간단하다. 생산은 싸져도 승인 책임은 여전히 비싸기 때문이다.

AI는 스타일 위반, 중복 로직, 단순 리팩터링, 빠진 예외 처리 같은 1차 검토를 꽤 잘 해낸다. 여러 가이드에서도 AI 코드 리뷰는 사람을 대체하기보다, 빠른 초안 검토와 개선 제안을 통해 인간 리뷰어를 보강하는 방식으로 설명된다.⁴⁵ 실무 감각으로 바꾸면, 예전에는 사람이 일일이 보던 사소한 지적을 AI가 먼저 걸러주고, 사람은 더 비싼 질문에 집중하게 된다는 뜻이다.

그 더 비싼 질문은 보통 이런 것들이다.

이 변경이 제품 의도와 맞는가
장애가 나면 어디서 무너지는가
이 설계가 3개월 뒤에도 유지보수 가능한가
테스트가 통과해도 실제 운영 리스크는 없는가
보안, 개인정보, 비용 측면에서 숨은 문제가 없는가

예를 들어 Codex가 Express + MongoDB 백엔드에서 주문 조회 API를 멋지게 리팩터링했다고 하자. 테스트도 통과했고 응답도 빨라졌다. 그런데 리뷰어가 봐야 할 핵심은 따로 있다. 인덱스 전략이 맞는지, 관리자 권한 검증이 누락되지 않았는지, N+1 쿼리 비슷한 접근 패턴이 숨어 있지 않은지, 캐시 무효화가 꼬이지 않는지 같은 문제다. 이건 단순 문법 검토가 아니라 시스템 감각의 영역이다.

그래서 AI 시대 리뷰어의 가치는 코드 줄수에서 나오지 않는다. 질문의 수준에서 나온다. 좋은 리뷰어는 "이 코드 예쁘네요"라고 말하는 사람이 아니라, "이 변경이 운영에 어떤 파장을 만들지"를 먼저 보는 사람이다.

주니어, 미들, 시니어의 기준도 바뀐다

경력 연차는 그대로인데 기대 역할은 달라진다. AI 시대에는 같은 3년 차 개발자라도 훨씬 넓은 범위를 커버할 수 있다. 반대로 말하면, 연차만으로 시니어처럼 보이던 시대는 빨리 끝난다.

주니어는 '구현자'보다 '검증 가능한 실행자'가 되어야 한다

주니어에게 가장 중요한 것은 이제 "혼자 다 짠다"가 아니다. 오히려 다음이 더 중요하다.

주어진 작업을 작은 단위로 나누기
Codex에 맡긴 결과를 실행하고 검증하기
모르는 부분을 숨기지 않고 근거와 함께 질문하기
테스트와 로그를 읽고 실패 이유를 설명하기

주니어가 AI를 잘 쓴다는 것은 멋진 프롬프트를 외우는 게 아니다. 에이전트가 낸 답을 그대로 복붙하지 않고, 왜 맞는지 확인하는 태도를 갖는 것이다.

미들은 '속도 담당'이 아니라 '흐름 담당'이 된다

미들 개발자는 이제 팀에서 가장 먼저 자동화를 체계로 바꾸는 사람이어야 한다. 자주 반복되는 작업을 Skills로 만들고, 팀 룰을 AGENTS.md로 정리하고, 반복 검증을 Automations로 옮기는 사람이 미들의 핵심 가치가 된다.

예를 들어 팀에서 매주 하는 작업이 있다고 하자. PR 리뷰 요약, CI 실패 원인 정리, changelog 생성, 배포 전 체크리스트 검토 같은 일들이다. 예전에는 성실한 사람이 이걸 많이 했다. 이제는 미들 개발자가 이런 흐름을 Codex 워크플로로 바꿔야 한다. "잘 한다"보다 "계속 잘 되게 만든다"가 중요해진다.

시니어는 '답을 내는 사람'보다 '판단 체계를 만드는 사람'이 된다

시니어의 역할은 더 분명해진다. 팀의 판단 기준을 시스템으로 남기는 것이다. 어떤 작업은 never approval로 못 하게 하고, 어떤 MCP 서버만 허용할지 정하고, 어떤 PR은 자동 머지 전에 사람이 반드시 보게 만드는 식의 규칙을 설계해야 한다.

즉, 시니어는 이제 가장 코드를 많이 치는 사람이 아니라, 팀이 AI와 함께 일할 때도 품질이 무너지지 않도록 경계선을 만드는 사람이다. 좋은 시니어는 에이전트를 많이 돌리는 사람이 아니라, 에이전트가 팀을 망치지 않게 하는 사람이다.

앞으로 3년, 어떤 개발자가 살아남을까

조금 현실적으로 말해보자. 앞으로 3년 동안 강해질 개발자는 대체로 아래 특징을 가진다.

요구사항을 모호하게 두지 않고 문서로 고정하는 사람
AI가 만든 결과를 검증 가능한 단위로 쪼개는 사람
리뷰에서 제품, 운영, 보안 관점을 동시에 보는 사람
개인 노하우를 AGENTS.md, Skills, Plugins, Automations로 자산화하는 사람
새 도구가 나와도 원리 중심으로 빨리 적응하는 사람

반대로 위험한 패턴도 뚜렷하다.

첫째, AI가 낸 코드를 빠르게 붙이는 데만 익숙한 사람이다. 속도는 빨라 보이지만, 장애가 나면 왜 그런지 설명하지 못한다. 둘째, 모든 문제를 모델 성능 탓으로 돌리는 사람이다. 사실은 작업 분해와 검증 루프 설계가 약한 경우가 많다. 셋째, 팀의 지식을 자기 머릿속에만 두는 사람이다. AI 시대에는 문서화되지 않은 숙련이 생각보다 빨리 가치가 떨어진다.

한국 개발자를 위한 현실적인 커리어 전략

이제 가장 중요한 질문으로 가보자. 그래서 나는 뭘 해야 할까?

거창한 답보다 현실적인 답이 필요하다. 특히 한국 개발자에게는 회사 일, 사이드 프로젝트, 취업 시장, 그리고 빠르게 바뀌는 도구 사이에서 균형을 잡는 전략이 중요하다.

1. "AI를 쓸 줄 안다"보다 "AI와 함께 끝낸 결과"를 남겨라

이력서에 "Codex 활용 가능"이라고 쓰는 것보다, 아래 같은 결과물이 훨씬 강하다.

Next.js + Supabase SaaS를 기획부터 배포까지 만든 기록
PRD, 구현 계획서, AGENTS.md, SKILL.md가 함께 들어 있는 레포
Codex가 만든 PR을 어떻게 리뷰하고 수정했는지 남긴 사례
장애 대응이나 배포 자동화 루프를 만든 경험

이런 포트폴리오는 단순 사용 경험이 아니라 운영 능력을 보여준다. 회사가 원하는 건 도구 사용자보다, 결과를 관리할 수 있는 사람이다.

2. 개인 생산성보다 팀 재현성을 먼저 배워라

혼자서만 빠른 사람은 생각보다 덜 귀하다. 팀원이 들어와도 같은 품질이 나오게 만드는 사람이 더 귀하다. 그래서 커리어 초중반에는 개인 프롬프트 비법보다 팀 표준화 경험을 쌓는 편이 훨씬 유리하다.

예를 들면 이런 것이다.

프로젝트용 AGENTS.md를 작성해 팀 규칙을 정리했다
PR 리뷰 스킬을 만들어 반복 검토 품질을 맞췄다
배포 전 자동 점검 Automations를 구성했다
MCP 연결 범위와 승인 정책을 문서화했다

이건 그냥 "AI 좀 써봤어요"와는 급이 다르다. 조직은 이런 사람을 놓치기 싫어한다.

3. 리뷰 능력은 절대 외주화하지 마라

구현은 점점 더 위임할 수 있다. 하지만 리뷰 능력은 커리어의 마지막 방어선이다.

리뷰 능력을 키우려면, 매번 Codex가 만든 결과에서 다음 질문을 해보면 좋다.

이 변경의 가장 큰 운영 리스크는 무엇인가
실패했을 때 롤백 경로는 있는가
테스트가 놓치는 실제 사용자 시나리오는 무엇인가
지금은 맞아도 한 달 뒤 깨질 가정은 없는가

이 질문을 습관처럼 던질 수 있으면, 도구가 바뀌어도 살아남는다.

4. 비개발자 바이브 코더라면 '구현'보다 '경계 이해'에 투자하라

비개발자 독자에게도 같은 원칙이 적용된다. 오히려 더 중요하다. 화면 하나 만드는 것은 AI 덕분에 쉬워졌다. 하지만 인증, 결제, 개인정보, 운영 장애, 비용 폭주 같은 경계는 여전히 어렵다.

그래서 비개발자 바이브 코더는 다음을 먼저 익히는 편이 좋다.

요구사항을 글로 또렷하게 쓰는 법
변경 범위를 좁혀서 요청하는 법
테스트 결과와 에러 메시지를 읽는 법
민감 정보와 배포 권한을 함부로 주지 않는 법

멋진 랜딩 페이지보다, 안전하게 운영되는 작은 서비스가 훨씬 오래 간다.

좋은 개발자는 이제 '답변자'보다 '질문 설계자'다

AI 이전 시대에는 아는 것이 경쟁력이었다. 물론 지금도 아는 건 중요하다. 하지만 이제는 질문을 어떻게 설계하느냐가 생산성을 크게 가른다.

좋은 질문은 단순히 예의 바른 질문이 아니다. 문제를 구조화한 질문이다.

예를 들어 "에러 왜 나요?"는 나쁜 질문이다. "Windows PowerShell 환경에서 UTF-8 인코딩 설정 후에도 npm 스크립트에서 한글 로그가 깨진다. 재현 명령은 이것이고, CMD에서는 정상이며, Node 버전은 22, stdout만 깨진다. 원인 후보를 우선순위대로 정리하고 가장 안전한 수정안을 제안해 달라"는 좋은 질문이다.

질문의 수준이 올라가면, AI의 답도 올라간다. 그리고 팀 대화의 수준도 같이 올라간다. 이건 도구 사용법이 아니라 문제 해결 습관의 변화다.