AI 개발자 레벨: 자동완성에서 자율 개발까지

AI 도구를 사용하는 모든 개발자는 같은 모호한 약속을 들어봤을 것이다: “AI로 생산성이 높아진다.” 이 발전이 실제로 어떤 모습인지 — 각 단계에서 무엇이 변하는지, 자신이 어느 레벨에 있는지 어떻게 알 수 있는지, 그리고 다음 레벨로 올라가기 위해 구체적으로 무엇을 다르게 해야 하는지 — 를 설명하는 사람은 거의 없다. 그 결과 많은 개발자들이 2년째 “AI를 사용하면서” 더 빠른 자동완성 도구 이상으로 실질적으로 나아가지 못하고 있다.

Dan Shapiro는 “바이브 코딩"이라는 프레임워크를 제시하며 이 발전을 6단계 사다리로 매핑했다 — AI가 더 똑똑한 Tab 키로 기능하는 것부터 AI가 완전히 자율적인 빌드 & 배포 시스템이 되는 것까지. Nate는 StrongDM과 Anthropic의 내부 개발 사례를 더해 이를 확장했다. Big Hat Group에서는 이 프레임워크를 기업 고객에게 적용하여 팀의 실제 레벨을 평가하고 빠진 부분을 채워왔다: 규범적 레이어. “이게 레벨입니다"가 아닌 “다음 레벨로 올라가는 구체적인 방법은 이것입니다"라는 것이다.

프레임워크: 빠른 개요

여섯 레벨은 인간에서 AI로의 위임 스펙트럼을 설명한다. 사다리를 올라갈수록 AI가 더 많은 구현 작업을 담당하고 개발자의 역할은 만드는 것에서 지시하는 것으로, 지시하는 것에서 명세를 작성하는 것으로, 명세를 작성하는 것에서 결과를 평가하는 것으로 이동한다.

이 글을 읽는 대부분의 개발자는 레벨 1과 레벨 3 사이 어딘가에 있다. 자신의 레벨을 파악하는 방법과 다음 단계를 아래에 설명한다.

레벨 0 — 스파이시 자동완성

일상적인 모습: GitHub Copilot, Cursor, 또는 Claude의 인라인 자동완성을 사용하지만 상호작용은 대체로 이렇다: 제안이 나타나면 무시하고 제안에 가까운 것을 수동으로 입력한다. 자동완성의 20~30% 정도만 그대로 받아들여진다. 모든 제안을 신뢰하기 전에 편집이 필요한 초안으로 취급한다.

여기 있다는 징후:

• “거의 맞는” 제안을 수동으로 다시 입력한다
• 읽는 것보다 빨리 자동완성을 닫는다
• “노이즈"처럼 느껴져서 자동완성을 끈 적이 있다
• AI 사용 시간이 시간이 아닌 분 단위로 측정된다

한계: 레벨 0에서 AI는 약 15~20%의 생산성 향상을 가져온다 — 실제이지만 제한적이다. 모델의 품질은 받는 컨텍스트에 제한되며, 이 레벨에서는 현재 파일 외에는 거의 컨텍스트를 제공하지 않는다. 잠재적 가치의 80%를 사용하지 않고 있다.

올라가는 방법:

1. 먼저 받아들이고, 나중에 편집한다. 자동완성을 받아들인 다음 틀린 것을 수정하도록 훈련한다. 목표는 자동완성을 우회해서 쓰는 게 아니라 더 빠르게 평가할 수 있게 되는 것이다.
2. 이름 짓기에서 모델을 신뢰한다. 변수명, 함수 시그니처, 테스트명 — 모델의 제안은 종종 당신의 것만큼 좋다. 과도하게 의심하는 것을 멈춘다.
3. 여러 줄 자동완성을 사용한다. 도구가 지원한다면 (Cursor, Copilot Next Edit Suggestions), 받아들일지 버릴지 결정하기 전에 모델이 전체 함수 본문을 완성하도록 연습한다.

레벨 1 — 코딩 인턴

일상적인 모습: 이산적인 코딩 작업을 위해 채팅 인터페이스나 에이전트 도구(Claude, Codex, Cursor 에이전트 모드)를 사용하기 시작했다. AI에게 단일하고 명확히 스코프된 작업을 준다 — “X를 하는 함수를 써줘"나 “이 파일의 이 특정 버그를 수정해줘” — 그런 다음 받아들이기 전에 모든 줄을 리뷰한다. 수정율이 높다. AI 출력을 아직 신뢰하지 않는 주니어 개발자의 코드처럼 다루고 있다.

여기 있다는 징후:

• AI에게 충분한 컨텍스트를 제공하기 위해 전체 파일 내용을 프롬프트에 붙여넣는다
• AI가 합리적인 선택을 할 것을 신뢰하지 않아 자세한 단계별 지시를 포함한다
• AI 출력 리뷰에 직접 코드를 작성하는 것만큼의 시간이 걸린다
• 단일 파일 스코프는 안전하게 느껴진다; 여러 파일 스코프는 불편하다

한계: 당신이 병목이다. 모든 작업은 코드를 작성하기 전에 당신의 대량 사전 스코프 정의가 필요하다. 각 작업이 독립적으로 취급되기 때문에 AI는 세션 내에서 이전 작업을 기반으로 구축할 수 없다. 실제 가치를 얻고 있지만 프롬프트 작성과 출력 리뷰 속도에 제한된다.

올라가는 방법:

1. 프로젝트용 CLAUDE.md 또는 agents.md를 만든다. 규약, 패턴, 제약을 한 번만 인코딩하는 컨텍스트 문서다 — 모든 프롬프트에서 반복할 필요가 없어진다. 이 컨텍스트로 AI의 당신의 코드베이스에서의 정확도가 크게 향상된다.
2. 작업 분해를 연습한다. 기능을 3~4개의 순차적 작업으로 분해하고, 하나씩 넘기고, 각 중간 단계가 아닌 시작과 끝 상태 사이의 diff를 리뷰한다.
3. 리뷰를 diff로 전환한다. 출력 파일을 처음부터 끝까지 읽는 대신 무엇이 변경됐는지 본다. 이게 더 빠르고 실제로 중요한 것을 잡아낸다.

레벨 2 — 주니어 개발자

일상적인 모습: 여러 파일 변경을 위임하고 있다. 여러 파일에 걸친 기능이나 버그 수정을 AI에게 주고, AI가 PR을 생성한다. 병합 전에 그 PR을 줄별로 리뷰한다. AI 사용량이 임계값을 넘었다 — 직접 쓸 수 있는 것보다 더 많은 코드를 생성하고 있다 — 하지만 리뷰가 새로운 병목이 되고 있다.

여기 있다는 징후:

• AI에게 5~10개 파일에 관련된 작업을 정기적으로 준다
• PR을 받아들이기 전에 여전히 모든 diff를 줄별로 읽는다
• 틀리지 않았지만 자신의 방식과 다른 것을 수정하고 있음을 발견한다
• 처리량이 늘었지만 리뷰 부담도 같이 늘었다

한계: 리뷰 시간이 출력에 비례해서 늘어난다. AI는 당신보다 빠르고, 병목이 쓰기에서 리뷰하기로 이동했다. AI 출력의 줄별 리뷰는 종종 불필요하다 — 모델의 오류는 구조적, 아키텍처적이지 구문적이지 않다. 줄별로 읽는 것은 비용이 높고 잘못된 종류의 오류를 잡으려 하는 것이다.

올라가는 방법:

1. 시맨틱 리뷰로 전환한다. “모든 줄이 정확한가?“가 아닌 “이 PR이 명세서에서 말한 것을 했는가?“를 묻는다. 구조적, 아키텍처적 격차가 중요하다; 모델은 구문을 안정적으로 처리한다.
2. AI 코드 리뷰 단계를 추가한다. Claude의 /code-review 명령이나 PR 리뷰 에이전트를 사용한다. AI가 AI의 출력을 리뷰하게 한다 — 직접 줄별로 읽지 않고 구조적 문제를 잡아낸다.
3. 지금 테스트 커버리지에 투자한다. 레벨 3으로의 전환은 테스트를 주요 안전망으로 신뢰하는 것을 필요로 한다. 커버리지가 회귀를 잡기에 너무 얕다면, 그게 올라가기 전에 수정해야 할 전제 조건이다.

레벨 3 — 매니저로서의 개발자

일상적인 모습: 코드 줄 레벨이 아닌 기능 레벨에서 리뷰한다. AI가 당신의 감독 없이 실행할 수 있을 만큼 명확한 명세서를 작성한다. 당신이 아키텍트; AI가 구현자. 대부분의 시간은 명세서 작성, 아키텍처 결정, 고수준 코드 리뷰에 쓰인다 — 구현이 아니라.

여기 있다는 징후:

• 구현 중 개별 파일 내용을 거의 보지 않는다 — PR 요약을 기다린다
• 프롬프트가 단계가 아닌 결과를 설명한다
• 특정 구현 방식보다 테스트 커버리지를 더 신경 쓰기 시작했다
• 뭔가 잘못됐을 때 본능적으로 코드를 수동으로 수정하는 대신 명세서를 고치려 한다

한계: 품질은 이제 명세서의 품질에 직접 의존한다. 모호하거나 불완전한 명세서는 재작업으로 이어진다. 여전히 주요 리뷰어이며, 이는 스케일에서 처리량을 제한한다. 병목이 다시 이동했다: 코드를 읽는 것이 아닌, 전달된 기능이 의도와 실제로 일치하는지 평가하는 것이다.

올라가는 방법:

1. 명세서 템플릿을 구축한다 — 작업을 넘기기 전에 인수 기준, 엣지 케이스, 테스트 요구사항을 정의하도록 강제한다. 템플릿의 규율이 AI의 출력을 일관성 있게 한다.
2. 자동화된 코드 리뷰 에이전트를 CI에 통합한다. 모든 PR에서 실행되는 두 번째 리뷰어가 당신이 리뷰하기 전에 구조적 문제를 잡아낸다 — 빠르게 움직일 때 놓칠 수 있는 것도 잡는다.
3. 명세서 자체에 테스트 요구사항을 정의한다. “[특정 테스트 시나리오]가 통과하면 이 기능은 완료"라고 하면 품질 게이트가 판단에서 객관적, 감사 가능한 기준으로 이동한다.

레벨 4 — PM으로서의 개발자

일상적인 모습: 코드는 블랙박스다. 명세서와 테스트가 당신의 인터페이스다. 요구사항과 인수 기준을 작성한다; AI가 기능을 만들고 그에 맞게 검증한다. 코드가 올바르게 보이는지가 아닌 테스트가 통과하는지 확인한다. 주요 산출물은 명세서와 테스트 계획이다.

여기 있다는 징후:

• 작업 중 구현 파일을 거의 (또는 전혀) 열지 않는다
• 명세서가 기술 설계보다 제품 요구사항처럼 읽힌다
• “완료"의 정의가 “테스트 통과 및 요구사항 충족"이지, “PR을 리뷰했다"가 아니다
• 코드 품질 지표가 아닌 기능 인수 기준으로 AI 출력을 측정한다

한계: 레벨 4에서는 테스트 커버리지가 전부다. 테스트의 맹점이 출시된 기능의 맹점이 된다. 엣지 케이스, 통합 시나리오, 성능 벤치마크를 포함한 포괄적인 커버리지 없이는 품질이 높은 것이 아니라 측정 불가능한 것이다. 두 번째 위험: 아키텍처 드리프트. AI가 국지적으로 올바른 결정을 내리고, 이것들이 당신이 코드를 읽지 않기 때문에 보지 못하는 체계적인 문제로 누적된다.

올라가는 방법:

1. 포괄적인 자동화 테스트 스위트에 투자한다 — 유닛, 통합, 엔드-투-엔드. 뮤테이션 테스팅이 여기서 가치 있다: 커버리지 양뿐만 아니라 커버리지 품질의 격차를 찾는다.
2. 기능을 위한 결과 지표를 정의한다 — 오류율, 성능 벤치마크, 사용자 대면 성공률. 이것들이 레벨 5의 결과 평가 모델에 대비하게 한다.
3. 아키텍처 리뷰 체크포인트를 추가한다. 레벨 4에서도 드리프트가 누적되기 전에 잡기 위해 시스템의 아키텍처 상태를 정기적으로 리뷰한다.

레벨 5 — 다크 팩토리

일상적인 모습: 명세서를 작성하면 반대편에서 검증된, 배포 가능한 산출물이 나온다. 인간은 정상 운영에서의 구현이나 리뷰 루프에 없다. 시스템은 자동화된 품질 게이트에 따라 빌드, 테스트, 배포한다. 시스템을 조정하고 결과를 평가한다; 빌드 중 개별 기능과 상호작용하지 않는다.

적절한 경우 — 적절하지 않은 경우: 다크 팩토리는 깊은 기존 테스트 커버리지와 명확하고 측정 가능한 결과 지표를 갖춘 좁고 명확히 정의된 도메인에서 작동한다. 인수 기준이 불명확한 새로운 기능, 자동화된 컴플라이언스 검증이 없는 규제 환경, 또는 배포 전에 테스트로 실패를 잡을 수 없는 도메인에는 적합하지 않다. 제대로 설정되지 않은 레벨 5 시스템의 실패 모드는 느린 배포가 아니다 — 잘못된 것의 빠른 배포다.

양보할 수 없는 요구사항:

• 관찰 가능성. 시스템이 무엇을 만들었고 어떻게 동작하는지 볼 수 없다면, 피드백 루프를 완전히 잃은 것이다. 로깅, 트레이싱, 알림은 부가 기능이 아닌 전제 조건이다.
• 자동 롤백. 자동 롤백 없는 자동화 배포는 효율 향상이 아닌 부채다.
• 결과 측정. 레벨 5에서 명세서에서 결과로의 루프가 유일한 품질 신호다. 계측되지 않으면 시스템은 눈 멀고 날고 있는 것이다.

대부분의 기업 팀은 레벨 3~4를 목표로 해야 한다. 레벨 5는 상당한 인프라 요구사항이 있는 도메인 특화 투자다. 전제 조건이 갖춰지기 전에 도달하는 것은 레벨 3에 머무는 것보다 나쁘다.

엔지니어링 리더에게의 의미

팀 구조는 각 레벨마다 변한다. 레벨 0~1에서는 팀 구성 방식이 크게 변하지 않는다 — 개발자가 구현을 담당하고 AI가 지원한다. 레벨 2에서는 테스트 인프라와 리뷰 도구에 투자해야 한다. 레벨 3에서는 역량 조합이 변하기 시작한다: 깔끔한 코드를 쓸 수 있는 개발자뿐만 아니라 명확하고 완전한 명세서를 쓸 수 있는 개발자가 필요하다. 레벨 4에서는 제품 사고 스킬을 채용한다 — 인수 기준 작성, 테스트 아키텍처, 결과 정의. 레벨 5에서는 시스템을 운영하고 있다.

채용에 대한 영향은 실재한다. 팀이 레벨 2에서 레벨 4로 나아갈수록 순수한 구현자는 덜 필요하고 명세와 아키텍처에 강한 개발자가 더 필요하다. AI 네이티브 조직에서는 AI가 완벽하게 실행할 수 있는 명세서를 쓸 수 있는 개발자가 그 명세서를 수동으로 구현할 수 있는 개발자보다 더 가치 있다. 이는 인원 감축에 관한 것이 아니라 — 역량 조합과 채용 프로필에 관한 것이다.

테스트 인프라 없는 레벨 4~5는 효율 향상이 아닌 부채다. 해당하는 테스트 커버리지 투자 없이 인간 워크플로를 레벨 4로 진행하는 팀은 대체 품질 게이트를 추가하지 않고 리뷰어를 루프에서 제거하는 것이다. 결과는 품질이 측정 불가능한 더 빠른 출력이다. 이는 레벨 1보다 나은 게 아니라 나쁜 것이다.

복리로 쌓이는 생산성 격차는 실재한다. 오늘 레벨 1에 있는 조직은 레벨 3 AI 네이티브 팀 대비 복리적인 불이익에 직면한다. 이 격차는 선형적이지 않다 — 높은 레벨의 팀이 더 빠르게 더 큰 작업을 수행하고 더 좋은 인프라에 투자하고 더 나아가기 때문에 복리로 쌓인다. 매 분기마다 격차는 커진다. 지금이 격차를 좁힐 때다.

30일 레벨업 계획

1. 현재 레벨을 솔직하게 평가한다. 자기 보고 추정이 아닌 위의 “여기 있다는 징후” 설명을 사용한다. 징후들은 행동적이고 관찰 가능하다; 그것들을 사용한다.
2. 현재 레벨의 “올라가는 방법” 섹션에서 하나의 습관을 선택해 2주 동안 꾸준히 연습한다. 하나의 습관을 잘 실행하는 것이 세 가지를 반쯤 채택하는 것보다 낫다.
3. 리뷰 프로세스를 계측한다. PR당 소요 시간과 그 중 얼마나 많은 비율이 코드 줄 수준 대 기능 수준 리뷰인지 추적한다. 데이터가 어디에 막혀 있는지 명확히 보여준다.
4. 테스트 커버리지 격차를 파악한다. 이것이 대부분의 팀이 레벨 2에서 레벨 3으로 올라가지 못하게 하는 숨겨진 병목이다. 커버리지가 실제가 되기 전까지는 테스트를 안전망으로 신뢰할 수 없다.
5. 로드맵을 얻는다. Big Hat Group은 기업 엔지니어링 팀이 현재 AI 개발 레벨을 평가하고, 발전을 막는 것을 파악하고, 전환을 지속 가능하게 만드는 도구, 테스트 인프라, 거버넌스 프레임워크를 구축하는 것을 돕는다.

기업 AI 개발 컨설팅 받기

Big Hat Group은 기업 엔지니어링 팀과 협력하여 AI 개발 실무를 발전시킨다 — 팀의 현재 레벨을 평가하는 것부터 발전을 지속 가능하게 만드는 AI 코딩 도구, 명세서 템플릿, 테스트 인프라 구현까지.

문의하기 — AI 개발 평가 시작하기 →

관련 글: Claude Code vs Codex vs Gemini CLI: 기업 가이드 · 기업 AI 코딩을 위한 agents.md 표준