개발자로써 회사에서 일하다 보면 다양한 상황들을 마주하게 됩니다. 커리어 전환, 팀 간 협업 문제, 코드 리뷰 문화, 작업 소요 시간 추정... 이런 상황들 하나하나에서 정답이 없어 고민하곤 했는데, 이번에 읽게 된 『The Software Engineer's Guidebook』 (게르겔리 오로스 저)는 말 그대로 소프트웨어 엔지니어의 가이드북 그 자체였습니다. 정말 현업에서 자주 마주치는 문제들에 대한 지침서처럼 느껴졌습니다.
선의 통장: 팀워크의 핵심
책에서 가장 인상 깊었던 개념은 선의 통장이었습니다.
다른 사람을 도우면 선의 통장의 잔고가 늘어난다. 도움을 청하면 그 잔고는 줄어든다. 합당한 이유 없이 다른 사람을 방해해도 선의 통장의 잔고는 감소한다. 도움을 요청하기 전에 가장 일반적인 디버깅 및 정보 수집을 수행하자. 해결책을 찾을 수 있다면 온라인이나 기업 내부 지식 베이스에서 찾아보자.
결국 선의 통장은 협업의 중요성을 강조하는 개념으로 이해했습니다. 동료를 도우면 선의 통장의 잔고가 늘어나고, 도움을 요청하면 잔고가 줄어듭니다. 합당한 이유 없이 다른 사람을 방해하면 잔고가 감소합니다.
실제로 긴급한 상황에서 동료의 도움을 받을 때, 그동안 쌓아온 선의가 있다면 훨씬 원활한 협업이 가능합니다. 반대로 도움을 요청할 때 기본적인 준비 없이, 상대방의 시간을 고려하지 않고 요청하면 선의 통장의 잔고는 금방 바닥나게 됩니다.
현실적인 작업 시간 추정
개발자에게 가장 어려운 질문이 될 수 있는 것이 바로 "얼마나 걸릴까요?" 입니다. 책에서는 이 질문에 대해 카테고리별로 세분화해 접근 방법을 제시합니다.
먼저 이전에 수행한 작업과 이전에 수행해보지 않았던 작업으로 크게 나눌 수 있습니다.
이전에 수행한 작업
이런 작업은 가장 쉽게 작업 시간 추정이 가능하다. 이전과 매우 유사한 기능을 새로 추가해야 한다고 가정하자. 예를 들어 웹사이트에 페이지를 하나 더 추가하거나 API에 엔드포인트를 하나 더 추가하는 수준으로, 이전 작업에 소요된 시간을 기준으로 새 작업의 소요 시간을 현실적으로 추정할 수 있다.
저도 개인적으로 비슷한 UI 컴포넌트를 추가하거나, 이미 구현된 기능과 유사한 기능을 개발할 때는 이전 경험을 바탕으로 비교적 정확한 예측이 가능했습니다.
이전에 수행해보지 않았던 작업
여기서부터 저자는 미지의 작업을 7가지 세부 카테고리로 나누고, 각각에 맞는 추정 전략을 제시합니다.
1. 동료의 작업과 유사한 작업
여러분은 처음 시도하겠지만 비슷한 작업을 경험한 팀원이 있을 수 있다. 이러면 처음부터 만드는 것이 아니다. 비슷한 작업을 했던 개발자는 시간을 예상할 수 있다. 유일한 차이는 콘텍스트에 대한 이해가 필요해 작업을 완료하는 데 시간이 조금 더 걸린다는 점이다. 이들과 상의해 > 접근 방식을 세분화해 현실적인 시간을 추정하자. 처음 시도하는 작업인만큼 시간을 조금 더 길게 잡는 편이 좋다.
2. 리팩터링
코드의 구조만 변경하고 새로운 기능은 추가하지 않는 경우, 이전에 리팩터링을 수행했다면 현재 리팩터링 유형이 새로워도 그 경험을 기준으로 시간을 예측할 수 있다. 또는 팀원에게 비슷한 리팩터링 작업을 해본 적이 있는지, 얼마나 쉬웠는지, 복잡했는지, 경험을 공유할 수 있는지 물어보자. 타임박스 작업을 적용할 수도 있다. 타임박싱이란 작업에 기간을 할당하고 그 기간 동안만 작업하고 그 이상은 작업하지 않는 것을 의미한다.
3. 잘 아는 기술을 사용하는 작업
이 경우 기술이 큰 문제가 되지 않으며 언어나 프레임워크의 버그에 갇힐 가능성도 적다. 가장 큰 문제는 비즈니스 요구사항이 불분명할 때인데 업무만 명확하다면 충분히 잘 맞는 예측치를 낼 수 있다.
4. 잘 아는 기술로 잘 모르는 시스템을 통합
익숙하지 않은 시스템을 기반으로 구축하거나 그 시스템에 통합할 때는 상황을 예측하기가 훨씬 더 어렵다. 다른 팀이나 외부 조직이 만든 엔드포인트와 통합하는 경우가 이에 해당한다. 가장 큰 위험은 내부의 작동 방식을 알 수 없는 시스템과의 연동이다. 큰 어려움이 있을 수 있다. 문서에 나와 있는 것과 다르게 작동하거나, 생각지도 못한 애매한 케이스가 발생하거나, 문서가 없어 통합에 많은 시간이 소요될 수 있다. 이러한 경우 먼저 프로토타입을 제작하고 다른 시스템이나 API를 테스트하는 간단한 개념 증명(PoC)을 한 후에 예상 시간 추정을 하는 것이 좋다. 프로토타이핑이 불가능하면 시스템에 문제가 없다고 가정하는 ‘이상적인 추정치’를 제공할 수 있다. 또한 시스템이 이상하게 작동해 해결 방법이 필요하다는 가정 하에 ‘최악의 경우’를 감안한 추정치도 제공하자. 최악의 경우를 반영한 예상 시간은 당연히 길어진다. 예상 시간 추정치를 제시하기가 부담스럽다면 최악의 경우를 제시하자. 마음에 안 들어 하는 사람도 있겠지만 프로토타입을 제작할 시간적 여유를 확보하는 데 도움이 되어 보다 정확한 견적을 제시할 수 있다. 개인적으로는 프로토타입을 제작한 뒤에 정확한 예상 시간 추정하는 걸 권한다.
이 조언은 특히 인상 깊었습니다. 외부 시스템과의 통합은 문서상으로는 간단해 보이지만, 실제로는 예상치 못한 복잡성을 내포하고 있는 경우가 많기 때문입니다. 프로토타이핑을 통한 사전 검증은 시간 추정의 정확도를 크게 높일 수 있다는 말이 인상적이었습니다.
5. 잘 모르는 성숙도 높은 기술로 간단한 결과물을 구축
경험이 거의 없는 안정적인 기술로 프로젝트를 구축한다고 가정하자. 이 경우 새로운 기술(언어 또는 프레임워크)을 배우는 데 가장 노력이 많이 든다. 현실적인 예상 시간 추정하는 가장 좋은 방법은 해당 기술을 사용해본 엔지니어에게 문의하는 것이다. 엔지니어는 시작할 위치를 알려줄 수 있고, 기술을 익히는 데 걸리는 시간을 예측하는 데 도움을 줄 수 있다. 물론 기술을 익히는 일이 얼마나 어려운지를 그 엔지니어가 과소평가할 수 있다는 점을 고려하자. 그 기술을 잘 아는 개발자와 같이 작업하면 구현에 걸리는 시간이 단축되고 학습과정도 빨라진다. 개발자와 같이 작업할 수 없다면 언제든 타임박스로 추정치를 작성해 기술을 익힐 수 있다. 이 타임박스를 매우 크게 잡아 튜토리얼 몇 가지를 살펴보고, 코딩을 해보고, 평소보다 얼마나 더 많은 디버깅이 필요한지 알아보자.
6. 잘 모르는 새로운 기술로 간단한 결과물을 구축
새로운 프레임워크나 언어는 성숙도 높은 기술보다 더 많은 위험을 수반한다. 학습 자료가 적고 질문에 답할 수 있는 사람도 적다. 또 새로운 언어나 프레임워크에는 버그가 있을 가능성도 높다. 프로토타이핑 없이 하나의 새로운 기술을 사용하는 데 얼마나 걸릴지 예상하기는 어렵다. 새로운 기술로 PoC를 수행한 다음, 그 기술을 사용할 수 있다는 확신이 든 뒤에 작업 예상 시간을 추정하길 권한다.
7. 익숙하지 않은 신기술로 복잡한 결과물을 구축하고 잘 모르는 시스템과 통합
이때 잘 알지 못하는 것이 너무 많아 합리적인 추정치를 제시하기 어렵다. 우선 알지 못하는 것을 세 종류로 나눠보자.
- 통합하려는 시스템
- 기술
- 미지의 요소 정확한 추정을 위해서는 미지의 요소를 줄여야 한다. 방법은 두 가지다.
- 프로토타이핑 : 프로토타입에서 학습한 내용을 바탕으로 예측치를 만들어 낼 수 있다.
작업의 세분화 : 작업을 모르는 요소가 하나씩만 포함되도록 분리한다.
- 새로운 기술을 사용하는 작은 작업
- 새로운 기술을 기반으로 한 기능 구현
- 새 시스템과 통합
- 남은 부분을 구현해 마무리
이렇게 작업을 나누면 지나치게 세분화된 것처럼 느껴지지만 이러한 접근 방식을 사용하면 모르는 영역을 효율적으로 정복할 수 있다. 작업 시간 추정치는 여전히 불완전하겠지만, 각 추정치는 여러 가지가 아닌 하나의 미지수에 영향을 받는다.
이렇게 다양한 카테고리로 접근하는 것이 신기했습니다. 개인적으로 이전에는 비슷한 작업 경험과 예상 외 상황을 고려한 여유만 두고 추정했었는데, 이런 세밀한 구분과 접근 방법을 알게 되어 앞으로 좀 더 정확한 작업 시간 추정이 가능할 것 같고, 팀에도 공유하면 좋을 만한 내용들인 것 같습니다.
마치며
이 책의 모든 내용을 전부 소개하지는 않았지만, 저에게는 솔선수범하라는 개념도 정말 인상 깊었습니다. 개발자로서 성장하기 위해서는 결국 자신의 담당 업무를 넘어서는 자발적 노력이 필수적이라는 걸 다시 깨닫게 되었습니다.
또한 책에서 다룬 제품 팀과 플랫폼 팀의 차이점도 흥미로웠습니다. 제품 팀은 사용자 대면 기능 개발에 집중하고 빠른 피드백과 반복 개발이 특징이며, 플랫폼 팀은 내부 도구 및 시스템 개발에 집중하고 더 깊은 기술적 탐구가 가능하다는 차이가 있습니다. 이 부분을 읽으며 제가 일하고 싶은 팀이 무엇인지, 그리고 저의 개인적인 커리어 방향성에 대해서도 좀 더 깊이 생각해볼 수 있었습니다.
멘토링을 요청하는 방식에 대한 조언도 매우 유용했습니다. 특히 이미 한 시도를 명확히 정리하고, 구체적인 질문을 준비하는 것이 멘토에 대한 존중이자 더 나은 도움을 받을 수 있는 방법이라는 것을 알게 되었습니다.
『소프트웨어 엔지니어 가이드북』은 말 그대로 개발자로서 성장하는 과정에서 마주하게 될 다양한 상황들에 대한 실질적인 지침을 제공하는 책이었습니다. 책의 내용도 그럽게 무겁지 않고 가볍게 읽을 수 있는(그렇지만 생각하면 좋을만한) 주제들로 되어있어, 560 페이지 정도 되는 분량임에도 불구하고 연휴를 이용하여 이틀만에 다 읽었던 것 같습니다.
개발자의 하드스킬 뿐 아니라 소프트스킬도 점점 중요해지는 시대에서, 앞으로 더 나은 커리어를 쌓아가기 위해 고민을 하는 분들께 큰 도움이 될 수 있는 책이라고 생각합니다.