한빛미디어

(전체 사진이 포함된 원문: https://velog.io/@broccolism/미니멀리즘-프로그래머-소프트-스킬-향상을-위한-액션-아이템-정리해보기-웹-개발자-독서-후기)

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

현실에서 온 책

실제 개발 업무와 맞닿아 있는 생생한 이야기가 담겨있다. 챕터 2. 코드 다이어트 장에 나온 이 내용이 특히나 공감되었다. 대학교 3, 4학년 때 학생 창업팀에서 개발하던 시절이 떠올랐기 때문이다. 당시 이 책에서 말하는 ‘고객’은 바로 디자인팀과 기획팀이었다. 스타트업 특성상 방향성, 기능, 디자인의 변경이 아주 유연한 편이었기 때문이다. 문서로만 봤을 때는 드러나지 않던 여러 사항을 갑자기 깨닫고 원래의 요청과 크게 달라질 수 있는 아이디어와 제안을 갖고 다시 찾아오기 는 일상적인 일이었다. 비슷한 규모나 분위기의 팀에서 일하고 있다면 크게 공감이 될 것 같다. (오히려 그래서 더 재밌었던걸지도..!!)

지금 하고있는 업무에 바로 써먹을만한 것, 어렵겠지만 도전해볼 만한 것도 많이 찾았다. 그만큼 개발자로 일하면서 배울만한 유용한 소프트스킬이 많이 담겨있는 책이다. 몇 가지 액션 아이템을 아래에 적어놓았으니 이제 막 개발자가 되었거나 새로운 업무 스타일을 찾고 있다면 참고해도 좋을 것 같다.

코드 다이어트: 적을수록 좋다

프레임워크도 결국엔 코드다

책을 다 읽고 보니 챕터 2에 북마크를 제일 많이 달았다. 마치 애자일 선언의 일부처럼 심플함을 추구하는 이 책의 성격이 가장 잘 드러나는 챕터였다.

어느 정도로 심플함을 추구하냐면, 프레임워크도 신중하게 사용하라는 내용이 나온다. 프레임워크도 결국에는 코드이며, 특히나 계속 새로운 기능이 붙는 코드이기 때문에 너무 방대해질 수 있다는 것이다. 스프링을 쓰는 입장에서 꽤 공감이 가는 내용이었다. 당장 ‘스프링 프레임워크로 웹 서버 개발하기’ 같은걸 검색해보면 수많은 모듈이 나온다. 스프링 부트, 스프링 데이터, 스프링 세션, 스프링 시큐리티, 스프링 배치, 스프링 클라우드, … 사용하지도 않을 기능을 import 하는걸 막기 위해 잘 골라서 사용해야한다. 스프링이라는 이름이 붙었다고 해서 그냥 갖다 쓰면 곤란하다. 반대로, 저렇게 많은 기능이 필요 없는 작고 간단한 서버라면 다른 방식으로 구현하는 게 오히려 좋다는 게 이 책의 방향성이다. 이미 스프링을 사용하고 있더라도 프레임워크의 도움이 필요한 건지, 직접 코드를 적는 게 유지보수에 유리할지 판단하는 과정이 필요하다는 걸 느꼈다.

내 코드는 정말 '사용'되고 있었을까

결국에는 제품을 만들어야 한다. 우리는 코드를 짜는게 목적이 아니라 동작하는 소프트웨어를 만드는 게 목적이다. 챕터 2.3 기능은 적을수록 좋다 에서는 이런 구절도 나온다. 복잡함을 걷어내고 빨리 출시하는 게 목표라면 이렇게 하는 게 합당하다.

그런데, 단순함만이 답은 아니다

하지만 그저 빨리 출시하는 게 목표가 아니라면? 너무 심플함만 추구하다가는 예기치 못한 사고를 당할 수도 있다. 충분한 예외 처리가 되어있지 않아 데이터 정합성이 깨지거나, 갑자기 튀어 오르는 트래픽 앞에서 서버가 무너진다거나, … 상상력을 발휘하여 매일 사용되지 않는 코드를 작성해야 할 때도 있다.

이 책에 나오는 내용은 아직 MVP 제작 전이거나, 소규모 테스트를 먼저 돌려보는 팀에 적용하면 좋은 내용이었다. 일간 방문자 수가 100만이 넘거나, 피크 타임에 평상시의 3배가 넘는 트래픽을 받아야 하는 서버라면 이야기가 좀 달라진다.

회의 다이어트: 의사소통도 심플하게

회의가 많은 편이라면 아래 내용을 읽어보자. 너무나도 현실적인 상황에 절로 웃음이 나올 것이다.

책에서는 회의는 원래 애자일하지 않습니다 라고 한다. 생각해 보면 그렇다. 비동기적인 소통을 통해 해결할 수 있는 일이 있고, 아닌 일이 있다. 만약 깃헙 코멘트나 슬랙 메세지, 이메일 등 글을 통해 해결하는 게 더 효율적인 일이라면 굳이 회의를 잡을 필요가 없다.

반대로 회의를 잡았다면 예정 시간을 최대한 준수할 수 있도록 미리 안건을 준비해가고, 이 내용을 공유하여 모두가 같은 눈높이에서 출발할 수 있는 장치를 만들자. 미리 회의 안건을 적어놓는 스레드를 만들면 유용할 것이다. 우리 팀에서도 매주 화요일 회의 전까지 각자 이야기하고 싶은 내용을 달아놓고, 회의 시간 때 하나씩 함께 논의하는 시간을 갖는다. 예전에 제안한 방식인데 회의가 늦어지는 경우가 훨씬 줄어들었다. 안건을 미리 볼 수 있으니 가볍게 해결할 수 있는 일은 코멘트나 메신저로 해결하고, 회의 전에 필요한 히스토리를 파악하고 공유하여 회의 시간을 줄일 수 있었다.

직접 해볼만한 일들

이제 책에 나온 내용을 바탕으로 액션 아이템을 하나씩 정리해 보자.

나도 이미 하고 있는 일

TODO 강조 표시하기

책에 나온 내용 중, 작년부터 필요성을 느끼고 설정해 놓았던 게 있다. 바로 코드 에디터에서 TODO 라고 적힌 게 있으면 강조해 주는 기능이다. (IntelliJ를 쓰고 있다면 Settings > Editor > TODO 메뉴에 원하는 키워드를 추가해서 자동 하이라이팅을 설정할 수 있고, VSCode 사용 중이라면 별도 익스텐션을 설치해서 설정할 수 있다.)

나는 메인 브랜치에 달린 TODO와 이번 브랜치에서 당장 해결해야 할 작업을 구분하기 위해 @@ TODO: 라는 커스텀 패턴을 등록해서 쓰고 있다. 이렇게 하면 당장 해야 할 일과 언젠가 해도 되는 일이 한눈에 구분되고, PR 올리기 전에 전체 검색으로 내 작업을 모두 완료했는지 확인하는 데에도 편하다.

당장 실천해볼 일: 시간에 이름표를 붙이자

탐색 시간을 확보하라는 내용이 크게 와닿았다. 늘 내가 해야 할 일만 쳐내다보면 새로운 정보를 접할 기회가 현저히 줄어든다. 본업은 결국 개발이기에 최신 뉴스만 계속 찾아다닐수는 없는 노릇이다. 하지만 이런 생각 때문에 최신 기술 탐색뿐만 아니라 내가 몰랐던 부분에 대한 탐색은 뒷순위로 밀리는 경우가 많고, 내 개인 스케줄 관리 어플에는 항상 백로그라 쌓여있었다.

마침 3월 말이다. 다음 달부터는 정기적으로 탐색을 위한 시간을 따로 확보해 놓아야겠다. 특히 올해부터 매주 금~일 중 하루 30분 주간 업무 보고 작성, 매달 마지막 워킹데이에는 그달 업무 회고하기, 매달 마지막 주 토요일은 월간 가계부 결산 과 같은 규칙을 만들어서 실천하고 있었다. 이런 식으로 시간에 이름표를 붙여서 관리하면 보다 알차게 시간을 보낼 수 있고 할 일도 놓치지 않을 수 있다. 그 할 일 중에 탐색의 시간도 추가해 볼 예정이다.

해보고 싶지만 쉽지 않을 일: 개발자 셔플

다양한 도메인을 경험할 수 있고, 새로운 시각이 들어오면서 코드가 한 단계 진화할 수 있다는 장점이 매력적이다. 다만 팀 회식 때 옆 팀 사례를 들어보니 인수인계나 운영 안정성 면에서 꽤 많은 준비가 필요한 일 같았다. 언젠가 팀 내의 좀 더 복잡한 도메인도 한번 맡아보고 싶지만 아직까진 때가 아닌 것 같다. 대신 그쪽 도메인에서 올라오는 PR과 이슈를 구경하면서 파악하는 시간을 가져야겠다.

생각해볼 일

이것도 역시 앞에서 나왔던 ‘시간에 이름표 붙이기’와 비슷한 맥락으로, 의식적으로 생각이 필요한 일이다. 매일 하던 업무만 하기보다는 앞으로 어떤 방향으로 나아가야할 지 항상 고민하다보면 언젠가 좋은 기회가 찾아오지않을까 싶다.

결국에는 사람이 하는 일이다

일을 하면 할수록 들었던 생각이 마침 이 책에서도 등장했다. 결국 우리는 모두 공동의 목표를 갖고 프로그램을 만들기 위해 모인 팀이다. 팀 내에서 의견 차이가 있을 때 우리가 해야 하는건 스스로 옳다는걸 증명하거나 상대방의 잘못을 집어내는게 아니라, 의견 차이를 좁히고 일이 되게 하기 위해서 무엇을 어떻게 할지를 결정하는 일이다. 애자일 선언문의 4가지 핵심 가치 중 하나가 떠오르는 구절이다: 프로세스와 도구보다는 사람과의 상호작용.

챕터 6.17 공감 능력 기르기에서는 공감은 미리 받는 피드백입니다라는 소제목도 나온다. 미리 합의한 방식대로 코드를 짜서 PR을 올리는게 그렇지 않았을 때보다 훨씬 더 빠르게 리뷰되고 머지되었다. 혹은, 코드를 직접 보면서 논의하기 위해 미리 PR을 만드는 방식도 괜찮았다. 결론은 우리 모두가 이 코드에 대한 합의가 이루어지면 된다는 것이다.

조금 갸우뚱했던 표현: 포트폴리오 없는 개발자

책을 읽다보면 챕터 3에서 생소한 용어가 등장한다.

각주에도 딱히 설명이 없고 구글링해봐도 결과가 나오지 않아서 클로드에게 물어봤다. 원문인 Developer Without Portfolio 는 특정 담당 영역 없는 개발자 정도로 생각하면 될 것 같다.

기억에 남(기고 싶)은 내용

• 프레임워크도 결국 기능이자 코드다. 기능과 코드는 적을수록 좋다.
• 자동화의 장점: 기억해야 할 것을 줄여주고, 필수 스텝을 빼먹지 않게 도와준다.
• 우선순위에 밀리는 일을 하기 위해 시간에 이름표를 붙여주자.
• 경력 개발에 도움이 되는 기술 분야, 개인적으로 흥미롭게 보이는 분야는 무엇일까? 탐색해보자.
• 공감은 미리 받는 피드백이다.

추천 대상

• 빠르게 MVP를 제작할 일이 많은 1인 개발자
• 스타트업에 근무하면서 업무 팁을 얻고 싶은 개발자
• 직장 생활 전반적인 소프트스킬을 향상시키고 싶은 개발자

✅ 액션 아이템 정리

지금까지 나온 액션 아이템을 정리해보았다. 각자 하고 있는 일은 무엇인지, 당장 실천해 볼 일과 언젠가 해볼만한 일은 무엇인지 분류 해보자. 그리고 책에 훨씬 많은 액션 아이템이 담겨있으니 소프트스킬 지침서가 필요하다면 꼭 읽어보자!

이미 하고 있는 일

• 에디터에서 TODO 키워드 강조 설정
  • PR 올리기 전 @@ TODO: 전체 검색으로 작업 완료 확인
• 시간에 이름표 붙이기
  • 매주 금~일 중 하루 30분 주간 업무 보고 작성
  • 매달 마지막 워킹데이 월간 회고
  • 매달 마지막 주 토요일 월간 가계부 결산
• 회의 전 안건 스레드 미리 작성
  • 회의를 잡기 전에 글(코멘트, 메신저, 이메일)로 해결 가능한 일인지 먼저 판단하기
• PR을 올리기 전에 리뷰어와 방향을 미리 합의하기

당장 실천해 볼 일

• 탐색을 위한 시간 확보하기
  • 언제 할 지, 이름표를 붙여주기
  • 경력 개발에 도움이 되는 기술 분야 탐색해 보기
  • 업무 맥락을 벗어나 개인적으로 흥미로운 기술 분야 찾아보기
• 새 의존성이나 프레임워크 모듈을 추가할 때, 정말 필요한지 한 번 더 따져보기
• 반복적으로 수동으로 하고 있는 작업이 있다면 자동화 검토하기

해보고 싶지만 당장은 아닌 일

• 팀 내 다른 도메인 맡아보기 (개발자 셔플) → 관심을 갖고 지켜보기.

#한빛미디어 #나는리뷰어다 #미니멀리즘프로그래머