벌써 1년이 또 지나서 2023년의 해가 밝은지도 벌써 두달이 지났다. 올해는 연초부터 회사일과 현재 사는 집에 대한 일 등으로 조금 정신없이 보내고 있다가 이제 좀 한가해져서 2022년에 대한 회고록을 적어보고 있다.

1. 2022년엔…

작년에 썼던 회고록의 작성 시점이 이미 2022년 중순쯤이었는데 당시에 회사에서 진행 중인 멤버십 서비스 런칭으로 인해 상당히 바빴던 시기였다. 풀재택이긴 했지만 진짜 과장없이 2월에서 4월 동안은 주 5일 중 4일은 8, 9시에 퇴근 했던거 같다.

그덕인지 아주 다행스럽게도 서비스 오픈은 큰 이슈없이 잘 넘어갔었다. 하지만 하반기 역시 생각보다 바빴고 그래도 상반기 때 보다는 무언가 기술적으로는 만족할만한 업무들을 주로 진행 해볼 수 있었다.

신규 서비스 런칭하기

상반기엔 거의 이 업무 하나로 네 달 가까이 보낸거 같은데 그만큼 회사에서도 크게 준비하고 있던 서비스였고 그만큼 작업 범위나 영향 범위도 엄청 넓었다. 이 회사와서 처음으로 몇 달 간을 야근으로 보내곤 했으니 얼마나 고달팠던 업무인지 대충 짐작은 할 수 있을 것이다…

아무튼, 고객들에게 제공할 멤버십 서비스에 대한 신규 프로젝트였는데 아무래도 고객들에게도 직접적으로 체감되는 서비스이기도 하고 회사 입장에서는 매출이나 이익에 직접적으로 아주 큰 영향을 미칠 수 있는 서비스이다보니 모든 팀들에게서 전반적으로 많은 업무량과 시간을 쏟게 하였던 프로젝트였다.

물론 서비스 자체가 큰 것도 있었지만 막판에 가서 너무 자잘하게 바뀌는 부분들도 많았던 터라 현업의 실무자들이 그만큼 더 고생했던 것 같다. 고생해가며 만들어서 그런지 다행히도 오픈하고 나서 우리팀 영역엔 큰 이슈가 없었고 지금까지도 잘 운영되고 있다. 내가 개발한 영역은 고객과 직접적으로 맞닿은 영역은 아니고 주로 백오피스, 그러니깐 어드민(admin)이 사용하는 영역에 대한 개발이었는데 이것도 결국 고객에게 보여지고 쓰일 마스터 데이터들을 관리하는 영역들이라 하나라도 대충 할 수 없었다.

특히나 기존 어드민을 개편하는 팀 내부 업무까지 같이 진행하였다보니(연관성이 깊어서 같이 할 수 밖에 없었다) 2배로 힘들었던 것 같다. 그래도 잘 오픈된 모습을 보니 그나마 위안이 되고 날 괴롭히던 큰 업무 하나를 덜어낼 수 있어서 좋았다…^^

GCP와 대용량 데이터 다뤄보기

그리고 하나 더 기억에 남는 큰 업무로는 외부 제휴사와의 연동을 위한 프로세스를 구축하는 것이었는데 Google Cloud Platform(이하 GCP)과 Kafka를 이용해볼 수 있었다. (Kafka는 이미 도입한 지 오래 되긴 했다)

기존엔 회사 메인 DB인 Oracle에서 제휴사로 연동할 데이터들을 가공하곤 했는데 이게 상당히 시간이 오래 걸렸다. 정말 데이터가 많을 때엔 최장 7, 8시간까지 걸리곤 했으니 제때 제휴사와의 데이터 연동이 되지 않을 때도 있었다.

그래서 내부적으로 논의하다가 나온게 GCP였는데 나도 아직은 찍먹(?)만 해본 수준이라 자세한 데이터베이스의 구조라든가 성능이 더 우수한 이유 등은 설명하긴 이르고 그냥 그것의 우수한 성능을 경험해보는 정도로 우선 경험을 간직하고 있다.

이게 얼마나 차이가 나냐면 시간으로만 따지면 거의 7 ~ 8시간 걸리던게 1 ~ 2시간까지 줄어들었다. 그러다보니 제휴사와의 연동이 늦어지는 일이 없게 되었고 메인 DB를 점유하고 있는 시간과 리소스 사용량이 줄어들다보니 덩달아 메인 서비스에 주던 영향까지 줄일 수 있었다.

GCP에서 데이터를 가공하고 그것을 프로듀서 애플리케이션에서 BigQuery API를 통해 JSON 데이터로 내려받은 뒤, Kafka로 쏴주고 최종적으로 컨슈머 애플리케이션이 컨슘하여 제휴사 연동 애플리케이션 쪽으로 전달해주는 형태이다. 이렇게 전환하면서 자연스럽게 메인 서비스가 올라가있는 Oracle DB의 리소스 사용량과 연동 시간을 줄일 수 있었다.

그리고 기존엔 DB의 프로시저로 이 연동 행위들을 진행하다보니 전체 프로세스가 하나로 묶여있었는데 이것도 Kafka를 이용함으로써 자연스럽게 비동기 방식으로 넘어갈 수 있게 되었다. 비동기 방식으로 전환하게 되면서 컨슈머의 성능 튜닝과 파티셔닝만 적절히 잘해주니 제휴사 연동 프로세스가 계속해서 애플리케이션을 점유할 일도 없어지고 이전보다 안정적으로 운영이 가능해졌다. 대용량이라 불릴만한 정도의 규모인지는 모르겠지만 그래도 연동 한 타임에 백만건 이상의 데이터를 다뤄보니 대용량 데이터를 내려받고 주고 받을 땐 고려해야할 점들이 많다는 것을 느낄 수 있었던 업무였다.

팀 내 개발 컨벤션 정리하기

그렇게 하반기도 나름 바쁘게 보내고 연말에는 좀 더 팀 내실(?)을 다지는 업무들 위주로 진행을 했었다. 팀원들 모두 업무가 많고 바쁘다보니 누구 하나 나서서 신경쓰지 못했던 팀 코딩 컨벤션이나 표준안들, 개발에 대한 공통화 등을 조금씩 정리해갔다.

정리해본 항목들에는,

Code Style: 이건 전사적으로 사용 중인 표준 스타일 가이드가 있어서 그것을 사용하는 것으로 했다. 이 가이드 역시 Google Code Style을 가져와서 우리 회사 입맛에 맞게 커스터마이징 한 것이다. 팀 단위로 개발을 진행할 땐 꼭 이러한 코드 스타일 가이드는 필요하다고 생각한다. 모두 각자의 코드 스타일이 있기 때문에 이런 표준없이 개발을 진행한다면 너무 중구난방의 소스코드가 되어버리기도 하고 누군가 보았을 때 한눈에 읽기도 힘들어질 수 있다. 팀 단위의 프로젝트는 마치 한 사람이 만든 것처럼 최대한 스타일은 맞춰서 진행하는게 좋은 것 같다.
Git Commit Message Convention: 기존에도 위 코드 스타일처럼 회사 차원에서 정해둔 커밋 메시지 컨벤션이 있긴 했는데 팀원들끼리 컨벤션 사용에 대한 협의한 적이 없다보니 사용하고 있지 않았다. 그래서 회사의 컨벤션을 기반으로 인터넷에서 쉽게 볼 수 있는 여러 글들을 읽어보며 그것들을 적절히 섞어서 현재의 팀 컨벤션을 만들게 되었다. 확실히 커밋 메시지 컨벤션이 정해지고 나서는 커밋 메시지를 살펴볼 때 어떠한 내역의 커밋인지, 그리고 어떤 부분에서 수정이 있었는지 간략하게 한눈에 알아볼 수 있어서 좋아졌다.
Git Branch 전략: 이건 아직 도입은 못했고 우선 대략적인 룰만 정해둔 상태이다. 현재 팀 내 프로젝트들은 기존에 회사 내 레거시 프로젝트들에 적용해둔 브랜치 전략을 따르고 있는데 아래와 같다.
- dev - qa - stg 총 3개의 브랜치가 존재한다. 개발자는 기본적으로 dev 브랜치에서 feature 브랜치를 생성하여 사용하고 dev -> qa -> stg 순으로 merge하여 최종적으로 운영 환경(Prod) 배포는 stg 브랜치 버전을 기준으로 나가게 된다.
- 새롭게 도입을 검토해본 전략으로는 그 유명한 Git-flow가 있다. 내용은 워낙 유명하니 따로 설명하지 않겠고 기존 브랜치 전략은 급하게 버그 픽스나 수정건으로 나가야 할 항목이 있으면 아래와 같은 단점들이 있었는데,
  1. 내가 반영할 건들 이전에 누군가 반영해둔 건이 있다면 해당 건들이 운영 환경까지 배포되어도 문제가 없을지 팀원들의 확인이 필요했다.
  2. 그러다보니 긴급건에 대한 신속한 대응이 어려운 경우가 생기기도 하고 필요하다면 롤백도 해야하는 번거로움까지 있기 때문에 코드 관리도 어려워지곤 했다.
  때문에 새로운 브랜치 전략을 찾아보았고 Git-flow가 이러한 단점들에 대한 것들을 보완해줄 수 있을 것 같아서 우선 도입 검토까지만 해두고 팀 전체적으로 조금 여유가 생기면 도입을 논의해볼 예정이다.
그 외 공통으로 만들어두고 사용할 유틸 클래스에 대한 정의나 특정 케이스에 대한 공통 처리 코드(?), 특정 업무에 대한 대응 프로세스 등을 하나씩 정리해가고 있다.

2. 올해는

올해는 연초부터 아주 뜻깊은(?) 업무를 하나 맡았었는데 바로 작년 말에 들어온 기획/개발 인턴 분들의 멘토링을 맡게 된 것이었다. 인사팀으로부터 미리 인턴분들에 대한 정보를 전달 받을 수 있었는데 다들 너무너무 스펙도 좋고 능력이 출중해보여서 사실 내가 멘토로 이분들에게 도움을 줄 수 있을지 많이 걱정이 됐었다. 그래서 괜히 내가 해보겠다고 했나 하고 살짝 후회도 하긴 했는데 결과적으로는 내 자신에게도 아주 좋은 경험이 된 거 같다.

평소 애매하게 알고 있던 지식들도 멘토링을 하며 한번 더 찾아보고 공부해보면서 다시금 기억 속에 새길 수 있었고 선배와 후배, 시니어와 주니어, 나이가 많고 적음을 떠나서 정말 개발자와 개발자 같은 동료들끼리 진행하는 업무라고 생각하고 코드 리뷰나 프로젝트 기획부터 설계, 개발까지 도움을 드리다보니 그분들에게서도 정말 배울 점들이 많았었다. 다들 어찌나 코드를 깔끔하게 잘 짜시는지 요즘 신입, 인턴분들의 수준이 상당히 높아졌음을 체감할 수 있었다.

그분들 입장에서는 큰 도움이 되었는지는 모르겠지만 그래도 무언가 하나라도 더 건져가셨으면 하는 마음에서 최대한 피드백도 빨리 드리고 이것저것 도움을 드리고자 해봤던 것 같다. 인턴십이 끝나고나서 아쉽게도 회사 사정으로 정규직 전환까지는 이어지지 못한 것으로 알고 있는데 인턴분들이 이 글을 보실 일이 있을진 모르겠지만 능력이 모자라서 안된게 아니라 다른 외적인 요인들로 인해 안된 것이니 너무 실망하지 않으셨으면 좋겠다.

가진 능력들을 보면 충분히 다른 더 좋은 기업들에 가실 수 있을 것으로 생각된다. 오히려 이렇게 능력 좋은 분들을 놓친 것이 회사 입장에서 악재라고 생각한다.

그 외엔 그냥 개인적으로 무언가 토이 프로젝트나 간단한 서비스 하나를 만들어보고 싶은데 아직까진 막 그렇게 구체화 할 정도의 아이템도 없고 상반기도 또 바쁠 예정이라 내가 할 수 있을련지 모르겠다…ㅎㅎ 우선은 그냥 해보고 싶다 정도의 생각만 가지고 있고 기회가 된다면 한번 구체화 해 볼 예정이다.

작년 말부터는 IT업계도 한창 불타오르다가 잠시 소강 상태가 되어 채용 시장도 찬바람이 불고 이름 있던 유명 스타트업이나 서비스들도 하나둘 문을 닫고 있는 상황이다. 다행히도 우리 회사는 어느정도 기반이 있는 회사라 당장 무너져내릴 정도는 아니지만 신규 채용 중단이나 비용 절감 등을 보면 그렇게 안심할 상태는 아닌 거 같기도 하다.

올해가 되면서 벌써 개발자로 일을 시작한 지도 5년 10개월 정도가 됐다. 조금만 더 지나면 6년이 되니 참 새삼스레 시간이 빠르단걸 느끼고 있다. 아마 상반기도 이미 진행 중인 업무들이 많다보니 시간이 금방 지나갈 거 같은데 올해 역시도 한단계 더 성장할 수 있는 해가 될 수 있으면 좋겠다. 물론 그만큼 나도 노력해야겠지만…^^