[회고] 2023년

이번 년도는 개인적으로 회사 프로젝트는 약간 아쉬움이 있었지만 나쁘지 않은 경험이었고, 취미 생활로 하는 악기 연주에서는 많은 사람들 앞에서 연주회를 2번이나 하였는데 주목도 받고 인기(?)도 많아져서 보람은 있는 해였던 것 같다.

 

회사에서는 2023년 처음부터 다른 팀으로 가서 내가 해보지 않은 경험도 해보고 싶다고 이사님에게 요청했었다. 팀 이동을 요청했고 결국 기다리라고 답변을 받았으나 1년이 지나도록, 2024년 현재 지금까지 아무 이야기도, 면담도 없었다. 연봉 협상도 원래부터 통보식이었으나 나 뿐만이 아닌 다른 사람들도 윗 사람과 같이 대면하는 자리조차도 없었다. 이번에 담당 임원이라는 제도가 생기면서 따로 개발 이사님에게 전달할 기회가 생겼었고, 이 기회를 통해 합리적인 이유를 들어 2024년에는 팀 이동이 확정되었다.

 

이번 해에는 크게 작업한 프로젝트 2가지가 있었다. 하나는 인터넷주소의 등록 및 연장 세팅 프로세스를 아예 갈아 엎어서 Spring을 이용한 애플리케이션을 만드는 것, 또 다른 하나는 지인이나 직원 및 VIP 고객 등의 할인 가격 관리 프로세스의 상품 체계 연동 작업이었다. 후자의 프로젝트는 DB 테이블을 새로운 테이블로 옮기고 기존 자동화 작업이랑 백오피스 연동된 것들이 있었기 때문에 수정을 또 거치고 검증도 해야 해서 결코 사소한 작업은 아니었다. 이 작업으로 사실상 나는 이 팀에서 취급하는 상품 체계를 내 손으로 설계하여 서비스 단에서 갈아 엎는 마지막 작업이 되었다.

 

개인적으로 아쉬웠던 것들은 항상 있었다. 우리팀을 포함해서 다른 팀의 어떤 서비스든지 Oracle DB에 너무 의존적이어서 API Aggregation같은 부분들이 많이 없었다. 모든 이유엔 기존 로직의 호환성이 따르는 부분이었다. 특히 도메인이 다른 부분에서 DB Join이 아닌 API를 통해 Aggregation 및 캐시화 등의 구현을 많이 해보고 싶었는데 프로젝트 우선순위로 보았을 때 이런 부분들은 당장은 작업에 들어가기 힘들 것 같아 보였다. 최근에 프론트 전시로 상품 노출하는 것들은 API 호출 시 Aggregation 후 Redis 이용해서 캐시화를 통해 성능과 트래픽에 대비하도록 구현했지만, 상품과 관련된 할인 가격 관리 기능이라던지 나머지 서비스와 관련된 기능들은 대부분이 PHP 기반으로 관리 기능이 구현되어 있고 DB Join으로 이루어져 있다 보니 MSA 측면에서도 이런 부분들에 대해 아쉬움이 항상 있었다. 아무래도 그만큼 트래픽이 높지 않아 자연스럽게 신경쓰지 않았던 것으로 보인다.

 

이번에 진행한 등록 및 연장 세팅 프로세스의 경우, 무언가를 등록하거나 연장하려면 인터넷주소를 관리하는 시행사를 무조건 통신으로 거쳐야 했다. 다만, 시행사별로 제공하는 기능의 이용하는 방식이 조금씩 비슷하면서도 달랐다. 사실, 국제적으로 이용하는 표준 프로토콜 방식이 존재하고 해당 프로토콜을 현재 사용을 하기도 하지만 어떻게 사용할 것인가는 시행사마다 조금씩 달랐다. 완벽하게 똑같은 것도 아니고, 국가에서 운영하는 경우는 성별이나 생일 등 개인정보를 추가적으로 받는 것도 있었다. 조금씩 다른 예외적인 부분이 힘들게 만들었다. 등록은 시행사에 그냥 등록만 하면 되는데, 연장은 대부분 시행사에서 환불도 안해주고, 시행사별로 방식도 다르고 만기일을 취급하는 방식마저 달라서 프로세스 설계 자체는 어렵지 않았는데 이런 도메인의 로직을 파악하고 검증하는 것이 쉽지 않아서 팀원분들과 기획분들에게 많은 질문을 했었던 것 같다.

 

팀장님은 보통 나에게 신중해야 하는 작업들을 주로 맡기셨다. 평소 프로젝트에 책임감을 가지고 진행했기 때문에 이런 모습이 만들어져서 신뢰감이 쌓인 것 같다. 지금까지 작업을 하면서 사고를 내지 않은 것은 아니지만, 이번에 이 프로젝트를 하면서 큰 사고를 낼 뻔 했다. 간단히 말하면 인터넷주소의 1년 연장을 더 하게 만든 것이다. 다행히 일부 제한적인 상황인 경우만 이랬던 것이어서 200개 정도의 도메인들이 대상이 되었으나 다행히 특히 일부 중에 일부인 환불을 해주는 시행사였기에 고비를 넘겼다. 이로 인해 비즈니스 로직에 대한 테스트 코드를 더 빡세게 작성하고자 하는 계기가 되었고, 실제로 이후로 더 작성하게 되었다. 의미있는 테스트 코드 작성이 역시 좋은 것 같다.

 

우리 팀에서는 주로 레거시 개선 작업을 할 때 한 번에 갈아치우는 방식이 아니라 하나씩 점진적으로 적용해나가는 방식을 따른다. 언젠가 다른 분들이랑 스터디하면서 인터넷을 찾아보다가 이런 방식을 스트랭글러 패턴이라고 하던데, 팀원분들은 대부분 야생형이라 그런 방식이 있다는 것을 몸으로 알뿐, 이런 용어가 있는지는 아마 모를 것 같았다. 시행사별로 적용을 천천히 해나가면서 진행했고, 운영실로부터 몇 가지 사소한 변경, 수정 요청들은 있었지만 다행히 크게 문제되는 부분들은 없었다.

 

다만, 한 가지 떠오르는게 있었다면 처음에 비동기로 세팅 요청을 전달하도록 구현했었는데 두 가지 이유로 모두 동기 방식으로 변경했다(...). 하나는 갑자기 시행사 중에서 특정 도메인을 더 우선해서 등록하면 Rebate를 해준다는 거였고, 다른 하나는 재무팀에서 가능하면 결제된 순서대로 해달라고 요청이 와서 요구대로 동기 방식으로 바꾸었던 것이 떠올랐다. 크게 이슈는 없어서 변경했고 문제는 일어나지 않았다. Rebate는 어느 정도 목표에 도달해야 해준다는 것 같던데 잘 될지는 지켜봐야 겠다.

 

할인 가격 관리 개선 프로젝트의 경우, 이벤트와 같은 할인 가격 보다는 정해져있는 고객들(지인, 직원, VIP)의 할인 가격을 개선하는 프로젝트였는데 이 프로젝트의 제일 핵심은 테이블 구조의 변경이었다. 할인 가격이라는 것은 어느 상품을 팔고 있을 때 그 상품의 정가보단 저렴하게 판다는 것을 의미하고, 할인 가격 데이터에는 해당 상품과 관련된 데이터가 있어야 한다.

 

그런데 문제점은 해당 상품과 관련된 데이터가 있다고 하면 상품 데이터의 인덱스를 가져다 쓰고 외래키로 Join 해서 쓰는 경우가 보통 일반적일 것인데, 원래부터 상품 체계가 없는 상태로 관리를 해오다 보니 아래처럼 상품을 구분하는 데이터부터 정규화되지 않은 상태로 관리되고 있었다는 점이다.

ID	KIND	PRICE	GROUP_ID
1	COM	11000	1
2	KR	22000	2
3	NEWGTLD_110000	132000	2

ID는 각 데이터 인덱스, KIND는 도메인의 끝 단어, PRICE는 VAT가 포함된 할인 가격, GROUP_ID는 할인 그룹의 외래키다.

서비스에서는 예를 들면 위의 KIND를 가지고 CO.KR, GO.KR 등을 전부 끝자리만 따와서 KR로 통합하여 전부 가격을 통일하며 사용하고 있었다. 혹은 시행사 이름을 넣거나 별도의 이름을 넣었다.

 

그런데 여기서 CO.KR, GO.KR로 가격을 분리해야 한다면 어떻게 해야 할까? CO.KR, GO.KR로 하나씩 데이터를 넣으면 좋겠지만 테이블에 들어간 해당 컬럼들의 값들 일관성부터가 우선 맞지 않고, 상품 체계가 도입되면 이는 나중에 데이터 중복이 될 수도 있다. 심지어 같은 KR이라도 시행사, 리셀러별로 분류하여 가격을 관리해야 한다면 어떻게 할 것인가? 이런 문제가 쌓이면서 아래처럼 구조를 변경하여 새로운 테이블을 만들었다.

ID	GOODS_ID	PRICE	GROUP_ID
1	1 (COM 등록)	10000	1
2	2 (KR 등록)	20000	2
3	3 (CO.KR 등록)	25000	2

GOODS_ID는 상품 테이블의 외래키, PRICE는 VAT를 제외한 할인가격이며 나머지 컬럼은 동일하다(실제로는 위에 나열한 컬럼보다 더 많다). 위의 KIND를 정규화를 거쳐 알맞은 상품의 외래키를 넣었다. 상품 테이블은 아래처럼 등록인지, 연장인지의 분류와 사이트, 각 도메인별 리소스 외래키를 가지고 조합하여 사용한다.

ID	SITE_NO	SERVICE_TYPE_NO	CATEGORY_NO	SELL_FLAG
1	2 (A 사이트)	1 (COM)	1 (도메인등록)	Y (판매)
2	24 (B 사이트)	4 (KR)	1 (도메인등록)	Y (판매)
3	2 (A 사이트)	2 (CO.KR)	1 (도메인등록)	Y (판매)

바로 위의 테이블의 ID를 가지고 초록색 테이블의 GOODS_ID로 외래키를 넣어서 관리하게 되면 상품을 가지고 할인 가격을 관리할 수 있게 되는 것이다. 위의 청록색 테이블을 초록색 테이블로 DDL을 바꾸기엔 이미 테이블에 들어간 데이터들의 일관성부터 맞지가 않고 나중에 원복할 때를 대비하여 새롭게 테이블을 만들어서 진행했다.

 

판매가 계산, VIP 선정 자동화, 백오피스쪽 비즈니스 로직 수정과 관리 페이지 개선 작업으로 큰 탈 없이 마무리를 했지만 검증을 하는데 힘들었고, 가끔씩 금액 불일치가 일어나는 건도 있었지만 팀원분들이 도와주셔서 어떻게든 해결도 되었다

 

기타 활동으로 신규 입사자 인턴들의 멘토링을 진행했었고 개발 이사님이 각 팀에서의 주요 벡엔드 개발자를 불러서 전사 차원의 API 응답 및 DB 컨벤션 관련 스터디, 라이브러리 개발을 해달라고 스터디 차원에서 요청이 내려왔다.

 

멘토링은 나를 포함한 6명의 멘토와 8명의 인턴들로 구성되었다. 프로젝트는 개인 단위와 팀 단위의 과제 두 가지를 내서 인턴들을 평가하게 되었고, 팀은 인턴들을 2그룹으로 나누어서 진행했다. 팀 단위 과제 아이디어 중 하나는 내가 떠올린 과제를 가지고 진행하게 되었는데 간단한 쇼핑몰을 만들어보라는 과제였다. 우리 팀은 어느 정도 프론트엔드를 다루기는 하지만 평가에서는 비중을 제외하고 참고 용도로 보았고, 벡엔드는 완성과는 별개로 어느 정도까지 진행할 수 있을지만 알고 싶었다. 실무에서는 사실상 On-Premise 기반이고, 자유롭게 인프라를 구성해서 하는 경우가 없기 때문에 인턴들이 과제를 할 때는 이런 부분에서는 자유롭게 할 수 있도록 서버를 지원해주면서 지켜 보고, 평가하여 신입 1명을 더 뽑게 되었다. 이번 인턴들은 Spring을 가지고 만들도록 해주었는데 멘토링이라는 것 자체가 멘토부터 뭔가 배경지식을 알고 있어야 멘토링이 가능하다 보니 스스로도 좀 더 공부하게 되는 경험이 되었다.

 

컨벤션은 나를 포함하여 총 5명의 벡엔드 개발자들이 모여 서로 팀들이 사용하던 API 이용 사례를 공유하고 REST API를 사용할 때 QueryString 은 어떻게 사용할지, 응답 포멧은 어떻게 쓸지, 네이밍 컨벤션은 어느 유형으로 사용할 것인지 정했다. 특히, 인상 깊었던 것 중 하나는 QueryString의 경우 Strapi나 jsonapi에서 보이는 필터 형식을 채택했다. 프론트엔드 개발자가 API를 다룰 때 어떤 파라미터인지, 어떻게 처리되는 파라미터인지 알 수 있도록 했다. 워낙 이런 것에 관심이 많았던 친구들이 서로 모여서 그런지 컨벤션 정하는 속도는 제법 빠르게 진행되었다. 단지, 함께 이걸 정하면서 항상 생각했던 것은 우리가 이걸 정하고 난 후에 사람들이 과연 잘 따라줄지가 제일 걱정이었고 의문이었다. 이번에 발표를 하면서 정작 개발 이사님들은 아무도 안 오시기도 했고, 결국 나중에서야 개발 이사님들 중 단 한 분이 제일 깊게 관심을 보이시면서 마무리가 났다. 라이브러리 개발은 내가 주도적으로 만들어서 진행했는데 개인적인 만족도는 한 70% 정도가 되는 것 같다. 나머지 30%는 내가 이걸 만든 후 관리가 잘 될까, 기여는 잘 해줄까 정도의 생각이 자리잡아서 그런 것 같다.

 

개발쪽은 AWS와 Reactor 쪽으로 공부를 해봐야겠다. 회사에서 클라우드 사업을 하고 있기에 퍼블릭 클라우드를 지원해주지 않아 항상 아쉬움이 많았는데 이번 기회에 자격증이라도 딴다는 목표로 한번 도전해봐야 겠다.

 

일상에서는 취미로 피아노에 집중했는데 어쩌다가 선생님들 사이에서 연습쟁이로 불리게 되었다(...). 사실 나는 피아노를 치는 것 자체가 좋아서 사람들과의 대화보다는 그냥 피아노에 집중해서 내가 치고 싶은 곡에 집중했을 뿐인데, 나중에 대화를 하게 되면서 알고 보니 대부분의 사람들은 잘 연습을 하지 않았던 것 같아 보인다. 퇴근하고 나서 집에서도 밤 늦게 디지털 피아노로 연습하고 업라이트 피아노로는 주말에 학원으로 가서 2시간 정도 연습하며 지냈다.

 

학원을 다니면서 선생님으로부터 연주회에 계속 나가보라고 권유하셔서 여름과 겨울 총 2번 연주회에 참가하게 되었다. 연주회는 분기마다 진행되었는데 여름에는 원령공주의 [아시타카와 산]을 연주했고, 겨울에는 애니메이션 에이티식스에서 등장하는 사와노 히로유키의 [Avid]를 연주했다. 연주회에서는 학원 로비에 있는 그랜드 피아노를 가지고 연주하는데 연습할 때도 느꼈지만 그랜드 피아노는 디지털 피아노와 업라이트 피아노와는 느낌이 정말 달랐다. 멜로디가 쨍하게 들리는 연습방과는 다르게 큰 홀에서 연주하니 멜로디에 집중하지 않으면 잘 들리지 않는 것 같은 느낌도 들거니와 악보를 보는 것도 느낌이 달랐다. 여름에 처음 연주회에서 연주할 때는 이 그랜드 피아노에 익숙하지가 않아서 다리도 부들부들 떨리면서 패달 밟고, 실수도 좀 하고 그랬는데 두 번째 연주회 때는 남들 앞에서 그랜드 피아노 치는 것도 좀 해보고 그러니 많이 개선되었다.

 

특히 두 번째 연주회에서는 엄청난 환호를 받았는데 기분이 어떨떨했다. 매니저님이 사진도 찍어주시고 작은 포토로 따로 주시기까지 했다. 잊을 수가 없어서 현재는 컴퓨터 앞에 놓여있다. 유튜브에도 영상이 올라가기까지도 했다.

뒷풀이에서는 새로 오신 매니저님과 어쩌다가 함께 자리했는데 친해지고 싶다는 얘기는 둘째치고 나는 인생 처음으로 나를 존경한다는 소리를 들었다. 평생 잊을 수가 없는 기억이고 너무나 특별해서 친해지지 않을 수가 없었다.

이때 마침 연주회가 12월 말인가 그랬는데 한해가 조금 아쉽더라도 뭔가 보기 좋게 연주회를 끝내게 되서 그런지 보람있게 한 해를 보낸 것 같은 생각이 든 해였다. 2022년에는 사진도 많이 찍으면서 돌아다녔는데 올해는 사진은 많이 못 찍은 것 같다.