오늘의 TIL 3줄 요약

1. 회귀 테스트 구현과 전체 자동화를 목표로 나아가자.

2. 사용자가 원하는 바를 찾아 적극적으로 파고들자.

3. 발전을 위해 내 코드에 긍지를 가지자.

TIL (Today I Learned) 날짜

2022-05-31

오늘 읽은 범위

• 9장. 실용주의 프로젝트 (p.377 ~ p.406)

책갈피

• 작고 안정적인 팀을 유지하라. (p.379)

• 팀 전체가 깨진 창문을 용납하지 않아야 한다. (p.379)

• 몇몇 팀 방법론에는 ‘품질 관리 담당자’가 있어서 제품의 품질에 대한 책임을 팀에게서 위임받는다. 정말 웃기는 일이다. 품질은 팀원 모두가 제각기 기여할 때만 보장되기 때문이다. 품질은 애초에 제품에 포함된 것이지 나중에 덧붙이는 것이 아니다. (p.380)

• “시간이 나면 그때” 하겠다는 것은 “영원히 하지 않겠다”는 것이다. (p.381)

• 자동화는 모든 프로젝트 팀에게 필수 불가결한 요소다. 도구 제작 역량을 팀 내에 꼭 갖추어서 프로젝트 개발과 서비스 배포를 자동화하는 도구를 만들고 적용하라. (p.385)

• 유행하는 것이 아니라 실제로 잘 맞는 것을 사용하라. (p.388)

• 사용자에게 필요할 때 제공하라. (p.391)

• 특정 방법론에 과도하게 투자하면 다른 대안을 보지 못하게 될 수도 있다. 하나에 고착되면 머지않아 다른 길을 보기 어렵게 된다. 한 가지 방식이 너무 굳어져 버리면 더 이상 빠르게 적응할 수 없게 된다. 코코넛을 사용하고 있는지도 모른다. (p.391)

• 버전 관리 시스템으로 빌드, 테스트, 릴리스를 운용하라. (p.394)

• 일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라. (p.394)

• 훌륭한 프로젝트에는 제품 코드보다 테스트 코드가 더 많을 수도 있다. 테스트 코드를 만들기 위해 들이는 시간에는 그 노력만큼의 가치가 있다. 길게 보면 이쪽이 훨씬 더 싸게 먹히며, 결함이 거의 없는 제품을 만드는 꿈이 정말 이루어지기도 한다. (p.395)

• 버그를 심어 놓고 테스트를 테스트하라. (p.397)

• 코드 커버리지만 올리지 말고 상태 조합을 테스트하라. (p.399)

• 버그가 기존 테스트의 그물을 빠져나갔다면 다음번에는 그걸 잡아낼 수 있도록 새 테스트를 추가해야 한다. (p.399)

• 수작업 절차를 사용하지 말라. (p.400)

• ‘딱 이거 하나만……’ 이라는 생각으로 수작업 단계를 넣는다면 아주 커다란 창문을 깨트리는 것이다. (p.401)

• 개발자로서 우리의 목표는 사용자를 기쁘게 하는 것이다. 그래서 우리가 여기 있는 것이다. 사용자의 데이터를 캐내거나, 마케팅에 노출된 고객 수를 세거나, 사용자의 지갑을 탈탈 터는 것은 우리의 목표가 아니니 사악한 목표는 제쳐 두자. (p.402) ㅋㅋㅋ

• 사업의 여러 부분을 함께 엮어낼 방법을 개개의 부서에서는 알아차리기 힘들다. 우리는 조직의 여러 측면을 경험한 개발자가 이런 방법을 더 잘 찾아낼 수 있다고 굳게 믿는다. (p.403)

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

• 자신의 작품에 서명하라. (p.404)

• 사람들이 코드에 붙은 여러분의 이름을 보고 그것이 튼튼하고 잘 작성되었으며 제대로 테스트되었을 뿐 아니라 훌륭히 문서화되었을 것이라고 기대하도록 만들자. 전문가가 만든 진정으로 전문가다운 결과물. (p.405 ~ p.406)

오늘 읽은 소감

[Topic 49. 실용주의 팀]을 읽으며 일단 나부터 실용주의 프로그래머가 되어 팀을 이끌어야겠다는 생각이 들었다.

본문 중에 ‘“시간이 나면 그때” 하겠다는 것은 “영원히 하지 않겠다”는 것이다.’ 라는 구절에 많은 반성을 하게 됐다. 나 같은 경우는 이슈들이 있다면 백로그에는 채워두긴 하는데, 그 이상으로 매번 새로운 기능을 기획팀에서 가지고 와서 숨돌릴 틈이 없었다. 그 때문에 사실상 중요한 이슈가 아니라면 백로그에 그대로 박제가 되어버리는 경우가 대부분이었다.

이제는 리뉴얼 프로젝트도 진행하면서 유지보수의 중요성을 확실히 알았고, 깨진 창문은 그대로 놔두면 안 된다는 걸 책을 통해 이해했으니 이번 프로젝트가 끝나면 유지보수와 더 나은 환경에서 서비스를 제공하기 위해 포트폴리오 확장에 힘을 쏟을 예정이다.

백엔드 프레임워크로 express(Node.js), Spring(JAVA), Codeigniter(PHP), Laravel(PHP), Django(Python), RoR(Ruby) 부터해서 아예 그냥 서버리스로 Firebase Functions, AWS Lambda 도 사용해봤는데, 이 중에 나에게 있어 가장 잘 맞는건 RoR이다. 요구하는 스펙에 대한 기능을 제일 빠르게 구현할 수 있으며, 현재로서 이해도가 제일 높은게 RoR이기 때문이다. 사실 저 중에 활용해서 실제 서비스까지 런칭해 본 건 express, Codeigniter, RoR과 서버리스 두 개뿐이었고 나머지는 토이 프로젝트 수준(프로토타입 구현)에서만 만져본 것이라 ‘나에게 잘 맞는’ , ‘이해도가 제일 높은’ 을 운운하기엔 성급한 판단이라고 생각한다. 정정해서 ‘내 취향에 잘 맞는’ 이라고 하겠다.

현재 진행 중인 리뉴얼 프로젝트의 초기 논의 단계에서는 향후 개발 팀원 충원을 고려했을 때 개발자가 부족한 RoR보다는 Django로 개발하자는 의견이 있어 검토해봤지만, 결국엔 당장의 생산성과 RoR의 완만한 러닝 커브를 감안해 나에게 가장 익숙한 RoR로 결정했다.

[Topic 50. 코코넛만으로는 부족하다]에서는 이처럼 트렌드를 좇아가기보다 현재의 환경에 잘 맞는 것을 사용하라고 말해주고 있다. 동시에 이 책에서 제시하는 것들 또한 곧이곧대로 받아들이지 말고 직접 체험해보고 결정하되 그 정도가 지나치지는 않도록 주의를 주고있다. 이상적인 목표는 팀에게 가장 잘 맞는 기술이나 개발 방법론을 적용해 지속적 배포가 가능한 환경을 만드는 것이라고 할 수 있다. 중요한 건 ‘사용자가 필요로 할 때마다, 사업적으로 배포가 의미 있을 때마다 배포하는 것’.

‘버전 관리' , ‘회귀 테스트’ , ‘전체 자동화’ 는 프로젝트를 관리하는 데 있어 중요한 요소다. [Topic 51. 실용주의 시작 도구]에서는 이 세 요소를 실용주의를 시작하기위한 도구로서 정의하고 있다.

특히 책 전반에서 강조하는 게 테스트의 중요성인데, 마침 오늘도 리팩터링을 진행하면서 코드 리뷰(커밋 전 작성된 코드 검토) 단계에서 Validation을 더욱 견고하게 하겠다며 마지막으로 덧붙인 조건문에 ! 를 빼먹은 채… ‘테스트는 앞서 진행했고, 저것만 추가한 것이니 다시 할 필요는 없겠지’ 라며 커밋을 강행한 바람에 정상적인 조건을 가지고 들어와도 에러가 반환되었다… 한창 API 연동 작업을 하던 팀원에게 이 이슈를 전달 받고 나서 격한 부끄러움에 휩싸였다. 명백히 테스트의 부족으로 인해 발생한 이슈라 뭐라 할 말이 없어졌다.

• 단위 테스트

• 통합 테스트

• Validation, Verification 테스트

• 스트레스 테스트

• 테스트를 위한 테스트

• 속성 기반 테스트

“모든 테스트가 끝날 때까지는 코딩이 끝난 게 아니다.” 라는걸 명심하자.

자동화 또한 테스트와 더불어 나에게 많이 부족한 영역이다. 웹 프론트엔드 쪽 서비스들은 전부 Github Action을 통해 Linter 확인, 빌드, 배포가 자동화되어있지만(이제는 여기에 테스트 과정을 추가해야 한다), 굉장히 부끄럽게도 아직 백엔드 서비스는 버전관리와는 별개로 Capistrano를 활용해 수동으로 배포하고 있다… (정말 부끄러운 내용이지만 결국 작성해버렸다. 그래야지 더욱 열심히 할 것 같다)

배포의 자동화가 이루어져야지 비로소 템플릿 기반(백업된 데이터 활용) Auto-scaling에서 탈피해, 커밋된 내용을 각 엔드포인트에 즉각적으로 반영시킬 수 있기 때문에, 지속적 배포라는 목표에 도달하기 위해서는 반드시 자동화를 구성해야 한다. 그래서 이번 프로젝트 말미에 예정된, Docker 컨테이너를 기반으로 Github Action을 통해 테스트를 수행 후 각 인스턴스에 자동으로 배포하도록 세팅하는 게 가장 중요한 과제로서 남아있다.

다시금 명심하자. ‘버전 관리' , ‘회귀 테스트’ , ‘전체 자동화’ 가 이루어져야 비로소 프로젝트에 온전히 집중할 수 있는 환경이 만들어지는 것이다.

개발에 아무리 공을 들여도 결국엔 서비스가 잘 유지되기 위해서는 사용자의 니즈에 맞춰야 한다. [Topic 52. 사용자를 기쁘게 하라]를 통해서 프로젝트의 성공 척도가 어디에 있는지 확인할 수 있다.

사용자들은 쓰는 데 불편함(조악한 UI/UX, 퍼포먼스 이슈)만 없다면 소프트웨어의 퀄리티에는 크게 관심이 없다는 걸 많이 봐왔다. 시장 조사를 하면 딱 봐도 투박해 보이는 서비스인데 높은 DAU를 유지하고 있는 성공한 서비스들을 많이 볼 수 있다. 그들은 확실하게 유저가 원하는 것들을 제공해 주었기에 프로젝트를 성공적으로 유지할 수 있었다. 결국 중요한 건 사용자의 입장이다. p.403에서 사용자의 기대를 충족시키기 위해서 고민해야 할 방향에 관해 정리된 부분은 두고두고 꺼내 봐야겠다.

나는 내 코드에 자신이 없어 내 코드가 외부에 밝혀지는 걸 경계하는 편이다. 회사의 코드는 보안이 중요하니 논외지만, 개인적으로 관리하는 서비스나 코드들도 전부 Private Repository로 관리하고 밖에 꺼내놓지 않았다. 하지만 이런 ‘익명성’만을 가지고는 발전할 수 없다는걸 [Topic 53. 오만과 편견]을 읽으면서 깨달았다.

이런 성향을 지녔기에 적당주의나 실수, 태만을 여태까지 그대로 방치해온 것 같다. 나에게 필요한 건 내 코드에 대한 긍지(내가 작성했다고 오픈하는 것)이다. 내놔도 부끄럽지 않은 코드를 작성하기 위해 난 더욱 공부하고 포트폴리오를 확장하며 나쁜 코드들을 찾아 적극적으로 개선해 나아갈 것이다. 한 번 제대로 해보자.

중요한 내용들이 너무나도 많아 책갈피가 폭발했다. 9장이 전반적으로 지금 시점의 나에게 가장 필요하고 와닿는 내용들로 가득 차 있었다. 아니, 9장뿐만 아니라 책 전체가 두고두고 꺼내 봐야만 할 정도로 유익하고 좋은 글귀와 지침들로 가득했다.

‘실용주의 프로그래머’ 책을 읽은 것, 그 하나만으로 2022년의 5월을 잊지 못할 것 같다.

오늘 읽은 다른사람의 TIL

• Assignment 15 - 9장 TIL

• 읽지 못한 Assignment 14 - 연습문제 33. MISSION

참고 자료

• 익스트림 프로그래밍 (XP) - 위키

• 린 (Lean) - 위키