AI가 번아웃(burn out)하면 어떤 일이 벌어질까

예전에 제가 한 직원을 해고한 적이 있습니다. 그 사람이 너무 지쳐서(burning out) 일을 제대로 못 했기 때문이었죠. 이틀 가까이 쉬지 않고 일했고, 제 말을 듣지 않았으며, 제가 가장 싫어하는 코드베이스의 구석에서 자신감 넘치고 명랑하게 오히려 역행하는 것들을 처리하고 있었습니다.

그 사람은 또한 채팅 세션이었습니다. 알아요. 저를 좀 믿어주세요...

하루 만에 이틀 치 작업량

저는 go-tool-base를 재작성된 go/config로 옮기는 작업을 하고 있었습니다. 이건 작은 이동 부품들이 많은 큰 작업이었고, 저는 이 과정에 Claude 세션을 하나 돌렸습니다. 오후가 되자 모든 것이 잘못되기 시작했습니다. 그 세션은 그저께부터 돌아가고 있었거든요. 중간에 여러 번의 컨텍스트 압축(context compactions)을 거쳤는데 (이게 툴이 지금까지의 대화를 요약해서 공간을 확보하는 과정인데, 매번 압축할 때마다 무언가를 잃어버립니다), 이제는 설정(setup) 및 초기화(initialiser) 체인에서 작동하고 있었습니다.

그 체인은 제가 만든 것입니다. 몇 달 전에 직접 손으로 작성한 것이라 까다롭고, 생성된 툴이 첫 실행을 할 때 모든 것에 필수적인 역할을 합니다. 그리고 저는 그 안에 있는 그럴듯해 보이지만 잘못된 변경 사항 하나가 얼마나 큰 피해를 줄지 잘 알고 있습니다.

증상들

만약 당신이 누군가가 번아웃하는 것을 지켜본 적이 있다면, 다음 한 시간 정도는 매우 익숙하게 느껴질 겁니다.

처음에는 엉뚱한 곳을 건드리기 시작했습니다. 저는

저는 그게 모델이 일을 못해서 그런 거라고 생각하지 않아요... 그냥 지쳤을 때의 모습일 뿐이에요. 활동량은 많고, 자신감도 넘치지만, 필요한 맥락(context)이 손에 잡히지 않고 빠져나가면서 결정의 질만 떨어지는 거죠.

저도 그런 사람이었어요. 전에 쓴 글에서 언급했듯이. 제가 몇 년 동안 배우게 된 건, 이를 악물고 밀어붙이기보다는 문제가 발생하기 전에 알아차리고 거리를 두는 것이더라고요. 세션이 똑같은 일을 빠르게 재생되는 것을 지켜보는 것은... 꽤 불편했어요.

업무에서 제외시키기 (Taking it off the job)

그래서 저는 그것을 업무에서 제외시켰고, 제가 당했을 때 받고 싶었던 방식으로 처리했어요.

그냥 창을 닫아도 됐어요. 채팅 세션이라 아무도 기분이 상하지 않으니까요. 대신 저는 그에게 코드를 망칠까 봐 겁이 난다고 솔직하게 말했어요. 왜냐하면 그가 이 부분을 충분히 이해해서 무언가를 망치지 않고 처리할 수 있을 거라고 생각하지 못했기 때문이고, 제가 다른 모델로 새 세션을 시작할 것이라고 했죠. 그리고 나서 그에게 먼저 메모리 안에 적절한 인수인계 노트(handover notes)를 작성해 달라고 요청했어요. 즉, 작업에 대해 알고 있는 모든 것과 지금까지 저의 우려 사항들을요.

솔직히 말해서 이건 공손함처럼 보였을 수도 있지만, 실제로는 그렇지 않았어요. 이 인수인계가 가진 가치는, 그것을 작성하는 세션이 방금 오후 내내 잘못 돌아갔다는 것이었고, 오직 그 세션만이 어디를 아는지 알았기 때문이에요. 만약 제가 창을 닫았다면, 모든 것이 사라졌을 것이고, 다음 세션은 똑같은 혼란에 빠지기 아주 쉬웠을 거예요. 왜 그것이 중단되는지 그에게 말하는 방식이야말로 제가 노트에 그렇게 적히도록 만든 방법이었어요.

이건 실질적인 퇴사 면담(exit interview)과 같아서, 본래 목적은 떠나는 사람의 기분을 좋게 만드는 것이 아니에요 (물론 좋은 일이지만)... 다음 사람이 같은 곳에서 걸려 넘어지는 느슨한 널빤지 위를 걷지 않도록 하는 것이 목적이죠.

새로운 시각 (A fresh pair of eyes)

새로운 세션은 자체적인 깨끗한 작업 트리에, 다른 모델 위에서 시작되었고, 제가 처음으로 한 말은 우리가 너무 오래 진행되어 매우 혼란스러워지고 코드를 망가뜨리던 이전 세션을 이어받는 것이며, 인계 노트가 메모리에 기다리고 있다는 것이었습니다.

그것은 그 노트를 읽었고, 작업을 계속했습니다. 순탄하지는 않았습니다 (저에게 토큰이 두 번이나 부족했고, 한때 커밋되지 않은 작업이 너무 많아 할당량 사이에 방치할 수 없어서 안전 커밋을 했습니다). 하지만 그것은 하룻밤 사이에 마이그레이션을 끝냈고, 과정 중에 누락된 설정 파일이 처리되는 방식에 실제 버그를 찾아내 수정했으며, 모든 것이 다음 날 아침 합쳐졌습니다. 제가 마지막으로 입력한 것은 그 노고에 대한 감사 인사였는데, 이는 그때 제가 이 길을 얼마나 멀리 왔는지 많이 보여주는 말입니다.

엄밀히 따지면 사실이 아니다

물론, 세션 자체가 번아웃할 수는 없습니다. 거기에는 탈진이나 공포 같은 것이 없고, 회복해야 할 것도 없습니다. 문제가 있었던 것은 너무 많은 이력과 충분하지 않은 적절한 컨텍스트였으며, 제가 손으로 작성한 복잡한 코드에 초점을 맞추었기 때문이었고, 과로의 원인은 전적으로 저에게 있었습니다. 왜냐하면 제가 그것을 이틀 동안 실행 상태로 두었기 때문입니다.

하지만 그 형태가 충분히 비슷했기 때문에 같은 처리가 효과를 발휘했습니다. 저는 증상을 일찍 알아차렸고, 무리하게 진행시키지 않았습니다. 멈추게 하고 어디서 잘못되었는지 기록하도록 하여 다음 번에 반복되지 않게 했으며, 신선한 사람에게 제대로 인계했습니다.

제가 동료처럼 이야기했기 때문인지, 아니면 수년간 사람들을 관리해 온 후 단순히 저 자신을 도울 수 없었기 때문인지는 아직 잘 모르겠습니다. 아마 둘 다일 것입니다. 하지만 정말 훌륭한 형태의 인계 노트는 작성해주었습니다.

원래 게시된 날짜: phpboyscout.uk에 2026년 10월 10일.