훌륭한 백엔드 동료들 (3명의 어른들과 병아리 한 마리 병아리는 바로 나) 과 함께 1년간 성장할 수 있는 기회를 얻었고
그 덕분에 경험하고 느꼈던 것들에 대하여 회고를 진행하려고 합니다.

한정된 리소스로 최선의 결과를

우리 회사는 통신 3사의 정책이나 프로모션을 담당하는 부서에 의사결정권이 강하다.

그 이유는 알뜰폰 서비스를 메인으로 제공하고 있기 때문인데
MNO(KT, SKT, LGT) 3사의 프로모션 상황에 따라 빠르게 자사 회원을 확보하고
확보한 자사 회원들에게 혜택을 지급 하는 것이 회사의 핵심 비즈니스 모델이기 때문이다.

그렇기에 촉박한 시간 안에 특정 프로모션에 대응하여 론칭해야 하는 상황이 주로 발생했다.
개발팀은 요구사항을 만족하기 위해 많은 노력을 하고 대부분의 경우 임무를 완수하지만
이런 방식으로 계발이 지속되면 발생 가능한 문제 중에 하나는 기술부채가 발생한다는 것이다.

어쩔 수 없이 한정된 리소스로 최선의 결과를 도출하기 위해 노력한다.

기술부채에 맞설 수 있는 문화로

개발팀에서 가장 무서운 말은 무엇일까?
올해 내가 생각하기엔 어쩔 수 없죠 인 것 같다.

주로 기술부채를 만들 때 사용된다.

우리 개발팀도 초반에는 이런 경향이 컸다.
도메인적 지식(통신)도 서비스의 복잡성을 올리는데
내가 입사할 당시에만 하더라도 거대한 MSA구조를 단 2명이서 유지하며
새로운 기능 개발까지 진행하고 있었기 때문이다.

감사하게도 서로 논의할 수 있는 문화와 환경을 만들기 위해서 많은 노력을 해주셨다.
우리 팀은 악순환의 굴레를 끊고자 하는 의지가 강했기에
바쁜 와중에도 팀 내부에서 제기한 의견에 대해서 진지하게 고민하고
논의하는 환경과 문화를 만들어 나갈 수 있었다.

한정된 리소스로 최고의 결과를 내기 위해

소프트웨어 아키텍처의 중요성 - 마틴 파울러
에선 다음과 같은 말을 한다.

• 좋은 아키텍처를 가져가려는 노력을 지속하면 개발 속도가 가속화된다
• 아키텍처는 팀과 핵심 가치를 공유해야 한다.
  필자는 여기서 등장하는 아키텍처에는 개발팀의 문화와 코드모두 포함된다고 느꼈다.
  그렇기에 내가 팀에 기여할 수 있는 게 무엇인지 코드 외적으로도 고민하는 계기가 되었다.

필자가 제안하고 진행했던 것들에 대해 돌아보자면 다음과 같다.

팀 문서 노션 이관 및 최신화

정리한 노션 페이지 일부

기존에 Jira Atlassian를 통해서 문서를 정리해오고 있었으나
업데이트가 되지 못하는 경우가 대다수였다.
마침 회사 전체가 노션을 도입하려고 하던 시기였고 노션 이관 및 정리를 맡아 진행했다.

이관하면서 집중한 것은 다음과 같다.

• 동료들이 쉽게 문서를 찾을 수 있도록 하자
• 미래의 동료를 위한 가이드 문서를 만들자
• 지루한 문서 재미있게 풀어내자

감사하게도 팀 전체가 문서 업데이트에 동참해 주셨고
다른 부서의 동료들도 백엔드팀이 무엇을 하는지 많이 알릴 수 있는 기회가 되었다.

코드 컨벤션 확립 및 Lint 구성

입사 당시 코드 컨벤션이 제대로 확립되어 있지 않아서
동일한 기술 스택을 사용함에도 작업자의 의도에 따라 구조, 코드스타일이 크게 달랐다.
그러므로 필자는 해당 부분에 대해 논의할 수 있도록 이슈잉을 진행했다.

그다음 서로 같은 눈높이(Insight)를 가질 수 있도록 팀원과 함께 논의하는 시간을 가졌다.
왜냐하면 처음에는 자유도를 제한하면 생산성이 낮아지는 것이 아닌가 하는 의견도 존재했기 때문이다.

이후 모든 서비스에 Lint Rule 적용까지 진행했고
초기 개발뿐만이 아니라 다른 작업자가 특정 로직을 수정할 때 구조와 코드를 이해하는데 도움을 주어 결과적으로 많은 시간을 절약해 그런 걱정들이 기우였음을 확인할 수 있었다.

클린코드를 보더라도 우리가 무엇을 하지 않을 때 얻을 수 있는 것에 대해 강조한다.

Figma 도입

입사 당시엔 프로젝트에 대한 히스토리성 문서가 전혀 없었다.
문서화의 일환으로 진행하는 프로젝트에 대한 내용(ERD, 플로우 등)을 Figma로 정리해서 공유했다.

결과적으로 해당 프로젝트에 직접 참여하지 않아도 쉽게 프로젝트에 대한 이해도를 높일 수 있었고
부가적인 효과로 코드리뷰의 질도 상승했다.

이후에는 모든 프로젝트는 Figma로 공유하고 리뷰하는 프로세스가 정착되었다.

BO 강화

백오피스 기능을 생략하거나 최소화하는 방향으로 프로젝트가 진행되는 케이스가 많이 발생했다.
사업구조 특성상 ASAP으로 진행되는 프로젝트가 많았기 때문이다

이렇게 될 경우 내가 생각한 문제점은 다음과 같다.

• 백엔드 팀이 운영성 업무에 대응하느라 다른 중요한 일을 하지 못한다.
• 백엔드 팀이 실시간 대응하기 어렵기 때문에 결과적으로 고객불만이 커진다.

그렇기에 계속해서 발생하는 운영성 업무에 대해서
BO API를 지원할 수 있도록 지속적으로 개발했다.
(공지사항 관리, 상품 딜 관리, 문자메시지 전송 등..)

이후 진행되는 프로젝트에서는 프로세스 상 발생가능한 운영성 이슈에 대해 다시 한번 생각하게 되었고
필요한 기능이 있다고 생각되면 기획팀에 의견을 제시했다.
(쿠폰 재발행처리, 쿠폰관리, 검색조건 등..)

팀 생산성 향상 프로젝트

프로젝트 도라에몽..

사내 Bitbucket에 스크립트나 도움이 되는 모듈들을 모아둘 수 있는 레포지토리를 하나 만들었다.
개인적으로 내 스크립트로 동료의 생산성을 높이고 피드백을 받는 과정이 즐거웠기 때문이다.

진행하고 공유한 스크립트는 다음과 같다

• 카카오톡 알림톡 발송 스크립트
• 현행화 테이블 데이터 부조화 수정 스크립트
• Swagger 문서 기반 자사 컨벤션에 맞는 DTO, Interface 생성 스크립트

특히 Swagger 기반 DTO, Interface 생성 스크립트 반응이 좋았다
유플러스 API를 빠른 시일 내에 연동해야 했는데 API만 50개 정도 되었고
API 요청, 응답 파라미터가 100개 이상되는 API가 많아 작업이 지연되고 있었는데
해당 스크립트를 통해 작업 시간을 많이 단축할 수 있었다.

로그 정리

우리 서비스의 모든 로그는 Datadog, 중요한 에러는 Sentry + Slack로 기록하고 있다.

서비스 로그 형식과 Sentry의 요청 기준을 통일하기 위해 이슈잉을 진행했다.
로깅과 Sentry 기록을 모두 개발자의 판단에 따라 비즈니스 로직에 포함시켜야 했기 때문이다.
MSA 구조에서는 어디에서 에러가 발생했는지 파악하는 것이 중요한데
관심사 분리가 충분히 이루어지지 않아 중복 로깅, 중복 알림 문제가 발생하고 있었다.

팀과 논의를 진행하고 다음과 같이 작업을 진행했다.

• 서비스 간 로깅 양식을 통일했다.
• NestJS CustomLogger를 활용하여 에러 레벨에 따라 로그를 처리하도록 했다.
  • 일반 로그 레벨 : 단순 기록용 로그
    • Datadog에만 기록된다.
  • 에러 로그 레벨 : 핸들링되지 않았거나, 기록 및 알림이 필요한 로그
    • Datadog에 에러 스택과 함께 기록된다.
    • 에러 스택, 에러 상세 내용이 Sentry에 기록된다.

이렇게 진행함으로써 로직상에서 이루어지는 로깅 로직에 대해 관심사 분리가 이루어졌고
자연스럽게 동일한 오류가 다른 서비스로 전파되어 중복으로 로깅되는 현상도 감소하였다.

테스트코드 도입

테스트 코드도 점진적으로 도입했다.
많은 팀원이 코드 수정을 진행하다 보니
코드 리뷰, 개발자의 테스트로는 확인 불가능한 에러가 늘어났기 때문이다.

현재 점진적으로 적용 중이며 각 프로젝트별로
nest-cli 명령어로 생겨난 불필요한 테스트 코드 제거하고
Husky per-push 이벤트를 후킹 하여 유닛테스트를 실행하도록 구성했다.

조금씩 천천히 도입 중인데 유닛 테스트 특성상 공유 의존성(ex. DB)에 대한 테스트가 어렵기 때문에
이런 종류의 테스트 처리 방식을 팀과 함께 고민하고 있다

자세한 사항은 블로그 글로 정리했다 -> 테스트 코드란

더 나은 대안을 제시할 수 있는 사람이 되자

동료들과 서로 신뢰하면서 일을 한다는 것이 어떤 것인지
더 나은 서비스를 만들기 위한 많은 경험과 고민을 할 수 있는 한 해였다.

기술 부채의 악순환을 해결해 나가면서 얻게 된 것은
우리가 노력함으로써 서비스는 더 나아질 것이라는 희망, 우리가 걸어온 길을 돌아볼 수 있는 기회가 생겼다는 점이다.

개인적으로 그 안에서 부족함을 느꼈던 것이 있는데
내가 한정된 리소스 안에서 더 나은 대안을 제시하고 실현할 수 있는
사람인가에 대해서는 한참 부족하다고 생각한다.

내년에는 탄탄한 레퍼런스로 더 나은 대안을 제시하는 경험을 해보고 싶다.

읽어주셔서 감사합니다.