2026년 3월 말에 앤트로픽이 Claude Code의 소스맵 파일을 공개 npm 패키지에 그대로 실어 보낸 일이 있었습니다. 빌드에 쓰는 Bun이 소스맵을 기본으로 만드는데 .npmignore에 *.map을 안 넣어둬서, 난독화되지 않은 TypeScript 원본이 패키지 안에 들어갔습니다. 경위는 이미 공개돼 있습니다.
저는 사고 내용보다 그 직후 반응이 더 눈에 남았습니다. 사람들이 제일 먼저 궁금해한 게 이거였거든요.
"이거 사람이 놓친 거야, 에이전트가 놓친 거야?"
원인은 사람 쪽 설정 누락으로 정리됐으니 질문 자체는 금방 답이 났습니다. 그런데 그 질문이 제일 먼저 튀어나왔다는 게 저한테는 더 흥미로웠습니다. 사고가 나면 원인을 사람이냐 AI냐부터 나누고 싶어지는 때가 온 것 같습니다. 그리고 그 질문 뒤에는 거의 자동으로 다음 질문이 붙습니다.
"그래서 누가 책임지는데?"
요즘 진로 고민하는 학생들이나 취업 앞둔 컴공과 4학년, 주니어들이 자꾸 꺼내는 불안도 결국 이쪽으로 모이는 것 같습니다. AI가 이렇게 빨라지면 내 일이 남을까. 지금 배우는 게 5년 뒤에도 쓸모가 있을까. 지금 이 업계에 들어가는 게 맞을까. 바닥까지 내려가면 질문은 하나입니다. AI가 거의 다 하게 되면 사람한테 남는 일이 진짜 있긴 한가.
저는 꽤 오래 이 질문에 같은 답을 해왔습니다. 있다고요. 그리고 그 위치는 생각보다 잘 안 없어진다고요. 그 답을 할 때 제가 떠올리는 건 늘 코드를 누가 쓰느냐가 아니라 사고가 났을 때 누구 이름이 불리느냐 쪽이었습니다.
리콜 발표문의 로봇
리콜 발표문을 읽어보면 문장이 대체로 똑같습니다. 어느 차종의 어느 부품에서 어떤 결함이 확인됐고 제조사가 자발적으로 시정 조치를 한다는 내용입니다. 거기 로봇이 나오는 경우는 없습니다.
생각해보면 좀 이상합니다. 자동차 공장은 오래전부터 로봇이 공정 대부분을 돌립니다. 용접도 도장도 조립도 합니다. 사람보다 정확하고 지치지 않고 일정합니다. 그러니 브레이크 배관이 잘못 조립돼서 나중에 사고가 났다면 실제로 그 조립을 한 건 로봇일 가능성이 높습니다. 그런데 그 라인의 로봇 때문이라고 끝나는 리콜은 없습니다. 아무도 그렇게 안 씁니다.
책임은 제조사로 갑니다. 더 좁히면 그 공정을 설계한 엔지니어, 품질 검수를 통과시킨 담당자, 출고를 최종 승인한 관리자 쪽으로 모입니다. 손을 쓴 게 로봇이어도 그 로봇이 어떤 동작을 하게 만들었고 그 결과가 안전한지 판단한 사람 쪽에 책임이 남습니다. 실행한 쪽과 책임지는 쪽을 처음부터 같은 걸로 안 보는 겁니다.
에이전트가 코드를 쓰는 것도 저는 이 모양을 그대로 따라간다고 봅니다. 코드가 서비스에 들어갔고 장애가 났고 데이터가 새고 고객이 피해를 봤다고 쳐보면, AI가 한 일이라고 끝나는 사고 보고서는 안 나옵니다. 리뷰한 사람, 머지한 사람, 배포를 승인한 사람, 그 에이전트가 그렇게 일하도록 세팅한 팀. 어디선가는 꼭 사람 이름이 나옵니다.
그래서 사람 실수냐 AI 실수냐는 겉모양만 기술 질문 같습니다. 실제로 묻는 건 책임을 어디에 둘 거냐이고, 그 답이 AI로 끝나는 사회는 아직 없습니다. 꽤 오래 없을 것 같고요.
로봇은 정해진 동작만 하고 AI는 스스로 판단한다는 차이는 있습니다. 용접 로봇은 좌표를 벗어나지 않는데 에이전트는 시키지도 않은 파일을 열어봅니다. 그런데 책임 쪽에서 보면 저는 이 차이가 오히려 반대로 작용한다고 생각합니다. 판단을 한다는 건 판단이 틀릴 수 있다는 거고, 그러면 틀린 판단의 결과를 받을 쪽이 더 분명해야 합니다. 로봇이 좌표를 안 벗어나면 좌표를 정한 사람만 보면 됩니다. 에이전트가 스스로 범위를 넓힐 수 있으면 그 범위를 어디까지 허용했는지 정한 사람이 필요해집니다. 자율성이 올라갈수록 책임이 흐려지는 게 아니라, 그 자율성의 경계를 정한 사람 쪽으로 더 선명하게 모이는 것 같습니다.
그 경계를 정할 때 제일 먼저 보게 되는 건 되돌릴 수 있느냐인 것 같습니다. 에이전트가 브랜치 하나에 코드를 잔뜩 써놓는 건 마음에 안 들면 지우면 됩니다. 머지나 배포, 데이터 삭제, 밖으로 나가는 메일 같은 건 한번 나가면 주워 담기가 어렵습니다. 에이전트가 똑똑해질수록 앞쪽은 더 맡겨도 된다고 보는데, 뒤쪽은 아무리 똑똑해져도 사람이 한 번 누르는 단계가 남아야 할 것 같습니다. 사고 보고서에 사람 이름이 올라가는 것도 결국 그 한 번을 누른 사람이라서요.
책임은 느리게 바뀝니다
AI가 점점 스스로 일하면 결국 책임도 AI한테 넘어가지 않겠냐는 기대를 자주 듣습니다. 방향만 보면 그럴 수도 있는데 속도가 전혀 다르다고 봅니다.
자율주행이 딱 그랬습니다. 센서도 판단도 제어도 예전보다 훨씬 좋아졌고, 기술 시연만 보면 이제 거의 다 왔다는 말이 몇 년째 반복됩니다. 그런데도 완전 자율주행이 사회 전체의 기본값이 안 되는 건 기술이 덜 좋아서만은 아닌 것 같습니다. 사고가 났을 때 누구 책임인지가 안 끝났기 때문입니다.
제조사인지, 운전자인지, 소프트웨어 공급자인지, 인프라 관리자인지. 이걸 법과 보험과 판례와 내부 기준으로 정리해야 하는데 이쪽은 기술 데모보다 훨씬 느립니다. 몇 년 단위가 아니라 거의 체제 단위로 바뀝니다.
AI 코딩도 비슷한 구간에 들어와 있다고 봅니다. AI가 코드를 많이 쓰는 건 이미 되고 있습니다. 테스트도 만들고 수정안도 내고 PR 초안도 씁니다. 여기까지는 기술 문제입니다. 그런데 그 결과가 문제를 일으켰을 때 법적으로든 조직적으로든 책임을 AI한테 돌리는 체계는 아직 없습니다. 이건 모델이 좋아진다고 저절로 따라오는 변화도 아닙니다. 법, 보험, 감사 기준, 내부 통제, 고객한테 설명하는 방식이 다 같이 바뀌어야 합니다. 기술이 더 많은 걸 할수록 그 결과를 대신 받아줄 사람은 당분간 계속 필요할 것 같습니다.
이게 영영 안 바뀐다고는 생각하지 않습니다. 다만 바뀌는 순서가 기술 쪽은 아닐 것 같습니다. 자율주행에서 실제로 바뀐 건 성능 지표가 아니라 특정 조건에서 누가 책임을 받느냐였습니다. 어떤 속도와 어떤 도로와 어떤 날씨에서는 제조사가 받는다고 정해진 다음에야 그 범위 안에서 기능이 기본값이 됐습니다. 기술이 전 구간을 다 해결해서 넘어간 게 아니라 책임 받을 쪽이 정해진 좁은 구간부터 넘어간 겁니다.
AI 코딩도 그런 모양으로 올 것 같습니다. 통째로 맡기는 게 아니라, 이 종류의 변경은 이 조건에서 자동 배포하고 문제가 생기면 이쪽이 받는다는 식의 좁은 합의가 먼저 생기고 그 범위가 조금씩 넓어지는 쪽이요. 그래서 저는 모델 벤치마크 점수보다 계약서와 보험 약관 쪽을 보고 있습니다. 그쪽이 바뀌기 시작하면 그게 진짜 변화일 것 같습니다.
좁은 합의가 먼저 생긴다면 그 첫 구간도 아마 되돌리기 쉬운 쪽일 겁니다. 설정 하나, 문구 하나, 기능 플래그 뒤에 숨은 변경처럼 잘못돼도 바로 끌 수 있는 것들이요. 되돌리기 어려운 변경일수록 그 합의는 늦게 올 거고, 데이터를 지우거나 돈이 오가는 쪽은 제일 마지막까지 사람 이름이 붙어 있을 것 같습니다. 되돌릴 수 있느냐로 줄을 세워보면 AI 가 어디부터 혼자 하게 될지 대충 보이는 것 같기도 합니다. 성능보다는 실수했을 때 얼마나 빨리 원래대로 돌릴 수 있느냐가 그 순서를 정하는 거죠. 그렇게 보면 개발자가 오래 붙들고 있게 될 일도 대충 짐작이 갑니다. 되돌리기 어려운 쪽, 그러니까 한 번 나가면 다시는 원래대로 못 돌리는 변경 앞에서 마지막으로 확인하는 일입니다. 그 일은 코드를 덜 쓰게 돼도 줄어들지 않을 것 같습니다. 오히려 에이전트가 많이 만들수록 그 앞에 쌓이는 변경도 많아지니, 확인할 일은 늘어날 수도 있습니다. 그 확인을 누가 할지가 남습니다.
기업 쪽에서 보면
개인 입장에서는 이 얘기가 좀 추상적으로 들릴 수 있는데, 기업 쪽에서 보면 훨씬 선명해집니다.
AI가 빠르고 싸니까 결국 다 흡수되겠지, 하는 분위기가 있습니다. 큰 방향은 맞다고 봅니다. 도메인을 이해하는 AI는 이미 들어와 있고 판단을 거드는 AI도 빠르게 늘고 있습니다. 그런데 기술적으로 된다는 것과 기업이 그걸 실무 표준으로 받아들일 수 있다는 건 전혀 다른 얘기입니다.
실제 기업에서 AI 도입이 어디까지 왔냐고 물으면 층마다 대답이 다릅니다. 맨 아래는 이미 끝났습니다. 문서 요약, 코드 설명, 리뷰 보조, 온보딩 지원처럼 도메인 이해를 돕는 쪽은 정착해서 도입할지 말지를 논의하지도 않습니다. 그 위의 판단 보조도 빠르게 넓어지고 있습니다. 설계 대안을 늘어놓고, 테스트 케이스를 만들고, 장애 원인 후보를 좁혀줍니다. 그래도 마지막에 고르는 건 사람입니다.
막히는 건 그 위, 책임까지 넘기는 층입니다. 말은 많이 나오는데 실제로 표준이 된 사례를 물으면 대부분 대답이 멈춥니다. 위로 갈수록 기술이 아니라 구조에 걸리기 때문인 것 같습니다.
기업에서 장애가 하나 나면 모든 추적은 사람 이름으로 흘러갑니다. 누가 커밋했는지, 누가 PR을 승인했는지, 누가 배포했는지, 누가 사후 감사에서 설명할지. 보안팀, 감사팀, 법무팀, 경영진 보고 라인이 전부 이 기준으로 돌아갑니다. AI가 그렇게 판단했다는 로그는 남길 수 있습니다. 하지만 그 로그를 법정에서, 감사 문서에서, 고객 공지에서 책임 주체로 세울 수 있는 체계는 아직 없습니다. 이걸 바꾸는 건 모델 하나 바꿔 끼우는 일과는 차원이 다르고, 모델이 몇 배 좋아지는 것보다 훨씬 느릴 겁니다.
그래서 기업 속도는 대체로 이렇게 보입니다. 도메인 이해 보조는 넓어지고, 같이 판단하는 AI도 더 깊이 들어옵니다. 책임까지 넘기는 AI는 훨씬 천천히, 아주 조심스럽게 들어옵니다.
이 세 층이 꼭 순서대로 열리는 것도 아닙니다. 어떤 회사는 판단 보조를 건너뛰고 책임 쪽부터 실험합니다. 사내 도구나 내부 관리 화면처럼 잘못돼도 고객이 안 보는 데서는 자동 배포를 그냥 켜버립니다. 반대로 결제나 개인정보가 붙은 쪽은 문서 요약조차 반려되기도 합니다. 층을 나누는 기준이 기술 난이도가 아니라 잘못됐을 때 누가 얼마나 다치느냐인 겁니다. 개발자의 위치가 생각보다 오래 갈 거라고 보는 것도 이 간극 때문입니다.
월급과 토큰 비용
AI 붐을 단순하게 줄이면 늘 두 줄입니다. 코드를 잘 짠다. 토큰 비용이 사람 인건비보다 싸다. 이 두 줄만 보면 경영진 입장에선 안 쓸 이유가 없어 보입니다. 시니어 개발자 한 명 월급보다 훨씬 적은 돈으로 더 빨리 결과가 나온다는 얘기니까요.
그런데 이 계산에는 책임 비용이 빠져 있습니다.
장애가 실제로 터지면 기업이 감당하는 건 개발자 한 명 월급보다 훨씬 클 때가 많습니다. 장애 대응 인건비, 고객 보상, SLA 위약금, 매출 손실, 감사 대응, 브랜드 신뢰, 법적 리스크. 이런 비용은 책임 주체가 분명할 때만 관리가 됩니다. 제조사는 제조물 책임 보험을 들고, 임원은 임원 배상책임 보험으로 막고, 개발팀은 재발 방지 프로세스로 설명할 수 있습니다. AI한테 책임을 넘긴다는 건 이걸 전부 다시 설계해야 한다는 뜻입니다. 보험도 감사도 법무 문서도 고객 설명 방식도 바뀌어야 하고, 이건 모델이 더 똑똑해진다고 알아서 풀리지 않습니다.
그래서 실제 기업의 계산은 사람 월급 대 토큰 비용 두 항으로 안 끝나고, 그 뒤에 책임이 불확실해서 생기는 비용이 붙습니다. 토큰이 아무리 싸도 그 불확실성이 크면 아낀 돈이 쉽게 사라지고, 어떤 영역에서는 오히려 손해가 납니다.
그러다 보니 실무에서는 구현은 AI에게, 책임은 사람에게라는 구조가 자연스럽게 굳어가는 것 같습니다. AI가 코드 대부분을 써도 마지막 게이트에는 사람 이름이 올라갑니다. PR을 승인하는 사람, 배포 버튼을 누르는 사람, 사고가 나면 설명할 사람. 이 안에서 개발자는 점점 코드를 치는 사람보다 리스크를 받아내는 사람 쪽으로 옮겨 갑니다. 코드 치는 쪽은 AI가 꽤 많이 가져갈 수 있겠지만, 리스크를 받는 쪽은 기업이 당분간 사람한테 붙여둘 수밖에 없는 역할입니다.
저는 이걸 좋은 소식으로만 읽지는 않습니다. 책임이 사람한테 남는다는 건 권한은 줄고 책임만 그대로인 역할이 생길 수 있다는 얘기이기도 합니다. 구현을 AI가 하면 그 코드가 어떻게 생겼는지에 대한 통제는 줄어드는데, 사고가 나면 설명은 여전히 사람이 해야 합니다. 꽤 불편한 조합입니다. 예전에는 제가 짠 코드라 제가 설명할 수 있었습니다. 지금은 제가 승인한 코드인데 왜 그렇게 생겼는지는 제가 정하지 않은 경우가 늘어납니다. 승인 버튼을 누를 때는 그 차이가 잘 안 느껴지는데, 장애 회의에서 이 줄은 왜 이렇게 됐냐는 질문을 받는 순간 아주 크게 느껴질 것 같습니다.
이 간극을 안 메우면 개발자 위치는 남되 점점 나쁜 일이 될 것 같습니다. 통제는 못 하고 책임은 지는 일이요. 그래서 책임이 남으니 안심해도 된다는 말은 저는 별로 안 믿습니다. 남는 건 위치이고, 그 위치가 괜찮을지는 통제를 얼마나 되찾아오느냐에 달려 있다고 보고 있습니다.
감독관이라는 말
이쯤 되면 앞으로 개발자는 AI를 감독하는 사람이 되겠다고 말하고 싶어집니다. 저는 이 표현이 좀 위험하다고 봅니다.
감독관은 감독만 하면 됩니다. 결과를 보고 통과인지 반려인지 정하면 끝입니다. 실제로 필요한 사람은 그게 아니라, AI가 만든 결과가 왜 맞고 왜 틀린지 설명할 수 있고 반례를 들어 검증할 수 있는 사람입니다.
감독만 하는 사람은 겉으로 그럴듯한 데 속습니다. AI 결과물은 대부분 말이 되는 상태로 나옵니다. 변수 이름도 괜찮고 함수 분리도 멀쩡하고 에러 처리도 대충 있습니다. 깊이를 모르면 그냥 통과시킵니다. 그러다 어느 선을 넘으면 모순이 터집니다. 그때가 되면 각자는 자기 영역은 멀쩡했다고 말하고, 검토자는 통과만 눌렀다고 말하고, AI는 원래 책임 주체가 아닙니다. 빈칸만 남습니다.
저는 책임이 결과를 승인하는 권한에서 나오는 게 아니라 이 결과가 왜 맞는지 틀린지 설명할 수 있는 데서 나온다고 생각합니다. 해석을 못 하는 사람은 책임자라기보다 도장 찍는 사람에 가깝습니다.
예를 들어 AI가 성능 최적화를 위해 이 함수에 캐시를 추가했다고 말한다고 쳐보겠습니다. 해석할 줄 아는 사람은 바로 묻습니다. 이 캐시는 언제 만료되지. 동시에 여러 요청이 들어오면 어떻게 되지. 세션 경계를 넘는 값인데 이전 사용자 데이터가 다음 사용자한테 새지는 않나. 이런 걸 물을 수 있어야 책임자입니다. 음, 깔끔해 보이네 하고 머지하는 사람은 승인자일 뿐입니다.
되돌릴 수 없는 단계 앞에서도 비슷한 걸 묻게 됩니다. 이 머지가 잘못되면 어디까지 되돌릴 수 있지. 이 마이그레이션은 롤백이 되나. 지우려는 대상이 몇 분 전에 본 그 상태가 지금도 맞나. 이런 걸 묻는 사람이 그 버튼 앞에 서 있어야 그 이름이 보고서에 올라갈 때 의미가 있습니다. 아무것도 안 묻고 누른 이름도 보고서에는 똑같이 올라가는데, 그 이름은 책임을 졌다기보다 그 시간에 그 버튼 앞에 있었다는 기록에 가깝습니다.
이 차이는 금방 드러날 것 같습니다. 처음에는 AI 결과 검토자 같은 역할이 생길 수 있습니다. 코드를 읽고 통과인지 아닌지 판정하는 사람입니다. 그런데 시간이 지나면 AI 품질이 올라가고 반려가 줄어듭니다. 그러면 조직은 이 역할이 왜 있냐고 묻기 시작합니다. 검토자가 왜 반려인지 기술적으로 설명을 못 하면 그 역할은 곧 자동 통과 흐름으로 흡수됩니다. 실무도 설계도 안 하는 애매한 중간 계층이 되는 건데, 저는 이게 AI 시대에 제일 먼저 압박받는 역할이라고 봅니다. 반려 사유를 말로 풀 수 있는 사람은 그 말 자체가 일의 증거로 남는데, 통과만 누른 사람은 남는 게 클릭 기록뿐이라 조직이 보기엔 없어도 되는 사람처럼 보이기 쉽습니다.
1인 개발과 대기업
모든 개발자가 같은 AI 시대를 사는 것도 아닌 것 같습니다.
AI가 개발자를 바로 대체하는 것처럼 느껴지는 데가 분명 있습니다. 1인 개발자, 인디 해커, 극초기 스타트업, 아주 작은 팀. 여기서는 실제로 구현 대부분을 AI가 가져가고 있고 운영 부담도 비교적 가볍습니다. 유튜브나 X에서 보이는 AI로 혼자 앱 만들었다, 에이전트로 서비스 런칭했다 같은 사례도 대부분 여기서 나옵니다. 이쪽은 느끼는 대로가 맞습니다. 혼자서도 꽤 많은 걸 해낼 수 있습니다.
그런데 이걸 대기업에 그대로 가져오면 그림이 완전히 달라집니다. 대기업에서 장애가 나면 보고 라인이 바로 열립니다. 팀장, 파트장, 본부장, 임원, 때로는 대외 커뮤니케이션팀까지 붙습니다. 이때 팀장이 AI가 짠 코드에서 문제가 났다는 문장 하나로 설명을 끝낼 수 있을까요. 못 합니다. 바로 질문이 이어집니다. 누가 리뷰했는가. 누가 승인했는가. 누가 배포했는가. 이 PR에 이름 올린 사람은 누구인가. 여기에 답을 못 하면 장애 규모보다 책임이 비어 있다는 게 더 큰 문제로 지적됩니다. 조직은 책임 추적이 끊긴 상태를 장애 그 자체보다도 훨씬 더 싫어한다고 봅니다. 장애는 고치면 끝나는데 끊긴 추적은 다음 장애 때 또 문제가 되니까요.
1인 개발자는 이 사슬이 자기 혼자라 망하면 본인이 감당합니다. 그래서 AI한테 다 맡겼다는 말이 비교적 쉽게 성립합니다. 대기업은 수십, 수백 명의 이름이 이어진 구조라서 AI가 했다는 말이 사실상 책임 사슬을 끊는 말이 됩니다. 조직이 이걸 받아들이지 않는 건 느려서가 아니라 감당해야 할 규모가 달라서인 것 같습니다.
그래서 똑같이 AI를 보고도 사람마다 온도가 다릅니다. 1인 개발자 쪽에선 이제 거의 다 된다는 말이 정말 실감 나고, 대기업 쪽에선 AI가 많이 할수록 책임질 사람이 더 중요해진다는 감각이 강해집니다. 서 있는 곳이 달라서 둘 다 자기 쪽에서는 맞는 말입니다.
커리어를 고민할 때도 AI가 개발자를 대체하냐를 통째로 묻는 건 그다지 쓸모 있는 질문이 아닌 것 같습니다. 어느 쪽에서 일할 생각인지를 먼저 정하면 답이 꽤 달라집니다. 혼자 만들어서 파는 쪽을 보고 있다면 AI는 지금 제일 큰 도움입니다. 큰 조직에서 큰 시스템을 맡을 생각이라면, AI가 늘려주는 건 만들 수 있는 양보다 설명해야 할 양일 겁니다.
중간에 낀 쪽
그 사이에 낀 쪽도 있습니다. 중소기업, 중견기업, 월급쟁이 개발자들이 있는 곳입니다.
유튜브에서 자주 보이는 AI 생산성 사례는 대개 두 끝에서 나옵니다. 자기 돈을 쓰더라도 레버리지가 큰 1인 개발자와 창업자, 그리고 전사적으로 AI 툴을 깔아주는 대기업과 테크 기업. 그 사이 사람들은 풍경이 다릅니다.
AI가 좋다는 건 알겠는데, 개발자 한 명당 매달 삼십만 원 가까운 툴을 회사가 결제해줄까. 이 질문 앞에서 많은 중소기업이 멈춥니다. 남은 인력도 빠듯한데 전사 라이선스를 과감하게 깔아주는 회사는 생각보다 드뭅니다. 그래서 현장에서는 종종 쓰고 싶으면 개인이 결제해서 쓰라는 쪽으로 갑니다. 유튜브에서는 다들 에이전트 팀을 돌리고 있는데 실제 현장에서는 무료 플랜 한도 안에서 겨우겨우 쓰는 경우도 많습니다. 개인이 자기 돈으로 AI를 사는 구조가 왜 자꾸 나오는지도 이 처지에서 보면 이해가 됩니다. 이 구간이 생각보다 크고, 여기 있는 개발자가 보는 AI 시대는 콘텐츠에서 보는 풍경과 꽤 다릅니다.
학생과 주니어한테 불편한 얘기도 여기서 나옵니다. 책임을 사람이 진다는 구조는 그 사람이 책임질 수 있는 사람이어야 성립합니다. 그리고 조직은 갓 들어온 사람한테 그 역할을 안 줍니다.
예전에는 이게 시간으로 풀렸습니다. 주니어가 작고 위험이 낮은 일을 맡아서 구현하고, 몇 년 그러다 보면 판단할 수 있게 됐습니다. 그런데 그 작고 위험이 낮은 일이 정확히 AI가 제일 먼저 가져가는 구간입니다. 입구 쪽 계단이 없어지고 있는 셈입니다. 위치가 남는다는 말과 거기 새로 들어갈 길이 있다는 말은 다릅니다. 신규 채용에서 제일 먼저 줄어드는 쪽도 여기라고 보고 있습니다.
그래도 하나는 달라졌습니다. 예전에는 판단력을 기르려면 위험한 일을 맡을 권한이 있어야 했는데, 지금은 AI한테 설계안을 받아서 그게 어디서 틀렸는지 짚어보는 연습을 혼자서도 할 수 있습니다. 예전 주니어한테 부족했던 건 시간이 아니라 기회였고, 그 기회는 오히려 늘었습니다. 그 연습을 실제로 하는 사람이 몇이나 될지는 또 다른 얘기겠지만요.
학생이나 주니어가 유튜브에선 다 혼자 다 하던데요, 하고 느끼는 것도 이해는 됩니다. 다만 그런 사례 대부분은 1인 개발 쪽에서 나옵니다. 실제로 많은 사람이 들어가게 될 중견기업이나 대기업에서는 얘기가 좀 다르고, 거기서는 오히려 책임질 수 있는 사람의 값이 올라가고 있습니다.
20년 가까이
이 얘기를 저는 꽤 오래 해왔습니다. 그때는 AI가 아니라 클라우드였고 프레임워크였고 오픈소스였고 자동화였습니다. 패턴은 매번 비슷했습니다. 새 기술이 나오면 이걸로 다 된다는 공기가 먼저 돌고, 개발자 할 일이 줄어든다는 불안이 뒤따랐습니다. 몇 년 지나면 실제로 어떤 공정은 흡수됐습니다. 그런데 개발자가 없어진다는 예측은 매번 빗나갔습니다. 사라진 건 특정 구현 작업이었고, 남은 건 그 기술을 쓰는 판단과 그 결과를 감당하는 책임이었습니다.
그래서 늘 사라질 걸 붙잡지 말고 안 사라질 걸 쌓으라고 말해왔습니다. 문제가 뭔지 정의하는 능력, 여러 후보 중 우리 상황에 맞는 걸 고르는 판단력, 결과가 왜 맞고 왜 틀린지 설명하는 이해, 판단이 틀렸을 때 고쳐내는 대응력 같은 것들입니다. 이건 언어가 바뀌어도 남고 프레임워크가 바뀌어도 남고 AI가 코드를 많이 써도 남습니다. 오히려 구현이 쉬워질수록 값이 올라갑니다. 뭘 구현할지, 그 구현이 우리한테 맞는지를 정하는 사람이 더 귀해지니까요.
이번엔 범위가 좀 넓긴 합니다. 클라우드는 서버 구축을 가져갔고 프레임워크는 반복 코드를 가져갔지만, 둘 다 무엇을 만들지 정하는 쪽은 안 건드렸습니다. AI는 그쪽에도 후보안을 냅니다. 그래도 후보안을 내는 것과 그중 하나를 골라서 책임지는 것 사이의 거리는 아직 남아 있다고 봅니다. 이번에도 비슷하게 갈 거라고 생각하는 건 모델 능력 때문이 아니라 그 거리 때문입니다.
그 판단력은 어디서
앞으로 설계하고 판단하고 책임지는 사람이 남는 역할이 된다고 치면, 그런 사람은 어떻게 길러질까요. 이건 저도 아직 답을 못 찾았습니다.
예전 시니어 개발자의 판단력은 대부분 구현하면서 겪은 고생에서 나왔습니다. 실패한 구현, 운영 사고, 새벽 롤백, 성능 병목, 데이터 정합성이 어긋난 일, 팀 커뮤니케이션 실패. 이런 비용을 실제로 맞아보면서 이 결정은 위험하다는 감각이 생겼습니다. 그런데 AI가 그 고생을 너무 많이 가져가면, 겉으로는 빨리 만드는데 판단은 얕은 설계자가 나올 수도 있습니다.
이게 이미 조금씩 보이는 것 같기도 합니다. AI가 써준 코드를 이해하지 못한 채 PR을 올리는 주니어, 리팩토링 결과를 깊게 안 읽고 그냥 머지하는 팀. 지금은 그게 낯설지 않습니다. 문제는 그 결과가 당장은 티가 잘 안 난다는 겁니다. 코드는 돌아가고 테스트는 통과합니다. 진짜 문제는 6개월 뒤에 옵니다. 그 코드를 처음 낸 AI도 머지한 사람도 그때 왜 그렇게 했는지 기억하지 못합니다. 버그가 터지면 아무도 구조를 해석하지 못하고, 해석을 못 하니 고치지도 못합니다. 그러면 이 모듈은 너무 복잡하니 다시 짜자는 이름으로 같은 일이 되풀이됩니다.
그런데 제가 만나본 사람 중에 판단이 제일 빠른 쪽은 제일 많이 구현한 사람이 아니었습니다. 남이 터뜨린 사고를 유심히 본 사람, 회고 문서를 실제로 읽는 사람, 자기 결정이 틀렸을 때 그걸 덮지 않고 적어둔 사람이었습니다. 필요한 건 고생 자체가 아니라 결과를 끝까지 따라가 보는 습관일지도 모르겠습니다. 그렇다면 AI가 구현을 가져간다고 판단력이 꼭 안 자라는 건 아닐 겁니다. 다만 따라가 보지 않아도 되는 환경이 훨씬 쉬워진 건 맞습니다. 예전에는 코드가 안 돌면 억지로라도 끝까지 봐야 했는데, 지금은 안 돌면 다시 물어보면 됩니다. 끝까지 따라가는 일이 강제에서 선택으로 바뀌었고, 선택이 된 일은 대부분 안 하게 됩니다.
그래서 앞으로는 많이 구현해본 사람보다 많이 판단해보고 검증에 많이 실패해본 사람이 깊어질 것 같습니다. 제일 귀한 공부 재료도 코드보다는 실패 로그, 의사결정 기록, 반례 모음 쪽이 될지도 모릅니다.
요즘 저는 AI가 그럴듯하게 틀린 순간을 적어두려고 합니다. 왜 틀렸는지, 뭘 못 봤는지, 다음에 같은 패턴을 어떻게 빨리 알아볼지. AI 실수는 의외로 꽤 반복됩니다. 결정을 내릴 때는 결론만 말고 왜 그랬는지도 남깁니다. 결론만 적으면 나중에 저도 왜 그랬는지 잊어버리는데, 어떤 안을 골랐고 왜 다른 안을 버렸는지가 남아 있으면 몇 달 뒤에 에이전트가 깔끔한 최적화를 들고 왔을 때 그걸 막을 거의 유일한 근거가 됩니다. 규칙에는 반례를 같이 붙여둡니다. 이 규칙이 왜 있는지, 안 지키면 무슨 일이 생기는지를 실제 사례로요. 규칙만 주면 AI는 언젠가 다시 어기는데 반례까지 붙어 있으면 좀 멈칫합니다. 이유를 이해해서라기보다 위험 신호를 더 세게 받는 것 같습니다. AI를 쓰면서 겪는 실패를 그냥 지워버리면 아깝다고 생각하는 것도 그래서입니다.
불안을 어디에 걸어두느냐
학생이든 주니어든 AI 때문에 불안해하는 걸 탓할 생각은 없습니다. 저라도 이런 때 커리어를 시작했으면 비슷하게 흔들렸을 겁니다. 변화가 빠르다는 체감은 진짜이고, 주니어 사다리가 실제로 얇아지고 있다는 얘기도 괜한 걱정은 아닙니다.
다만 그 불안을 어디에 걸어두느냐는 좀 다른 문제 같습니다. AI가 내 일을 뺏는 거 아닌가로만 불안해하면 할 수 있는 게 별로 없습니다. 내 바깥에서 일어나는 변화만 쳐다보게 됩니다. 그런데 결과를 감당할 수 있는 개발자가 되려면 지금 뭘 쌓아야 하지, 로 묻기 시작하면 할 일이 꽤 구체적으로 보입니다. 문제를 정의하고, 설계하고, 실패를 해석하고, 결정의 근거를 적고, 설명하는 일들이요. 비슷해 보이는 두 질문인데, 앞의 걸 붙들고 있으면 유행만 따라다니게 되고 뒤의 걸 붙들면 판단하는 힘이 붙습니다. 몇 년 지나면 그 차이가 꽤 벌어질 것 같습니다.
앤트로픽 소스맵 노출 같은 일은 앞으로도 계속 생길 겁니다. AI가 코드의 더 많은 부분을 쓸수록 사고 원인이 사람인지 AI인지 구분이 잘 안 되는 순간도 늘어날 거고, 그때마다 같은 질문이 나올 겁니다. 그래서 누가 책임지는데. 저는 그 답이 한동안, 아마 꽤 오래 사람으로 끝날 거라고 보고 있습니다. 로봇이 자동차를 만들어도 사고가 나면 제조사가 책임지듯, 에이전트가 코드를 써도 장애가 나면 그걸 배포한 팀이 책임집니다.
한 사람이 여러 AI를 동시에 돌릴 수 있게 되면서 판단 하나에 걸리는 무게는 훨씬 커졌습니다. 예전엔 열 명이 달라붙어야 했던 프로젝트를 설계 감각 있는 두세 명과 에이전트 팀이 돌릴 수도 있습니다. 그러면 몸값이 오르는 건 그 두세 명 안에 들어갈 수 있는 사람일 텐데, 거기 들어가는 조건은 코드를 얼마나 빨리 치느냐보다 우리 시스템에서 뭐가 지켜져야 하는지를 얼마나 정확히 아느냐 쪽인 것 같습니다.
댓글
댓글 쓰기