제2장 소프트웨어 개발 자체를 어떻게 해야 할까?

Chapter 2 소프트웨어 개발 자체를 어떻게 해야 할까?

들어가며

소프트웨어 개발을 다룰 때, 많은 사람들이 놓치는 부분이 두 가지였습니다. 첫째, 불확실성이 많다는 것입니다. 둘째, 그럼에도 불구하고 ‘공학적으로 탄탄’해야 한다는 것입니다.

불확실성을 다루는 방법

EoA: Essence of Agility

김창준님의 ‘가장 효과적인 애자일 프레임워크 13가지'에서 나옴

EoA(Essence of Agility) 불확실성이 높은 상황에 효과적으로 대응하는 전략

» Avoid big loss: 큰 손실 피하기
- Redundancy: 중복을 허용하기
- Detect early: 문제를 빠르게 감지하기
- Asymmetry: 비대칭성 확립하기(밑져야 본전 구조)

» Learn as you go: 계속 배우면서 나아가기
- Feedback & adapt: 피드백을 받고 재조정하면서 나아가기
- Receiving new info: 새로운 정보 얻기
- Many projects, sequential: 많은 프로젝트를 하는 것처럼 순차적으로 나아가기

» Achieve critical early with less effort: 핵심적인 것을 일찍 적은 노력으로 성취하기
- Piecemeal & center first: 가장 중요한 것을 먼저 하되 작은 단위로 쪼개서 진행하기
- Work with stakeholders: 이해관계자와 함께 일하기

» Be flexible: 유연하게 대처하기
- High ground for change: 변화에 유리한 지점 선점하기
- Real option: 선택의 옵션 만들어 두기
- Diversify: 외부 자극에 다양하게 대응하기
- Slack: 여유 확보하기
- Generative Sequence: 생성적 순서대로 하기

구체적으로 이거 해라 저거 해라라는 실천 방법들을 제시하는 것은 사실 쉽지 않습니다. 조직이 다르고 사람들의 지식수준이 모두 다르기 때문 입니다. 그렇기 때문에 현실적으로 애자일 코치들이나 숙련된 프로그램 매니 저들조차 다들 자신만의 방법을 만들어 내서 사용합니다.

그런데 우리는 이상한 것을 늘 하려고 한다, 너무나 이상하게도

우리는 내부 협력을 통해 관련된 모든 구성 원들이 승리하는 시스템을 구축해야 합니다. 이를 위해서는 각 구성원이 가진 능력과 역할을 최대한 발휘할 수 있도록 해야 합니다.

사회적 시스템이 인간의 성향보다 더 중요하며, 이를 통해 성과를 내는 사람과 그렇지 않은 사람을 구별할 수 있습니다. 협력과 선한 의지를 기반으로 성과를 창출하려면 올바른 시스템이 필요합니다.

소프트웨어 개발은 시작하면 계속해야 한다

프로덕트 로드맵/릴리즈 플랜

소프트웨어의 단종 (end of life, EOL)이 선언될 때까지는 지속적으로 개발 및 개선을 진행합 니다. 이 과정에서 제품이 어떤 단계로 만들어져야 하는지를 정의하는 것이 프로덕트 로드맵입니다. 프로덕트 로드맵을 기반으로 하여 릴리즈 플랜을 작성합니다. 릴리즈 플랜은 각 개발 단계의 목표, 일정, 책임자 등을 명확히 정의하여 개발을 효율적으로 진행하는 데 도움이 됩니다.

프로덕트 로드맵 만들기

프로덕트 로드맵이란 “비즈니스 목표와 프로덕트 전략을 지원하고 프로덕트 개발을 가시화하기 위해서” 만드는 큰 계획을 말합니다.

로드맵은 계속 변화할 수 있으며 로드맵, 마일스톤이 조금씩이라도 바뀌지 않는다면 문제 신호로 간주할 수 있습니다. 목표를 끝까지 잡고 가는 일관성은 지켜져야 합니다. 그러나 그 달성 과정에서 고객의 목소리에 따라서 혹은 여러 가지 상황에 따라서 달라질 수있는 유연함도 가져야 합니다. 정말 달성해야 하는 가치는 변해서는 안 되지만 변화에도 열려 있어야 합니다.

릴리즈 플랜 만들기

릴리즈 플랜은 이제 프로덕트 로드맵에 따라 제품을 어떻게 만들지 계획을 세우는 것입니다.

프로덕트 로드맵/릴리즈 플랜 예제

예제는 예제일 뿐

계획은 계획입니다: 실제 진행하면서 조금씩 수정될 수 있습니다. 마음을 열어 놓으세요.
모든 일정은 모든 구성원들의 합의하에 만들어져야 합니다
근간을 흔들지 마세요
이래도 달성이 되는 것도 있고 안 되는 것도 있을 것입니다

우리가 만들 것 합의하기

무엇을 만들지는 이야기했나요?

코드가 나오기 전에 ‘무엇이 나와야 하는지’를 합의를 해야 합니다. 물론 그래도 실제 원했던 제품이 아닐 수도 있습니다. 그러나 뭐가 나와야 할지 손바닥만 한 엽서 한 장만으로는 알 수 없습니다. 결국 긴 글로 써야 합니다.

하일마이어 질문(Heilmeier catechism)

하일마이어는 액정 크리스털 디스플레이 (liquid crystal display, LCD)를 개발한 전자공학자로, 1970 년대 ARPA (DARPA전신)의 전설적인 과제 관리자였습니다. 하일마이어 질문은 그가 만든 과제 제안서에 있는 9가지 질문으로, 국방고등연구계획국 (DARPA)이기술혁신을 이끌어내는 데 중요한 역할을 하고 있습니다.

무엇을 개발하려고 하는가? 전문용어를 사용하지 말고 기술하시오.(What are you trying to do? Articulate your objectives using absolutely no jargon.)
현재는 어떻게 하고 있으며 현재 기술의 한계는 무엇인가?(How is it done today, and what are the limits of current practice?)
당신의 방법에서 새로운 것은 무엇이며, 그것이 왜 성공할 것이라 생각하는가?(What is new in your approach and why do you think it will be successful?) 4 누구에게 도움이 되는가?(Who cares? If you are successful)
성공할 경우 무엇이 달라지는가?(What difference will it make?)
위험과 고비는 무엇인가?(What are the risks?)
개발 예산은?(How much will it cost?)
기간은?(How long will it take?)
성공을 검증하기 위한 중간 및 최종 시험 방법은?(What are the mid-term and final “exams” to check for success?)

거꾸로 일하기(Working backward)

아마존 (Amazon)의 CTO인 워너 보겔스 (Werner Vogels)는 자신의 블로그에서 ‘거꾸로 일하기 (working backwards)’라는 방법을 소개하고 있습니다.

“지금 만들 제품의 보도자료”

지금 만들려는 서비스나 소프트웨어가 언론에 소개된다고 하면 어떻게 만드실 건가요? 아마도 명확하고 정확하게 전달되게 하기 위해 온갖 노력을 들이고 생각을 정리할 것입니다.

보도자료를 작성하라

반드시 A4 한 장으로 작성하시고, 문단은 3~4문장으로 제한하세요. 늘어나면 과감히 지우십시오. 최대한 고객이 뭘 얻는지에 집중하시고 나머지 내용은 FAQ에 붙이면 됩니다. 그리고 이걸 쓸 때 혼자 쓰지 마시고 관련된 분들 (개발 리더 포함)이 모여서 여러 번 같이 쓰세요. 언론에 뿌릴 보도자료이니 관련된 모든 사람이 쉽게 이해할 수 있게 쓰여야 합니다.

FAQ를 작성하라
사용자 경험을 정의하라

이 목적은 우리 서비스나 제품을 가지고 어떻게 고객이 그들의 문제를 해결하는지 이야기를 나눠보는 것입 니다. 그리고 각 기능별로 모든 화면을 만든 스토리보드를 꼭 만들어봐야 합니다.

사용자 매뉴얼을 만들어라

이 과정에서 여러분은 여러분 제품이 정말 괜찮은 것인지 아닌지 스스로 자각할 수 있을 것입니다. 그러면서 보도자료와 FAQ까 지도 바꾸게 될 수 있습니다.

악보와 음반의 관계

음악을 음반으로 들을 경우 음악의 최후 생산물은 ‘소리가 녹음된 음반’일 것입니다. 그러나 그것을 만들기 위한 기본은 ‘악보’입니다. 지금 여러분은 ‘악보’를 하나 쓰신 것입니다. 그리고 이 악보는 음반을 만드는 기본 작업입니다.

가장 초기 서비스를 만드는 프로덕트 로드맵 생각해 보기

이 상황의 조건

소프트웨어를 개발할 때 점진적으로 진화시키는 과정을 알아야 합니다. 여기서 소개할 방법은 대부분이 이른바 린 스타트업 전략을 참고해서 정리한 방법입니다. 여기에 제 경험을 담았습니다. 가능한 한 여기서 이야기 하는 단계를 거쳐서 소프트웨어를 진화시켜 나가고 건너뛰지 않기를 추천합니다. 왜냐하면 진짜 자본을 투입하고 완벽을 추구해야 하는 시기가 따로 있기 때문입니다.

첫 번째 단계 – 코드 없이 시작하기

마음가짐: 코드는 빚

“코드는 빚”이라는 표현은 우선 코드를 작성하는 순간 빚을 진다는 것인데, 이 빚을 지금 지는 게 적절하지 않을 수도 있으니 무조건 코드부터 만들려고 하지 말라는 뜻입니다.

소프트웨어 개발에 앞서서 우리는 먼저 제품이 어떤 것을 달성해야 하는지, 어떤 목표를 가져야 하는지에 대해 고민해야 합니다. 이러한 초점을 가지고 만들어진 제품이 고객에게 실질적인 가치를 제공할 수 있는 것입니다. 우리의 시간과 노력을 무엇에 집중해야 할지에 대한 고민이 이 단계에서 중요합니다.

과정 - 척후병 보내 보기: 정말 고객이 원하는 것인가?

랜딩 페이지(landing page) 전략

랜딩 페이지 (landing page) 전략이란 아주 간단한 최소 기능 제품 (minimum viable product, MVP)으로서, 빈 페이지 하나만 올려놓는 것입니다. 이 페이지에는 간단하게

이메일을 남기거나
실제 결제가 일어나는 과정을 시뮬레이션을 할수 있게 합니다.

프로토타입(prototype) - 노코드/로우코드(No code/Low code) 도구

이런 노코드/로우코드 (No code/Low code) 도구로 만들면 어떤 좋은 점이 있나요? 우선 만드는 중에 ‘이거 될 것이다, 아닐 것이다’를 판단할 수 있습니다. 이상한 제품이면 실제 만들 수도 없는 일들이 벌어지기 때문입니다. 두 번째로 조직 내부에서 제품을 보면서 서로 피드백을 주고받으며 쓸 만한 것인지 아닌지 평가를 받고 만들어 갈 수 있습니다. 세 번째로 실제 고객에게 선보여서 실제 고객이 어떻게 쓰는지를 보고, 고객이 제대로 자신들의 문제를 이 제품으로 해결하고 있는지 아닌지를 볼 수 있습니다.

로우코드라고 해도, 약간의 ‘공학적 사고’를 할 수 있어야 하긴 합니다. 간단한 스크립트를 작성하고 이해할 수 있는 수준은 되어야 합니다. 그러나 실제 개발자가 개발하는 것보다는 간단합니다.

고객 만나기

내부 고객은 서비스 개발을 담당하는 개발자, 디자이너, 기획자 등을 말합니다. 내부 고객은 서비스의 품질과 효율성에 영향을 미치는 중요한 역할을 합니다. 따라서 내부 고객의 요구사항을 파악하고 이를 반영하는 것이 중요 합니다.

외부 고객은 서비스의 사용자를 말합니다. 외부 고객이 서비스에 만족해야만 서비스가 성공할 수 있습니다. 따라서 외부 고객의 요구사항을 파악하고 이를 충족시킬 수 있는 서비스를 개발하는 것이 중요합니다.

모든 제품에 대한 평가는 이 두 고객 모두에게 받아야 합니다.

고객을 이해하는 것은 코드 없이 서비스를 만드는 데 있어 가장 중요한 단계입니다. 고객을 이해하고, 고객의 요구사항을 충족시키는 서비스를 개발해야 성공적인 서비스를 만들 수 있을 것입니다.

두 번째 단계 - 기술의 빚을 당겨서 고객을 빠르게 만나자

마음가짐: 대출받아 시간을 사자

“기술부채 (technical debt)”라는 개념을 이해해야 합니다. 이는 간편하지만 제한된 해결책을 선택할 시, 나중에 재작업을 할 때 발생하는 암묵적인 비용을 의미합니다. 일반적으로는 부채를 늘리지 않는 것이 좋습니다.

이 단계에서는 이 기술적 부채를 상황에 맞게 활용하여 초기 버전을 만들어 보려 합니다. 이때 “이번에 만든 것은 재사용하지 않습니다!”라는 선언을 해야 합니다. 고객에게 가치를 전달하지 못한다면 성공의 기회를 잃게 될 수 있습니다. 이 단계에 만드는 것은 사실상 ‘제품’이 아닙니다. 이른바 개념 검증 (proof of concepts, PoC) 단계입니다.

하루에 10명도 안 들어오는 사이트를 설계하는데 고가용성을 지원하기 위해서 제일 비싼 사양의 가상머신을 클라우드에서 구매하려 하고, 쿠버네티스로 유연하고 복잡한 아키텍처부터 만들 생각을 하나요? 지금은 가장 싼 가상머신 하나로도 됩니다.

과정

개발팀이 없다면 인력을 모집하거나 외주를 고려하는 대책이 필요합니다. 이 과정에서는 최소한 여러분과 함께 일할 기술리더급 한 사람 정도는 필요한 상황입니다.

첫 번째, 어떤 데이터를 어떤 구조로 정리할지 결정하는 것이 중요합니다.

두 번째, 아키텍처를 생각할 때 모노리식(monolithic) 아키텍처에 집중합시다. 복잡한 마이크로서비스 (microservices architecture, MSA)는 절대 고려하지 않습니다. 이렇게 하는 이유는 ‘조금이라도 빨리 개발’하기 위해서입니다.

이러한 작업을 진행하는 과정에서 초기 버전의 데브옵스를 구현해야 합니다. 지속적 통합 및 지속적 배포 (continuous integration, continuous deployment, CI/CD)를 고려하며, 모니터링 역시 필수입니다.

고객 만나기

이때에는 여러 어려움이 나타날 수 있으며, 모든 것이 순조롭게 진행되지 않을 수 있습니다. 이 단계에서는 치명적인 문제들에 신속하게 대응하는 것이 필요합니다.

원래 해결하려는 고객의 문제가 실제로 해결되는지, 그리고 그 문제의 가치가 예상한 만큼 있는지, 그리고 이로 인해 발생하는 수익이 확인되는 지를 신중히 고려해야 합니다. 또한 만나는 고객이 실제로 제품이나 서비스를 구매할 의사가 있는지를 의심해야 합니다.

세 번째 단계 - 탄탄하게 만들기

마음가짐: 이제 좀 오래갈 물건을 만들자

이제는 재사용이 가능하고 견고한 제품을 개발하는 데 집중하고자 합니다.

이 단계에 진입하면 소프트웨어 개발에 소요되는 비용이 늘어나므로, ‘이 비용을 투자해야 한다’는 결단력과 의지가 반드시 필요합니다.

과정

이제 소프트웨어를 지속적으로 성장시키기 위해 필요한 준비를 해야 합니다. 첫째로, 유지보수 가능한 아키텍처를 구축하는 것이 중요합니다. 둘째로, 모든 데이터를 효율적으로 수집하고 보관하는 데이터 레이크 (data lake)를 구축하는 것이 필요합니다.

고객 만나기

이번에는 고객들의 실제 서비스 내에서의 행동을 데이터로 분석하여 봐야 합니다. 이를 위해 CDP (customer data platform)를 검토하거나 내부 고객의 행동을 분석하는 전략을 마련해야 합니다. 그럼에도 불구하고, 정기적으로 소수의 고객들과 1:1로 대화하여 그들의 목소리를 직접 듣는 시간을 확보하는 것이 중요합니다.

그리고 받은 피드백을 기반으로 다음 사업 전략을 수립하는 것이 필요합니다. 만약 예상과 차이가 있다면, 그 이유를 파악해야 합니다.

네 번째 단계 - 다시 방향 잡기

마음가짐

이 시기의 목적은 주로 지난 기간 동안 발생했던 문제들을 해결하고 프로젝트를 안정화하는 것입니다.

이 시기에 소요되는 시간은 일종의 ‘버퍼 (Buffer)’ 역할을 합니다. 이는 고객에게 제품이나 서비스를 제공하는 도중에 발생하는 예상치 못한 문제들을 수습할 수 있는 여유 시간을 의미합니다.

과정

꼭 잊지 말아야 하는 것이 있습니다. “비즈니스의 가치가 소프트웨어로 지속적으로 구현되어 갈 수 있느냐 없느냐”입 니다. 이것이 소프트웨어로 비즈니스를 하는 회사의 성장 열쇠입니다.

고객 만나기

이때가 되면, 이미 우리에게 충성인 고객도 있을 수 있고 신규 고객들 역시 계속 확보할 수 있을 것입니다.

했을 때 반드시 효과가 있는 방법-고객 참여

『함께 자라기』 책에 ‘애자일 도입 성공 요인 분석’이라는 장이 있습니다. ‘애자일 실천법 중에서 도입해서 성과에 도움을 준 것들을 모두 고르세요’라는 질문에 대한 결과 내용이 있습니다.

‘고객 참여’가 제일 중요하다는 것입니다. 보통 사람들이 생각 하는 것처럼 칸반을 쓰거나, 테스트 기반 개발을 하는 것이 핵심이 아니었습니다. 이 분석대로라면 ‘고객을 조금이라도 일찍 불러다가 개발의 과정에 참여시 키는 조직이 성공할 확률이 높다’는 것을 증명해 낸 셈입니다. 그리고 조직의 성숙도를 떠나서 통계적으로 가장 유의미한 실천법으로 ‘고객 참여’를 꼽았습니다.

무언가 조직의 문제를 해결하는 데 ‘작게 시작 하는’ 것이 반드시 답이 아닐 수 있습니다. 산출물은 적게 시작해서 가도 되지만, 조직과 엉켜 있는 문제를 해결하는 데는 이른바 ‘제약이론’에 근거해서 ‘전체 최적화’를 해야만 제대로 돌아간다는 뜻입니다.

요약

아주 초기 단계에서는 프로덕트 로드맵을 통해 어떻게 첫 제품을 만들 것인 지를 계획해야 합니다. 두 번째 단계에서는 기술적인 부분을 강화하고 고객과 실질적으로 만나는 단계입니다. 세 번째 단계에서는 제품을 더 탄탄하게 만들어야 합니다. 마지막 단계에서는 다시 방향을 조정하고 고객의 피드백을 반영합니다.

소프트웨어 개발에서 불확실성을 극복하고 성공적인 제품을 만들기 위해 EoA 원칙을 적용하며, 프로덕트 로드맵과 릴리즈 플랜을 효과적으로 활용하고, 고객 참여를 핵심으로 모든 개발 단계에서 지속적인 혁신과 개선을 추구할 것을 권해드립니다.

jongfeel / BookReview