켄트 벡이 신입에게: "태스크 끝내라고 널 뽑은 게 아니야"

"일 다 끝냈는데, 왜 반응이 미지근하죠?"

주니어 시절에 이런 경험 한 번쯤 있으시죠? 시킨 일을 후딱 끝내고 "다 했습니다!" 하고 자신만만하게 보고했는데, 정작 선배 표정이 영 떨떠름했던 순간이요. 애자일 선언문에 서명하고 TDD(테스트 주도 개발, 테스트를 먼저 짜고 그에 맞춰 코드를 만드는 방식)를 널리 퍼뜨린 켄트 벡(Kent Beck)이 최근 자기 뉴스레터에 딱 이 이야기를 꺼냈어요. 제목부터 좀 도발적입니다. "이봐 신입, 우린 네가 태스크나 끝내라고 뽑은 게 아니야."

처음 들으면 좀 서운할 수도 있는데요, 끝까지 읽어보면 사실 굉장히 따뜻한 조언이에요. 그리고 AI가 코드를 대신 짜주기 시작한 지금이야말로 한 번 곱씹어볼 만한 메시지이기도 하고요.

티켓을 닫는 건 목적이 아니라 수단이에요

벡이 말하는 핵심은 이렇습니다. 회사가 개발자에게 진짜 바라는 건 "지라 티켓에 완료 도장을 찍는 행위" 그 자체가 아니라는 거예요. 티켓을 닫는 건 어디까지나 수단이고, 진짜 목적은 그 일을 통해 "현실의 문제가 실제로 풀리는 것"이거든요.

이 둘이 뭐가 다르냐면요. 예를 들어 "가끔 결제가 실패한다"는 버그 티켓을 받았다고 쳐봐요. 한쪽은 에러가 뜨는 그 자리에 try-catch를 둘러서 에러 메시지를 안 보이게 막고 티켓을 닫아요. 동작은 하죠, 티켓도 닫혔고요. 근데 결제는 여전히 실패하고 있어요. 다른 한쪽은 "왜 실패하지?"를 파고들어서 타임아웃 설정이 너무 짧았다는 근본 원인을 찾아내요. 똑같이 티켓 하나를 닫았지만, 회사에 남긴 가치는 하늘과 땅 차이인 거죠.

주니어가 흔히 빠지는 함정이 바로 여기예요. 주어진 문장을 그대로 받아들이고 "완료"까지 최단 거리로 달려가려는 거죠. 반면 경험 많은 개발자는 일을 시작하기 전에 먼저 물어요. "이걸 왜 하지? 진짜 풀어야 할 문제가 뭐지? 혹시 이 요구사항 자체가 틀린 건 아닐까?"

AI 시대라서 더 뼈아픈 말

사실 이 조언이 지금 더 와닿는 이유가 있어요. 요즘 Claude Code나 코파일럿 같은 AI 코딩 도구가 등장하면서, "명확하게 정의된 작업을 코드로 옮기는 일"은 점점 기계가 더 빠르고 정확하게 해내고 있거든요. 그러니까 "시킨 걸 군말 없이 빠르게 코드로 바꾸는 능력"만으로는 더 이상 나를 특별하게 만들어주지 못하는 시대가 온 거예요.

오히려 사람의 진짜 가치는 다른 데로 옮겨갔어요. 무엇을 만들지 정하고, 왜 그게 맞는 방향인지 판단하고, 애매하게 던져진 요구사항을 좋은 질문으로 다듬는 일이요. 재미있는 건, AI에게 좋은 결과물을 뽑아내려면 결국 내가 문제를 깊이 이해하고 있어야 한다는 점이에요. 문제를 모르면 AI에게 제대로 된 지시조차 못 내리니까요.

한국 개발자라면 이렇게

당장 실천할 수 있는 것들을 정리해볼게요.

티켓을 받으면 "왜요?"를 한 번 물어보기. 따지려는 게 아니라 맥락을 이해하려는 질문이에요.
코드 리뷰에서 "동작하나요?"를 넘어서기. "이게 맞는 방향인가요?", "더 단순한 방법은 없나요?"까지 같이 보는 거죠.
평가 기준을 경계하기. 작성한 코드 줄 수나 닫은 티켓 개수로 사람을 줄 세우는 문화라면, 결국 "태스크 완료 기계"를 키우게 되거든요.