이번 글은 몸이 안 좋아서 회사에서 있었던 일을 회고하는 글로 대체합니다.

현재 회사에 들어온 지도 벌써 6개월이 지났네요. 그간 어떤 일들이 있었는지 회고하려 합니다.

저는 현 회사에서 아래 내용들을 진행했습니다.

1. 레거시 개선 및 신규 서비스 런칭 준비
2. 기존 완성된 서비스 일부를 재구성하여 배포
3. 적극적인 개발문화 조성

레거시 개선 - 준비과정

주요한 요소는 레거시 개선입니다. 제가 입사하기 전 까지 백엔드 전체가 외주로 관리(!)되고 있었죠. 제가 입사를 결정할 즈음 해서 인수인계 과정이 시작되었습니다. 입사 후 인수인계 문서를 받아보자 프로젝트 생성 시 만들어진 README 문서와 데이터 테이블 엑셀파일이 있었습니다. 어떤 테이블이 어떻게 연관관계를 맺고있는지 파악이 불가능한 상태였고, 연관관계나 설계 의도에 대한 문서도 꽤나 차이가 많아 곤욕을 치렀습니다.

하지만 책임지고 해봐야죠. 이 상황을 개선해내고 나은 시스템을 만들어 봐야죠. 이를 위해 기존 기획서와 필요한 요소들을 교차검증하여 무엇부터 재구성 해야하는지 다시 설계했습니다. 더 나아가 회사 내 비즈니스 컨셉에 대해 조금씩 물어보기 시작헀고, 신입교육을 듣고난 후에는 어떤 컨셉의 용어들이 오고가는지를 문서에 작성하기 시작했습니다. 어떤 용어를 쓰며 구성원들이 의사소통 하는지 이해해야, 어떤 것들이 필요하고 또 어떤 것들이 모자란지 그리고 어떤 것을 만들고 개선해야할지 파악할 수 있기 때문입니다.

레거시 개선 - 어떻게 개선했나요?

백엔드 개선

빠른 일정에 맞추어 기존 레거시를 도저히 수정할 자신이 없었기 때문에, 제게 익숙한 언어와 프레임워크를 사용하기로 결정했습니다. 이후 앞서 말한 요구사항 도출로부터 다시 시작했습니다. 그리고 기존에 만들어진 웹앱과 네이티브 앱에서는 어떤 API를 사용하는지, 어떤 API를 신규로 만들어야 하는지를 먼저 듣고 회의를 진행한 후 RDB 테이블부터 재설계 했지요. 최소한 RDB 테이블 설계부터 잘 한 다음에 앞으로 어떻게 시스템을 확장해야겠다 라는 생각을 했습니다.

아키텍처 구성은 새 API로 빠르게 이전될 수 있도록 구성을 가져왔습니다. 엔드포인트-서비스-DB 순의 3계층 구성으로 요청-응답을 그대로 가져왔지만 제 설계대로 로직이 처리될 수 있게 갈아끼웠습니다.

배포는 컨테이너 기반으로 빠르게 대체했습니다. 기존에 몇번 해본 경험도 있고, ‘안되어있는 것 보단 빠르게 하는게 맞겠다’ 라는 판단 하에 망설일 것 없이 도입했습니다.

인프라 구성 자동화

전 인프라를 테라폼으로 코드화한 경험을 바탕으로 현재 구조도 코드화를 완료했습니다. 완료된 설계사항은 draw.io로 문서화를 해두었는데, 이 때 Layer 기능이 굉장히 좋았습니다. 특히나 네트워크 구성을 문서화해두고, 설계한 VPC 내에서 어떤 서브넷은 얼마만큼 커질지 예상해서 배포해두었습니다.

필요한 테라폼 모듈은 만들기도 하고, 이미 완성된 모듈을 사용해서 최대한 반복을 줄여서 배포할 수 있도록 Terragrunt 로 구성했습니다. 반드시 필요할 개발서버/스테이징서버/운영서버 생성과정 대응을 환경변수 수정 및 YAML 파일 수정만으로 할 수 있게 구성했지요.

DevOps 문화 조성

공유가 필요한 내용은 앞서 말했던 문서화를 다른 팀에게 공유할 수 있도록 위키를 만들었습니다. 사내 업무 시스템을 이용해서, 멘션 시 즉시 알람을 받고 의사소통할 수 있는 환경을 제안했습니다.

엔드포인트에 대한 현상 공유는 구성원들에게 익숙한 Postman 스펙과 Swagger문서로 제공했습니다. 확실한 예시값/응답값을 전달해서 보다 명확한 의사소통 포인트를 잡았습니다.

이슈 생성부터 해결과정을 한눈에 보기 위해 이슈 트래커를 적극 활용했습니다. 이슈와 PR 및 머지 내용을 함께 알람으로 받아볼 수 있도록 해서, 필요한 사람은 진행상황을 지속적으로 받아볼 수 있도록 조성해서 누가 언제 이 일을 진행하고 끝낼지 칸반보드로 볼 수 있게 구성했습니다.

서비스의 현상 파악을 위해 CloudWatch의 대쉬보드 생성을 진행했고 threshold 감지 시 알람을 받을 수 있도록 구성해두었습니다. 서비스 에러 모니터링 대응을 위해선 Self hosted Sentry를 직접 구축하고 운용을 시작했습니다. 500에러 퍼센티지 메트릭 알람으로 에러를 리포팅받는 것을 넘어, Sentry를 통해 에러를 직접 받아볼 수 있게 하고 업무 메신저나 이슈 트래커로 관리되게 연동했습니다.

회고합시다

걸어온 일에 대해 제 스스로 딴지를 걸어보며 되짚어봅시다.

회고해보면 - 백엔드 개선

현 작업을 통해, 최소한 배포 후 서버가 죽었는지 살았는지 파악하기 힘들던 시스템부터 재구성 했습니다.

도메인 기반 설계는 일부러 진행하지 않았습니다. 이제는 이 기술이 ‘좋아보인다’ 로 판단하지 않고 ‘내게(그리고 회사에) 필요한가?‘로 판단했습니다. 우선 레거시를 넘어 저의 설계로 넘어오는 것이 먼저라고 생각했고 그게 가능하려면 빨리 개발될 수 있는 트랜잭션 스크립트로 개발하면 되는 일이었기 때문이죠. 현재 요구사항이 도메인 기반으로 설계할 만큼 복잡하다고 판단하지 않았기 때문입니다. 서비스가 커지고, 도메인이 해야할 일이 복잡해지면 옮겨야겠지만요.

개발하면서 저의 의사소통의 방식이 많이 아쉬웠습니다. 기존 API 엔드포인트를 옮기고 신규 엔드포인트를 설계하며, ‘이 내용은 이렇게 설계하면 향후 변화에 더 대응하기 좋을 것이다’ 라는 생각을 보다 적극적으로 어필하지 못했기 때문입니다. 그렇다보니, 변화 후 Swagger 문서 및 Postman 문서로 즉각 제공해도 변화에 대응해야 하는 시간을 가져야 함을 고려하지 못했죠.

회고해보면 - 인프라 구성

현재 구성이 생각보다 복잡한가? 하는 생각을 하기도 했습니다. 저 스스로는 모든 것을 다 할 수 있지만, 앞으로 함께 할 동료도 이런 환경에 익숙해져야 할테니까요. 이런 상황에 대비하여 문서화는 진행했습니다. (감사하게도) 팀이 커진다면, 인프라 팀이 별도로 구성되었을 때 ‘왜 이런 설계를 하셨나요?’ 라고 설계의 근거를 전달할 수 있도록 말이죠.

회고해보면 - DevOps 문화 조성

누구나 이런 환경에 익숙한 건 아닙니다. 전체 개발팀 구성원이 이러한 방식으로 의사소통을 하고 시너지를 내기 위해서는 모두에게 이 시스템이 왜 좋은지 설득할 수도 있어야 하지요. 일단 만들고 쓰길 기대하는 것에서 더 나아가 이렇게 쓰면 좋음을 사내에 세미나로 공유하기로 했고, 진행할 예정입니다.

앞으로의 6개월?

앞으로의 6개월은 이렇게 나아갈 예정입니다.

1. 공유, 공유, 공유!
   • 비즈니스와 연관있다면 어떤 문제든지 구성원들과 함께 공유하고 문제 해결을 진행하기
2. 백엔드 서비스의 테스트 코드 확보
   • 비즈니스 로직부터 API 호출 모두 테스트할 수 있도록 구성하기
   • 테스트 가능한 구성으로 코드 리팩터링을 진행하기
3. DevOps 문화 강화
   • 현재 문화를 혼자 개선하려고 행동하는게 아니라, 모든 구성원을 설득하고 시너지를 낼 수 있도록 적극적으로 설득하기

끝으로

제가 배우고 익혔던 것들을 팀원에게 공유하고 이것으로 비즈니스적 가치창출에 도움이 된다면 좋겠다는 생각 뿐입니다. 이를 위해 더 많은 것들을 배우고 그 과정 속에서 구성원들과 더욱 즐겁게 일할 수 있었으면 좋겠습니다.