개발자는 코드를 쓰는 사람이 아니다 — AI 시대에 끝까지 남는 자리는 ‘책임’에 있다

AI 때문에 개발자가 사라질 거라는 말을 요즘 정말 자주 듣는다.

 

재미있는 건 이 말을 개발을 잘 모르는 사람이 아니라, 오히려 AI를 매일 쓰는 개발자들이 더 많이 한다는 점이다. 매일 눈앞에서 AI가 자기 대신 코드를 뽑아내는 걸 보고 있으면 흔들릴 수밖에 없다. 예전에는 “주니어 업무부터 줄어들겠지” 정도였는데, 이제는 시니어도 안전하지 않다는 식으로 얘기가 확장됐다.

 

얼마 전 지인 한 명이 진지하게 커리어 전환을 고민한다고 했다. 30년 넘게 코딩한 사람인데, 요즘은 자기가 일주일 붙들 일도 AI가 몇 시간 안에 대충 형태를 만들어내는 걸 보면서 묻더라. “내가 지금 쌓고 있는 숙련이 3년 뒤에도 값이 있을까?” 반대로 다른 한 명은 AI를 거의 안 쓰는 팀원들을 보면서 완전히 다른 불안을 말한다. “저 사람들은 지금 뭘 준비하고 있는 거지?”
같은 시기에 완전히 다른 종류의 공포가 동시에 생기고 있는 셈이다.

 

둘 다 이해는 간다.

 

근데 나는 이 불안의 출발점 자체가 조금 틀렸다고 본다.
개발자가 없어지는 게 아니다.
“개발자”라는 말이 가리키는 대상이 바뀌는 중이다.

 

그리고 이 변화가 너무 빠르고 거칠게 오니까, 사람들이 제일 쉬운 문장으로 번역해버린다.

 

“개발자 없어지는 거 아냐?”

 

실제로는 조금 다르다.
구현만 하던 개발자의 자리가 줄어드는 거고,
무엇을 만들어야 하는지 정의하고, 무엇을 버려야 하는지 판단하고, 결과에 책임지는 개발자의 자리가 다시 커지고 있다.

 

나는 이걸 “개발자가 구현자에서 설계자로 이동한다”는 말보다 조금 더 날카롭게 표현하고 싶다.

 

개발자는 다시 “책임자”가 되고 있다.

 

구현자에서 설계자로 이동한다는 말로는 조금 부족하다

 

작년에 사내 발표를 준비하면서 이 주제를 한 번 정리한 적이 있다. 겉으로는 복잡한 크로스플랫폼 데스크톱 앱을 리팩토링하면서 겪은 경험담이었는데, 사실 진짜 하고 싶었던 얘기는 그게 아니었다.

 

“AI를 잘 쓰는 팁”이 아니라
AI를 쓰다 보니 내가 하는 일의 무게중심이 어디로 옮겨가고 있는지.

 

그게 더 중요했다.

 

그때 적어둔 문장 하나를 지금 다시 봐도 여전히 정확하다.

 

개발자의 무게중심이 구현자에서 설계자로 다시 이동하고 있다.

 

여기서 중요한 단어는 “다시”다.

 

원래 개발자는 요구사항을 이해하고, 구조를 정하고, 구현하고, 테스트하고, 운영까지 책임지는 사람이었다. 90년대나 2000년대 초반만 해도 “개발자” 안에는 설계가 당연히 들어 있었다. 그런데 어느 순간부터 역할이 쪼개졌다. 프레임워크는 풍부해지고, 오픈소스는 넘쳐나고, 구현 속도는 경쟁력이 됐다. 그 과정에서 개발자는 점점 “코드를 빨리 치는 사람”으로 축소됐다. 설계는 아키텍트나 테크 리드 같은 별도 역할로 밀려났다.

 

AI는 바로 이 축소된 정의를 깨고 있다.

 

구현이라는 가장 눈에 띄는 일을 AI가 가져가니까, 역설적으로 개발자라는 직군의 원형이 다시 드러난다. 요구사항을 해석하고, 경계를 정의하고, 판단을 내리고, 결과에 책임지는 사람. 그게 원래 개발자였는데, 한동안 우리는 구현자만 개발자라고 불러왔던 셈이다.

 

그래서 “개발자가 사라진다”는 말을 그대로 받아들이면 곤란하다.
정확히 말하면, 구현만 하던 개발자의 자리가 빠르게 줄고 있다.
반대로 설계와 판단과 책임을 지는 개발자의 자리는 오히려 더 비싸지고 있다.

 

바이브 코딩은 왜 늘 80%에서 갑자기 무너질까

 

이 얘기를 너무 추상적으로 하고 싶진 않다.
내 경험으로 말하면, 바이브 코딩은 처음 80%까지는 정말 잘 된다.

 

요구사항 몇 줄 던지면 그럴듯한 코드가 나온다. 화면도 뜨고, 기본 동작도 맞고, 컴파일도 된다. 이 구간에서는 진짜 황당할 정도로 빠르다. “이제 작은 프로젝트는 정말 며칠이면 끝나겠는데?”라는 착각이 들 정도다. 나도 그랬다.

 

근데 남은 20%에서 분위기가 완전히 바뀐다.

 

버그 하나가 터진다.
프롬프트를 조금 바꿔본다.
AI가 강한 확신으로 원인을 지목한다.
그대로 고친다.
다른 곳이 깨진다.
그걸 고친다.
처음 문제랑 연결된 구조가 또 어긋난다.
비슷한 코드가 하나 더 생긴다.
한 시간쯤 지나면 처음 뭘 고치려 했는지 감각이 흐려진다.

 

이게 정말 자주 생긴다.

 

어느 날은 단순한 UI 버그 하나를 세 시간 넘게 붙들고 있었다. AI가 제안한 수정안을 넣으니 다른 렌더링 로직이 무너졌고, 그걸 고치니 상태 관리가 엉켰고, 상태를 다시 맞추니 처음 문제였던 UI가 또 이상해졌다. 그때 좀 웃겼다. 그냥 처음부터 내가 직접 디버깅했으면 30분이면 끝났을 버그였으니까.

 

이런 순간이 몇 번 쌓이고 나서야 하나가 보이기 시작했다.

 

AI는 지금 눈앞의 코드 조각은 꽤 잘 본다.
근데 그 조각이 속한 시스템의 숨은 전제에는 쉽게 눈이 멀어진다.

 

이 상태값은 언제 초기화되는지,
이 이벤트는 어느 타이밍에 발생하는지,
이 렌더링은 어떤 사이클에서 트리거되는지,
이 캐시가 언제 폐기되어야 하는지.

 

이런 전제는 코드 몇 줄 안에 안 담겨 있다.
시스템 전체에 퍼져 있고, 가끔은 사람 머릿속에만 있다.

 

그래서 AI는 한 곳을 고칠 때, 그 전제를 암묵적으로 들고 있던 다른 곳을 조용히 망가뜨린다. 프롬프트를 더 정교하게 써도 여기서 벗어나기 어렵다. 전제를 구조로 밖에 꺼내놓지 않으면, AI는 계속 같은 함정에 빠진다.

 

이 단계에서 사람들은 보통 “프롬프트를 더 잘 써야 하나 보다”라고 생각한다. 나도 한동안 그랬다. 근데 오래 안 갔다. 프롬프트를 아무리 공들여도, 장기 구조와 일관성과 책임 경계 문제는 계속 반복됐다.

 

질문 자체를 바꿔야 했다.

 

“AI한테서 원하는 답을 어떻게 끌어낼까?”가 아니라,
“AI가 사람의 말투에 흔들리지 않고 미리 정의된 기준을 계속 따르게 하려면 무엇이 필요한가?”

 

거기서부터 얘기가 달라졌다.

 

세 번의 실험, 그리고 한 번의 꽤 비싼 실패

 

이걸 좀 더 선명하게 만든 건 리팩토링 작업 몇 번이었다.

 

처음에는 정말 단순하게 시작했다.
“코드 재설계 해줘.”

 

처음엔 그럴듯하게 갔다. 구조도 깔끔해 보이고, 설명도 번듯했다. 근데 중반쯤부터 속도가 갑자기 꺾였다. 그때는 AI 한계라고 생각했다. 지금 돌이켜보면 더 정확한 원인은 설계 기준점이 없었다는 거다. AI는 매번 그럴듯한 답을 냈지만, 그 답들끼리 일관성이 없었다. 일관성을 맞출 기준이 없으니, 매번 “이번 턴의 최적해”만 내놓았던 셈이다.

 

두 번째 시도에서는 docs를 먼저 만들고 들어갔다. 이번엔 괜찮을 줄 알았다. 문서가 있으니까. 근데 또 틀렸다. 버그가 날 때마다 AI는 자꾸 큰 구조 변경을 제안했고, 비슷한 유틸을 두 번, 세 번씩 새로 만들었다. 그때 알았다. 문서를 만들었다는 것과 설계를 했다는 것은 다르다. 문서는 산출물일 수 있지만, 설계는 그 산출물이 흔들리지 않게 계속 검증하고 보정하는 과정이다.

 

세 번째 시도에서는 여러 AI를 동시에 참조시키고 교차 검증하는 방식으로 갔다. 그제야 실제 기능이 끝까지 붙었다. 결제까지 들어간 앱이 나왔다. 성공이었다. 근데 여기서도 한계는 분명했다. 병목은 모델이 아니라 내 설계의 깊이였다.

 

그다음 단계에서 더 복잡한 시스템에 같은 방식을 적용하려다가 크게 멈췄다.
Rust, C++, Electron, React, Node.js가 서로 얽힌 데스크톱 앱이었다.
중단이라고 표현했지만, 솔직히 말하면 실패에 더 가까웠다.

 

풍경은 이랬다.

 

핵심 상태값 하나를 바꾸는데 React 상태와 Electron 메인 프로세스 캐시와 Rust 코어가 들고 있는 인스턴스 값이 서로 조금씩 다른 방향으로 어긋나기 시작했다. 어디가 원본이고 어디가 복제본인지 감각이 사라지는 순간이 왔다. AI에게 상태 관리를 정리해달라고 할수록 구조는 더 복잡해졌다. 각 레이어에서 AI는 다 그럴듯한 개선안을 냈다. 문제는 그 개선안들이 서로를 무효화했다는 점이다.

 

그때 깨달은 건 꽤 아팠다.

 

나는 이 구조를 머릿속에서 한 장의 그림으로 그릴 수 없었다.
그리고 그릴 수 없으니 AI에게 줄 기준도 만들 수 없었다.

 

React에서 증상이 보이는데 원인은 IPC 메시지 변형에 있고, 그 아래에는 FFI 경계의 전제가 숨어 있고, 더 밑에는 Rust 코어의 판단이 있었다. 각 레이어별로 보면 AI는 거의 항상 “말이 되는” 답을 냈다. 근데 전체 흐름의 정합성은 아무도 붙잡지 못했다. 설계가 없었던 게 아니다. 설계의 깊이가 모자랐다.

 

이 실패가 남긴 가장 비싼 교훈은 이거였다.

 

AI는 설계가 얕다는 사실을 알려주지 않는다.
매 레이어에서 그럴듯한 답을 낸다.
그 답들이 서로 충돌한다는 건 전체를 붙잡고 있는 사람만 느낀다.

 

그 사람이 없으면 모순은 조용히 코드에 쌓인다.
그리고 어느 날 운영에서 터진다.

 

문서가 부족한 게 아니라, 문서를 운영하지 못한 게 문제였다

 

이 실패 뒤에 남은 건 “문서를 더 써야겠다” 같은 결론이 아니었다.
오히려 그 반대에 가까웠다.

 

문서는 이미 있었다.
문제는 그 문서가 기준으로 운영되지 않았다는 점이었다.

 

AI는 대화가 새로 시작될 때마다 문서를 읽는 것처럼 보인다. 근데 실제로는 표면만 훑고, 자기가 지금 생성하기 편한 쪽으로 흘러가는 경우가 많다. 문서가 있다는 사실만으로는 기준이 고정되지 않는다.

 

그래서 그 뒤에 바뀐 건 문서 자체보다 문서를 운영하는 방식이었다.

 

docs는 판단과 맥락을 고정하는 기준선이 되고,
ENGINEERING HANDBOOK은 공통 판단의 출발점이 되고,
설계 문서와 구현 가이드와 경계 문서는 서로를 연결하고,
DEBUGGING RUNBOOK은 운영 단계에서 다시 설계를 되짚는 장치가 됐다.

 

이 구성의 핵심은 문서가 산출물이 아니라는 데 있다.
문서는 판단 기준을 운영하는 도구다.

 

여러 AI를 교차 검증하려면, 결국 모두가 한 기준선을 참조해야 한다. SSOT가 흐려지면 검증은 불가능해진다. 복수의 AI를 돌려보면서 가장 자주 본 장면도 그거였다. AI끼리 의견이 엇갈리는 지점은 대체로 AI의 오류라기보다 내 설계의 빈틈이었다. 그 충돌 지점을 다시 문서에 반영하고, 다시 돌리고, 또 충돌나는 부분을 수정하는 식으로 가야 했다.

 

이 사이클을 몇 번 돌리고 나서야 체감한 변화가 있다.

 

일관성이 생겼다.

 

변수 이름이 수렴하고,
채널 이름이 정리되고,
도메인 규칙이 흔들리지 않고,
중복 유틸과 유사 코드가 눈에 띄게 줄었다.

 

그리고 제일 인상적이었던 건,
실패 신호가 코드보다 문서에서 먼저 보이기 시작했다는 점이다.

 

문서 단계에서 모순을 잡아내면 구현 단계에서의 삽질 루프가 줄어든다.
이건 생산성 문제가 아니라 책임 구조 문제에 더 가깝다.

 

“감독관”이라는 말이 자꾸 어긋나는 이유

 

이쯤 되면 누구나 이렇게 말하고 싶어진다.

 

앞으로 개발자는 AI를 감독하는 사람이 되겠네.

 

근데 나는 이 표현이 좀 위험하다고 본다.

 

감독관은 감독만 하면 된다.
결과물을 보고 통과인지 반려인지 정하면 끝이다.

 

실제로 필요한 사람은 그게 아니다.

 

AI가 만든 결과가 왜 맞고 왜 틀린지 설명할 수 있어야 하고, 반례를 들어 검증할 수 있어야 하고, 시스템의 암묵적 규칙을 기억하고 있어야 한다. 감독만 하는 사람은 겉보기 일관성에 속는다. AI 결과물은 대부분 “말은 되는” 상태로 나온다. 변수 이름도 괜찮고, 함수 분리도 멀쩡하고, 에러 처리도 대충 있다. 깊이를 모르면 그냥 통과시킨다. 그러다 임계점을 넘는 순간 모순이 터진다.

 

그 시점이 되면 누가 책임지나.

 

각자는 자기 영역은 멀쩡했다고 말한다.
검토자는 통과만 눌렀다고 말한다.
AI는 원래 책임 주체가 아니다.

 

결국 빈칸만 남는다.

 

그래서 “감독관”보다 더 정확한 표현은 따로 있다.

 

무엇이 정답인지 정의하고, 그 결과에 책임지는 사람.

 

그게 앞으로 남는 개발자에 더 가깝다.

 

AI는 구현과 검증을 확장할 수 있다.
근데 책임의 주체가 되지는 못한다.

 

이건 말장난이 아니다.
책임은 법적 선언이 아니라 해석 능력에서 나온다.

 

해석할 수 없는 사람은 책임자가 아니다.
그냥 도장 찍는 사람이다.

 

이 차이가 왜 중요한지는 금방 드러난다. 처음에는 “AI 결과 검토자” 같은 역할이 생길 수 있다. 코드를 읽고 OK/NG를 판정하는 사람. 근데 시간이 지나면 AI 품질이 올라가고 NG가 줄어든다. 그때 조직은 묻기 시작한다. “이 역할은 왜 있지?” 검토자가 기술적 근거로 왜 NG인지 설명하지 못하면, 그 자리는 곧 자동 통과 플로우로 흡수된다. 실무도 설계도 하지 않는 애매한 중간 계층이 된다. 이건 AI 시대에 제일 먼저 압박받는 자리다.

 

책임은 결과를 승인하는 권한이 아니라,
왜 이 결과가 맞는지 틀린지 설명할 수 있는 능력에서 나온다.

 

정답을 정의하는 사람보다, 제약을 관리하는 사람이 더 귀해진다

 

한 발 더 들어가면, “정답을 정의하는 사람”이라는 표현도 조금 모자란다.

 

현실에서는 정답이 하나인 경우가 거의 없다.
대부분은 여러 개의 덜 나쁜 선택지 중에서,
어떤 제약을 덜 깨는 쪽을 고르는 일에 가깝다.

 

여기서 동시에 봐야 하는 것들이 있다.

 

비즈니스 정합성,
기술 부채,
보안과 법무 리스크,
운영 가능성,
조직이 지금 감당할 수 있는 복잡도.

 

AI는 후보안을 정말 잘 만든다.
근데 그 후보들 중에서 “우리에게 맞는 답”이 뭔지는 조직의 기억 안에서만 결정된다.

 

예를 하나 들어보자.
AI가 어떤 모듈을 더 깔끔하게 리팩토링할 수 있다고 제안한다. 기술적으로는 맞는 말이다. 구조는 좋아지고, 코드도 예뻐진다. 근데 나는 안다. 이 모듈을 유지하는 팀은 지금 다른 마일스톤에 묶여 있고, 이번 분기에 구조를 크게 바꾸면 다음 달 배포에서 다른 팀과 충돌이 생긴다. 게다가 이 영역은 내년 초에 통째로 다시 바뀔 가능성이 높다. 그러면 지금 리팩토링은 기술적으로는 맞아도 조직적으로는 틀린 답이다.

 

비슷한 상황은 훨씬 더 자주 있다.
AI가 API 응답 구조를 더 깔끔하게 정리하자고 한다. 예쁘다. 맞는 말이다. 근데 이 API를 쓰는 외부 파트너 세 곳 중 한 곳은 파서를 3년째 안 건드리고 있다. 필드 이름 하나 바꾸면 거기가 먼저 터진다. 이 정보는 코드에도 없고 문서에도 없다. 조직 안에서 오래 일한 사람이 머릿속에만 들고 있는 정보다.

 

그리고 바로 그 사람이 “안 됩니다”라고 말할 수 있어야 시스템이 지켜진다.

 

이건 진짜 중요하다.

 

AI는 기술적으로 맞는 답을 제안할 수 있다.
근데 지금 우리에게 맞는 답을 고르는 건 다른 문제다.

 

그래서 앞으로 개발자는 생성자라기보다 선별자, 판단자, 제약 관리자에 가까워진다.
조금 더 노골적으로 말하면, AI가 만들어낸 여러 정답 후보 중에서 우리 조직이 감당할 수 있는 답을 고를 줄 아는 사람이 점점 더 희귀해진다.

 

시스템의 암묵적 규칙을 기억하는 사람

 

모든 시스템에는 문서화되지 않은 규칙이 있다.

 

이 데이터는 이 경로로만 이동해야 한다.
이 흐름은 절대 깨면 안 된다.
이 기능은 빠르게 만드는 것보다 설명 가능성이 더 중요하다.
이 사용자 경험은 건드리면 안 된다.

 

이런 것들은 대개 문서에 없다.
사람 머릿속에만 있다.

 

그리고 AI는 바로 이 지점에서 자주 “그럴듯하게” 틀린다.

 

그래서 앞으로 남는 개발자는 추상적인 윤리 감독관 같은 이미지보다, 시스템의 암묵적 규칙을 기억하고 지키는 사람에 더 가깝다. 윤리는 그 일부일 뿐이다. 보안, 운영 안정성, 사용자 신뢰, 조직의 암묵적 계약도 다 이 범주에 들어간다.

 

이 역할은 겉으로 보기엔 덜 화려하다.
근데 AI가 강해질수록 더 중요해진다.

 

왜냐하면 AI는 표면적 정합성을 빨리 맞추기 때문이다.
그럴수록 암묵적 규칙을 붙잡는 사람이 없으면
시스템은 더 조용하게, 더 깊게 틀어진다.

 

그래서 요즘은 진짜로 이렇게 일한다

 

이런 경험을 몇 번 겪고 나서, 지난 반년 동안 내 일하는 방식은 꽤 많이 바뀌었다.

 

2025년 11월부터 지금까지 거의 모든 개발 작업을 바이브 코딩으로 돌렸다. 내가 에디터에서 직접 코드를 친 시간은 많지 않다. Claude Code와 Codex가 주요 실무자처럼 움직였고, 나는 그들이 맥락을 제대로 이해하고 엉뚱한 실수를 덜 하도록 환경을 설계하는 쪽에 붙어 있었다.

 

실제로 내가 가장 많이 한 일은 코드 작성이 아니었다.

 

ADR을 썼다.
왜 이 구조를 선택했고, 왜 다른 안을 버렸는지를 기록으로 남겼다. ADR이 없으면 AI는 매번 새로운 최적해를 찾으려 든다. 기존 결정을 아무 의도 없이 뒤엎는다. 반대로 ADR이 있으면 반년 뒤에 새 에이전트 세션이 열려도 같은 판단을 재사용할 수 있다. AI 시대의 ADR은 취향 기록이 아니라 기억 장치에 가깝다.

 

docs를 계속 고쳤다.
AI가 코드를 읽다가 맥락을 놓치는 지점이 보이면, 그걸 설계 문서로 끌어올려 명시화했다. 코드 주석 몇 줄로 버티려 하지 않았다. 주석은 자주 무시되지만, 설계 문서는 기준점으로 재사용되기 때문이다.

 

스킬 정의도 계속 손봤다.
AI가 반복적으로 같은 실수를 하면, 프롬프트 한 번 고치고 끝내지 않았다. 스킬 정의 자체를 바꿨다. 한 번 손보면 그 스킬을 호출하는 모든 세션에 같은 개선이 들어간다. 이건 일회성 수정이 아니라 반복 가능한 교정이다.

 

에이전트 팀도 나눴다.
한 에이전트가 모든 걸 하게 두지 않고, 전략, 실행, 검수, 발행처럼 역할을 나눴다. 사람 팀에서 책임 분리가 필요한 이유와 똑같다. 맥락을 너무 많이 쥔 한 에이전트는 금방 흐려진다.

 

훅과 MCP도 만들었다.
실수 가능성이 높은 지점에 자동화된 가드레일을 심었다. 특정 파일을 건드릴 때 필요한 문맥을 자동으로 주입하고, 커밋 전에 특정 규칙을 검사하고, 위험한 루트를 막는 식이다. 이건 “AI에게 잘 설명하기”와는 다른 종류의 일이다. 설명은 무시될 수 있지만, 구조는 우회하기 어렵다.

 

그리고 계속 신경 쓰는 게 하나 더 있다.
토큰 낭비다.

 

어떤 문맥을 언제 주입할지,
어떤 일을 어떤 에이전트에 맡길지,
어디까지 자동화하고 어디서 끊을지.

 

이 결정들은 품질도 정하고 비용도 정한다. 5천 토큰이면 끝날 일을 5만 토큰으로 돌린다고 결과가 꼭 더 좋아지지 않는다. 오히려 흐려질 때도 많다. 그래서 설계자는 이제 결과물만 보는 게 아니라, 그 결과가 얼마의 비용과 얼마의 복잡도로 나왔는지도 같이 본다. 이건 예전엔 거의 없던 감각이다.

 

코드를 덜 치게 됐다고 일이 줄어든 건 아니다.
무게중심이 완전히 다른 쪽으로 옮겨갔을 뿐이다.

 

가장 어려운 질문은 아직 남아 있다

 

여기서 제일 솔직해져야 하는 부분도 있다.

 

좋다. 앞으로 설계자, 판단자, 책임자가 남는 자리가 된다고 치자.
그런 사람은 어떻게 길러지나?

 

이건 나도 아직 답을 못 찾았다.

 

예전 시니어 개발자의 판단력은 대부분 구현의 고통에서 나왔다.
실패한 구현, 운영 사고, 새벽 롤백, 성능 병목, 데이터 정합성 깨짐, 팀 커뮤니케이션 실패. 이런 비용을 실제로 맞아보면서 “이 결정은 위험하다”는 감각이 생겼다.

 

근데 AI가 구현 고통을 너무 많이 흡수하면 어떻게 되나.
겉으로는 빨리 만들지만 판단은 얕은 설계자가 나올 수 있다.

 

이건 진짜 위험하다.
그리고 이미 조금씩 보이는 것 같기도 하다.

 

AI가 써준 코드를 이해하지 못한 채 PR을 올리는 주니어,
리팩토링 결과를 깊게 읽지 않고 그냥 머지하는 팀.
지금은 그게 낯설지 않다.

 

문제는 그 결과가 당장 티가 잘 안 난다는 점이다.
코드는 돌아가고 테스트는 통과한다.
진짜 문제는 6개월 뒤에 온다.

 

그 코드를 처음 낸 AI도, 머지한 사람도, 그때 왜 그렇게 했는지 기억하지 못한다. 버그가 터지면 아무도 구조를 해석하지 못한다. 해석을 못 하니까 고치지 못한다. 결국 “이 모듈은 너무 복잡하니까 다시 짜자”는 이름으로 같은 루프가 반복된다.

 

그래서 앞으로의 성장 경로는 꽤 다르게 생길 것 같다.

 

예전에는 많이 구현해본 사람이 깊어졌다.
앞으로는 많이 판단해보고, 많이 검증 실패를 겪어본 사람이 깊어질 가능성이 크다.

 

가장 귀한 학습 자산도 코드 그 자체보다 실패 로그, 의사결정 기록, 반례 모음 쪽으로 이동할 수 있다. “왜 이 설계가 틀렸는지”에 대한 구체적인 사례가 쌓인 사람이 결국 가장 강한 판단자가 된다.

 

그래서 요즘은 의식적으로 세 가지를 남기려 한다.

 

AI가 그럴듯하게 틀린 순간의 로그.
왜 틀렸는지, 무엇을 못 봤는지, 다음에 같은 패턴을 어떻게 빨리 알아볼지를 적는다. AI의 실수 패턴은 의외로 꽤 반복적이다.

 

의사결정의 “왜”.
결론만 적으면 나중에 본인도 왜 그렇게 했는지 잊는다. 어떤 안을 선택했고 왜 다른 안을 버렸는지를 남겨야 한다. 이건 몇 달 뒤 에이전트가 “깔끔한 최적화”를 들고 왔을 때 그걸 막아주는 유일한 방패가 된다.

 

반례 모음.
이 규칙이 왜 있는지, 깨지면 무슨 일이 벌어지는지 구체적 사례로 남겨둔다. 규칙만 주면 AI는 언젠가 다시 어긴다. 근데 반례까지 붙어 있으면 멈칫한다. 이유를 이해하기 때문이다. 정확히 말하면, 이유를 이해한다기보다 최소한 위험 신호를 더 강하게 인식한다.

 

지금 AI를 쓰면서 겪는 실패를 그냥 지워버리면 안 되는 이유가 여기 있다.
그 실패들이 앞으로 판단 근육이 될 가능성이 크기 때문이다.

 

남는 자리는 줄어드는 게 아니라 오히려 넓어지고 있다

 

AI가 코드를 더 잘 짤수록 사라지는 건 “구현만 하던 개발자”다.

 

반대로 더 희소해지는 건
무엇이 정답인지 정의하고,
제약을 관리하고,
결과에 책임질 수 있는 개발자다.

 

이 사람은 감독관이 아니다.
결과에 도장 찍는 사람이 아니다.
결과를 설명할 수 있고, 반례로 검증할 수 있고, 시스템의 불변식을 말할 수 있는 사람이다.

 

나는 결국 이 문장으로 정리하게 된다.

 

책임은 직함이 아니라 해석 능력이다.

 

예를 들어 AI가 “성능 최적화를 위해 이 함수에 캐시를 추가했습니다”라고 말한다고 치자. 해석 능력이 있는 사람은 바로 묻는다. 이 캐시의 만료 조건은 뭐지. 동시성 상황에서 꼬이면 어떻게 되지. 세션 경계를 넘나드는 값인데 이전 사용자의 데이터가 다음 사용자에게 새지 않나. 이런 질문을 할 수 있어야 책임자다. “음, 깔끔해 보이네” 하고 머지하는 사람은 승인자일 뿐이다.

 

이게 가능하려면 도메인을 이해해야 하고, 시스템의 불변식을 설명할 수 있어야 하고, AI가 낸 결과의 위험 지점을 먼저 감지할 수 있어야 한다. 이걸 못하면 결국 AI 결과를 통과시키는 중간 관리자가 된다. 그리고 그런 자리는 AI가 더 좋아질수록 제일 먼저 흔들린다.

 

AI가 개발자를 없앤다는 말이 진짜로 의미하는 건 사실 이쪽에 더 가깝다.

 

AI의 결과에 책임질 수 없는 사람은 자리가 줄어든다.
반대로 책임질 수 있는 사람의 자리는 더 커진다.

 

한 명의 판단자가 여러 AI를 동시에 돌릴 수 있는 시대니까, 판단 하나가 걸 수 있는 레버리지가 훨씬 커졌기 때문이다. 예전엔 개발자 10명이 달라붙어야 했던 프로젝트를, 이제는 설계 감각 있는 두세 명과 에이전트 팀이 돌릴 수도 있다. 이 구조에서 몸값이 높아지는 건 “두세 명 안에 들어갈 수 있는 사람”이다. 그리고 그 자리에 들어가는 조건은 코드를 얼마나 빨리 치느냐가 아니라, 우리 시스템에서 무엇이 지켜져야 하는지 얼마나 정확히 알고 있느냐다.

 

그래서 지금 필요한 건 막연한 공포가 아니다.
판단 근육을 어디서 기를지에 대한 계획이다.

 

AI가 구현을 가져갈수록
사람이 더 많이 하게 되는 건 판단이니까.