제품 엔지니어링의 부상

주요 시사점

• 소프트웨어 엔지니어링의 제품 엔지니어링은 기술적 우수성과 고객 중심 사고를 결합한 것으로, 코드를 제공하는 것을 넘어 실제 사용자 문제를 해결합니다.

• 팀은 선형 핸드오프 방식에서 벗어나 엔지니어가 탐색, 디자인 및 유효성 검사 과정에 참여하는 지속적 학습 루프로 전환하고 있습니다.

• 이 접근 방식은 기능 도입, 팀 참여 및 고객 요구와의 정렬을 촉진해 줍니다.

• 엔지니어가 결과에 대한 주인 의식을 가지고 고객과 긴밀하게 협업하며 제품 영향력을 최대화하는 문화를 조성합니다.

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에서 어떻게 이런 혁신을 이루었는지 자세히 알고 싶습니까? 제품 엔지니어링의 마법: 고객의 문제를 고객이 애용하는 기능으로 바꾸기 웹 세미나를 확인해 보세요. 이 웹 세미나에서는 우리의 여정을 자세히 살펴보며 팀에 구현할 수 있는 실용적인 전략 및 의식을 공유합니다.