서론

3월 18일 마지막 게시글 이후로 코인 마이그레이션에 대한 이야기를 안했다.
사실 어느정도 기반을 갖춘 뒤에는 대부분 CRUD 작업이 주된 작업이 되었고, 팀으로 나눠져 기능 개발 작업이 착수되어 진행한 작업은 저 시점과 많이 달라지지 않았다고 생각한다.

사실상 어드민 기능을 제외한 기능 마이그레이션은 4월중에 끝났다.
학업에 치여사느라 이에 대한 회고를 월간회고 중간에 살포시 껴놨는데 종강한 틈을 타 정리해두려고한다.

참고로 오늘의 주제는 마이그레이션 반쪽짜리 성공에 대한 회고다.
어떤 점을 중요하게 생각했는지와 내가 어떤 부분을 생각하지 못했는지, 마이그레이션을 진행하면서 어떤 것들을 배웠는지 등을 회고해본다.

여러분 마이그레이션은 성급하게 하지 마세요!!

마이그레이션의 목적

코인 마이그레이션 (1)을 돌아보며 마이그레이션의 목적을 되짚고 넘어가보려고한다.

• 기존의 기능이 안정적으로 돌아가는 것을 보장한다. (기본)
• 개발하기 쉬운 환경을 구성하여 구성원들의 프로젝트 흥미를 이끌어낸다.
• 복잡한 환경 설정을 단순화한다.
• 지속적으로 신입 부원이 들어오는 순환 구조에서 온보딩에 들어가는 비용을 절감한다.

부원이 빠르게 바뀌는 학교 동아리라는 조직의 특성상 선순환 구조를 원활하게 구성하고 싶었다.
이것이 목적이 되어 마이그레이션을 시작했었다.

아쉬운 점 🥲

개인적으로 이번에 진행한 마이그레이션에서 아쉬운 점이 자꾸 보인다. 내 경험과 판단이 너무 얕았다는 것을 많이 느꼈다.
이전에 발생하지 않던 버그도 많이 터지고, 왜 안돼?! 하는 클라이언트의 곡소리도 이전보다 훨씬 많아졌다.
무엇이 문제였을까?

엣지케이스를 등진자의 최후 ⛔️

올해 초에 트랙장을 달고 가장 먼저 마이그레이션을 주도하기 시작했다.

현재 교육중인 Beginner 인원들에 대해서 신경도 같이 써야했다.
신규 부원들이 Regular로 전환된 이후에 프로젝트 참여를 원활히 수행할 수 있는 환경을 만드려다보니 2달 이내로 협업체계를 갖춰놔야하는 상황이였다.

이 당시 다른 팀원들은 협업체제를 경험하지 않은 상황이였기 떄문에 초기 팀 문화를 내 경험에 빗대어 만들 수 밖에 없었고, 여기에는 빈틈이 많을 수 밖에 없었다.

최대한 간단하고, 처음봐도 이해하기 편하게! 가 당시의 모토였다. 그러다보니 함께 작업하는 부원들에게 테스트 작성에 대한 거부감을 주고싶지 않았고 이전 기능과 Response 만 동일하면 된다고 말했다.
그렇게 해피케이스만 테스트하는 분위기가 잡혔고 마이그레이션 내내 이어져왔다.

지금 돌아보면 초반에 팀 문화를 만들면서 최대한 테스트를 꼼꼼하게 작성하도록 유도했어야만했다.
해피케이스는 단순 명세 그 이상의 도움이되지 않는다는것을 깨달았다.

잠잠하던 에러 채널에 무수히 많은 에러가 팡팡팡팡... 터지기 시작했다.

특정 API에 대한 정책을 명세하고, 이 안에서 발생할 수 있는 엣지케이스에 대해서 테스트를 작성해야만했다.
이는 기획 레벨에서도 많은 신경을 써야겠다는 생각을 같이하게 되었다.

물론 모든 예외를 다 잡을수는 없겠지만 적어도 당연하게 잡을 수 있는 예외에 대해서도 놓치는 경우가 빈번하게 발생했다.

마이그레이션을 진행하면서 가장 중요하게 생각해야할 시스템의 안정성을 100% 챙기지 못했다는 부분이 많은 아쉬움으로 다가왔다.

경험을 추구하다가 고꾸라짐 🐶

동아리라는 특성을 살려 인프라를 담당하고있는 인원에게 많은 경험을 제공하려고 했다.
중간에 무중단 배포를 하기 위해 쉘 스크립트로 새로운 WAS를 띄운 후 Health Check를 한 뒤 포트를 갈아 끼워주는 Blue/Green 배포를 도입했었다. 그리고 Docker를 도입하는 등의 작업을 맡기고 진행시켰다.

여기서 멈췄어야했는데.. stay..!!!!

인프라 인원의 경험에 대한 욕망을 채워줘야겠다는 생각에 뭔가 브레이크없이 OK해주다보니 뭐가 막 흘러가서 Docker Swarm 까지 구성되어있었다.
이 상태로 Production 배포까지 이뤄졌고 나는 도커 스웜이 뭔지도 모르는 상태에서 트러블 슈팅을 해야했던 날도 있었다.

무중단 배포인줄 알았던 도커 스웜의 환경이 실제로는 30초 이상 중단되는 배포 방식으로 돌아가고 있다는 것도 뒤늦게 알아서 많이 아쉬운 상황이 연출되기도 했다.

트랙 리더의 역할을 잘 못한 느낌이였다. 뭐가 그리 급해서 저런 기술들을 다 수용했을까 아쉬운 생각이 든다.

물론 중간중간 주간공유 시간에 Docker Swarm이라는 기술에 대한 지식공유를 하긴 했지만 팀 내 모든 인원들의 이해를 사기에는 다소 어려움이 있었다.

도커도 안써본 사람이 태반이라서 공유 몇번으로 메꾸기에는 너무 어려운면이 있었다고 생각한다.

게다가 이전에는 1분 내외로 앱을 빌드/배포 할 수 있었는데 지금은 앱을 빌드하고 배포하는데 6분 27초나 걸린다.
롤백을 하고싶었으나 속도를 잘 개선해보겠다는 인프라 담당 친구의 경험을 더 줘보기로했다.

원래 이런 말을 별로 안좋아하는데 그래도 학습을 위한 동아리니까...

간단하게라도 Docker를 알려주는 온보딩 혹은 교육과정을 추가해야겠다는 계획도 머릿속에 추가되었다.

지난번에 들었던 Docker 강의를 부원들에게 알려주면서 메타인지할 수 있는 기회라고 생각하는데 생각보다 쉽지않은것 같다.

JPA란 무엇일까...🥲

마이그레이션에 참여하는 인원들이 JPA에 대한 이해도가 많이 부족했고, 이 과정에서의 부원들의 야매 학습(?)이 많이 일어났던 것 같다.

나름 온보딩으로 메울 수 있을 거라고 생각했는데 ORM을 익히기에는 너무 짧은 시간이였던것 같다.

엔티티를 구성하고, 연관관계를 구성하는 과정에서 에러도 꽤 많이 터졌던 기억이 난다..ㅎㅎ

지금은 Beginner 정규 과정에 포함되어 이에 대한 온보딩 비용을 절감할 수 있을것이라고 기대하고있다.

휴먼 에러 😅

API 명세를 사람이 눈으로 보고 이를 기반으로 DTO를 만들고 구현하는 방식으로 컨트롤러가 구현되었다.
레거시 코드와 Swagger 명세를 보면서 작업을 했는데 휴먼 에러가 날 수 밖에 없었다.

Swagger 명세는 정확하지 않았고, 레거시 코드를 보고 치다가 오타가 날 수도 있었다. 실제로 Swagger 명세와 실제 코드가 달라서 문제가 생긴적도 있었다.

이전에 우테코에서 발표했던 OpenAPI 명세를 활용해봤으면 어땠을까 싶기도하다.

IntelliJ에는 선택한 프로젝트 내에 있는 API EndPoint를 확인할 수 있는 기능이 있다.
이 명세를 통해 Swagger 문서 및 Codegenerator를 활용해 엔드포인트에 대한 명세는 빠르고 정확하게 구현할 수 있겠다는 생각이 들었다.

이걸로 나중에 코틀린으로 마이그레이션을 시도해볼까

좋았던 점 👍

그래도 협업체제를 갖추고 모두가 코드에 적극적으로 참여할 수 있고, 프로젝트를 주도적으로 다룰 수 있는 환경을 만드는데 성공했다고 본다.

프로젝트 입문 허들을 낮췄다!

docker를 도입하고 각종 설정이 단순화되면서 🛠️ 프로젝트 구동을 위한 설정을 문서 하나로 프로젝트 로컬 설정 설명을 대체할 수 있게 되었다. 이 문서를 작성해둔 덕분에 온보딩이 많이 수월했었던 경험도 있었다.

Regular 인원들이 테스트를 접할 수 있는 환경을 만들어 둔것도 나름 좋은 환경이라고 생각한다.

프로젝트가 활발해졌다!

프로젝트 코드 참여도가 매우 활발해졌다.
물론 이 부분은 동아리 구조 개편도 한몫 했다고 생각하지만 프로젝트 코드를 누구나 쉽게 구성하고, 기능을 추가하고, 고칠 수 있는 구조로 구성했다.

이 덕분에 문제 상황에 빠르게 대응할 수 있고, 새로운 기능을 빠르게 도입하고 시도할 수 있게 되었다.

교육의 허들도 낮췄다!

Beginner 교육과정에서 Spring 실습을 제공하기 다소 난감한 감이 있었는데 SpringBoot로 프로젝트가 변경되면서 교육도 SpringBoot로 변경했다.

이 과정에서 실습 환경을 제공하기 매우 수월해져서 교육생들의 실습 환경이 좋아졌다는 수강평을 많이 받고있다.
교육설문을 통해 Beginner의 교육 만족도도 이전보다 많이 좋아진 것을 확인할 수 있었다. (비기너 과정을 재수강하는 모 교육생의 의견으로는 메타인지가 정말 잘되는 과정이라는 평도 있었다 👍)

What if?

실시간 사용자가 대박많은 서비스에서 마이그레이션을 해야한다면?
회사라는 상황이라면 조금은 다른 방식을 고수할 것 같다.

핵심 로직에 대한 단위테스트를 먼저 작성할 것 같다.
그리고 도메인별로 정책을 정확하게 명세해 둘 것 같다.

API 엔드포인트도 OpenAPI 명세를 활용해볼 것 같다.

유저에게 발생할 수 있는 악영향도 최소화하기 위한 장치도 꼼꼼하게 마련할 것 같다. 스트랭글러 패턴을 도입하되 배포는 카나리배포를 선택할 것 같다. 행여나 발생할 수 있는 에러 영향을 최소한으로 미치기 위함이다.

그 외 나머지 문화적인 측면의 개선이 필요한 부분은 이번 마이그레이션 경험을 기반으로 구축해볼 것 같다.

후기

만약 지금 과거의 나에게 해주고싶은 말이 있다면 다음과 같을 것 같다.
몸을 두개로 분할해서 레거시프로젝트에서 신규기능 개발도하고, 마이그레이션도 2년동안 진행하라고

테스트에 대한 경험도 없고, 마이그레이션 과정에 대한 이해를 많이 하지 못한 팀원들과 성급하게 작업을 시작한 것이 많은 에러를 야기하지 않았나 생각이 든다.

동아리라는 특성에 의해 빠르게 새로운 인원이 들어오고, 동아리 구조 개편과 프로젝트 신규기능 활성화로 인해 마이그레이션이 빠르게 이뤄져야했다는 부분은 나름의 트레이드 오프를 가져갔다고 생각한다.

안정성을 조금(?) 버리고 프로젝트를 활성화 했다고 봐야겠지

협업싱크를 맞추느라 일정이 늘어진다고? 그러면 굳이 컨벤션, 협업 하지말고 능력이 좋은 1명이 모든 Task를 할당받아서 갈리면 되는거 아닌가? 라고 생각할 수도 있다. 하지만 나는 그 방식을 좋아하지 않는다.
다시 한다고 해도 협업 가능한 구조를 만드는 것을 0순위로 두고 진행했을 것이다. 선순환 구조를 만들어야 프로젝트가 오래 지속될 수 있다고 생각하기 때문이다.
이번 과정을 통해 이 부분에 있어서만큼은 스스로 잘했다고 위안을 주고싶다.

아쉬운것들은 차차 메워나가보려고한다.

예를 들면 배포당 에러 발생률 0에 수렴하도록 만들어본다던가, 배포시간을 다시 1분 이내로 단축한다던가, JPA의 N+1 문제를 분석하고 해결할 수 있도록 부원들에게 과제를 내준다던가 등등 많은 학습거리를 던져줄 수도 있을 것 같다.

마무리

이렇게 배운점도 많고, 느낀점도 많은 마이그레이션 여정이 끝이났다.
이번 경험을 통해 조직의 특성을 고려하고 계획 수 있는 시야를 얻게된 것 같다.
무엇보다 믿어주고 따라와준 부원들에게 고맙다는 마음이 크다 🙇‍♂️
다들 고맙고 앞으로도 화이팅~! 💪💪