incident report에 AI agent 이름을 올릴 수 있는 회사는 아직 없습니다

2026년 3월 말에 앤트로픽이 Claude Code의 소스맵 파일을 공개 npm 패키지에 그대로 실어 보낸 일이 있었습니다. 빌드에 쓰는 Bun이 소스맵을 기본으로 만드는데 .npmignore에 *.map을 넣어두지 않아서, 난독화되지 않은 TypeScript 원본이 패키지 안에 들어갔습니다. 경위는 이미 공개되어 있습니다.

그런데 사고 내용보다 더 눈에 남은 건 그 직후에 나온 반응이었습니다. 사람들이 제일 먼저 궁금해한 게 이거였습니다.

"이거 사람이 놓친 거야, 에이전트가 놓친 거야?"

결과적으로 원인은 사람 쪽 설정 누락으로 정리됐습니다. 그러니 질문 자체는 금방 답이 났습니다. 그런데 저한테는 그 질문이 제일 먼저 튀어나왔다는 사실이 더 흥미로웠습니다.

이게 지금 풍경입니다. 사고가 나면 원인을 사람인지 AI인지부터 가르고 싶어지는 시대입니다.

그리고 그 질문 뒤에는 거의 자동으로 다음 질문이 붙습니다.

"그래서 누가 책임지는데?"

요즘 진로 고민하는 학생들이나 취업 앞둔 컴공과 4학년, 주니어들이 반복해서 꺼내는 불안도 결국 이 자리로 모입니다. AI가 이렇게 빨라지면 내 자리가 남을까. 지금 배우는 게 5년 뒤에도 쓸모가 있을까. 지금 이 업계에 들어가는 게 맞는 선택일까.

이 고민의 가장 바닥에는 사실 질문이 하나밖에 없습니다. AI가 거의 다 하게 되면 사람한테 남는 일이 진짜 있긴 한가.

저는 이 질문에 꽤 오래 같은 답을 해왔습니다. 있습니다. 그리고 그 자리는 생각보다 잘 안 없어집니다.

리콜 발표문에 로봇 얘기가 나오는 걸 본 적 있습니까

불안을 줄이려면 추상적인 얘기부터 꺼내면 안 됩니다. 실제로 굴러가는 장면 하나를 먼저 보는 게 낫습니다.

리콜 발표문을 읽어보면 문장 구조가 대체로 똑같습니다. 어느 차종의 어느 부품에서 어떤 결함이 확인됐고, 제조사가 자발적으로 시정 조치를 실시한다는 내용입니다. 여기에 로봇이 등장하는 경우는 없습니다.

이게 좀 이상한 일입니다. 자동차 공장은 오래전부터 로봇이 대부분의 공정을 돌립니다. 용접도 도장도 조립도 합니다. 사람보다 정확하고 지치지 않고 일정합니다. 그러니까 브레이크 배관이 잘못 조립돼서 나중에 사고가 났다면, 물리적으로 그 조립을 한 건 로봇일 가능성이 높습니다.

그런데 "그 라인의 로봇 때문입니다"로 끝나는 리콜은 없습니다. 아무도 그렇게 쓰지 않습니다.

책임은 제조사로 갑니다. 더 좁히면 그 공정을 설계한 엔지니어, 품질 검수를 통과시킨 담당자, 출고를 최종 승인한 관리자 쪽으로 모입니다. 손을 움직인 게 로봇이라도, 그 로봇이 어떤 동작을 하게 만들었고 그 결과가 안전한지 판단한 사람 쪽에 남습니다. 실행 주체와 책임 주체를 애초에 같은 것으로 안 보는 겁니다.

에이전트가 코드를 쓰는 상황도 이 구조를 그대로 따라갑니다. 코드가 서비스에 들어갔고 장애가 났고 데이터가 새고 고객이 영향을 받았다고 칩시다. "AI가 한 일입니다"로 끝나는 사고 보고서는 나오지 않습니다. 리뷰한 사람, 머지한 사람, 배포를 승인한 사람, 그 에이전트가 그렇게 일하도록 세팅한 팀. 어디선가는 반드시 사람 이름이 나옵니다.

그래서 "사람 실수냐 AI 실수냐"는 겉모양만 기술 질문입니다. 실제로 묻고 있는 건 책임을 어디에 둘 거냐입니다. 그리고 그 답이 "AI"로 끝나는 사회는 아직 없습니다. 꽤 오래 없을 가능성이 높습니다.

이 비유에 곧바로 나올 수 있는 반박이 있습니다. 로봇은 정해진 동작만 하고 AI는 스스로 판단하니까 같은 취급을 하면 안 된다는 얘기입니다. 맞는 지적입니다. 용접 로봇은 좌표를 벗어나지 않지만 에이전트는 시키지 않은 파일을 열어봅니다.

그런데 책임 쪽에서 보면 이 차이가 오히려 반대로 작동합니다. 판단을 한다는 건 판단이 틀릴 수 있다는 뜻이고, 틀린 판단의 결과를 받아낼 주체가 더 분명해야 한다는 뜻입니다. 로봇이 좌표를 벗어나지 않는다면 좌표를 정한 사람만 보면 됩니다. 에이전트가 스스로 범위를 넓힐 수 있다면 그 범위를 어디까지 허용했는지 정한 사람이 필요해집니다. 자율성이 올라갈수록 책임 주체가 흐려지는 게 아니라, 그 자율성의 경계를 정한 사람 쪽으로 더 선명하게 모입니다.

책임 구조는 기술보다 훨씬 느리게 움직입니다

여기서 사람들이 자주 섞어버리는 게 있습니다. AI가 점점 자율적으로 움직이면 결국 책임도 AI한테 넘어가는 거 아니냐는 기대입니다. 방향만 보면 그럴 수 있습니다. 그런데 속도가 완전히 다릅니다.

자율주행이 딱 그런 사례입니다. 센서도 좋아졌고 판단도 좋아졌고 제어도 예전보다 훨씬 정교해졌습니다. 기술 시연만 보면 "이제 거의 다 왔다"는 말이 몇 년째 반복됩니다. 그런데도 완전 자율주행이 사회 전체의 기본값이 안 되는 이유는 기술이 덜 좋아서만은 아닙니다.

사고가 났을 때 누구 책임인지가 안 끝났기 때문입니다.

제조사 책임인지, 운전자인지, 소프트웨어 공급자인지, 인프라 관리자인지. 이걸 법과 보험과 판례와 내부 기준으로 정리해야 하는데, 이 층위는 기술 데모보다 훨씬 느립니다. 몇 년 단위가 아니라 거의 체제 단위로 움직입니다.

AI 코딩도 비슷한 구간에 들어와 있습니다. AI가 코드를 많이 쓰는 건 가능합니다. 이미 되고 있습니다. AI가 테스트도 만들고 수정안도 내고 PR 초안도 작성합니다. 여기까진 기술 문제입니다.

그런데 그 결과가 문제를 일으켰을 때 법적으로나 조직적으로 책임을 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가 제일 먼저 가져가는 구간입니다. 입구 쪽 계단이 사라지고 있는 셈입니다. 자리가 남는다는 말과 그 자리에 새로 들어갈 길이 있다는 말은 다릅니다.

이건 제가 좋게 포장할 수 있는 부분이 아닙니다. 신규 채용에서 제일 먼저 줄어드는 쪽이 여기라고 보고 있습니다. 다만 한 가지는 달라졌습니다. 예전에는 판단력을 기르려면 위험한 일을 맡을 권한이 필요했는데, 지금은 AI에게 설계안을 받아서 그게 어디서 틀렸는지 짚어보는 연습을 혼자서도 할 수 있습니다. 예전 주니어가 못 가졌던 건 시간이 아니라 기회였고, 그 기회 쪽은 오히려 늘었습니다. 물론 그 연습을 실제로 하는 사람이 몇이나 되는지는 다른 문제입니다.

그러니까 학생들이나 주니어가 "유튜브에선 다 혼자 다 하던데요?"라고 느끼는 것도 이해는 됩니다. 다만 그 사례 대부분은 1인 개발자 층위에서 나옵니다. 실제로 많은 사람이 들어가게 될 중견기업이나 대기업 환경에서는 얘기가 조금 다릅니다. 그쪽에서는 오히려 책임질 수 있는 사람의 가치가 더 올라가고 있습니다.

20년 가까이 비슷한 말을 해왔습니다

이 얘기를 저는 꽤 오래 해왔습니다.

그때는 AI가 아니었습니다. 클라우드였고 프레임워크였고 오픈소스였고 자동화였습니다. 매번 패턴은 비슷했습니다. 새로운 기술이 나오면 "이걸로 다 해결된다"는 공기가 먼저 돌고, "개발자가 할 일이 줄어든다"는 불안이 뒤따릅니다. 몇 년 지나면 실제로 어떤 공정은 흡수됩니다. 그런데 "개발자가 없어진다"는 예측은 매번 빗나갑니다.

사라진 건 특정 구현 작업이었고, 남은 건 그 기술을 쓰는 판단과 그 결과를 감당하는 책임이었습니다.

그래서 늘 같은 말을 했습니다. 사라질 걸 붙잡지 말고 안 사라질 걸 쌓아라.

안 사라지는 게 뭔가 하면 결국 이런 쪽입니다. 문제가 뭔지 정의할 수 있는 능력. 여러 후보 중 우리 상황에 맞는 걸 고를 수 있는 판단력. 결과가 왜 맞고 왜 틀린지 설명할 수 있는 이해도. 판단이 틀렸을 때 고쳐낼 수 있는 대응력.

이건 언어가 바뀌어도 남고 프레임워크가 바뀌어도 남고 AI가 코드를 많이 쓰기 시작해도 남습니다. 오히려 구현이 쉬워질수록 이 네 가지의 값이 올라갑니다. 구현이 쉬워질수록 "뭘 구현할 것인가"와 "그 구현이 우리한테 맞는가"를 정하는 사람이 더 희귀해지기 때문입니다.

물론 이 논리에 약한 데가 있다는 것도 압니다. 지난 스무 해 동안 매번 빗나갔으니 이번에도 빗나갈 거라는 말은 그 자체로는 근거가 못 됩니다. 매번 안 왔다는 사실이 앞으로도 안 온다는 보장을 해주지는 않습니다.

그래서 이번이 다른 점이 뭔지도 짚어보려고 했습니다. 예전 기술들은 특정 공정을 대체했는데 AI는 범위가 넓습니다. 클라우드는 서버 구축을 가져갔고 프레임워크는 반복 코드를 가져갔지만, 둘 다 "무엇을 만들지 정하는" 쪽은 건드리지 않았습니다. AI는 그쪽에도 후보안을 냅니다. 여기까지는 확실히 다릅니다.

그런데 후보안을 내는 것과 그중 하나를 골라서 책임지는 것 사이의 거리는 여전히 남아 있습니다. 제가 이번에도 비슷하게 갈 거라고 보는 근거는 모델 능력이 아니라 그 거리입니다. 그 거리가 좁혀지는 게 보이면 판단을 바꿀 생각입니다. 지금은 아직 안 보입니다.

그런데 그 판단력은 어디서 길러지나요

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

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

이건 저도 아직 답을 못 찾았습니다.

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

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

이건 진짜 위험하고, 이미 조금씩 보이는 것 같기도 합니다. AI가 써준 코드를 이해하지 못한 채 PR을 올리는 주니어, 리팩토링 결과를 깊게 읽지 않고 그냥 머지하는 팀. 지금은 그게 낯설지 않습니다.

문제는 그 결과가 당장 티가 잘 안 난다는 점입니다. 코드는 돌아가고 테스트는 통과합니다. 진짜 문제는 6개월 뒤에 옵니다. 그 코드를 처음 낸 AI도, 머지한 사람도, 그때 왜 그렇게 했는지 기억하지 못합니다. 버그가 터지면 아무도 구조를 해석하지 못합니다. 해석을 못 하니까 고치지 못합니다. 결국 "이 모듈은 너무 복잡하니까 다시 짜자"는 이름으로 같은 루프가 반복됩니다.

그런데 이 걱정에도 균형을 좀 맞춰야 할 것 같습니다. 구현 고통이 판단력의 유일한 경로였는지는 다시 생각해볼 만합니다. 제가 만나본 사람 중에 판단이 제일 빠른 쪽은 제일 많이 구현한 사람이 아니었습니다. 남이 터뜨린 사고를 유심히 본 사람, 회고 문서를 실제로 읽는 사람, 자기 결정이 틀렸을 때 그걸 덮지 않고 적어둔 사람이었습니다. 그러니까 필요한 건 고통 자체가 아니라 결과를 끝까지 따라가 보는 습관일 수도 있습니다.

이게 맞다면 AI가 구현을 가져가는 것이 판단력 형성을 반드시 막는 건 아닙니다. 다만 따라가 보지 않아도 되는 환경이 훨씬 쉬워지는 건 맞습니다. 예전에는 코드가 안 돌아가면 억지로라도 끝까지 봐야 했는데, 지금은 안 돌아가면 다시 물어보면 됩니다. 결과를 끝까지 따라가는 일이 강제에서 선택으로 바뀐 셈이고, 선택으로 바뀐 일은 대부분 안 하게 됩니다.

그래서 앞으로의 성장 경로는 꽤 다르게 생길 것 같습니다. 예전에는 많이 구현해본 사람이 깊어졌습니다. 앞으로는 많이 판단해보고 많이 검증 실패를 겪어본 사람이 깊어질 가능성이 큽니다. 가장 귀한 학습 자산도 코드 그 자체보다 실패 로그, 의사결정 기록, 반례 모음 쪽으로 옮겨갈 수 있습니다.

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

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

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

셋째는 반례 모음입니다. 이 규칙이 왜 있는지, 깨지면 무슨 일이 벌어지는지를 구체적 사례로 남겨둡니다. 규칙만 주면 AI는 언젠가 다시 어깁니다. 그런데 반례까지 붙어 있으면 멈칫합니다. 이유를 이해해서라기보다, 최소한 위험 신호를 더 강하게 인식하는 것 같습니다.

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

불안의 방향을 바꾸는 게 먼저입니다

학생이든 주니어든 AI 때문에 불안해하는 걸 탓할 생각은 없습니다. 저라도 지금 같은 시기에 커리어를 시작했으면 비슷하게 흔들렸을 것 같습니다. 변화 속도가 빠르다는 체감은 진짜입니다. 주니어 사다리가 실제로 얇아지고 있다는 얘기도 근거 없는 걱정은 아닙니다.

그런데 그 불안을 어디에 걸어두느냐가 중요합니다.

"AI가 내 자리를 뺏는 거 아닌가"로만 불안해하면 대응 방법이 별로 없습니다. 그건 내 바깥의 변화만 바라보게 만듭니다.

반대로 "AI 시대에 결과를 감당할 수 있는 개발자가 되려면 지금 뭘 쌓아야 하지?"라고 묻기 시작하면 대응 방법이 많아집니다. 문제 정의, 설계, 실패 해석, 의사결정 근거 기록, 설명 능력. 할 일이 갑자기 구체적으로 보입니다.

두 질문은 비슷해 보이는데 결과가 완전히 다릅니다. 첫 번째 질문에 갇히면 트렌드만 따라다니게 됩니다. 두 번째 질문을 쥐면 판단 근육을 기르게 됩니다. 몇 년 지나면 격차가 꽤 크게 벌어집니다.

앤트로픽 소스맵 노출 같은 사건은 앞으로도 반복될 겁니다. AI가 코드의 더 많은 부분을 쓰게 될수록 사고 원인이 사람인지 AI인지 헷갈리는 순간도 더 많아질 겁니다. 그때마다 똑같은 질문이 나옵니다. 그래서 누가 책임지는데.

그리고 그 질문의 답은 한동안, 아마 꽤 오래, 사람으로 끝날 가능성이 높습니다. 로봇이 자동차를 만들어도 사고가 나면 제조사가 책임지듯, 에이전트가 코드를 써도 장애가 나면 그걸 배포한 팀이 책임집니다.

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

확인한 자료

• Anthropic accidentally exposes Claude Code source code — 2026년 3월 31일 소스맵 노출 경위와 원인. 2026년 9월 11일 확인.