유령 사냥: 개발자의 진짜 기여를 보는 법

‘고스트 엔지니어’—개발자 열 명 중 한 명은 바쁜 척만 그럴듯하게 할 뿐, 실질적으로 유용한 일을 거의 하지 않습니다. 투잡, 번아웃, 또는 그저 일을 게을리하는 것 같은 진짜 이유는 오랫동안 경영진의 눈에 띄지 않을 수 있습니다. (2024년 스탠퍼드 연구: 원문 스레드)

개발자들은 자신의 성과가 화제에 오르는 것을 좋아하지 않습니다. 이 직업의 오랜 ‘황금기’를 거치며 업계에는 단순한 질문 하나를 꺼내기 어려운 분위기가 생겼습니다. 개발 결과가 투입한 시간과 비용에 걸맞은가? 하지만 고스트 엔지니어 때문에 답답한 것은 동료 개발자들도 마찬가지입니다. 대개 문제를 가장 먼저 알아채는 쪽은 경영진이 아니라 팀입니다.

러시아에는 역사적으로 ‘고자질’을 꺼리는 문화가 있습니다. 그래서 여러 사람이 문제를 알고도 아무도 말하려 하지 않습니다. 남의 골치 아픈 일에 왜 끼어들겠습니까? 결국 모두의 인내심이 바닥난 뒤에야 문제가 수면 위로 올라옵니다.

그래도 그 유령들은 그냥 놔두면 안 될까요? 회사 돈이 조금 샌다고 무슨 큰일이겠어요.

하지만 함정은 바로 거기에 있습니다….

제가 말하는 낮은 성과는 Alex가 열심히 일하면서도 Ben보다 10% 덜 해내는 상황이 아닙니다. 매일 스탠드업 때마다 팀 전체가 또 하나의 눈물겨운 사연을 들어야 하는 상황입니다. 다른 팀이 발목을 잡았고, 티켓이 모호했고, 운도 따르지 않았다고 합니다. 그래도 내일은 반드시 끝납니다. 정말입니다.

그런데 그 ‘내일’은 어제도, 그제도 이미 들었던 말이고, 이제는 하나의 전통이 되었습니다.

팀은 이런 일을 빠르게 알아챕니다. 실제로 업무를 짊어진 사람이라면 자연스럽게 묻게 됩니다. 그럴듯한 이야기만 늘어놓고 아무 책임도 지지 않을 수 있는데, 왜 나만 죽도록 일해야 하지?

하지만 문제를 알아채는 것만으로는 부족합니다. 숫자와 사실이 없으면 대화는 금세 말싸움이 됩니다. 팀은 “성과가 나오지 않는다”고 하고, 개발자는 “일을 못 하게 막는다”고 맞섭니다. 보통은 모두의 인내심이 다하고 팀이 관리자에게 교체를 요구한 뒤에야 조사가 시작됩니다.

그때부터 긴 과정이 시작됩니다. 사실을 모으고, 양쪽 이야기를 듣고, 피드백을 주고, 상황이 나아질 시간을 줍니다. 제 경험상 대부분은 고스트가 새롭고도 아주 ‘운 좋은’ 고용주를 찾아 떠나는 것으로 끝납니다.

문제는 단지 한 사람이 일을 덜 한다는 데 그치지 않습니다. 회사는 두 번 비용을 냅니다. 먼저 끝내지 않은 업무에 돈을 내고, 그다음에는 동료와 관리자가 재확인하고, 빈틈을 메우고, 왜 일이 진행되지 않는지 파악하는 시간에 돈을 냅니다. 결국 성과가 떨어지는 것은 개발자 한 명이 아니라 팀 전체입니다.

팀의 인내심이 바닥나고 회사가 시간과 돈을 잃기 전에, 관리자가 이상 징후를 발견하고 맥락을 물은 뒤 조사할 수는 없을까요?

경험이 충분하면 몇 가지 특징적인 행동 패턴만으로도 이런 상황을 미리 알아볼 때가 있습니다.

• 성공은 모두 내 공이고, 실패는 모두 네 탓이다.
• 일을 시작하기도 전에 실패할 경우를 대비한 핑계를 댄다.
• 부족한 실력을 과도한 말로 메우려 한다.
• 시간이 지날수록 특히 관리자가 ‘문제의 원인’으로 지목된다.
• 정말로 어려움을 겪는 사람과 달리, 직접적인 피드백을 받아도 행동이 나아지지 않는다.

하지만 의심을 뒷받침하려면 디지털 흔적이 필요합니다.

개발 성과를 측정할 때 가장 흔히 쓰는 도구들을 살펴보고, 고스트를 찾아내는 데 도움이 되는지 알아보겠습니다.

비교에 앞서 명백한 이해관계를 밝혀야겠습니다. 지금 읽고 있는 곳은 DevGhost 공식 블로그이고, 저는 이 제품의 창업자입니다. 이 글은 독립적인 연구가 아니라 저자의 관점입니다.

비즈니스나 제품 전체가 아니라 소프트웨어 개발 자체를 평가할 때 저는 ‘속도, 품질, 양’이라는 단순한 세 축을 사용합니다. 속도는 DORA 지표가, 품질은 테스트와 결함이 알려줍니다. 어려운 것은 양입니다. 가장 덜 개척된 영역이자, 우리가 찾는 고스트가 숨어 있기 쉬운 곳입니다.

DORA: 속도와 릴리스 신뢰성

DORA는 팀이 변경 사항을 얼마나 빠르고 안정적으로 프로덕션에 전달하는지 보여줍니다. 현재 모델은 커밋에서 프로덕션까지 걸리는 시간, 배포 빈도, 장애를 일으킨 배포의 비율, 복구 시간, 계획하지 않은 재작업의 비율이라는 다섯 가지 지표를 사용합니다.

전달 프로세스를 측정하기에는 좋지만 개인의 기여도를 보여주지는 않습니다. 한 사람이 세 명 몫을 하고 다른 한 사람은 팀 전체 성과 뒤에 숨어 있어도 DORA로는 알 수 없습니다.

이 지표들은 KPI로 쓰기에도 놀라울 만큼 편리합니다. 제가 일했던 한 회사에서는 2018년부터 아주 알차게 활용했습니다. 모두가 만족한 채 모든 대시보드를 성공적으로 초록색으로 칠했죠. 현재 DORA 모델.

테스트와 결함: 일을 얼마나 잘했는가

방법은 이미 잘 정립되어 있고 실무에서도 효과가 있습니다. 코드 리뷰, 테스트, 정적 분석으로 품질을 관리하고, 결함과 인시던트로 결과를 추적합니다.

하지만 이 신호들은 작업량을 말해주지 않습니다. 작고 완벽한 패치 하나만으로 모든 지표가 초록색이 될 수 있고, 고스트는 여전히 보이지 않습니다.

Jira와 스토리 포인트: 티켓을 몇 개 닫았는가

Jira는 완료된 티켓과 스토리 포인트를 보여주지만, 그 추정치는 팀이 직접 정합니다. 같은 일을 3포인트로도 13포인트로도 잡을 수 있고, 티켓 다섯 개로 나누거나 하나로 합칠 수도 있습니다.

스토리 포인트는 계획에는 유용하지만 개인의 기여도를 측정하기에는 신뢰하기 어렵습니다. 포인트가 목표가 되는 순간, 사람들은 업무가 아니라 포인트를 최적화하기 시작합니다.

역시 KPI로 쓰기에는 편리합니다. 품질 게이트를 통과하려고 데이터만 입력하고 티켓만 옮깁니다. 무의미한 수작업이 잔뜩 생깁니다.

커밋과 코드 줄 수: 맥락 없는 사실

Git은 팀의 추정치에 의존하지 않으니 커밋과 코드 줄 수를 세고 싶어집니다. 하지만 커밋 다섯 개가 아주 작은 패치 하나일 수도 있고, 단일 squash 커밋이 일주일치 작업일 수도 있습니다.

포맷 변경, 생성 코드, 복사, 코드 이동은 모두 줄 수를 부풀립니다. 반면 까다로운 수정은 단 열 줄일 수도 있습니다.

Swarmia, LinearB, Waydev: 개발 시스템 전체를 한곳에

Swarmia, LinearB, Waydev는 Git, 이슈 트래커, CI/CD를 한데 모읍니다. 관리자는 DORA 지표, 리뷰 대기열, 변경 리드 타임, 설문 결과를 볼 수 있습니다.

개발 시스템을 파악하는 데 유용하며, 문제가 개인이 아니라 프로세스에 있다는 사실을 드러내는 경우도 많습니다. 하지만 개별 개발자의 작업량을 서로 비교 가능한 척도로 재는 것은 이 플랫폼들이 답하려는 핵심 질문이 아닙니다. Swarmia, LinearB, Waydev.

GitClear: 코드 노이즈를 걷어낸 뒤 남는 것

GitClear는 추가, 이동, 복사된 코드를 구분하고 생성 파일을 제외하며, 새 코드가 나중에 다시 작성되거나 삭제되었는지도 반영합니다.

그 결과가 Diff Delta입니다. 코드베이스에 남은 의미 있는 변경을 나타내는 GitClear만의 단위입니다. 복사한 코드나 곧 버려진 코드는 프로덕션에서 계속 작동하는 간결한 변경보다 낮은 가중치를 받습니다. Diff Delta의 작동 방식.

Diff Delta는 얼마나 많은 노력이 필요했는지에 답하지 않습니다. 노이즈와 재작업 뒤에 의미 있는 변경이 얼마나 남았는지에 답합니다. GitClear의 강점은 코드의 지속성과 품질을 측정하고 AI의 영향을 분석하는 데 있습니다.

이제 조금 가까워졌습니다. 이 서비스는 벤치마크를 공개하지만 Diff Delta는 여전히 독자적인 단위입니다. 적절한 비교 대상과 방법론에 대한 이해가 없으면 10,000이라는 숫자만으로는 별 의미가 없습니다. ‘100%가 정상’ 같은 명확한 기준점도 없습니다. Diff Delta 벤치마크.

BlueOptima: 같은 질문을 엔터프라이즈 규모에서

저는 BlueOptima를 직접 써봤습니다. 2019년부터 이 플랫폼을 사용했고, 그 경험이 제 제품을 만드는 계기가 되었습니다.

Coding Effort 알고리즘은 일련의 정적 지표로 소스 코드 변경 하나하나를 분석합니다. 변경의 크기, 복잡성, 나머지 코드와의 관계를 고려한 뒤 결과를 시간으로 표현합니다.

그래서 서로 다른 팀과 기술 스택의 개발자를 글로벌 벤치마크까지 포함해 비교할 수 있습니다. 제게는 “이 개발자가 몇 줄을 썼는가?”가 아니라 “이 변경에 실질적인 일이 얼마나 들어 있는가?”라는 질문에 답하려는 최초의 설득력 있는 시도였습니다. BlueOptima 방법론, 글로벌 벤치마크.

제 경우 이런 엔터프라이즈 기능을 쓰려면 상당히 무거운 도입 과정이 필요했습니다. 폐쇄망 안에 에이전트를 배포해야 했고, 가격은 높았으며, 결과를 해석하려면 전문가가 필요했습니다.

개발자가 수천 명인 회사라면 정당화할 수 있습니다. 스타트업이나 작은 팀이라면 아마 어렵겠죠. 그 간극은 훗날 DevGhost가 탄생한 이유 중 하나가 되었습니다.

같은 척도를, RFP 없이

DevGhost를 만들 때 저는 상상할 수 있는 모든 개발 지표를 넣은 또 하나의 올인원 플랫폼을 만들려던 것이 아닙니다.

BlueOptima가 주던 답, 즉 변경 뒤에 실질적인 일이 얼마나 있는지를 스타트업 대표나 작은 팀도 RFP, 긴 도입 과정, 컨설턴트 팀 없이 얻을 수 있게 만들고 싶었습니다.

원리는 간단합니다. DevGhost는 무엇이 추가되고 삭제되고 재구성되었는지, 그 결과를 만들고 검증하기가 얼마나 어려웠는지 등 변경 자체를 분석합니다. 포맷 변경, 코드 이동, 대규모 자동 치환, 생성 코드는 실질적인 작업에서 분리합니다.

결과는 등가 시간으로 표현한 작업량 추정치입니다. 코드베이스를 알고 AI 없이 일하는 중급 개발자가 같은 코드를 작성하는 데 얼마나 걸릴지를 뜻합니다. 실제 키보드 앞에 앉아 있던 시간도, 코드 품질이나 비즈니스 가치에 대한 평가도 아닙니다. 변경을 비교하기 위한 공통의 척도입니다. DevGhost 방법론 자세히 보기.

Ghost%는 이 추정치를 중급 개발자에게 기대되는 산출량과 비교하면서, 그 사람이 실제로 개발에 쓰는 시간의 비율도 반영합니다. 100%는 기준에 부합한다는 뜻입니다. 낮으면 이유를 살펴볼 신호이고, 높으면 연구해 모범 사례로 확산할 만한 결과입니다.

기준은 의도적으로 AI를 쓰지 않는 업무를 가정합니다. DevGhost는 특정 코드를 사람, Copilot, 자율 에이전트 중 누가 작성했는지 판별하지 않습니다. 최종 변경을 보고, AI 없는 중급 개발자라면 이를 만들고 검증하는 데 얼마나 많은 노력이 필요했을지 평가합니다.

따라서 AI의 효과는 지표 속에 묻히지 않고 눈에 보이게 됩니다. 한 개발자가 어떤 기간에 과거라면 두세 배의 노력이 필요했을 결과물을 만들고 검증한다면 Ghost%에 반영됩니다. 포맷 변경, 대량 생성, 그 밖의 코드 노이즈가 같은 효과를 내서는 안 됩니다.

평가자는 누가 평가하는가

가장 당연한 질문은 이것입니다. 기계가 만든 추정치를 왜 믿어야 할까요? 짧게 답하면, 맹목적으로 믿어서는 안 됩니다.

업무의 난도를 평가하는 일은 정의상 주관적입니다. 저희는 같은 변경을 여러 숙련 개발자에게 추정해 달라고 했고, 눈에 띄게 다른 숫자를 받았습니다. 속도도, 경험도, 무엇을 어렵다고 느끼는지도 사람마다 다릅니다.

DevGhost도 틀릴 수 있습니다. 장점은 절대적 진실에 접근한다는 데 있지 않습니다. 모든 변경을 같은 척도로, 호감이나 피로, 작성자에 대한 선입견 없이 평가한다는 데 있습니다.

그래서 Ghost%는 판결이 아니라 신호입니다. 낮은 결과는 기여가 부족하다는 뜻일 수 있지만, 팀 리드 업무, 아키텍처 작업, 멘토링, 인시던트, 블로커로 설명될 수도 있습니다.

숫자는 어디에서 질문해야 하는지를 알려줍니다. 답을 찾는 일은 여전히 관리자의 몫이지만, 이제 직감만이 아니라 독립적인 두 번째 의견을 가지고 시작할 수 있습니다.

“우리 팀에서 누가 어떻게 일하는지는 이미 안다”

DevGhost 고객 중 한 명은 빠르게 성장하는 AI 기업의 엔지니어링 리더입니다. 처음에 그는 개발 성과를 측정한다는 발상 자체에 회의적이었습니다. 좋은 기술 리더라면 대시보드 없이도 누가 어떻게 일하는지 이미 안다는 입장이었습니다.

저희는 그가 잘 아는 리포지토리의 이력을 분석했습니다. 개발자 세 명은 이미 우려를 사고 있었습니다. 티켓 진행은 느렸지만 별도 서비스를 맡고 있어 나머지 팀과 비교하기 어려웠습니다. DevGhost는 약 6개월 동안 세 사람 모두가 일관되게 낮은 결과를 냈음을 보여줬습니다.

나중에 그들이 회사를 떠나기 시작하면서, 그 기간 내내 각자의 제품도 함께 만들고 있었다는 사실이 드러났습니다. DevGhost는 이유까지 알 수 없었습니다. 그저 커밋 수, 풀 리퀘스트, Slack에서의 일상 대화가 보여주지 못한 사실, 즉 작업량이 기대보다 눈에 띄게 낮았다는 점을 드러냈을 뿐입니다.

그러나 분석 결과가 해고 명단이 된 것은 아닙니다. 다른 개발자 두 명에게는 낮은 결과 덕분에 구체적인 피드백을 주고 원인을 살펴본 뒤 성과를 개선할 수 있었습니다. 둘 다 팀에 남았습니다.

그가 강하다고 생각했던 개발자들도 예상한 위치에 정확히 나타났습니다. 이제 누가 높은 성과를 내는지뿐 아니라 얼마나 꾸준한지도 볼 수 있었습니다.

물론 사례 하나로 방법의 정확성을 입증할 수는 없습니다. 고객이 놀란 것은 전체 그림이 이전에는 감으로만 알았던 것, 어떤 경우에는 일이 지나간 뒤에야 분명해진 것과 아주 잘 맞았다는 점입니다.

한 개발자가 세 명 몫의 결과를 낸다면?

고스트 사냥은 이 이야기에서 가장 눈길을 끄는 부분입니다. 하지만 차트의 상단이 더 유용할 수도 있습니다.

개발자가 평균의 몇 배에 이르는 결과를 꾸준히 낸다면, 정확히 어떻게 해내는지 알아볼 가치가 있습니다.

이제 질문은 개발자가 AI를 쓰느냐가 아닙니다. 많은 사람에게 AI는 이미 일상의 일부입니다. 중요한 것은 에이전트를 얼마나 효과적으로 추가 생산 역량으로 바꾸느냐입니다.

어떤 사람은 자동 완성에서 멈춥니다. 다른 사람은 에이전트에 적절한 맥락을 주고, 명확한 규칙을 세우고, 여러 작업을 병렬로 진행하며, 결과를 꼼꼼히 검토할 줄 압니다. 따라서 같은 AI를 쓸 수 있어도 생산성 향상 폭은 완전히 달라집니다.

높은 Ghost%는 사람과 에이전트의 조합으로 이미 좋은 결과를 내는 개발자를 찾고, 그들의 어떤 방식을 팀 전체가 배울 수 있는지 이해하는 데 도움이 됩니다.

높은 결과가 업무 품질과 관리자의 평가로도 뒷받침된다면, 그 개발자를 제대로 인정하고 붙잡아야 하며 승진 후보로도 고려해야 합니다. 그 방식도 연구해 팀 안에 확산해야 합니다.

척도를 무기로 만들지 마라

모든 지표는 같은 운명을 맞습니다. 언젠가 누군가 KPI로 만들려 합니다. Ghost%는 그 용도에 맞지 않습니다.

Ghost%를 팀 KPI로 만들면 사람들은 일을 지표에 맞춰 최적화하기 시작합니다. 순위를 공개하면 신뢰가 사라집니다. 점수를 해고 버튼으로 만들면 실수는 피할 수 없습니다.

저라면 네 가지 원칙을 정하겠습니다.

• 한 번의 측정이나 짧은 기간만 보고 결론 내리지 않는다.
• 그 사람의 역할, 개발에 쓰는 시간의 비율, 코드 밖에서 하는 일을 고려한다.
• 결과를 개발자에게 보여주고 맥락을 설명할 기회를 준다.
• Ghost%만으로 고용 관련 결정을 내리지 않는다.

낮은 결과가 계속된다면 관리자는 먼저 이유를 살펴봐야 합니다. 실제로 업무 수행에 어려움을 겪는 것일 수 있습니다. 반대로 아키텍처 작업을 맡고 있거나, 다른 사람의 인시던트를 처리하거나, 팀 프로세스에 막혀 있을 수도 있습니다.

문제가 확인되면 구체적인 개선 계획을 세우고 합의한 기간이 지난 뒤 다시 평가해야 합니다.

지표를 거부한다고 사람에 대한 평가가 사라지는 것은 아닙니다. 그 자리를 직감, 스탠드업에서 들려오는 이야기, 관리자의 개인적 호불호가 차지할 뿐입니다.

속도, 품질, 양에는 서로 다른 도구가 필요합니다. DORA는 변경이 프로덕션으로 이동하는 과정을 보여주고, 테스트와 결함은 품질을 보여줍니다. DevGhost는 코드 변경 뒤에 있는 작업량 추정을 더합니다.

어떤 지표도 관리자를 대신해 결정을 내려서는 안 됩니다.

숫자의 가치는 판결을 내리는 데 있지 않습니다. 어려운 대화를 더 일찍, 사실에 근거해 시작하게 해주는 데 있습니다.

여러분은 개발자의 작업량을 어떻게 평가합니까? 유용한 투명성과 감시 사이의 선은 어디에 긋습니까?