AI 보조 코딩 (AI-assisted coding)을 도입한 후 우리 팀이 더 빨라지는 것을 지켜보며, 솔직히 말해서 기분이 좋았습니다. 더 많은 티켓(tickets)이 해결되었고, 사이클 타임 (cycle times)은 짧아졌으며, PR (Pull Request) 볼륨은 늘어났습니다. 저는 '이것이 바로 레버리지 (leverage)구나'라고 생각했던 기억이 납니다.

그것이 실수였습니다. 도구가 아니라, 가정이 문제였습니다.

변경 사항이 배포된 지 2주 후 — 모든 테스트를 통과하고, 리뷰를 거쳐, 깔끔하게 배포되었음에도 불구하고 — 우리는 그것이 재시도 메커니즘 (retry mechanism)을 조용히 저하시키고 있었다는 사실을 발견했습니다. 이는 우리의 테스트 환경이 재현하지 못하는 특정 부하 조건 (load conditions) 하에서만 작동했습니다. 아무도 이를 잡아내지 못했는데, 왜냐하면 잘못된 것처럼 보이지 않았기 때문입니다. 작동은 했습니다. 단지 안전하지 않았을 뿐입니다.

엔지니어에게 그 과정을 설명해 달라고 요청했을 때, 그들은 설명할 수 있었습니다. 코드는 논리적이었습니다. 그들은 각 부분이 무엇을 하는지 이해하고 있었습니다. 하지만 다운스트림 서비스 (downstream service)가 중단된 것이 아니라 단순히 느려진다면 어떻게 될 것인지 물었을 때, 잠시 침묵이 흘렀습니다. 그들이 능력이 없어서가 아니었습니다. 그런 질문을 던질 필요가 없었기 때문입니다. AI가 처리 코드 (handling code)를 작성했고, 테스트는 통과했으며, 그 질문이 나오기도 전에 모든 것이 진행되었습니다.

대시보드는 거짓말을 하지 않았습니다. 작업물은 더 빠르게 배포되고 있었습니다. 다만 대시보드는 저에게 중요한 부분을 보여주지 않았을 뿐입니다.

내가 예상하지 못했던 것

실제로 저를 놀라게 했던 것은 이것입니다: AI는 팀을 '실제로' 더 유능하게 만들기 전에, 팀이 '더 유능해 보이게' 만들 수 있다는 점입니다.

저는 예전에 막히는 과정을 통해 배웠습니다. 밤 11시에 겪는 그런 막막함 말입니다. 스택 트레이스 (stack trace)를 세 시간 동안 뚫어지게 쳐다보며, 내가 정말 이걸 이해하고 있는 게 맞는지 진심으로 의심하곤 했습니다. 그러한 마찰 (friction)은 실질적인 무언가를 만들어냈습니다. '이게 아마 작동하겠지만, 뭔가 느낌이 이상해. 배포하기 전에 무엇이 문제인지 파악해야 해'라고 말하는 본능 말입니다. 저는 6시간 동안 조용히 데이터를 손상시킨 마이그레이션 (migration)을 통해, 그리고 스테이징 (staging) 환경은 무사히 통과했지만 금요일 오후 운영 환경 (production)에서 실패한 캐싱 레이어 (caching layer)를 통해 그 본능을 쌓아 올렸습니다.

그것은 불필요한 고통에 대한 향수가 아닙니다. 고통은 그 자체로 하나의 메커니즘(mechanism)이었습니다. 초안을 작성하는 비용이 무료가 되는 순간, 그 메커니즘은 멈춥니다. 과거에는 코드를 작성하는 행위 자체 안에서 학습이 일어났습니다. 이제는 그렇지 않습니다. 그리고 저는 그것을 무엇이 대체할지 진심으로 확신할 수 없습니다.

어쩌면 무언가가 대체하고 있을지도 모릅니다. 어쩌면 제가 놓치고 있는 것일 수도 있습니다. 하지만 그것이 저절로 일어나는 것을 본 적은 없습니다.

격차는 한꺼번에 나타나지 않는다

어떤 것들은 빠르게 무너집니다. 어떤 것들은 몇 달이 걸립니다. 그중 하나는 위기가 닥쳤을 때에야 비로소 알게 됩니다.

리뷰 품질(Review quality)이 보통 가장 먼저 떨어집니다. 엔지니어 한 명이 예전에는 세 명이 해야 했을 만큼의 PR(Pull Request) 양을 생성하게 되면, 리뷰어들은 한계에 부딪힙니다. 자연스러운 움직임은 더 빨리 읽고, 문제가 없어 보이면 믿고 넘어가는 것입니다. 테스트가 통과하고 명백한 오류가 없다면, 아마 괜찮을 것이라고 생각합니다. 미묘한 문제들이 빠져나갑니다. 누군가 부주의해서가 아니라, 모든 변경 사항을 정말로 깊이 파고들 수 있는 정신적 여유(headspace)가 아무에게도 없기 때문입니다.

그다음에는 디버깅(debugging)이 얕아집니다. 오류를 채팅 인터페이스에 붙여넣고 30초 만에 해결책을 얻을 수 있게 되면, 왜 고장이 났는지 묻는 것을 멈추게 됩니다. 증상은 해결되고, 다음 작업으로 넘어갑니다. 하지만 다음에 비슷한 실패가 나타나면 — 형태가 약간 다르거나 맥락이 다르더라도 — 첫 번째 실패를 제대로 이해하지 못했기 때문에 더 오랜 시간이 걸립니다. 그리고 그때쯤이면 두 사건이 서로 연결되어 있다는 사실조차 깨닫지 못할 수도 있습니다.

장애 대응(Incident response)은 상황이 얼마나 악화되었는지 실제로 목격하게 되는 지점입니다. 저는 몇 달 동안 훌륭하게 업무를 수행해 온 엔지니어를 한 명 알고 있었습니다. 탄탄한 PR, 빠른 전달, 주변의 좋은 피드백까지 모두 갖추고 있었죠. 하지만 그들의 첫 번째 실제 장애는 혹독했습니다. 패닉에 빠진 것은 아니었습니다. 단지 상황이 제대로 돌아가지 않고, 명확한 답 없이 문제를 해결해야 하는 상황을 겪어본 적이 없었을 뿐입니다. 새벽 2시에 세 가지 잘못된 가설을 검토한 끝에야 비로소 정답에 도달해야 하는 그런 상황 말입니다. 그런 종류의 자신감은 다른 어디에서도 얻을 수 없습니다.

다른 분들도 이와 같은 형태, 즉 빠른 배포(fast shipping) 이후 첫 번째 실제 위기가 예상과는 다르게 다가오는 경험을 하셨는지 궁금합니다. 아니면 여러분의 경험은 달랐나요?

이것이 피할 수 없는 일일까요? 솔직히 저도 잘 모르겠습니다. 하지만 이것이 저절로 해결될 것이라고도 생각하지 않습니다.

그래서 우리는 여러 가지 시도를 하기 시작했습니다. 주로 그 사건(incident) 이후, 더 이상 무시하는 것이 불가능해진 시점부터였습니다.

우리가 실제로 시도한 것들

우리는 이 문제를 깔끔하게 해결해낸 것이 아닙니다. 무언가 잘못되었다는 것을 감지한 후, 즉 팀은 빠르게 움직이고 있지만 자신들이 무엇을 배포(shipping)하고 있는지 정확히 이해하지 못하고 있다는 사실을 깨달은 후에야 대부분의 해결책을 우연히 찾아냈습니다.

우리가 처음 시도한 것은 스탠드업(standups) 미팅에 더 많은 구조를 추가하는 것이었습니다. 사람들에게 그날 무엇을 배포했는지 설명하도록 요청했습니다. 하지만 효과가 없었습니다. 그것은 그저 하나의 '공연(performance)'을 만들어낼 뿐이었습니다. 사람들은 자신이 완전히 이해하지 못한 것들을 요약하는 데 능숙해졌습니다.

실제로 도움이 되었던 것은 코드 리뷰(code review)의 목적을 바꾸는 것이었습니다. 우리는 코드 리뷰를 '이것이 작동하는가?'라는 관문의 역할로 사용하는 것을 중단하고, 속도를 늦추어 함께 생각하는 장소로 취급하기 시작했습니다. 리뷰어들은 다음과 같은 질문을 던지기 시작했습니다: "여기서 가장 걱정되는 실패 모드(failure mode)는 무엇인가요?"

인증(auth), 결제(payments), 데이터 마이그레이션(data migrations) 또는 외부 신뢰성(external reliability)과 관련된 모든 사항에 대해 우리는 한 가지 기대치를 추가했습니다. 바로 PR(Pull Request) 설명에 무엇이 잘못될 수 있는지에 대한 한 단락을 포함해야 한다는 것이었습니다.

처음에는 더 느려진 것처럼 느껴졌습니다. 하지만 그렇지 않았습니다. PR의 질이 좋아졌습니다. 사람들이 PR을 열기도 전에 던지는 질문들이 더 좋아졌습니다. 결국 품질 검사(quality check)와 학습(learning)은 같은 것이었습니다. 우리는 단지 리뷰가 실제로 무엇을 위한 것인지에 대해 솔직하지 못했을 뿐입니다.

우리는 또한 일반적인 스프린트(sprint)에서는 자연스럽게 만들어지지 않는 연습을 위한 공간을 마련했습니다. 디버깅 훈련(Debugging drills), 새로운 팀원이 타임라인을 소리 내어 추론해 보는 사후 분석(Post-mortem) 워크스루, 그리고 단순히 승인(sign-off)만을 받는 것이 아니라 도전적인 의견을 기대하는 디자인 리뷰(Design reviews) 등이 그것입니다.

그리고 우리는 주니어들이 적절하다고 느껴지는 시점보다 더 일찍 장애 대응(incident shadowing)에 참여할 수 있도록 했습니다. 예전에는 그것이 자격을 갖추어야 얻을 수 있는 권한이라고 생각했습니다. 하지만 제가 반대로 생각했다는 것을 깨달았습니다. 실제 장애가 전개되는 과정—어떤 질문이 던져지는지, 무엇이 제외되는지, 사람들이 어디에서 막히는지—을 지켜보는 것은 훈련(drill)으로는 재현할 수 없는 경험입니다.

그중 어느 것도 "영원히 AI를 쓰지 말자"는 뜻은 아니었습니다. 저 역시 이것이 완전한 해답이라고 확신하지는 못합니다. 하지만 아무것도 하지 않은 채 그 간극이 저절로 메워지기를 바라는 것보다는 나았습니다.

여전히 해결하지 못한 문제들

저는 이 모든 것을 측정할 수 있는 깔끔한 방법을 가지고 있지 않습니다. 리뷰 품질의 향상, 설계 논의에서의 더 날카로운 질문들, 장애 발생 시 더 빠른 진단 — 이 모든 것들이 저에게는 실질적으로 느껴지지만, 매우 느리고 간접적입니다. 이를 위한 대시보드도 없으며, 그런 대시보드가 있다고 말하는 사람을 저는 온전히 신뢰하지 않습니다.

또한 저는 AI가 전반적으로 학습에 나쁘다는 주장을 하는 것도 아닙니다. 이전에는 특정 시도를 하지 않았을 엔지니어들이 이제는 시도하게 되고, 그 시도가 무언가를 가르쳐 줍니다. AI는 모른다는 사실에서 오는 수치심을 덜어주는 방식으로 개념을 설명해 줄 수 있습니다. 저는 이 점을 부정하고 싶지 않습니다.

하지만 고장 난 시스템 안에 머물며 스스로 문제를 해결해야 할 때 얻게 되는 특정한 종류의 이해가 있습니다. 로그는 모호하고, 런북(runbook)은 정확히 이 상황을 다루지 않습니다. 아무도 명확한 답을 가지고 있지 않습니다. 그런 과정이 무언가를 쌓아 올립니다. 실제 상황이 아닌 곳에서 이를 어떻게 재현할 수 있을지는 잘 모르겠습니다.

어쩌면 제가 생각하지 못한 접근 방식이 있을지도 모릅니다. 다른 사람들도 똑같은 벽에 부딪히고 있는지, 아니면 이를 우회할 방법을 찾고 있는지 궁금합니다.

계속해서 되돌아오게 되는 지점

AI는 초안을 작성합니다. 하지만 초안이 틀렸을 때 AI가 당신을 가르쳐 줄 수 있을지는 확신할 수 없습니다. 그리고 어쩌면 그 부분이 가장 중요한 부분일지도 모릅니다.

팀은 더 빨라지는 동시에 더 얕아질 수 있습니다. 속도 지표(velocity metrics)는 이를 알려주지 않을 것입니다. 당신은 1년 동안 그것을 알아차리지 못할 수도 있습니다.

저는 AI 도입을 늦추자고 주장하는 것이 아닙니다. 그것이 옳은 결정이라고 생각하지 않으며, 솔직히 무엇이 옳은 결정인지조차 아직 잘 모르겠습니다. 하지만 이것은 대부분의 팀이 그러는 것보다 더 솔직하게 이야기할 가치가 있다고 생각합니다.

제가 진심으로 궁금한 몇 가지는 다음과 같습니다:

• 여러분의 팀은 이 문제를 어떻게 생각하고 계신가요? 속도를 높임에 따라 깊이(depth)가 유지되고 있다고 보시나요, 아니면 여러분도 조용한 표류(drift)를 느끼고 계신가요?
• 판단 격차(judgment gap)가 어디에서 가장 먼저 나타난다고 보시나요 — 리뷰(review), 디버깅(debugging), 장애(incidents), 아니면 다른 무엇인가요?
• "더 많이 페어 프로그래밍하고 더 엄격하게 리뷰하자"는 식의 조언을 넘어, 실제로 효과가 있는 방법을 찾은 분이 계신가요?
• 그리고 불편한 질문입니다: 우리는 올바른 것을 측정하고 있나요, 아니면 그저 측정하기 쉬운 것만을 측정하고 있나요?

이 질문들에 대해 깔끔한 정답이 하나만 존재한다고 생각하지 않습니다. 하지만 대시보드가 모든 진실을 말해주고 있는 척하기보다는, 차라리 이렇게 공개적으로 질문을 던지는 편이 낫다고 생각합니다.