리더가 정말 신경 써야 할 것은 생산성이 아니다

이번에 신혼여행으로 인해 간만에 일에서 한 발 물러나 며칠을 보내다 보니, 평소 업무에 파묻혀 좀처럼 꺼내보지 못하던 질문 하나를 오래 들여다보게 됐다.

필자는 그동안 AI 시대의 개발자를 두고 여러 편의 글을 써왔다. 그런데 뉴질랜드의 한적한 풍경 속에서 그 글들을 되짚어보니 공통점이 하나 보였다. 전부 개발자 개인으로서의 고민이었다는 점이다. 나 하나가 어떻게 AI에 마취되지 않을 것인가, 나 하나가 어떻게 역량을 지킬 것인가처럼 말이다.

하지만 정작 그런 개인들이 모여 있는 조직에는 어떤 변화가 일어날 것이며, 그 조직을 이끄는 리더는 또 어떻게 변해야 하는가는 한 번도 제대로 생각해보지 않았다.

그래서 이번 포스팅에서는 그 빈자리를 들여다보려 한다. AI를 잘 활용하면 유능한 개발자가 될 거라는 믿음이 왜 착각에 가까운지, 그 착각이 한 사람을 넘어 조직 단위로 번질 때 무슨 일이 벌어지는지, 그리고 그 앞에서 리더는 무엇을 신경 써야 하는지에 대한 이야기다.

AI에 기댈수록 출력을 검증하는 역량은 점점 옅어진다

필자는 최근 세 편의 글을 통해 AI 시대에 개발자들이 어떤 스탠스를 취해야하는지, 어떤 역량을 목표로 해야하는지에 대해서 적은 바가 있다. 이 글들을 보면 필자의 생각이 어떤 식으로 변화되어왔는지를 알 수 있다.

각 글에서 이 문제를 무엇의 문제로 봤는지 정리하면 이렇다.

포스팅	문제	결론
지금 프로그래밍을 하고 있는 당신은 누구인가	의지의 문제	정신만 똑바로 차리면 도구는 도구로 남는다
물이 빠지면 누가 발가벗고 수영했는지 드러난다	자리의 문제	작성자에서 의사결정권자로 올라서면 된다
더이상 성장하지 않는 개발자들	구조의 문제	AI를 쓰면서도 의도적으로 뇌에 부하를 거는 구조를 설계해야 한다

세 편이 가리키는 곳은 결국 하나다. AI를 잘 다루는 능력과 그 출력을 검증하는 능력은 같은 것이 아니며, 도구에 기댈수록 후자는 조용히 약해진다. 마치 마취 당하는 것처럼 아프지도 않게 말이다. 그래서 그 능력은 정신을 차린다고 지켜지지도, 서는 자리를 옮긴다고 지켜지지도 않고, 결국 의식적인 구조로만 지킬 수 있다.

그런데 이 셋에는 공통의 테두리가 있었다. 전부 “나 한 사람을 어떻게 지킬 것이냐”의 이야기, 결국 필자 혼자 하는 일이었다는 점이다. 그러나 사람을 뽑고 팀의 방향과 머지 기준을 세우는 자리에서 보면, 이 마취는 한 사람의 판단력이 무뎌지는 데서 끝나지 않는다. 한 사람이 아니라 조직이 함께 마취될 때, 그 조직을 이끄는 사람은 무엇을 해야 하는걸까?

답을 향해 가기 전에, 우선 이 마취가 왜 개인의 의지로는 막아지지 않는지부터 짚어야겠다. 그게 한 사람의 문제가 아니라 도구의 성질에서 오는 것이기 때문이다.

AI는 추상화가 아니라 대리인이다

AI를 잘 활용하면 유능해진다는 믿음의 바탕에는 하나의 등식이 깔려 있다. AI를 잘 활용하는 능력이 곧 개발자의 역량이라는 등식이다. 활용을 잘하니 더 많이 만들고, 더 많이 만드니 더 유능하다는 흐름이다.

이 등식은 역사적으로 꽤 든든한 근거를 가지고 있다. 우리는 브라우저가 화면을 어떻게 다시 그리는지 일일이 따지지 않아도 React로 선언형 UI를 잘 다루면 유능한 개발자라고 불렀고, SQL을 직접 한 줄도 쓰지 않아도 ORM으로 데이터를 잘 다루면 좋은 개발자라고 인정했다.

이처럼 저수준의 노동을 한 겹씩 도구에게 넘기고 사람은 더 높은 곳에서 설계와 조립에 집중하는 것, 이게 지금까지 개발이라는 직업이 진화해온 방식이었다. 그러니 AI에게 구현을 넘기고 우리는 더 위에서 판단만 하면 된다는 주장은 언뜻 보면 이 진화의 다음 장처럼 보인다.

이번 추상화에는 내려갈 사다리가 없다

문제는 AI가 그 앞선 추상화들과 결이 꽤 다르다는 것이다. 지금까지의 도구들은 결정론적이었다. 원리가 명확하고 같은 입력에는 같은 출력을 내도록 되어있어 무언가 잘못됐을 때 왜 그렇게 됐는지를 따라 내려갈 사다리가 늘 거기 있었다. 평소엔 그 아래를 안 보고 살아도 필요하면 언제든 내려가서 인과를 직접 확인할 수 있었다. 여기서의 핵심은 그 사다리를 매일 타느냐가 아니라, 필요할 때 타고 내려갈 수 있느냐다.

하지만 생성형 AI는 확률적이다. 같은 요청에도 매번 다른 코드가 나오고, 그 코드가 왜 그렇게 나왔는지를 따라 내려갈 사다리가 애초에 없다. 심지어 그 생성형 AI 모델을 만든 사람들도 왜 AI가 이런 출력을 내는지 명확하게 설명을 하지 못하니 말 다했다.

여기서 오해 하나는 짚고 가자. 생성된 코드 자체를 못 읽는다는 뜻이 아니다. AI가 뱉어낸 코드는 ORM이 만들어준 SQL을 들여다보듯, 그 자체로는 얼마든지 읽을 수 있다. 사다리가 없다는 건 산출물을 못 읽는다는 게 아니라, 그 코드가 “왜 그렇게 짜였는지”로 내려갈 사다리가 없다는 뜻이다. 결정론적 도구 아래에는 따라 내려갈 인과의 규칙이라도 있었지만, 확률적 대리인이 내놓은 결과에는 사람이 되짚어 내려갈 길이 없다. AI 안에 어떤 과정이 있었든, 그게 사람의 머리를 한 번도 통과하지 않았기 때문이다.

그리고 더 결정적인 차이가 하나 있다. 앞선 추상화들은 우리를 한 층 위로 올려보냈다. 직접 DOM을 만지던 일을 React에 넘긴 대신 우리는 컴포넌트 설계라는 더 높은 층의 인과를 새로 손에 쥐었다. 그런데 AI는 우리를 위층으로 올려보내지 않는다. 우리가 서 있던 바로 그 층에 대신 들어앉는다. 추상화가 사다리를 한 칸 올라서는 일이었다면, AI는 그 자리에 대리인을 앉히는 일이다. 그래서 위로 올라가 새로 쥘 인과도 없이, 원래 쥐고 있던 인과만 슬그머니 빠져나간다. 이게 필자가 AI를 추상화가 아니라 대리인이라 부르는 이유다.

그러니까 AI를 잘 활용한다는 말의 실체는 결정론적인 규칙을 익혀 결과를 통제한다는 게 아니라, AI가 쏟아낸 수많은 확률적 결과 중에서 가장 괜찮은 하나를 골라낸다는 것에 더 가까운 것이다. (즉, 아무리 하네스를 잘 쳐도 기본적으로는 운빨 게임이다)

인과의 소유권을 누가 쥐고 있는가

여기서 활용이 역량을 쌓아주는 경우와 갉아먹는 경우의 경계가 드러난다. 그 경계는 인과관계의 소유권을 누가 쥐고 있느냐다. 우리가 직접 짠 코드에는 왜 이렇게 짰는지에 대한 인과가 머릿속에 남는다. 이 분기를 왜 여기 뒀는지, 왜 이 자료구조를 골랐는지, 어떤 경우를 포기했는지가 자연스럽게 같이 따라온다. 반면 AI가 짠 코드에는 결과만 있고 그 결과에 이르기까지의 인과는 우리 머릿속을 거치지 않았다.

인과가 빠진 코드를 쌓아 올리는 건 모르는 언어로 쓰인 계약서에 매번 서명하는 일과 비슷하다. 당장은 아무 문제가 없으나 조항들이 서로 충돌하는 순간, 서명한 사람은 한 줄의 방어권도 갖지 못한다. 읽어서 이해하는 것과 처음부터 인과를 쥐고 있는 것은 위급할 때 전혀 다른 무기가 되기 때문이다. 시스템이 복잡해질수록, 그렇게 서명만 쌓아온 개발자는 AI 없이는 한 줄도 손대지 못하는 상태로 향한다.

여기까지는 사실 지난 글들에서 다룬 이야기다. 그리고 4월 글에서 봤듯, 이 마취는 개인의 의지로도 잘 막아지지 않는 구조의 문제다. 그런데 백번 양보해서 정신 똑바로 차린 한 사람이 의지로 버텨낸다고 치자. 진짜 문제는 이게 애초에 한 사람의 머릿속에서 끝나는 일이 아니라는 데 있다.

AI는 실력이 아니라 그럴싸함을 평준화한다

이 마취가 한 사람 선에서 멈추지 않는 데는 이유가 있다. 인과가 빠진 코드가 하필 겉보기에는 멀쩡하기 때문이다. 그래서 그런 코드는 누구의 제지도 받지 못한 채 조직 안에 슬그머니 쌓여간다. 그리고 그 양상은 멀리서 찾을 것도 없이, 매일 필자의 책상 위로 올라온다.

요즘 면접관으로, 또 매일 올라오는 PR을 들여다보는 리뷰어로서 AI가 작성한 정말 많은 코드를 보게 된다. 그러다보면 AI로 인해 개발자들의 실력이 그럴싸하게 평준화되고 있다는 생각이 든다.

예를 들어 코드의 겉보기 완성도를 1부터 10이라고 본다면, 예전에는 1짜리 코드도 있었고 10짜리 코드도 있었다. 그러나 요즘에는 1~4는 좀처럼 안 보이고 최저점이 5정도로 평준화된 느낌이랄까. 여기서 평준화되는 건 개발자의 역량이 아니라 산출물의 겉보기 수준이라는 점이 중요하다.

즉, AI가 끌어올린 건 실력이 아니라 “그럴싸함”의 바닥이다. 그리고 이 구분이 중요한 건, AI가 더 좋아진다고 해서 이 문제가 풀리는 게 아니기 때문이다. 모델이 발전하면 그럴싸함의 바닥은 더 높아질 뿐이고, 산출물이 더 그럴듯해질수록 그 안에 인과가 비어 있다는 사실은 오히려 더 안 보이게 된다. 즉 AI의 품질은 이 글이 말하는 문제의 변수가 아니다. 좋아지면 좋아질수록 마취는 더 은밀해진다.

멀리서 보면 그럴듯한 코드들

실제로 매일 올라오는 PR만 자세히 들여다봐도 간혹 퀄리티가 별로인 것들이 눈에 보이는데, 그 코드들의 공통점은 하나같이 멀리서 보면 그럴듯해 보인다는 것이다.

변수명도 멀끔하고 구조도 그럴싸한데, 조금만 들춰보면 같은 책임을 가진 함수를 중복으로 작성하거나 책임 분리의 경계가 명확하지 않거나 사이드 이펙트 덩어리인 코드를 남발하곤 한다.

그런데 코드를 들춰보는 것보다 더 빠른 단서가 하나 있다. 그 코드를 짠 사람에게 직접 물어보는 것이다. 자기가 짰다는 코드인데도 “여기는 왜 이렇게 하셨어요?” 한마디에 답이 막히거나 별 관계없는 이야기를 늘어놓는 경우가 생각보다 많다. 변수명도 구조도 멀끔한데 정작 그 선택의 이유를 대지 못하는 것, 이게 바로 겉모습만 멀쩡하고 인과는 빠져 있는 코드의 가장 정직한 증거다. (면접관으로 들어가면 이런 장면을 정말 자주 마주친다)

진짜 문제는 이렇게 인과가 빠진 코드를 알아볼 수 있는 사람 자체가 많지 않다는 데 있다. 면접이든 리뷰든, 빈 인과를 짚어내려면 결국 보는 쪽에 그만한 눈이 있어야 하는데, 애초에 좋은 구조의 코드를 분간하고 만들어내는 능력은 AI 시대 이전에도 드문 것이었다. 게다가 이제는 몇 초 안에 코드를 작성할 수 있는 시대이니 점점 더 빠르게 이런 애매한 퀄리티의 코드가 늘어나고 있다.

이 관점에서 보면 매일 올라오는 그 허술한 PR들은 예외가 아니라 신호다. 그게 필자의 눈에 허술해 보이는 건, 아직 필자가 애매함과 좋은 퀄리티, 그 간격을 볼 수 있기 때문이다. 정말로 무서운 건 이런 퀄리티의 코드가 조직 내에서 대량으로 작성되어 올라오기 시작했을 때, 그리고 그 코드에서 문제를 읽어낼 수 있는 개발자가 점점 줄어들었을 때, 그 상황을 명확하게 컨트롤할 수 있는 방법이 아직 모호하다는 것이다.

필자는 이 현상을 “조직이 점점 AI에 마취되고 있는 것”으로 바라보고 있다.

마취는 개인이 아니라 조직 단위로 번진다

그렇다면 조직이 함께 마취되는 걸 막으려면, 리더는 무엇부터 봐야 할까? 그 출발점은 평소 우리가 뭉뚱그려 쓰던 두 가지를 떼어놓고 보는 데 있다.

여기서 필자가 제안하고 싶은 것은 생산성과 인지적 점유권의 구분이다. 생산성은 단위 시간당 만들어내는 코드의 양과 기능의 완성도이고, AI를 잘 쓸수록 이 값은 거의 폭발적으로 올라간다.

인지적 점유권은 조금 다른 이야기다. 지금 다루는 코드가 왜 그렇게 작성되어야만 했는지, 그 논리적 궤적을 처음부터 끝까지 따라가며 설명할 수 있는 상태를 말한다. 코드가 누구의 손을 거쳤느냐가 아니라, 그 코드의 인과가 누구의 머릿속에 있느냐의 문제다.

개인 차원에서 이 둘은 같이 가지 않는다. AI에게 더 많이 위임할수록 생산성은 오르지만, 그 코드에 대한 인지적 점유권은 점점 희석된다. 이제 이 희석을 조직 단위로 옮겨보면 그림이 훨씬 더 살벌해진다.

예전에는 한 줄의 코드에 최소 두 겹의 점유권이 걸려 있었다. 그걸 짠 작성자가 인과를 쥐고 그걸 리뷰한 사람이 한 번 더 인과를 쥐었다. 작성자가 회사를 떠나도 리뷰어의 머릿속에 인과의 사본이 한 부 남아 있었던 셈이다. 그래서 코드에 대한 인과와 맥락은 개인이 아니라 여러 머릿속에 분산되어 점유되고 있었다.

생성은 1초, 검증은 그대로다

그런데 AI 시대에 이 두 겹은 빠르게 얇아진다. 가장 근본적인 이유는 코드를 생성하는 비용과 검증하는 비용이 비대칭이기 때문이다. AI가 코드를 만들어내는 한계비용은 거의 0에 수렴한다. 프롬프트 한 줄만 넣어도 코드는 수십, 수백 줄이 쏟아진다. 반면 그 코드를 제대로 검증하는 비용은 조금도 줄어들지 않는다. 코드가 길어지고 맥락이 깊어질수록 검증에 드는 시간과 집중은 그대로 늘어난다.

여기에 조직의 속도 압력이 얹힌다. 팀의 생산성은 머지된 PR의 수와 배포 빈도로 측정되기 쉽지, 그 코드를 팀이 얼마나 이해하고 있느냐로는 측정되지 않는다.

그래서 1초 만에 나온 코드를 1시간 동안 붙들고 검증하는 사람은 조직의 지표 위에서 가장 느린 사람으로 보인다. 빠르게 만들어내는 쾌감 옆에서, 느리게 검증하는 노동은 점점 비합리적인 행동처럼 느껴진다. 비판적 수용은 의지력만으로 버틸 수 있는 게 아니라, 시간과 효율이라는 경제적 압력 아래에서 서서히 무너지는 종류의 것이다.

그래서 검토마저 AI에게 넘어간다

이 압력이 찾아낸 가장 매끄러운 출구가 바로 검토마저 AI에게 떠넘기는 것이다. 요즘 “AI가 리뷰까지 해주면 리뷰 병목도 사라지는 것 아니냐”는 질문을 부쩍 자주 받는데, 이 질문 자체가 이미 검증을 빨리 치워야 할 비용으로 본다는 신호다. 실제로 PR이 올라오면 AI 리뷰 봇이 알아서 요약과 지적을 달아주고, 사람은 그 요약을 훑고 “LGTM” 한 줄을 남기는 풍경이 점점 익숙해지고 있다.

그러나 AI가 달아주는 리뷰는 검증처럼 보일 뿐 실제 검증이 아니다. 그것 역시 인과가 빠진 또 하나의 그럴싸한 산출물일 뿐, 누가 옳고 그름을 책임지고 판단한 흔적은 아니기 때문이다. 리뷰를 AI에게 넘기는 건 검증의 병목을 푼 게 아니라, 검증이라는 단계를 통째로 건너뛴 것에 가깝다.

그렇게 작성도 AI, 검토도 AI가 되는 순간, 그 PR의 인과는 팀의 어느 머릿속에도 들어 있지 않다. 작성자도 인과를 쥔 적이 없고 승인자도 도장만 찍었다. 조직은 자기가 운영하는 시스템을 아무도 점유하지 못한 채로 굴리게 된다.

흔히 “내가 만든 코드는 내가 운영한다”는 원칙이 이런 사태를 막아준다고들 믿는다. 하지만 그게 점유를 보장하던 건 만드는 일이 곧 이해하는 일이던 시절의 이야기고, 작성을 AI가 대신하는 순간 그 고리는 끊긴다. 운영은 내가 하는데 정작 그 코드의 인과는 나에게 없는, 예전이라면 모순이었을 상태가 그냥 가능해지는 것이다. 검증하지 못하는 승인자, 그러니까 읽지 못하는 계약서에 직인을 찍는 사람이 한 명의 일탈이 아니라 조직의 기본 상태가 되는 것이다.

이 마취를 먼저 통과한 산업들

사실 이건 개발자가 처음 겪는 문제도 아니다. 항공 업계는 이 마취를 수십 년 먼저 통과했다. 리잔 베인브리지(Lisanne Bainbridge)는 1983년 자동화의 아이러니라는 논문에서, 자동화가 진행될수록 사람에게는 가장 어려운 예외 상황만 남는데 정작 그 예외를 감당할 기량은 자동화 때문에 퇴화한다고 지적했다. 2009년 에어프랑스 447편 사고의 조사 보고서가 짚은 원인 중 하나도, 자동조종이 풀린 순간 요구된 수동 조종을 승무원들이 감당하지 못했다는 것이었다. 한 사람이 아니라 조종석 전체가 동시에 무력해졌고, 평소에 자동화를 누구보다 잘 활용하던 사람들이었는데도 그랬다.

항공만의 이야기도 아니다. 길 찾기를 GPS에 넘긴 뒤로 우리 머릿속의 지도가 어떻게 됐는지를 떠올려보면 된다. 도시 전체의 길을 통째로 외워야 하는 시험을 통과한 런던의 택시 기사들은 공간 기억을 맡는 해마가 일반인보다 크다는 연구가 있다. 반대로 습관적으로 GPS에 의존해온 사람일수록 시간이 지나며 해마에 기대는 공간 기억이 더 가파르게 나빠진다는 후속 연구도 나왔다. 길을 직접 더듬어본 뇌는 자라고, 안내만 따라간 뇌는 줄어든다. 인과를 쥔 자와 결과만 받은 자의 차이가 뇌의 부피로까지 드러나는 셈이다.

의료 현장도 같은 함정을 안다. 미국에서 수십만 건의 디지털 유방 촬영 판독을 분석한 연구는, 병변을 짚어주는 컴퓨터 보조 진단(CAD)을 붙였을 때 판독 정확도가 어떤 지표로도 나아지지 않았고, 오히려 두 방식을 모두 써본 판독의들 사이에서는 CAD를 쓸 때 민감도가 더 낮았다고 보고했다. 도구가 짚어준 것에 눈이 길드는 동안, 도구가 놓친 것을 사람도 함께 놓치게 되는 것이다. 검증을 도구에 넘길 때 치르는 대가가 바로 이것이다.

여기에 시간차의 잔인함이 겹친다. AI가 짜둔 코드의 결함이 6개월 뒤에 장애로 터졌다고 해보자. 그 6개월 동안 팀의 점유권이 충분히 무뎌졌다면, 정작 문제가 터진 순간엔 그걸 수습할 능력이 조직 어디에도 남아 있지 않을 수 있다. 결함이 자라는 속도보다 그걸 감당할 능력이 더 빨리 줄어드는 셈이다.

취향은 고장 속에서만 자란다

마취가 유독 무서운 건 그것이 고통이 아니라 편안함의 얼굴로 찾아오기 때문이다. 그렇다면 그 편안함이 정확히 무엇을 마취시키는지, 한 번 더 들여다볼 필요가 있다. 요즘 AI 시대의 개발자를 두고 “이제 중요한 건 취향(taste)“이라는 글을 읽은 적이 있다. 구현은 AI에게 맡기고 사람은 무엇이 좋은지를 알아보는 안목만 쥐면 된다는 것이다. 절반은 맞는 말이다. 확률적으로 쏟아지는 결과 더미에서 가장 나은 하나를 골라내는 일에서, 그 안목은 점점 더 결정적인 변수가 되고 있다. 앞에서 필자가 인지적 점유권이라 부른 것도 결국 이 안목의 다른 이름이다.

문제는 그 취향이 대체 어디서 오느냐다. 취향 경제를 말하는 사람들은 대개 안목을 타고난 감각이거나, 좋은 결과물을 많이 구경하면 길러지는 것쯤으로 여긴다. 그러나 무엇이 좋은 코드인지를 분간하는 눈은 좋은 코드를 많이 읽어서 생기지 않는다. 그건 우리가 짠 것이 깨지고, 그 깨진 자리에서 멈춰 서서 왜 깨졌는지를 손으로 더듬고, 다음엔 그렇게 짜지 않게 되는 과정이 수없이 몸에 새겨진 결과다.

하이데거가 망치를 예로 든 유명한 이야기가 있다. 손에 익은 망치는 매끄럽게 쓰이는 동안에는 망치라는 사실조차 잊힌 채 손에서 사라져 있다가, 머리가 빠져 못이 헛도는 순간에야 비로소 하나의 대상으로 눈앞에 떠오른다는 것이다. 우리가 도구의 본질과 그 아래 깔린 인과와 정면으로 마주하는 건 역설적으로 그것이 고장 났을 때다. 이 이야기는 코드 앞에서도 그대로 들어맞는다. 컴파일이 깨지고 원인을 몰라 한참을 막혀 있던 그런 순간들이야말로 무엇이 좋고 나쁜지에 대한 감각이 만들어지던 자리이자 일종의 대장간이었던 것이다.

그래서 취향은 명제로 전수되지 않는다. “사이드 이펙트를 줄여라” 같은 규칙을 몇백 개 외운다고 좋은 설계를 알아보는 눈이 저절로 생기지는 않는다. 그 눈은 규칙의 목록이 아니라 무수한 개별 사례에서 직접 데어보고 길들여진 종류의 앎에 더 가깝다.

아리스토텔레스가 책으로 배우는 지식과 따로 떼어 “실천적 지혜”라 불렀던 게 딱 이런 것이다. 그건 오직 반복된 실천이 습관으로 몸에 밴 자리에서만 자란다. 그러니 구현을 한 번도 거치지 않은 취향이라는 건, 한 번도 걸어본 적 없는 길의 목적지를 안다고 말하는 것과 비슷하다. 형용모순까지는 아니어도, 적어도 자기가 무엇을 모르는지조차 모르는 취향이다.

그리고 바로 여기에 AI의 조용한 함정이 있다. AI는 고장을 없애주는 게 아니라 고장을 겪는 경험을 없애준다. 막히는 자리를 알아서 메워주고 깨진 자리를 미처 들여다보기도 전에 봉합해준다.

편의의 얼굴을 하고 있지만, 그렇게 매끄럽게 메워진 매 순간이 사실은 취향이 자랄 수 있었던 대장간 하나가 닫히는 순간이다. 마취의 진짜 함정은 아픔을 지우는 데 있지 않다. 아픔과 함께, 그 아픔을 통해서만 자라던 것까지 같이 지운다는 데 있다. 그래서 취향 경제라는 말에는 늘 한 가지가 빠져 있다. 모두가 안목만 쥐고 아무도 바닥에서 깨지지 않는 세계에서, 정작 그 안목은 어디서 새로 자라느냐는 물음이다.

도제가 끊긴 자리에서 사람을 뽑는다는 것

리더의 입장에서 이 마취가 가장 곤란하게 작동하는 지점은 새로운 인재의 채용과 육성이다.

앞 절에서 말한 그 대장간을 우리는 오랫동안 도제라고 불러왔다. 좋은 판단력을 갖춘 시니어는 어느 날 갑자기 하늘에서 떨어지는 게 아니라, 콤마 찍는 정규식을 백지에서 짜보며 헤매고 한밤중에 인과를 더듬어 장애를 잡아본 주니어가 시간이 지나 그 자리에 서는 것이다. 검증의 고통을 치르는 그 시간이 곧 도제의 본체였다.

AI가 도제를 건너뛰게 할 때

문제는 AI가 이 도제의 경로를 통째로 건너뛰게 해준다는 데 있다. 신입 시절부터 AI가 옆에 있던 개발자에게 검증을 생략하는 건 어느 순간의 타협이 아니라 처음부터 주어진 기본값이다. 그리고 산출물만 놓고 보면, 그렇게 도제를 건너뛴 주니어도 AI를 붙여 그럴듯한 코드를 충분히 빠르게 뽑아낸다. 앞에서 말했듯 AI가 평준화하는 건 실력이 아니라 그럴듯함이니, 적어도 겉으로 드러나는 생산성에서는 차이가 잘 보이지 않는다.

여기서 리더는 꽤 고약한 유혹 앞에 선다. 어차피 산출물이 비슷하다면 굳이 비효율을 감수하며 주니어가 바닥을 더듬게 둘 이유가 있는가. AI를 붙여 빠르게 결과를 내게 하는 편이 분기 지표에는 훨씬 유리하다.

그러나 그 선택이 한 분기, 두 분기 쌓이면, 코드를 분간할 수 있는 사람의 공급 자체가 마른다. 구현 점유권의 죽음은 당장 표가 나지 않다가 한 세대쯤 시차를 두고 판단 점유권의 고갈로 돌아오고, 그때쯤이면 그 고갈을 알아챌 사람조차 남아 있지 않을 수 있다.

이 고갈이 치명적인 건, 개발자의 값을 끝내 결정하는 게 무엇이 옳고 무엇을 만들 가치가 있는지를 아는 판단이기 때문이다. 그리고 그 판단은, 앞 절에서 봤듯 구현의 바닥을 직접 더듬어본 자리에서만 자란다.

여기서 한 가지 반론이 가능하다. 구현을 통째로 AI에게 맡기더라도 그 과정에서 인간이 설계 결정에 깊이 개입한다면, 판단력은 그 위에서도 자라지 않겠느냐는 것이다. 맞는 말이고, 사실 그게 뒤에서 말할 처방의 핵심이기도 하다.

다만 그 개입은 저절로 일어나지 않는다. 버튼 한 번에 그럴싸한 결과가 나오는데 굳이 멈춰 서서 “왜 하필 이 설계인가”를 스스로 묻는 건, 앞에서 본 경제적 압력을 정면으로 거스르는 일이기 때문이다. 그래서 구현은 맡기되 결정의 인과만큼은 사람이 쥐는 공동 설계는, 가만히 두면 일어나는 기본값이 아니라 의식적으로 설계해 넣어야 하는 예외다. 개입이 빠진 위임이 기본값으로 굳는 순간, 판단의 인과가 자랄 토양은 사라진다.

단기 생산성과 장기 역량 공급 사이에서 선택해야 하는 자리, 그게 리더의 자리다. 그리고 이 선택은 개인 개발자가 의지로 풀 수 있는 게 아니라, 조직이 의도적으로 비용을 떠안기로 결정해야만 풀리는 종류의 것이다.

기본기 타령으로 끝낼 문제가 아니다

이걸 개개인의 기본기가 부족한 탓으로 돌리는 한탄으로 끝내고 싶지는 않다. 그건 어셈블리를 안 배운 세대를 향한 옛날의 한탄과 크게 다르지 않고, 필자 역시 그 한탄의 수혜자다. 도구가 한 겹씩 올라설 때마다 기준선은 늘 옮겨갔고, 옮겨간 기준선 위에서도 좋은 개발자는 언제나 나왔다.

다만 앞서 언급했듯 이번에는 다르다. 앞선 추상화들은 인과를 숨겼을 뿐 없애지는 않았기 때문에 필요하면 언제든 다시 사다리를 타고 내려가 그 인과를 직접 확인할 수 있었다.

그러나 AI라는 확률적인 대리인 위에서는 그 사다리가 저절로 깔리지 않는다. 바닥까지 내려가 인과를 직접 만져볼 길이, 가만히 두면 아예 생기지 않는 것이다. 그래서 이건 누가 더 게으르거나 자질이 부족하냐의 문제가 아니다. 이제 역량이 자라느냐 마느냐는 점점 개인의 의지가 아니라 그가 놓인 구조가 결정한다. 그리고 AI가 걷어가 버린 그 사다리를 팀 안에 인위적으로라도 다시 놓아줄지 말지를 정할 수 있는 자리에 있는 사람이 바로 리더다.

처방은 개인의 결심이 아니라 팀의 구조여야 한다

문제는 점유권을 지키는 일이 결심만으로는 되지 않는다는 점이다. 앞에서 봤듯 검증을 생략하게 만드는 건 의지가 아니라 경제적 압력이다. 그러니 처방도 마음가짐만 다져서는 안 되고, 쉽게 빠져나갈 수 없는 행동의 구조로 박아둬야 버틴다. 그리고 조직 단위에서 그 구조를 세울 수 있는 사람은 개별 개발자가 아니라 리더다.

점유권의 비효율은 보험료다

다만 구조를 세우기 전에 정직하게 짚을 게 있다. 점유권을 지키는 일은 분명한 비효율이다. 1초면 나올 코드를 굳이 사람이 붙들고 있는 것이니, 단기 지표 위에서는 거의 언제나 손해로 보인다. 그러니 “그래도 옳으니 감수하자”는 식의 호소만으로는, 이 비효율이 경제적 압력 앞에서 오래 버티지 못한다.

그래서 이 비용은 도덕이 아니라 회계의 언어로 정당화되어야 한다. 점유권에 들이는 비효율은 손실이 아니라 보험료다.

앞서 본 시간차를 떠올려보자. AI가 심어둔 결함은 지금 청구서를 내밀지 않고, 몇 달 뒤 장애가 되어 한꺼번에, 그것도 그걸 수습할 능력이 조직에서 가장 많이 빠져나간 시점에 돌아온다. 장애 한 번의 비용은 평소 검증에 들인 시간을 다 합한 것보다 크기 쉽다.

빠르게 머지한 PR의 속도는 분기 지표에 또렷이 잡히지만, 그렇게 아낀 시간이 나중에 몇 배의 장애 비용으로 불어나는 흐름은 어떤 지표에도 잡히지 않는다. 리더가 할 일은 그 보이지 않는 청구서를 미리 장부에 적어두는 것이다. 점유권의 비효율을 사치가 아니라 지불해야 할 보험료로 회계 처리하지 않으면, 아래의 구조들은 속도 경쟁 앞에서 가장 먼저 잘려나가는 비용 항목이 될 뿐이다.

여기서 누군가는 이렇게 받아칠 수 있다. 시장은 결국 속도로 굴러가는 곳인데, 마취된 채로라도 빠르게 내놓는 조직이 이긴다면 점유권 따위는 한가한 사치 아니냐고. 일리 있는 말이지만 두 가지를 빼먹은 반론이다.

첫째, 그 “이긴다”는 대개 분기 지표 위에서의 승리다. 앞서 본 장애 비용은 그 지표에 잡히지 않은 채 뒤에 쌓이고 있을 뿐, 청구서가 도착하기 전까지만 이긴 것처럼 보인다.

둘째, 속도가 해자가 되는 건 모델이 귀할 때뿐이다. 같은 AI를 누구나 쥐는 순간 생성 속도는 평준화되고, 남는 차이는 그 출력을 분간하고 검증하는 힘으로 옮겨간다. 그러니 점유권은 시장을 거스르는 향수가 아니라, 속도가 흔해진 다음에 시장이 값을 매기기 시작할 바로 그 능력이다. 마취를 늦추는 일은 효율을 포기하는 게 아니라, 모두가 빨라진 세계에서 끝까지 분간할 수 있는 소수로 남는 일에 가깝다.

그 위에서 필자가 붙들고 있는 건 당장 도입할 규칙 목록이라기보다 몇 가지 방향에 가깝다. 같은 방향이라도 팀마다 그 모습은 꽤 다르게 구현될 것이다.

검증의 최종 책임은 사람이 쥔다

앞에서 봤듯 검토를 AI에게 통째로 넘기는 건 편의가 아니라, 조직이 인지적 점유권을 집단으로 내려놓는 행위에 가깝다. 그러니 첫 번째 방향은 검증의 책임을 개인의 의지가 아니라 팀의 구조 위에 얹되, 그 책임의 끝만큼은 반드시 사람에게 묶어두는 것이다. 밤 11시 야근의 압박 앞에서 가장 먼저 무너지는 건 개인의 결심이라, 빠져나가기 어려운 절차 곳곳에 검증을 깜빡할 수 없게 만드는 마찰을 박아둬야 버틴다.

예컨대 인과를 설명하지 못하는 코드는 머지하지 않는다는 걸 리뷰 규칙으로 박아두고, PR 설명란에 “왜 이렇게 짰는지”를 사람이 자기 언어로 적게 한다. 리뷰어나 리더가 가끔 무작위로 PR을 짚어 “이 분기는 왜 이렇게 두셨어요”라고 구두로 묻는 인위적인 압력을 만들어두는 것도 한 방법이다. “LGTM” 한 줄도 통과 도장이 아니라 “이 코드를 내가 설명할 수 있다”는 인수 선언으로 그 의미를 바꿔두면 좋다.

다만 이 방향에는 한계가 분명하다. 사후에 읽어서 설명하는 건 처음부터 인과를 쥔 것보다 약한 무기고, 그럴싸한 코드를 1초 만에 뽑는 AI는 그럴싸한 “왜”도 1초 만에 적어준다. 그래서 글로 적게 하는 데서 멈추면 AI가 쓴 코드 위에 AI가 쓴 변명만 한 겹 더 얹힌다. 이 방향의 진짜 목적은 점유권을 길러내는 것보다, 설명조차 못 하는 코드가 그대로 흘러가는 최악을 막고 그 위조가 들통나는 순간을 만들어두는 데 있다. 글로는 매끄럽던 설명이 꼬리 질문 앞에서 막히는 그 순간 말이다. 텍스트는 위조해도 그 막힘은 위조하기 어렵고, 그걸 알아채는 눈이 뒤에서 말할 리더의 감별력이다.

설계는 사람이 쥐고, AI에게 넘기는 법을 가르친다

검증이 사후에 드리우는 그물이라면, 설계는 사전에 인과를 쥐는 일이다. 구현은 AI에게 맡기더라도 무엇을 왜 만드는지에 대한 설계 결정만큼은 사람이 먼저 쥐고 간다. 앞서 공동 설계가 가만히 두면 일어나지 않는 예외라고 했는데, 이 방향이 바로 그 예외를 기본값으로 끌어올리려는 시도다.

구체적으로는 AI에게 맡기기 전에 사람이 먼저 설계안을 세우고, 그 설계를 제약과 엣지 케이스까지 명세로 정확히 옮겨 전달하고, 돌아온 결과물을 다시 그 설계 기준으로 검증하는 흐름이다.

그리고 이 “설계를 쥐고 AI에게 정확히 넘기는” 일을 개인의 감각에 맡겨두지 말고, 팀이 함께 연구하고 가르쳐야 할 역량으로 다뤄야 한다. 프롬프트를 잘 치는 기술이 아니라 자기 머릿속 설계를 빠짐없이 밖으로 꺼내놓는 기술이다.

포기하지 않을 거점을 고른다

모든 영역에서 점유권을 유지하는 건 불가능하다. 그러니 다 쥐려 하기보다, 절대 놓지 않을 거점 몇 곳을 의도적으로 정해두는 쪽이 현실적이다. 팀의 중심이 되는 코어 도메인이 그 거점일 수도 있고, 장애가 터졌을 때 결국 사람이 직접 손대야 하는 영역일 수도 있고, 바깥에 설명할 책임이 가장 무거운 영역일 수도 있다.

그렇게 고른 거점에서만큼은 빠르게 뽑는 것보다 천천히 이해하는 것을 더 높이 산다. 거점이 있는 팀과 없는 팀은 낯선 영역을 검증하는 힘부터 다른데, 무엇이 좋은 코드인지에 대한 감각은 결국 어딘가에서 바닥을 본 경험에서 출발하기 때문이다.

비효율을 학습 경로로 만든다

점유권을 기르는 비효율은 분기 지표에 쫓기는 개인이 자발적으로 택하기 어렵다. 그래서 이건 조직이 비용으로 떠안기로 결정해야만 생기는 경험이다.

작은 영역 하나를 골라 AI 없이 바닥까지 내려가보게 하거나, 자기가 짠 코드가 깨졌을 때 답을 바로 떠먹여주는 대신 그 인과를 직접 더듬게 두거나, 앞서 정한 코어 도메인에 주니어를 일부러 붙여 거기서만큼은 속도를 포기하게 하는 식이다.

정기적으로 AI를 꺼두는 “도구 없는 시간”을 의례처럼 박아두는 것도 방법이다. 근육에 일부러 부하를 주듯, 가끔은 손과 머리로만 문제를 끝까지 밀고 가보게 하는 것이다. 점유권이 무엇인지 몸으로 아는 사람만이 그걸 지킬지 말지를 선택할 수 있고, 그런 사람은 개인의 의지가 아니라 팀의 설계로만 길러진다.

속도뿐 아니라 점유권도 측정한다

여기까지가 절차와 사람에 관한 이야기였다면, 마지막은 지표에 관한 것이다. 이 글이 짚은 문제의 뿌리는 결국 조직이 속도만 측정하기 때문에 검증이 비합리적으로 보인다는 데 있었다. 그렇다면 가장 근본적인 처방은 측정하는 대상 자체를 바꾸는 것이다. 머지된 PR 수와 배포 빈도 옆에, 팀이 자기 코드를 얼마나 점유하고 있는지를 보여주는 계기판을 나란히 두는 것이다.

설명하지 못하는 코드의 비율이나, 무작위 스팟 체크에서 설명이 막히는 빈도 같은 것이 그런 계기판이 될 수 있다. 장애를 수습하는 데 걸리는 시간도 하나의 신호다. 점유권이 빠진 조직일수록 막상 문제가 터졌을 때 원인을 더듬는 데 오래 걸리기 때문이다. 다만 이 값은 장애마다 난이도가 달라 들쭉날쭉하니, 절대치를 KPI로 박기보다 추세로 읽고, 포스트모템에서 “이번 수습이 더뎠던 게 문제가 어려워서였는지, 아무도 그 코드의 인과를 쥐고 있지 않아서였는지”를 갈라 묻는 편이 낫다. 후자가 반복된다면 그게 곧 조직이 마취되고 있다는 신호다.

물론 조심할 게 있다. 어떤 지표든 평가의 목표로 못 박는 순간 사람들은 그 지표가 가리키던 진짜 목표 대신 숫자 자체를 좇기 시작한다(굿하트의 법칙). 설명 가능 비율을 KPI로 걸면 진짜 이해 대신 그럴싸한 설명만 양산되는, 앞에서 본 그 가짜 증명이 지표 위에서 똑같이 반복되는 식이다. 그러니 점유권 지표도 최적화할 KPI가 아니라, 조직이 무뎌지고 있는지를 가끔 들여다보는 계기판으로만 두는 게 안전하다.

그런 점에서 채용과 평가의 기준에서 “AI로 얼마나 빨리 만들어내는가”보다 “자기가 내놓은 것의 인과를 설명할 수 있는가”를 보겠다고 정하는 것 하나가, 실은 어떤 계기판보다 강하게 작동한다.

미리 말해두면, 이 처방들의 겉모습은 4월 글에서 개인의 성장을 이야기하며 꺼냈던 것들과 비슷하다. 달라진 건 주어다. 그때는 한 사람이 자기 역량을 지키는 기술이었다면, 지금은 조직이 그 역량의 공급 자체를 마르지 않게 하는 설계다. 같은 동작이라도 혼자 근손실을 막는 운동과 팀 전체의 근육량을 관리하는 일은 무게가 다르다.

검증하지 못하는 승인자는 결국 나일 수 있다

지금까지 이 글은 주어를 개인에서 조직으로 한 칸씩 넓혀 왔다. 그런데 그 주어를 한 칸만 더 따라가면, 마지막에 다시 한 사람이 남는다. 그 구조를 세우라고 말해온 리더, 바로 필자 자신이다. 그리고 바로 거기서 이 글에서 가장 살벌한 그림이 떠오른다.

두 번째 글에서 필자는 AI가 아무리 발전해도 최종 승인 도장을 찍는 인간의 역할은 사라지지 않을 거라고 썼다. 코드에 문제가 생기면 책임질 사람이 필요하기 때문이고, 그 판단은 지금도 유효하다. 그런데 이번 글의 마취를 거기에 겹쳐보면, 책임 구조 때문에 도장을 찍는 자리는 없어지지 않는데, 마취는 그 도장을 찍을 능력만 골라서 지워간다. 그렇게 되면 종국에는 검증 능력이 빈약한 승인자만 남는다.

그리고 그 승인자가 누구일지 생각하면 마음이 편치 않다. 조직에서 도장을 쥔 사람은 대개 가장 큰 책임을 지고 있는 사람이고, 가장 큰 책임을 지는 사람은 대개 코드에서 가장 멀어진 사람, 바로 리더다.

사실 리더가 코드에서 멀어지는 것 자체는 AI가 만든 문제가 아니다. 매니징에만 집중하다 보면 코드를 분간하는 감각이 녹스는 건 예전부터 있던 일이다. 달라진 건 그 녹슮을 받쳐주던 받침대다.

앞서 말했듯 예전에는 리더가 코드에서 멀어져도 그 아래에 인과를 쥔 작성자와 리뷰어가 두 겹으로 깔려 있었다. 리더 개인이 녹슬어도 조직에 분산된 점유권이 그걸 받쳐준 셈이다. 그런데 작성도 AI, 검토도 AI가 되는 순간 그 받침대가 통째로 빠진다. 리더의 녹슮이 더 이상 개인의 문제로 머물지 않고, 받쳐줄 것이 없는 조직의 기본값이 되는 것이다.

즉 마취가 가장 먼저, 가장 깊이 도달하기 좋은 사람이 정작 최종 승인의 책임을 진 사람일 수 있다는 것이다. 회사에서 코드를 거의 짜지 않는 필자 같은 사람이 정작 최종 승인의 도장을 쥐고 있다는 사실이 바로 이 지점에서 서늘해진다. 능력 없이 자리만 남은 승인자에게 책임은 방패가 아니라 청구서가 되기 때문이다.

리더가 지켜야 하는 건 감별력이다

그래서 앞에서 말한 구조들은 사실 팀을 위한 처방이기 전에 리더 자신을 위한 처방이기도 하다. 다만 여기서 리더가 해야 하는 건 모든 코드를 직접 검증하는 게 아니다. 그건 가능하지도 않고, 이미 코드에서 멀어진 리더에게 전수 검증을 요구해봐야 또 하나의 그럴싸한 도장만 늘 뿐이다.

리더에게 필요한 건 전수 검증이 아니라 감별력이다. 팀이 적어낸 인과가 진짜인지 그럴듯한 포장인지를 가려낼 수 있을 정도의 감각 말이다. 그 감각은 책상에서 지표만 들여다봐서는 유지되지 않아서, 코어 도메인의 바닥에 가끔은 직접 내려가봐야 녹슬지 않는다. 리더가 바닥에 내려가는 건 그 코드를 혼자 책임지기 위해서가 아니라, 팀의 설명이 썩어가는 걸 알아챌 눈을 잃지 않기 위해서다. 자기가 가려낼 수조차 없는 기준을 팀에 강제하는 리더는, 마취된 조직 위에 한 겹의 권위를 더 얹을 뿐이다.

마치며

길게 돌아왔지만 필자가 이 글에서 깨고 싶었던 착각은 하나다. AI를 잘 다루는 능력이 곧 유능한 개발자가 되는 길이라는 믿음이다. 활용 능력과 인지적 점유권은 같은 축이 아니고, 오히려 한쪽이 오르는 동안 다른 쪽이 조용히 깎이는 관계에 더 가깝다. 그리고 그 깎임은 한 사람의 머릿속에서 끝나지 않고, 조직의 머릿속을 통째로 비워가며 번진다.

그래서 예전 글들에서 필자가 던졌던 질문도 한 칸 옮겨야 할 것 같다. 개인으로서는 “나는 아직 내가 내보내는 걸 검증할 수 있나, 그리고 그 능력을 잃었을 때 나는 그 사실을 알아챌 수 있나”를 물으면 됐다. 그런데 리더의 자리에서는 질문이 이렇게 바뀐다. “우리 팀은 우리가 내보내는 걸 검증할 수 있나. 그 능력이 조직에서 말라갈 때, 나는 도장을 쥔 사람으로서 그걸 알아챌 수 있나. 그리고 다음 세대가 그 능력을 가져볼 사다리를, 나는 남겨두고 있나.”

물론 이런다고 마취제가 도는 것 자체를 멈출 수는 없다. 끝까지 마취되지 않는 조직 같은 건 없을지도 모른다. 그렇다면 리더가 통제할 수 있는 건 마취 여부가 아니라 마취가 도는 속도뿐이고, 자기 팀을 남들보다 조금 더 오래 무엇이 좋고 나쁜지를 분간할 수 있는 조직으로 남기는 것이 그나마 손에 잡히는 목표가 된다. 그게 면역을 보장해주진 않아도 유예는 벌어준다.

솔직히 임계점 너머에서 조직이 무엇을 해야 하는지에 대해 필자는 깔끔한 답을 가지고 있지 않다. 다만 효율이라는 마취제에 취해, 아무도 무엇을 모르는지조차 모르는 채로 굴러가는 시스템을 내 손으로 만들지는 않는 것, 지금 리더로서 필자가 할 수 있는 최소한의 저항은 거기까지라고 생각한다.

그래서 필자는 오늘도 AI가 짜둔 코드를 검수하고, 팀에 설명을 요구하고, 가끔은 직접 바닥에 내려가본다. 답을 알아서가 아니라, 검증하지 못한 코드를 그대로 내보내는 일이 무섭다는 감각만큼은 나에게도 우리 팀에게도 가장 늦게까지 남아 있기를 바라기 때문이다.

이상으로 리더가 정말 신경 써야 할 것은 생산성이 아니다 포스팅을 마친다.