대시보드가 저에게 좋은 소식을 전하고 있다고 생각했습니다.

우리 팀은 AI 보조 코딩 (AI-assisted coding)을 빠르게 도입했고, 한동안은 모두가 약속했던 바로 그 모습처럼 보였습니다. 더 많은 티켓(tickets)이 종료되었습니다. 사이클 타임 (cycle times)은 짧아졌습니다. 더 많은 PR (Pull Requests)이 진행되었습니다. 동일한 팀원이 더 많은 결과물을 내면서도 저항(drag)은 줄어들었습니다.

저는 이에 대해 기분이 좋았습니다.

그것이 제가 틀렸던 부분이었습니다.

변화를 느낀 순간

이 상황이 변하게 된 계기는 거대한 서비스 중단(outage)이나 극적인 실패가 아니었습니다. 그것은 그보다 더 조용하게 찾아왔고, 솔직히 말해 그 점이 상황을 더 악화시켰습니다.

우리는 모든 테스트를 통과하고, 리뷰를 마쳤으며, 깔끔하게 배포된 변경 사항을 출시했습니다. 2주 후, 우리는 그것이 테스트 환경에서는 재현되지 않는 부하 조건(load conditions) 하에서 재시도 경로(retry path)를 저하시키고 있다는 사실을 발견했습니다.

해당 엔지니어에게 변경 사항에 대해 설명해 달라고 요청했을 때, 그들은 설명할 수 있었습니다. 코드는 논리적이었습니다. 그들은 각 부분이 무엇을 하는지 이해하고 있었습니다.

하지만 다운스트림 서비스 (downstream service)가 다운되는 것이 아니라, 단지 느려진다면 어떻게 될 것 같냐고 물었을 때, 잠시 침묵이 흘렀습니다.

그들이 능력이 부족해서가 아니었습니다.

그 질문을 던질 필요가 전혀 없었기 때문입니다.

AI가 처리 코드(handling code)를 작성했고, 테스트는 통과했으며, 그 질문이 나오기도 전에 모든 과정이 앞으로 나아갔습니다.

그 순간 대시보드는 저에게 진실을 말해주지 않기 시작했습니다.

대시보드가 거짓말을 하고 있었기 때문이 아닙니다. 실제로 상황은 더 빠르게 진행되고 있었습니다.

단지 중요한 부분을 보여주지 않았을 뿐입니다.

예상치 못했던 것

제가 예상하지 못했던 것은, AI가 팀을 실제로 더 유능하게 만들기 전에 팀이 더 유능해 보이게 만들 수 있다는 점이었습니다.

저는 예전에 막히는 과정을 통해 배웠습니다. 즐거운 방식은 아니었습니다. 밤 11시의 그런 방식 말입니다. 스택 트레이스 (stack trace)를 몇 시간 동안 응시하고, 잘못된 가설을 세 번이나 쫓고, 기술적으로는 작동하지만 여전히 안전하지는 않다는 것을 알려주는 직관을 천천히 쌓아가는 그런 방식 말입니다.

그 직관은 다듬어진 답변에서 온 것이 아니었습니다. 그것은 마찰(friction)에서 왔습니다. 데어본 경험에서 왔습니다. 압박 속에서 무엇이 실패하는지를 목격하는 과정에서 왔습니다.

그것이 바로 우리가 아직 진정으로 대체하지 못했다고 생각하는 부분입니다.

초안이 공짜로 제공될 때, 초기 학습의 많은 부분이 생략됩니다. 결과물은 여전히 얻을 수 있고, 움직임(motion)도 계속됩니다. 하지만 과거에 고군분투(struggle) 과정 속에서 내재화되었던 판단력(judgment)이 자동으로 얻어지지는 않습니다.

어쩌면 그 판단력이 다른 어딘가에서 재구축될지도 모릅니다. 제가 놓치고 있는 것일 수도 있습니다. 하지만 그것이 저절로 일어나는 것을 본 적은 없습니다.

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

첫 번째 격차는 보통 리뷰(review) 단계에서 나타납니다.

이제 엔지니어 한 명이 과거에 여러 명이 수행하던 수준의 PR(Pull Request) 양을 생성할 수 있습니다. 리뷰어들은 과부하에 걸립니다. 모두가 더 빨리 읽기 시작합니다. 테스트가 통과하고 명백하게 망가진 부분이 없다면, 아마 승인될 것입니다.

저는 테스트가 존재하고 깔끔하지만, 실제 실패 모드(failure mode)와는 완전히 동떨어진 PR들을 보기 시작했습니다. 그것은 매우 특정한 종류의 문제입니다. 엄격함(rigor)처럼 보이지만, 엄격함이 아닙니다.

다음 격차는 디버깅(debugging)에서 나타납니다.

모든 오류를 채팅창에 붙여넣기만 하면 30초 만에 그럴듯한 수정안으로 바꿀 수 있다면, 왜 망가졌는지 묻는 것을 멈추게 됩니다. 증상만 패치(patch)될 뿐, 교훈은 남지 않습니다. 그러다 다음번에 비슷한 실패가 약간 다른 형태로 나타나면, 아무도 첫 번째 실패로부터 제대로 배우지 못했기 때문에 팀은 예상보다 더 많은 시간을 허비하게 됩니다.

그러다 첫 번째 진짜 장애(incident)가 발생하면, 그때 무엇이 구축되었고 무엇이 구축되지 않았는지를 깨닫게 됩니다.

몇 달 동안 작업을 잘 수행해 온 엔지니어가 있었습니다. 탄탄한 PR, 빠른 전달, 좋은 피드백을 보여주었습니다. 하지만 그들의 첫 번째 진짜 장애 대응은 힘들었습니다. 패닉에 빠진 것은 아니었습니다. 단지 정답이 명확하지 않을 때 문제를 어떻게 좁혀나가야 하는지 알 정도로 망가진 시스템 안에서 충분한 시간을 보내지 않았을 뿐입니다.

그것은 반복 숙달(reps)이 필요합니다. 달리 설명할 방법을 모르겠습니다.

우리가 실제로 시도했던 것

우리는 이 문제를 깔끔하게 해결하지 못했습니다.

우리는 전혀 효과가 없었던 한 가지를 시도했습니다. 스탠드업(standup) 미팅에 더 많은 구조를 추가하고 사람들에게 자신이 무엇을 배포했는지 설명하도록 요청하는 것이었습니다. 대부분의 경우, 그것은 단지 사람들이 자신이 완전히 이해하지 못한 것에 대해 자신감 있게 말하는 법을 배우게 만들 뿐이었습니다.

더 도움이 되었던 것은 코드 리뷰(code review)의 목적을 바꾸는 것이었습니다.

우리는 리뷰를 단순히 통과해야 하는 관문(gate)으로 취급하는 것을 멈추고, 사람들이 자신의 사고 과정을 보여주어야 하는 장소로 사용하기 시작했습니다. 단순히 코드가 무엇을 하는지가 아니라, 그들이 무엇을 가정했는지, 무엇이 가장 먼저 실패할지, 그리고 무엇을 처리하지 않기로 선택했는지를 보여주는 곳 말입니다.

영향력이 큰 영역에 대해서는, PR(Pull Request) 설명에 한 단락 정도의 짧은 글을 작성하도록 요구하기 시작했습니다: '여기서 무엇이 잘못될 수 있는가?'

처음에는 이것이 더 느리게 느껴졌습니다.

하지만 실제로는 그렇지 않았습니다.

PR을 올리기 전에 사람들이 던지는 질문들이 더 좋아졌습니다. 리뷰가 좋아졌습니다. 코드도 좋아졌습니다.

우리는 또한 일반적인 스프린트(sprint) 작업만으로는 자연스럽게 만들어지지 않는 연습을 위한 여유를 만들기 시작했습니다. 디버깅 훈련(debugging drills), 사후 분석(postmortem) 워크스루, 주니어 엔지니어들을 (본인이 느끼기에) 다소 불편할 정도로 이른 시점에 장애 대응 섀도잉(incident shadowing)에 참여시키는 것 등이 그것입니다.

이 중 어느 것도 화려하지 않습니다. 슬라이드 덱에 나오는 AI 전환(AI transformation)처럼 보이지도 않습니다.

하지만 이것은 속도를 더 신뢰할 수 있게 만들어 주었습니다.

내가 여전히 파악하지 못한 것

나는 여전히 이 모든 것을 어떻게 잘 측정할 수 있을지 확신하지 못하고 있습니다.

나에게는 판단력 개발(judgment development)을 위한 대시보드가 없으며, 그런 것이 있다고 말하는 사람을 완전히 신뢰하지도 않습니다.

또한 나는 그 해답이 AI로부터 멀어지는 것이라고 생각하지 않습니다. 그것은 너무 단순한 생각이며, 실제로 일어나고 있는 일을 놓치는 것입니다.

도구들은 유용합니다. 도구들은 사람들이 이전에는 시도하지 않았을 일들을 시도하도록 돕습니다. 모른다는 것에 대한 수치심을 줄여주기도 합니다. 그 부분 또한 실재합니다.

하지만 시스템이 망가지고, 로그가 모호하며, 아직 아무도 명확한 답을 내놓지 못한 상황에서만 나타나는 일종의 이해(understanding)라는 것이 있습니다.

그것은 여전히 고된 경험을 통해 배워야 하는 영역입니다.

그리고 나는 많은 팀이 더 빨라졌다고 스스로를 축하하는 바로 그 순간에, 이 사실을 다시 깨닫게 될 것이라고 생각합니다.

토론을 위하여

다른 팀들은 이것을 어떻게 보고 있는지 진심으로 궁금합니다.

여러분도 결과물(output)과 이해(understanding) 사이의 동일한 격차를 경험하고 계신가요?

그 격차가 여러분에게는 어디에서 가장 먼저 나타나나요: 리뷰, 디버깅, 장애(incidents), 아니면 다른 곳인가요?

AI 보조 팀에서 실제로 판단력을 기르는 데 도움이 되는 무언가를 찾으셨나요?

그리고 더 어려운 질문은 이것입니다: 우리는 정말 중요한 것을 측정하고 있나요, 아니면 단지 세기 쉬운 것만을 측정하고 있나요?