엔지니어의 리더십: 지표, 보이지 않는 것을 보이게 만드는 일

작성자:

예전에 소프트웨어의 중요성이 한창 부각되던 시절이 있었습니다. 자연스럽게 회사의 경영층에서는 개발 중인 소프트웨어의 수준이 어떤지, 그 품질을 직접 확인하고 싶다는 요구가 증가했습니다. 제가 속한 팀은 오랜 고민 끝에 몇 가지 지표를 선정해서 소프트웨어의 품질을 가시화했습니다. 비전문가의 눈높이에 맞춘 지표였기 때문에 소프트웨어 개발자들이나 실무자들은 완전히 동의하지 않았습니다. 그런데도 그 지표는 얼마 전까지 사내 표준으로 채택되어 오랜 기간 사용되었습니다.

사실 소프트웨어는 눈으로 볼 수 없고, 구조가 무척 복잡하기 때문에 숫자 몇 개로 전체 품질을 보여준다는 것은 말이 안 됩니다. 그럼에도 불구하고 숫자 몇 개로 구성된 지표가 사용된 이유는 단순했기 때문입니다. 가시화는 대상을 있는 그대로 모든 걸 보여주는 일이 아니라, 보여줄 것과 보여주지 않을 것을 정하는 일입니다. 보여줄 것을 선정해서 대표 지표를 만들고, 나머지는 부가 정보로 남겨두고 필요할 때만 꺼내볼 수 있게 만들어야 합니다.

이 글에서는 소프트웨어 품질을 예로 들어 가시화가 왜 어려운지, 지표를 고를 때 어떤 함정에 빠지는지, 그리고 AI가 들어오면서 기존 기준이 어떻게 흔들리는지를 함께 정리해 보겠습니다.

목차

소프트웨어는 보이지 않는 것

소프트웨어의 가시화는 소프트웨어 공학 분야의 오래된 숙제입니다. 소프트웨어는 분명히 존재하지만 눈으로 볼 수 없습니다. 그래서 설계를 하다 보면 수많은 다이어그램이 필요합니다. 이 다이어그램들은 모두 같은 대상을 바라보지만, 보고 싶은 관점에 따라 서로 다른 뷰(View)를 표현합니다.

가시화해야 할 대상은 크게 두 종류입니다. 하나는 여기저기 흩어져 있는 정보이고, 이때 가시화는 모아서 압축하는 일이 됩니다. 다른 하나는 복잡하게 얽힌 구조인데, 이때는 관계를 풀어서 구조화하는 일이 됩니다. 보통 전자는 대시보드로 보여주고, 후자는 다이어그램으로 표현합니다.

어느 쪽이든 뷰는 일종의 필터입니다. 필터에는 의도에 따라 통과하는 정보와 막히는 정보가 공존합니다. 가령 결함 밀도라는 뷰는 결함만 통과시키고 나머지 속성은 전부 막습니다. 그래서 가시화에서 정보가 줄어드는 것은 당연한 일입니다.

소프트웨어 품질을 정의한 국제 표준 ISO/IEC 25010도 같은 목적을 가지고 있습니다. 이 표준은 소프트웨어 품질을 기능 적합성, 성능 효율성, 호환성, 상호작용 역량, 신뢰성, 보안성, 유지보수성, 유연성, 안전성의 아홉 가지 특성으로 나눕니다. “품질을 높이자”는 모호한 말을 측정 가능한 기준으로 바꾸기 위해서입니다. 표준의 효과는 정확성 자체가 아니라, 여러 개발 조직과 사업 조직이 품질을 같은 언어로 이야기하게 만드는 데 있습니다.

가로등 아래의 반지

지표를 고를 때 사람들이 흔히 하는 실수가 있습니다. 측정해야 할 지표가 아니라 측정 가능한 지표를 찾는 것입니다.

밤길에 반지를 잃어버린 사람이 가로등 아래를 열심히 뒤지고 있습니다. 지나가던 사람이 여기서 잃어버렸느냐고 묻자, 저쪽 어두운 데서 잃어버렸지만 이곳이 밝아서 여기에서 찾는다고 답합니다. 오래전부터 전해지던 이야기인데, 데이비드 프리드먼이 2010년에 이것을 가로등 효과라고 이름 붙였습니다. 찾기 쉬운 곳만 뒤지는 ‘관찰 편향’을 가리킵니다.

지표에서도 같은 일이 벌어집니다. 품질을 측정하는 것은 어려우니 코드 라인 수와 커밋 수를 셉니다. 효과가 잡히지 않으니 투입 비용을 셉니다. 목적에 맞는 필터를 고르는 것이 아니라, 이미 손에 쥔 필터에 목적을 맞추는 셈입니다. 보통 지표를 선정하는 과정에서 나오는 불만은 대개 여기서 비롯됩니다.

중요한 것은 본질을 드러내면서 표현을 단순하게 만든 지표와 측정하기 쉬운 것을 본질인 척 내세운 지표는 다르다는 점입니다. 전자의 경우 필요한 압축 과정이지만 후자의 경우 측정해야 할 지표를 측정 가능한 지표로 대체한 것입니다. 당연히 단순함 자체는 문제가 아니고, 지표가 실제로 무엇을 드러내는지가 문제입니다.

지표의 두 얼굴: 과정지표 vs 결과지표

지표는 과정지표와 결과지표로 나뉩니다. 목적이 다르기 때문에 둘 다 써야 합니다.

일반적으로 결과지표가 중요하지만 측정 시점이 늦습니다. 시장 결함 건수, 장애 발생률, 평균 복구 시간은 모두 품질이 이미 나빠진 뒤에 드러납니다. 측정은 쉽고 해석에 논란도 적지만, 숫자가 보일 때는 이미 손쓸 시점이 지나 있는 경우가 많습니다.

과정지표는 이른 시점에 측정 가능하지만 결과를 보장하지 않습니다. 코드 리뷰 건수, 코드 결함 분석 시간, 테스트 케이스 커버리지, 빌드 실패율은 결과가 나오기 전에 개선할 방향을 알려줍니다. 하지만 결과와의 구체적인 인과관계가 느슨하고, 과정지표를 목표로 삼는 순간 지표 측정의 목적이 왜곡되기 쉽습니다.

따라서 개발을 진행하는 중에는 과정지표를 통해 방향성을 수립하고 시장 출시 후에는 결과지표를 관리해야 합니다.

DORA 연구도 같은 구조를 권장합니다. DORA는 소프트웨어 관련 성과를 다섯 가지 지표로 측정합니다. ‘처리량’을 보는 변경 리드타임, 배포 빈도, 실패 배포 복구 시간이 있고, ‘불안정성’을 보는 변경 실패율과 배포 재작업률이 있습니다. 원래는 네 가지였는데 현재는 다섯 가지 체계로 바뀌었습니다.

흥미로운 점은 DORA가 이 지표들을 선행과 후행 어느 한쪽으로 규정하지 않는다는 것입니다. 개발 관점에서는 결과를 반영하는 후행 지표이지만, 조직 성과 관점에서는 앞을 내다보는 선행 지표가 됩니다. 무엇을 기준으로 보느냐에 따라 같은 숫자의 성격이 달라집니다. 그래서 DORA는 코드 리뷰 소요 시간이나 테스트 품질처럼 더 앞에서 움직이는 지표를 따로 두라고 안내합니다. 과정으로 관리하고 결과로 검증하는 것입니다.

AI 시대의 지표

새로운 기술이 들어오면 판단의 기준도 바뀝니다. 측정 대상이 바뀌었는데 측정 방식을 똑같이 하면 측정되는 숫자는 남지만 의미 없는 숫자가 됩니다. 지금 AI가 다양한 분야에서 그런 상황을 만들고 있습니다.

첫째, 기존의 지표들은 사람의 ‘노력’을 측정했습니다. 코드 라인 수, 커밋 수, 리뷰 시간은 모두 사람이 얼마나 일했는지를 측정하는 값이었습니다. 우리는 사람이 신중하게 많이 일하면 좋은 결과가 나온다는 가정 위에서 사람의 노력을 품질의 선행 신호로 써 왔습니다.

하지만 AI의 등장으로 이러한 가정이 깨졌습니다. AI의 ‘노력’을 측정하는 일은 무의미합니다. 결국 투입된 노력과 만들어진 산출물의 인과관계가 끊어지면, 이를 측정한 지표는 잡음일 뿐입니다. AI가 만든 결과를 사람의 노력 지표로 재면 안 되는 이유입니다.

둘째, 많은 경우 측정해야 할 과정 자체가 사라집니다. 기존에는 설계, 구현, 리뷰, 테스트가 각각 단계로 존재했고, 단계별로 필요한 지표를 측정할 수 있었습니다. 그런데 AI는 이 단계들을 한 번에 통과합니다. 요구사항을 프롬프트로 넣으면 실행 가능한 코드가 나옵니다. 기존의 필터를 단순히 갈아 끼우는 문제가 아니라, 필터를 적용할 자리가 없어지는 문제입니다.

그런데 사실은 과정이 없어진 것이 아니라 옮겨간 것입니다. AI가 아무리 코드를 만드는 과정을 대신한다 해도 사람이 직접 판단해야 하는 지점은 남게 됩니다. 무엇을 시켰는지, 무엇을 받아들였는지, 무엇을 고쳤는지를 판단 지점에서 측정해야 합니다. 필터는 이제 작업량이 아니라 이 판단 지점에 걸어야 합니다.

AI의 효과 자체를 가시화하는 일은 여전히 어렵습니다. AI가 무엇을 잘하고 무엇을 못하는지는 대부분 알지만, 그래서 무엇이 얼마나 좋아졌는지를 말하기는 어렵습니다. IBM이 2025년 4분기에 정리한 조사에서 생산성 향상을 체감한다는 응답은 79%였던 반면, 투자 대비 효과를 자신 있게 측정할 수 있다는 응답은 29%에 그쳤습니다. 포레스터의 2026년 전망도 AI 의사결정자 가운데 15%만이 실제 수익성 개선을 보고했고, 3분의 1이 채 되지 않는 인원만 AI의 가치를 손익과 연결할 수 있다고 지적합니다.

그래서 논의는 결국 비용으로 수렴합니다. 이것은 게으름이라기보다, 가장 늦게 나오지만 가장 쉽게 받아들여지는 숫자가 비용이기 때문입니다. 가로등 아래에서 반지를 찾는 장면이 한 번 더 반복되는 셈입니다.

좋은 대시보드란?

관리 단계의 가시화는 결국 대시보드를 만드는 일에서 시작해서 대시보드로 끝납니다. 그래서 대시보드를 어떻게 구성할 것인가가 실질적인 질문이 됩니다.

가장 흔한 실패는 우선순위 없이 전부 늘어놓는 것입니다. 매출, 결함, 진척도, 만족도가 한 화면에 평평하게 놓이면 어느 것도 책임을 지지 않습니다. 필터를 여러 개 걸어도 중요한 신호를 알아채기 어렵습니다. 위젯이 늘어날수록 보이는 것은 많아지지만 판단은 어려워집니다.

그래서 좋은 대시보드는 평평하지 않고 우선순위가 있습니다. 중요한 지표 하나를 대표로 맨 위에 배치하고, 그 아래 그 숫자를 움직이는 보조 지표들을 붙입니다. 대표 숫자가 바뀌면 아래를 따라 내려가며 원인을 찾습니다. 션 엘리스가 제안한 북극성 지표 방식도 같은 구성입니다. 제품이 고객에게 주는 핵심 가치를 가장 잘 담아내는 지표 하나를 꼭대기에 두고, 그것을 구성하는 입력 지표들을 아래에 배치합니다.

이렇게 보면 앞서 지표를 중심으로 한 갈등도 다르게 해석할 수 있습니다. 비전문가를 위한 지표와 실무자를 위한 지표는 서로 충돌한다기보다는 상호보완적인 관계입니다. 경영층은 대표 숫자를 보고, 실무자는 그 숫자를 떠받치는 지표를 봅니다. 같은 대상을 보되 각자에게 필요한 만큼 걸러서 보는 것입니다.

맺음말

완벽한 필터는 없습니다. 모든 필터는 거른 만큼 보여주고, 막은 만큼 가립니다. 그래서 필요한 필터가 무엇인지 파악하는 일이 무척 중요합니다. 당연히 그 필터를 통과한 정보를 읽을 고객이 누구인가가 가장 중요한 기준일 것입니다. AI 시대에도 모든 정보를 한눈에 볼 수 있는 방법이 없는 건 마찬가지입니다. 새로운 기술과 바뀐 기준에 따라 어떤 필터가 아직 쓸모 있는지를 구분하고 필요한 필터를 새로 만드는 일이 중요합니다.

제가 속했던 팀이 개발한 지표가 오랜 기간 사용된 이유도 여기에 있다고 생각합니다. 모든 정보를 잘 전달해서가 아니라 함께 볼 수 있을 만큼 단순했기 때문입니다. 지표의 우열은 지표를 생산하는 쪽과 소비하는 쪽이 얼마나 쉽게 합의하는가에서 갈리는 것 같습니다.

보이지 않는 것을 보이게 만드는 일은 함께 볼 수 있는 기준을 만드는 일입니다.

ChulJoo Kim (김철주)

※ 참고문헌

ckarch.kr © 2026 is licensed under CC BY-NC-SA 4.0 CC BY NC SA

댓글 남기기