서론
오늘도 어김없이 근 2주간 프로젝트 진척도에 대한 근황보고를 한다.
지난주에 6개월의 일정추산을 진행한 결과 어드민을 제외한 사용자 기능만큼은 전부 구현하겠다! 라는 목표를 세웠다.
이번 2주간은 기존 프로젝트 QA일정, 새로운 참여인원 등의 이슈가 있었기 때문에 기능 구현이 많이 이뤄지지 않았다.
이번 주는 기존 KOIN의 QA 진행과정과 온보딩을 주로 이야기할 예정이다.
KOIN 사장님 기능
KOIN에는 상점 정보를 보여주는 기능이 있다.
지금은 해당 상점정보를 사장님들께 직접 연락을 받아 동아리에서 자체적으로 업데이트 해주는 방식으로 운영하고있다.
그러다보니 상점 메뉴, 가격, 기타 정보가 변경되었을 때 이에 대한 정합성이 맞지 않는 경우가 빈번하게 생기곤 한다.
가게 사장님들은 이런 상황이 있을때마다 동아리 회장에게 문자/전화로 변경사항을 알려줘야한다.
사장님이 직접 가게정보를 수정할 수 있도록 기능을 열어두고자하는 기능이 바로 KOIN 사장님 기능이다.
Why?
마이그레이션을 진행하는 과정에서 병렬적으로 신기능이 배포되는 상황에 이것을 처리하는 과정 또한 마이그레이션의 일부라고 생각하기 때문에 기존 KOIN 개발 이야기를 같이 남겨본다.
사장님 기능은 2020년부터부터 기획하고 개발하던 기능으로 중간에 담당자 변경, 누락된 인수인계, 트랙별 소통 오류 등의 이유로 다양한 문제가 존재했다.
대표적으로 API 하위호환이 안되는 문제, 기능이 잘 동작하는지 테스트가 정확히 안되는 문제 등이 있다.
오랜 기간동안 개발되던 기능인데다가 production에 머지되지 않은지 오래된 상황이라 확실하게 뿌리를 뽑을 필요가 있었다.
QA(Quality Assurance)
QA란?
QA는 품질보증이란 뜻을 가지고 있으며, 제품 기능을 검증하고 개발 프로세스 점검 및 이슈, 사용자입장에서 동작 점검 등의 목적을 가지고있는 행위입니다.
참여 가능한 인원이 가장 많은 날을 잡고 QA를 진행하기로 했다.
직장다니느라 고생하는데 QA 진행까지 주도해준 고마운 PL ✨
QA 진행에 앞서 QA 체크리스트를 만들어봤다.
막상 만들고 나니 해당 QA를 진행할 여력이 안났다.
그리고 API별이 아닌 시나리오별로 체크리스트를 만드는게 맞다는 생각이 들었다. 백엔드 개발자 중심의 QA 시트를 작성할게아니라 인수테스트를 별도로 만들어서 수행하는 것이 더 올바른 방향이라는 생각이 들었다.
하지만 레거시코드에 테스트를 전부 쌓기에는 버전 호환성, 규모가 있다보니 마이그레이션 과정에서 작성중인 인수테스트로 이를 해소하고있다는 소소한 변명이다.
QA 진행
13명의 인원이 모여서 2시간 30분동안 개발환경에 배포된 서비스를 테스트했다.
시나리오 기반 QA 시트가 사장님 회원가입부터 상점생성, 메뉴생성 등 서비스의 전체적인 플로우를 경험하고 문제가 되는 부분은 슬랙으로 공유하는 방식으로 진행했다.
참여해준 동아리인원들 정말 ㅅ..ㅅ..성공하실겁니다
시간내주셔서 정말 감사합니다 🙇♂️
정해진 시나리오를 명확하게 정의하지 못했던 부분은 다소 아쉬웠지만 대략적인 QA만으로도 꽤 많은 문제점을 발견할 수 있었다.
서비스 출시 전에는 주기적으로 트랙 상관없이 모여서 사용자입장으로 QA를 진행해봐야겠다는 생각이 들었다.
우당탕탕 QA 결과 꽤나 많은 문제점을 발견할 수 있었고 해결해야하는 task가 명확해졌다.
정리, 진행왕 ✨✨✨
고민
이런 QA 진행은 누가해야하는가? 에 대한 의문이 들었다.
필요하다고 느낀 사람이 작성해야하는것이 맞다고 생각이 들지만 실제 회사에서는 어떤 역할 분배가 이뤄지는지 궁금해졌다.
얼핏 듣기로는 PM, PO, 기획자, QA 직군 등이 역할에 해당 업무가 포함되어있다고도 한다.
이러한 상황을 경험하면서 동아리에 PM과 같은 직군이 필요할 수도 있겠다는 생각이 들었지만 해당 인원을 어떻게 관리해야할지(어떤 업무를 할당해야할지)는 잘 모르겠어서 섣불리 동아리 내에 PM 직군을 만들기에는 논의가 필요해보인다.
개발자 겸 PM 혹은 디자이너 겸 PM을 둬야할까도 고민이다.
QA시트를 잘 만들어둔다면 이를 통한 신규인원 온보딩 또한 가능하지 않을까 생각도 해본다.
서비스 흐름을 알고 개발하느냐 그렇지 않느냐의 차이는 꽤나 크다고 생각하기 때문이다.
어쨋든 이렇게 우당탕탕 사장님 기능 QA가 마무리 지어졌고 백엔드에는 6개의 이슈가 할당되었다.
신규 인원 참여
코인 마이그레이션에 신규 인원이 참여하게되었다.
해당 인원은 스타트업에서 약 4년간 일한 경력이 있는 인원이였고, 혼자서 작업하는것에 익숙해진 나머지 협업 프로세스에 대해 배우고싶다는 니즈가 있었다.
나름 협업 환경을 잘 만들어가고있다는 자신감이 있었기 때문에 해당 인원에게 좋은 인사이트를 제공할 수 있을 것이라고 생각하여 다른 구성원들의 동의를 구하고 참여하기로 했다.
첫 합류날 인원 신규 인원 온보딩을 진행했다.
온보딩 과정에서 테스트 코드 작성, GitHub Wiki, discussion, Issue, 코드리뷰 등 협업을 위한 모든 프로세스가 낯선 탓에 섣불리 이러한 협업과정에 녹아들기 어려워하는 모습이 보였다.
최대한 간단한 작업을 할당해주면서 협업 플로우에 익숙해지도록 온보딩용 issue를 제공해줬다.
타입을 입력하면 버전 정보가 나오는 간단한 API이다.
최대한 권한이 안껴있는 이슈로 할당해줬다.
근데 이제 남은 온보딩용 이슈가 없다. 다음 인원이 오기 전에 빨리 인증 인가 플로우를 구현해둬야겠다는 생각이든다.
일해라 나 자신 🔥
온보딩에서 나온 컨벤션
온보딩 과정에서 하나의 제안이 나왔다.
코드 내부에 다음과 같이 Optional 처리가 중복되어 사용되고있었다.
// 예시코드
Entity entity = somthingRepository.findById(id)
.orElseThrow(() -> IllegalArgumentException("아이디가 존재하지 않습니다. id: " + id))
// ...이러한 중복 코드에 대해 메시지를 계속해서 신경써줘야하고, Optional 처리를 일일히 해줘야하는 번거로움이 신경쓰인다는 의견이었다.
꽤나 좋은 주제라고 생각해서 관련한 discussion을 올렸다.
discussion - Repisitory의 findByXXX() 중복사용에 대해
Java의 default method를 활용해 Optional 처리를 내부에서 하게끔 코드를 개선할 수 있었다.
추가로 해당 이슈를 해결하면서 예외를 묶어서 관리하는 방법도 생각해볼 수 있었다.
discussion - DataNotFoundException 선언
익숙함에 녹아들지말고 계속해서 개선점을 찾아내야겠다는 경각심을 일깨워주는 좋은 시간이였다.
BackLog
온보딩을 진행하면서 신규 인원의 입장에서 보이는 이건 왜 안하고있어요? 라는 부분이 굉장히 많았다.
대표적으로 다음과 같은 내용들이 있다.
- 인프라 개선
- DB 구조 개선
- KOIN_V2 배포 방법
- 프로젝트 구동방법 문서화
가장 크게 다가왔던 부분은 3번째 배포 방법에 대한 부분이였다.
짧은 배포주기로 테스트를 하면서 수행하면 좋겠다는 의견이 나왔다.
배포환경 구성에 대한 부분을 조금 우선순위를 높여볼 필요도 있어보인다.
가용할 수 있는 인력이 더 오기를 바라거나 그럴 수 없다면 잠을 줄여서라도 구성해야겠다는 생각이다..
Docker로 배포를 손쉽게하는 방법도 고려중인데 아직 학습이 덜된상태라 개인적으로 학습이 마무리되면 Docker 워크숍을 진행하며 구성원들의 이해도를 맞춰서 진행하려고 고민중이다.
이런 고민거리들을 조금 명확하게 쌓아두기 위해 백로그 이슈를 조금 쌓아둬야할 필요성도 느껴 일단 이슈로 만들어놨다.
후기
게시글 조회, 복덕방 조회 등 몇몇 조회 기능이 구현되긴 했으나 핵심기능이 많이 구현되지않아 진척도가 많이 아쉬운 주간이였다.
하지만 기존 서비스의 QA를 진행하면서 인수테스트의 중요성을 다시금 느끼기도 한 좋은 시간이였다.
또한 신규인원 온보딩을 통해 보다 탄탄한 컨벤션을 갖추고 진행할 수 있었고 배포와 같이 놓치고있던 작업에 대한 상기를 할 수 있기도 했다.
기존 서비스의 정상구동이 0순위기 때문에 마이그레이션에 시간을 많이 쏟지 못했던건 당연한 과정이라고 생각한다.
더 나은 협업, 지속가능한 프로젝트를 만들기 위해 계속해서 노력해보자
함께하는 팀원들에게 감사함을 느끼며 다음 주간도 화이팅이다 🔥
