의사결정과 업무 진행은 프로덕트를 사용하는 고객 관점에서 시작한다.
‘고객 관점’이라는 말은 많이 사용되지만, 실제로 왜 중요한지 두 가지 측면에서 살펴보려고 한다.
1. 조직에서의 의사결정 측면
이런 상황을 경험해본 적이 있을 것이다. 팀원들이 서로 다른 방향을 바라보며 의견이 엇갈리는 순간 말이다. 각자가 자신이 생각하는 해결 방법에 몰입하다 보면, 대화가 평행선을 달리기 쉽다. 이럴 때 어떻게 하면 좋을까?
먼저 고객이 실제로 겪고 있는 문제 상황을 함께 정확히 이해해보자. 고객에게 정말 필요한 것이 무엇인지 함께 정의하는 것이다. 이를 문서 최상위에 “목표"로 명확히 적어두면 좋다.
목표가 정의되면 자연스럽게 대화의 방향이 잡힌다. “이 고객은 이런 문제를 해결하고 싶어한다"는 공통의 이해 위에서, 어떤 방법이 더 적절한지 Pros/Cons를 함께 검토할 수 있다. 고객을 만족시킨다는 공통 목표가 있기 때문에, 서로의 의견은 단순한 대립이 아니라 더 나은 방향을 찾기 위한 건설적인 피드백이 된다. 해야 할 일의 윤곽이 점점 선명해지고, 자연스럽게 함께 문제를 해결하는 방향으로 나아갈 수 있다.
이 과정에서 스스로 돌아보자. 혹시 특정 방법에만 집착하고 있지는 않은지, 팀의 목표보다 내 의견을 관철시키는 데 초점이 맞춰져 있지는 않은지 말이다.
2. 프로덕트의 디테일 측면
프로덕트를 만들다 보면 자연스럽게 욕심이 생긴다. “이 기능도 추가하면 좋겠다”, “UI를 조금 더 아름답게 꾸미고 싶다"는 생각이 드는 것은 당연하다. 하지만 고객의 입장에서 바라보면, 대부분 더 단순하고 사용하기 쉬운 것을 선호한다. 복잡함보다는 직관성을 원한다.
어떻게 하면 더 단순하게 문제를 풀 수 있을지 고민하다 보면, 프로덕트 리뷰의 관점도 달라진다. UI/UX는 사용자 경험을 위한 것인데, 만약 만드는 사람의 취향이나 관점만 투영된다면 사용자와의 간극이 생길 수 있다. 고객의 눈으로 바라보고 리뷰하다 보면, 정말 중요한 디테일이 무엇인지 더 명확하게 보인다.
우리 팀의 시야를 넘어 전체 프로덕트를 사용하는 고객의 관점에서 문제를 바라보면, 더 본질적인 해결책을 찾을 수 있다.
동기부여가 있다면 100%가 아닌 120%의 결과물이 나온다.
지시받아 하는 일과 스스로 하고 싶어서 하는 일은 결과가 다르다.
만약 모든 스펙이 정의되고, 해야 할 일이 이슈로 만들어져서 팀원에게 할당된다면 어떻게 될까?
아마 100% 이슈가 완료되면서 일은 “정상적으로” 끝날 것이다. 표면적으로는 문제가 없어 보인다. 하지만 이런 방식이 계속된다면? 정의되지 않은 일은 시작되지 않고, 팀원들은 주어진 일만 정확히 수행하게 된다. 그것만으로도 충분한 결과물이 나오는 것처럼 보이기 때문이다.
하지만 빠르게 변화하는 스타트업 환경에서는 이런 방식이 오래 가기 어렵다. 주어진 일만 하는 사람들만 남고, 더 큰 성과를 만들고 싶어하는 사람들은 다른 곳을 찾아가게 된다.
조금 다른 방식을 생각해보자. 문제 상황이 주어졌을 때, 우리가 이것을 왜 해결해야 하는지 궁극적인 목표(Objective)를 함께 공유하고, 팀원들이 이에 공감하고 몰입할 수 있게 한다면 어떨까? 목표에 진심으로 공감한 팀원들은 다양한 방법으로 문제를 풀려고 노력할 것이고, 처음 계획했던 100% 이상으로 디테일이 채워진 결과물이 나온다.
실제로 우리 채팅팀에서 OKR의 Objectives와 Key Results를 공유하는 방식이 그랬다. 물론 과정이 항상 순조로운 것은 아니다. 중간에 공감대를 형성하지 못하거나, 방향을 수정해야 하는 경우도 있다. 그럼에도 이런 방식은 팀원들이 자발적으로 동기부여되어 더 깊이 몰입하고, 더 좋은 결과를 만드는 데 도움이 된다.
OKR이 단순한 목표 관리 도구를 넘어, 팀원들의 진짜 동기부여가 되고 프로덕트 개선을 이끄는 원동력이 되는 것을 경험하고 있다.
달리는 기차를 멈추지 않는다. 바퀴를 교체한다.
워터폴과 애자일의 차이를 생각해보면 이해가 쉬울 것 같다. 처음부터 완벽하게 기획하고, 디자인하고, 개발할 수 있다면 얼마나 좋을까. 하지만 현실은 다르다. 일을 진행하면서 우리의 이해도는 깊어지고, 고객의 요구사항도 계속 변한다.
그렇다면 처음부터 정확한 방향과 힘(벡터)를 정의해서 한 번에 목표에 도달할 수 있을까?
현실적으로는 어렵다. 고객의 문제를 보며 일하다 보면 비즈니스 도메인을 더 깊이 이해하게 되고, “아, 이렇게 하면 더 좋겠다"는 생각이 드는 순간들이 있다. 비유를 들어보자. 레일을 먼저 만들고 손수레를 올려서 굴려본다. 그러면 무엇이 문제인지 보이기 시작한다. 엔진 동력이 부족한지, 바퀴에 문제가 있는지, 브레이크가 제대로 작동하지 않는지 알 수 있다.
우리는 처음부터 모든 문제를 예측하고 해결할 수 없다. 그런데 실제로 일할 때를 보면, 처음부터 완벽한 것(유니콘)을 만들려고 하는 경향이 있다. 하지만 이런 방식은 오히려 좋은 결과물을 만드는 데 방해가 될 수 있다.
먼저 “달릴 수 있는” 최소한의 조건만 생각해보자. 예를 들어 채팅에서 검색 기능을 만든다고 하면, 검색이 동작하기 위해 정말 필요한 것은 무엇일까? 검색창과 결과 화면, 그리고 이를 처리하는 API와 기본적인 쿼리 엔진. 이 정도만 있으면 기차가 달리기 시작한다.
그 다음은? 달리면서 개선하면 된다. 쿼리 엔진의 성능 튜닝, 검색 알고리즘 고도화, 실시간 메시지 인덱싱 방식 등은 달리면서 바꿀 수 있는 바퀴들이다. 기차를 멈추지 않고도 개선할 수 있다.
이걸 정리해보면 두 가지 관점으로 나눠서 생각하면 좋다.
- 필수적이고 기반이 되는 것: 처음부터 반드시 정해야 하는 것
- 선택적이고 개선 가능한 것: 나중에 바꿀 수 있는 것
필수적이고 기반이 되는 것은 초기에 정의해야 한다. 다행히 이런 것들은 보통 그렇게 복잡하지 않다. 기본 인프라와 API 스펙 정도다. 한 번 정하면 프로덕트가 살아있는 동안 함께 간다. 기차로 치면 “달린다"는 본질적인 기능이다. 엔진을 개선하고 외형을 바꿀 수 있지만, 달린다는 사실은 변하지 않는다.
반면 내부 로직은 언제든 바꿀 수 있다. 계속 개선하고 고도화할 부분이다. 그렇기 때문에 처음부터 너무 많은 노력을 들일 필요가 없다. 일단 동작하게 만드는 게 중요하다. 어차피 계속 개선될 것이기 때문에 처음부터 완벽할 필요는 없다.
이 두 가지를 구분하는 것이 정말 중요하다. 일하다 보면 “이것도 필요하고 저것도 필요하다"는 이야기를 많이 듣게 되는데, 실제로 “꼭” 필요한 것은 생각보다 많지 않다. 진짜 필수적인 것만 정확히 정의하고 일단 달리기 시작하면, 결과를 보면서 하나씩 부품을 교체하며 계속 개선해나갈 수 있다.
고객은 문제를 가지고 있다. 하지만 고객이 말하는 해결책이 항상 정답은 아니다.
고객의 목소리를 듣는 것은 정말 중요하다. CS팀이나 다른 팀과의 소통을 통해 고객의 진짜 목소리를 들을 수 있다. 다만 여기서 주의할 점이 있다. 고객은 종종 자신이 생각한 구체적인 해결 방법(How to)을 말할 때가 있다. “이렇게 해주세요"라고 말이다.
고객이 제안한 방법에만 집중하면, 오히려 좁은 시야로 문제를 볼 수 있다. 예를 들어보자. 중고거래를 자주 하는 사용자는 “중고거래 관련 기능을 채팅 목록에 넣어주세요"라고 요청한다. 반면 모임 채팅을 자주 쓰는 사용자는 “모임 관리 기능을 채팅 목록에 넣어주세요"라고 한다. 이 두 요청을 그대로 받아들이면 어떻게 될까?
조금 더 깊이 들여다보면, 실제로 사용자들이 원하는 것은 “채팅 목록에서 내가 원하는 것만 모아보고 싶다"는 것이다. 여러 종류의 채팅이 섞여 있어서 불편하다는 근본적인 문제가 있는 것이다.
진짜 문제가 무엇인지 정확히 파악하는 것이 중요하다. 표면에 드러난 요청 뒤에 숨어있는 본질적인 불편함을 찾아야 한다. 그래야 더 큰 범위의 문제부터 차근차근 정의하고, 점점 좁혀가면서 제대로 된 해결책을 찾을 수 있다.
고객의 피드백에서 여러 문제 요소들을 분리하고, 문제의 구조를 분석해보자. 그러면 고객이 제안한 방법보다 더 나은, 근본적인 해결책을 찾을 수 있다.
신뢰와 솔직한 대화, 그리고 더 나은 선택
협업하다 보면 이런 고민이 생길 때가 있다.
“내가 이런 이야기를 해도 될까? 반대 의견을 내도 괜찮을까?”
여기에는 중요한 전제가 필요하다. 우리가 서로 다른 의견을 나누는 이유는 더 나은 선택을 하기 위해서다. 더 확실한 대안을 찾기 위해서다. 그리고 이것이 가능한 이유는 상대방과 함께라면 더 좋은 결정을 내릴 수 있다는 신뢰가 있기 때문이다.
다른 의견을 내는 것은 단순히 반대하는 것이 아니다. 고객에게 더 나은 가치를 전달할 수 있다고 믿기 때문에, 기꺼이 다른 관점을 제시하는 것이다. 이것은 상호 신뢰를 기반으로 한다. “우리는 같은 목표를 향해 가고 있고, 서로를 존중한다"는 믿음이 있기에 솔직하게 생각을 나눌 수 있다.
건강한 토론과 다양한 관점의 공유는 팀을 더 강하게 만든다. 서로 다른 생각을 존중하면서도 최선의 답을 함께 찾아가는 과정, 그것이 진정한 협업이다.
쉬운 선택과 어려운 선택
일하다 보면 두 가지 선택의 순간과 마주한다. ‘쉬운 선택’과 ‘어려운 선택’이다.
쉬운 선택은 이런 것이다:
- “다른 회사에서 잘 쓰고 있으니까 우리도 도입하자”
- “여러 블로그에서 베스트 프랙티스라고 하니까 따라하자”
이런 선택이 항상 나쁜 것은 아니다. 빠르게 시작하는 데는 도움이 된다. 하지만 우리의 상황, 우리의 고객, 우리의 문제에 정말 맞는 해결책인지는 다시 생각해봐야 한다.
좋은 회사들을 보면, 프로덕트 관점, 기술적 관점, 조직적 관점에서 깊이 고민한다. 다른 곳의 방식을 참고는 하지만 그대로 따라하지 않는다. 실제로 도입하고 적용할 때는 “이렇게 결정했으니 따라하세요"가 아니라, 충분히 과정을 공유하고 함께 고민하는 시간을 갖는다.
기술 선택도 마찬가지다. “시장에서 많이 쓰니까 우리도 쓰자"가 아니라, 우리 상황에서 왜 필요한지, 어떤 문제를 해결할 수 있는지 충분히 검토한다. 때로는 직접 도구를 만들기도 하고, 기존 방식을 우리 방식으로 개선하기도 한다.
프로덕트 의사결정도 비슷하다. 예를 들어 중고거래 서비스에서 전국 검색은 ‘쉬운 선택’이었을 것이다. 하지만 좁은 지역 기반 거래라는 ‘어려운 선택’을 했을 때, 더 의미있는 연결이 만들어졌다. 별점 대신 ‘매너온도’라는 개념을 만든 것도, 우리 고객을 관찰하고 고민한 결과다.
단순히 따라하는 것을 넘어, 깊이 고민하고 우리만의 답을 찾는 과정. 이것이 차별화된 서비스와 문화를 만든다. 이런 환경에서 일하는 것 자체가 팀원들에게 동기부여가 되고, 좋은 인재들이 모이는 이유가 된다.
중요한 것은, 같은 방법이라도 상황에 따라 정답이 될 수도, 아닐 수도 있다는 점이다. 늘 우리의 상황에서 다시 생각해보고, 문제를 해결해가는 과정 자체에서 즐거움과 성장을 느낄 수 있어야 한다.
현장을 가장 잘 아는 사람은 실제로 일하는 팀원이다.
큰 그림은 리더가 잘 볼 수 있다. 하지만 디테일과 실제 현장의 느낌은 직접 일하는 팀원이 더 깊이 알고 있다. 예를 들어 채팅 기능을 개발하는 상황이라면, 구체적인 기술적 과제와 해결해야 할 세부 문제들은 실제로 손으로 만드는 팀원이 가장 잘 안다.
디자인의 미묘한 차이, 코드의 구조, 고객 피드백의 뉘앙스. 이런 디테일들은 현장에서 직접 경험하는 팀원이 가장 섬세하게 이해하고 있다. 리더가 고객의 전반적인 상황을 전달할 수는 있지만, 그것을 실제 프로덕트로 구현하면서 필요한 디테일과 품질을 높이는 감각은 팀원의 몫이다.
리더는 이 사실을 인정하고 존중해야 한다. 팀원들이 자신의 전문성을 발휘하며 유기적으로 협력할 수 있도록 환경을 만들어주는 것, 그것이 리더의 역할이다.
하지만 동시에, 전체 방향에 대한 정렬도 중요하다.
팀원이 디테일을 가장 잘 안다는 것과, 조직 전체의 방향성에 힘을 모으는 것은 별개의 문제다. 때로는 우리 팀의 의견이나 판단과 다른 방향으로 전사적 결정이 내려질 수 있다. “이건 우리 관점에서는 최선이 아닌 것 같은데"라고 생각할 수도 있다.
이럴 때 필요한 것이 ‘Disagree & Commit’ 문화다. 의사결정 과정에서는 충분히 우리의 의견과 관점을 제시하고, 더 나은 방향을 찾기 위해 적극적으로 토론한다. 하지만 최종 결정이 나면, 설령 그것이 우리의 의견과 다르더라도 그 방향에 힘을 모은다.
왜냐하면 조직 전체적으로는 우리가 보지 못하는 더 큰 그림이 있을 수 있기 때문이다. 우리 팀의 최선이 전체 조직의 최선과 항상 일치하는 것은 아니다. 전사적으로 필요한 방향이라면, 우리의 전문성을 그 방향 안에서 최대한 발휘하는 것이 더 가치 있을 수 있다.
결국 중요한 것은 균형이다. 우리의 전문성과 판단을 존중받으면서도, 더 큰 목표를 위해 함께 움직일 줄 아는 것. 이 두 가지가 함께 있을 때 팀도 성장하고 조직도 앞으로 나아갈 수 있다.
피드백은 자주, 작게, 그리고 꾸준히
6개월에 한 번 성과평가 때 모든 피드백을 한꺼번에 쏟아내면 어떻게 될까? 팀원이 실제로 그 많은 것들을 한 번에 개선할 수 있을까? 현실적으로 어렵다. 개발할 때 애자일 방식을 선호하는 것, 코드 리뷰에서 작은 Pull Request를 선호하는 것과 같은 이치다.
피드백도 마찬가지다. 프로젝트에 마일스톤을 두듯, 피드백도 자주, 작게 나눠서 주는 것이 효과적이다. 팀원들이 보여주는 작은 신호들 - 만족감이나 불편함 - 을 잘 읽고, 2주 정도마다 피드백을 나누면 6개월이 지났을 때 놀라운 변화를 볼 수 있다.
완벽한 사람은 없다. 우리 모두 성장하는 중이다. 한 번에 모든 것을 개선하려 하기보다는, 조금씩 나아질 수 있는 것에 집중하는 게 좋다. 예를 들어 한 달은 기술 역량에 집중해서 피드백하고, 다음 달은 협업 스킬에 집중하는 식이다. 한 번에 한 가지씩 집중하면 더 확실한 개선이 일어난다.
주기적으로 작은 변화들을 관찰하고 기록해두었다가, 다시 피드백으로 연결하면 장기적으로 좋은 습관이 만들어진다. 이렇게 조금씩 쌓인 피드백과 개선이 1년이 지나면 팀원들을 훨씬 더 성장시킨다.
인내심을 갖고, 꾸준히 작은 피드백을 주고받는 것. 이것이 팀과 개인 모두를 성장시키는 방법이다.
그리고 이것은 리더인 나 자신에게도 똑같이 적용된다. 나도 자주 피드백을 받고, 작은 변화들을 쌓아가며 성장해야 한다.