개발자
류준열

설계 리뷰

• 덜 구현된 채로 완료처리되는 일감들
• 불필요한 작업에 쏟는 시간
• 자신이 작업하지 않은 부분에 대한 이해도 부족

이를 개선해보고자 설계 리뷰라는 것을 만들었다.

커밋메시지 주도개발, 뱅크샐러드의 테크스펙을 참고했다.

1. 할 일과 하지 않아도 되는 일을 명확히 함으로써 에너지를 흩뿌리지 않는 것.
2. 서로 동일한 이해도를 갖는 것

요약

3줄 내외로 정리한다.

유저는 관리자 권한이 필요한 페이지에 접근 할 수 없다.
url 등 비정상적인 방법으로 권한이 없는 페이지에 접근 시 강제 리다이렉트 시킨다.

배경

이 기능을 왜 만드는지, 어떤 문제를 해결하려 하는지, 이전에 어떤 시도가 있었는지.

일반 사용자가 url을 통해 관리자 페이지에 접근하는 사례 발생
일반 사용자의 관리자 접근을 제한하여 시스템 문제 발생을 예방

목표

유저는 ~~ 할 수 있다. 의 형태로 작성한다.

유저는 A,B,C,D 페이지에서 테이블 우측 상단 버튼들과 체크박스를 볼 수 없다.
유저는 사이드바에서 A하위의 수정,실행 버튼과 관리자 버튼을 볼 수 없다.
관리자는 유저가 보지 못하는 모든 것들을 볼 수 있다. (사이드바 하위의 관리자 버튼, A페이지 상단의 실행, 추가 버튼)

목표가 아닌 것

프로젝트에 연관되어 있으나 목표와 관련 없는 것을 작성한다.
이것도 붙히자, 저것도 붙히자 등 리뷰어의 폭주를 막기 위함

서버 컴포넌트에서의 api call과 미들웨어 사용을 고려하지 않음

계획

상세히 묘사한다. 결정하지 못한 상태라면 고려하고 있는 것들을 다 목록화 해서 작성한다.

• AuthGuard.tsx에서 전역 state로 isSuperUser을 저장한다. (GET: /v1/user/me 의 response)
• A, B C, D, 관리자 페이지에서 isSuperUser에 따라 특정 UI 노출 여부를 결정한다.
• 일반 유저가 관리자 접근 권한이 필요한 페이지에 접근하면 AuthGuard.tsx 에서 뒤로가기 시킴

버그를 유발할 수 있는 부분

쿼리키를 통한 캐시관리 등 특히 조심해야 하는 사항들도 작성한다.

• 로그인/비로그인 상태와 관리자/일반유저 간의 쿼리키가 겹치지 않도록 주의

이외 고려 사항들

고려했었으나 하지 않기로 결정된 사항들을 작성하여 논의가 끝난 주제가 다시 이야기되지 않도록 함.

• 로그인 버튼 디자인은 디자이너 휴가 복귀 후 작업함
• 관리자 전환 스위치 기능 → 추후 논의

커밋 메시지

가장 중요한 부분이다.

내가 어떤 코드를 쓸 지 커밋 메시지를 미리 작성하고 이 범위를 벗어난 작업은 하지 않는다. 꼭 필요한 추가 작업이 발견되면 할 일 목록에 추가한다.

첫 회사 CTO님의 커밋메시지 주도개발을 따라했다.

• feat: PMA2-894 auth-guard.tsx에서 유저정보 조회 및 유저 정보를 갖고 있는 전역상태 추가
• feat: PMA2-894 관리자를 위한 UI는 일반 유저에게 보여주지 않음.
• feat: PMA2-894 일반 유저가 관리자 접근 권한이 필요한 페이지에 접근하면 강제 리다이렉트

작성자, 리뷰어 회고

• 작성자 회고
  • 역시나 예측이 부족했다. queryProvider를 만들어야 함을 예측하지 못해서 첫번째 커밋의 변경이 예상보다 컸다.
  • 커밋메시지 작성시 선행작업들을 놓치지 않도록 gpt를 이용해보자
• 리뷰어 회고
  • 쿼리키가 겹치는 상황때문에 잠재적 버그가 발생할 상황은 크게 없었던 것 같음.

아래 이미지는 기존 설계리뷰를 회사 업무와 무관한 내용으로 일부 수정한 내용이다.

기존에는 잘 모르는 작업을 할 때 작업과 학습을 동시에 진행했다. 이번에는 커밋메시지 주도개발을 위해 잘 모르는 부분을 미리 공부해야했고, 간단한 기술검증이 필요하기도 했다. 작업을 시작하기까지 오래걸렸지만 작업을 시작하고 나서는 계획에 벗어나는 일을 하지 않음으로 생각과 노력의 비용을 줄일 수 있었다. 그럼에도 실제 작업할때 오차가 생겼다.

한편, 작은 작업의 경우 불필요하단 생각이 들었다. 일을 위한 일이 아닌가? 하는 생각도 들었다. 설계 리뷰를 작성하는 기준을 정해야 할 것 같다.

동료들은 유저스토리를 작성하여 할 일을 명확히 하는 것이 좋았다고 했다.

하지만 자신이 작업하지 않은 부분에 대해서 동일한 이해도를 갖고자 하는 목표는 이루지 못했고 회고도 잘 이뤄지지 않았다. 이유는 너무 바빠서. 나의 회고는 계속 작성했지만, 모든 작업에 회고를 작성하는게 무의미한 문장들을 짜내는 것이 아닌가? 하는 의문을 스스로 떨치지 못해 동료의 회고를 요구하지 않았다.

좋다고 여겨지는 모든 일하는 방식이 모든 조직에 맞지는 않는다는 생각이 들었다. 좋다고 여겨지는 일하는 방식을 도입하려면 설득을 하는게 맞는걸까? 아니면 조직의 비즈니스 방식(혹은 팀의 가치관)과는 맞지 않음을 인정해야 하는걸까?

나는 후자라는 생각이 든다. 영업부에서 날짜를 정해오고 그 기한 내에 작업을 하는 환경에서는 일단 만들어주기로 한 걸 빨리 내보내주는게 비즈니스에 기여하는 것일테니까. 그리고 누군가의 고정관념을 깨기 위해서는 경험에서부터 나오는 강한 확신이 필요한데 나는 인터넷에 떠도는 좋다고 보이는 것들을 제안한 것 뿐이다. 그러다보니 설득할 근거가 없었다. 나도 그냥 '해봅시다' 였으니까. 모든 노력에는 시간이 들고 시간은 모두에게 공평하기 때문에 의미있게 사용해야 한다.

나는 첫 회사에서 날 성장시켜줬던 사람들처럼 나도 동료의 성장에 기여하고 싶다. 그래서 팀 전체의 성장을 위해 고민하는 것도 내 업무의 일부라고 생각한다.