Last updated on 2월 8th, 2021 at 10:31 오후

시작하면서

지난 4월 22일~23일, 국내 개발자 커뮤니티 중 가장 규모가 크고 활발한 한국 스프링 사용자 그룹에서 매년 개최하는 “스프링 캠프 2017”이 열렸다. 필자는 이 행사에 연사로 참여하여 “Build the RIGHT thing – 린 & 애자일 개발 이야기 @ Pivotal Labs”라는 주제로 올바른 소프트웨어 제품 개발 사례를 공유하는 시간을 가졌다. 필자가 작년에 3개월간 샌프란시스코에 위치한 피보탈 랩스 본사에서 직접 경험한 것에 대해 다루었으며, 일반적으로 국내에서 진행하는 소프트웨어 개발 프로젝트와는 사뭇 다른 사상과 문화, 프로세스에 대해 말했다. 발표 이후에 몇 가지 질문을 받았는데, 그 중에 한 질문에 대한 이야기를 해볼까 한다. 질문은 아래와 같다.

“린이나 애자일은 개발자가 기획이나 디자인과 같은 여러 방면에 모두 참여를 하게 되는데, 이렇게 되면 개발자들이 쉽게 지치게 되는 것 같습니다. 개발기간에 비개발자들과 개발자들간에 좀 더 효율적인 협업 방안이 없을까요?”

필자가 지난 번에 기고한 “소프트웨어 개발/프로그래밍 분야에서 비전공자가 가져갈 수 있는 강점”의 연장선에서 이 질문에 대한 답을 할 수 있을 것이라고 생각했다. 앞 글은 소프트웨어 개발 프로젝트에서 개발을 직접 하지 않는 멤버들의 역할과 책임에 대한 이야기를 했다면, 이번 글에서는 소프트웨어 개발을 위한 이상적인 팀 구조와 협업 방안에 대해서 이야기해보고자 한다.

피보탈 랩스와 소프트웨어 제품 개발을 위한 역할

피보탈 랩스는 1989년에 설립되었고, 샌프란시스코에 본사를 둔 소프트웨어 컨설팅 회사이다. 다른 회사와의 가장 큰 차이점은 고객사에 방문하여 컨설팅을 하는 것이 아니라, 랩에 고객들을 초대하여 본인들이 일하는 문화, 프로세스, 기술들을 페어링(Pairing)을 통해 직접 전수한다는 점이다. 그들은 원칙을 잃지 않는, ‘제대로 된’ 소프트웨어 개발 방법론을 전파하고 컨설팅을 받은 고객은 회사로 돌아가 그 방법을 전파하게 된다. 그렇게 “온 세상에 소프트웨어를 만드는 법을 알려주겠다.(We transform how the world builds software)”라는 당찬 슬로건을 내세우고 있는 회사다. 피보탈 랩스는 지금까지 트위터, 그루폰, 넷플릭스와 같은 수많은 실리콘밸리의 기업들에게 소프트웨어 제품 개발을 컨설팅했으며, 많은 굴지의 기업들이 피보탈 랩스를 벤치마킹했다. 심지어는 사무실의 구조나 책상 배치까지 따라했을 정도다.

이들이 소프트웨어 개발 팀에 필요하다고 말하는 역할은 딱 3가지이다. 제품 설계자(Product Designer), 제품 관리자(Product Manager) 그리고 개발자(Developer)이다. 앞 글에서 소개한 국내의 일반적인 프로젝트의 역할들에 비해서 굉장히 적다.

이미지 출처: https://www.slideshare.net/ChrisCho2/springcamp-2017-build-the-right-thing-pivotal-labs-sf

이러한 3 가지 역할로 구성된 소프트웨어 개발 팀은 국내에서는 쉽게 찾아보기 어렵다. 이는 한국의 소프트웨어 개발 프로젝트들이 대부분 고객이 외주 업체에게 의뢰하여 개발을 하는 “프로젝트”가 대부분이기 때문이다. 하지만, 본인들의 아이디어로 시작하여 독특한 서비스나 제품을 제공하는 스타트업인 경우에는 위 같은 모습을 종종 찾아볼 수 있다. 그야말로 “제품”을 만드는 회사들이기 때문이다. 그럼 위 3가지 역할이 국내의 전통적인 소프트웨어 개발 현장과 비교하여 어떤 부분이 다르고, 어떤 부분에서 강점을 가지는지 함께 살펴보자.

제품의 전부를 디자인하는 제품 설계자 (Product Designer)

제품의 설계를 책임지는 사람이다. 단순히 UI/UX를 디자인하는 사람이 아니라 제품의 기저에 깔려 있는 가정들을 추출하여 우선순위를 정하고, 이를 증명하기 위해 필요한 모든 활동을 주도적으로 수행한다. 인터뷰가 필요하다면 인터뷰 대상자를 선정하고, 질문 리스트 준비 및 인터뷰 수행을 한 다음, 인터뷰 대상자로부터 얻은 통찰들을 팀에 전달하는 역할을 한다. 이렇게 팀 전체가 배운 정보를 바탕으로 UI/UX 디자인 작업 및 고수준의 프로토타입을 만든 뒤, 다시 사용자의 피드백을 받는 중요한 역무를 수행한다.

국내 소프트웨어 개발 프로젝트에서 UI/UX에 대한 디자인은 외주 업체에 위임하는 경우가 많다. 그렇다보니 대부분의 디자이너들이 본인 회사의 제품이 아니라 고객의 의뢰에 의해 수동적으로 디자인을 하는 경우가 대부분이고, 그런 디자인으로 탄생한 화면들을 쓰는 사용자(End-user)는 ‘디자이너들의 고객의 고객’인 경우가 많다. 실제 소프트웨어를 사용하는 사용자가 원하는 제품을 만들기가 여간 쉽지 않은 것이다. 그리고 전문적인 UX 랩이 아닌 이상, 디자이너들이 고객을 직접 만나서 인터뷰를 하거나 프로토타입을 만들어서 사용자 대상으로 테스트를 하는 것도 찾아보기 힘들다.

그렇기에 필자는 제품 UI/UX의 디자인 및 퍼블리셔 역할을 하는 엔지니어들이 ‘직접’ 고객들을 만나고 연구 및 조사하는 “고객 개발”과 관련된 지식과 경험을 쌓는 것이 중요하다고 생각한다. “고객 개발”은 스티브 블랭크 교수가 주장하는 모델로, 잠재적인 고객과의 끊임없는 접촉, 제품을 가능한 빨리 출시하며 지속적으로 제품 개발 이터레이션을 해나가면서 고객의 피드백을 기반으로 해서 제품을 발전시켜나가는 방법을 소개하고 있다. 이를 제대로 하기 위해서는 어떤 사람들을 만나고, 무엇을 어떻게 물어봐야 하는지, 이를 통해 어떻게 배울수 있는지 구체적인 방법을 알아야한다. 필자가 번역한 “Talking To Humans 한국어판”이 이러한 기법들을 잘 설명하고 있으니 관심있는 분들은 찾아가 보기 바란다.

제품의 요구사항부터 인수 테스트까지 책임지는 제품 관리자 (Product Manager)

제품 관리자(Product Manager)는 프로젝트 관리자(Project Manager)와 자주 비교되곤 한다. 특히, 국내에는 프로젝트 기반 소프트웨어 개발이 대부분이라 프로젝트 관리자는 쉽게 찾아볼수 있지만, 제품 관리자는 좀처럼 찾아보기 힘들다. 두 역할을 영화를 제작하는 과정과 비교해보자.

영화를 제작하기 위해서는 영화 제작사가 필요하다. 영화에 대한 대략적인 컨셉과 제작 기간, 비용, 촬영을 도와줄 스태프 등을 섭외하고 영화가 잘 제작되도록 지원하는 역할을 할 것이다. 이렇게 영화 제작 자체를 관리하는 사람을 우리는 “프로젝트 관리자”라고 할 수 있다. 이번에는 영화 감독 입장을 살펴보자. 감독은 본인이 찍고자 하는 영화를 좋은 작품으로 만들기위한 모든 활동을 수행한다. 본인이 검토 혹은 작성한 시나리오를 영화로 담아내기 위해 본인의 사상이나 경험, 연출력 등을 총동원하여 영화라는 제품에만 올인하는 사람인 것이다. 이러한 역할을 “제품 관리자”와 같다고 볼 수 있다.

제품 관리자는 소프트웨어 개발을 하기 위한 요구사항을 명확하게 정의하고 우선순위를 정하는 중요한 위치에 있다. 이렇게 정의된 요구사항을 사용자 스토리로 작성을 하게되며, 구현이 완료되었을 때 확인해야 할 인수 테스트 조건을 최대한 상세하게 정의한다. 그리고 개발이 완료되면 기능 구현이 제대로 되었는지 최종적으로 확인한다. 품질 관리나 테스터의 역할까지 겸하고 있다고 볼 수 있다.

또한, 제품 개발을 위해 검증해야 할 가정들이나 위험 요소들을 파악하고, 이 또한 우선순위를 잡아서 테스트하거나 제거하는 역할을 한다. 제품 설계자와 밀접하게 협업해야 하며, 개발자에게 전달할 요구사항 상세사항 및 검증이 완료된 화면을 전달하여 커뮤니케이션 오류로 인한 재작업을 최소화하는 중심 역할이다.

제품을 직접 구현하는 개발자(Developer)

드디어 개발자다. 개발자는 말 그대로 제품을 직접 구현하는 주체이다. 피보탈 랩스에는 프론트엔드, 백엔드나 특정 기술(자바, iOS, 안드로이드 등) 심지어는 퍼블리싱 작업까지 개발 영역을 딱히 구분하지 않는다. 대신, 전체 인력이 테스트 주도 개발(TDD)을 필수로 생각하고 행동에 옮기며, 100% 짝 프로그래밍*을 실천한다. 게다가 매일 매일 짝을 바꿔가며 특정 개발자에게 도메인 지식이나 소스 코드가 의존되는 현상을 최소화한다. 소스 코드에서만 Loose coupling을 실천하는 것이 아니다! 이를 통해 한 제품을 개발하는 개발자 전원은 전체 소스 코드를 최소한은 한번씩 읽거나 작성하는 데 동참하게 되며, 누군가가 갑작스럽게 팀에서 떠난다 한다해도 전혀 문제 될 것이 없다. 실제로 피보탈 랩스에서는 개발자가 떠나기로 결정이 나면 인수인계 기간 없이 바로 다른 프로젝트에 투입되기도 한다. 많은 프로젝트의 실패 요인이 “잦은 개발 인력 교체”인 것을 감안하면, 가볍게 넘어갈 문제는 아니라고 본다.

개발자는 적절한 기술을 선정하여 품질이 높은 제품을 개발하는 책임을 가지고 있으며, 동시에 제품 관리자나 제품 설계자에 제품 구현 가능성에 대한 기술적인 조언을 해야 하며, 팀 단위로 이루어지는 활동에 모두 참여한다. 개발자 역시 제품에 대한 비전과 방향성, 본인이 작성하는 한 줄의 코드일지라도 왜 작성이 되는지 분명하게 알아야하는것이 이 곳의 원칙이다.

균형 잡힌 팀

이 팀의 책임자는 누구 일까? 혹시 제품 관리자라고 생각하고 있지는 않은가?

그렇지 않다. 이 3개의 역할은 “하나의 제품 팀”을 이루며, 모두가 제품에 대한 책임을 함께 진다. 모두 평등한 입장에서 서로 의지해가며 개발이 진행이 되어야 한다. 혹시 어떤 이슈나 문제가 생기면 특정 인력을 비난할 것이 아니라 모두 합심하여 해결해나가야 한다. 마치 아래 그림의 3개의 날개가 같은 크기로 균형이 잘 잡혀야 매끄럽게 프로펠러가 돌아가는 것과 같은 이치이다. 피보탈 랩스에는 Balanced Team 즉 균형이 잡힌 팀을 강조하고 있으며, 오너십을 모두 나눠 갖아야 한다고 말한다. 피보탈 랩스에서 이야기하는 균형이 잡힌 팀에 대한 강연을 보고 싶다면, 피보탈 랩스 피플 팀의 디렉터였던 Janice Fraser님의 유투브 동영상을 참고하기 바란다.

출처 : https://www.slideshare.net/ChrisCho2/springcamp-2017-build-the-right-thing-pivotal-labs-sf

소프트웨어 개발을 위한 가장 이상적인 팀 구조와 협업 방안

이러한 구조 안에서 요구되는 각 포지션의 지향점은 무엇일까?

소프트웨어 개발에서 이루어지는 많은 활동 중 소스 코드를 작성하는 비용이 가장 비싸다. 제품 설계자가 프로토타입을 만드는 것보다 비싸며, 제품 관리자가 사용자 스토리를 상세하게 작성하는 비용보다 더 비싸다. 가장 비싸다는 말은 완성하는 데 시간이 더 오래 걸린다는 의미며, 고치기가 가장 어렵다는 것이다. 그렇기 때문에 이 작업에 가장 많은 품이 필요하다. 그리고 개발자 혼자만 하기에는 버거운 경우가 많다. 프로젝트를 통해 원하는 성과를 내기 위해서는 이 작업에서도 제품 설계자와 제품 관리자의 도움이 절대적으로 필요하다. 하지만 위에 언급했듯이 그들은 개발자가 아니다. 소스 코드를 작성하는 일을 하지 않는다. 그렇다면 어떻게 도움을 줄 수 있을까?

제품 설계자와 제품 관리자는 개발자가 구현에 들어가기 전에 요구사항 수집 및 정제, 구체화하는 작업과 프로토타입을 제작하여 실제 사용자에게 검증하는 작업에 최선을 다해야 한다. 가령, 제품 관리자가 본인 판단에 사용자가 필요할 것이라고 생각하는 기능을 자세하게 기술한다고 해보자. 이 기능은 어쩌면 사용자에게 전혀 쓸모 없는 기능일 가능성이 있다. 이 기능을 개발자가 구현까지 한 다음에 쓸모가 없다는 것을 알게되었다고 해보자. 이 기능에 대해서 정성을 들여서 작성한 사용자 스토리나 화면 디자인, 구현이 완료된 소프트웨어에 들어간 비용은 낭비가 되는 것이다. 그리고 이 작업을 한 당사자들에게도 무척 힘빠지는 일이 아닐수 없다. 열심히 노력하여 만든 내 자식과도 같은 제품이 알고보니 쓸모가 없다니 이게 무슨 날벼락이란 말인가. 팀의 사기를 저하시키는 데에도 적지 않은 영향을 끼친다.

여러 고민끝에 ‘필요할 것 같다’라는 기능의 리스트가 준비가 된다면, 그 중에 어떤 기능이 사용자에게 가장 필요한 기능인지 고민해보자. 그리고 선별 작업이 끝나면, 제품 설계자와 함께 프로토타입을 작성해보자. 이 프로토타입은 소스 코드를 작성하여 소프트웨어를 만드는 작업이 아니다. 종이에 그린 그림일수도 있고, PPT에 작성한 단순한 그림일수도 있다. 최소한의 비용을 사용하되 기능이 필요성을 검증하기에는 충분해야 한다. 프로토타입 제작이 완료가 되었으면 실제로 제품을 사용할 사용자를 만나보자. 사용자를 고르고 어떤 질문을 해야 할지, 개방형 질문을 통해서 사용자의 이야기를 듣는 것은 제품 설계자의 책임이다. 프로토타입을 보여주면서 사용자가 흥미를 갖는지, 쉽게 사용을 할 수 있는지 등에 대한 확신을 얻어야 한다. 여러 사용자를 만나서 패턴을 분석해보면 해당 기능이 정말 쓸모가 있는지 검증할 수 있다. 이렇게 검증이 완료된 화면에 대해서 개발자에게 전달하기 위한 사용자 스토리(상세 요구사항)를 적어보자. 누가 보더라도 명확하게 내용을 파악할 수 있어야 한다. 그리고 개발자가 구현이 완료되었을 때, 정말 제대로 구현이 되었는지 확인할 수 있는 인수 테스트 조건을 기재해보자. 이 인수테스트 조건은 개발자에게 훌륭한 테스트 케이스를 제공할 것이며, 개발자가 처음 의도대로 개발을 할 수 있는 이정표가 된다. 검증이 완료된 화면을 첨부하는 것도 잊지 말자.

이러한 활동들이 결국 개발자가 재작업하는 빈도수를 줄이게 하며 낭비를 최소화 할 수 있게 한다. 다르게 말하면 적시에 사용자에게 정말 필요한 솔루션을 제공할 수 있게 된다는 뜻이다. 그리고 이는 곧 전체 팀의 관점에서 보아도 훨씬 효율적이다. 재작업이나 쓸모없는 작업을 함으로써 팀이 받게 되는 스트레스나 사기저하 역시 최소화할 수 있다. 소프트웨어 개발은 결국 ‘사람’이 하기 때문에 이런 부분도 중요하게 생각해야 한다. 이렇게 균형이 잘 잡혀진 팀에서 투명하게 의견들이 교환되고, 짧은 주기로 동작하는 소프트웨어 개발을 사용자에게 딜리버리하게 된다면, 그야말로 “즐겁게” 소프트웨어를 개발할 수 있지 않을까.

마무리

개발자이든 아니든간에 꼭 기억했으면 하는 것이 있다. 소스 코드를 작성하는 행위 자체가 가장 비싸고, 가장 최후에 수행이 되어야 하는 것이라는 것을 말이다. 모두가 이 생각이 뒷받침된다면 생각보다 이상적인 팀을 꾸려 나가는 것은 어렵지 않을 수 있다.  우리나라에 이런 시스템이 적용되기란 쉽지 않을 것이다. 그리고 이러한 구조가 반드시 이상적이라고 말하는 것도 무리가 있다. 하지만 이러한 구조가 존재한다는 것을 알고, 구조의 장단점을 파악하여 작은 것이라도 지금 회사의 시스템에 적용할 수 있는 방안을 고민해보고 실천해본다면 훨씬 더 발전할 수 있을 것이라고 기대한다. 🙂

* 짝 프로그래밍 : Pair Programming의 한글식 표현으로, 한 개의 컴퓨터를 사용하여 두 명의 짝이 동일한 화면에 보여지는 하나의 소스 코드를 함께 작성하는 것을 짝 프로그래밍이라고 한다.

입문자부터 실무자까지, 패스트캠퍼스 프로그래밍 강의 자세히 보기 >>> [클릭]