소프트웨어가 세상을 삼켰습니다. 이제 AI가 파일을 하나씩 삼키며 소프트웨어를 먹어 치우고 있습니다. 코드를 작성하며 생계를 이어가는 사람이라면, 아마 키보드 아래의 지면이 흔들리는 것을 느꼈을 것입니다. 한 개발자는 1년 사이에 그 변화를 두 번이나 경험했습니다. 처음에는 기계가 '작성'을 가져갔습니다. 그다음에는 '검토'를 가져갔습니다. 그는 여전히 직업을 유지하고 있지만, 그것은 그가 자신의 역할을 알아볼 수 없을 정도로 바꾸었기 때문입니다.
이것은 종말론적인 예언이 아닙니다. 전환기의 한복판에서 전하는 현장 보고서입니다.
첫 번째 변화: 타이핑에서 교정으로
그의 기술을 설명하기란 간단했던 시절이 있었습니다: 생각하고, 타이핑하고, 테스트하고, 배포하는 것. 그는 모든 함수를 직접 작성했습니다. 변수 이름을 짓고, 루프를 중첩하고, 노력과 시행착오를 통해 예외 상황(edge cases)을 잡아냈습니다. 코드를 읽는 것은 별개의 작업이 아니었습니다. 그것은 속도를 늦추어 검사하며 진행하는 창작 과정이었습니다. 품질 관리와 생산이 하나의 움직임 속에서 이루어졌습니다.
그러다 자동 완성 기능이 더 이상 단순한 편의 기능에 머물지 않게 되었습니다.
AI 코딩 어시스턴트는 단순히 다음 키워드를 제안하는 데 그치지 않았습니다. 클래스 전체, 데이터베이스 마이그레이션, API 래퍼(wrapper)를 통째로 쏟아내기 시작했습니다. 개발자의 손은 방향키에서 리뷰 창으로 옮겨갔습니다. 그는 '작성'이라는 행위를 잃었지만, 스스로 안전하다고 믿었습니다. 여전히 모든 줄을 읽었고, 로직의 형태를 추적했습니다. 그는 편집자이자 문지기이며, 루프 안에 존재하는 인간(human in the loop)이었습니다.
이 변화는 통제할 수 있다는 착각 덕분에 감당할 만하게 느껴집니다. 여전히 코드를 만지고 있고, 오프 바이 원(off-by-one) 오류를 찾아내고 있으니까요. 하지만 당신의 역할은 이미 바뀌었습니다. 당신은 더 이상 저자가 아닙니다. 당신은 기계의 환각(hallucination)에 맞서는 첫 번째 방어선입니다.
두 번째 변화: 읽기에서 신뢰로
두 번째 변화는 더 강력하게 다가왔습니다.
AI 에이전트는 인간의 도움 없이도 몇 시간 동안 작업할 수 있을 만큼 빠르게 성장했습니다. 그가 커피를 마시러 간 사이, 에이전트는 스캐폴딩(scaffolding)을 만들고, 레거시 모듈을 리팩터링하며, 의존성(dependencies)을 패치할 수 있었습니다. 처리량(throughput)은 더 이상 문제가 아니었습니다. 문제는 그의 읽기 속도였습니다.
프로젝트를 계속 진행하기 위해 그는 모든 줄을 읽는 것을 멈춰야만 했습니다. 다른 선택지가 없었습니다. 공장의 생산 속도가 그의 승인 속도보다 빨라졌기 때문입니다. 신뢰는 미덕이 아닌 필수 요건이 되었습니다. 그는 교정자에서 운영 관리자로 변모하여, 예전에는 1년 동안 썼을 양의 코드를 단 한 번의 스프린트 만에 생성해 내는 시스템을 감독하게 되었습니다.
그는 그 기분을 솔직하게 표현했습니다. 그는 더 이상 코더가 아니었습니다. 그는 컨베이어 벨트가 자신의 눈보다 빠르게 움직이는 기계 공장을 관리하는 사람이었습니다.
병목 현상이 상류로 이동하다
놓치기 쉬운 부분이 여기 있습니다. 병목 현상은 사라진 것이 아니라 위치를 옮겼을 뿐입니다.
인간이 코드를 작성할 때, 지연은 뇌와 IDE 사이에서 발생했습니다. 개발자가 가장 느린 부분이었고, 그것은 용인될 수 있는 수준이었습니다. 일단 AI가 작성을 맡게 되자, 병목 지점은 인간의 검토가 되었습니다. 그러다 에이전트가 몇 시간 단위의 루프를 돌 수 있게 되자, 병목 지점은 인간의 의사 결정이 되었습니다. 에이전트가 무엇을 작업해야 하는가? 무엇을 자동화해도 안전한가? 무엇을 다시 확인해야 하는가?
공장은 관리자가 승인할 수 있는 속도보다 빠르게 생산합니다. 문제는 더 이상 기계의 속도가 아닙니다. 정보를 흡수하고, 판단하고, 지시하는 인간의 역량입니다.
만약 당신이 이 병목 현상의 이동을 무시한다면, 당신은 다음 도구가 제거하기 위해 만들어질 장애물이 될 것입니다.
하나의 커리어, 세 번의 재구축
두 번의 파도를 모두 넘어서기 위해서는 자신의 역할을 세 번이나 재구축해야 했습니다.
첫째, 그는 코드를 쓰는 것에서 코드를 읽는 것으로 이동했습니다. 이는 오픈 소스 저장소와 포럼 스레드를 학습한 모델이 생성한 상용구(boilerplate) 코드에서 미묘한 버그를 찾아내며, 회의적인 시각으로 훑어 읽는 법을 배우는 것을 의미했습니다. 제안된 코드가 겉보기에는 맞지만 미묘하게 틀린 경우를 알아채는 '감'을 기르는 것을 의미했습니다. 이는 처음부터 코드를 작성하는 것과는 완전히 다른 기술이었습니다.
다음으로, 그는 코드를 읽는 것에서 워크플로우를 구축하는 것으로 이동했습니다. 이것이 현재 많은 개발자가 도달하고 있는 지점입니다. 당신은 함수를 고치는 것이 아니라, 함수가 고쳐지는 환경을 설계하고 있습니다. 프롬프트를 작성하고, 시스템 지침을 만들고, 가드레일(guardrails)을 설정하며, CI 게이트를 구성합니다. 에이전트를 컴파일러, 린터(linter), 테스트 스위트와 연결하는 배관(plumbing)을 구축합니다. 당신의 결과물은 구문(syntax)보다는 오케스트레이션(orchestration)에 가깝습니다.
마지막으로, 그는 워크플로우를 구축하는 것에서 무엇을 구축할지 결정하는 것으로 이동했습니다. 이것은 정점에 도달했을 때 마주하는 희박한 공기와 같습니다. 당신은 첫 번째 파일이 생성되기 전에 아키텍처를 선택합니다. AI가 채워 넣을 제약 조건, 인터페이스, 비즈니스 로직을 정의합니다. 당신은 시스템의 언어로 말하는 제품 사고가(product thinker)가 된 것입니다.
만약 그가 1단계에 머물러 있었다면, 그는 완전히 교체되었을 것입니다. 그가 여전히 급여를 받고 있는 유일한 이유는 그가 3단계까지 올라갔기 때문입니다.
하지만 그 과정은