신입 개발자를 작업 수로 평가하면 놓치는 것

신입 개발자를 작업 수로 평가하면 놓치는 것

IT & AI 뉴스 썸네일

신입 개발자가 이번 분기에 티켓 40개를 닫았고, 동료는 20개를 닫았어요. 숫자만 보면 전자가 앞서 보여요. 켄트 벡은 이 비교로는 두 사람이 어떤 엔지니어로 성장하고 있는지 알 수 없다고 말해요. 팀이 봐야 할 대상은 처리량뿐 아니라 학습 속도와 주변에 남기는 작업 비용이에요. 1 2

핵심 요약

구분	핵심	왜 볼 만한가요
기본 신뢰	동작하는 코드를 합리적인 시간 안에 내고 진행 상황을 공유해요	리뷰와 운영에 숨어 있는 비용까지 평가할 수 있어요
성장 신호	작업마다 설계, 테스트, 문서화 능력을 더 쌓아요	지금의 속도보다 다음 작업에서 빨라질 근거를 보여줘요
팀 기여	작은 변경과 재사용할 도구로 동료의 일을 줄여요	개인 처리량을 넘어 팀 전체의 생산성에 영향을 줘요
주의점	곁가지 개선이 공식 작업을 계속 늦추면 좋은 신호가 아니에요	학습과 납기를 함께 관리해야 해요

1. 신입 개발자의 가치는 완료한 티켓 수로만 보이지 않아요

켄트 벡은 선임 엔지니어가 신입을 세 부류로 가늠한다고 설명해요. 주변 동료의 생산성까지 높일 사람, 안정적으로 성장할 사람, 오래 함께하기 어려울 사람으로 나눠 봐요. 다소 거친 분류지만, 글이 묻는 질문은 분명해요. 지금 맡은 일을 얼마나 빨리 끝냈는지보다 앞으로 더 큰 문제를 다룰 능력을 어떻게 드러내는지가 핵심이에요. 2

기본 평가는 속도보다 신뢰에서 시작해요

좋은 신호의 출발점은 화려하지 않아요. 코드는 실제로 동작해야 해요. 진행 상황과 막힌 지점을 동료가 알 수 있어야 해요. 최초 예상에서 크게 벗어나지 않는 시간 안에 마쳐야 하고, 리뷰어나 온콜 담당자에게 피할 수 있었던 일을 넘기지 않아야 해요.

728x90

도움을 요청하는 일 자체는 문제가 아니에요. 같은 실수를 반복하거나 검증하지 않은 변경으로 장애 대응을 늘리는 행동이 신뢰를 깎아요. 실수한 뒤 원인을 기록하고 다음 변경에서 재발을 막는다면 오히려 학습 과정이 보여요. 작업 상태를 부풀리거나 하지 않은 일을 했다고 말하는 행동은 기술 수준과 별개로 협업을 무너뜨려요. 1

성장 속도는 다음 작업에서 드러나요

작업 하나를 마치며 무엇을 배웠는지가 다음 작업의 속도와 품질을 바꿔요. 요구사항 전체를 구현하기 전에 효과가 큰 일부를 찾을 수도 있어요. 어려운 변경을 바로 밀어 넣는 대신 주변 설계를 먼저 단순하게 만들 수도 있어요. 큰 변경 하나를 오래 들고 있기보다 검토 가능한 작은 변경을 연속으로 내면 피드백도 빨리 받아요.

단위 테스트와 문서도 같은 기준으로 볼 수 있어요. 테스트는 이번 코드의 오류만 찾는 장치가 아니에요. 다음 사람이 안전하게 고칠 수 있는 범위를 알려줘요. 문서는 작업 중 알아낸 제약과 선택 이유를 남겨서 동료가 같은 조사를 되풀이하지 않게 해요. 비슷한 일이 다시 생긴다면 내부 도구가 도움이 돼요. 한 번뿐인 일을 자동화하느라 구현보다 더 오래 쓰면 순서가 뒤집혀요. 2

작은 변경은 학습과 리뷰를 함께 빠르게 해요

작은 변경을 자주 제출하면 선임은 결과만 보는 대신 판단 과정을 일찍 확인할 수 있어요. 방향이 틀렸을 때 되돌릴 코드도 적어요. 신입은 피드백을 다음 변경에 바로 반영하면서 같은 실수를 반복할 가능성을 낮춰요. 팀은 큰 변경 하나가 끝날 때까지 기다리지 않아도 돼요.

다만 변경을 작게 나누는 것 자체가 목표가 되면 안 돼요. 서로 의존하는 조각을 지나치게 쪼개면 리뷰 문맥이 사라져요. 각 변경이 독립적으로 이해되고 검증되는 크기인지가 더 중요해요.

왜 중요한가요

개발팀이 티켓 수만 성과로 쓰면 쉬운 작업을 많이 고르는 행동을 부추길 수 있어요. 설계를 정리하거나 테스트를 보강하고 동료에게 지식을 전하는 일은 숫자에서 빠지기 쉬워요. 반대로 학습이라는 이름으로 납기를 계속 미루면 팀이 비용을 대신 떠안아요. 평가 기준에는 결과물, 소요 시간, 리뷰 비용, 운영 안정성, 같은 실수의 반복 여부가 함께 들어가야 해요.

신입에게도 적용 방법은 구체적이에요. 작업을 시작할 때 완료 조건과 예상 시간을 공유해요. 중간에는 바뀐 가정과 막힌 지점을 알려요. 제출할 때는 테스트 방법, 설계 선택, 남은 위험을 짧게 적어요. 리뷰에서 받은 지적은 다음 변경에서 먼저 확인해요. 이런 기록이 쌓이면 완료한 티켓 수보다 성장 방향을 설명하기 쉬워져요.

이 글은 조직의 책임도 남겨 둬요. 신입이 작은 변경을 제출하고 질문할 시간을 주지 않으면서 학습 속도만 요구할 수는 없어요. 선임은 기대 수준과 피드백 주기를 분명하게 정해야 해요. 신입은 그 안에서 납기를 지키며 배운 내용을 팀의 자산으로 바꿔야 해요. 켄트 벡의 글은 연구 결과가 아니라 오랜 개발 경험을 바탕으로 쓴 의견이에요. 모든 팀에 같은 등급표를 적용하기보다 평가 대화를 시작하는 기준으로 읽는 편이 맞아요. 1 2

참고 자료

1. 이봐, 신입, 우린 당신에게 주어진 일이나 끝내라고 채용한 게 아니야 — GeekNews
2. Hey, N00b, We Didn't Hire You to Complete Tasks — Kent Beck, Software Design: Tidy First?