서론
덥디 더웠던 작년 여름 첫 발을 내딛은지 어느덧 1주년이 되었습니다. 1년 동안 회사 외부에서는 다른 개발자들의 이야기를 많이 듣고, 내부적으로도 열심히 지내왔습니다. 단순히 시간이 흘렀다고 넘기기에는 바뀌고 성장한 것들이 많아서 지금까지 어떤 삽질(?)하는 경험들이 있었고, 앞으로 어떤 방향으로 나아가고 싶은지에 대해 이야기해보고자 합니다.
현재의 상황
처음 최종 오퍼가 결정되고 입사 당시에 백엔드 팀은 저를 포함해 총 3명이었습니다. 하지만, 현재는 다른 팀원들이 모두 퇴사하고 4월부터 새로운 파트 리더님이 합류하시게 되면서 현재는 파트 리더님과 둘이서 백엔드 업무를 진행하고 있습니다.
기존 팀원 두 분이 비슷한 시기에 퇴사했을 때는 걱정과 우려가 많았 었습니다. 그런데 역설적이게도 전체 기간으로 보았을 때 이 시기가 제가 가장 많은 성장을 했던 기간이었던 것 같아요. 기존 팀원들이 담당하던 태스크들을 혼자 도맡아 해결해야 했기 때문에 무엇보다 '일'을 잘하기 위한 고민과 결정들을 많이 했습니다. 이전까지는 엔지니어로서의 기술적인 고민에 집중했다라면 이 시점을 기준으로 문제 해결과 (더 적극적인) 공유에 초점을 맞추게 되었어요. 이러한 노력들 덕분인지 현재는 파트 리더님께서 저를 믿고 일을 맡겨주시고 고민을 같이 나누고 해결해 나가고 있답니다.
어떤 것을 했는가
실제 운용되고 있는 백엔드 레포지토리만 해도 대략 20개 넘습니다. 그만큼 기존 서비스들을 운영 및 유지보수하고 신규 서비스를 개발하는 경험들을 해왔습니다.
그동안의 업무들을 나열해보면 다음과 같습니다.
- 통계 및 지표 쿼리
- 학습 통계
- 이용현황 통계
- 포인트 적립, 지급, 교환 개발
- 포인트 테이블 설계 및 개발
- 포인트 정률 이벤트 개발 (어드민 포함)
- 포인트로 기프티콘 교환 (외부 제휴사 연동)
- 데이터 마이그레이션 (Firestore to MySQL)
- 외부 제휴사와 결제 연동
- 멱등성 처리
- 팀 내 아키텍처 변경 제안 및 도입 적용
- 구현 레이어 추가
- 멀티 모듈 도입
- 보안 및 운영 개선
- AWS 자격증명 개선: 키 페어 방식 -> IAM 역할(role) 방식
- 헬스 체크 개선: Health Indicator, k8s probes(Readiness)
- 영속성(persistence) 기술 전환
- 기존: 프로시저 -> ORM(hibernate) 마이그레이션 (일부)
- 신규: Spring Data JPA, QueryDSL-JPA
- 해외 파트너(베트남, 일본)와 커뮤니케이션 및 기능 구현
- 애너테이션 기반 권한 프로세스 설계 및 구현
- (도메인 및 객체 중심으로 개발 진행중)
이 중에서 기억에 남 는 경험 몇 가지를 조금 더 적어보고자 합니다.
1. 팀 내 애플리케이션 아키텍처 변경
기존에 만들어진 서비스의 90% 이상이 스토어드 프로시저 기반으로 구현되어 있었습니다. 다행히 빌더 패턴 형태로 만들어진 유틸 클래스와 사내 프로시저 형상 관리 서비스가 존재했기에 관리 측면에서의 문제는 덜 했습니다. 그럼에도, 디버깅이 어렵고 유지보수가 어렵다는 문제가 존재했습니다. (물론 쿼리와 친해질 수 있어서 좋은 점도 있었습니다)
이러한 문제들을 떠안은 채로 작년 하반기부터 신규 서비스나 기존 서비스들에 작은 피처들부터 ORM을 적용해가기 시작했고, 올해 4월부터 시작해서 얼마전에 런칭한 신규 서비스에는 단 한 개의 프로시저도 사용하지 않으면서 프로시저를 걷어내는 시작이 되었습니다.
하지만, ORM으로 적용해가던 시기에 영속성 기술에 있어서는 차차 개선돼가고 있었지만, 애플리케이션 레벨에서의 유지보수는 여전히 어려움이 있었습니다. 구체적인 구현들이 하나의 함수(메서드)에 포함되어 있어 테스트 하기 어렵고, 읽기 어려운 코드들로 작성되고 있었습니다. 애플리케이션 레이어에서의 유지보수 문제를 해결해보고자 명세와 구현을 나누어 관리하는 방식을 팀원들에게 제안하여 설득에 성공해 현재까지도 유지되어오고 있습니다.
현재는 확장 가능성이 높고 복잡한 영역에 대해서는 순수한 도메인 모델(POJO)을 활용하 여 비즈니스 요구사항에 유연하게 풀어내고 있습니다. 회사 도메인 특성상 애그리거트 단위(상위 모델)로 묶이는 영역들이 있다보니 도메인 관심사를 기준으로 한 설계가 익숙해지면 합리적인 방법을 찾아 개선할 수 있을지 고민해보려고 합니다
2. 안정성 및 가용성, 일관성에 대한 고민
이번에 런칭을 과정에서 비정형 데이터를 관계형 데이터베이스로 마이그레이션 하는 작업을 담당했습니다. 한정된 일정과 비용에서 혼자 이 작업을 진행하면서 실패 가능성과 데이터 일관성에 대해 고민해야 했습니다.
가장 큰 마이그레이션은 다행히 요구사항 자체가 하루 한 번만 실행되면 된다였지만 자정마다 실행되어야 했기 때문에 한동안은 작업 완료를 확인하고 잠들곤 했습니다. 비정형 데이터에 프롬프트로 가공된 데이터들이 포함되어 있어 베타 테스트 기간 동안 불안정한 상황들이 존재했기 때문입니다. 그래서 에러 예외(OOM과 같은)가 아닌 예외가 발생하면 알림 또는 기록하는 방식들을 적용되어 있는 상태입니다.
물론, 현재 방법은 예외가 발생하면 복구전까지 완벽한 데이터 일관성은 깨지고 직접 처리를 해주어야 하는 단점은 존재합니다. 이 과정에서 결과적 일관성(Eventual Consistency)에 대한 패러다임에 대해서도 간접적으로 생각해볼 수 있었던 것 같습니다.
여담이지만, 개발 과정에서 실수를 줄이고 중요한 작업의 진행 상황을 모니터링하기 위해 만든 저만의 알림 채널이 있었는데요,
앞서 언급한 가장 큰 마이그레이션의 작업 진행 상태를 알림받는 용도로도 사용하고 있었습니다.
그런데, 얼마전에 팀 동료분이 이 알림 채널의 구현 방법에 대해 공유를 요청해 주셨습니다.
처음에는 단순히 제 업무의 효율을 높이기 위해 만든 도구였는데, 다른 팀원분께서 관심을 가져주시니 무척 뿌듯했던 것 같습니다
물론 제가 긍정적으로 해석한 것일 수도 있지만, 그래도 제가 만든 채널이 실제로 유용하게 사용되고 있다는 생각에 너무나도 기뻤고, 본래는 단순히 실수를 줄이기 위한 작은 노력이었는데 예상치 못한 행복을 느꼈습니다,,,!
3. 제안과 설득 그리고 팀
3. 보안 및 운영 개선의 하위 불릿 포인트로 AWS 자격증명 개선과 헬스 체크 개선이 있었는데요,
사실 이 두 개선 사항은 같은 팀 인프라 엔지니어분이 먼저 제안해 주신 내용이었습니다. 이 과정에서 저는 팀원으로서의 역할과 책임에 대해서 생각해볼 수 있었습니다.
두 포지션 모두 엔지니어는 동일하지만 인프라와 백엔드는 다루는 영역이 다소 다르기 때문에, 서로의 전문 분야를 이해하고 소통하려면 서로의 컨텍스트를 이해하기 위해 복잡한 개념을 쉬운 언어로 설명하는 과정이 필요했습니다.
아직 여러 경험들을 해보지 못한 신입이다보니 제안을 받기보다는 주로 제안을 하는 입장이었는데요,
이번에는 반대로 제안을 받아도 보고 이야기를 나누면서 함께 성장하는 경험을 했습니다. 이 과정에서 다른 팀원들의 제안을 경청하고 수용하는 것은 생각보다 중요하다는 걸 깨달았습니다. 이러한 경험은 단순히 기술적인 측면을 넘어 팀의 일원으로서 중요하다는 걸 느끼게 되어 기억에 남았습니다.
2년차에는 무얼 이루고 싶은가
미움 받을 용기
지금까지는 기획 / 디자인 / 개발 등 영역을 가리지 않고 이유가 있다면 대부분의 의견을 듣고 수용해왔던 것 같습니다. 그 이유를 곰곰이 생각해보니 불필요한 갈등을 피하고자 하는 마음에서 비롯된 것이었습니다.
하지만 제 생각을 전달하는 것의 중요성을 조금 의식하면서 다른 시각으로 접근해보고자 합니다.
이러한 생각이 든 건 다음의 이유 때문입니다.
- 미처 고려하지 못한 케이스를 발견할 수 있음
- 더 나은 아이디어라면 사용자에게 더 나은 서비스를 제공할 수 있음
- 건설적인 논의를 통해 팀 전체가 성장할 수 있게 됨
무엇보다 중요하다고 느낀 건 건설적인 논의가 될 수 있다는 생각 때문입니다.
더 성숙한 마음가짐으로 팀에 더 기여해보고자 합니다.
시스템을 만드는 것
서론에 적어놓았듯이 회사 외적으로도 다양한 활동을 해왔습니다. 선배 개발자 혹은 대대대선배 개발자분과 멘토링도 해보고, 컨퍼런스나 네트워킹을 하면서 다른 사람들의 고민과 생각들도 해보고, 스터디도 하며 이래저래 바쁘게 지내왔던 것 같아요.
그런데, 최근 이러한 활동들이 덜 수용되고, 정리되지 않은 상태가 되는 받았습니다.
그래서 한동안은 선택과 집중을 신중히 하면서 책도 많이 읽고, 내실도 다지면서 하나씩 단단히 하는 시간들을 보내볼까합니다.
(기술이 되는 근간이나 기본을 알아가는 시기에는 당장에 효용성을 느끼지 못하지만 스텝업이 되는 시기에 잘했구나하는 생각이 들더군요)
결론
얼마전에 "평범한 사람들이 모여 비범한 결과를 만든다"는 말이 최근 제 마음에 와닿게 한 문장이었습니다.
아직은 첫걸음을 뗀 햇병아리 신입 개발자이지만 그럼에도 불구하고, "팀 빌딩 하고 싶은 목표가 있다"고 당돌하게 이야기하고 다니고 있습니다. 조직에서 한 사람, 한 사람이 중요하고 조직이 어떻느냐에 따라 개인의 능력을 더 발휘할 수 있고 시너지가 나는 말로 표현 못하는 무언가가(?) 있는 것 같습니다.
믿고 의지해주고, 더 잘할 수 있는 조직을 만드는 목표를 이룰 때까지,,, 킵고잉 !
