Compass의 엔지니어링 팀에 문제가 발생했습니다. 우리 기능들은 엄밀히 따지면 괜찮았는데 뭔가 부족했습니다. 바로 진정한 고객 사랑이었습니다. 코드는 효율적으로 작성했지만 과연 문제를 제대로 해결하고 있었을까요?
Atlassian에서 Compass를 개발하는 선임 엔지니어링 매니저인 저는 몇 년 동안 이 도전과 씨름해 왔습니다. 우리 팀은 개발 팀이 소프트웨어 구성 요소 및 리소스를 대규모로 관리하는 데 도움이 되는 도구를 만드는 일을 담당합니다. 처음 입사했을 때 많은 엔지니어링 조직이 직면하는 패턴을 봤습니다. 우리는 기능 제공에는 능숙하지만 때때로 가치 제공에서 목표를 놓치는 경우가 있습니다.
저는 엔지니어링 문화가 어떻게 제품의 성패를 좌우하는지 직접 봤습니다. Atlassian은 단순히 소프트웨어 팀만을 위한 도구를 만드는 것이 아니라 고객이 매일 직면하는 동일한 문제를 직접 경험하며 해결하고 있습니다. 이 경험은 엔지니어링 문화를 혁신할 수 있도록 독특한 관점을 제공합니다. 그래서 저는 우리가 배운 점을 공유하는 데 특히 열정적입니다.
기존 엔지니어링의 단절
친숙하게 들릴 수도 있는 가상의 제품 팀에 대해 얘기해 보겠습니다.
Tina는 기술 우수성으로 유명한 선임 개발자입니다. Tina는 코드를 완벽하게 작성했지만 요구 사항을 받고 코드를 작성하고 기능을 배포하는 익숙한 순환에 갇혀 있었습니다. "외부와 단절된 상태에서 코드를 작성하고 있었습니다."라고 Tina는 인정합니다. "제가 만들고 있는 기능이 실제로 고객 문제를 해결하는지 아닌지 전혀 몰랐습니다." Tina는 고객 컨텍스트를 더 많이 알고 싶었지만 구현에만 집중하는 것에 한계를 느꼈습니다.
팀의 제품 디자이너 Rita도 어려움을 겪고 있었습니다. 완벽한 픽셀 디자인을 만드느라 몇 주를 보냈는데 개발 중 중요한 피드백을 받아서 대대적인 수정이 필요했습니다. "개발자들이 기술 제약을 지적할 때쯤이면 원래의 디자인 비전을 유지하기가 너무 늦은 경우가 많습니다."라고 Rita는 설명합니다. Rita는 개발 프로세스와 더 잘 통합되고 디자인을 더 일찍 검증할 방법이 필요했습니다.
제품 관리자 Paul은 모든 것을 하나로 조율하려고 애쓰고 있습니다. Paul은 상세한 요구 사항 문서를 작성하느라 셀 수 없이 많은 시간을 보냈지만 전달 과정에서 항상 무언가 누락되곤 했습니다. "전화 게임을 하는 것 같습니다."라고 Paul은 말합니다. "기능이 고객에게 도달할 무렵에는 처음에 상상했던 것과는 다른 기능으로 변해 있습니다." Paul은 엔지니어링 팀과 디자인 팀 간의 공동 작업 개선을 필사적으로 모색하고 있었지만 기존 핸드오프 프로세스로 인해 계속 장벽이 생겼습니다.
가장 어려운 역할은 아마도 프로그램 매니저 Rick의 몫이었습니다. Rick은 여러 팀의 종속성을 조율하면서 제공 속도와 품질 간의 균형을 맞추느라 밤을 새워야 했습니다. "팀들이 사일로에서 일할 때는 단순한 변경만으로도 몇 주씩 지연될 수 있습니다."라고 Rick은 말합니다. Rick은 팀 간 공동 작업을 촉진하고 가시성을 높일 방법이 필요했습니다.
이 모든 상황을 감독한 건 팀 운영 방식을 바꾸려고 고군분투한 엔지니어링 리더 Anna였습니다. Anna는 기술 우수성을 중시했지만 무언가 부족하다는 걸 알았습니다. "우리에겐 대단히 재능 있는 엔지니어들이 있지만 고객에게 필요한 가치를 지속적으로 제공하고 있지는 않습니다."라고 Anna는 말합니다. Anna는 팀 문화를 바꾸고 싶었지만 기존 개발 모델로는 기술 우수성과 고객 가치의 균형을 맞추기가 어려웠습니다.
이 팀의 경험은 소프트웨어 개발에서 더 광범위한 패턴을 반영합니다. 기존의 순차적 접근 방식은 체계적이고 예측 가능한 반면 제품 제작 측면과 사용 측면 간의 자연스러운 단절을 초래합니다.
문화: 혁신의 열쇠
"문화는 전략을 아침 식사로 먹는다." 이 인용문은 종종 경영 전문가 Peter Drucker의 말로 알려져 있지만, 2006년 Mark Fields가 포드의 워룸에 영구적으로 게시하면서 널리 알려졌습니다. 이 메시지는 그냥 눈에 띄는 문구가 아니리 기술 업계에서 반복해서 목격한 근본적인 진실을 담았습니다. 아무리 훌륭한 전략도 조직 문화와 충돌하면 실패한다는 진실입니다.
Compass에서 엔지니어링 문화를 바꾸기로 결정했을 때 우리는 '기술 우수성만으로는 충분하지 않다'라는 심오한 사실을 발견했습니다. 엔지니어와 고객 사이의 공백을 메워야만 했습니다. 수치가 이를 뒷받침합니다. 강한 문화를 보유한 기업들은 경쟁사에 비해 매출이 4배나 성장합니다.
Compass에서 우리의 혁신 여정이 이 사실을 완벽하게 설명합니다. 보통 6~8주에 걸쳐 완료하던 기존의 기능 수명 주기 프로세스를 고객 문제에 훨씬 더 가까이 다가갈 수 있는 반복 탐색 프로세스로 전환했습니다. 단순한 프로세스 변화가 아니라 '모든 것을 안다'는 사고방식에서 '모든 것을 배운다'는 사고방식으로 근본적으로 전환되었으며 모든 기능이 고객으로부터 배울 수 있는 기회가 되었습니다.
제품 엔지니어링의 진화
소프트웨어 엔지니어링은 전통적으로 체계적 디자인, 개발, 테스트를 통해 요구 사항을 작업 코드로 바꾸는 과정이었습니다. 엔지니어는 주로 기술 실행, 즉 효율적인 코드 작성, 시스템 유지 관리, 품질 보장에 집중합니다.
하지만 제품 엔지니어링은 소프트웨어 구축을 둘러싼 사고방식의 근본적인 변화를 보여줍니다. 소프트웨어 엔지니어링의 기술적 엄격함은 유지하면서도 중요한 요소인 고객에 대한 깊이 있는 이해 및 지속적 학습이 추가됩니다. 제품 엔지니어는 단순히 코드만 작성하는 것이 아니라 고객 문제를 발견 및 해결하고 제품 결정에 기술 인사이트를 제공하고 작업 결과를 책임지는 데 참여합니다.
기존 소프트웨어 엔지니어링 모델
기존 모델에서는 개발이 선형 경로를 따릅니다. 요구 사항은 제품 관리부터 디자인을 거쳐 요구 사항을 구현하는 엔지니어링 팀까지 이어집니다. 각 팀이 다음 팀으로 배턴을 넘기는 릴레이 경주라고 생각하면 됩니다.
우리 팀의 예전 워크플로도 이런 선형적 접근 방식을 반영했습니다.
- 요구 사항 문서 작성 및 승인에 수개월 소요
- 단절된 상태로 작업하는 아키텍트 및 디자이너
- 정확한 사양으로 코딩하는 엔지니어
- 마지막에 이루어지는 테스트 및 배포
- 여러 층을 통해 필터링되는 고객 피드백
이 접근 방식은 요구 사항이 안정적이고 변경 비용이 많이 들 때는 효과적이었습니다. 하지만 오늘날 빠르게 진화하는 시장에서는 더욱 적응력이 높고 고객 중심적인 방식이 필요했습니다.
제품 엔지니어링 지속적 루프
우리의 혁신은 이 선형 프로세스를 지속적 학습 루프로 대체하는 데 중점을 두었습니다. 개발을 릴레이 경주로 취급하지 않고 이제는 축구팀처럼 운영됩니다. 모두가 함께 움직이고 변화하는 조건에 적응하며 고객 가치 제공이라는 목표에 주목합니다.
새 모델의 특징은 다음과 같습니다.
- 엔지니어가 고객 인터뷰 및 탐색 세션에 참여
- 개발 및 디자인을 공동 작업으로 진행, 신속한 프로토타이핑 및 테스트
- 고객의 요구에 따라 검증되는 기술 결정
- 단순한 제공 마일스톤이 아니라 배움의 기회가 되는 배포
- 기술 메트릭뿐만 아니라 고객 영향을 통해 성공을 측정하는 팀
구현에서 책임 의식으로의 진화
Tina와 같은 엔지니어에게 이러한 혁신은 순수한 구현에서 진정한 책임 의식으로의 진화를 의미했습니다. 엔지니어는 이제 다음 역할을 수행합니다.
- 문제 정의 및 솔루션 탐구에 참여
- 초기 토론에 기술적 관점 제공
- 고객과 직접 가정 검증
- 코드 품질뿐 아니라 기능 결과까지 책임
- 비즈니스 메트릭 및 시장 영향 추적
결과는 명백했습니다. 이 모델을 채택한 조직은 기존 엔지니어링 접근 방식을 사용하는 조직보다 시장 출시 시간도 더 빠르고 기능 채택률도 높습니다. 아마도 더 중요한 변화는 팀 참여도가 높아지고 기술 결정이 개선되었으며 기술 솔루션 및 고객 요구 간의 긴밀한 정렬이 이루어졌다는 사실입니다.
이 혁신을 지원한 방법
엔지니어의 업무 방식을 바꾸려면 단순한 사고방식의 전환뿐만 아니라 올바른 기반이 필요했습니다. 우리 팀에게 이 토대의 중요한 부분은 Jira Product Discovery였습니다. 우리는 이 도구를 통해 일상 워크플로에 고객 컨텍스트를 자연스럽게 도입했습니다.
우리가 해결해야 할 첫 번째 과제는 누구나 고객 인사이트에 접근할 수 있도록 하는 것이었습니다. 전에는 고객 피드백 및 제품 요구 사항을 Confluence 문서, Slack 스레드, Jira 티켓에서 확인해야 했습니다. Jira Product Discovery는 이 모든 컨텍스트를 개발 워크플로에 직접 가져왔습니다. 엔지니어들은 이제 고객 인터뷰, 피드백 세션, 사용 패턴을 개발 작업과 함께 볼 수 있어 고객의 요구를 추상적이고 멀게 느끼는 대신 구체적이고 즉각적으로 인식할 수 있습니다.
접근성은 우리 팀의 공동 작업 방식을 근본적으로 변화시켰습니다. Rita 같은 디자이너는 새 디자인을 만들 때 엔지니어가 보고 이해할 수 있는 고객 불만 사항과 직접 연결시킬 수 있었습니다. Paul은 기능의 우선 순위를 정할 때 고객에게 미치는 영향을 기술적 복잡성과 쉽게 연결하여 더 나은 정보를 바탕으로 결정을 내릴 수 있었습니다. 가장 중요하게도 엔지니어가 마침내 전체 그림을 볼 수 있게 되었습니다. 우리가 무엇을 만들고 있는지뿐만 아니라 그것이 고객에게 왜 중요한지, 그리고 업무에 어떤 영향을 미칠지까지 이해하게 됐습니다.
비슷한 변화를 고려하는 팀의 경우, 기술 우수성 및 고객 중심 중 하나를 선택하는 것이 아니라 이들을 하나로 모아 고객이 진정으로 애용하는 제품을 만드는 게 중요하다는 사실을 기억하세요. 엔지니어가 고객의 요구를 깊이 이해하면 더 나은 기술 결정을 내리고 더 세련된 솔루션을 설계하며 업무의 직접적인 영향을 볼 수 있어 업무에서 더 큰 의미를 찾을 수 있습니다.
Atlassian에서 어떻게 이런 혁신을 이루었는지 자세히 알고 싶습니까? 제품 엔지니어링의 마법: 고객의 문제를 고객이 애용하는 기능으로 바꾸기 웹 세미나를 확인해 보세요. 이 웹 세미나에서는 우리의 여정을 자세히 살펴보며 팀에 구현할 수 있는 실용적인 전략 및 의식을 공유합니다.