11월은 coverage growth silo에서 새로운 사업자 대상의 체크리스트 제품을 만들고, 숨은 환급액 찾기의 웹진출을 위한 백업 작업과 다음 세목 추가를 위한 작업들을 먼저 진행했다. 그리고 드디어 프론트에서도 개인 클러스터를 도입했다. 11월 한달간 작업들을 정리해보려 한다.
새로운 제품, 사업자 체크리스트와 새로운 세목을 위한 준비
사업자 체크리스트는 새로운 사업자 대상의 제품이 나가기 전, 현재 사업자 분들이 사업을 진행하면서 혜택을 받을 수 있는 부분들에 대해 잘 알고 있는지 파악하고, 정보를 전달하기 위한 제품이다. 제품 출시 후 아직 많이 사용되고 있지는 못한 상태지만, 우리 부모님은 잘 알고 계실까하는 궁금한 내용도 있어 앞으로 좀 더 디벨롭해가면 좋겠다는 생각이 들었고, 이후 확장할 세목 제품들에도 시너지를 낼 수 있기를 기대하고 있다.
이후에는 숨은 환급액 찾기와 함께 새로운 세목을 추가하기 위한 준비 작업을 하고 있다. 같은 제품 내 함께 녹이기 때문에 같은 제품 영역에 두가지 사일로 작업이 있다보니, 디자인이나 실험에 있어서 병목이 있을 거란 우려가 생겼다. 다행히 먼저 이부분에 대해 이슈 레이징 했을 때 컨버젼 사일로 분들께서 잘 공감해주셔서 먼저 새로운 세목이 추가되는 버전을 먼저 내보내 충돌없이 독립적으로 각각 작업할 수 있었다. 현재 준비중인 새로운 세목이 12월를 타겟팅하고 있기 때문에, 12월 회고에 조금 더 작성해 보려한다.
숨은 환급액 찾기 웹버전 백업과 이어지는 고민
컨버전 사일로의 노력으로 최근 숨은 환급액 찾기 서비스가 웹으로 출시되게 되었다. 팀이동을 하면서 직접 작업을 하지 않았지만, 이전 히스토리를 아는 사람으로서 새로 오신 두분의 백업을 맡아 조금씩 함께 이슈를 처리하며 백업을 진행했다. 백업을 진행하면서 웹쪽 코드를 보면서, 웹과 모바일 두가지 플랫폼에서 플랫폼 차이로 발생하는 관리의 어려움을 느낄 수 있었고, 앞으로 두가지 모두를 잘 관리하기 위해 여러가지 방법과 기술적인 고민도 필요하겠다는 생각이 들었다.
예를 들어 모바일과 웹 모두에서 똑같이 제보된 이슈를 수정할 때나, 단순 문구를 수정할 때도 항상 두가지 플랫폼 모두를 신경써서 작업해야한다는 점에서 앞으로 리소스가 2배 이상 쓰일 수 있는 작업들을 어떻게 하면 공통화할지, 또 다른 부분은 어떻게 처리할지에 대한 다양한 논의가 필요할 것 같다.
이런 고민들과 함께 새롭게 웹을 위한 인프라 세팅을 하면서 동료분이 어려움을 이야기 해주셨고, 인컴에서 인프라 관련 작업을 할 때의 어려움이 블랙박스로 남아 계속해서 어렵게 한다는 생각이 들었다. 내가 관심있는 분야이기도 하고, 현재 팀이 겪고 있는 문제이기도 하기 때문에 해당 세팅을 어떻게 하면 간편하게 할 수 있을지 등 고민해보려 한다.
프론트 개발 생산성을 위한 개인클러스터 도입
프론트 개발자가 2명에서 5명으로 늘어나면서, 기존 알파 환경을 사용하는 방식에 대해 문제가 커졌다. 2명에서는 기존에 바텀싯 형식으로 특정 개발자 이름으로 들어가면 해당 개발자의 결과물을 볼 수 있도록 별도 도메인과 서버를 연결해 해결하고 있었다. 여기에는 세가지 문제점이 존재하게 된다.
먼저 한명이 하나의 결과물만 알파 환경에서 테스트할 수 있다. 기존의 구현방식은 개발자 마다 하나의 도메인과 하나의 서버를 연결해 테스트할 수 있게 되어있었다. 이때 한명이 여러개의 작업에 대한 빌드 결과물을 보고 싶을 때는 기존 걸 revert한 후에 새로 올리거나 이전 작업이 main에 병합되어야 알파 환경과 연결된 브랜치에 연결해서 볼 수 있는 문제가 있었다.
두 번째로는 알파 환경 구현 방식으로 인한 테스트의 어려움이다. 라이브와 달리 알파는 develop 기준 도메인에 진입해 바텀싯을 띄우고나서, 선택한 도메인으로 진입하는 방식이기 때문에 테스트환경이 다르다. 이로 인한 사이드 이펙트로, 진입 시점에 실행되는 로직을 테스트할 때 이동 전에 먼저 실행되거나, 결과물이 develop에서 없는 페이지인 경우 404가 발생하는 이슈가 있었다. 또한 두번 웹뷰를 띄우면서 발생하는 사이드 이펙트로 인해 앱브릿지의 에러로 타팀에서 수정요청이 들어오기도 했다.
세 번째로는 인프라와 개발과정의 복잡성이다. 개발자가 한명 추가될 때마다 매번 별도의 파이프라인을 만들어, 새로운 브랜치와 바텀싯에 이름 추가, 새로운 도메인을 인식하기 위한 devops 팀의 작업이 필요했다. 또한 별도의 파이프라인으로 인해, 각각의 변경점을 감지하기 위해 타겟팅하는 dev/a, dev/b 등의 브랜치들이 만들고, 이러한 커스텀 git flow 전략으로 develop을 개인마다 가지고 것처럼 배포하다 보니, 계속 브랜치를 최신화하기 위한 관리가 더 많이 필요해지고, merge 커밋은 어떻게 할지 등 다양한 고민이 필요했다.
이러한 문제점을 한번에 해결하기 위해 개인 클러스터를 도입하게 되었다.
개인 클러스터는 먼저 개발자별 서버를 고정적으로 사용하는 게 아니라, 작업별 서버를 만들는 방식으로 같은 요청이 들어와도 특정 헤더 를 감지해, 해당 서버로 꺾어주는 gateway를 중앙에 두는 방식을 의미한다.
기존 이미지와 비교해 보면 아래와 같다
간단하게 생각해보면 바텀싯으로 웹에서 진행하던 부분을 게이트웨이에서 웹뷰를 띄울때 request header에 있는 헤더값을 감지해 필요한 서버로 라우팅을 하고, 해당 서버의 빌드 결과물을 가져오는 방식이다.
첫 번째 문제점이었던 개발자별 하나의 작업만 테스트 환경에 올릴 수 있는 문제가, 작업별 서버를 띄우고 해당 서버에 대한 설정을 헤더로 설정하는 작업을 하면 됨으로 해결되게 된다. 테스트를 할때는 헤더 설정을 앱내에서 수정하면 다른 작업으로 바로 진입할 수 있게 된다.
두번째 문제였던 테스트의 어려움 문제는 더이상 두번 웹뷰를 띄우지 않고 미리 설정한 헤더 값을 읽고 웹뷰를 띄워 alpha/tax-refunds로 한번만 진입하기 때문에 해결되게 된다.
세번째 문제였던 인프라와 개발과정의 복잡성은 파이프라인은 하나로 유지한 체로, 게이트웨이에 설정과 서버만 띄우면되기 때문에 devops팀 분들의 도움 없이도 알파환경 구성이 가능하다. git 전략은 이제 main을 기준으로 바로 작업 브랜치를 따고 개별 작업 서버를 띄우면 되기 때문에 TBD를 이용해 간단하게 운영이 가능하다.
1~2달 정도 devops 분들과 함께 이야기하고 요청드린 후에 어떻게 사용할지를 고민하고, 테스트한 후에 적용하게 되었다. 사용하는 프론트 개발자분들과 테스트하시는 사일로원분들, QA분들의 의견을 자주 들어 더 자주 배포하고, 더 빠르게 배포하는데 기여하는 좋은 개발 문화를 만들어가보려 한다.
돌아보는 11월의 액션아이템과 12월 액션아이템
11월의 목표는 아래와 같았다.
- 도커와 쿠버네티스 공부해보기
- 프론트 개인 클러스터 도입
현재 도커는 공부하고 있지만 아직 쿠버네티스까지 가지는 못했다. 대신 도커에 대한 이해도를 바탕으로 인컴 내 다양한 서비스의 인프라에 대한 이해도를 조금씩 올려가고 있다. 앞으로 다양한 서비스를 서빙해야하는 것에 대한 니즈가 있기 때문에 나만의 뾰족함을 만들어가기에도 좋을 것 같아서 계속해서 해보려 한다.
프론트 개인클러스터는 무사히 잘 도입했고 이후에는 더 잘 사용할 수 있게 사용성을 개선하기 위한 다양한 방식을 고민하고 적용하려 한다.
그래서 12월의 목표는 아래로 잡아보려 한다.
- 도커와 쿠버네티스 공부해보기
- 인컴 내 인프라 구조 정리하기
- 개인클러스터 사용성 개선하기
12월의 목표는 11월과 유사하지만 조금 더 인프라를 챕터내 자산으로 만들기 위한 문서화와, 관리 편리성을 위한 관리 방식 통일화에 대해 고민해볼 예정이다. 그와 함께 도커와 쿠버네티스를 계속해서 공부하고, 개인 클러스터가 아직 낯선 분들을 위해 조금 더 편하게 사용할 수 있게 사용성을 더 높여보려 한다.
매달 느끼지만 한달 한달 똑같은 걸 그냥 했다는 없는게 신기하다. 더 많은 걸 배우고 적용해보자.