제 9장 실용주의 프로젝트

여러분의 직함이 명목상으로는 “소프트웨어 개발자”나 “소프트웨어 엔지니어” 비슷한 이름일지 몰라도
진정한 여러분의 직함은 “문제 해결사”다.
이것이 우리가 하는 일이고, 실용주의 프로그래머의 본질이다.

 

" 우리는 문제를 해결한다. "

TIL (Today I Learn)

• Assignment 15
• 2022-04-05

---

오늘 읽은 범위

• 9장 실용주의 프로젝트
  • Topic 49 실용주의 팀
  • Topic 50 코코넛만으로는 부족하다
  • Topic 51 실용주의 시작 도구
  • Topic 52 사용자를 기쁘게 하라
  • Topic 53 오만과 편견

---

3줄 요약

• 각 팀원이 자신의 방식대로 빛나게 하라.
• 유행하는 것이 아니라 실제로 잘 맞는 것을 사용하라.
• 사용자를 기쁘게 하라.

 

" 프로그래머는 고양이 같은 면이 있다. 
호기심 많고 제멋대로이며, 
고집이 세고, 
독립적인 데다, 
가끔은 인터넷에서 숭배를 받기도 한다. "

 

책에서 기억하고 싶은 내용을 써보세요

Topic 49 실용주의 팀

• 작고 안정적인 팀을 유지하라.
• 팀 전체가 깨진 창문을 용납하지 않아야 한다
  • 사소한 결점을 아무도 고치지 않고 놔두어서는 안 되고, 반드시 제품의 품질에 책임을 져야 한다.
• 품질은 팀원 모두가 제각기 기여할 때만 보장된다.
  • 품질은 애초에 제품에 포함된 것이지 나중에 덧붙이는 것이 아니다
• 팀은 개인보다 더 삶은 개구리가 되기 쉽다. 
  • 모든 사람이 적극적으로 환경 변화를 감시하도록 권장하라. 
  • 범위의 확장, 일정 단축, 추가 기능, 새로운 환경 등 무엇이건 간에 애초에 인지하고 있던 것과 다른 것들을 늘 깨어서 의식해야 한다.
  • 이미 일어난 변화를 거부할 필요는 없다. 단지 그런 일이 벌어지고 있다는 것을 파악하고 있으면 된다. 
• 할 일을 기능 개발로만 몽땅 채우지는 말라. 새로운 기능을 만드는 것 외에도 해야 할 일들이 있다. 
  • 구형 시스템 유지 보수
  • 프로세스 회고와 개선
  • 새로운 기술 탐험
  • 학습 및 기술 갈고 닦기
• 프로젝트를 시작할 때 이름을 지어 주는 것이다. 유별난 이름이라면 더 좋겠다.
  • 양을 잡아먹는 앵무새, 착시 효과, 애완용 쥐, 만화 캐릭터, 신화의 도시 등
  • 괴짜스러운 로고를 만들어 사용하라. 
• 좋은 의사소통이 이런 문제를 피하는 핵심이다. 여기서 “좋은”이란 즉각적이고 매끄러운 것을 말한다.
  • DRY를 지키려면 서로 관심을 유지하라. Don't Repeat Yourself !
• 모든 기능을 갖춘 팀을 조직하라.
  • 처음에는 작고 제한적일지라도 시스템의 끝에서 끝까지 전체에 걸쳐 있는 단일 기능을 개발할 것을 추천한다. 
  • 프론트엔드, UI/UX, 서버, DBA, QA 등이 모두 함께 일하는 것이 편안하고 익숙해야 한다. 
• 도구 제작 역량을 팀 내에 꼭 갖추어서 프로젝트 개발과 서비스 배포를 자동화하는 도구를 만들고 적용하라
• 팀은 개인들로 이루어진다는 사실을 명심하라.
  • 각 팀원이 자신의 방식대로 빛나게 하라.
  • 그리고 프로젝트가 가치를 만들어 내기에 딱 좋을 만큼의 구조를 제공하라.
  • 그러고 나면 계속 덧칠하려는 욕구를 참아야 한다. (멈춰야 할 때를 알라)

 

 

Topic 50 코코넛만으로는 부족하다

• 화물 숭배의 함정은 너무 솔깃해서 빠지기 쉽다. 눈에 잘 띄는 결과물을 만드는 데만 투자하면서 기반이 되는 작업이 마법처럼 끝나 있기를 소망한다. 
  • 코코넛 껍질로 만든 모조 공항은 진짜를 대체할 수 없다.
• 유행하는 것이 아니라 실제로 잘 맞는 것을 사용하라.
  • “잘 맞는 것”을 어떻게 알 수 있을까? 한번 해 보라. 
  • 잘 맞는 것 같은 좋은 부분만 유지하고 나머지는 낭비나 비용일 뿐이므로 버리면 된다. 
• 어떤 특정 방법론에서 가장 좋은 부분만 가져다가 적절히 조정하여 사용해야 한다. 
  • 만병통치약은 없고, 현재의 방법론들도 아직 완성되려면 멀었다. 
    • 여러분의 조직이 스포티파이나 넷플릭스와 다르게 운영된다고 해서 깎아내릴 사람은 아무도 없다.
  • 그러니 인기 있는 방법론 하나만 좇지 말고, 다른 것들로도 눈길을 돌려야 한다

 

하지만 우리 말을 곧이곧대로 받아들이지는 말라. 직접 이런 접근 방법들을 조사하고 시도해 보라.
하지만 지나치지 않도록 주의하라. 특정 방법론에 과도하게 투자하면 다른 대안을 보지 못하게 될 수도 있다.
하나에 고착되면 머지않아 다른 길을 보기 어렵게 된다.
한 가지 방식이 너무 굳어져 버리면 더 이상 빠르게 적응할 수 없게 된다.
... 코코넛을 사용하고 있는지도 모른다.

 

 

Topic 51 실용주의 시작 도구

버전 관리로 운용하라

• 버전 관리 시스템으로 빌드, 테스트, 릴리스를 운용하라.
  • 버전 관리 시스템의 커밋이나 푸시로 빌드와 테스트, 배포가 시작된다.
  • 빌드는 클라우드의 컨테이너 위에서 돌아간다
  • 배포 대상 환경은 버전 관리 시스템의 태그를 사용하여 지정한다.

 

" 테스팅은 버그의 존재만 보여줄 수 있지 버그의 부재까지는 보여줄수 없다."
-  데이크스트라

 

가차 없고 지속적인 테스트

• 일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라.
  • 단위 테스트 : 하나의 모듈을 테스트
  • 통합 테스트 :  프로젝트를 구성하는 주요 서브시스템이 다른 부분과 제대로 작동하는지 
  • 유효성 평가 및 검증 : 정말 사용자들이 필요로 하는 것인가? 시스템의 기능적 요구 사항을 충족하는가? 
  • 성능 테스트 : 예상하는 사용자 수나 접속 수 혹은 초당 트랜잭션 숫자를 염두
  • 테스트를 테스트 : 버그가 의도적으로 생기도록 한 다음 테스트가 경보를 울리는지 확인
    • 코드를 작성하자마자 테스트해야 한다.
    • 모든 테스트가 끝날 때까지는 코딩이 끝난 게 아니다.
    • 테스트 환경은 실제 환경과 최대한 비슷해야 한다. 두 환경의 차이에서 버그가 번식한다.
  • 속성 기반 테스트 :  계약과 불변식에 따라 테스트 데이터를 생성
• 코드 전체를 필요한 만큼 철저하게 테스트했다는 것은 어떻게 알 수있을까?
  • 한마디로 답하자면 “알 수 없다.” 그리고 앞으로도 알 수 없을 것이다.
• 한번 인간 테스터가 버그를 찾았다면 더는 인간 테스터가 그 버그를 만나서는 안 된다. 

전체 자동화

• 수작업 절차를 사용하지 말라

 

버전 관리, 가차 없는 테스트, 전체 자동화라는 세 기둥이 있다면 여러분의 프로젝트에 필수적인 견고한 기반이 생긴 것이다.
이제 여러분은 어려운 부분에 집중할 수 있다. 바로 사용자를 기쁘게 하는 것이다.

 

 

 

Topic 52 사용자를 기쁘게 하라

• 개발자로서 우리의 목표는 사용자를 기쁘게 하는 것 사용자를 기쁘게 하는 것이다. 
  • 여러분의 사용자가 진짜로 원하는 것은 코드가 아니다.
  • 여러분의 사용자가 기대하는 것은 소프트웨어와 관련이 없다.
  • 고객 잔존율, 데이터 품질, 절감한 비용 등의 성공 척도가 진짜로 의미 있는 사업 가치다.
  • 소프트웨어는 이런 목적을 달성하기 위한 수단일 뿐이다.
• 고객이 문제를 풀 때 적극적으로 도와줄 수 있는 관계를 구축하라. 

 

 

Topic 53 오만과 편견

• 자신의 작품에 서명하라.
  • 실용주의 프로그래머는 책임을 회피하지 않는다. 
  • 익명성은 특히 큰 프로젝트에서 적당주의나 실수, 태만, 나쁜 코드의 온상이 될 수 있다.
• "남에게대접 받고자 하는 대로 너희도 남에게 대접하라." 
  • 여러분의 코드를 참견하는 사람으로부터 방어하려고 해서는 안 된다. 
  • 다른 사람의 코드를 존중해야 한다.
• 우리는 소유권에 대한 긍지를 보고 싶다. 
  • 여러분의 서명이 품질의 보증 수표로 인식되게 해야한다.

 

 

---

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

• 아무래도 팀이나 프로젝트 같은 큰 단위로 가다보니 한국과 미국의 전반적인 문화 차이를 안 느낄 수가 없다.
• 한국 회사에선 업계를 막론하고 품질 관리 담당자가 대부분 따로 있는 것 같다. 정말 웃기는 일이라고는 나는 한국처럼 책임 전가가 꽤 많이 일어나는 내부 구조에서는 그렇게라도 누군가를 내세워야 하는 경우가 많다는 의미로 해석한다. 빨리빨리 문화가 회사에서도 심심치 않게 나타나기 때문에 상품 출시를 위해 총대를 메는 누군가의 역할인 것이다. 특히 다채로운 고객을 상대하는 사업이라면 방향성도 다양하기 때문에 필요하다고 생각되는 것 같긴하다. 아물론 그렇게 해야만 굴러간다는게 애초에 이상적인 비즈니스가 아닐지도.
• 예전에 팀 내에 주니어들끼리 스크럼을 해보라는 요구를 받은 적이 있다. 왜 굳이 주니어들 끼리만 하라는지도 몰랐지만 더 큰 문제는 대부분의 구성원이 신규 입사자였으며 접점이 크지 않은 업무를 하고 있던 터라 당황스러웠다. 그러다보니 시간 되는 분들끼리 커피타임이나 하는 시간으로 썼던 것 같다. 물론 한달도 채 가지 못하고 흐지부지 되었지만. 스크럼이든 뭐든 물론 잘 정착되면 이점을 많이 갖다줄 방법론이지만, 수직적이고 품질보단 일정 준수를 더 중시하는 한국 문화에서 정말 잘 운영되고 있는 조직이 얼마나 될지는 글쎄. 
  • 지금 생각하니 아마 스크럼이 유행이고 좋다는 사람이 많으니 한번 해보라는게 아니었을까 싶다.
• 우리는 소프트웨어 개발 리더들이 직원들에게 “우리는 넷플릭스―혹은 다른 앞선 회사 중 하나―처럼 일해야 합니다.”라고 말한다는 이야기를 많이 듣는다. 물론 그렇게 할 수 있다.
    먼저, 서버 수십만 대와 사용자 수억 명을 준비한다…….
  • ㅋㅋㅋㅋ아 너무 공감간다. 그리고 자리수가 많은 연봉계약서 :)
• 긍지있는 코드라니. 거창하지만 멋있는 말이다. 잘짜여진 라이브러리를 많이 오픈해두는 사람 닉네임이 눈에 익는 것 처럼 코드로써 다른 사람들에게 익숙해 질 수 있다니. 가벼운 시도들로 까마득한 결과를 만들어 낸 것이겠지. 가끔 그런 사람들을 보면 어쩌면 난 취미 수준으로 개발을 하는게 아닌가 싶다. 그정도의 열정까진 없는 것 같아.

 

- 나같은 범인도 어딘가에 실용되길 바라며

 

---

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

• 실용주의 팀은 작다는 것에 동의하지만, 구성원이 추가되거나 빠지는 일이 드물어야 한다는건 좀 어려운 조건이라 생각한다. 좋은 오퍼가 들어오면 언제나 옮길 준비를 하는게 개발자들 아닌가. 또한 협력은 잘 할수 있지만 서로를 잘 알만큼 친분이 있어야하는 걸까. 의존 또한 받아본 입장으로써 좋기만 한 경험은 아니었는데 말이지.