🤔 Chapter 8: 프로젝트 전에

🍭 Topic 45. 요구 사항의 구렁텅이

많은 책과 튜토리얼에 따르면 "요구 사항 수집"은 프로젝트의 초기에 이뤄진다. 요구 사항이 이미 널려 있다는, 고로 그것들을 쉽게 찾아서 바구니에 주워 담고 행복하게 가던 길을 계속 갈 수 있다는 느낌을 풍긴다.

사실은 그렇지 않다. 요구 사항이 땅 위에 놓여 있는 경우는 드물다. 보통은 가정과 오해, 정치의 지층 속 깊숙이 묻혀 있다. 심지어 아예 존재하지 않을 떄도 있다.

Tip 75. 자신이 뭘 원하는지 정확히 아는 사람은 아무도 없다.

🥕 요구 사항 미신

진짜 세상은 엉망이고 갈들이 넘쳐나며 알 수 없는 점도 많다. 무엇을 다루든 정확한 명세란 것은 거의 불가능하다고 볼 수 있다.

그래서 우리 프로그래머들이 등장한다. 우리의 일은 사람들이 자신이 원하는 바를 깨닫도록 돕는 것이다. 사실 이게 우리의 가치가 가장 빛나는 부분일 것이다. 그러니 다시 한번 반복하겠다.

Tip 76. 프로그래머는 사람들이 자신이 원하는 바를 깨닫도록 돕는다.

🥕 요구 사항은 과정이다

Tip 77. 요구 사항은 피드백을 반복하며 알게 된다.

여러분의 임무는 의뢰인에게 그들이 제시한 요구 사항의 여파를 꺠우쳐 주는 것이다. 여러분은 피드백을 주고 의뢰인은 피드백을 바탕으로 자기 생각을 더 가다듬는다.

가끔은 여러분이 익숙하지 않은 분야여서 구체적으로 피드백을 주기 어려울 수도 있다. 그럴 때 실용주의 프로그래머는 "말씀하신 게 이런 것입니까?" 부류의 피드백에 의존한다. 우리는 모형이나 프로토타입을 만들어서 의뢰인이 직접 다루어 볼 수 있도록 한다. "이건 제가 원한 것이 아닌데요."라고 할 때 "그러면 이런 식일까요?"라고 다시 물어볼 수 있다면 좋을 것이다.

종종 이런 모형은 한 시간 남짓이면 후다닥 만들어 낼 수 있다. 공들여 만들지 않아도 생각을 전달할 수만 있다면 된다.

그런데 사실 우리가 하는 모든 일은 일종의 모형을 만드는 것이다. 프로젝트가 막바지에 이르러서도 우리는 의뢰인이 원하는 것을 계속 해석해야 한다. 사실 프로젝트 막바지가 되면 의뢰인의 수가 늘어난다. QA 사람들, 운영팀, 마케팅, 어쩌면 고객사의 테스트 조직까지 모두 의뢰인이 된다.

그러니 실용주의 프로그래머는 프로젝트 전체를 요구 사항 수집 과정으로 보아야 한다. 그래서 우리는 짧은 주기로 반복하는 것을 선호한다. 반복 주기가 끝날 때마다 직접 의뢰인에게 피드백을 받는다. 그러면 우리가 궤도에서 벗어나지 않을 수 있다. 혹시 우리가 정말로 잘못된 방향으로 가더라도 잃어버리는 시간을 최소화할 수 있다.

🥕 의뢰인의 입장에서 보라

시스템이 실제로 어떻게 사용될지 통찰을 얻을 수 있을 뿐 아니라, "일하시는 데 일주일만 옆에 앉아 있어도 될까요?"라고 부탁하는 것이 의뢰인과 신뢰를 구축하고 의사소통의 기반을 다지는 데 얼마나 도움이 되는지 놀라게 될 것이다. 단, 방해햐지 않도록 주의하라.

Tip 78. 사용자처럼 생각하기 위해 사용자와 함께 일하라.

피드백 수집은 의뢰인과의 관계를 쌓아 나가는 시작점이기도 하다. 그들이 여러분이 만드는 시스템에 어떤 것을 기대하고 바라는지 들을 수 있다.

🥕 요구 사항 대 정책

Tip 79. 정책은 메타데이터다.

시스템은 다양한 정책을 처리할 수 있도록 일반적으로 구현해야 한다.

🥕 요구 사항 대 현실

도구가 성공하려면 사용하는 사람의 손에 적응할 수 있어야 한다는 우리의 믿음을 잘 보여 준다. 이 점도 염두에 두어야 성공적으로 요구 사항을 수집할 수 있다. 그래서 프로토타입이나 예광탄을 이용한 빠른 피드백으로 의뢰인으로부터 "네. 이것이 원하는 것이 맞긴 한데 제가 원하는 방식은 아니네요."라는 반응을 얻어야 하는 것이다.

🥕 요구 사항 문서화

우리는 최고의 요구 사항 문서, 아니 아마 유일한 요구 사항 문서는 작동하는 코드라고 믿는다.

그렇다고 의뢰인이 원하는 바를 여러분이 어떻게 이해했는지 문서로 정리하지 않아도 된다는 뜻은 아니다. 그저 문서는 목표가 아니고, 의뢰인에게 승인해 달라고 들이밀 수 있는 것도 아니라는 뜻일 뿐이다. 문서는 구현 과정에서 안내 역할을 하는 이정표일 뿐이다.

요구 사항 문서는 의뢰인을 위한 것이 아니다

의뢰인이 2분 정도 원하는 것을 설명하면, 그것을 확장하여 그림과 표로 가득 찬 손가락 한 마디 두께의 걸작을 만들어 냈다. 구현하면서 모호한 부분이 거의 없을 정도로 모든 것을 상세하게 정의했다. 충분히 강력한 도구만 있었다면 정말로 문서를 프로그램으로 변환할 수도 있었을 것이다.

이런 문서를 만든 것은 두 가지 면에서 틀렸다. 첫째는 우리가 논의했듯이 의뢰인은 자신이 원하는 것을 처음에는 잘 모른다. 따라서 의뢰인이 말한 것을 확장하여 법률 문서에 준하는 수준으로 만든 문서는 그저 사상누각에 불과하다.
여러분이 이렇게 항변할지도 모르겠다. "하지만 우리가 의뢰인에게 요구사항 문서를 가져갔더니 도장을 찍어 주었단 말입니다. 우리는 피드백을 받았어요." 이것이 바로 요구 사항 명세의 두 번쨰 문제다. 의뢰인은 절대 그걸 읽지 않는다.

의뢰인이 프로그래머를 고용하는 이유는 의뢰인은 고차원적이고 모호한 측면이 있는 문제를 풀고 싶어 하는 반면, 프로그래머는 세부 사항과 미묘한 차이 하나하나에 관심을 두기 때문이다. 요구 사항 문서는 개발자를 위해서 쓰는 것이다. 의뢰인이 보기에는 이해하기 어려운 부분도 많고, 온통 지루하기만 한 정보와 세부 요소들을 담고 있다.

요구 사항 문서는 계획을 위한 것이다

어떤 형식으로 요구 사항 문서를 적어야 할까? 우리는 진짜 인덱스카드 혹은 가상의 인덱스 카드에 들어갈 정도로 적는 방식을 선호한다. 이런 짧은 설명을 "사용자 스토리(user story)"라고도 부른다. 여기에는 애플리케이션의 작은 일부가 그 기능을 쓰는 사용자 관점에서 어떻게 작동해야 하는지를 적는다.

이렇게 적으면 요구 사항을 화이트보드에 붙일 수도 있고, 상태나 우선순위를 표현하기 위해 이리저리 옮길 수도 있다. 요구 사항 설명을 이처럼 짧게 제한하면 개발자들이 명확하지 않은 점을 물어보도록 유도할 수 있다. 코드를 작성하기 전이나 작성하는 도중에 일어나는 의뢰인과 개발자 간의 피드백 과정이 더 활발해지는 것이다.

🥕 지나치게 자세한 명세

요구 사항 문서를 만들 때 생기는 또 다른 심각한 문제는 지나치게 자세히 서술하는 것이다. 좋은 요구 사항은 추상적이다. 요구 사항을 기술할 때는 사업에 필요한 사항을 정확히 반영하는 가장 간단한 표현이 최고다. 밑에 깔려 있는 의미론적 불변식을 요구 사항으로 잘 갈무리하고, 구체적인 작업 방식이나 현재의 작업 방식은 정책으로 문서화해야 한다.

요구 사항은 아키텍처가 아니다. 요구 사항은 설계가 아니며 사용자 인터페이스도 아니다. 요구 사항은 필요를 표현하는 것이다.

🥕 딱 하나만 더...

많은 프로젝트가 범위의 증가 때문에 실패한다고 알려져 있다. "기능 블로트"나 "기능 크리프", "요구 사항 크리프"라고도 한다. 요구 사항이 슬금슬금 추가되는 것을 어떻게 막을 수 있을까?

해답은 다시 한번 피드백이다. 반복 주기를 거치며 의뢰인과 정기적으로 피드백을 주고받는다면, "딱 한 기능만 더"란 요청이 미치는 영향을 의뢰인이 직접 체험할 것이다. 화이트보드에 또 다른 스토리 카드를 올리겠지만, 그 카드를 구현할 시간을 확보하기 위해 다음 반복 주기로 미룰 카드 선택을 도와주게 될 것이다. 피드백은 서로 주고받는 것이다.

🥕 용어 사전 관리하기

요구 사항에 대한 토론을 시작하자마자 사용자나 도메인 전문가들은 그들에게 특별한 의미가 있는 용어들을 사용할 것이다.

프로젝트 용어 사전을 만들고 관리하라. 프로젝트에서 사용하는 모든 용어와 어휘를 모아 놓은 단 하나의 장소여야 한다. 최종 사용자에서 지원 부서 직원까지 프로젝트에 참가하는 모든 사람이 일관성을 위해 동일한 용어 사전을 사용해야 한다. 이렇게 되려면 용어 사전에 여러 사람이 접근하기 쉬워야 한다. 따라서 온라인 문서가 적합하다.

Tip 80. 프로젝트 용어 사전을 사용하라.

사용자와 개발자가 동일한 것을 다른 이름으로 부른다면 프로젝트는 성공하기 힘들다. 같은 이름으로 서로 다른 것을 지칭한다면 더더욱 힘들다.

🍭 Topic 46. 불가능한 퍼즐 풀기

🥕 자유도

어떤 퍼즐이든 그것을 해결하는 열쇠는 제약을 인식하는 것과 더불어 여러분에게 주어진 자유도를 파악하는 것이다. 퍼즐의 해답은 그 자유도 안에서 발견된다.

모든 선입견을 의심하고 그것이 진짜 바꿀 수 없는 제약인지 가늠해 봐야 한다.
이것은 틀을 벗어나고 벗어나지 않고의 문제가 아니다 문제는 틀을 찾는 것, 곧 진짜 제약을 찾는 일이다.

Tip 81. 생각의 틀을 벗어나지 말로, 틀을 찾아라.

풀리지 않는 문제와 마주쳤다면 생각해 볼 수 있는 모든 해결 경로 후보를 눈 앞에 나열해 보라. 아무리 쓸모없고 바보 가아 보이는 경로라도 절대 버리지 말라.

제약을 범주별로 나누고 우선순위를 매겨라. 제일 구석이 심한 제약부터 파악해 내고 나머지 제약을 그 안에서 맞춰 보아야 한다.

🥕 자신만의 방법에서 빠져나오라

어떤 때는 문제가 생가보다 훨씬 어려워 보이기도 한다. 아마 접근 방법을 잘 못 선택했다는 느낌이 들 것이다. 잠시 딴짓을 하기 딱 좋은 시간이다. 잠깐 다른 일을 하라.

여러분의 의식적인 뇌와 문제를 인지하고 있긴 하지만, 뇌의 이 부분은 사실 꽤 멍청하다. 여러분이 일부러 딴짓을 하고 있을 때 갑자기 여러분의 머릿속에 답이 떠오르는 일이 얼마나 자주 일어나는지 놀라게 될 것이다.

간단히 표현하면 딴짓을 한 사람이 의식적으로 노력한 사람보다 복잡한 문제 해결 과제를 더 잘 해냈다.

혹시 문제를 잠시도 손에서 놓고 싶지 않다면, 다음으로 좋을 만한 방법은 문제를 놓고 이야기할 사람을 찾는 것이다. 그저 문제에 대해 이야기하는 것으로 주의를 돌리기만 해도 깨달음을 얻을 때가 있다.

🥕 행운은 준비된 사람에게 찾아온다.

관찰을 할 떄, 행운은 준비된 사람에게 찾아온다.

이는 문제 해결에서도 마찬가지다. "유레카!"의 순간을 경험하려면 여러분 뇌의 무의식 영역에 원료를 많이 주입해야 한다. 문제 해결에 필요한 원료는 바로 해답에 도움이 될 수 있는 경험이다.

여러분의 뇌에 경험을 주입하는 가장 좋은 방법은 일상적인 작업을 할 때 무엇은 잘되고 무엇은 안되는지 피드백을 주는 것이다. 그리고 언제나 "겁먹지 마시오(DON'T PANIC)"를 명심하라.

🍭 Topic 47. 함께 일하기

이 책 전반에 걸쳐 우리는 사용자와 밀접하게 함께 일하라고 권했따. 사용자는 여러분 팀의 일원이다. 우리가 함께 일한 첫 번째 프로젝트에서 우리는 요즘이라면 "짝 프로그래밍"이나 "몹 프로그래밍"이라고 부를 방식을 사용했다. 한 사람이 코드를 입력하는 동안 한 명 혹은 여러 명의 팀 동료가 조언하고 고민하며 문제를 함께 푸는 것이다. 이 방식은 함께 일하는 아주 강력한 방법이다. 끝없는 회의나 제안서보다, 그리고 유용성보다 무게를 더 중시하는 법률 문서스러운 문서 뭉치보다 훨씬 낫다.

이것은 우리가 말하는 "함께 일하기"다. 그저 질문하고, 토론하고 메모를 하는 것이 아니라, 실제로 코딩을 하는 와중에 질문을 하고 토론을 하는 것이다.

🥕 짝 프로그래밍

짝 프로그래밍은 익스트림 프로그래밍의 실천 방법 중 하나였지만 XP와 별개로도 유명해졌다. 짝 프로그래밍에서 개발자 한 명은 키보드를 조작하지만 다른 한 명은 하지 않는다. 키보드 담당은 필요에 따라 바꿀 수 있고, 둘이 함께 문제를 푼다.

짝 프로그래밍에는 여러 가지 장점이 있다. 사람들은 모두 다르므로 다른 배경과 경험을 가지고 있고, 문제를 푸는 데도 다른 기법과 접근 방법을 사용한다. 주어진 문제를 집중하는 정도나 주의력도 제각각이다. 입력을 담당한 개발자는 문법이나 코딩 스타일 같은 낮은 수준의 세부 사항에 집중해야만 한다. 반면에 다른 개발자는 문제를 더 높은 수준에서 넓은 범위를 보며 고민할 수 있다.

두 번째 사람의 존재로 인해 생기는 사회적인 압력은 변수 이름을 foo로 짓는 것 같은 나쁜 습관이나 약점으로부터 우리를 지켜준다. 다른 사람이 지켜보고 있으면 민망할 수도 있는 꼼수를 덜 쓰게 되고, 결과적으로 소프트웨어의 품질이 좋아진다.

🥕 몹 프로그래밍

몹 프로그래밍은 셋 이상의 사람이 참여하는 짝 프로그래밍의 확장판이다. 몹 프로그래밍 지지자들은 몹 프로그래밍이 어려운 문제를 해결하는 데 아주 좋다고들 한다. 몹에는 사용자나 프로젝트 후원자, 테스터처럼 일반적으로 개발팀의 일부로 여겨지지 않는 사람도 쉽게 끌어들일 수 있다.

몹 프로그래밍을 "실시간 코딩을 곁들이 밀접한 협업"이라고 생각해도 될것이다.

🥕 무엇을 해야 할까?

현재 늘 혼자서 프로그래밍을 하고 있다면 짝 프로그래밍을 시도해 봐도 좋을 것이다. 처음에는 어색할 테니 한 번에 두어 시간씩 최소 2주만 해 보라.
새로운 아이디어를 모아야 하거나 골치 아픈 문제를 분석해야 한다면 몹 프로그래밍 시간을 가져 봐도 좋을 것이다.

짝 프로그래밍이나 몹 프로그래밍을 이미 하고 있다면 누구와 함께 하는가? 개발자끼리만 하는가, 아니면 사용자나 테스터, 후원자 등 더 넓은 범위의 팀원과도 하는가?

이렇게 하면 일하는 동안 기술적인 면 외에 인간적인 측면도 신경 써야 한다. 가장 먼저 고려할 만한 몇 가지 팁을 적어 보았다.

• 코드를 짜는 거지 자아(ego)를 쌓는 게 아니다. 누가 가장 똑똑한지 겨루은 것이 아니다. 우리 모드는 각자 뛰어난 부분이나 장단점이 있다.
• 소규모로 시작하라. 네다섯 명과 몹을 만들어 보거나, 짝 프로그래밍을 짧게 몇 번 해 보는 것으로 시작하라.
• 코드만 비판하고 사람을 비판하지 말라. "넌 틀렸어."보다는 "이 부분을 한 번 볼까요?"가 훨씬 듣기 좋다.
• 다른 사람의 관점을 듣고 이해하려고 노력하라. 다른 것은 틀린 것이 아니다.
• 자주 회고를 하라. 그래서 다음번에 시도하거나 개선할 점을 찾아라.

코딩을 같은 사무실에서 하든 혹은 원격에서 하든, 혼자든, 짝이든, 몹이든, 전부 함께 일하면서 문제를 푸는 유효한 방법이다. 여러분과 여러분의 팀이 늘 한 가지 방법으로만 일했다면, 다른 방식을 실험해 보는 것이 좋다. 하지만 너무 무턱대고 접근하지는 말라. 각각의 개발 방식마다 규칙과 참고 사항, 지침 들이 있다. 예를 들어, 몹 프로그래밍을 할 때는 키보드로 입력하는 사람을 5 ~ 10분마다 바꿔 주어야 한다.

교과서와 사례 보고서를 모두 찾아보고 연구를 좀 하라. 장점과 걱정되는 점에 대한 감을 잡아라. 곧장 제품의 가장 어려운 코드로 뛰어들기보다는 연습 삼아 간단한 문제로 시작해 보는 것이 좋을 것이다.

여러분이 어떻게 시작하든 우리의 마지막 조언은 다음과 같다.

Tip 82. 코드에 혼자 들어가지 말라.

🍭 Topic 48. 애자일의 핵심

"애자일(agile)"은 기민하다는 뜻의 형용사다. 즉, 무언가를 하는 방식이다. 여러분은 애자일한 개발자가 될 수 있다. 여러분은 애자일 실천 방법을 도입한 팀, 변화와 고난에 애자일하게 대처하는 팀에 속할 수 있다. 애자일은 여러분이 일하는 방식이지 여러분이 아니다.

Tip 83. 애자일은 명사가 아니다. 애자일은 무언가를 하는 방식이다.

우리는 많은 사람들이 진정한 애자일의 의미를 잊어버렸다고 느낀다. 이제는 들 기본으로 돌아와야 한다. 애자일 선언에서 언급한 가치를 기억하라

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 과정에서 우리는 다음과 같은 가치를 찾아냈다.

• 공정과 도구보다 개인과 상호작용
• 포괄적인 문서보다 작동하는 소프트웨어
• 계약 협상보다 고객과의 협력
• 계획을 따르기보다 변화에 대응하기 왼쪽에 있는 것도 가치가 있지만 우리는 오른쪽에 있는 것에 더 높은 가치를 둔다.

여러분에게 오른쪽에 있는 것보다 왼쪽에 있는 것의 중요도를 높이는 것을 팔려는 사람은 우리를 비롯한 애자일 선언 참가자들과 다른 가치관을 갖고 있음이 분명하다.

애자일의 가치는 소프트웨어를 만드는 더 나은 방법을 지속적으로 탐구하는 과정에서 찾고 알게 되는 것이기 때문이다. 애자일 선언 고정불변의 문서라기보다는 만들어 가는 과정에 대한 제안이다.

🥕 애자일 프로세스라는 것은 있을 수 없다

사실 누군가가 "이걸 하세요. 그러면 애자일인 겁니다."라고 한다면 이건 틀린 말이다. 정의상 그렇다.

물리적인 세계에서든 소프트웨어 개발에서든 애자일, 즉 기민함이란 것은 변화에 대응하는 것, 일을 시작한 이후 맞부딪히는 미지의 것에 대응하는 것이 전부이기 떄문이다.

소프트웨어를 개발할 때 따라야 할 단 한 가지 계획이란 없다. 애자일 선언의 네 가지 가치 중 세 가지가 이를 언급하고 있다. 온통 피드백을 수집하고 그에 대응하라는 것뿐이다.
이 가치들은 무엇을 하라고 알려 주지는 않는다. 대신 여러분이 할 일을 결정할 때 무엇을 추구해야 할지를 알려 준다.
그 결정은 언제나 상황에 따라 다르다. 여러분이 어떤 사람인지, 여러분의 팀은 어떤 특징이 있는지, 여러분의 애플리케이션이나 도구, 회사, 고객, 바깥세상은 어떤지에 따라 다르다. 엄청나게 많은 요인이 있고, 그중 몇 가지는 중요하지만 몇 가지는 별 영향이 없다. 이렇게 불확실한 환경이라면 고정된 채 바뀌지 않는 계획은 살아남을 수 없다.

🥕 그래서 우리는 무엇을 해야 할까?

누구도 여러분에게 무엇을 하라고 알려줄 수 없다. 에자일 선언은 피드백을 모으고 그에 맞게 행동함으로써 불확실성을 헤쳐 나가라고 제안한다. 우리가 제안하는 애자일하게 일하는 방법은 다음과 같다.

1. 여러분이 어디에 있는지 알아내라.
2. 도달하고 싶은 곳을 향하여 의미 있는 발걸음을 가능한 한 작게 옮겨라.
3. 어디에 도착했는지 평가하고, 망가트린 것이 있으면 고쳐라.

위 과정을 끝날 떄까지 반복하라. 위 과정을 여러분이 하는 모든 일의 모든 층위에서 재귀적으로 적용하라.

🥕 이 과정이 설계를 주도한다

좋은 설계는 나쁜 설계보다 바꾸기 쉬운 결과물을 만든다.

애자일에 대한 이 논의는 왜 바꾸기 쉬워야 하는지를 알려준다. 여러분이 뭔가 바꾼다. 하지만 바꾼 것이 마음에 들지 않는다. 앞에서 말한 과정을 따르려면 세 번쨰 단계에서 우리는 망가트린 것을 고칠 수 있어야 한다. 그렇지 않으면 어깨를 한번 으쓱하고는 망가진 채로 놔두고 싶은 유혹에 빠질 것이다. 애자일이 전반적으로 작동하게 하려면 좋은 설계를 만들어야 한다. 좋은 설계는 무언가를 바꾸기 쉽게 하기 때문이다. 바꾸기 쉽다면 모든 층위에서 아무런 주제 없이 문제를 바로잡을 수 있을 것이다.

이것이 애자일이다.