개요
이 글은 인프콘 2022 에서 박미정님이 발표하신 내용입니다. 박미정님은 이전에 백기선님 유투브에도 나오고 퍼블리에서도 글을 연재하셔서 알고 있었습니다. 또한 OKKY에서 하는 세미나도 들었습니다. 세미나에서 그때 개발자가 회의를 하는 것을 시간낭비라고 생각하지 않았으면 좋겠다고 말했던 내용이 인상깊었습니다. 이번 발표도 그때의 발언과 일맥 상통했습니다. 개발자는 단순히 개발만 하는 직업이 아니라 개발의 시작과 끝까지 모든 것을 동료들과 함께 힘을 합쳐서 만들어나가며 고민해야 합니다.
나와 팀을 성장시키는 리뷰들
개발자의 일과 리뷰는 무엇일까? 개발자들은 일을 오해하고 있다.
개발자는 단순히 코드를 짜는 것이 아니라 요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 배포 크게 5가지를 하고 있다.
요구사항 분석
문제를 명확하게 정의하는 것이 중요하다.
그렇지 않다면, 디자이너, 기획자, 개발자가 각각 다른 결과물을 상상하는 문제가 발생한다.
- 사례
쿠폰 기능을 외부에서 시스템을 들여와서 사용중인데, 마케터가 하나의 쿠폰을 여러명에게 뿌리 수 있는 기능 요구하였다.
이미 외부 시스템에서 사용 가능한 기능이 있었다. 마케터는 기존에 존재했던 기능을 몰라서 요구했던 것이었으므로, 기능이 있음을 알려줘서 추가적인 개발을 하지 않고 해결하였다!
설계
설계리뷰를 하지 않는다면, 영향도를 놓치거나, 또한 너무 견고하게 만들려고 하다보니 정말 필요한 일을 기간 내에 못하는 경우가 많다.
- 뱅크 샐러드 사례
뱅크샐러드의 경우에는 테크 스펙 템플릿으로 상세하게 기술한다. 목표와 목표가 아닌것을 구분해서 적고 팀원들에게 승인을 받는다.
- 실제 설계 사례
기존 모놀리식 서비스에서 메뉴 서비스를 분리하기로 결정하여 특정 개발자가 설계를 했다. 하지만 MSA, CQRS, Event-sourcing 등 엄청나게 수많은 방법론들을 가지고 왔다. 그런데 이건 주어진 인적, 시간적 자원들을 고려하지 않았다. 결국 메세징 큐 하나만 통과되어 적용하였다.
구현
- 어떤 종류가 좋은 코드리뷰인가?
-요구사항이 온전히 반영되었는가, 확장성을 고려했는가, 다른 도메인에 미치는 부작용 고민, 기술 공유와 팀 내 개발 규칙과 문화를 제안하였다.
- 코드리뷰시 고려 할 것
코드리뷰를 할 때도 왜 이 코드를 승인했는지 이유를 남기는 것도 중요하다.
- 코드리뷰의 중요성 알리기
코드 리뷰 집중시간을 강제하였다(오전 1시간 반)!, 작성자는 요구사항/이슈를 충분히 설명해야 한다. 문제가 발생하면 코드리뷰에서 예방 할 수 있었는지 회고를 하고 그렇다면 모든 직원들에게 공유해서 코드리뷰의 중요성을 알린다.
<구글 엔지니어는 이렇게 일한다> 라는 책에서 코드리뷰에 관한 설명이 약 20페이지정도 나오는데 이 부분으로 사내에서 토론하는 시간을 가져도 좋다.
테스트
테스트 작성을 해서 통과하는게 끝이 아니라 테스트 자체도 리뷰해야 한다. 테스트를 잘못 만들었을 수 있기 때문이다.
테스트 코드 리뷰 및 테스트 시나리오도 리뷰해야 한다.
배포
배포 전 언제 배포인지 어떤 기능인지, 배포 후 기능이 의도한대로 잘 쓰이는지, 성능 문제가 없는지 모니터링하고 리뷰한다.
장애 발생 시, 리뷰
장애 상황이 닥쳤을 때, 장애를 탐지하고 빠르게 공지하고 영향이 있을 것 같은 내, 외부에 연락을 한다. 또한 후속조치를 해야한다. 근본적인 원인을 찾는 과정에서 '누가'를 신경쓰지 않고 재발 방지 대책을 수립한다.
(박미정님은 코드 리뷰 단계에서 장애를 발견할 수 있지 않았을까 계속 고민하신다. 코드 리뷰를 정말 소중한 시간으로 생각하신다. 집단지성이랄까)
성장
박미정님의 꿈은 여전히 계속 개발을 잘 하는 것보다 "함께 일하고 싶은 사람"이 되는 것이다.
각 단계의 리뷰는 서로의 빈틈을 메워주기 때문에 결국 개개인의 능력이 향상된다.
소감
박미정님의 철학을 축구에 비교해보겠습니다.
"팀보다 위대한 선수는 없다"
아무리 패스, 달리기 , 슛이 좋더라도 혼자만 해결 할 수 있는 문제가 아닙니다. 주변의 동료를 신뢰하지 않으면, 팀이 하나가 되지 못하고 좋은 결과를 낼 수가 없습니다. 단순히 나만 잘하고, 나만 문제가 없다면 끝이 아니라, 주변의 동료들을 도와주고 함께 고민하여 팀이 성장하는 것이 곧 나의 성장입니다.
퍼거슨 감독 아래에서 박지성이 최고의 클럽 맨유에서 오랫동안 뛸 수 있었던 것은, 몸싸움이, 패스가, 슛이 너무 뛰어났기 때문이 아니라, 감독의 원하는 전술을 정확히 흡수해서 다른 동료들에게 멋진 링커의 역할을 했기 때문입니다. 박지성 덕분에 루니, 호날두, 테베즈 등의 선수들은 정말 맘놓고 상대 수비영역을 휘저을 수 있었습니다.
이처럼 개발실력이 뛰어날수록 좋지만, 현재 꾸준히 다른 팀원들과 의견을 교류하여 궁극적으로 좋은 소프트웨어를 제공하는 가치에 도움을 주는 것이 너무나도 중요합니다.
축구는 아무리 화려함과 멋진 기술이 있어도 결국 골을 넣어야 이기는 것처럼, 개발도 아무리 좋은 기술을 사용한다고 해도 결국에는 안정적이고 유연한, 좋은 서비스를 제공하는 것이 목표임을 다시한번 상기합니다.
박미정님의 발표가 유독 듣기 편했던 이유는 아마 많은 개발조직들이 그동안 알게 모르게 실천하고 있었기 때문일 것입니다. 또한 머리는 이미 아는듯이 끄덕거리지만, 실제 실천을 못하고 있는 조직도 많을 것입니다. 여전히 개발자들에게 코드리뷰시간과 회의 시간은 개발 시간을 빼앗는 사탄 취급을 받고 있습니다.(?)
하지만 개발이라는 것이 단순히 덧셈, 뺄셈에 간단한 문제가 아닌, 요구사항, 설계부터 테스트 배포까지 이어지는 커다란 과정이기 때문에, 그 과정에서 피드백이 있어야 더 견고한 소프트웨어를 완성 할 것입니다.
* 출처
'회고 > 영상, 칼럼, 스터디 회고' 카테고리의 다른 글
| 나도 내 코드의 문제를 찾고 싶다구요?! - 테스트 할 때 기억할 7가지, 한주승 (0) | 2022.10.07 |
|---|---|
| 성공하는 스터디를 만드는 10가지 방법 - 인출 위주의 스터디 여정기, 한윤석 (0) | 2022.10.01 |
| 실용주의 프로그래머 실천사항 (0) | 2022.06.02 |
| 실용주의 프로그래머 (4/27) (0) | 2022.04.27 |
| 실용주의 프로그래머 (4/13) (0) | 2022.04.20 |
