jongfeel
commented
9 months ago 5.3.4 코딩
코딩 하는 건 중요할 수도 그렇지 않을 수도 있다. 그런데 할줄 아는 일만 하는 간식을 먹는 행위라는 점에서 공감이 된다. 보통은 경력이 쌓이면 그렇게 느끼는데 간식만 먹다 보면 중요한 일을 못하는 사람이 될 수 있다는 건 안타까운 일이라고 본다.
Closed jongfeel closed 9 months ago
jongfeel
commented
9 months ago 5.3.4 코딩
코딩 하는 건 중요할 수도 그렇지 않을 수도 있다. 그런데 할줄 아는 일만 하는 간식을 먹는 행위라는 점에서 공감이 된다. 보통은 경력이 쌓이면 그렇게 느끼는데 간식만 먹다 보면 중요한 일을 못하는 사람이 될 수 있다는 건 안타까운 일이라고 본다.
jongfeel
commented
9 months ago 5.3.4 코딩
내가 더 잘할 수 있다는 판단이 있어도 주니어 개발자의 업무에 관여해서 지배하지 말라는 얘기는 매우 좋은 조언이라고 생각한다. 스스로 생각하고 성장할 수 있게 도와주는게 좋다고 본다.
jongfeel
commented
9 months ago 5.3.5 의사 소통
외부 의사소통에서 일정의 문제점이 발생한다는 건 분명 관리자의 잘못이 크다고 본다. 그리고 책에 언급한 것처럼 모든 게 조금만 노력하면 다 잘될 거라는 유혹은 정말 뿌리쳐야 한다. 보통 그렇게 해서 야근을 하고 주말에도 해결하려고 시간을 쓴다고 해도 결국 협업은 필요하고 문제는 드러나고 공유된다.
CHAPTER 5 대규모 프로젝트 진행
훌륭한 리더의 자질은 대개 인내심, 용기, 그리고 다른 사람들과 소통하려는 의지에서 나온다. 일반적으로 프로젝트가 어려운 이유는 기술의 경계를 넓혀야 하기 때문이 아니다. 그보다는 모호한 업무 방향, 얼키고설킨 복잡한 인간관계, 예측 불가의 레거시 시스템을 다루기 때문이다. 이럴 때는 이 프로젝트를 견고하게 이끌며 문제를 해결하고 복잡성을 처리할 수 있는 기술 리더가 꼭 필요하다.
5.1 프로젝트 진행 프로세스
프로젝트의 성과물과 마일스톤을 검토하고, 여러분을 포함한 기대치를 설정한다. 목표를 정의하고, 책임과 구조를 추가하며, 역할을 정의하고, 성공을 위해 꼭 필요한 기록을 작성하는 방식으로 프로젝트를 설정한다.
5.2 프로젝트 시작
프로젝트에는 다른 시니어 엔지니어들이 있을 수도 있고, 심지어 더 선임인 엔지니어들도 있을 수 있다. 그렇다면 그들에게 지시를 내려야 하는가, 아니면 그들의 조언을 들어야 하는가?
5.2.1 새로운 프로젝트의 압박감을 극복하는 방법
기존 프로젝트에 새로운 인력으로 투입된다면 투입 전에 고려하고 살펴보아야 할 부분이 상당히 많다. 대규모 프로젝트를 시작할 때 프로젝트에 압도당하는 것은 정상적인 일이다.
이런 불편함조차 실은 일종의 학습이기도 하므로 불편함을 관리하는 것도 배울 수 있는 스킬이다
불편함이나 부담감은 수많은 생각을 불러온다. 실수로 리더의 위치에 올라왔다고 생각하거나, 프로젝트가 너무 어려워서 본인이 감당할 수 없다고 생각할 수도 있다. 또는 다른 사람들에게 실망을 안겨주거나 공개적으로 실패할 것 같은 두려움으로 고통스러울 수도 있다. 이는 심리학적으로 가면 증후군imposter syndrome이라고 부르는 현상이다.
사실 이런 감정은 자원 중에서 최소한 하나가 부족하다는 신호일 수 있다. 예를 들어서 모든 에너지를 소진했거나, 업무 시간이 부족하거나, 또는 스킬이 부족하다고 느끼면 그것이 스트레스와 불안으로 발현되는 것이다. 그러니 보유한 자원을 스스로 잘 살펴서 혹시 부족하지는 않은지 점검해보자.
다른 사람이 이 일을 맡는다면 어떤 느낌이 들지 생각해보는 것도 불안감을 극복하는 좋은 방법이다. 결론은 누가 이 프로젝트를 담당하든 간에 그들도 실은 이 프로젝트를 어려워한다는 것이다.
어려움이 핵심이다. 어려움이 업무의 본질이라는 것을 깨닫고 이를 내면화했을 때 비로소 그 모호함을 다룰 수 있다는 진리를 발견할 수 있다. 복잡하고 어려운 업무가 아니었다면 기업은 여러분을 필요로 하지 않았을 것이다. 업무를 열심히 하다 보면 당연히 실수를 할 수도 있다. 그래도 중요한 것은 누군가는 이 업무를 해야만 한다는 것이다. 열 번이나 실수하더라도 그 실수가 파멸시키지는 못한다. 사실 실수야말로 우리가 무언가를 진정으로 배울 수 있는 훌륭한 교보재다.
다음은 새로운 프로젝트의 부담을 줄이기 위해 수행해볼 수 있는 다섯 가지 방법이다. 나를 위한 문서 만들기
프로젝트 규모와 관계 없이 프로젝트 기간 동안 머릿속에 있는 생각들을 정리해서 이를 기록한 문서를 만든다. 다음에 무엇을 해야 할지 잘 모를 때는 이 문서를 찾아서 과거에 중요하다고 생각했던 것이 무엇인지 살펴보면 된다.
프로젝트 후원자들과 대화하기
누가 이 프로젝트를 후원하는지 알아낸 뒤 그들이 원하는 것을 정확하게 파악하라. 그리고 그들과 함께할 수 있는 시간을 만들자. 먼저 프로젝트를 통해서 달성하고자 하는 목표와 성공이 무엇인지 명확하게 설명할 수 있도록 준비한다. 문서로 정리된 설명일수록 더 명확하다.
프로젝트의 불확실성을 공감하고 이해해줄 사람 찾기
프로젝트가 어렵고 능력 밖의 일처럼 느껴진다면 누구와 이야기를 나눌 것인지 생각해보자.
확신이 서지 않는 부분들을 허심탄회하게 논의할 수 있는 사람을 적어도 한 명은 찾자. 그 사람은 매니저나 멘토 또는 동료일 수 있으며, 2장에서 논의한 동료 스태프 엔지니어도 여기에 해당한다.
프로젝트 초창기에 최대한 배우기
만약 문제가 너무 커서 여전히 직접 해결하기가 어렵다면, 적어도 그 문제를 통제하는 데 도움이 되는 조치를 취하는 것을 목표로 하자. 다른 사람과 대화를 나누어보거나 그림을 그려보거나 문서를 작성해볼 수 있다. 아니면 다른 사람에게 이 문제를 설명해보자. 프로젝트의 초창기는 해당 프로젝트에 관해서 아는 것이 가장 적은 시기이기도 하다.
나만의 장점 활용하기
본인의 장점을 중심으로 전략을 세워 핵심 근육을 사용하라. 예를 들어서 코드가 가장 익숙하다면 코드를 확인하자. 만약 여러분이 인간관계를 먼저 생각하는 경향이 있다면 사람들과 대화해보자. 읽는 것을 선호한다면 서류를 찾아보자. 본인이 가진 장점을 최대로 활용해야 한다.
5.2.2 맥락 쌓기
업무를 다른 관점에서 보고, 프로젝트의 목표를 이해하며, 프로젝트의 제약 조건 및 역사 그리고 프로젝트가 사업 목표와 어떻게 연결되는지에 대해 명확하게 설명하는 위치 인식 지도를 만들 수 있다. 그리고 건너야 하는 지형과 그곳의 지역 정치를 식별할 수 있고 프로젝트에 참여하는 사람들이 일하는 스타일과 결정이 어떻게 내려질지를 포함하는 지형 지도를 만들 수 있다. 마지막으로어디로 가는지, 그리고 어떤 마일스톤에서 멈출지를 보여주는 보물 지도를 만들 수 있다.
목표 이해
이 프로젝트를 수행하는 목표가 무엇인가? 달성 가능한 모든 사업 목표와 기술 투자 및 미결 과제 부분을 모두 고려해서 왜 이 목표를 설정했는지 알아야 한다. 업무를 해야 하는 이유는 프로젝트 전반에 걸쳐서 동기를 유발하고 앞으로 나아갈 때의 지침이 된다.
주도해야 할 프로젝트가 명확한 목표를 달성하지 못한다면, 그 프로젝트를 수행하는 것 자체가 모두에게 시간 낭비다. 그러니 목표는 일찍 파악할수록 더 좋다.
사용자의 정확한 욕구 파악
가장 내부적인 프로젝트조차도 ‘고객’이 존재한다. 설계한 시스템은 누군가는 반드시 사용한다. 때로 스스로 만든 시스템의 사용자가 될 수도 있다. 그러나 대부분의 사용자는 다른 사람들이다. 사용자가 무엇을 필요로 하는지 이해하지 못하면 올바른 프로덕트를 구축하고 배포할 수 없다.
사용자와 대화하고 그들이 응답하는 내용에 귀를 기울여야 한다. 사용자의 욕구를 정확하게 파악해야 한다.
사용자에게 교체할 소프트웨어의 사용 사례를 직접 보도록 요청해야 한다. 내부 사용자들에게 그들이 원하는 API가 무엇인지 설명하도록 요청하거나, 사용자가 원하는 인터페이스의 스케치를 보여주고 그들이 실제로 API와 어떻게 상호 작용하는지 확인한다. 사용자가 원하는 것을 추측하지 말고, 실제로 묻고 대답을 들어서 정확하게 파악해라.
특히 프로덕트 매니저가 해야 할 일로 치부하면서 여러분이 사용자의 욕구를 직접 파악할 수 있는 길을 무시하지 말자!
성공 측정 기준 설정
새 기능을 만든다면 프로덕트의 요구사항을 정리한 문서PRD, Product requirements document처럼 이미 정해진 성공 측정success metric 방법이 있을 수도 있거나 직접 측정 기준을 제안할 수도 있다. 어느 쪽이 됐든 후원자와 프로젝트의 다른 리더의 동의를 얻어야 한다.
마이크로서비스 전문가 사라 웰스는 쿠버네티스 콘퍼런스인 쿠버콘Kubecon에서 「쿠버네티스로 150개 이상의 마이크로서비스를 마이그레이션하는 과제The Challenges of Migrating 150+ Microservices to Kubernetes」라는 기조연설을 진행했다. 그녀는 이 연설에서 마이그레이션의 성공 여부를 판별하는 두 가지 측정 기준을 제시했다. 첫 번째는 클러스터cluster를 정상적으로 유지하는 데 걸린 시간을 측정하는 것이었고, 두 번째는 이 기능에 대한 불만을 슬랙으로 토로하는 팀원들의 수를 측정하는 것이었다. 두 가지 모두 충분히 객관적으로 측정 가능한 방법이다.
처음 프로젝트를 시작할 때는 성공 측정 기준을 정의하는 데 더욱더 주의를 기울여야 한다. 만약 신뢰성과 사회 자본이 굳건하다면 다른 사람들의 믿음을 바탕으로 프로젝트를 시작하거나 설득력 있는 문서나 영감을 주는 연설을 통해 프로젝트를 후원하도록 설득할 수 있다. 프로젝트가 어떻게 진행되는지 명확하게 파악할 수 있도록 아이디어를 현실적인 관점에서 바라보며 측정 가능한 기준을 설정하자.
후원자, 이해관계자 및 사용자 탐색
프로덕트 요구사항 문서가 있다면 문서에 이 모든 내용이 적혀 있을 수도 있지만, 그렇지 않다면 직접 이 사항들을 명확하게 정의해야 한다. 첫 번째, 사용자 또는 주요 이해관계자가 누구인지, 두 번째, 그들이 원하는 것은 무엇인지, 세 번째, 언제 결과를 보고 싶어 하는지 등이다.
고정 제약 조건 설정
업무를 수행할 때마다 어느 정도는 제약을 받는다. 그렇다면 제약이 무엇인지 명확하게 이해하자. ‘절대로 뒤로 미룰 수 없는 마감일이 있는가?’, ‘프로젝트 진행 예산은 충분한가?’, ‘너무 바빠서 도와줄 시간이 없는 팀이나 사용할 수 없는 시스템 컴포넌트에 의존하고 있지는 않은가?’, ‘같이 일하기 힘든 사람과 함께 일해야 하는가?’ 등이다.
구속하는 제약을 명확하게 이해하는 것은 다른 사람들의 기대치도 정할 수 있도록 도와준다. ‘단순히 기능을 제공하는 상황’과 ‘엔지니어를 충분히 보유하지 않은 상태에서 서로 합의점을 찾지 못한 두 이해관계자와 함께 기능을 제공하는 상황’에는 아주 큰 차이가 있다. 원하는 대로 되지 않는다고 현실에 분개하는 데 시간을 낭비하지 말고, 현실을 정확하게 직시하자.
위험 요소 관리
현실의 프로젝트에서는 종종 문제가 발생하며 규모가 커지면 커질수록 위험도 더 커진다. 이에 잘 대비할 수 있도록 몇 가지 위험 요소를 사전에 예측해보자.
가장 일반적인 위험 요소 중 하나는 헛된 노력에 대한 두려움이다. 이럴 때는 프로젝트를 진행하며 특정 부분을 반복해서 자주 수정할수록 위험성을 줄일 수 있다. 사용자 피드백을 받으며 진행 단계를 자주 수정하지 않으면, 마지막 출시 단계에서 성공이냐, 실패냐의 단 한 가지 가능성밖에 남지 않는다.
프로젝트 이력 파악
완전히 새로운 프로젝트일지라도, 알아야 할 그간의 이력이나 맥락이 있을 수 있다. 해당 프로젝트가 완전히 새로운 아이디어에서 출발한 것이 아니라면, 지난 이력은 대개 모호하고 심지어 알고 싶지 않은 것일 수 있다.
기존의 프로젝트를 처음 접하는 경우라면 무작정 그 프로젝트에 뛰어들지 말고, 먼저 다양한 대화를 나누어보자. 새로운 해결책을 만들기 전에 사용법이나 해결책 또는 정리해야 할 부분을 절반 정도만 먼저 완성해서 확인해보자. 그리고 다른 사람들이 이 프로젝트에 가진 감정이나 기대를 이해하고 그들의 경험으로부터 배우자.
팀 규모 파악
프로젝트의 규모에 따라서 몇 명의 주요 담당자 또는 팀 구성원, 리더, 이해관계자, 사용자 및 주변 역할을 대규모로 채용해야 할 수도 있다.
한 팀만 참여하는 프로젝트의 리더라면 해당 팀의 모든 사람과 정기적으로 대화를 나눌 수 있다. 그러나 규모가 더 큰 프로젝트라서 더 많은 팀이 참여한다면 팀별로 연락 담당자가 필요하다.
큰 프로젝트이고 리더가 많다면 다른 모든 리더와 좋은 업무 관계를 구축하고 서로 돕는 것이 중요하다. 권력 다툼에 시간을 낭비하지 말자. 협업해서 업무를 잘 수행하면 공동의 목표를 달성할 가능성이 훨씬 더 커진다.
5.2.3 프로젝트 공식 구조 설정
앞에서 다룬 모든 상황을 고려해서 프로젝트를 실행하는 데 도움이 되는 공식 구조를 설정해볼 수 있다.
다음은 프로젝트 구조를 설정하기 위해서 필요한 몇 가지 업무다.
역할 정의
시니어 수준에 이르면 엔지니어링 역할의 경계가 서로 모호해진다. 예를 들어서 고참 시니어 수준의 엔지니어나 엔지니어링 매니저 및 기술 프로그램 매니저 간의 역할 차이가 명확하게 구분되지 않을 수도 있다. 기본적으로 이들은 모두 소위 ‘방 안의 어른’역할을 맡고, 프로젝트의 위험을 식별하며 진행을 저해할 만한 것들을 제거해서 문제를 해결할 책임이 있다. 즉, 프로그램 매니저는 진행 상황별 격차를 파악하고, 프로젝트 상태에 대해 소통하며, 프로젝트를 저해하는 점을 없애야 한다.
프로젝트 출범 초창기는 각 리더의 직무를 명확하게 설정하기에 가장 좋은 시기다. 그러니 이 시기에 반드시 각 역할을 명확하게 정의하자. 두 사람이 같은 일을 하고 있다는 것을 나중에 스스로 깨닫게 될 때까지 기다리지 말자.
가장 간단한 방법은 리더십 직책을 표로 만들어서 누가 각각 무엇을 맡아야 하는지를 정하는 것이다. [표 5-1]은 작성법 예시다.
표를 더 정교하게 구성해보고 싶다면 책임 할당 매트릭스 도구인 RACI를 써보자. RACI는 프로젝트마다 가장 일반적으로 포함되는 네 가지 주요 직책의 약자다.
■ 실무 담당자Responsible
실제로 업무를 담당하는 사람 ■ 의사결정권자Accountable
업무 수행 시 최종적으로 업무 완료를 승인하는 승인자.
■ 업무 수행 조언자Consulted
프로젝트 수행과 관련해 견해를 공유하는 사람 ■ 결과 통보 대상자Informed
프로젝트 진행 프로세스에 대한 최신 정보를 받는 사람
프로젝트 관리에 관심이 있다면 RACI의 다양한 변형 사항을 더 읽어보면 좋다. 물론 상황에 따라서 너무 과한 방법을 쓸 필요는 없지만, 정말 필요할 때는 당연히 써야 한다.
논란의 여지가 없는 구조를 제공하는 것이 RACI 방법이 지닌 진정한 장점이다. RACI는 사람들이 큰 문제 없이 모든 대화를 시작할 수 있는 방법을 제공해준다.
어떤 식으로 접근하든지 간에 본인의 역할이 무엇이고 누가 무엇을 하고 있는지에 대해 모든 리더가 동의하도록 노력하라.
프로젝트의 리더라면 궁극적으로 프로젝트에 대한 책임이 있다. 이 책임에는 아무도 맡지 않은 역할을 리더가 스스로 나서서 맡거나 최소한 업무가 완료되었는지 확인하는 것까지 포함된다.
인재 채용
하기 싫어하는 종류의 업무를 선호하는 사람들을 찾을 수 있는지 확인해보자. 바로 이것이야말로 최고의 파트너십이다!
프로젝트에 누가 참여하느냐에 따라서 마감일 준수, 업무 완성도, 목표 달성도 면에서 큰 차이가 발생한다. 함께 일하면서 온갖 마찰을 극복하고 일을 해낼 수 있는 사람들, 의지할 수 있는 사람들을 채용하자.
범위 합의
먼저 무엇을 할지부터 결정하자. 그리고 목표 달성을 위한 마일스톤을 세우고 마감 날짜를 결정하자. 각 마일스톤은 ‘어떤 기능이 포함되어 있는가?’, ‘사용자는 이 기능으로 무엇을 할 수 있는가?’ 등 여러 사항을 자세히 설명할 수 있어야 한다.
마일스톤은 어떤 식으로든 사용 가능하거나 데모 체험이 가능하며 사용자와 이해관계자로부터 피드백을 받을 수 있는 기회를 제공해준다. 마일스톤을 잘 구성해놓으면 사용자와 이해관계자들이 먼저 방향이 잘못되었다고 말해줄 수 있기에 잘못된 방향을 빨리 수정할 수 있는 기회가 생긴다.
프로젝트 범위를 최대한 작게 쪼개서 세부적인 마일스톤을 설정하라. 게다가 마일스톤이 있으면 목표를 잘 달성하고 있는지 수시로 점검할 수 있다. 이는 큰 동기 부여가 된다.
프로젝트가 매우 크다면, 업무를 흐름에 따라 분할하고 각각의 마일스톤을 설정해서 여러 업무 흐름workstream으로 구성하는 것이 좋다.
모든 직원이 명확하게 언제, 무엇을 하기로 했는지 동일한 생각을 해야 한다는 점이 중요하다.
업무 소요 시간 측정
『실용주의 프로그래머Pragmatic Programmer』에서 “프로젝트 일정 계획을 제대로 수립하는 유일한 방법은 동일한 프로젝트에 대해 충분한 경험을 쌓는 것이다.”라고 조언한다.
기능을 작은 단위로 배포하면 팀이 어떤 작업을 수행하는 데 얼마나 오래 걸리는지에 대한 경험을 쌓을 수 있으므로 매번 일정을 업데이트할 수 있다. 또한, 업무 소요 시간을 측정하는 것을 연습해서 그 측정이 실제로 맞는지 기록해보는 방법도 추천한다.
업무 소요 시간을 측정할 때는 관련 팀들의 의견도 고려해야 한다.
다른 팀에게 필요한 것을 늦게 말할수록, 그것을 얻을 수 있는 가능성은 크게 줄어든다. 그런데도 만약 다른 팀이 요청을 수락한다면, 그것은 동시에 그들의 현 업무를 방해하고 있다는 것이고 그들의 다른 프로젝트에 대한 업무 소요 시간 측정까지도 방해하는 것이다.
실행 계획 논의
■ 언제, 어디서, 어떻게 만날지에 대한 실행 계획 논의
■ 비공식적인 의사소통 장려하기
SNS에서의 대화, 비공식적인 아이스브레이커icebreaker 미팅, 또는 가능하다면 며칠 동안 모두가 한 자리에 모여서 서로 격려해보는 것이 좋다. 밈meme 스레드와 같은 농담을 서로 주고받는 것도 서로 간의 연결고리를 만들어주는 방법이다.
■ 프로젝트 상태와 업데이트를 공유하는 방법 논의
■ 프로젝트 관련 문서를 문서 홈에 모으기
프로젝트 관련 문서를 작성할 때 기억할 수 있는 URL이나 눈에 띄는 링크를 사용해서 쉽게 찾을 수 있도록 작성하라.
■ 개발 관행 파악하기
기존에 여러 프로젝트를 잘 수행해낸 기업에서 새 프로젝트를 진행하는 경우라면 질문에 대한 표준 답변이 있을 것이다.
킥오프 미팅 진행
킥오프 미팅kickoff meeting은 프로젝트 설정의 일환으로 마지막으로 하게 된다. 이미 중요한 정보를 다 설정했다면 킥오프 미팅이 불필요하다고 느낄 수도 있겠지만, 서로 얼굴을 마주 보며 추진력을 갖고 프로젝트를 시작하는 것은 생각보다 큰 힘이 된다. 특히 킥오프 미팅은 모든 사람이 같은 목표 아래에서 단결하고 팀의 일원으로 명확하게 느끼게 하는 기회를 제공한다.
킥오프 미팅에서 다루어야 할 주제들은 대개 다음과 같다.
5.3 프로젝트 진행
프로젝트 리더라면 운전석에 있는 것과 같다. 리더는 모든 사람을 목적지까지 안전하게 데리고 가야 할 책임이 있다.
5.3.1 탐색
프로젝트의 진정한 요구사항을 이해하고 이를 달성하기 위해 취할 수 있는 접근 방식을 평가하려면 연구와 탐색이 어느 정도 필요하다. 목표를 명확하게 설명하기 어려운 설계를 만들거나 설정한 목표가 구현에 대한 설명에 불과하다면, 이 탐색 단계를 충분히 거치지 않았다는 신호다.
프로젝트의 주요 측면은 무엇인가?
팀원들은 프로젝트나 사용 사례에서 중요하지 않은 작은 측면에 집착할 수도 있고, 다른 영역 범위를 생각하고 있을 수도 있다. 이런 상황에서는 같은 것을 설명하는데 다른 용어를 사용하거나 같은 용어라도 다른 의미로 사용할 수 있다. 그러니 프로젝트의 여러 팀이 동의하고 원하는 방향을 간결하게 설명할 수 있는 지점에 최대한 빨리 도달하자.
탐색을 해보면 다른 사람들의 기대치를 발견하고 그들이 하는 일에 대해 명확하게 정의할 수 있다. 비슷해 보이지만 실제로 관련이 없는 일, 또는 전혀 관련이 없어 보이지만 예상치 못한 연관성이 있는 일을 명확하게 구분할 수 있다.
가능한 접근 방법은 무엇인가?
실제로 수행하려는 일을 명확하게 하는 방법을 알아내자. 모두가 동의하는 해결책을 찾을 때까지는 열린 마음을 갖도록 노력하자.
기존의 해결책은 새롭게 상상했던 것과 다른 형태일 수도 있지만, 어떤 면에서는 더 나은 형태일 수도 있다. 유연하게 받아들이는 마음가짐을 갖자. 유사한 프로젝트의 성공 여부와 어떤 부분에서 어려움을 겪었는지 등을 알고, 이러한 프로젝트의 이력으로부터 배워라.
5.3.2 명확성 확보
프로젝트를 시작할 때 가장 중요하게 고려해야 할 부분 중 하나는 하고자 하는 일에 대해 모두에게 정신 모형을 제공하는 것이다. 프로젝트를 주도할 때는 프로젝트를 달성하는 데 도움이 된다면 까다로운 개념을 이해하는 데 시간을 할애해야 한다.
정신 모형 구축
이미 이해하고 있는 다른 것과 연관 지어서 생각해볼 수 있도록 무언가를 제공해주는 정도의 설명이 필요하다.
추상적인 아이디어라 해도 원래 잘 알고 있던 다른 사실과 연결하면 그 아이디어를 설명하거나 흡수하는 것이 쉬워진다.
사람들에게 편리하고 기억에 남는 개념을 사용하거나, 비유를 사용하거나, 다른 사람이 이미 이해하고 있는 것과 관련지어서 설명함으로써 프로젝트가 잘 진행되도록 만들어야 한다. 그렇게 하면 그들만의 정신 모형을 빠르게 구축할 수 있다.
명칭 공유
기업 내부에서는 사용자, 고객 및 계정과 같은 매우 일반적인 단어에도 특정한 의미가 있을 수 있다. 이러한 의미는 재무, 마케팅 또는 엔지니어링 분야의 누군가와 대화하는지에 따라서 달라진다. 소통하고자 하는 사람들에게 특정 단어가 어떤 의미를 갖는지 이해하는 시간을 갖고, 가능하다면 그들의 단어를 사용하자.
도판 사용
복잡성을 줄이려면 도판을 활용하라. 사람들이 시각화하도록 돕는 데 도판보다 더 쉬운 방법은 없다. 만약 무언가가 변경되었을 때 ‘전’과 ‘후’를 나타내는 도판 세트는 글보다 훨씬 더 명확하다.
도판을 사용할 때는 고정관념에 유의하자. 다이어그램에서 원기둥 모양은 대부분 데이터 스토리지로 인식되기 때문에, 다른 의미로 사용하지 않는 것이 좋다.
도판은 그래프 또는 차트의 형태를 취할 수도 있다. [그림 5-2]처럼 목표와 그 목표를 향해 나아가는 선을 보여줄 수 있다면 성공이 어떤 모습일지 쉽게 알 수 있다.
5.3.3 설계
의견 일치를 확인하는 가장 효율적인 방법은 기록하는 것이다.
설계 문서의 필요성
많은 사람이 공동의 이해 없이 함께 무언가를 성취하도록 하기는 매우 어렵다. 서면 계획 없이는 이해를 공유하고 있다는 확신을 갖기가 어렵기 때문이다.
설계 검토를 요청하는 것은 단순히 아키텍처 또는 일련의 단계의 실현 가능성에 관해 묻는 것만 의미하지는 않는다. 올바른 문제에 제대로 접근해서 해결하고 있는지와 다른 팀과 기존 시스템에 대한 가정이 올바른지에 대한 동의도 포함한다.
서면 설계는 가장 저렴한 업무 수행 방식이다.
RFC 템플릿의 중요성
아무리 훌륭한 아키텍트라고 해도, 복잡한 시스템이나 프로세스 또는 변화를 설계하려면 기억해야 할 것이 아주 많다. 그리고 인간은 모든 것에 주의를 기울이는 데는 능숙하지 않다.
좋은 RFC 템플릿은 결정 사항을 생각하는 데 도움이 되고, 잊어버릴 수도 있는 주제를 확실하게 다시 상기시켜 준다.
RFC 템플릿 필수 포함 사항사항
좋은 RFC 템플릿을 위해서 최소한 표 제목으로 포함되어야 하는 항목들이다.
■ 맥락
RFC 문서에는 제목, 작성자 이름 및 날짜 중에서 하나 이상은 있어야 한다. 그리고 문서의 상태까지 포함해야 한다. RFC를 빠르고 쉽게 찾을 수 있도록 해주는 표준 제목 형식보다 정보의 이용 가능 여부가 더 중요하다.
■ 목표
목표 부분은 왜 이것을 하고 있는지 설명해야 한다. 즉, 어떤 문제를 해결하려고 하는지, 또는 어떤 기회를 이용하려고 하는지 보여주어야 한다. RFC는 검토자가 올바른 문제를 해결하고 있다고 생각하는지 알 수 있도록 충분한 정보를 제공해야 한다.
또한, 목표에는 구현 세부 정보가 포함되지 않아야 한다. 실제로 어떤 문제를 누구를 위해 해결하려고 하는지 모른다면, 이것이 정말로 올바른 접근법인지 평가할 수 없다.
구체적인 구현은 목표에 부합해야 하지만, 그것이 목표가 되어서는 안 된다. 설계 결정은 설계 부분에 맡겨라.
■ 설계
설계 부분에서는 목표를 달성하려는 실제 방법을 설명해야 한다. 문서를 읽는 검토자가 해결책이 잘 작동할 수 있는지를 평가할 수 있도록 충분한 정보를 포함해야 한다. 잠재적인 사용자나 프로덕트 매니저를 위한 글을 쓰는 경우라면 사용자에게 제공하려는 기능과 인터페이스를 명확히 설명해야 한다. 시스템이나 컴포넌트에 의존하는 경우라면 그것들을 어떻게 사용할지 설명해서 검토자들이 그들의 능력을 부족하다고 오해하지 않도록 하는 것이 좋다.
RFC에서 중요한 것은 마지막까지 읽고 난 검토자들이 문서에서 무엇을 하려고 하는지 이해하도록 하고, 그것의 효과를 말할 수 있어야 한다는 것이다.
모호한 것보다는 차라리 잘못된 것이 낫다
세부사항이 모호한 것보다는 차라리 틀리거나 논쟁을 벌이는 것이 시간을 더 잘 활용하는 것이다. 만약 틀렸다면 사람들이 그 사실을 말해줄 것이다. 그러면 적어도 무언가를 배울 것이고 필요하다면 계획을 바꿀 수도 있다. 만약 논란의 여지가 있는 아이디어를 시도하고 있다면 동료들이 그 접근법에 반대할 것인지, 아닌지를 일찍 알 수도 있다. 이처럼 설계에 대해 논쟁이 일어나거나 의견이 일치하지 않는 것은 프로세스를 변경해야 한다는 것을 의미하는 것이 아니라 궁극적으로는 여러분이 몰랐던 정보를 제공해주는 것이다.
■ 보안/개인 정보/준수
다음과 같은 질문들을 체크해보자. 문서에서 보호해야 할 가치가 있는 항목은 무엇이며, 누구로부터 보호해야 하는가? 여러분이 작성한 계획은 어떤 방식으로 사용자 데이터에 접속하거나 이를 수집하는가? 그 계획은 외부에 새로운 접속점을 제공하는가? 사용하는 키 또는 암호는 어떻게 저장하는가? 내부나 외부의 위협으로부터 시스템을 보호하고 있는가? 아니면 둘 다 보호하고 있는가?
■ 대안으로 고려할 만한 사항/선행 기술
‘대안 고려사항’ 부분은 실제로 문제를 해결하기 위해서 존재하는 부분이다. 이 부분은 해결책에만 매달리고 있지 않다는 사실을 다른 사람에게도 보여준다. 다른 대안을 고려하지 않아서 이 부분을 생략한다면 이는 문제에 관해서 충분히 생각하지 않았다는 신호다.
만약 그럴듯해 보이는 선택지가 이미 기업 내부에 존재하는데 그것을 사용하지 않았다면, RFC 작성자는 그 시스템을 소유한 사람들에게 새로운 설계 문서를 보내서 그들이 여러 방식으로 새롭게 생각해볼 기회를 주어야 한다.
다음의 항목들은 비교적 작은 규모의 RFC에도 반드시 포함되어야 한다고 생각하는 소제목들이다. 이 제목들을 사용하면 적어도 여러 항목을 정직하게 고려했다는 것을 보여줄 것이다.
기술적인 함정 유형
설계 문서에서 자주 볼 수 있는 몇 가지 함정이 있다. 다음과 같은 함정에 빠지지 않도록 먼저 관련 사항을 검토해보자.
■ 완전히 새로운 문제라고 생각하는 함정
다른 사람에게 배울 기회를 놓치지 말자. 또한, 기존 해결책을 재사용하는 것도 항상 염두에 두자.
■ 쉬운 문제라고 섣불리 단정 짓는 함정
대부분의 소프트웨어 엔지니어는 다른 도메인들도 그들의 도메인만큼 풍부하고 복합적인 프로세스로 이루어졌다는 점을 생각하지 않는 편이다.
왜 이전의 팀들이 여기에 수천 시간이나 투자했는지 이해가 안 될 수도 있다. 이 문제가 사소한 것처럼 보인다면 여러분은 이 문제를 제대로 이해하지 못한 것이다.
■ 미래를 내다보지 않고 현재에만 집중하는 함정
현재 상태에 맞춰서 올바르게 설계했다고 가정해도 이 해결책이 과연 3년 후에도 여전히 효과가 있을까? 기술적인 부분을 고려할 때는 현재를 넘어서 미래까지 생각해야 한다.
■ 머나먼 미래에 집착해서 설계하는 함정
만약 현재 사용하는 것보다 몇 배 더 큰 규모의 기술을 설계한다면, 그렇게 크게 설계해야 할 진정한 이유가 무엇인지도 고려해보자.
단순히 “우리는 나중에 이것이 필요할지도 모른다.”라는 말은 필요성을 정당화할 수 없다.
■ 모든 사용자를 고려하지 못하는 함정
사용자가 워크플로우workflow 또는 동작을 변경하는 것과 같은 해결책의 모든 부분은 매우 어렵다. 그러니 이 부분 또한 설계의 일부로 포함해야 한다.
■ 어려운 부분은 나중에 해결하려는 함정
프로젝트의 어려운 부분을 무시하거나 나중에 해결하려는 것은 실은 그 복잡성을 다른 사람에게 떠넘기는 것과도 같다.
■ 큰 문제를 더 어렵게 만들어서 작은 문제를 해결하는 함정
최소한 설계 단계에서 이 문제를 언급해야 한다. 더 큰 문제를 쉽게 할 방법을 찾기 전에 먼저 더 작은 문제부터 해결할 방법을 생각해보자.
■ 재설계할 필요가 없는데도 재설계하는 함정
다시 설계할 것을 결정하기까지는 여러 면에서 심사숙고하는 프로세스를 거쳐야 한다. 그래도 프로젝트를 잘 살펴보았을 때 ‘처음부터 다시 하기’가 최고의 해결책이라면, 솔직하게 이를 인정하자.
■ 시스템의 운영 및 관리를 어렵게 만드는 함정
팀에 새롭게 합류하는 사람들은 시스템을 훨씬 더 이해하기 어려워할 것이다. 그러니 다른 사람들이 쉽게 추론할 수 있도록 무언가를 만들어야 한다. 이때는 시스템을 관찰하고 디버깅할 수 있도록 하는 것을 목표로 한다. 모든 프로세스를 가능한 한 단순하게 하고 문서화하라.
■ 사소한 결정을 가장 많이 논의하는 함정
바이크쉐딩bikeshedding은 사소한 문제에 시간을 쓰는 걸 뜻하는 말로 원자력 발전소의 계획을 평가하는 대신에 대부분의 시간을 직원 자전거 보관소에 어떤 재료를 사용할 것인지와 같은 쉬운 주제를 논의하는 데 쓰는 것과 같은 비유를 들 수 있다.
이해하기 어렵거나 합의점을 찾기 어려운 결정에는 전혀 관여하지 않으면서 사소한 결정에는 많은 시간을 보낼 때가 있다.
5.3.4 코딩
대부분의 소프트웨어 프로젝트는 새로운 수많은 코드를 작성하거나 기존 코드를 변경하는 업무를 포함한다.
프로젝트 진행 시 코드 작성 문제
프로젝트의 리더의 코드 업무 기여 여부는 프로젝트의 규모, 팀의 규모, 여러분의 선호도에 따라서 달라진다. 수많은 프로젝트 리더가 코드를 많이 리뷰하지만, 직접 작성하지는 않는다.
“만약 일주일에 하루 정도 코딩을 작성했을 때 일할 의욕이 샘솟는다면, 그렇게 하라. 그러면 다른 일도 더 잘할 것이다.”
그러나 더 어렵고 중요한 것들을 희생하면서까지 코드를 작성하는 데 기여하지는 말아라. 더 크고 어려운 설계 관련 결정이나 조직에 중요한 일을 회피하고 여러분이 할 줄 아는 일만 맡는 간식 먹기와 같은 행위다.
롤모델 지양 및 병목 현상 지양
가장 크고 중요한 문제들을 떠맡게 된다면, 코딩 작업에 도달하는 데만 해도 다른 사람들보다 더 오랜 시간이 걸릴 것이다. 이는 다른 사람들의 업무 진행을 막고 병목 현상을 일으킬 수 있다. 만약 코딩을 해야 한다면 여유 시간이 있거나 업무상 꼭 필요한 때에만 수행하자.
작성한 코드를 다른 사람들을 돕는 지렛대로 생각하자.
팀의 역량을 강화할 수 있는 해결책을 목표로 하되, 그 해결책을 타인으로부터 양도받지는 말자.
모든 중요한 변화를 스스로 해결하기보다는 다른 사람들과 세부사항을 논의하거나 변화에 대응하기 위해 프로그래밍을 할 때 짝을 지어서 다른 사람들이 성장할 수 있도록 돕자. 짝을 짓는 것(페어링)은 지식을 공유하고 다른 사람의 스킬 역량을 발전시키도록 돕는다.
코드 및 변경 사항을 리뷰하는 중이라면 의견을 전달하는 방식에도 신경 쓰자. 비록 여러분이 스태프 엔지니어지만, 주니어 엔지니어들과 친하고 기탄없이 의견을 나누는 사이라고 생각할지라도 여러분이 그들의 업무에 관해서 언급하는 것은 주니어 엔지니어들에게는 위협적일 수 있다.
누군가가 적당히 해낸 업무를 보면 여러분이 더 잘할 수 있을 것 같더라도 괜히 관여해서 그들의 업무를 지배하지 않는 편이 더 낫다.
스태프 플러스 엔지니어는 팀에 대한 기대치를 설정하는 등 암묵적인 방식으로 본보기를 보일 수 있다. 그러므로 좋은 결과를 내는 것이 중요하다. 테스트 표준을 충족하거나 초과하는 수준의 결과를 선보이고, 유용한 설명과 문서를 추가하며, 신중하게 지름길을 선택하자.
5.3.5 의사소통
내부 의사소통: 친분 쌓기
팀원들끼리 서로 자유롭게 의견을 공유할 수 있을 정도로 서로를 편안하게 느끼도록 만들자. 공유 미팅, 우호적인 슬랙 채널, 데모 및 소셜 이벤트를 통해 관계를 더욱 쉽게 구축할 수 있다
관계 구축은 팀이 내부적으로 자연스럽게 질문을 주고받고 모르는 것은 편안하게 인정하는 데까지 도달하는 것을 목표로 한다.
외부 의사소통: 프로젝트 진행 상태 공유하기
외부와의 의사소통은 사용자가 무슨 일이 일어나고 있는지 쉽게 파악할 수 있도록 하고, 언제 다양한 마일스톤에 도달할 것인지에 대한 기대치를 설정하는 것이다.
프로젝트가 앞으로 어떤 영향을 미칠 수 있을지에 관한 정보와 실제로 검토자들이 무엇을 알고 싶어 하는지를 고려해서 해당 정보를 제공하는 것이 좋다. 그들은 사용자들이 지금 무엇을 할 수 있는지, 그리고 언제 다음 일을 할 수 있는지에 대해서 신경 쓴다. 만약 마일스톤상으로 중요한 중간 지점에 도달했는데 마감일까지 프로젝트를 완료하지 못할 것이라는 점이 확실해진다면, 이 정보는 이해관계자들에게 반드시 말해주어야 하는 사실이다.
명확하지 않은 점이 있으면 꼭 전달해야 할 점을 설명하자. “그것은 ···을 의미한다.”라는 식의 표현법, “우리는 할 수 있을 만큼 ···를 하고 있다.”라는 식의 표현법을 연습하자.
외부와의 의사소통은 프로젝트의 상태를 현실적이고 정직하게 말하는 것을 기본으로 한다. 만약 프로젝트가 어려움을 겪고 있다면 얼굴에 철판을 깔고 모든 것이 다 잘되리라고 말하고 싶은 유혹에 흔들릴 수도 있다. 그러나 이렇게 하면 프로젝트가 끝날 때쯤에 그간 거짓말을 일삼고 프로젝트의 문제를 숨기고 있었다는 사실을 인정해야 하는 순간이 오면 불쾌한 충격을 경험할 수도 있다.
5.3.6 안내
모든 프로젝트에는 항상 잘못될 가능성이 내포되어 있다. 계획의 핵심이었던 기술이 결국에는 적합하지 않다는 것을 나중에야 깨달을 수도 있다.
만약 무언가 잘못될 것이지만, 그 무언가가 무엇인지는 아직 모른다는 것을 가정한 상태로 프로젝트를 시작한다면 더 수월하게 프로젝트를 진행할 수 있다. 이런 태도는 좀 더 유연해지도록 도와준다. 즉, 장애물을 만나면 좌절하기보다는 이를 흥미롭게 살펴보게 만든다. 문제를 해결하는 프로세스를 스트레스로 여기지 말고 그간 겪어보지 못했던 경험을 해볼 수 있는 기회로 여기자.
프로젝트가 장애물에 부딪혔을 때 일어나는 일에 대해서는 책임을 져야 한다. 경로를 변경하거나, 도움을 줄 수 있는 사람에게 물어보거나, 정말로 필요하다면 목표를 달성할 수 없다는 사실까지도 이해관계자에게 알려야 할 책임이 있다.
무슨 일이 있어도 계속해서 의사소통을 시도하자.
매니저의 책임은 성공적으로 일을 마치도록 하는 것이고, 감독하는 책임자의 책임은 조직을 성공적으로 이끄는 것이다. 하지만 무언가에 가로막혀서 도움이 필요할 때 저지를 수 있는 가장 큰 실수는 도움을 요청하지 않는 것이다. 혼자서 힘들어하지 마라.
5.4 마치며