고객 문제를 모른 채 코드를 짜는 건 아무도 읽지 않을 책을 쓰는 것이다
베트남으로 출장 오기 전 공항에서 후배녀석(조대협이란 필명)이 본인 유튜브 콘텐츠(아래 참고)를 올렸길래 급하게 작성한 내용입니다.
2024년도에는 기존의 파편화에 따른 기술부채로 인하여 이를 하나의 기술 영역으로 합치는 것을 전략으로 삼았었습니다. 올해는 이제 그 기술을 기반으로 고객을 담아야 할 2025년도였습니다.
여기서는 클라우드에 대해 적어보겠습니다.
우리 회사의 입장에서 클라우드는 OpenStack을 기반으로 하는 확장형 아키텍처를 만들게 되고, 그 위에 고객의 버티컬(공공/금융 등) 영역에 서비스(AI, SaaS 등)를 올리는 작업이 그것입니다.
클라우드본부에는 신임 본부장께서 조인하셔서 현재의 시장 트렌드와 고객에게서 발생하는 니즈를 반영하는 서비스를 기획하고, 이를 기술로 펼쳐서 기술본부에서는 제품화(productize)시키는 작업을 하고 있습니다.
클라우든 본부는 고객의 접점에서 움직이게 됩니다. 현재 서비스에 대한 재정의(re-framing)를 통해 현재 가지고 있는 이슈 뒤의 진짜 숨은 문제를 찾아 이를 NEXT에 반영하는 작업을 해야 합니다.
여기서 의심해야 할 것은 “원래 이렇게 해왔었다”라고 구성원들의 말입니다. 이는 개인의 판단일 수 있는 상황이므로 실제 데이터로 검증해야 하고, 사용자 인터뷰, 실험을 통해 모든 시나리오를 따져봐야 합니다. 위험한 것은 의사결정권자의 직감일 수 있습니다. 맞으면 영웅이 되겠지만 실패하면 회사에 큰 위험을 초래할게 분명하거든요.
대부분 기업에서 가지고 있는 실패 사례들이 고객 관점 결여라는 공통점을 가지고 있다고 봅니다. 특정 기술을 논하기 전에(이게 블루오션이더라도) “세상에 꼭 필요한 문제인지” 확인(어떤 방법으로든 조사를 해야겠죠)해 보는 게 중요합니다.
우리는 개발/엔지니어링을 하는 사람들이니까 고객은 몰라도 된다? 절대 이런 생각 안 하셨으면 좋겠습니다. 고객을 무시하는 건 개발한 내용의 성과가 무효화되는 치명타를 얻게 됩니다. 결국 이는 회사 매출/이익의 하락으로 이어지고 안 좋은 결과를 초래하게 됩니다.
고객 인터뷰, 요구사항 등을 현장에서 듣는 것도 굉장히 중요합니다. 모든 DoD(Definition of Done)에는 고객지표가 반드시 포함되어 있어 개발된 기술이 고객에게 미치는 비즈니스 영향도(business impact)를 반드시 체크하셔야 합니다. 동영상에서 이야기하는 크리티컬 싱킹(Critical Thinking: 주어진 정보를 그대로 믿지 않고, ‘왜?’ ‘정말일까?’를 따져 논리와 증거로 판단‑결정을 내리는 사고법)을 해야 합니다.
“기술은 고객이 써줄 때만 가치가 생깁니다.
고객 문제를 모른 채 코드를 짜는 건 아무도 읽지 않을 책을 쓰는 것과 같습니다.”