애매한 문제를 제대로 정의한다는 것
"좋아진 것 같아요"에서 "좋아졌다"로 가는 과정에 대하여
이번 포스팅에서는 현실에 존재하는 애매모호한 문제들을 해결하는 방법에 대해서 이야기해보려고 한다.
본론에 들어가기 앞서, 한번 여러분이 지난 분기에 가장 공들여서 한 일을 하나 떠올려보자. 몇 주를 들인 리팩토링일 수도 있고, 팀에 새로 들인 도구일 수도 있고, 야심 차게 시작한 개선 프로젝트일 수도 있다. 그 일을 떠올린 채로 이 질문에 답해보자.
그 일로 풀려고 했던 문제는 정확히 무엇이었고, 그 문제가 실제로 줄어들었다는 건 무엇으로 보여줄 수 있는가?
보통 이런 질문을 던지면 “코드가 너무 복잡해서 리팩토링을 끝냈어요”, “생산성이 좋아질 것 같아서” 같은 말이 먼저 나오는데, 이건 실질적인 문제를 해결했다기보다 해결했다는 느낌에 가깝다. 분명 열심히 했고 무언가 나아진 느낌도 드는데, 명확하게 “무엇 때문에 뭐가 좋아졌다”라고 말하기는 어려운 것이다.
이런 모습은 개인의 일에서만 보이는 게 아니다. 조직의 목표 문서를 들여다봐도 해야 할 일은 빼곡하게 적혀 있는데, 그 일들이 어떤 문제를 풀기 위한 것인지, 풀렸다는 건 어떻게 알 수 있는지는 비어 있는 경우가 많다. 필자도 여러 조직의 목표 문서를 함께 다듬으면서 비슷한 질문을 꽤 여러 번 던졌는데, 돌아보면 그 질문들은 대부분 네 가지로 모였다.
문제를 제대로 정의하는 역량은 개발자라는 직군을 떠나, 일을 잘하는 사람이라면 누구나 갖춰야 할 기본 소양에 가깝다. 그런데 필자가 지켜본 바로는 이 역량을 몸에 익힌 사람이 생각보다 많지 않았다. 열심히 일하는 사람은 많아도, 그 일이 어떤 문제를 풀고 있는지 제대로 설명할 수 있는 사람은 드물다는 것이다.
게다가 문제를 정의하는 역량만큼 한 번 익혀두면 쓸모가 넓은 역량도 흔치 않다. 코드를 고치든, 새 도구를 들이든, 팀의 분기 목표를 세우든 일의 모양은 달라도, 무엇이 문제이고 무엇이 나아져야 하는지를 먼저 정의하는 과정은 똑같이 적용되기 때문이다.
이번 포스팅에서는 그 네 가지 질문을 하나씩 따라가면서 문제를 정의하고 해결한다는 게 어떤 과정인지를 정리해보고, 마지막에는 이 역량을 어떻게 키울 수 있을지도 함께 생각해보려고 한다. 예시는 대부분 필자에게 가장 익숙한 개발 조직에서 가져왔지만, 과정 자체는 어느 일에나 그대로 적용된다.
다만 모든 일에 네 질문을 전부 던질 필요는 없다. 변수 이름 하나를 바꾸거나 함수 하나를 분리하는 작은 리팩토링까지 문제 정의부터 하라고 하면, 문제를 정의하는 비용이 문제 자체의 비용보다 커진다. 제프 베이조스(Jeff Bezos)는 2015년 주주서한에서 결정을 되돌릴 수 없는 것과 되돌릴 수 있는 것으로 나누고, 되돌릴 수 있는 결정은 가볍고 빠르게 내려야 한다고 말한 적이 있다. 이 글에서 이야기하는 과정은 몇 주 이상의 시간이 들고, 되돌리기 어렵고, 다른 사람의 시간까지 쓰는 일에 쓸 때 가장 가치가 있다.
이건 무슨 문제를 해결하는 건가요?
도입부의 질문에 선뜻 답하기 어려웠다면, 그 이유는 대개 일을 시작할 때 적은 첫 문장에 있다. 우리는 생각보다 자주 문제 대신 할 일을 적고, 그 할 일이 끝나면 일도 끝났다고 여긴다. 그렇다면 할 일과 문제는 정확히 무엇이 다르고, 우리는 왜 이렇게 자연스럽게 할 일부터 적게 되는 걸까?
할 일과 문제는 다르다
먼저 개발 조직에서 흔히 들을 수 있는 세 개의 문장을 나란히 놓고 보자.
결제 모듈 코드가 너무 복잡한 것 같아요. 이번 분기에 리팩토링하면 좋겠어요.
LCP p99가 너무 높아요. 2초 이하로 줄여봅시다.
이번 하반기 목표는 조직의 생산성을 높이는 것입니다.
세 문장 모두 미팅에서 들었다면 자연스럽게 고개를 끄덕일 만한 문장들이다. 그런데 가만히 들여다보면 이 문장들에는 정작 문제가 적혀 있지 않다.
처음 두 문장은 목표는 없고 수단만 설명하고 있다. 리팩토링이나 성능 개선은 어떤 문제를 해결하기 위한 수단일 뿐인데, 이 문장들에는 그 문제가 무엇인지가 적혀 있지 않다.
반대로 마지막 문장은 너무 추상적이다. “생산성을 높인다”는 마치 좋은 목표처럼 보이지만, 무엇이 얼마나 낮아서 어떤 상태가 되어야 하는지는 설명하지 않는다. 생산성을 높여보자는 것은 결국 지금 생산성이 낮다는 것을 의미하는데, 생산성이라는 것이 무엇으로 정의되는지, 왜 낮다고 하는 것인지와 같은 부분이 전부 빠져 있다.
이렇게 나이브하게 문제를 정의하는 모습은 개발자들에게만 한정되어 나타나는 것도 아니다. “상세 페이지를 리뉴얼하자”는 문장에는 수단만 있고, “브랜드 인지도를 높이자”는 문장에는 방향만 존재하는 것처럼 말이다.
결국 어떤 문장이든 바로 지금 “실제로 무슨 일이 일어나고 있는지에 대한 관찰”이 빠져 있다고 볼 수 있다.
필자는 문제를 꽤 건조하게 정의하는 편이다. 문제란 기대하는 상태와 실제 상태 사이의 차이다. 이렇게 정의하면 문제를 말하려면 적어도 두 개의 상태가 필요해진다. 지금 어떤지와 어떠해야 하는지다. 이건 비단 필자만 쓰는 방식은 아니다. 토요타도 문제를 “있어야 할 모습과 지금 모습의 차이”로 정의하고, 그 차이를 줄여가는 과정을 개선이라고 불러온 것으로 잘 알려져 있다.
이게 사소한 말장난처럼 들릴 수 있는데, 이 차이가 나중에 “이건 왜 한 거예요?”라는 질문에 대답할 수 있는지를 거의 결정한다. 할 일로 시작한 작업은 끝난 뒤에도 할 일로만 설명된다. “리팩토링을 했습니다”, “AI 도구를 도입했습니다”는 사실이지만, 그게 어떤 차이를 줄였는지는 처음부터 정의된 적이 없으니 설명할 방법도 없다. 그러다 보니 “좋아진 것 같아요”라는 대답이 나오게 되는 것이다.
수단과 방향부터 떠오르는 이유
그렇다면 우리는 왜 이렇게 자연스럽게 수단이나 막연한 방향부터 떠올리게 되는 걸까?
노벨 경제학상을 받은 심리학자 대니얼 카너먼(Daniel Kahneman)은 이런 경향을 “보이는 것이 전부다”라는 말로 설명한다. 사람은 눈앞에 있는 정보만으로 그럴듯한 이야기를 빠르게 완성하고, 거기에 빠진 정보가 있을 가능성은 잘 따지지 않는다는 것이다. 코드를 들여다보고 있을 때 눈앞의 정보는 대부분 코드이니 원인도 해결책도 코드에서 찾게 되고, 조직 전체를 내려다볼 때 눈앞의 정보는 대부분 막연한 인상이니 목표도 그만큼 크고 흐릿해진다.
여기에 또 하나의 힘이 작용하는데, 바로 할 일을 쳐내는 데서 오는 진척감이다. 문제를 정의하는 일은 눈에 보이는 결과물이 잘 남지 않는다. 하루 종일 고민해도 티켓 하나 닫히지 않는다. 반면 리팩토링은 파일이 바뀌고, PR이 올라가고, 머지 버튼이 눌린다. (초록색 머지 버튼만큼 확실한 도파민도 드물다) 일을 하고 있다는 감각은 후자가 훨씬 강하기 때문에, 문제를 충분히 이해하기 전에 해결 모드로 뛰어드는 일이 반복된다.
그 문제가 실제로 존재한다는 건 어떻게 알 수 있나요?
할 일과 문제가 다르다는 걸 알았다면, 다음은 그 문제가 정말로 존재하는지 확인할 차례다. 문제는 대부분 “~한 것 같다”는 느낌에서 시작하는데, 이 느낌을 다른 사람과 공유할 수 있는 현상으로 바꾸는 게 이 단계에서 할 일이다. 그리고 현상을 제대로 적고 나면, 그 문제가 지금 풀어야 할 만큼 큰지도 함께 보이기 시작한다.
직감은 출발점일 뿐이다
앞에서 수단부터 떠올리는 경향을 이야기했지만, 그렇다고 “코드가 복잡한 것 같다”는 직감을 버려야 한다는 이야기는 아니다. 필자는 오히려 대부분의 좋은 문제 정의가 이런 직감에서 출발한다고 생각한다. 매일 그 코드를 만지는 사람이 뭔가 이상하다고 느꼈다면, 거기에는 보통 무언가가 있다.
문제는 직감 그 자체보다 직감을 그대로 문제로 확정해버리는 데 있다. 직감은 가설이고, 가설은 확인되기 전까지 가설일 뿐이다. 그렇다면 확인은 어떻게 해야 할까?
가장 먼저 해볼 수 있는 건 그 직감이 사실이라면 실제로 내 주변에서 어떤 현상이 관찰되어야 하는지를 떠올려보는 것이다. 결제 모듈이 정말로 복잡해서 문제라면, 아마 이런 것들이 관찰될 가능성이 높다.
- 결제 관련 기능을 추가할 때 처음 예상한 일정보다 오래 걸리는 일이 잦다
- 결제 모듈을 수정한 뒤에 다른 곳에서 버그가 터지는 일이 반복된다
- 결제 모듈 PR의 리뷰가 다른 PR보다 유난히 오래 걸리거나 코멘트가 많다
- 새로 온 사람이 결제 모듈에 대해 질문하는 빈도가 높다
이 중 하나라도 실제로 관측이 되었고 얼마나 발생하는지 세어볼 수 있다면 직감은 현상으로 바뀐다. 지난 분기 결제 관련 티켓의 예상 일정과 실제 일정을 비교해보거나, 장애 회고 문서에서 결제 모듈이 원인으로 언급된 횟수를 세어보는 식이다. 대단한 분석이 필요한 게 아니라, 대부분 한두 시간이면 확인할 수 있는 것들이다. (요즘에는 LLM 돌리면 진짜 금방 뽑아볼 수 있다)
여기서 한 가지 더 중요한 건, 실제로 관측해보기 전에 미리 어떤 결과가 나오면 내 직감이 틀렸다고 인정할지를 먼저 정해두는 것이다. 이걸 정해두지 않으면 어떤 숫자가 나와도 직감을 지지하는 쪽으로 편향적인 해석을 하게 된다. 사람에게는 원래 자기가 믿는 것을 지지하는 정보를 더 잘 발견하는 경향이 있기 때문이다.
예를 들어 결제 모듈 예시라면 이런 식으로 정해볼 수 있다.
“지난 분기에 결제 모듈을 건드린 작업이 두 건 이하라면, 코드가 복잡하더라도 지금 풀어야 할 문제는 아니다.”
이 조건은 꽤 중요한 사실을 담고 있다. 아무도 건드리지 않는 복잡한 코드는 생각보다 비용을 만들지 않기 때문이다. 복잡함의 비용은 대부분 그 코드를 바꿔야 할 때 발생하기 때문에, 바뀔 일이 없는 코드라면 복잡하든 아니든 비즈니스에는 큰 차이가 없을 가능성이 크다.
만약 이렇게 기준을 정해둔 뒤에 실제로 관측을 해보니, 지난 분기 결제 관련 기능 작업 8건 중 예상 일정 안에 끝난 건 3건뿐이었고, 일정을 넘긴 5건 중 4건은 두 배 이상 걸렸다고 해보자.
그러면 결제 모듈을 건드린 작업이 8건이나 되니 반증 조건에도 걸리지 않으니, 이제 “복잡한 것 같다”라는 직관과 느낌은 누구나 확인할 수 있는 현상이 된다.
즉, 직감을 관찰로 확인하는 과정은 직감이 맞는지 틀리는지만 가려주는 게 아니다. 직감이 맞더라도 그게 지금 풀 가치가 있는 문제인지까지 같이 드러내준다.
해석 말고 현상을 적는다
직감이 관찰로 확인됐다면 이제 지금 상태를 적을 차례다. 흔히 As-Is라고 부르는 부분인데, 여기서 가장 자주 하는 실수는 관찰한 현상 대신 해석을 적는 것이다.
앞의 결제 모듈로 보면, “결제 모듈의 코드 품질이 낮다”는 해석이고 “지난 분기 결제 관련 작업 8건 중 5건이 예상 일정을 넘겼다”는 현상이다.
해석은 사람마다 다르게 할 수 있어서, “코드 품질이 낮다”는 말에 누군가 “제가 보기엔 괜찮던데요”라고 하면 대화는 거기서 멈춘다. 반면 “8건 중 5건”에 동의하지 않는 사람이 있다면 같이 티켓을 열어보면 된다.
디자인 시스템도 마찬가지다. “UI가 제각각이다”라는 해석보다 “같은 역할을 하는 버튼 스타일이 서비스 안에 23가지 있고, 지난 분기 디자인 QA 이슈의 40%가 스타일 불일치였다”는 현상이 훨씬 많은 것을 말해준다.
그렇다고 숫자가 들어 있기만 하면 현상이 되는 건 아니다. 성능 개선 이야기를 할 때 이런 문장을 자주 보게 된다.
A 서비스의 LCP p99가 3.2초로 높다.
이 문장에는 명확한 숫자가 있고, 평균이 아니라 가장 느린 1% 구간까지 보고 있다는 점에서 꽤 좋은 지표를 고른 것처럼 보인다.
그런데 이 문장을 읽고 나서도 여전히 알 수 없는 게 있다. 그 1%에 속한 사용자가 누구인지, 그들이 어떤 페이지에서 무엇을 하려다 막히고 있는지, 그 결과로 무엇이 일어나지 않고 있는지다. 이게 빠진 채로 서비스 전체의 p99를 2초로 줄이자는 목표를 세우면, 정작 중요한 페이지보다 고치기 쉬운 페이지부터 손대기 쉽다.
같은 상황을 현상으로 적으면 이렇게 될 수 있다.
상품 상세 페이지는 전체 주문의 60%가 거쳐 가는 페이지인데, 이 페이지의 LCP p99가 3.8초다. 첫 화면이 3초 넘게 걸린 방문은 그렇지 않은 방문보다 구매 전환율이 절반 수준이고, 이런 방문이 하루 2만 건 정도 된다.
이 문장에는 어디서(주문의 60%가 거쳐 가는 페이지), 무엇을 겪고 있고(첫 화면이 3초 넘게 걸린다), 그래서 무엇을 잃고 있는지(전환율이 절반으로 떨어지는 방문이 하루 2만 건)가 들어 있다.
특히 마지막 부분이 중요하다. 문제가 실제로 존재하는지만이 아니라, 이 문제가 지금 풀어야 할 만큼 큰지까지 답해주기 때문이다. 같은 p99 3.8초라도 하루 방문이 몇백 건뿐인 설정 페이지라면 다른 급한 일에 밀려도 괜찮을 가능성이 크다.
문제는 대부분 여러 개가 동시에 존재하고, 우리가 가진 시간은 한정되어 있다. 그래서 현상을 적을 때는 그 문제가 무엇을 얼마나 잃게 만들고 있는지까지 같이 적어야, 여러 문제 중에서 무엇부터 풀지를 고를 수 있다.
필자는 As-Is를 적고 나면 한 가지를 꼭 확인해본다. 이 문장을 처음 보는 동료가 읽었을 때 필자와 같은 현상을 떠올릴 수 있는가? 숫자가 있든 없든, 어디서 무엇을 겪고 있고 그게 얼마나 큰지가 공유되어야 그 다음 단계인 목표에 대해서도 같은 그림을 그릴 수 있다.
왜 하필 그 방법인가요?
문제가 실제로 존재한다는 걸 확인했다면, 이제 무엇을 할지 정할 차례다. 그런데 여기서 바로 해결책으로 뛰어들면 앞에서 본 할 일 중심의 문장으로 되돌아가기 쉽다. 방법을 고르기 전에 먼저 어떤 상태가 되어야 하는지를 적고, 지금과 그 상태 사이의 차이가 왜 생기는지를 따라가봐야 한다. 그래야 “왜 하필 그 방법인가요?”라는 질문에 답할 수 있다.
목표는 결과로 적는다
지금 상태를 적었다면 이제 어떤 상태가 되어야 하는지를 적어야 한다. 흔히 To-Be라고 부르는 부분이고, 필자가 드리는 피드백 중 가장 많은 비중을 차지하는 곳이기도 하다. “그래서 뭐가 어떻게 좋아진다는 건가요?”라는 질문이 대부분 여기서 나온다.
예를 들어 요즘 많은 조직들이 관심을 가지고 있는 AI 도구 도입을 한번 살펴보자. 보통 새로운 도구를 조직에 도입할 때 목표를 적어보라고 하면, 이런 식의 문장이 나오는 경우가 많다.
- 전사 개발자의 AI 코딩 도구 도입률 90% 달성
- 주간 활성 사용자 비율 70% 이상 유지
- AI가 생성한 코드가 전체 커밋의 30% 이상
이 문장들은 명확하고 측정도 쉽지만, 전부 우리가 무엇을 했는지를 서술하는 것 이상도 이하도 아니다. 필자는 이걸 산출물과 결과로 나눠서 본다. 산출물은 우리가 만들거나 바꾼 것이고, 결과는 그 산출물 때문에 사람들의 행동이나 상황이 어떻게 달라졌는지다. 목표에 적어야 하는 건 산출물보다 결과에 더 가깝다.
열심히 도입을 시켜서 최종적으로 도입률 90%를 달성했다고 해보자. 그래서 무엇이 좋아졌을까?
결국 이 질문에 제대로 답하려면 처음 우리가 정의했던 “AI 도구로 무슨 문제를 풀려고 했는지”로 돌아가야 한다. 새로운 도구를 도입하는 것은 문제를 풀기 위한 수단이지, 그 수단 자체가 목표가 될 수 없기 때문이다.
반대로 문제를 제대로 정의했다면 목표는 자연스럽게 결과의 모양이 된다. 예를 들어 “라이브러리 메이저 버전 업데이트 같은 반복적인 마이그레이션 작업이 분기마다 팀 가용 시간의 20%를 잡아먹고 있다”는 현상을 관측했다면, 목표는 “마이그레이션에 드는 시간을 절반으로 줄이고, 그렇게 확보한 시간으로 분기당 제품 이터레이션 횟수를 늘린다”가 될 수 있다. AI는 이 목표를 이루기 위한 여러 수단 중 하나일 뿐이다.
필자가 본 사례 중 이 일이 잘 풀린 경우는 대부분 도구보다 지표를 먼저 정했다. 도입하기 전에 개발 생산성과 제품 품질을 각각 무엇으로 볼지 정의해두고, 도구를 넓혀가는 동안 그 지표들이 어떻게 움직이는지를 지켜보는 식이다. 이렇게 하면 도입률은 목표가 아니라 수단을 제대로 활용하고 있는지 확인하는 중간 점검 지표가 된다.
산출물은 우리가 통제할 수 있어서 적기 쉽고, 달성 여부도 명확하다. 그래서 목표 문서에 산출물이 들어가는 건 자연스러운 일이다. 문제는 산출물이 달성됐다고 해서 처음에 정의한 차이가 줄어든다는 보장이 없다는 것이다.
필자가 이전에 쓴 리더가 정말 신경 써야 할 것은 생산성이 아니다에서 AI로 인해 산출물은 빠르게 늘어나는데 그걸 검증하고 이해하는 역량은 조용히 줄어들 수 있다는 이야기를 한 적이 있는데, 도입률 같은 산출물 지표만 보고 있으면 이런 변화는 영영 보이지 않는다.
리팩토링도 마찬가지다. “결제 상태 관리를 한 곳으로 모은다”는 산출물이고, “결제 관련 작업이 처음 예상한 일정 안에 끝나는 비율을 3/8에서 6/8 수준으로 높인다”는 결과다. 그리고 여기까지 적고 나면 리팩토링이 비즈니스와 어떻게 연결되는지도 비로소 설명할 수 있게 된다. 결제 전환율 실험을 자주 돌리는 조직이라면, 결제 관련 작업이 예상 일정 안에 끝난다는 건 같은 기간 안에 결제 실험을 더 많이, 더 예측 가능하게 돌릴 수 있다는 뜻이 된다.
필자는 리팩토링의 비즈니스 가치가 대부분 이런 식으로 드러난다고 생각한다. 리팩토링 자체가 매출을 만들지는 않지만 앞으로 일어날 변경의 속도와 안정성을 바꾼다. 그래서 리팩토링의 가치를 설명하려면 앞으로 그 코드에 어떤 변경이 얼마나 일어날 예정인지를 같이 이야기해야 한다. 이 연결을 설명하지 못하면 리팩토링은 개발자들의 취향 문제로 받아들여지기 쉽고, 반대로 이 연결을 설명할 수 있다면 리팩토링은 제품팀이 먼저 요청하는 일이 될 수도 있다.
As-Is와 To-Be, 차이는 왜 생기는가
지금 상태와 되어야 할 상태를 적었으면 그 사이의 차이가 보인다. 이제 그 차이가 왜 생기는지를 물어야 한다. 이 단계를 건너뛰고 바로 해결책으로 가는 경우가 많은데, 필자는 오히려 이 단계에서 처음 떠올린 해결책이 틀렸다는 걸 알게 되는 경우를 꽤 자주 봤다.
결제 모듈부터 보자. 일정을 넘긴 5건의 회고를 모아보면, 결제 상태를 바꾸는 코드가 여러 곳에 흩어져 있어서 변경 영향 범위를 파악하는 데 시간이 오래 걸렸다는 이야기가 공통으로 나온다. 여기서 한 번 더 이유를 물어보면, 영향 범위를 잘못 파악한 대가를 QA 단계에서야 치르게 되는 건 결제 흐름에 자동화된 테스트가 거의 없어서다. 그렇다면 결제 모듈의 차이를 줄이는 방법은 코드를 한 번에 새로 짜는 것보다, 테스트로 문제를 일찍 발견하게 만들고 흩어진 상태 변경 경로를 모으는 쪽에 더 가깝다.
이번에는 “조직의 생산성을 높이자”는 목표로 돌아가보자. 현상을 적어보니 이런 그림이 나왔다고 해보자.
기능 요청이 들어와서 배포되기까지 평균 3주가 걸린다. 그중 실제로 코드를 작성하는 시간은 평균 4일 정도다.
그러면 나머지 2주 남짓은 어디로 갔을까? 필자는 이럴 때 “왜?”를 여러 번 반복해서 눈에 보이는 증상 너머의 원인까지 내려가보는 편이다.
- 왜 배포까지 3주가 걸리는가? 코딩이 끝난 뒤에도 한참을 기다리기 때문이다.
- 왜 기다리는가? 리뷰 대기, 다른 팀의 API 작업 대기, QA 일정 대기가 차례로 이어지기 때문이다.
- 왜 다른 팀을 기다려야 하는가? 기능 하나를 만들려면 세 팀의 작업이 모두 필요한 구조로 팀이 나뉘어 있기 때문이다.
- 왜 그런 구조가 되었는가? 처음에는 전문성을 기준으로 팀을 나눴는데, 제품이 커지면서 사용자 기능의 단위와 팀의 경계가 어긋났기 때문이다.
이 방법도 필자만 쓰는 건 아니다. 토요타에서는 문제가 생기면 “왜?”를 다섯 번 묻는 5 Whys를 오래전부터 써왔고, 지금은 많은 회사의 장애 회고에서도 흔히 볼 수 있는 방법이 됐다.
이렇게 내려가보면 “생산성이 낮다”의 원인이 코드를 작성하는 속도에 있지 않을 가능성이 꽤 커진다. 그리고 여기서 앞의 AI 도구 이야기와 연결되는 지점이 나온다. 만약 원인이 대부분 대기에 있다면, AI 도구로 코드 작성 시간을 4일에서 2일로 줄여도 배포까지의 시간은 3주에서 2주 반 정도로밖에 줄지 않는다. 생산성을 높이려고 도입한 도구가 정작 가장 큰 차이는 건드리지 못하는 셈이다.
디자인 시스템에서도 비슷한 일이 자주 일어난다. 버튼 스타일이 23가지나 된다는 현상을 보고 “공통 컴포넌트가 없어서”라고 생각하기 쉬운데, 막상 들여다보면 컴포넌트는 이미 있는데 안 쓰이고 있는 경우가 많다. 어디에 뭐가 있는지 찾기 어렵거나, 조금만 다른 모양이 필요할 때 커스텀할 방법이 막혀 있거나, 디자이너가 넘겨준 시안 자체가 이미 제각각인 경우다. 원인이 이런 곳에 있다면 컴포넌트를 더 만드는 건 차이를 줄이지 못한다.
물론 5 Whys가 항상 하나의 정답으로 수렴하는 건 아니다. 원인은 보통 여러 개가 얽혀 있고, 어느 가지로 내려가느냐에 따라 다른 원인에 도달하기도 한다. 필자는 5 Whys를 정답을 찾는 도구라기보다 처음 떠올린 해결책을 한 번 의심해보게 만드는 도구에 더 가깝다고 생각한다. 이 단계에서 확인하고 싶은 건 결국 하나다. 이 원인을 없애면 앞에서 정의한 차이가 정말로 줄어드는가?
한 방이 아니라 작은 걸음으로
원인을 찾았으면 그 원인을 없애기 위한 전략을 세운다. 여기서 가장 흔하게 보는 전략은 한 방짜리 전략이다. 리팩토링이라면 “새 구조로 전부 다시 짠다”, AI 도구라면 “전사에 한 번에 도입한다”, 디자인 시스템이라면 “모든 컴포넌트를 다 만든 다음 배포한다” 같은 식이다.
이런 전략의 가장 큰 문제는 성공했는지 실패했는지를 마지막 날에야 알 수 있다는 점이다. 몇 달 동안은 투자만 있고 확인할 수 있는 결과가 없다. 그리고 끝난 뒤에 누군가 “그래서 뭐가 좋아졌어요?”라고 물으면 여전히 대답하기 어려운 슬픈 상황이 발생한다. 너무 많은 것이 한 번에 바뀌었기 때문에 무엇이 효과를 냈는지 가려낼 방법이 없어서다.
필자는 전략이 가급적 작은 걸음으로 쪼개져 있어야 하고, 걸음마다 앞에서 정의한 차이가 조금씩 줄어드는 게 보여야 한다고 생각한다. 마틴 파울러(Martin Fowler)가 소개한 스트랭글러 패턴도 같은 생각을 담고 있다. 옛 시스템을 한 번에 교체하는 대신 새 시스템이 기능을 하나씩 가져가면서 옛 시스템을 점점 줄여나가는 방식이다.
하반기 동안 결제 모듈을 개선한다면 전략을 이런 식으로 쪼갤 수 있다.
- 9월: 결제 핵심 경로 세 가지에 자동화 테스트를 붙인다. QA 단계에서 되돌아오는 작업이 줄어드는지 본다.
- 10월: 결제 상태를 바꾸는 코드 중 가장 자주 수정되는 두 곳을 하나의 경로로 모은다. 그 두 곳과 관련된 작업의 일정 초과가 줄어드는지 본다.
- 11월: 나머지 상태 변경 코드를 같은 경로로 옮긴다. 9월부터 쌓인 결제 관련 작업 전체의 일정 준수율을 누적으로 본다.
- 12월: 하반기 전체를 돌아보고 처음 정의한 목표에 얼마나 가까워졌는지 확인한다.
AI 도구 도입도 마찬가지다. 전사에 한 번에 뿌리는 대신, 마이그레이션 작업 비중이 가장 큰 한 팀에서 먼저 써보고 그 팀의 마이그레이션 시간이 실제로 줄었는지를 본다. 줄었다면 비슷한 팀으로 넓히고, 줄지 않았다면 왜 줄지 않았는지를 확인한 뒤에 다음 걸음을 정한다.
이렇게 쪼개두면 각 달이 끝났을 때 어떤 그림이 되어 있어야 하는지가 명확해진다. 필자가 리드분들께 “9월, 10월, 11월이 끝났을 때는 어떤 그림이 되는 거냐”고 반복해서 물었던 이유도 여기에 있다.
매달의 그림이 없으면 12월에 가서야 전략이 통했는지를 알 수 있고, 그때는 방향을 바꾸기에 너무 늦다. 반대로 9월에 테스트를 붙였는데 QA에서 되돌아오는 작업이 전혀 줄지 않았다면, 9월에 이미 원인 분석 어딘가가 틀렸다는 신호를 받는 셈이다. 그러면 10월 계획을 바꿀 수 있지만, 같은 신호를 12월에 받으면 그냥 실패한 프로젝트가 된다.
이 과정을 한 줄로 이어보면 활동, 산출물, 결과가 사슬처럼 연결된다.
- 활동: 결제 상태 변경 코드를 하나의 경로로 모은다
- 산출물: 상태 변경 경로가 한 곳으로 정리된 결제 모듈
- 결과: 결제 관련 작업이 예상 일정 안에 끝나는 비율이 올라간다
- 비즈니스 영향: 같은 기간에 더 많은 결제 실험을 예측 가능하게 돌릴 수 있다
필자가 전략 문서를 볼 때 가장 먼저 확인하는 것도 이 사슬이다. 그리고 경험상 이 사슬이 가장 자주 끊기는 곳은 산출물에서 결과로 넘어가는 구간이다. 무엇을 만들지는 대부분 잘 적는다. 그런데 그걸 만들면 왜 결과가 바뀌는지를 적으라고 하면 문장이 갑자기 흐려진다. “좋아질 것 같다”는 말은 대부분 바로 이 구간에서 나온다.
다만 모든 걸음의 효과가 한 달 안에 숫자로 보이는 건 아니다. 매주 지표가 10%씩 출렁이는데 한 걸음의 효과가 3%라면 걸음마다 나아지는 걸 확인하기는 어렵고, 코드 품질에 대한 투자처럼 몇 달이 지나서야 장애 건수 같은 지표에 반영되는 일도 있다.
이럴 때는 아싸리 확인 주기를 늘리거나, 결과로 이어질 것이라고 합리적으로 예상할 수 있는 중간 지표를 대신 보는 편이 나을 수도 있다. 매달 숫자로 확인하자는 원칙이 확인할 수 없는 것을 확인하라는 요구가 되어서는 곤란하다.
그 방법으로 문제가 해결됐다는 건 어떻게 알 수 있나요?
방법을 정하고 실행에 옮겼다면, 마지막으로 남는 질문은 그 방법이 실제로 문제를 줄였는지다. 도입부에서 던졌던 질문의 뒤쪽 절반이기도 하다. 필자는 이 질문에 답하려면 행동하기 전에 미리 적어둔 숫자와, 그 숫자를 실제와 맞춰보는 습관이 필요하다고 생각한다.
“좋아졌다”라고 말하기 위한 숫자
“좋아진 것 같다”와 “좋아졌다”가 갈리는 곳이 바로 여기다.
이 이야기를 하면 자주 보는 반응이 하나 있다. 정량적인 기준을 잡아보자고 하면, 1+1=2처럼 반박할 수 없는 숫자를 찾으려고 하는 것이다.
이런 반응은 대개 “배포까지 걸리는 시간이 줄었다고 해도 그게 우리가 한 일 때문인지 어떻게 알아요? 그 사이에 요구사항이 쉬웠을 수도 있고, 사람이 바뀌었을 수도 있잖아요.”라는 생각에서 나오는데, 솔직히 틀린 말은 아니다. 하지만 그렇게 따지기 시작하면 어떤 개선의 효과든 온전히 증명할 수 있는 숫자는 세상에 거의 존재하지 않는다.
개발자라면 이런 반응이 특히 익숙할 텐데, 필자는 그 이유가 우리가 익숙한 세계의 성질에 있다고 생각한다. 코드의 세계는 대부분 결정론적이다. 같은 입력에는 같은 출력이 나오고, 테스트는 통과하거나 실패한다. 그런데 사람과 조직이 얽힌 세계에서의 측정은 그렇게 동작하지 않는다. 같은 행동을 해도 결과는 매번 조금씩 다르고, 결과에 영향을 주는 요인은 셀 수 없이 많다.
그래서 필자는 측정을 조금 다르게 바라보는 편이 낫다고 생각한다. 측정은 무언가를 증명하는 일이 아니라 모르는 것을 조금 덜 모르게 만드는 일이다. 배포까지 3주 걸리던 것이 2주로 줄었다면, 그게 전부 우리가 한 일 덕분이라고 증명할 수는 없어도 “효과가 있었다”는 쪽으로 믿음을 옮길 근거는 충분히 된다.
그렇다면 100% 정확하지 않은 숫자 중에서도 쓸 만한 숫자와 그렇지 않은 숫자는 어떻게 구분할 수 있을까? 필자는 정밀도보다 두 가지를 더 중요하게 본다.
첫 번째는 그 숫자를 행동하기 전에 적었는가다. 일이 끝난 뒤에 “뭐가 좋아졌는지 숫자를 찾아보자”라고 하면 거의 항상 뭔가 좋아진 숫자를 하나쯤은 찾을 수 있다. 수십 개의 지표 중 하나는 우연히라도 올라가 있기 마련이기 때문이다. 이렇게 사후에 고른 숫자는 아무리 정확해도 설득력이 약하다. 반대로 행동하기 전에 “이게 이만큼 움직일 것이다”라고 적어둔 숫자는 조금 거칠더라도 훨씬 강하다. 그건 증명이 아니라 예측이고, 예측이 맞았다는 건 우리가 문제를 제대로 이해하고 있었다는 신호이기 때문이다.
사후에 숫자를 요구받을수록 사람들이 공리적인 숫자를 찾으려는 경향이 더 강해지기도 한다. 이미 끝난 일의 가치를 숫자로 보여달라는 요구는 증명을 요구받는 것처럼 느껴지고, 증명이라면 반박당하지 않을 숫자가 필요하다. 같은 질문을 행동하기 전에 던지면 대답은 예측이 된다. 예측은 틀려도 되니까 대략 말이 되는 숫자를 내놓기가 훨씬 쉬워진다.
두 번째는 그 숫자가 다음 행동을 바꿀 수 있는가다. 결제 작업의 일정 준수율이 10월에 전혀 오르지 않았다면 11월 계획을 바꿀 것인가? 바꿀 것이라면 그 숫자는 의미가 있다. 어떤 숫자가 나와도 하려던 일을 그대로 할 거라면, 그 숫자는 측정이라기보다 보고서를 꾸미는 장식에 더 가깝다.
하나의 완벽한 지표를 찾기보다는 불완전하지만 같은 방향을 가리키는 지표 두세 개를 함께 보는 편이 현실적이다. 성능 개선이라면 LCP p99, 이탈률, 상품 상세에서 장바구니로 넘어가는 비율을 같이 볼 수 있다. 셋 다 성능 외의 요인에 영향을 받지만, 셋이 동시에 같은 방향으로 움직인다면 우연일 가능성은 꽤 줄어든다.
조직 생산성이라면 구글 클라우드의 DORA 연구팀이 정리한 지표가 좋은 출발점이 될 수 있는데, 배포 빈도나 변경 리드타임 같은 속도 지표만 보지 말고 변경 실패율이나 복구 시간 같은 안정성 지표를 함께 봐야 한다. 물론 이것 역시 참고할 기준이지 생산성을 증명해주는 공리는 아니다.
필자는 OKR에서 핵심 결과를 정할 때도 같은 원리가 적용된다고 생각한다. 구글에 OKR을 처음 소개한 존 도어(John Doerr)는 핵심 결과가 측정 가능하고 검증 가능해야 한다고 말하는데, 이 말을 “논리적으로 완벽한 숫자여야 한다”로 읽을 필요는 없다. 애초에 현실에 그런 숫자는 거의 없다. 행동 전에 합의했고 결과에 따라 다음 행동이 바뀔 수 있는 숫자라면, 조금 거칠더라도 충분히 좋은 핵심 결과가 될 수 있다.
숫자는 달을 가리키는 손가락이다
여기까지 읽으면 숫자만 잘 정하면 된다는 이야기로 들릴 수 있는데, 숫자를 정한 뒤에 꼭 붙잡아야 할 게 하나 있다. 숫자는 문제 그 자체가 아니라 문제를 가리키는 손가락이라는 점이다. 달을 가리키면 손가락만 본다는 옛말처럼, 숫자를 목표로 걸어두고 시간이 지나면 사람들의 시선은 어느새 문제보다 숫자 쪽으로 옮겨간다.
예를 들어 테스트 커버리지 90%를 목표로 걸면 아무것도 검증하지 않는 테스트가 늘어나고, 배포 빈도를 목표로 걸면 사용자에게 아무 변화도 주지 않는 배포만 잦아질 수 있다. 진짜 문제를 해결하기보다 숫자를 올리기 위한 꼼수가 등장하는 것이다. 숫자는 올라갔지만 처음에 줄이고 싶었던 차이는 그대로 남는다. 흔히 “측정이 목표가 되면 더 이상 좋은 측정이 아니게 된다”는 굿하트의 법칙으로 알려진 현상이다.
그렇다고 숫자를 버릴 필요는 없다. 필자는 숫자가 움직였을 때 한 가지를 같이 확인하는 편이다. 처음에 적어둔 현상도 같이 나아졌는가? 커버리지가 올랐다면 QA에서 되돌아오는 작업도 줄었는지, 배포 빈도가 늘었다면 기능이 사용자에게 닿는 시간도 짧아졌는지를 보는 식이다. 숫자만 움직이고 현상이 그대로라면 손가락만 보고 있었다는 신호다. 앞에서 행동하기 전에 숫자를 적고 불완전한 지표 여러 개를 함께 보자고 한 것도, 결국 시선이 달에서 떠나지 않게 하려는 장치들이다.
반대로 손가락으로 가리키기 어렵다고 달이 없는 것도 아니다. 베트남 전쟁 당시 미국 국방장관이었던 로버트 맥나마라(Robert McNamara)는 적군 사망자 수처럼 셀 수 있는 숫자로 전황을 판단하다가, 숫자로 잡히지 않는 것들을 놓쳤다는 비판을 받는다. 측정하기 쉬운 것만 재다가 측정하기 어려운 것을 없는 것처럼 다루게 되는 이 함정을 그의 이름을 따 맥나마라 오류라고 부른다. 문서화나 온보딩, 코드를 읽는 사람이 느끼는 인지적 부담 같은 것들은 숫자로 잡기 어렵지만 분명히 존재한다. 숫자로 잡기 어렵다는 이유로 이런 문제를 버리기보다는, 거친 지표라도 찾아보거나 관찰한 현상을 꾸준히 기록해두는 것만으로도 충분히 다룰 가치가 있다.
예측과 실제를 맞춰본다
숫자를 정하고 전략을 실행했다면, 이제 예측과 실제를 맞춰볼 차례다.
매달 말에 처음 적어둔 그림과 실제 그림을 나란히 놓고 보는 것이다. 9월 말에는 QA 단계에서 되돌아오는 작업이 절반으로 줄 거라고 예측했는데 실제로는 20%만 줄었다면, 왜 그런지를 짧게라도 적어본다. 테스트를 붙인 경로가 실제로 자주 바뀌는 경로가 아니었을 수도 있고, 되돌아오는 원인 중 테스트로 잡을 수 없는 종류가 생각보다 많았을 수도 있다.
이 과정이 중요한 이유는 “대략 말이 되는 숫자”를 고르는 감각이 여기서 길러지기 때문이다. 처음에는 누구나 예측을 크게 틀린다. 너무 낙관적이기도 하고 엉뚱한 지표를 고르기도 한다. 예측을 적고, 틀리고, 왜 틀렸는지 확인하는 과정을 몇 번 반복하다 보면 어느 정도의 정밀도면 충분한지, 어떤 지표가 실제로 문제를 잘 반영하는지에 대한 감각이 생긴다.
반대로 이 과정이 없으면 목표 문서는 분기 초에 한 번 쓰고 서랍에 넣어두는 문서가 된다. 그리고 분기가 끝났을 때 누군가 “이건 왜 한 거예요?”라고 물으면 결국 다시 “좋아진 것 같아요”라는 대답으로 돌아가게 된다.
문제 정의 역량은 스스로 던지는 질문에서 자란다
그렇다면 이 역량은 어떻게 키울 수 있을까? 앞에서 꽤 긴 과정을 적었지만, 필자는 문제 정의 역량이 자랐다는 게 이 과정을 외우고 있다는 뜻은 아니라고 생각한다. 오히려 누가 묻기 전에 필요한 질문이 자기 안에서 먼저 떠오르는 상태에 더 가깝다.
필자는 예전에 이 과정을 교육 과목으로 만들어 운영해본 적이 있는데, 그때 알게 된 건 방법을 배우는 것과 실제 일 앞에서 그 방법을 꺼내 쓰는 것이 꽤 다른 일이라는 점이다. 교육장에서는 템플릿이 질문을 대신 던져주지만, 실제 일에서는 아무도 그 질문을 대신 던져주지 않는다. 그래서 필요한 건 거창한 공부보다는, 평소 일하는 자리에서 그 질문을 스스로 던져보는 습관이다.
누군가 나에게 묻는다고 상상해보기
방법은 생각보다 단순하다. 일을 시작하기 전에, 누군가 나에게 이렇게 묻는다고 한 번만 상상해보는 것이다.
이건 무슨 문제를 해결하는 건가요?
그 문제가 실제로 존재한다는 건 어떻게 알 수 있나요?
왜 하필 그 방법인가요?
그 방법으로 문제가 해결됐다는 건 어떻게 알 수 있나요?
눈치챘겠지만 이 네 질문은 이 글의 소제목이었다. 첫 번째 질문은 할 일과 문제를 구분하게 만들고, 두 번째 질문은 직감을 관찰과 현상으로 바꾸게 만들고, 세 번째 질문은 목표와 원인에서 방법을 끌어내게 만들고, 네 번째 질문은 행동하기 전에 확인할 숫자와 예측을 적게 만든다. 넷 중 하나에서라도 말문이 막힌다면, 아직 문제가 충분히 정의되지 않았다는 신호다.
개발자라면 러버덕 디버깅을 떠올리면 이해가 쉽다. 책상 위 오리 인형에게 코드를 한 줄씩 설명하다 보면, 오리가 아무 말도 하지 않는데도 어느 순간 버그가 보인다. 설명하려고 하는 순간 머릿속에서 대충 넘어가던 부분이 드러나기 때문이다. 가상의 질문자도 같은 역할을 한다. 대답하려고 하는 순간 “좋아질 것 같다”로 덮어두었던 빈칸이 드러난다.
다만 머릿속으로만 상상하면 사람은 스스로에게 꽤 관대해지기 때문에 필자는 두 가지를 권한다.
하나는 각 질문의 답을 한 문장씩이라도 실제로 적어보는 것이다. 머릿속에서는 그럴듯하던 답도 문장으로 옮기려고 하면 어디가 비어 있는지 금방 보인다. 다른 하나는 질문자를 구체적으로 정하는 것이다. 막연한 누군가보다는 평소에 가장 날카롭게 질문하는 동료나 리드의 얼굴을 떠올리는 편이 훨씬 효과가 좋다.
리드라면 그 질문자가 되어주기
리드라면 한 걸음 더 나아가볼 수 있다. 처음에는 리드가 실제 질문자가 되어주는 것이다. 필자가 목표 문서를 볼 때마다 비슷한 질문을 반복했던 것도 결국 이 역할이었다.
다만 이 질문들이 리드의 머릿속에만 있으면 구성원들은 문제를 정의하는 대신 리드의 기준을 맞추는 게임을 하게 된다. 그래서 필자는 질문을 숨기지 않고 미리 꺼내두는 편이 낫다고 생각한다. 문서를 쓰기 전에 이 네 질문을 먼저 공유해두면, 구성원들은 리드를 만나기 전에 그 질문을 자기 문서에 스스로 던져볼 수 있다. 교육장의 템플릿이 연습 문제에 붙어 있던 질문이었다면, 이건 실제 문서를 쓰는 바로 그 시점에 붙어 있는 질문이라는 점이 다르다.
그렇게 몇 번의 사이클이 지나면 리드가 묻기 전에 답이 먼저 문서에 적혀 오기 시작한다. 가상의 질문자가 어느새 자기 안에 자리를 잡은 것이다. 필자는 그게 문제 정의 역량이 자란다는 것의 실체에 가깝다고 생각한다.
마치며
처음에 나란히 놓았던 세 개의 문장을 다시 떠올려보자.
“결제 모듈을 리팩토링하자”는 “결제 관련 작업 8건 중 3건만 예상 일정 안에 끝나고 있으니, 이걸 6건으로 늘려 결제 실험을 더 자주 돌리자”가 될 수 있다. “LCP p99를 2초 이하로 줄이자”는 “주문의 60%가 거쳐 가는 상품 상세 페이지에서 첫 화면이 3초를 넘긴 방문이 하루 2만 건이고 이 방문들의 전환율이 절반이니, 이 구간부터 줄이자”가 될 수 있다. 그리고 “조직의 생산성을 높이자”는 “기능이 배포되기까지 걸리는 3주 중 2주 넘게 차지하는 대기 시간을 줄이자”가 될 수 있다.
바뀐 문장들에 대단한 방법론이 들어 있는 건 아니다. 앞에서 본 네 질문에 한 번씩 답해본 결과일 뿐이다. 그리고 이 질문들은 한 번 답하고 끝나는 게 아니라, 작게 움직이면서 문제에 대한 이해가 바뀔 때마다 다시 던져야 하는 질문이기도 하다. 토요타의 5 Whys나 베이조스의 결정 방식, 구글의 OKR도 모양만 다를 뿐 결국 비슷한 질문 위에 서 있으니, 새로운 이야기라기보다는 오래된 이야기에 가깝다.
그런데도 이 과정이 잘 지켜지지 않는 건 매 단계가 할 일을 쳐내는 것보다 덜 생산적으로 느껴지기 때문이라고 생각한다. 세어보는 시간, 문장을 다듬는 시간, 예측을 적는 시간은 티켓을 닫아주지 않는다. 그래도 필자는 이 시간이 결국 가장 많은 시간을 아껴준다고 믿는다. 풀 필요가 없던 문제를 푸는 데 쓴 몇 주, 풀었는지 아닌지 끝까지 알 수 없었던 몇 달을 생각해보면 더 그렇다.
이 글의 처음에 지난 분기에 가장 공들인 일을 하나 떠올려보자고 했다. 다음 일을 시작할 때는 누군가 그 일에 대해 네 가지를 묻는다고 한 번만 상상해보자. 그 질문에 답할 수 있는 일이 하나둘 늘어날 때쯤이면, “이건 왜 한 거예요?”라는 질문 앞에서도 “좋아진 것 같아요”보다는 조금 더 단단한 대답을 할 수 있게 되어 있을 것이다.
이상으로 애매한 문제를 제대로 정의한다는 것 포스팅을 마친다.