개발자의 KPI 설계 - 경력기술서 작성을 넘어 업무 방향성 정하기

"경력기술서를 제출 안내드립니다."

토스 러너스하이 프로그램에서 이 메일을 받았을 때, 나는 또 익숙한 고민에 빠졌다. 개발 경력 동안 나는 무엇을 해왔고, 그것을 어떻게 표현해야 할까? 이전까지 작성했던 경력기술서들은 대부분 "~ 시스템을 개발했다", " ~ 기능을 구현했다" 정도의 단순한 서술에 그쳤던 것 같다. 그리고 이번에도 비슷한 고민이 반복되었다.

하지만 이번엔 익숙함 속에서 깨달은 바가 있었다. 내가 그동안 성과를 측정하고 관리하는 관점에서 일하지 않았다는 것. 그리고 이것이 단순히 경력기술서 작성의 문제를 넘어, 일하는 방식 전반에 걸친 근본적인 변화가 필요하다는 신호라는 것을.

왜 개발자에게 KPI가 필요한가

SI/SM 회사에서 시작한 나의 첫 경력에서부터 지금까지, 대부분의 조직에서 성과는 '무엇을 출시했는가'로 평가되었다. 새로운 기능을 만들고, 새로운 시스템을 구축하는 것. 이것이 전부였다. 그러다 보니 개발을 하면서 마주치는 의사결정 과정에서도 출시에 방해가 되느냐? 도움이 되느냐?의 기준아래서 모든 것이 결정되었던 것 같다. 우리가 기한 내에 익숙하게 처리할 수 있는 방식이 심지어 유지보수에 어려움을 준다고 해도 서비스 출시라는 미명 아래 선택되었다.

요즘도 크게 다르지는 않지만, 이제는 개발을 하는 것 뿐만 아니라 팀의 워크플로우를 정하고 수정하는 위일까지 하게 되었다. 과거를 되풀이 하지 않기 위해, 코드 컨벤션을 강조하고, 코드 리뷰나 Merge Request 형식을 작성하게 하고, 스크럼을 하는 등 적지 않은 노력을 했다. 그러면서 점점 명확해 진 것이 있다. 정량 지표가 없이 정성적인 설명만 하면 모두가 다른 생각과 방향으로 나아간다는 것이다.

정량적 지표가 중요한 이유는 바로 여기에 있다:

1. 의사결정의 객관적 근거를 제공한다.
2. 팀원들과의 합의된 기준점이 된다
3. 성과를 명확하게 측정하고 개선할 수 있다

예를 들면 '문서화가 잘 안되어 있어 기능 파악에 어려움이 있으니, 이런 문서를 만들어 봅시다.' 이런 제안은 거의 소리소문 없이 사라지기 일쑤였다. 이것이 문제 지점이 맞고 해결되어야 한다고 생각했으면 '우리가 말하는 문서화란 기능 당 무슨 무슨 문서가 있어야 하고, 이 기능의 수는 시스템 내 120개가 있으며, 현재 문서화 율은 12% 입니다. 다음 스프린트까지 문서화 우선 대상 기능은 무엇무엇이고 목표 문서화 율은 18% 입니다.' 이런 제안이 있을 때 훨씬 추적이 잘되고 팀 구성원들의 명시적, 암묵적인 합의가 더 잘 이루어졌다.

이 예시에서 '문서화 율'이라는 것이 하나의 정량 지표가 될 수 있겠다. 그리고 많은 조직에서 이런 성과관리 지표를 핵심성과지표 즉 KPI(Key Performance Indicator)라고 표현한다.

KPI 설정과 측정 방법론

KPI를 어떻게 설정할까 고민하던 중, 경력기술서 작성에 대해 설명한 영상을 보게 되었다. 이 영상에서 제시한 "문제 해결 중심의 서술" 방식에 착안해, 생성형 AI에게 개발자의 문제 해결 영역과 KPI를 연결해달라고 요청해보았다. 이하는 이 중에 몇 가지를 추린 결과다.

생성형 AI 를 통한 KPI 만들기

마치 어떤 개발팀에서 일하는 컨설턴트 처럼 지표를 만들어 주었다. 이것도 충분히 좋지만 보다 내 능력을 온전히 표현하도록 구성하고 싶다면 개발자의 역량 기준으로 조금 구분지어 생각해보면 좋을 것 같다.

개발자의 역량 기준으로 KPI 만들기

흔한 구분으로 개발자의 업무 영역으로 두 가지를 생각해볼 수 있다. 신규 개발(설계/구현)의 영역, 운영/유지보수의 영역이 그것이다. 특정 서비스를 담당하는 개발자라면 이 두 영역을 적절히 해결할 수 있는 역량을 갖추게 될 것이다. 그렇다면 거꾸로 생각해서 이 두 가지 영역에 대한 KPI 를 골고루 선정해 주는 것이 온전히 본인을 표현하는 것이다.(물론 이 영역의 구분은 개인의 상황에 따라 다를 수 있다.)

설계/구현 영역의 KPI

운영/유지보수 영역의 KPI

이렇게 재구성하면 개발자의 핵심 역량별로 어떤 KPI를 관리해야 하는지 더 명확해진다. 설계/구현 단계에서는 시스템의 기본 품질을 결정하는 지표들을, 운영/유지보수 단계에서는 시스템의 안정적 운영과 관련된 지표들을 관리하게 된다. 각 영역의 KPI는 서로 연관되어 있으며, 설계 단계의 품질이 운영 단계의 효율성에 직접적인 영향을 미친다는 점을 알 수 있다.

KPI와 개인의 경력 개발 연계

그럼 이제 이걸 하기만 하면 되겠지만, 현실은 녹록치 않다. 어떤 개발팀에 모니터링 도구를 도입한다는 것, ELK 스택을 도입한다는 것은 개인이 눈 감았다가 뜨면 해결되는 문제가 아니다. 조직의 규모와 구조, 사업 영역의 규제 정도에 따라 이런 해결책들을 도입하기 위한 노력과 시간은 천차만별이다. 결국 이런 내용을 참고 삼아, 본인만의 문제 해결 활동을 해야한다.

개발자로서 우리는 종종 "이상적인 개발 환경"에 대한 로망을 가지고 있다. 하지만 현실의 제약 속에서 우리는 어떤 것들을 실현할 수 있을까? 중요한 것은 "문제를 위한 문제"를 만들지 않는 것이다. 예를 들어, 단순히 최신 기술을 도입하고 싶다는 이유로 안정적으로 운영되고 있는 시스템을 뜯어고치자고 제안하는 것은 현명하지 않다.

KPI를 통한 업무 방향성 도출

만약 정말 중요하다고 생각하는 기술적 과제가 있다면, 이를 실현하기 위한 단계적 접근이 필요하다. 예를 들어 Grafana 를 통한 로그 수집 시스템 도입이 필요하다고 판단된다면:

1. 현재 발생하는 문제점을 수치화
2. 조직의 문제와 연결되는 KPI와 개선 목표 제시

이런 식의 단계적 접근이 불가능하다고 판단된다면, 어쩌면 다른 환경을 찾아야 할 시기라는 신호일 수 있다. 혹은 조직을 설득할 더 나은 방법을 고민해볼 기회일 수도 있다.

비즈니스 관점의 진짜 문제 vs 기술적 과제

예를 들어 내가 백화점 SI/SM 환경에서 겪었던 일화가 있다. MyBatis로 구성된 시스템을 처음 보았을 때, 나는 JPA의 편리함을 알고 있었기에 무작정 이것을 JPA로 전환하자고 제안했었다. 당시 JPA를 살짝 맛보기로 사용해본 경험에 취해있었던 것이다. 하지만 이는 매우 순진한 생각이었다. 트랜잭션 관리 방식의 변경, 복잡한 쿼리들의 JPA 변환, 기존 코드와 동일한 동작을 보장하기 위한 검증 등 실질적으로 수반되어야 할 문제들을 전혀 고려하지 않은 제안이었다. 새로운 기술 도입은 단순히 코드를 바꾸는 것 이상의 복잡한 과정이며, 이는 현재 시스템의 안정성을 해칠 수 있는 위험이었다.

지금 생각해보면, JPA 도입을 제안하기 전에 다음과 같은 KPI를 먼저 정립했어야 했다. 예를 들자면 아래와 같다:

1. 현재 시스템에 대한 문제 정량화

• 현 백오피스 솔루션 내 반복적인 CRUD 코드가 전체 코드의 약 N%를 차지
• 현 백오피스 솔루션의 신규 고객사 적용 시 DB 연동 코드 작성에 평균 N%의 시간 소요

2. KPI를 통한 JPA 도입 필요성에 대해 역설

• 솔루션의 신규 고객사 적용의 맨먼스를 KPI로 정하고 이를 얼마만큼 감소시킬 수 있는지 표현
• 이 KPI를 조직의 목표로 정하기 위해 설득

이런 식으로 KPI로 설득했다면, "신규 개발되는 독립적인 기능부터 JPA 적용"과 같은 파일럿 프로젝트를 진행하는 등의 절충안이라도 진행할 수 있었을 것 같다.

마치며

꼭 경력기술서를 잘 쓰기 위해서 KPI를 고민해야 한다기 보다는, 나의 성과를 타인에게 설득력 있게 표현하기 위한 방식으로써 KPI를 고민해보면 좋을 것 같다. 내 기준으로는 생각보다 같은 개발 조직 내에서도 합의된 업무 방향을 갖는다는 것이 쉽지가 않았다. KPI의 설정 만으로 그것이 해결되지는 않겠지만, 이런 지표를 다같이 고민하고 정해보는 시간을 가진다면 구성원이 공감하는 방향으로 성과를 낼 수 있을 것이라 본다.

만약 올해 이런 KPI에 대해 아직 고민해보지 않았다면, 몸 담고 있는 조직의 진짜 문제와 연결되는 KPI를 만들고 이를 기준으로 일해보면 어떨까?