2022년 5월 개발일지
5월은 새로운 프로젝트를 진행하면서 작업 방법의 변화와 여러가지 새로운 시도도 하게 되었고 개발적인 이슈 외에도 구성원간의 커뮤니케이션 이슈도 있었기에 참 다사다난했던 월이었던것 같다. 하나하나 살펴보자
Schema first
백엔드 서버의 코드는 공통적인 설정이나 이슈 대응 외에 새로운 기능에 대한 개발은 하지 않고 코드리뷰에 집중을 하였다. 기능에 대한 설계 시 백엔드 개발자가 다같이 모여서 구현방향을 논의하고 결정하였기 때문에 코드리뷰에 많은 도움이 되었던 것 같다. 다만 지금와서 아쉬운 부분은 설계 시 Graphql Schema 부터 하지 않고 Entity 설계부터 하였다는 것이다. (그땐 왜 그것부터 하였는지 잘 이해가 가지 않지만…) 그로인해서 개발서버에 Schema가 조금 늦게 배포되면서 프론트앤드 개발자 분들이 개발할때 조금 불편함을 겪었다. 다음 작업부터는 Schema 부터 정의하도록 개선해보아야 겠다. 우리가 DGS Framework를 왜 선택했는지 다시한번 상기해봐야 겠다.
Task 관리
정비기간을 가지기 이전까지는 프로젝트 진행 시 PM분들이 에픽과 유저스토리를 관리하고 개발자들이 작업을 관리하는 형태로 진행했었다. 그래서 스토리 단위로 기능 개발에 필요한 작업들을 생성하여 연결을 했었고 스프린트가 진행되는 동안 추가 작업이 필요하면 생성하는 방법으로 진행되었었는데 이상에 가까운 방법이었지만 Jira의 태스크를 관리해 주는 사람이 없다면 운영하기가 조금 어렵다는 단점과 추가작업이 유연하게 생길 수 있다는 점에서 스프린트 일정을 정확하게 측정하기가 어렵다는 단점이 있었다. 그래서 이번에는 에픽을 생성해두고 개발자들이 필요한 작업들을 미리 생성해두고 세부작업들은 서브태스크를 생성해서 진행하는 방법으로 시도해 보았다. 이렇게하면 추가 작업을 생성하지 않는다는 제약조건으로 인해 작업에 대한 일정을 그나마 결정한 후 스프린트를 진행할 수 있을 것이라는 기대감과 작업의 전반적인 관리를 각 작업자마다 가져가므로 별도의 작업관리자가 필요없다라는 장점을 누릴 수 있다는 것이었다.
하지만 스프린트를 진행하면서 이러한 방법도 결국 문제점을 드러내게 되었다. 첫번째로 작업자들이 전반적으로 필요한 작업들이 무엇인지 정확하게 예상하기는 힘들었고 그러다보니 작업을 생성할 수 없다는 제약조건을 우회하기 위해서 서브태스크를 억지로 맞춰서 생성하는 기형적인 형태로 운영되게 되었다. 결국 작업을 생성하지 않는다라는 제약조건이 의미가 없어진 것이다. 두번째로는 Jira의 특징 때문인데, 서브태스크들이 모두 완료될때까지 작업을 닫지 않기 때문에 하나의 작업에 대한 사이클타임이 긴 단점이 있었다. 그러다보니 주간회의마다 작업 리포트를 뽑아보면 작업 진척도가 올라가지 않아 현재 얼마나 작업이 진행중인지 쉽게 파악하기 힘들어서 조기 대응이 어렵다라는 문제점이 발견되었다.
아마 팀 회고 시 이부분을 언급할 것 같은데 현재로써는 서브태스크를 이용하지 않고 오로지 태스크만 생성해서 진행하는 방법이 그나마 최선일것이라 생각이 되지만 이것도 에픽 하위로 엄청나게 많은 작업들을 생성하게 될 것이라 좋은 방법인지는 잘 모르겠다. 이 방식대로라면 Jira에서 사용하는 에픽이 하나의 스프린트단위로 되게 될 것인데 이렇게 운영하는 것이 좋은 방법인지도 논의를 해봐야 될듯하다.
관리자
현재 우리팀에서는 백엔드 개발자가 개발자 중에 가장 많은 비율을 차지한다. 그러다보니 프로젝트 진행 시 프론트엔드 또는 앱 개발자 작업 일정에 비해 조금 여유로운 편이기도한 상황이다. 그리고 현재 내부인원을 위한 백오피스의 개발 책임을 프론트앤드가 가져가다 보니 항상 일손이 부족한 프론트앤드 개발자들이 백오피스에 대한 개발 공수를 투입할 여력이 되지 않는 상황이다. 그러다보니 간단한 수정사항이 있더라도 어드민으로 개발되지 않아 운영부서가 Altair와 같은 도구를 사용하여 원하는 작업을 수행하는 불편한 상황이 계속되고 있는 상태였다. 그래서 이번 프로젝트부터 새로운 기능에 대해 백오피스 기능을 백엔드에서 가져가기로 하였다. 개인적으로 지금까지 백오피스는 백엔드가 맡아오던 회사를 경험했다보니 어찌보면 백오피스는 당연히(?) 백엔드가 맡아야 한다라는 생각이 있었기 때문에 백엔드 챕터 분들의 동의도 얻었겠다 바로 진행하게 되었다.
무엇보다 고민했던 것은 UI(HTML, CSS, Javascript)개발에 익숙하지 않은 백엔드 개발자가 어떻게하면 손쉽게 개발할 수 있고 요구사항을 잘 충족시킬 수 있으며 유지보수가 쉬울까였다. (이쯤되면 욕심이 가득하다고 봐도 되겠다.) 그렇게 고민해서 나온 대안들이 아래의 것들이다.
- Spring Boot + thyeleaf
- Spring Boot + thyeleaf + vuejs
- React
Spring Boot + thyeleaf는 백엔드 개발자가 가장 손쉽게 다가갈 수 있고 익숙한 방법이다. 관련예제도 많으니 참고할 수 있는 레퍼런스도 많다. 하지만 액션마다 화면이 깜빡거리는 불편함이 있고(물론 관리자니까 큰 단점이 아닐 수 있다.) 요구사항이 복잡해질수록 화면구성이 어려워지는 단점이 있다. 그리고 한번 화면을 고칠때마다 서버를 재기동 하여야 하는(devtools를 사용하면 그나마 보완할 수 있지만 강력 새로고침을 연거푸 연타해야하는 불편함이 있다.) 불편함이 있기에 개발 경험이 썩 좋은 대안은 아니다.
Spring Boot + thyeleaf + vuejs는 첫번째 방법을 조금 보완한 방법으로 vuejs가 제공하는 양방향 바인딩의 편리함을 이용하여 보다 나은 사용자 경험을 제공해주고 복잡한 화면 구성을 쉽게 해줄 수 있다는 점에서 후보군에 오르게 되었다. 하지만 여전히 화면을 고칠때마다 서버를 재기동 하여야 한다는 불편함은 존재한다.
React는 백엔드 개발자 입장에서 러닝커브가 상당하다. 라이프사이클을 모두 이해하고 개발하기에는 힘들것이라는 생각이 들었다. 하지만 React Hook이 나오면서 그나마 상태관리에 대한 복잡함이 많이 줄었다고 생각되고 제공해주는 라이브러리와 레퍼런스가 상당하기 때문에 한번 익숙해지면 다른 대안들보다 화면개발에 대한 생산성 걱정은 하지 않아도 되리라 생각되었다. 그리고 무엇보다 프론트앤드 개발자의 도움을 받을 수 있다는 점도 좋았다.
여러 논의와 고민끝에 우리팀은 React를 이용한 백오피스 개발을 진행하기로 하였다. 디자인 프레임워크는 Ant Design을 사용하기로 하였다. 이유는 내가 이전에 이 프레임워크를 사용해보았을 때 경험이 좋았었기 때문이었다.
초기 설정은 프론트앤드 개발자의 도움을 받아서 진행하였고 테스트 코드를 넣으려다가 포기하였다는 헤프닝만 제외하면 순조롭게 개발되고 있다. 나중에 백엔드 개발자가 만들어보는 리엑트를 이용한 관리자 앱이라는 주제로 글을 한번 써봐야겠다.
커뮤니케이션 이슈
제목이 좀 안어울리는 것 같지만 어찌되었든 팀 내 커뮤니케이션과 관련한 이슈이기 때문에 제목을 이렇게 적어보았다.
최근 제공해주는 API와 관련해서 프론트엔드 개발자와 의견차이가 있었다. 당시 나의 입장에서는 납득이 안되는 API를 만들어달라는 요청이 있었고 납득이 되지 않았기에 다른 방법을 제시해 주며 제시해준 방법으로 개발해보는 것이 어떻겠냐는 의견을 드렸었다. 다만 프론트앤드 개발자도 본인의 생각에 충분히 요청할만한 API였다고 생각을 하셨었고 이부분에 대한 의견이 좁혀지지 않은 상황에서 챕터장 및 팀장님 CTO님까지 모여서 의견을 조율하는 자리까지 마련되게 되었다.
결론적으로는 내가 제시한 방법으로 개발하는 것으로 결정이 되었지만 프론트엔드 개발자분께 내 의견을 납득시켜서 내려진 결정이라는 느낌을 받지는 못했기 때문에 조금 아쉬운 마음이 들긴하다. 내가 너무 고집을 부린건가 싶기도 하고 내가 설득력이 부족했다 싶기도 하다. 가뜩이나 이번 이슈로 인해 팀장님과 CTO님과 면담을 하게 되었고 다른 챕터장님들과의 소통이 필요하다라는 피드백을 주셨기에 좀 더 나의 의사소통에 대한 태도와 말투에 대해 되돌아 보게 되었다.
어찌되었든 프론트엔드 및 앱 개발자분들의 너그러운(?) 이해와 공감으로 이번 헤프닝은 잘 넘어가게 되었지만 프로젝트를 진행하면서 앞으로 이런일이 다시 발생하지 않으리라는 보장이 없기 때문에 다시한번 내 의사소통 방법을 돌아보고 고쳐야 하는 부분들을 의도적으로 고치려고 노력해봐야겠다.
Mockk vs Mockito
최근 서버의 테스트 코드 속도를 줄이기 위한 노력을 하면서 Mockk 라이브러리가 Mockito에 비해 느리다는 것을 알게 되었다.
이슈 : https://github.com/mockk/mockk/issues/13
속도와 관련한 이슈가 없었다면 참 좋아겠지만 몇초의 테스트 속도와 가독성 중에 선택하라고 한다면 나는 가독성을 선택하고 싶다.
jekyll nokogiri 이슈
최근 노트북을 M1 pro로 바꾸면서 지금의 블로그를 로컬에서 실행하기 위한 설정을 다시하게 되었다. bundle 명령어를 통해 설치를 시도해보았지만 nokogiri와 관련한 오류가 발생하면서 설치가 되지 않았고 아래와 같이 명령어를 실행해서 해당 이슈를 해결하였다.
gem uninstall nokogiri
bundle config set force_ruby_platform true
gem install nokogiri
Fake Graphql API server
스키마만 정의해주면 Fake 서버를 제공해주는 라이브러리가 있어서 적어본다. 스키마만 있으면 서버와 통신하는 것처럼 개발할 수 있으니 되니 프론트엔드나 앱개발자 입장에서 개발할때 도움이 많이 될 듯하다.
4년간의 Graphql 사용에서 얻은 교훈
- Solve a real problem.
- Think like the client.
- Have a first client.
- Incremental adoption.
- YAGNI (You Aren’t Gonna Need It).
- Avoid “second system syndrome.”
- Timing is critical; recognize inflection points.
- Encourage taking measured risks.
출처 : https://www.graphql.com/articles/4-years-of-graphql-lee-byron
React SearchPrams
React를 이용하여 목록 화면을 구현할 때 일반적인 구현으로는 목록의 검색결과에 대해 이력관리 및 페이지 공유가 쉽지 않다. 왜냐하면 URL로 페이지를 다시호출하거나 하지 않기 때문이다. 이러한 불편함을 해소해 주는것이 바로 React Router에서 제공해주는 SearchParams이다.