The Nature of Software Development를 읽고나서..

간결하게, 가치 있게, 하나씩 완성하기

들어가며

책을 좀 읽어야겠다고 다짐한 지 한 두 달 만에, 독서모임에 참여하게 되어 Ron Jeffries의 "The Nature of Software Development"를 읽게 되었다.
개발 서적을 읽고 독서 감상문을 적는 건 처음이라 좀 당황스럽지만..! 단순 요약이 아니라 책을 읽으면서 들었던 나의 생각과 의문점들을 적어보려 한다.

우선 이 책을 처음 마주했을 때는 생각보다 책이 얇고, 글자 크기도 크고 그림도 많아서 가볍게 읽을 수 있을 줄 알았다. 물론 지금 생각해보면 빠르고 가볍게 읽을 수 있을 것 같긴 하지만.. 독후감을 쓰기 위해 중간중간 메모하고 고민하며 읽으려 하니 속도가 늦어졌다. (물론 나의 짧은 집중력 덕분에 속도가 나지 않았을지도 😅)

 

서론

우선 소프트웨어 개발을 용암에 빗대어 표현한 게 인상 깊었다. 분명 지금 적용하는 방법보다 더 좋은 방법이 있는데, 내가 그 방법을 모를 뿐이고 그러다 보니 좋지 않은 코드를 계속 생산해내게 되어 용암은 멈추지 않는다는 점. 정말 남일 같지 않는 이야기다 😞

개발을 하다 길을 잃어버렸을 때, 분명 어딘가에 길이 있다는 것을 기억해야 한다. 때때로 개발을 할 때, 내가 보아도 내 코드가 너무 별로고 이 방식이 문제가 있다는 것을 알 때가 있다. 개선하기가 어려워 주변에 있는 시니어 개발자들에게 ‘이럴 때는 어떻게 해야 하나요..? 👀’라고 물어보는데, 언제나 길은 존재했다. 
코드를 짜면서 느껴지는 나의 부족함은 다양한 디자인 패턴에 대한 무지함이라는 점인데, 알면서도 아직도 공부를 시작하지 않았다는 것이 부끄러워지는 순간이었다.

소프트웨어 개발에는 언제나 본질적인 방법이 존재하고, 이 방법은 모두(사용자, 비즈니스, 경영진, 개발자)에게 도움을 준다. 그러므로 우리는 항상 본질적인 가치를 떠올려야 하며 사용자들에게 이 가치를 빠르게 전달하여 가치를 실현시켜야 한다. 동의하지만, 어려운 내용이다.
내가 하는 프로젝트의 본질적인 가치를 마음에 새기고 모든 회의에서 이를 기반으로 소통하고 의사결정을 내린다는 게 가능할까? 우선 본질적인 가치를 깨닫고 마음에 새기는 것부터가 쉬운 일은 아닌 것 같다. 하지만 해야 하는 작업이라는 건 알겠다.

 

Part 1. 가치를 이루는 것들

이 책에서 가장 중요시 이야기하는 게 가치와 간결함이다. 소프트웨어를 개발할 때는 가장 가치 있는 것을 우선적으로 간결하게 작업해야 한다.

글쓴이는 가치가 본질적인 개발 방법의 핵심이라고 말한다. 그렇다면 가치는 무엇인가? 가치는 우리가 원하는 것이다.
일을 진행할 때는 가장 우선적인 가치를 먼저 수행하고, 계획할 때는 다음에 수행할 가치는 무엇 일지를 기준으로 계획하면 된다.

가치를 확인하는 방법은 작동하는 소프트웨어를 확인하면 된다. 작동하는 소프트웨어를 확인하려면 배포를 해야 하는데, 배포를 하는 순간 가치는 생겨난다. 우리는 가치를 빠르게 실현시키기 위해 배포 주기를 짧게 가져가야 하는데, 그러기 위해 실현하고자 하는 가치들을 잘게 쪼개 피처 단위로 개발하여 사용자들에게 제공해줄 수 있다.

그럼 어떤 기능을 우선적으로 제공해야 할까? 이는 각 피처의 가치와 비용을 측정해보면 된다. 글쓴이는 피처의 가치를 높이로, 피처를 만드는 비용을 너비로 하는 블록을 그려 높이는 높으면서 너비는 좁은 블록을 우선적으로 개발하는 방법을 제시했다. 좀 귀여우면서 신선했다. MVP 단계에서 개발해야 하는 기능들을 우선순위를 매겨 수행해왔는데, 가치와 비용을 수치화해서 나열해본 적은 없어서 생각보다 괜찮은 방법이라 다음에 한번 적용해봐야겠다고 생각했다.

가치를 중심적으로 개발하다 보면, 장난감 조랑말이 장난감 스포츠카가 되는 경우가 생길 수 있다. 기능을 배포하고 사용자들의 반응을 살펴보면 그들이 더 원하는 가치가 있다고 생각되었을 때 해당 기능을 우선적으로 개발하게 될 수 있기 때문이다. 이러다 보면 처음에 우리가 생각했던 제품과 완전 다른 제품이 나오게 될 수 있는데, 글쓴이는 이런 상황을 호의적으로 바라보는 듯하다.

나는 잘 모르겠다. 솔직히 말하면 이 상황을 좀 부정적으로 생각한다. 사용자들이 더 원하는 기능을 우선적으로 개발해줄 수 있다. 그런데 그 와중에도 우리가 이 서비스로 무엇을, 어떤 가치를 말하고 싶었는가는 흔들리면 안 된다고 생각한다. 장난감 조랑말에 기능을 이것저것 추가하더라도, 아무리 변해도 조랑말이 유니콘이 될 수는 있어도 스포츠카가 되면 처음 타겟으로 잡은 사용자들과 피처들이 이것저것 추가되고 나서 잡은 사용자들이 매우 다르지 않을까? 물론 비즈니스적으로 성공하는 것도 매우 중요한데, 조랑말이 스포츠카가 돼서 성공하는 게 진짜 성공이라고 할 수 있을까? 잘 모르겠다.

글쓴이는 하나의 큰 프로젝트를 한 번에 계획하고 개발하는 것이 어렵기 때문에 큰 Vision을 작은 Feature 단위로 쪼개서 프로젝트를 진행하라고 이야기한다. Sprint 내에 Feature들을 개발하면서 Task 위주의 개발이 아닌 사용자 스토리(플로우) 기준으로 개발하라고도 이야기한다. 그러면서 거듭 강조하는 말은 “제품을 언제든지 배포할 수 있는 상태로 유지하라”이다. (가치를 확인하는 유일한 방법이 작동되는 제품을 확인하는 것이니까)

제품을 언제든지 배포할 수 있는 상태로 유지하며 개발하는 것. 너무 이상적인 말이다. 이 내용은 책이 끝날 때까지 수차례 반복해서 나오는데, 나는 이 말을 계속 읽으면서 이걸 어느 수준으로 유지하라는 건지 의문이 들었다.
3년 동안 개발자로 일하면서 언제나 Dev 서버를 배포 가능한 상태로 유지했던 것 같다. 적어도 그러려고 항상 노력했다.
분사 이후 프로젝트를 진행했을 때, All Hands 시간에는 2-3주간 한 스프린트 동안 개발했던 내용을 Demo로 보여주는 Demo Driven Development(줄여서 DDD 😅) 방식으로 프로젝트가 진행되었다. 내가 맡았던 프로젝트에서 나는 서버뿐만이 아니라 컨트랙트 개발, 서비스 웹 개발, 어드민 웹 개발을 모두 함께 진행했기 때문에, 해당 Demo를 보여주기 위해 12일 정도 개발을 하고 2일 정도 이제껏 해왔던 작업들을 모두 조립하는 시간이 필요했다.

수차례 이 방식으로 프로젝트를 진행하다 보니 3개월 정도가 지났을 때는 데모를 위해서 준비하는 시간이 소모적이고 이런 잦은 Demo가 매우 비효율적이라고 생각했다. 각 개발자들이 Feature를 크게 잡았기 때문일까? 2주 안에 개발이 끝나는 Feature가 아닌 경우, 데모를 위해서 들어가야 하는 임시의 방어적인 코드들이 있었고, 퀄리티 있는 데모를 위해 데이터를 넣어주고 이것저것 조립을 해야 하다 보니 계속해서 컨텍스트 스위칭이 일어나야 했다. 글쓴이가 말하는 ‘언제든지 배포할 수 있는 상태’는 이상적이지만 그 작업을 위해 들어가야 하는 시간이 생각보다 크고, 차라리 그 시간에 미처 끝나지 않은 Feature 작업의 완성도를 늘리고 새로운 Feature를 더 개발하는 게 빠른 프로젝트 출시에 도움이 된다고 생각했다. 결국 우리 팀은 Demo 주기를 늘렸다. 지금도 잘한 결정이라고 생각하는데, 글쓴이는 어떻게 받아들일까?

일하면서 아직도 가장 어려운 부분이 일정 산정이다. "빅토리아, 이거 얼마나 걸릴 것 같아요?"라고 질문을 받을 때마다 동공 지진하며 떠듬거리는 나를 보곤 한다. 내가 좋아하는 삼촌 개발자 케이든은 ‘너 연차에서 일정 산정할 때는 항상 네가 생각한 일정에 최소 2배는 잡아야 해. 보통 3배 걸려.’라고 조언해주곤 하신다. 책에서는 “오늘은 어제의 업무량만큼 일할 수 있다”는 어제의 날씨라는 방법을 알려주었는데 좋은 방법인 것 같다. 가장 최근 주기의 작업량을 기준으로 내 업무량을 측정하는 연습을 조금씩 해봐야 할 것 같다.

Part 1 요약

1. 가치는 우리가 원하는 것이다. 피처들은 가치를 전달한다. 피처들을 빨리 보여줄 수 있다면 그만큼 가치를 얻을 수 있다.
2. 가치를 기준으로 프로젝트를 관리하는 방법이 가치를 전달하지 못하는 산출물이나 일정으로 관리하는 방법보다 낫다.
3. 피처 개발을 계획하기는 매우 쉽다. 필요하다면 프로젝트 추정도 괜찮은 방법이다. 어제의 날씨 방법에 따라 해야 할 작업을 선별하는 것도 좋다.
4. 1-2주의 짧은 개발 주기마다 작지만 완전히 돌아가는 제품을 개발해야만 한다. 이 제품은 항상 올바르게 작동해야 하며 훌륭한 설계를 가지고 있어야 한다.
5. 개발자는 반드시 실제로 작동하는 피처들을 배포해야 한다. 제품은 반드시 올바르게 테스트해야 한다. 비즈니스 측면에 있는 사람과 개발자는 테스트에 시간을 투자해야 한다. 제품은 항상 올바르게 설계되어야 하며, 개발자는 항상 훌륭한 설계를 유지해야 한다.

 

Part 2. 메모와 에세이

서비스 품질을 정하는 기준은 우리의 기대에 달려있다. 가치는 우리가 원하는 것이기 때문에, 우선순위가 높은 가치부터 개발하여 서비스를 만들어나가기 때문에 우리의 기대가 서비스 품질을 결정한다. 글쓴이는 내가 이 Feature를 왜 선호하고, 왜 그렇게 생각했는지 적은 뒤 다른 이해 관계자에게 물어봄으로 가치를 측정할 수 있다고 한다. 가치를 비즈니스 측면이나 사용자 입장에서 판단해보려 할 수 있지만, 진정한 방법은 제품의 책이자와 이해관계자, 그리고 팀의 고민으로 판단해서 만들어 나가는 게 진정한 방법이라고 말한다.

항상 가치에 집중할 것, 가치를 기준으로 계획하고 관리할 것, 사용자가 어떤 반응을 보이는지 살펴볼 것.

 

가치를 측정하고 판단하는 일이 쉬운일은 아니지만 꼭 해야 하는 필수적인 일이라는 점은 알겠다. 현재 내가 개발하고 있는 서비스가 나타낼 수 있는 가치는 무엇일지 나도 한번 생각해봐야겠다 👀

Part 2에서 가장 고민하면서 읽었던 부분은 압박과 관련한 부분이었다. “더 강한 채찍질”이라는 것.
책에서 볼드체가 되어있던 질문들을 보니 마음이 심란해지는 기분이 들었다.

“더 많은 피처가 필요합니다! 왜 더 속도를 내지 못하죠?”
“아뇨, 우린 정말로 더 많은 피처가 필요합니다. 개발자는 더 빨리 개발해야 합니다.”
“더 빠르게 개발을 진행하는 방법은 없나요? 그럼 어떻게 해야 할까요?”

 

그리고 글쓴이가 적은 방법들과 설명들이 너무 공감되었다. 더 강한 채찍질은 개발자로 하여금 이 코드와 방식이 잘못된 걸 알아도 포기하게 만든다. Test를 하지 않도록 하고, 나쁜 코드를 방치하게 된다. 이는 가치의 하락을 발생시키고, 결점이 발생하기 쉬워지며 결국 이후 Feature에서 일정 지연을 발생시키게 될 것이다.

또한 개발팀이 보수적으로 일하게 된다. 해당 Feature를 끝마치는 데 걸리는 일정을 더 여유롭게 산정하게 되고, 개발팀은 결정하기보다 주문을 받는 조직이 된다.

너무나 공감되고 예측 가능한 상황이다. 내가 실제로 봤던 상황이기 때문이다. 더 빠르게 개발을 진행하려면, 개발팀이 개발에 필요한 기술을 모두 갖도록 인력을 충원하던지, Team의 생산성을 높이기 위해 수준 높은 기술을 훈련하고 교육하는 단계가 필요하다고 한다. 너무 공감하는데, 내가 본 한 예외적인 신 같은 개발자는 언제나 채찍질에 맞춰져 작업을 해나가셨는데, 그 사람은 뭐지..?라는 생각이 들면서 티타임을 한번 요청해서 대화해봐야겠다고 생각했다. (물론 그 사람에게는 노하우가 있어서 일정 조율을 잘했던 게 아닐까 싶긴 하지만..)

마지막으로 리팩토링 챕터를 읽으면서 야영지 규칙을 보고 옛 스타트업 인턴 시절 CTO분이 떠올랐다. 당시 나에게 하셨던 말 중에 인상 깊었던 부분이 ‘전 옛 코드를 수정하거나 다시 봐야 할 때, 적어도 어떤 한 부분이라도 개선하려고 노력해요'라고 말해주셨는데, 그게 되게 멋있어서 오랫동안 마음에 간직하고 있었다. 글쓴이가 말하는 야영지 규칙은 ‘야영지는 그곳을 발견했을 때보다 떠날 때 더 나은 곳이어야 한다’ 이다. 다시 봐도 멋진 말이고, 나도 점점 내 코드를 더 개선시키는 개발자가 되어야겠다는 다짐을 해본다.

 

독후감을 마무리하며..

개발 서적 독후감 적는 것 확실히 쉬운 일이 아니다. 기술과 관련한 내용을 서술한 책이 아니어서 나의 여러 경험들을 떠올리고, 이것저것 생각하며 읽을 수 있는 좋은 시간이었던 것 같다.

평소 책을 읽을 때 의심하지 않고 팩트처럼 받아들이곤 했던 것 같은데, 내가 조금 변한 건지 조금은 경험이 있는 상태에서 이 책을 접해서 그런 건지 내용을 읽다 어떤 점들은 의문점이 들고 뭔가 물어보고 싶은 느낌이 든 것이 처음인 것 같아 또 새로운 나를 발견할 수 있어 좋았다.

무엇보다 책을 읽고, 글도 썼다는 게 뿌듯하다 😎