TIL 8장. 프로젝트 전에 – 노마드 코더 Nomad Coders

요구 사항이나 분석, 코딩, 테스팅 등 무엇을 하든 어려운 문제는 생기기 마련이다. 하지만 대게 첫눈에 보고 생각했던 것만큼 어렵지는 않다.
자신이 뭘 원하는지 정확히 아는 사람은 아무도 없다.
우리의 일은 사람들이 자신이 원하는 바를 깨닫도록 돕는 것이다. 사실 이게 우리의 가치가 가장 빛나는 부분일 것이다.
일반적으로 의뢰인은 필요한 것이 있어서 우리에게 찾아온다. 그 필요가 전략적일 수도 있으나, 단지 바로 현재 발생한 문제를 푸는 전술적 사안에 불과할 수도 있다. 기존 시스템을 변경해야 하거나, 새로운 것을 요청할 수도 있다. 요청을 비즈니스 용어로 표현하기도 하고 기술적인 용어로 표현하기도 한다. 신입 개발자들이 자주 범하는 실수는 이런 요청 사항을 받았을 때 바로 해결책을 구현해 버리는 것이다.
요구 사항은 피드백을 반복하며 알게 된다.
우리는 모형(mockup)이나 프로토타입을 만들어서 의뢰인이 직접 다루어 볼 수 있도록 한다. 만든 모형이나 프로토타입이 이리저리 바꾸기 쉬워서 의뢰인과 대화하는 도중에도 계속 바꿀 수 있다면 이상적이다. "이건 제가 원한 것이 아닌데요."라고 할 때 "그러면 이런 식일까요?"라고 다시 물어볼 수 있다면 좋을 것이다.
사실 우리가 하는 모든 일은 일종의 모형을 만드는 것이다. 프로젝트가 막바지에 이르러서도 우리는 의뢰인이 원하는 것을 계속 해석해야 한다. 사실 프로젝트 막바지가 되면 의뢰인의 수가 늘어난다. QA사람들, 운영팀, 마케팅, 어쩌면 고객사의 테스트 조직까지 모두 의뢰인이 된다.
실용주의 프로그래머는 프로젝트 전체를 요구 사항 수집 과정으로 보아야 한다. 그래서 우리는 잛은 주기로 반복하는 것을 선호한다. 반복 주기가 끝날 때마다 직접 의뢰인에게 피드백을 받는다. 그러면 우리가 궤도에서 벗어나지 않을 수 있다. 혹시 우리가 정말로 잘못된 방향으로 가더라도 잃어버리는 시간을 최소화할 수 있다.
피드백 수집은 의뢰인과의 관계를 쌓아 나가는 시작점이기도 하다. 그들이 여러분이 만드는 시스템에 어떤 것을 기대하고 바라는지 들을 수 있다.
사업 정책인가, 요구 사항이낙? 그 차이는 비교적 미묘하다. 하지만 이 차이가 개발자에게 중대한 의미가 있다. 만약 요구 사항이 "인사팀에서만 직원 기록을 열람할 수 있다."는 식으로 되어 있다면 개발자는 애플리케이션이 이 데이터에 접근할 때마다 인사팀인지 확인하는 코드를 작성할 것이다. 하지만 요구 사항이 "권한이 있는 사용자만이 직원 기록에 접근할 수 있다."는 식이라면 개발자는 아마도 일종의 접근 관리 시스템을 설계하고 구현할 것이다. 그러면 정책이 바뀔 때(실제로 바뀐다) 시스템의 메타데이터(metadata)만 업데이트 하면 된다. 실제로 이런 식으로 요구사항을 수집하면 자연스럽게 메타데이터를 지원하는 잘 분리된 시스템이 만들어질 것이다.
정책은 메타데이터다.
의뢰인이 프로그래머를 고용하는 이유는 의뢰인은 고차원적이고 모호한 측면이 있는 문제를 풀고 싶어 하는 반면, 프로그래머는 세부 사항과 미묘한 차이 하나하나에 관심을 두기 때문이다. 요구 사항 문서는 개발자를 위해서 쓰는 것이다. 의뢰인이 보기에는 이해하기 어려운 부분도 많고, 온통 지루하기만 한 정보와 세부 요소들을 담고 있다.
좋은 요구 사항은 추상적이다. 요구 사항을 기술할 때는 사업에 필요한 사항을 정확히 반영하는 가장 간단한 표현이 최고다. 그렇다고해서 모호하게 적어도 된다는 말은 아니다. 밑에 깔려 있는 의미론적 불변식을 요구 사항으로 잘 갈무리하고, 구체적인 작업 방식이나 현재의 작업 방식은 정책으로 문서화해야 한다.
요구 사항은 아키텍처가 아니다. 요구 사항은 설계가 아니며 사용자 인터페이스도 아니다. 요구 사항은 필요를 표현하는 것이다.
'프로젝트 용어 사전(glossary)'를 만들고 관리하라. 프로젝트에서 사용하는 모든 용어와 어휘를 모아 놓은 단 하나의 장소여야 한다. 최종 사용자에서 지원 부서 직원까지 프로젝트에 참가하는 모든 사람이 일관성을 위해 동일한 용어 사전을 사용해야 한다. 이렇게 되려면 용어 사전에 여러 사람이 접근하기 쉬워야 한다. 따라서 온라인 문서가 적합하다.
어떤 제약 조건은 절대적이지만, 다른 것들은 단순한 지레짐작에 불과하다. 절대적 제약 조건은 그것이 아무리 불쾌하거나 어리석어 보여도 꼭 따라야 한다.
유명한 경구 "생각의 틀을 벗어나라"는 유효하지 않은 제약을 인식하고 그걸 무시해 버리라고 말한다. 하지만 이 경구가 완전히 정확한 말은 아니다. 여기서 '틀'이 제약이나 조건 들의 경계선을 의미한다면, 우리가 해야 할 일은 그 틀을 파악하는 것이다. 그 틀은 여러분의 생각보다는 꽤 넓을 것이다.
어떤 퍼즐이든 그것을 해결하는 열쇠는 제약을 인식하는 것과 더불어 여러분에게 주어진 자유도(degree of freedom)를 파악하는 것이다. 퍼즐의 해답은 그 자유도 안에서 발견된다.
모든 선입견을 의심하고 그것이 진짜 바꿀 수 없는 제약인지 가늠해 봐야 한다. 이것은 틀을 벗어나고 벗어나지 않고의 문제가 아니다. 문제는 틀을 찾는 것, 곧 진짜 제약을 찾는 일이다.
생각의 틀을 벗어나지 말고, 틀을 찾아라.
풀리지 않는 문제와 마주쳤다면 생각해 볼 수 있는 모든 해결 경로 후보를 눈앞에 나열해 보라. 아무리 쓸모없고 바보 같아 보이는 경로라도 절대 버리지 말라. 이제 목록을 하나씩 점검하면서 왜 그 경로를 따라갈 수 없는지 설명해보라. 정말 확신하는가? 증명할 수 있는가?
여러분에게 이런 질문을 던져 달라고 부탁하라.
- 왜 이 문제를 풀고 있는가?
- 문제를 풀어서 얻는 것이 무엇인가?
- 풀려고 하는 문제가 특수한 경우에 해당하는가? 특수한 경우를 없앨 수는 없나?
- 관련된 문제 중에 여러분이 풀 수 있는 더 간단한 문제는 없나?
사용자는 여러분 팀의 일원이다. 우리가 함께 일한 첫 번째 프로젝트에서 우리는 요즘이라면 '짝 프로그래밍(pair programming)'이나 '몹 프로그래밍(mob programming)'이라고 부를 방식을 사용했다. 한 사람이 코드를 입력하는 동안 한 명 혹은 여러 명의 팀 동료가 조언하고 고민하며 문제를 함께 푸는 것이다. 이 방식은 함께 일하는 아주 강력한 방법이다. 끝없는 회의나 제안서보다, 그리고 유용성보다 무게를 더 중시하는 법률 문서스러운 문서 뭉치보다 훨씬 낫다.
짝 프로그래밍에는 여러 가지 장점이 있다. 사람들은 모두 다르므로 다른 배경과 경험을 가지고 있고, 문제를 푸는 데도 다른 기법과 접근 방법을 사용한다. 주어진 문제에 집중하는 정도나 주의력도 제각각이다. 입력을 담당한 개발자는 문법이나 코딩 스타일 같은 낮은 수준의 세부 사항에 집중해야만 한다. 반면에 다른 개발자는 문제를 더 높은 수준에서 넓은 범위를 보며 고민 할 수 있다.
몹 프로그래밍은 짝 프로그래밍의 확장판이다. 몹에는 사용자나 프로젝트 후원자, 테스터처럼 일반적으로 개발팀의 일부로 여겨지지 않는 사람도 쉽게 끌어들일 수 있다. 몹 프로그래밍을 '실시간 코딩을 곁들인 밀접한 협업'이라고 생각해도 될 것이다.
'에자일(agile)'은 '기민하다'는 뜻의 형용사다. 즉, 무언가를 하는 방식이다.
에자일 선언에서 언급한 가치를 기억하라
- 우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 과정에서 우리는 다음과 같은 가치를 찾아냈다.
  - 공정과 도구보다 개인과 상호작용
  - 포괄적인 문서보다 작동하는 소프트웨어
  - 계약 협상보다 고객과의 협력
  - 계획을 따르기보다 변화에 대응하기
- 왼쪽에 있는 것도 가치가 있지만 우리는 오른쪽에 있는 것에 더 높은 가치를 둔다.
우리가 제안하는 에자일하게 일하는 방법은 다음과 같다.
- 여러분이 어디에 있는지 알아내라.
- 도달하고 싶은 곳을 향하여 의미 있는 발걸음을 가능한 한 작게 옮겨라.
- 어디에 도착했는지 평가하고, 망가트린 것이 있으면 고쳐라.
- 위 과정을 끝날 때까지 반복하라.
에자일이 전반적으로 작동하게 하려면 좋은 설계를 만들어야 한다. 좋은 설계는 무언가를 바꾸기 쉽게 하기 때문이다 .바꾸기 쉽다면 모든 층위에서 아무런 주저 없이 문제를 바로잡을 수 있을 것이다.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

어려운 문제는 항상 생기기 마련이나, 생각만큼 어렵지는 않다는 말이 크게 다가왔다. 무언가를 시작하기 전에 항상 내가 이것을 할 수 있을까, 어떻게 해야 좋은 결과물을 만들 수 있을까. 또한 변경되어 가는 과정도 진행중에 추가되는 각종 요구 사항들도 나 자신의 결과물에 대한 자신감을 떨어뜨리는데 한 몫을 한다는 느낌이다. 그러나 막상 요구사항들을 정리하고, 단계를 정해서 차근차근 진행하다보면 어느 순간 내가 생각했던 것 보다 완성에 좀 더 근접해 있다는 것을 알게 된다.
어떻게 보면 프로그래밍에 대한 책이지만, 또 다르게 보면 실용주의 라는 삶의 태도를 전해주는 책이라는 생각이 든다. 모든 것을 쥐려 하지 않고, 완벽함을 추구하는 것이 아닌 할 수 있는 것을 파악하고, 할 수 있는 것들에 대해서 하는 것. 그리고 잘 되지 않을 때는 잠깐 쉬어가는 것. 안될 때는 안된다는 것을 인정하고, 한계를 수긍하고 절망하고 좌절하기보다는 언제 어디서라도 당장 내가 할 수 있는 것을 찾고, 그것이 어떻게 나아가는지에 대해 생각해보고 피드백 하라. 그리고 끊임없이 의심하고 생각을 멈추지 말라. 그리고 그것을 실천할 수 있는 작은 팁들. 그것이 이 책의 본질이 아닐까 하는 생각이 든다.
물론 코린이의 입장에서 예시로 든 코드들을 모두 이해하는 것은 지금 당장은 불가능했고, 제시되는 도구들을 어떤순간에, 어떤 방법으로 적용해야되는지는 당장은 모를 것 같다. 그저 마음 한구석에 메모해 두거나, 내가 읽었던 기록으로써 남겨두고 나중에 생각날때 다시 한번 읽어볼 수 있는 인생의 책갈피는 될 수 있을 것 같다.
추상적인 것은 구체적인 것 보다 유연하다. 그러나 모호하지는 않다. 모호한 것은 의미와 본질을 흐리게 만들지만, 추상적인것은 구체적으로 구현되기 바로 직전의 단계라는 생각이 든다. 그래서 추상적을 추구하되, 모호해지지 않도록 끊임없이 의심하고, 바라보고 잠깐 멈춰서 물러서서 보는 태도를 강조하는 것 같다.
그러니까 에자일하게.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

오늘 읽은 다른사람의 TIL

글쓰기

노마드코더 이벤트노마드 코더, 강의 1:1 상담 해드려요~️⭐️📚 노마드코더 신간 안내 📚 IT 5분 잡학사전

# interview