개발자는 코드를 쓰는 사람이 아니다 — AI 시대에 남는 자리는 '책임'에 있다
개발자는 코드를 쓰는 사람이 아니다 — AI 시대에 남는 자리는 '책임'에 있다
AI 때문에 개발자가 없어질 거라는 말, 요즘 진짜 많이 듣는다.
특히 AI를 매일 쓰는 개발자들이 더 불안해하는 것 같다. 매일 AI가 자기 대신 코드를 짜는 걸 보다 보면, 이 일이 얼마나 더 이어질까 싶은 거다. 예전엔 주니어만 대체된다는 이야기였는데, 이제는 시니어까지 같이 묶여서 이야기가 나온다.
얼마 전엔 지인 한 명이 커리어를 바꿀까 고민 중이라고 했다. 30년 넘게 코딩했는데, 요즘 자기가 일주일 걸릴 작업을 AI가 몇 시간 만에 해치우는 걸 보면서 "내가 지금 쌓고 있는 스킬이 3년 뒤에도 의미가 있을까"라는 생각이 든다고 했다. 다른 한 명은 반대로, AI를 거의 안 쓰는 동료들을 보면서 "저 사람들 지금 뭐하고 있는 건가" 싶다고 했다. 같은 시기에 완전히 다른 종류의 불안을 겪고 있는 거다.
둘 다 이해는 간다. 근데 이 불안의 전제 자체가 틀렸다고 본다.
정확히는 반은 맞고 반은 틀렸다. 개발자가 없어지는 게 아니라, "개발자"라는 단어가 가리키는 대상이 바뀌고 있을 뿐이다. 근데 그 변화가 혼란스러워 보이니까 "개발자가 사라진다"는 쉬운 말로 퍼지는 것 같다.
작년에 사내에서 한 발표를 준비하면서 이 주제를 나름대로 정리해본 적이 있다. 주제는 복잡한 크로스플랫폼 데스크톱 앱을 리팩토링하면서 겪은 경험이었는데, 진짜 하고 싶었던 이야기는 프로젝트 경험담이 아니라 한 발짝 더 떨어진 곳에 있었다.
"AI를 잘 쓰는 법"이 아니라, AI를 쓰다 보니 내가 하는 일의 무게중심이 어디로 옮겨가고 있는가. 그 이야기를 하고 싶었다.
그리고 1년이 지난 지금, 그때 적었던 결론은 오히려 더 또렷해졌다.
구현자에서 "다시 설계자로"
발표에서 썼던 문장 하나가 지금 다시 봐도 정확한 것 같다.
개발자가 사라지는 흐름이라기보다는, 개발자의 무게중심이 구현자에서 설계자로 다시 이동하는 과정에 가깝다.
"다시"라는 단어가 핵심이다.
원래 개발자는 요구사항 분석, 설계, 구현, 테스트 전체를 책임지는 사람이었다. 90년대, 2000년대 초반까지만 해도 "개발자"라는 말에는 설계가 당연히 포함돼 있었다. 근데 언제부터인가 "개발자 = 코드 치는 사람"으로 역할이 축소됐다. 프레임워크가 풍부해지고 오픈소스가 흔해지면서, 구현만 빠르게 할 수 있는 사람이 개발자라는 이름을 차지하게 된 거다. 설계는 어느 순간 별도의 타이틀(아키텍트, 테크 리드 등)로 분리됐다.
AI는 이 축소된 정의를 깨고 있다.
구현이라는 가장 눈에 띄는 부분을 AI가 가져가면서, "개발자"라는 직군의 원형이 역설적으로 다시 드러난다. 구현만 하는 사람은 대체되고, 원래 개발자라는 이름이 가리키던 전 영역 — 요구사항부터 설계, 판단, 책임까지 — 을 다루는 사람이 다시 중심이 된다.
그러니까 "개발자가 없어진다"는 말은 이렇게 읽어야 맞다. 구현만 하던 개발자가 없어지고 있다. 그리고 설계, 판단, 책임을 지는 개발자의 자리는 오히려 커지고 있다.
바이브 코딩이 80%에서 무너지는 이유
내 경험으로 이야기해보면, 바이브 코딩은 처음 80%까지는 진짜 잘 된다.
요구사항을 몇 줄 던지면 그럴듯한 코드가 나온다. 컴파일도 되고 화면도 뜨고 기본 동작도 맞다. 초기 개발 속도가 폭발적이다. 이 구간에서는 "AI 덕분에 개발이 얼마나 쉬워졌는지"를 체감하게 된다. 나도 처음엔 "이제 작은 프로젝트는 며칠이면 끝나겠구나" 싶었다.
문제는 남은 20%다.
이슈 하나가 터지고, 프롬프트를 바꿔도 해결이 안 되는 순간이 온다. 더 황당한 건 AI가 강한 확신을 가지고 잘못된 원인을 지목한다는 거다. 그 원인대로 고치면 다른 곳이 깨진다. 또 고치면 또 다른 곳이 깨진다. 비슷한 코드가 쌓인다. 한참을 헤매다 보면 처음에 뭘 고치려 했는지 기억이 흐려질 정도가 된다.
어느 날은 간단한 UI 버그 하나를 세 시간째 붙잡고 있는 나를 발견했다. AI가 제안한 수정안을 적용하니 다른 렌더링 로직이 깨졌고, 그걸 고치니 상태 관리가 엉켰고, 상태 관리를 고치니 처음 고치려던 UI가 다시 이상해졌다. 이 루프가 얼마나 오래 돌았는지 기억도 안 난다. 그냥 처음부터 내가 직접 디버깅했으면 30분이면 끝났을 버그였다.
이 경험에서 배운 건 단순하다. AI는 지금 눈앞에 있는 코드 조각은 꽤 정확히 분석한다. 근데 그 조각이 속한 시스템의 숨은 전제 — 이 상태값은 언제 초기화되나, 이 이벤트는 어느 타이밍에 발생하나, 이 렌더링은 어느 사이클에서 트리거되나 — 에는 쉽게 눈이 먼다. 그래서 한 곳을 고치면 그 전제를 모르고 건드린 다른 곳이 조용히 깨진다. 프롬프트를 바꾸는 걸로는 이 한계를 넘을 수 없다. 전제를 문서로 밖에 꺼내놓지 않는 이상, AI는 계속 같은 함정에 빠진다.
이 단계에서 대부분은 "프롬프트를 더 잘 써야 한다"는 결론으로 간다. 나도 한동안 그랬다. 근데 프롬프트를 아무리 공들여 써도 같은 문제가 반복됐다.
어느 시점에 깨달았다. AI는 단기 맥락에는 강하다. 대신 장기 구조, 일관성, 책임 경계 같은 것에는 약하다.
그러니까 질문을 바꿔야 했다. "AI한테서 원하는 답을 어떻게 끌어낼까"가 아니라, "AI가 사람의 표현에 휘둘리지 않고 미리 정의된 기준을 유지하게 하려면 뭐가 필요한가"로.
세 번의 실험, 그리고 한 번의 실패
LMS 리팩토링 작업을 AI로 해본 적이 있다.
"코드 재설계 해줘"로 시작했다. 처음엔 그럴듯하게 진행되다가 중반 이후 속도가 급격히 느려졌다. 문제는 AI가 아니었다. 설계 기준점이 없었다는 게 문제였다. AI는 매번 그럴듯한 답을 내는데, 그 답들이 서로 일관되지 않았다. 기준이 없으니 일관성을 맞출 근거가 없었다.
두 번째 시도에서는 docs를 먼저 만들고 시작했다. 이번에는 문서가 있으니 괜찮을 줄 알았다. 근데 버그가 날 때마다 AI가 매번 큰 구조 변경을 제안했다. 같은 유틸을 두 번, 세 번 중복으로 만들기도 했다. 문서는 있는데, 그걸 일관된 기준으로 쓰고 있지 않았다.
여기서 알게 됐다. "문서를 만들었다"와 "설계했다"는 다르다. 문서는 산출물이고, 설계는 그 산출물이 흔들리지 않게 계속 검증하고 보정하는 과정이다.
세 번째 시도에서 여러 AI를 동시에 참조시키면서 교차 검증하는 방식으로 갔다. 이때 실제 기능이 완성됐다. 결제까지 포함해서. 성공이었다. 근데 한계도 같이 보였다. 병목이 AI가 아니라 내 설계의 깊이였다.
그 다음 단계에서 앞선 프로젝트보다 훨씬 복잡한 시스템에 같은 방법을 적용하려 했다. Rust + C++ + Electron + React + Node.js가 얽힌 크로스플랫폼 데스크톱 앱. 중간에 멈췄다. 그냥 멈춘 게 아니라 실패에 가까운 중단이었다.
정확히는 이런 풍경이었다. 핵심 상태값 하나를 바꾸는데, React의 상태와 Electron 메인 프로세스의 캐시, Rust 코어가 들고 있는 인스턴스 — 이 세 곳의 값이 서로 엇갈린 상태로 쌓여갔다. 어디가 원본이고 어디가 복제본인지 구분이 안 되는 순간이 왔다. AI에게 "상태 관리를 정리해달라"고 요청할수록 오히려 더 복잡해졌다. 각 레이어에서 AI는 나름 그럴듯한 개선안을 냈는데, 그 개선안들이 서로를 무효화했다. 나는 이 구조를 머릿속에서 한 장의 그림으로 그릴 수 없었고, 그릴 수 없으니 AI에게 줄 기준도 만들 수 없었다. 거기서 멈추는 게 진행을 강행하는 것보다 나았다.
처음엔 AI의 한계라고 생각했다. 시간을 두고 다시 보니 그게 아니었다. 내가 인지한 설계 깊이가 부족했던 거다. 다중 언어, 시스템 레벨에서는 AI가 겉보기 일관성만 맞춰준다. 실제 동작과 설계 문서가 충돌하는 지점이 쌓이고, 얕은 설계에서는 구현이 진행될수록 모순이 폭발한다.
React에서 증상이 보이는데 원인은 IPC 메시지 변형에 있고, 그 뒤에 FFI 경계에서 전제가 고정되어 있고, 더 내려가면 Rust 코어의 판단이 있다. 각 레이어에서 AI는 자기 나름 타당한 판단을 제시한다. 근데 전체 흐름의 정합성은 문서 없이 검증할 길이 없다.
문제는 React, Renderer, IPC, FFI, Core 중 어느 하나의 오류가 아니라, 각 레이어의 판단을 하나로 묶는 설계가 없었다는 점이다.
이 실패에서 한 가지 귀한 걸 얻었다. 설계의 깊이가 부족하다는 걸 AI는 알려주지 않는다. AI는 매 레이어에서 나름 그럴듯한 답을 낸다. 그 답들이 서로 모순된다는 건 전체 흐름을 붙잡고 있는 사람만 느낀다. 그 사람이 없으면 모순은 코드에 조용히 쌓이다가 어느 날 운영 중에 폭발한다.
실패 뒤에 남은 건 문서가 아니라 '운영 도구'였다
그 데스크톱 앱에서 중단된 시도를 돌아보면서, 앞서 두 번째 시도에서 내가 놓친 게 뭔지 다시 정리했다.
문서를 만들었는데 왜 안 됐을까. 문서는 있었지만 그걸 기준으로 AI가 움직이지 않았기 때문이다. AI는 대화가 새로 시작될 때마다 문서를 참조하는 것 같지만, 실제로는 표면만 훑고 자기가 생성하기 편한 방향으로 코드를 만들어간다. 문서가 있다는 사실만으로는 기준이 운영되지 않았다.
그래서 이후에 시도한 건 "문서를 기준선으로 운영하는 체계"였다. 최소 구성은 이렇다.
- docs/ — 판단과 맥락을 고정하는 설계 기준
- ENGINEERING HANDBOOK — 팀 또는 AI 에이전트들의 공통 판단 출발점
- DESIGN / CODE / IPC-EVENT GUIDE — 설계, 구현, 경계 일관성을 연결하는 문서
- DEBUGGING RUNBOOK — 운영 단계에서 설계를 되돌아보는 장치
이 구성의 핵심은 문서가 "산출물"이 아니라는 점이다. 문서는 판단 기준을 운영하는 도구다. 여러 AI가 교차 검증하려면 단 하나의 기준 문서 — SSOT(Single Source of Truth) — 를 참조해야 하고, 그 기준이 흩어지면 검증 자체가 불가능해진다.
복수의 AI를 돌려보면서 알게 된 건, AI끼리 의견이 충돌하는 지점은 대부분 AI의 오류가 아니라 내 설계의 빈틈이라는 거다. AI가 엇갈리는 지점을 찾아 그 틈을 문서에 반영하고, 다시 AI를 돌리고, 또 엇갈리는 지점을 찾는다. 이 사이클을 반복하면 설계의 모호함이 점점 제거된다.
설계 문서는 한 번 쓰고 끝나는 결과물이 아니다. AI와 대화하면서 계속 검증하고 보정하는 과정의 운영 도구다. 이 감각을 얻고 나서야 두 번째 시도에서 뭐가 부족했는지 진짜로 이해할 수 있었다.
그리고 이 체계를 한번 갖추고 나니, 설계를 고정했을 때 가장 먼저 나타난 변화는 의외로 단순했다. 일관성이었다. 변수 이름, 채널 이름, 도메인 규칙이 문서 기준으로 자연스럽게 수렴했다. 중복 유틸과 유사 코드가 눈에 띄게 줄었다. 그리고 가장 인상적이었던 건, 실패의 신호가 코드보다 문서에서 먼저 드러나기 시작했다는 거였다. 문서 단계에서 모순을 발견할 수 있으면, 구현 단계에서의 사후 대응 루프가 사라진다.
'감독관'이라는 프레임이 틀린 이유
여기까지 경험하고 나서 나도 처음엔 이렇게 생각했다.
"앞으로 개발자는 AI를 감독하는 사람이 되겠구나."
이 표현에는 함정이 있다. 감독관은 감독만 하면 된다. 결과를 보고 통과 또는 반려만 하면 끝이다. 근데 실제로 필요한 건 그게 아니다. AI가 만든 결과가 왜 맞고 왜 틀린지 설명할 수 있어야 한다. 반례를 들어서 검증할 수 있어야 한다. 그 시스템의 암묵적 규칙을 기억하고 있어야 한다.
감독만 하는 사람은 겉보기 일관성에 속는다.
AI가 만든 결과는 보통 "말은 되는" 상태로 나온다. 변수 이름이 적절하고, 함수가 분리돼 있고, 에러 처리도 어느 정도 들어가 있다. 깊이를 모르면 그냥 통과시킨다. 그러다 임계점을 넘으면 모순이 터진다. 그 시점에서 "누가 이걸 통과시켰냐"고 물어도 책임질 사람이 없다. 각자 "내 담당 영역은 괜찮았다"고 말할 뿐이다.
그래서 "감독관"보다 더 정확한 표현은 "무엇이 정답인지 정의하고, 그 결과에 책임지는 사람"이다. 이게 발표에서 제일 말하고 싶었던 한 줄이었다.
AI는 구현과 검증을 확장할 수 있지만, 책임의 주체가 될 수는 없다.
이 문장은 말장난이 아니다.
책임은 법적 선언이 아니라, 판단할 수 있는 능력에서만 성립한다. 판단할 수 없는 사람은 책임자가 아니다. 그냥 도장 찍는 사람이다. 그래서 "AI가 만든 걸 승인하는 사람" 같은 역할은 당장은 그럴듯해 보여도, 실제로는 자리가 오래 유지되지 않는다.
구체적으로 어떻게 사라지느냐면, 이런 흐름이다. 처음에는 "AI 결과 검토자"라는 타이틀이 생긴다. 검토자는 AI가 낸 코드를 읽고 OK/NG를 판정한다. 시간이 지나면 AI의 품질이 올라가고 NG가 점점 드물어진다. 그러면 조직은 자연스럽게 이 타이틀의 존재 이유를 묻기 시작한다. 검토자가 기술적 근거로 "왜 NG인지"를 설명하지 못하면, 그 역할은 곧 "자동 통과 + 이슈 생기면 상위 보고"로 단순화된다. 결국 중간 관리 계층 하나가 사라지고, 검토자는 실무도 설계도 하지 않는 애매한 사람이 된다. 이게 AI 시대에 가장 먼저 구조조정 대상이 되는 자리다.
책임지려면 최소한 이런 게 필요하다.
- 도메인 모델을 이해하고 있어야 한다
- 시스템의 경계와 불변식을 설명할 수 있어야 한다
- AI가 낸 결과가 왜 맞고 왜 틀린지 반례를 들어 검증할 수 있어야 한다
이게 없으면 "책임자"라는 직함은 결재권자에 불과하다.
정답을 정의하는 사람, 그리고 제약을 관리하는 사람
한 발 더 들어가보면, 개발자의 역할은 "정답을 정의하는 사람"만으로도 부족하다.
실제 현장에서는 정답이 하나인 경우가 거의 없다. 대부분은 불완전한 선택지 여러 개 중에서 제약을 덜 깨는 쪽을 고르는 일이다. 이 판단을 할 때 동시에 봐야 하는 것들이 있다.
- 비즈니스 정합성
- 기술 부채
- 보안과 법무 리스크
- 운영 가능성
- 조직이 지금 감당할 수 있는 복잡도
AI는 후보안을 아주 잘 만든다. 근데 그 후보들 중에 "우리한테 맞는 정답"이 뭔지는 조직의 기억과 책임 구조 안에서만 결정된다. AI가 모르는 건 "이 팀은 지금 이 정도 복잡도를 감당할 수 없다" 같은 현실 감각이다.
예를 들어 이런 상황이 자주 있다. AI가 "이 코드는 이렇게 리팩토링하는 게 깔끔합니다"라고 제안한다. 기술적으로 맞는 말이다. 근데 나는 알고 있다. 이 모듈을 유지하는 팀은 지금 다른 마일스톤에 쫓기고 있다. 이번에 구조를 크게 바꾸면 다음 달 배포에서 다른 팀과 충돌이 생긴다. 그리고 이 코드는 내년 초에 다른 방향으로 다시 바뀔 예정이라 지금 리팩토링한 결과가 몇 달 뒤 통째로 폐기될 가능성이 크다.
그러니까 "기술적으로 맞는 답"과 "지금 우리한테 맞는 답"은 다르다. AI는 앞은 잘 본다. 뒤는 못 본다. 뒤는 조직의 현재 상태, 다른 팀의 사정, 로드맵 같은 게 얽힌 문제라서다.
비슷한 상황은 정말 흔하다. 예를 들어 AI가 "이 API 응답 구조를 개선해서 필드 이름을 snake_case에서 camelCase로 바꾸면 프론트엔드 코드가 훨씬 깔끔해집니다"라고 제안했다고 치자. 맞는 말이다. 근데 이 API를 쓰는 외부 파트너가 세 곳 있고, 그중 한 곳은 응답 파서를 3년째 손대지 않는 상태다. 필드 이름을 바꾸면 그쪽이 가장 먼저 터진다. AI는 이 파트너가 있다는 걸 모른다. 코드에도 없고 문서에도 없다. 이건 조직에서 몇 년 일한 사람의 머릿속에만 있는 정보다. 그리고 이 정보를 가진 사람이 "안 됩니다"라고 말할 수 있어야 시스템이 지켜진다. 이 한마디를 할 수 있는 사람이 있는지 없는지가, 이 팀에 AI가 들어왔을 때 오히려 더 선명하게 드러난다.
그래서 앞으로 개발자는 생성자라기보다 선별자, 판단자, 제약 관리자에 가까워진다. 조금 다르게 말하면, "AI가 만들어낸 여러 정답 후보 중에서 우리한테 맞는 걸 고를 줄 아는 사람"이 점점 귀해진다는 뜻이다.
하나 더. 모든 시스템에는 문서화되지 않은 암묵적 규칙들이 있다. "이 데이터는 이런 경로로만 이동해야 한다." "이 흐름은 깨면 안 된다." "이 기능은 빠르게 만드는 것보다 설명 가능성이 더 중요하다." "이 사용자 경험은 절대 건드리지 마라." 이런 규칙들은 보통 문서에 없다. 사람의 머릿속에만 있다.
그리고 바로 이 지점에서 AI가 자주 그럴듯하게 틀린다.
그래서 개발자는 앞으로 "윤리 감독관" 같은 이미지보다는, 시스템의 암묵적 규칙을 기억하고 지키는 사람에 가까워진다. 윤리는 그 일부일 뿐이다. 보안, 운영 안정성, 사용자 신뢰, 조직의 암묵적 계약 — 이런 것들이 모두 같은 범주에 들어간다.
그래서 요즘은 이렇게 일한다
이런 경험들을 거치면서, 지난 반년 동안은 완전히 다른 방식으로 일하고 있다.
2025년 11월부터 지금(2026년 4월)까지, 거의 모든 개발 작업을 바이브 코딩으로 돌렸다. 내가 에디터에서 직접 코드를 친 시간은 극소수다. Claude Code와 Codex가 주요 실무자고, 나는 그들이 맥락을 정확히 이해하고 코드를 제대로 수정할 수 있도록 환경을 설계하는 쪽에 붙어 있다.
실제로 내가 하는 일을 풀어보면 이런 것들이다.
먼저 ADR(Architecture Decision Records) 작성. 왜 이 구조를 선택했고 왜 다른 안을 배제했는지를 기록으로 남긴다. ADR이 없으면 AI는 매번 새로운 "최적해"를 찾으려 하고, 기존 결정을 의도 없이 뒤엎는다. ADR이 있으면 반년 뒤에 새 에이전트 세션이 열려도 같은 판단을 유지한다. AI 시대에 ADR은 '아키텍트의 취향 기록'이 아니라 '에이전트의 기억 장치'에 가깝다.
docs 수정도 상시 작업이다. AI가 코드를 읽다가 맥락이 모호해지는 지점이 보이면, 그 부분을 설계 문서 쪽으로 끌어올려 명시화한다. 코드 주석으로 해결하려 하지 않는다. 주석은 AI가 가끔 무시하고, 설계 문서는 AI가 더 신뢰하기 때문이다.
스킬 정의 수정. AI가 반복적으로 같은 실수를 하면, 프롬프트를 일회성으로 고치는 게 아니라 스킬 정의 자체를 다듬는다. 한번 다듬으면 그 스킬을 호출하는 모든 에이전트가 동일한 개선을 적용받는다. 한 번의 교정이 수백 번의 실행에 반영된다.
에이전트 팀 구성. 한 에이전트가 모든 걸 하는 게 아니라, 역할별로 분리해서 각자 자기 도메인 안에서만 판단하게 만든다. 전략, 실행, 품질 검수, 발행 — 이렇게 나누면 한 에이전트가 과도한 맥락을 붙잡다가 판단이 흐려지는 일이 줄어든다. 사람 팀에서 책임 분리가 중요한 이유와 똑같다.
마지막으로 훅(hook)과 MCP 구축. AI가 실수할 가능성이 높은 지점에 자동화된 가드레일을 심는다. 커밋 전에 특정 규칙을 검증하거나, 특정 파일을 수정할 때 필요한 컨텍스트를 자동으로 주입하는 식이다. 이건 "AI에게 지시하는 것"과 완전히 다른 접근이다. 지시는 AI가 무시할 수 있지만, 훅은 무시할 수 없다. 실수를 줄이려면 지시를 늘리지 말고 구조를 심어야 한다.
그러면서 계속 신경 쓰는 건 토큰 낭비다. 어떤 컨텍스트를 언제 주입할지, 어떤 작업을 어떤 에이전트에게 맡길지 — 이 결정들이 결과 품질을 정하고 동시에 비용을 정한다. 5천 토큰으로 끝낼 일을 5만 토큰으로 돌리면 결과가 더 좋아지지도 않으면서 청구액만 불어난다. 그래서 설계자는 AI의 작업 결과만 보는 게 아니라, 그 결과가 얼마의 비용으로 나왔는지도 같이 본다. 이게 예전에 없던 새로운 감각이다.
이 반년 동안 거의 완벽하게 돌아가는 앱 하나가 그렇게 만들어졌다. 내가 친 코드는 얼마 안 된다. 근데 이 앱이 지금처럼 동작하는 이유는, 그 뒤에 ADR 수십 개, 스킬 조정 수백 번, 훅과 MCP 구성, 에이전트 팀 설계가 차곡차곡 쌓여 있기 때문이다.
예전이라면 "이 기능 만들어"라는 업무가 들어왔을 때 에디터부터 열었을 거다. 지금은 먼저 질문이 바뀐다. 어느 에이전트에게 맡길까. 이 에이전트가 맥락을 이해하려면 어떤 문서가 더 필요한가. 기존 스킬로 충분한가, 아니면 이 작업 전용 스킬을 하나 만들어야 하나. 실수 가능성이 높은 지점이 있다면 훅으로 막을 수 있나. 이 판단을 먼저 하고, 그 다음에 에이전트를 돌린다. 실제 코드는 에이전트가 쓴다. 내 일은 그 에이전트가 틀리지 않게 환경을 깔아주는 것이다.
작년 발표에서 말했던 "구현자에서 설계자로"가 추상적 선언이 아니라, 실제로 내가 매일 하는 일의 모양이 됐다. 코드를 치지 않는다고 해서 일이 줄어든 것도 아니다. 무게중심이 완전히 다른 쪽으로 옮겨갔을 뿐이다.
아직 답이 없는 질문 — 그 사람은 어떻게 길러지는가
여기서 솔직한 이야기를 하나 해야 한다.
"설계자 / 책임자 / 판단자"가 앞으로 남는 자리라는 건 알겠다. 근데 그런 사람은 어떻게 길러지는가? 나도 아직 답을 못 찾았다.
과거 시니어 개발자의 판단력은 대부분 구현 고통에서 왔다. 실패한 구현, 운영 사고, 새벽의 데이터 정합성 붕괴, 성능 병목, 팀 커뮤니케이션 실패, 배포 롤백. 이런 실제 손실이 누적되면서 "이 결정은 이래서 위험하다"는 감각이 생겼다.
AI가 이 구현 고통을 너무 많이 흡수하면 어떻게 될까.
차세대는 겉으로는 빨리 만들지만, 판단 깊이는 얕은 설계자가 될 수도 있다. 이건 실제로 일어날 수 있는 위험이다. 아니, 이미 조금씩 일어나고 있는 것 같다. AI가 써준 코드를 이해하지 못한 채 PR을 올리는 주니어, AI가 리팩토링한 결과를 읽지 않고 머지하는 팀 — 이런 풍경이 어색하지 않은 시대가 됐다.
문제는 그 결과가 당장은 별로 티가 안 난다는 거다. 코드가 돌아가고 테스트가 통과하니까 PR은 통과된다. 진짜 문제는 6개월 뒤다. 그 코드를 처음 짠 AI도, 머지한 사람도 이제 맥락을 기억하지 못한다. 버그가 터지면 아무도 그 구조를 해석할 수 없고, 해석 못 하니까 고치지 못한다. 결국 "이 모듈은 너무 복잡하니까 다시 짜자"라는 이름으로 같은 루프가 반복된다. 판단 근육 없이 빠르게 쌓인 코드는, 결국 판단 근육 없는 팀을 계속 요구한다.
그래서 개발자의 성장 경로가 이렇게 바뀔 것 같다.
- 예전: 많이 구현해본 사람이 깊어졌다
- 앞으로: 많이 판단해보고, 많이 검증 실패를 겪어본 사람이 깊어진다
앞으로 개발자에게 가장 귀한 학습 자산은 코드 자체가 아니다. 실패 로그, 의사결정 기록, 반례 모음이 될 거다. "왜 이 설계가 틀렸는지"에 대한 구체적 사례가 쌓인 사람이 가장 강한 판단자가 된다.
구체적으로 무엇을 기록으로 남겨야 할까. 내가 요즘 의식적으로 쌓고 있는 건 세 가지다.
AI가 틀렸던 순간의 로그. AI가 그럴듯하게 틀린 순간을 그냥 넘기지 않고, "왜 틀렸는지 / 어디를 못 봤는지 / 다음에 비슷한 패턴을 어떻게 알아볼지"를 짧게라도 적어둔다. 이게 쌓이면 판단 감각이 선명해진다. AI의 실수 패턴은 의외로 반복되기 때문이다. 한번 속은 패턴에 두 번째는 덜 속게 된다.
의사결정의 "왜". 설계 문서에 결론만 적으면 나중에 그 결론이 왜 내려졌는지 본인도 까먹는다. "이 구조를 선택한 이유는 A, B, C 때문이고, D안을 택하지 않은 이유는 E 때문이다" — 이런 메모가 훗날 가장 귀한 자산이 된다. 실제 메모는 이런 식으로 쓴다. "결제 흐름을 이벤트 기반 대신 동기 호출로 유지하기로 결정. 이유 1: 현재 백엔드 팀 3명이 비동기 디버깅 경험이 부족함. 이유 2: 결제 실패 시 사용자에게 즉시 피드백이 필요한데, 이벤트 큐의 지연은 UX를 해침. 이유 3: 트래픽이 아직 초당 수십 건 수준이라 동기 처리로 충분. 6개월 뒤 팀 규모와 트래픽을 재점검 후 비동기 전환 여부를 다시 논의. 기각된 메시지 큐 안은 이 세 가지 조건이 해소되면 재고려 가능." 이 정도 메모가 쌓이면, 반년 뒤 내가 까먹은 사이에 팀의 AI 에이전트들이 "깔끔하게 이벤트 기반으로 리팩토링하자"고 제안해도 바로 막을 수 있다.
반례 모음. "이 규칙이 깨지면 어떤 일이 벌어지는가"를 구체적 케이스로 쌓아둔다. AI는 규칙을 외우는 건 잘하지만, 규칙이 언제 왜 위험한지는 잘 모른다. 반례 모음은 그래서 판단자에게만 있는 자산이다. 예를 들어 "사용자 식별자를 로그에 평문으로 남기지 마라"라는 규칙이 있다고 치자. AI에게 이 규칙만 주면 그 순간은 지키는데, 며칠 뒤 새로 만드는 디버깅 코드에서 슬쩍 어긴다. 근데 반례를 함께 줘보면 얘기가 달라진다. "작년 하반기, 지원팀이 사용자 문의를 해결하려고 임시로 로그 뷰어에 접근했다가 로그 파일에 평문으로 남은 이메일 주소를 본 사건이 있었고, 이후 컴플라이언스 감사에서 5건의 이슈가 제기됐다." 이 한 단락이 규칙 옆에 붙어 있으면 AI는 규칙을 깨려 할 때마다 멈칫한다. 규칙을 왜 지켜야 하는지가 눈에 보이기 때문이다.
그러니까 지금 AI를 쓰면서 겪는 실패들을 그냥 지우지 말았으면 한다. AI가 그럴듯하게 틀린 순간, 내가 그 위에서 한 번 더 틀린 순간, 설계 없이 시작해서 중간에 포기한 순간. 이게 다 자산이다. 위에서 이야기한 세 번의 시도와 중단된 데스크톱 앱 리팩토링 같은 기록들 말이다.
남는 자리는 오히려 넓어지고 있다
AI가 코드를 더 잘 짤수록 사라지는 건 "구현만 하던 개발자"다.
그 자리에서 오히려 더 희소해지는 건 "무엇이 정답인지 정의하고, 제약을 관리하고, 책임질 수 있는 개발자"다. 그런데 이 두 번째 개발자는 감독관이 아니다. 결과에 도장 찍는 사람이 아니라, 결과를 설명할 수 있고 반례로 검증할 수 있는 사람이다.
책임은 직함이 아니라 해석 능력이다.
해석 능력이 뭐냐 하면, 이런 거다. AI가 "이 함수는 성능 최적화를 위해 캐시를 추가했습니다"라고 결과를 내놓았다고 치자. 해석 능력이 있는 사람은 이렇게 묻는다. 이 캐시의 만료 조건은 뭐지. 동시성 상황에서 값이 꼬이면 어떻게 되지. 이 함수는 세션 경계를 넘나드는데, 세션이 끝난 뒤에도 캐시가 살아 있으면 이전 사용자의 데이터가 다음 사용자에게 노출되는 거 아닌가. 이런 질문을 할 수 있는 사람이 책임자다. "음, 깔끔해 보이네, 머지"라고 하는 사람은 승인자일 뿐이다.
이게 가능하려면 도메인을 이해하고 있어야 하고, 시스템의 불변식을 설명할 수 있어야 하고, AI가 낸 결과의 위험 지점을 먼저 감지할 수 있어야 한다. 이걸 못하는 사람은 그냥 AI 결과를 통과시키는 중간 관리자가 된다. 그리고 중간 관리자는 AI가 더 성숙해질수록 가장 먼저 사라지는 자리다.
AI가 개발자를 없앤다는 말이 진짜로 의미하는 건 이거다. AI의 결과에 책임질 수 없는 사람은 자리가 없어진다. 반대로 책임질 수 있는 사람의 자리는 오히려 넓어진다. 한 사람의 판단자가 여러 개의 AI를 동시에 돌릴 수 있는 시대니까, 판단 능력 하나에 걸리는 레버리지 자체가 커졌다.
구체적으로 이런 그림이다. 예전에 개발자 10명이 달라붙어야 했던 프로젝트를, 이제는 설계 감각이 있는 개발자 두세 명과 에이전트 팀이 돌릴 수 있다. 이 구조에서 가장 몸값이 높아지는 건 "두세 명" 안에 들어갈 수 있는 사람이다. 그리고 그 자리에 들어가는 조건은 "코드를 얼마나 빨리 치느냐"가 아니라 "우리 시스템의 무엇이 지켜져야 하는지를 얼마나 정확히 알고 있느냐"다. 예전에는 숙련된 구현자가 레버리지를 만들었다면, 앞으로는 숙련된 판단자가 레버리지를 만든다.
그러니까 지금 필요한 건 불안이 아니라, 판단 근육을 어디서 기를지에 대한 계획이다.
AI가 구현을 가져갈수록 더 많이 하게 되는 건 판단이니까.
댓글
댓글 쓰기