AI 시대 개발자의 역할

코딩 노동력이 병목이던 산업

IT는 첨단 산업이면서 동시에 노동집약 산업이었다. 문제의 난이도와 상관없이 논리를 빈틈없이 코드로 옮기는 데 시간이 들었고, 야근과 크런치가 일상이 된 이유도 여기 있다. 그래서 개발자는 늘 생산성 도구를 가장 먼저 받아들였다. 생성형 AI도 마찬가지다. 자동완성 → Copilot(문맥 기반 코드 예측) → ChatGPT(대답까지 자동완성) → AI IDE → Claude Code 같은 에이전트 CLI로 이어지며, 이제 사람이 코드를 한 줄도 직접 치지 않고 실무 수준의 개발을 하는 것이 가능해졌다. 실제 GitHub 이슈를 푸는 벤치마크(SWE-bench)에서도 상위 모델은 대부분의 문제를 푼다.

그래도 남는 구조적 한계

LLM은 기존 개발 도구와 두 가지가 다르다. 인간의 언어로 지시받고, 비결정적으로 결과를 낸다. 같은 입력에도 결과가 달라진다. 여기서 사람이 맡아야 할 몫이 생긴다.

한계	내용	사람에게 남는 일
언어의 모호성	"요즘 스타일 버튼", "자연스럽게" 같은 말은 실행 가능한 명령이 아니다. 사람은 대충 추상화해 말하도록 진화했다	모호한 요구를 명확한 문제와 명세로 바꾸기
마지막 1마일	누군가는 결국 컴퓨터가 실행할 만큼 명확하게 마무리해야 한다	최종 결과를 확정하기
판단과 책임	AI는 사회적으로 결정에 책임질 수 없다	결정권자 역할
평균 회귀	지도학습으로 기존 코드의 통계 패턴을 따르므로 익숙한 해법과 대중적 기술로 돌아간다. 바둑처럼 닫힌 시스템과 달리 코드는 정답이 없는 열린 시스템이라 스스로 "더 나은 코드"를 평가하기 어렵다	맥락에 맞는 최선과 새 기술 도입을 고르기
환각	99% 정확해도 100번에 한 번은 틀린다. 사람의 실수와 달리 "운영 DB를 초기화하겠다"처럼 상식 밖의 실수를 한다	검증과 안전장치

그래서 개발자의 핵심 역할은 이렇게 정의된다. 사람의 모호한 요구를 컴퓨터가 풀 수 있는 문제로 재정의하고, (AI를 통해) 컴퓨터 언어로 구현하고, 그 결과가 올바른지 판단하며 책임진다.

시장에 생긴 변화

채용 문턱이 높아졌다. 코로나 시기에 늘어난 개발자 공급과 IT 성장 둔화가 겹쳤고, AI는 채용 동결의 명분이 됐다. AI가 평균 수준의 코드를 쓰니 신입에게는 "적어도 AI보다는 잘해야" 한다는 기준이 생겼다. 기업이 원하는 사람은 예전과 같다. 개발 잘하고, 일 잘하고, 소통 잘하는 사람이다.
본질이 퇴화한다. 뇌는 쓰지 않는 능력을 버린다. 고민이 길어지는 것을 견디지 못하고 바로 AI에 답을 묻는 습관은 문제 해결 능력을 깎는다.
기술이 평균으로 수렴한다. AI는 학습 데이터가 많은 기술일수록 잘 다룬다. "그거 AI가 잘 짜 줘?"가 기술 선택 기준이 되면서 새 기술의 도입 동기가 약해지고, 코드도 AI가 이해하기 쉬운 평균 패턴으로 끌려간다.
진입 장벽은 낮아졌다. 막연한 아이디어만 있어도 동작하는 결과를 만들어 볼 수 있다. AI가 만든 코드를 복사만 하면 낭비지만, 왜 그렇게 짰는지 분석하면 좋은 학습 도구가 된다.

자동화가 산업을 줄일지 키울지는 시장이 닫혀 있느냐 열려 있느냐에 달렸다. 농업은 땅과 식량 수요가 한정된 닫힌 시장이라 자동화로 종사자가 줄었다. 자동차는 값이 내려가며 시장이 커진 열린 시장이라 오히려 늘었다. 소프트웨어가 어느 쪽인지는 아직 정해지지 않았다.

지시에서 위임으로

AI에게 일을 시키는 방식도 바뀌었다.

단계	방식	깨달음
세세한 지시	"포커스가 사라지면 이벤트를 잡아서 다음 항목에 둬"	내가 던진 방법이 잘못된 앵커가 되면 AI는 그 틀 안에서 땜질만 한다
위임	필요한 것과 이유(Why), 목표(What)만 주고 방법은 맡긴다	일 잘하는 사람에게 일을 맡기는 법과 같다
의도 정렬	"바로 코딩하지 말고 내 의도를 맞혀 봐. 모르면 질문만 해"	LLM은 "문제 해결 = 코드 출력"에 고착(goal fixation)돼 있어, 질문만 해도 코드를 고치려 든다. 산출물을 '질문'으로 정하면 멈춘다
산출물 분리	TDD를 `/red`(실패하는 테스트만) → `/green`(통과하는 구현만) → `/refactor`로 나눈다	한 턴에 출력할 수 있는 양은 한정돼 있다. 두 일을 한 턴에 시키면 목표(코드)에 밀려 중간 산출물(테스트)이 부실해진다
파이프라인	`/spec → /red → /green → /refactor → /verify → /commit`	스킬은 입력·출력·제약이 있는 함수다. 단일 책임·개방-폐쇄 같은 클린 코드 원칙이 `.md` 파일에도 그대로 통한다

결국 프롬프트를 쓰는 것이 아니라 스킬과 에이전트라는 함수를 코딩하는 것이다. 플랫폼이 IDE에서 마크다운 편집기로, 실행 주체가 결정적 컴퓨터에서 비결정적 에이전트로 바뀌었을 뿐이다. 이 작업은 자기 자신을 텍스트로 추상화하는 일, 곧 암묵지의 명세화이기도 하다. 무의식적으로 하던 판단("이 에러면 이 파일부터 본다")을 꺼내 적어야 한다. 반복해서 쓰는 좋은 패턴은 금세 Skills·hooks·memory·loop 같은 도구 기능이 되므로, 방법론 자체보다 방법론을 실제 문제에 굴려 본 경험이 차별점이 된다. 스킬 작성법은 Claude 스킬 만들기 가이드, 자동 주행 설계는 루프 엔지니어링에 있다.

하네스와 오라클

"AI가 짠 코드를 다른 AI에게 검증시키면 된다"는 생각은 오라클 문제(Oracle Problem), 즉 무엇이 올바른지 판단할 기준을 어떻게 세우느냐에 막힌다. LLM에게 자기 코드를 비판시키면 맞는 답까지 틀렸다며 고쳐 정확도가 떨어지기도 한다. 비결정적 함수를 통제하려면 기준만큼은 결정적이어야 한다. 컴파일러(tsc), 테스트 러너, 린터, 브라우저 자동화(Playwright) 같은 결정적 게이트를 파이프라인 곳곳에 덧대는 것을 하네스(harness) 라고 한다.

예전: 결정적인 코드로 비결정적인 세상(사용자 입력, 네트워크)을 방어한다
지금: 비결정적인 함수(AI)로 결정적인 결과(제품)를 만들고,
      결정적인 함수(하네스·오라클)로 그 비결정성을 묶는다

AI가 쉽게 푸는 것은 이미 추상화가 끝난 잘 정의된 문제다. 생성 비용은 싸졌지만 조립·관리·검증 비용은 그대로다. 개발자의 일은 예전에는 가끔 만나던 고난도 영역, 곧 비결정적인 엣지 케이스 통제로 채워진다. 실무 규칙은 AI 코딩 실무 가드레일에 있다.

코딩 밖의 개발이 드러난다

AI와 큰 문제를 굴리면 새로 보이는 것들이 있다.

시켜 보지 않은 것이 한계다. "브라우저를 직접 열어 확인하고 고쳐"라고 시키면 된다. AI의 한계라고 여긴 것 중 상당수는 상상력의 한계다. 질문은 "내가 할 수 있을까"에서 "어떻게 얘가 하게 만들까"로 바뀐다.
맥락이 저절로 쌓이지 않는다. 직접 코딩할 때는 왜 이 파일을 고쳤는지, 어디가 위험한지가 몸에 남았다. AI가 코드를 쓰면 이 축적이 멈춘다. 그래서 요구사항 문서, 의사결정 기록, 작업 보고, 테스트가 전보다 더 필요하다. 맥락과 판단을 보존하는 기술이 코딩 능력만큼 중요해졌다.
커밋이 쌓인다고 제품이 커지지 않는다. 코드가 늘어나는 것과 제품이 나아지는 것은 다르다. 상태가 흩어지고 책임이 흐린 코드는 AI도 사람도 길을 잃게 한다.
필요한 도구는 만들면 된다. 문서가 넘치면 문서 뷰어를, 구조가 안 보이면 코드 분석 도구를 만든다. 예전에는 ROI가 맞지 않던 중간 도구가 현실적인 선택지가 됐다.

프론트엔드가 특히 흔들리는 이유

처음 화면은 빨리 나오지만, 디자인 시스템·비활성 상태·키보드 조작·빈 데이터 화면 같은 기준이 붙으면 흔들린다. 프론트엔드의 판단은 "덜 튀게", "선택된 느낌" 같은 모호한 말 위에서 움직이고, 실패 신호도 흐리다. 빌드와 테스트는 통과하는데 써 보면 이상하다. 사람끼리는 같은 화면을 보며 의미를 좁혀 가지만, AI에게는 매번 모호한 말을 코드로 바꾸게 하니 결과가 흩어진다.

LLM과의 작업은 여러 주사위를 던지고 원하는 눈은 고정한 채 나머지만 다시 던지는 게임과 같다. AI는 어느 주사위가 6이고 어느 것이 1인지 알려 주지 않는다. 잘하는 사람은 무엇이 이미 맞았는지 알아보고, 빗나간 것만 다시 던지고, 될 때까지 한다. 같은 도구를 써도 결과가 평준화되지 않는 이유는 이 눈과 집요함의 차이다.

역할은 갈라진다

영상 제작의 허들이 낮아져도 영상 전문가가 사라지지 않고 역할이 다양해졌듯, 개발도 그렇다. 기획자·디자이너·PM이 AI로 동작하는 프로토타입을 만들어 오고, 개발자는 그것을 다음 단계로 넘어갈 수 있게 닦는 역할을 맡기도 한다. 상태를 나누고, 책임을 정리하고, 테스트할 지점을 만들고, 맥락을 남겨 AI와 사람이 이어서 작업할 수 있게 한다. 문제를 가장 잘 아는 사람, 결과를 끝까지 밀어붙이는 사람, 구조를 닦는 사람, AI가 쓰기 좋은 레이어와 도구를 만드는 사람으로 개발자의 길은 여러 갈래가 된다.

길러야 할 역량

역량	예
추상적 요구를 구체적 명세로	"로그인 만들어 줘"가 아니라 프레임워크·암호화 방식·응답 코드까지 말한다. 전공 지식이 있어야 가능하다
맥락과 의도를 전하는 소통	"리뷰해 줘"가 아니라 "동시 결제 중복 처리 때문에 트랜잭션을 넣었으니 race condition을 봐 줘"
서비스 한 바퀴를 끝까지	인증·배포·로그·DB까지 전체 흐름을 한 번은 겪어야 무엇을 맡기고 무엇을 직접 볼지 판단한다
작은 CTO처럼 결정하기	혼자 일해도 스택·아키텍처를 정하고, 기술 부채를 관리하고, 일을 나눠 AI에 맡길 입력과 받을 출력을 정한다. 문제 크기에 비해 과하지 않은 기술을 고르는 것까지가 결정이다
결과의 가치를 설명하기	만든 것이 사업에서 어떤 가치를 내는지 스스로 평가하고 말할 수 있어야 결과에 책임질 수 있다. 결과물을 먼저 만들고 그 과정에서 코드를 배우는 순서가 가능해진 만큼 이 판단의 비중이 커졌다
목적이 먼저인 사고	"AI로 뭘 해 볼까"가 아니라 "이 번거로운 배포 과정을 어떻게 없앨까"
큰 문제와 내 스킬 하나	작은 문제에서는 요구사항·문서·검수 기준의 필요가 드러나지 않는다. 반복하는 일 하나를 골라 스킬로 만들고, 전후 차이를 체감한다
코드 밖으로 시야 넓히기	GitHub 이슈·PR·위키, 문서·캘린더·메신저까지 AI가 다룰 수 있는 범위로 본다

이 중 AI가 대신할 수 없는 것이 기술적 근거 위에서 자기 맥락을 구조적으로 말하는 능력이다. 회고로 기른다. 먼저 사실을 구체적으로 늘어놓고("sticky가 특정 브라우저에서만 안 됐다", "상위 요소의 transform과 충돌했다"), 각 사실에 범주 이름(문제 정의, 기술적 원인, 제약 조건, 트레이드오프, 해결책)을 붙인 뒤, 인과 순서로 배치한다. 소프트웨어 설계처럼 이름을 붙이고 제자리에 두는 일이다. 글로 정리한 것을 말로 설명해 보면 막히는 지점이 아직 이해하지 못한 곳이다.

주니어는 어떻게 시니어가 되나

AI 코딩 도구를 「주니어 개발자」에 비유하는 순간 질문이 생긴다. AI가 주니어의 일을 하면 주니어는? Stanford 디지털 경제 연구소에 따르면 AI 노출이 큰 직업에서 22~25세 고용은 덜 노출된 직업의 추세보다 19% 낮고, 주로 젊은 층을 덜 뽑은 결과다. 하지만 시니어는 어느 날 완성된 채로 나타나지 않는다. 법률(패러리걸 → 변호사)과 건축(손 제도 → CAD → 3D 모델링)도 같은 문제를 먼저 겪었다. 손으로 도면을 그리던 세대는 실수 하나에 몇 시간이 날아가니 무엇이 되고 안 되는지 몸으로 익혔지만, 3D 모델링 세대는 한 번 바꾸면 끝이라 그 경험이 줄었다.

원래 주니어의 일은 우연히 좋은 연습이었다

잘 정의된 작은 작업의 반복, 페어링, 테스트와 PR 리뷰라는 빠른 피드백, 검색 결과에서 믿을 것 고르기, 혼자 얼마나 버티고 언제 도움을 청할지 익히기. 이 구조는 의도적 연습(deliberate practice)의 조건과 맞아떨어졌다.

의도적 연습의 조건	주니어의 일
하고 싶게 만든다	실제 제품에 기여한다
이미 아는 것에서 출발한다	범위가 좁고 맥락이 주어진다
즉각적이고 유익한 피드백	테스트, 리뷰, 페어
같거나 비슷한 과제를 반복	비슷한 작업이 계속 온다

연습에는 세 모델이 있다. 실전과 다른 운동으로 근육을 키우는 스포츠형, 고수의 수를 보고 따라 하는 체스형, 부분을 따로 연습해 합치는 음악형. 주니어 업무가 AI로 넘어가면 이 연습을 일부러 설계해야 한다.

그래도 배워야 할 것과 새로 배울 것

여전히 필요한 것	새로 필요한 것
기초(데이터베이스, 클라우드, 구성 요소가 맞물리는 방식)	비판적 사고: 왜 되는지, 왜 깨졌는지, 정보가 어디서 왔는지 끝까지 묻는다
냄새: 운영에서 문제가 될 징후	AI를 잘 쓰는 법: 일을 명확하게 지시하는 능력
디버깅, 리팩터링	코드 리뷰를 훨씬 일찍: AI가 쓴 코드를 신입 때부터 리뷰한다
배우는 법과 계속 따라가는 법	시스템 사고를 일찍: 하위 작업이 아니라 스토리 단위를 맡으니 전체가 어떻게 맞물리는지 알아야 한다

이제 기초는 저절로 쌓이지 않으니 적극적으로 가르쳐야 한다. 신입은 AI에게 일을 맡기며 이전보다 큰 작업을 혼자 해내고, 일찍부터 테크 리드처럼 일하게 된다. 신입들은 AI를 코드 생성만이 아니라 문제를 함께 생각하고 코드를 이해하는 데 쓴다. 같은 질문을 반복해도 화내지 않는 끝없이 참을성 있는 멘토다. 위험도 있다. 사람의 지혜가 빠진 조언을 받고, 선배의 코칭이 줄어들 수 있다.

시니어가 할 일

가르치는 법을 배운다. 사람은 무의식적 무능 → 의식적 무능 → 의식적 유능 → 무의식적 유능으로 기술을 익힌다. 운전처럼 생각하지 않고 해내는 단계의 고수는 왜 그렇게 했는지 설명하지 못해, 물으면 선의로 그럴듯한 이유를 지어낸다. 의식적 유능 단계의 중간 경력자가 주니어를 더 잘 가르치는 이유다. 고수는 가르치기를 의식적으로 배워야 한다.
일을 연습이 되게 설계한다. 위의 연습 모델로 과제를 쪼갠다.
늘 이유를 설명한다. 「모범 사례라서」 뒤에 숨지 않는다. 이유를 모르면 찾아본다.
AI를 직접 잘 쓴다. 팀원은 이미 쓰고 있다.
건강한 의심을 가르친다. LLM은 본질적으로 정교한 자동 완성이라 새로운 문제에서는 자주 틀린다. 출처와 문서를 확인하게 한다. 그래프가 괜찮다고, 권위자가 말했다고 믿지 않는 태도는 원래 엔지니어에게 좋은 습관이다.

파도를 막을 수는 없지만 서핑은 배울 수 있다. 해변에서 파도가 지나가길 기다리는 것도, 물속에 들어가 사는 것도 답이 아니다.

정리

주니어 업무가 AI로 넘어가면 그 업무가 주던 의도적 연습을 일부러 설계하고, 기초·코드 리뷰·시스템 사고를 일찍 가르친다. 시니어는 가르치는 법과 건강한 의심을 가르친다.
AI는 코드 작성의 병목을 풀었지만, 모호함을 명확하게, 비결정을 결정적으로, 결과를 책임 있게 바꾸는 일은 개발자에게 남는다.
지시보다 위임, 프롬프트보다 산출물이 분리된 스킬 파이프라인, 그리고 결정적 하네스가 AI를 다루는 기본기다.
코딩이 사라진 자리에서 문서·테스트·의사결정 기록으로 맥락을 보존하는 일이 커졌다.
AI가 내 대신 생각하게 두면 스스로 대체된다. AI를 잘 쓰려면 역설적으로 AI가 아닌 것(원리, 원본 문서, 동료, 언어 능력)을 더 잘해야 한다.

버그 제보