일을 이끄는 힘

• 내 리더는 답을 내기 전에 질문부터 바꾼다. 그러면 누구를 볼지, 무엇을 잴지, 어디서부터 할지가 한 번에 정해진다.

• 결론부터 쓰고, 숫자로 말하고, 우선순위를 낮출 때도 이유를 말한다. 오늘은 그런 그의 습관 이야기다.

• 저마진 고객사 (Low-margin account) — 매출에 비해 운영 비용이 커서 남는 게 적은 고객사. 첫 번째 이야기에서 그가 기준을 바꾼 단어다.

• as-is / to-be — 지금 상태와 바뀐 뒤의 상태. 그는 임팩트를 잴 때 항상 이 둘을 나란히 놓는다.

흉내 내기 어려운 리더

그에게서 본 장점을 다섯 가지로 나눠 본다.

하나, 답보다 질문을 먼저 바꾼다

그는 받은 문제를 그대로 풀지 않고, 그 문제가 맞는 문제인지부터 따진다. 우리 셀의 목표는 회사의 마진을 개선하는 거였다. 마진을 개선하는 방법으로 내가 접근했던 것은 매우 심플했다. 매출 대비 비용이 많이 나가는 고객사를 찾는 것. 7월에 저마진 고객사를 정리하자는 논의가 나왔을 때, 그는 기준 자체를 바꿨다. 이미 가격을 책정하고 들어온 고객이고 가격은 시장에서 정해지는 것이니, 제품팀이 저마진으로 잡히는 고객사의 매출 구조에 집중하는 것은 의미가 없다는 것이었다. 대신 '비용이 큰 상위 10개 고객사의 특징'을 보자고 했다.

질문이 바뀌자 이후의 일이 전부 달라졌다. 누구를 볼지, 무엇을 잴지, 어디서부터 할지가 그 한 문장에서 정해졌다. 모든 팀원들이 고비용을 해결하기 위한 솔루션과 그것을 만드는 특징에 집중했다. 전체를 포괄하기보다 발견한 한 가지를 부술 수 있는지에 집중했다.

비슷한 일을 겪었었다. 1:1에서 나는 저마진 고객사의 스코프 조정 문서를 들고 갔다. 내 문서는 Sales에게 스코프를 줄여야 한다는 걸 알리는 데 초점이 있었다. 그는 스코프 조정과 고객사와의 합의는 목적이 다르다고 짚었다. 고객사와 합의하려면 SSales가 그대로 설명할 수 있는 기술적 근거가 필요하다는 것이었다. 그날 문서의 독자가 고객사로 바뀌었다.

둘, 결론부터 쓰고 하지 않을 것도 쓴다

그의 공유 글은 구조가 일정하다. 6월 새로운 인텔리전스 기능 런칭 연기를 알릴 때는 '아젠다 → 배경 → 결론' 순서로 썼다. 왜 미루는지, 대신 무엇을 하는지, 가격과 남용 방지 정책까지 한 글에 담겨 있었다. (Slack)

슬랙 예시

아젠다

1. 배포 일정 연기

2. Interim Pricing 확정

배경 (Context)

1. 현재 목표 배포 일정 기준으로는 충분한 테스트 및 검증 기간이 확보되지 않아 안정성 측면에서 우려가 있습니다.

2. 또한, 어제 대부분 합의된 Pricing 정책을 이번 초기 런칭 경험에 포함하는 것이 바람직하다고 판단했습니다. 이를 통해 런칭 이후 고객들이 접근 권한 및 가격 정책에 대해 혼란을 겪는 것을 방지할 수 있습니다. 다만, 이를 지원하기 위해서는 추가적인 개발 작업이 필요하며, 이 또한 런칭 일정 연기의 이유 중 하나입니다.

결론

1. 고객 런칭 일정 연기: 고객 런칭 일정을 xx일에서 yy일로 연기합니다.

2. 사전 배포 및 안정화 기간 운영

   • 고객 런칭 일정과 별개로 사전 배포를 진행합니다.

   • Internal User대상으로 일정 기간 사용하며 안정성을 검증하고 개선합니다.

3. Pricing 확정: (비공개)제품 출시와 관련한 가격 정책 주요 결정 사항

4. Anti-abuse 정책: (비공개)출시 전 반드시 짚어야 하는 Validation

개발 결정을 정리할 때는 '결정 요약 3줄'로 시작하고, 변경 사항을 P0/P1/P2로 나눈 뒤 '하지 않을 것'을 따로 적었다. 하지 않을 것을 적어 두면 나중에 같은 논쟁을 다시 하지 않아도 된다.

구조

1. 결정 요약 3줄:

2. 코드 변경:

   • P0 (반나절):

   • P1 (1~2일):

   • P2 (측정 스키마, 가장 먼저 착수 권장):

   • 하지 않을 것:

3. 변경 후 흐름도:

4. 실험 근거 표:

5. 부탁드릴 것:

6. 부록 A: 실험 완료된 프롬프트, 제약사항

셋, 목표를 숫자로 말하고 달성하면 다음 숫자를 꺼낸다

3분기에 대표적인 사례가 있었다. 비용을 15%로 낮추는 목표를 달성할 것 같다고 감사를 전한 뒤, 연말 목표 XX%를 바로 꺼냈다. 그리고 "인력을 모두 자동화하는 것만으로는 부족하다"고 다음 난이도를 미리 말했다.

"Q2가 아직 끝나지는 않았지만, 지난 Q1과 Q2 동안 정말 고생 많으셨고 진심으로 감사합니다. 쉽지 않은 목표였지만, 팀 모두의 헌신 덕분에 이번 Q2에는 목표를 달성할 가능성이 매우 높다고 보고 있습니다. 우리의 KPI는 비용을 15%로 낮추는 목표하는 것이었습니다. 현재 추세대로라면 7월 기준으로 이 목표를 달성할 것으로 예상합니다. 이 결과는 ...(중략) ...모든 팀 분들께 진심으로 감사드립니다.

하지만 우리의 여정은 아직 끝나지 않았습니다. 이제 남은 목표는 연말까지 XX%까지 낮추는 것입니다. 이 목표를 달성하기 위해서는 단순히 모든 리소스를 자동화하는 것만으로는 부족합니다. 그 이후에도 더 많은 영역에서 자동화를 만들어내야 합니다. (중략) 하지만 지금까지 우리가 해왔던 것처럼 함께 힘을 모은다면 충분히 해낼 수 있다고 믿습니다."

작은 일도 마찬가지다. 사내 도구 하나를 두고도 '한 명당 10만 원의 체감 가치, 사내 50명 사용'처럼 숫자로 목표를 잡았다.

나와의 1:1에서도 마찬가지였다. 7월 초 1:1에서 그는 "7월 마감까지 60% 이상"이라는 숫자를 먼저 정하고, 그 숫자에 맞춰 밀려 있던 작업의 우선순위를 다시 잡게 했다. 다음 분기 OKR도 방향성을 먼저 정한 뒤 이니셔티브로 구체화하라고 했다.

넷, 우선순위를 낮출 때도 이유를 말한다

그는 이슈를 버리지 않고 티켓으로 남기되, 우선순위는 이유와 함께 정한다. 언어가 섞인 답변 버그는 흔하지 않아서 낮추고, 사용자 경험이 크게 깨지는 버그는 QA 티켓 중 가장 위로 올렸다.

결정을 바꾸는 데도 주저하지 않는다. 백엔드에서 리스크를 제기하자 배포를 하루 미루며 "같은 스케줄로 준비하고 날짜만 하루 미루자"고 범위를 분명히 했다.

"@here 팀, 오늘 배포하는게 조금 리스크 할것 같다고 백엔드에서 콜아웃 주셔서, 내일로 배포 미루고자 합니다. 배포 일정 맞추기 위해서 타이트하게 왔는데, 급하게 하다 보니 아래 이슈가 있습니다.

1. 이슈 첫번째

2. 이슈 두번째

2가지 이슈 해결하고 내일 다시 배포 나가는 걸로 해야 할것 같습니다..! 오늘과 동일한 스케줄로 배포 준비(17:00 Pre-Release 목표)하고, 날짜만 하루 더 미루시죠."

내 일에서도 그랬다. 9월 1:1이 끝날 때 그는 내 할 일을 순서로 정리해 주었다. 1순위는 월 323시간의 인력 갭을 줄이는 방법, 2순위는 고객사 설득 자료, 3순위는 모델·형태 차이를 반영한 커버리지 개선이었다. 3순위가 뒤로 밀린 이유도 분명했다. Claude로 테스트한 결과가 아직 뚜렷하지 않았고, 인터뷰가 끝난 고객사를 먼저 보는 편이 더 빨랐다.

다섯, 현장을 관찰하는 방법까지 설계한다

자동화를 시작할 때 그는 작업 분석 시트를 먼저 만들었다. 하루 작업을 UX 인터뷰처럼 자세히 적게 하되, 행동(acting)과 생각(thinking)을 나눠 적게 했다. 작업마다 정확도와 작업량이 가장 좋은 사람 한 명을 골랐다. 에이전트는 사람의 '생각'을 배워야 하니, 처음부터 그 생각을 뽑아내는 방식으로 관찰을 설계한 것이다.

다섯 가지는 하나로 이어진다

다섯 가지 장점은 따로 노는 게 아니라 하나의 순서로 이어진다. 그가 논의를 이끄는 흐름을 정리하면 이렇다.

1. 질문을 다시 정의한다. "이게 맞는 기준인가?"부터 묻는다. (저마진 → 고비용 상위 10개)

2. 비교할 수 있는 기준선을 세운다. 지금 쓰는 시간(as-is)과 완료 후 시간(to-be)을 나란히 놓고 임팩트를 잰다.

3. 임팩트로 우선순위를 정한다. 다 찾기 전에 몇 개만 골라 시작해도 된다고 분명히 말한다.

4. 작은 결과를 하나의 이야기로 묶는다. 고객사별 임팩트를 더해 하나의 프로젝트로 만들어야 전사에 전달하기 쉽다고 본다. 개별 에이전트를 하나씩 만들어 하나의 큰 그릇에 담는다는 구상도 같은 생각이다.

5. 결론부터 공유하고, 상황이 바뀌면 다시 연다. 우선순위에서 뺀 일도 고객 요청이 들어오면 "상황 보고 바뀔 수 있다"고 문을 열어 둔다.

사람을 움직이는 방식에도 패턴이 있다.

• 질문으로 빈틈을 짚는다. 목표 수치를 볼 때 "키워드는 무작위인가, 중복은 포함인가, 우선순위는 없는가" 세 가지를 번호 붙여 물었다. 틀렸다고 말하지 않고 상대가 답하면서 발견하게 한다.

• 기준을 예시로 보여준다. 1:1 사전 질문에 '좋은 예시'와 '좋지 않은 예시'를 나란히 두었다. "구체적으로 써 달라"는 말보다 훨씬 명확하다.

• 있는 것부터 쓴다. 새로 만들기 전에 "예전에 만든 걸로 안 되나요?"를 먼저 묻는다.

• 인정과 다음 방향을 한 번에 준다. 감사 인사를 하면서도 "우리의 목표는 이제 시작했다"고 다음 기준을 함께 제시한다.

• 자유는 주되 책임은 분명히 한다. 5월 1:1에서 그는 팀원에게 자유도를 주되 결과물에 대한 책임은 분명히 한다고 했다. 누구도 정답을 갖고 있다고 가정하지 않고, 성장을 위해 일부러 어려운 일을 맡긴다고도 했다. 7월에는 리드의 역할을 '올바른 길을 보여주는 사례를 만드는 사람'이라고 설명했다.

가장 오래 남은 장면은 4월이다. AI팀원들에게 각자 독립된 과제를 맡기는 방식이 처음 시작됐을 때, 나는 그를 찾아가 고민을 털어놓았다. 새 구조에서 내 역할이 무엇인지, 엔지니어의 설명을 다 이해하지 못한 채 결과를 믿어도 되는지 불안했다.

그의 답은 단순했다. PM이 할 가장 중요한 일은 목표를 분명히 하는 것이고, 과제마다 성공 기준을 정해 두면 신뢰는 그 위에서 생긴다는 것이었다. 애매하게 의심하며 지켜보지 말고, 완전히 믿거나 분명하게 관여하거나 둘 중 하나를 고르라고 했다. 공식적인 자리에서는 목표로 이야기하고, 불안은 따로 풀라고 했다. 팀원에게 물을 때는 의심이 아니라 호기심으로 물어야 한다는 말도 덧붙였다. 낯선 기술이라도 기초 문서 열 장 정도면 대화를 따라갈 수 있다고 했다.

그때는 조언으로 들었는데, 지금 보면 그가 매일 일하는 방식 그대로였다.

그처럼 되려면 말을 잘하기보다, 말하기 전에 하는 일을 바꿔야 한다. 당장 내 일에 넣어볼 것은 네 가지다.

• 요청을 받으면 바로 풀지 않고, "이 기준이 맞나?"를 한 줄로 먼저 적는다.

• 공유 글은 '결론 → 배경 → 하지 않을 것' 순서로 쓴다.

• 모든 제안에 as-is와 to-be 숫자를 하나씩 붙인다.

• 피드백을 줄 때는 결론 대신 번호 붙인 질문 세 개로 준다.

하지만 이 일에서 정의할 수 없는, 그리고 내가 흉내내기 어렵다는 것은 그래서 이 문장들을 모두가 이해하고 동기부여를 가지고 하나로 바라보게 하는 작업을 그가 잘 한다는 것이다.

여러분 곁에도 흉내 내고 싶지만 흉내 내기 어려운 리더가 있나요?