요즘 우아한 개발 리뷰 :: 마이구미

이 글은 "요즘 우아한 개발" 이라는 책을 리뷰한다.
본인은 평범한 프론트엔드 개발자이다. 개인적인 생각과 해석이 들어가 있을 수 있다.
책 링크 - https://www.yes24.com/Product/Goods/122535338

 

 

누구나 제목과 표지를 보면 어떤 책인지 추측할 수 있다.

우아한형제들은 기술 블로그를 꾸준히 운영하고 있는 건 개발자라면 누구나 알고 있을 것이다.

이 책은 기술 블로그의 모음집으로 볼 수 있는 것 같다.

본인은 사실 기술 블로그가 잘 운영되고 있는 것은 알고 있으나, 거의 읽어본 적은 없다...

그래도 배울 점이 많다는 것은 이미 알고 있기에, 한번 책을 구매하게 되었다.

 

개발적인 내용뿐만 아니라, 우아한형제들의 전체적인 문화를 엿볼 수 있다.

네트워크, DB 등 본인에게는 흥미가 없거나 다소 어려운 내용도 있었지만, 그 속에서 유용한 정보도 많이 얻을 수 있었다.

정말 많은 내용들이 있지만, 개인적으로 좋았던 몇가지만 기록용으로 남겨두려고 한다.

 

---

 

피트스탑이란 1년에 한 번 2주간, 진행하고 있는 과제를 멈추고 팀 상황을 재정비하고 그동안의 기술 부채를 해결하는 우아한형제들만의 제도입니다.

 

이건 정말정말 부러운 것 중 하나이고, 개인적으로는 손가락에 꼽을 정도의 복지라고 생각한다.

1년에 2주면 엄청나게 짧은 기간으로 볼 수 있다.

하지만 2주간 집중할 수 있는 시간이 주어진다면, 엄청난 것들을 해낼 수 있다.

개인적으로 기술 부채를 해결하는 것을 즐기는 편이라 꾸준히 진행하고 있지만, 혼자서 처리할 수 있는 건들은 한정적이다.

그 외에는 공유를 매번 하더라도 우선순위, 환경 등등으로 인해 몇년째 방치되곤한다.

 

코드 리뷰 문화 개선 이야기

 

코드 리뷰 문화를 정착하는 것은 정말 힘들다.

정말 다양한 이슈가 있어서, 시스템으로 채워나가야한다.

개인적으로 시행착오를 겪으면서 현재는 나쁘지 않게 진행하고 있다고 생각하고 있는 상황으로 최근 업데이트는 거의 없었다.

하지만 이 책을 통해 더 개선할 수 있는 팁들을 얻게 되었다.

 

템플릿 사용하기

현재도 PR 작성시의 템플릿을 제공하고 있다.

크게 작업 분류, 작업 개요, 이슈 사항, 테스트 방법을 작성 구조로 잡고 있다.

책에서 소개된 팀의 템플릿은 다음과 같다.

• 해결하려는 문제가 무엇인가요?
• 어떻게 해결했나요?
• 첨부 파일

정말 단순하지만, 리뷰어 입장에서 PR 의 의도를 더 명확하게 파악할 수 있다고 느꼈다.

 

칸반 리뷰 최대치 초과 시 우선 리뷰하기

PR 이 쌓이는 건 자주 겪는 일이지만, 어쩔 수 없는 일이라고 생각하고 딱히 개선하려는 시도는 없었다.

PR 의 최대치를 정해두고 초과한다면, 현재 업무를 중지하고 리뷰를 하고자 하는 방식은 정말 좋은 방법인 것 같다.

 

자동화로 쌓이는 리뷰 줄이기

리뷰를 받기까지 몇주가 지나는 PR 들도 자주 접할 수 있다.

디데이를 정해두고, 디데이가 지나면 승인이 있어야만 머지할 수 있는 규칙을 과감하게 제거하는 방식은 리스크가 있을 수 있으나, 내부 구성원에게 조금더 리뷰를 신경쓰게 해주는 좋은 장치라고 생각한다.

 

왜 자꾸 같은 질문이 나올까? 내가 질문을 덜 받으려면 어떻게 할까?

 

업무를 하다보면, 같은 질문이 반복되는 경우가 많다.

본인은 왜 계속 물어보지? 그리고 그 사람을 의심하곤한다.

책에서 언급된 내용은 "문제의 초점을 질문하는 사람에서 질문받는 사람으로 돌린다." 이다.

우리는 정말 자주 말하는 것들이 있다.

"매번 말했던거다, 문서 찾아봐라, 문서 작성해라, 히스토리 남겨라..." 항상 같은 말을 반복한다.

이 초점은 질문하는 사람에게 문제가 있다는 것이 이미 깔려있는 상태이다.

사람이 문제라는 것으로 생각한다면, 다른 시도는 일어날 수 없다는 것을 개인적으로 놓치고 있었다.

이것이 반복되면, 현재 상황을 의심해봐야한다.

 

유효성 검증 시각화

 

관리자 사이트의 경우에는 폼 구조가 굉장히 복잡하다.

각 필드들의 유효성 검증의 알려주는 방식은 굉장히 다양하다.

여기서는 각 요소의 아이콘 리스트를 활용했는데 단순하면서도 좋은 기능으로 생각되어 남기게 되었다.

 

 

실제 사용자 본인인지 여부 검증 없이 우회 수단으로 현금 혹은 그에 준하는 가치로 전환 가능한 때에는 가상 재화도 다른 결제수단과 동일하게 별도 인증 절차를 거쳐야 합니다.

 

특정 서비스를 사용을 위해서는 해당 서비스에서 가입한 계정을 로그인을 해서 사용한다.

하지만 간혹 서비스의 포인트를 사용하는 경우에는 이미 로그인이 되어있더라도, 별도 인증을 요구하고 경우가 흔히 존재한다.

번거롭다고 생각했지만, 다음 내용을 보고 이해할 수 있었다.

만약 사용자 부주의로 부정 로그인을 당했다면, 이건 따지고 보면 서비스의 잘못이 아니라 사용자의 잘못이다.

하지만 서비스가 이것을 그냥 방치하면 서비스의 신뢰도를 하락시키고 고객의 이탈을 유발할 수 밖에 없다.

 

비즈니스 요구사항을 명확히 충족하는가?

 

요구사항에 맞게 개발하는 건 당연한 이야기이다.

하지만 종종 요구사항은 충족하지만, 애매한 상황들을 자주 접할 수 있다.

도메인, 요구사항보다는 다른 것들을 우선 순위를 더 크게 잡아 종종 혼란을 야기하곤 한다.

개인적으로는 코드가 다소 투박하더라도, 현재 요구사항과 도메인 흐름을 더 잘 표현하는 코드를 지향한다.

 

불확실한 형태로 모듈을 세분화하면 오히려 복잡성을 증가시킬 수 있다

 

위 내용과 비슷한 맥락이다.

개발자는 확장성, 재사용성을 먼저 고민하는 경우들이 많다.

이게 과하면 코드의 의도와 목적을 파악하기가 오히려 힘들어진다.

 

 

외부 라이브러리 선택 기준

 

외부 라이브러리를 사용하는 경우에는 왜 선택했는지에 대한 기준이 필요하다.

책에서는 제어권의 유무, 공식 지원 유무, 커스텀 지원, 안정성, 마지막 수정/커밋 을 기준으로 삼았다.

개인적으로는 마지막 수정/커밋 날짜를 공식 문서 유무, 이슈에 등록된 건들, 이슈에 등록된 건들을 잘 소통하는가? 를 중점으로 본다.

이 내용은 본인도 같은 생각을 가지고 있고, 모두가 인지하면 좋겠다 라는 생각으로 남겨보았다.

 

 

컴포넌트 분리 기준과 근거 더 테스트하기 좋은 코드

 

컴포넌트의 분리 기준은 사람마다 다르고, 정답은 없다 라고 생각한다.

그래서 개인적으로는 억지로 맞출 필요까지 없다고 생각하고 있다.

책에서는 테스트 코드의 시나리오들을 설명했고, 그것을 기반으로 테스트하기 좋은 코드가 분리 기준이라는 것에 어느정도 공감이 되었다.

테스트 코드를 실무에서 성공한 적이 없어서, 지금까지 이렇게 생각해온 것 같기도 하다...

 

 

동적 서비스 리소스와 정적 리소스 도메인 분리 구성

 

대부분 js, css 등과 같은 파일들은 별도 리소스 서버를 통해 가져온다.

이를 통해 서비스 리소스간의 의존성 감소, EC2 리소스 낭비 방지, 불필요한 로그 수집 방지의 이점이 존재한다.

 

현재 운영중인 서비스의 nginx 에 불필요한 로그들이 항상 쌓이고 있는 걸 인지하고 있었는데 크게 신경쓰지 않았다.

일부 폰트나 파비콘 등과 같은 파일들을 별도 정적 리소스 서버에 두지 않고 있었는데 리소스 낭비와 불필요한 로그 수집을 방치하고 있는 걸 다시 인지하게 되었다.