2022년 회고-1

드디어. 언젠가 한 번 써야지하고 미뤄만 두던 회고록이다. 2022년 회고치고는 조금 늦은 감이 없지 않아 있지만, 늦었다고 생각한 때가 가장 빠른 때라고 하니, 용기를 내서 작성해 보기로.

Abstract

돌아 보니 참 정신 없던 한 해였다. 추리고 추려서 세 줄로 요약하자면.

1. 백엔드 개발자가 되었다. 그리고 팀장을 해 봤다.
2. 이직했다. 새로운 회사에 둥지를 틀었다.
3. 2번의 이사를 했다. 연어마냥 본가로 돌아왔다.

1Q

병아리 백엔드 개발자

TF 마무리

2021년 5월부터 합류했던 유통이력 관리 및 제품 인증 서비스를 위한 블록체인 플랫폼 개발 프로젝트 TF가 종료되었다. 블록체인 플랫폼에서 제공할 수 있는 AI 서비스를 개발하는 TF였는데, 1월 말 최종 보고서 작성, 2월 말 국내 특허 출원 및 3월 초 미국 특허 출원을 기점으로 프로젝트를 마무리했다.

백엔드 개발을 경험해 보고 싶어 적극적으로 참여했다. Python 기반으로 Flask를 이용해 간단하게 개발했는데, 당시까지만 해도 실제 서비스를 개발해 본 경험이 전무했기 때문에, 누군가가 사용하고 있다는 사실만으로도 재미나게 일할 수 있었다. 말로만 듣던 Tibero도 써 보고? 정부 과제여서 이용자가 많지는 않았지만, 종종 이슈 혹은 추가 기능 개발 요청이 있었는데, 그 때마다 TF 팀원들과 열띤 회의를 했던 것도 기억에 남는다. 회의의 과정 속에서 문제를 어떻게 정의해야 하는지, 문제를 풀기 위한 대안을 어떻게 선택해야 하는지 많이 배웠다.

결과적으로 대규모 서비스는 아니었지만, 개발부터 이슈 대응, 문서 작성까지 이것 저것 다 경험해 볼 수 있었던 프로젝트여서 기억에 남는다. 정부 과제였다 보니, 회사 차원에서 정부 과제를 어떻게 진행하는지도 어깨 너머로 볼 수 있었고. 아래는 지금 보니 꽤나 근사해 보이는 시스템 구조도(위)와, AI 모델 시각화 결과(아래).

로그 모니터링 시스템 배포

2021년 말, 백엔드 개발 팀으로 옮긴 후 처음으로 담당한 업무다. 2022년 1월, 본부에서 사내 직원들을 대상으로 사내 카페에서 이용할 수 있는 간편결제 앱을 배포했는데(간편결제 앱과 사내 카페 POS 시스템의 연동이 서비스 차별점이었으며, 기존에 나는 POS 시스템 프론트엔드 개발 팀에 있었다.), 배포를 앞둔 시점에 모니터링 관련 진행된 작업이 많지 않아 로그 모니터링을 할 수 있도록 대시보드를 만들어 보겠다며 호기롭게 자원해서 진행한 프로젝트였다.

ELK stack을 이용했다. Spring으로 개발된 간편결제 앱에서 나오는 로그를 Logstash를 이용해 정제한 뒤 Elasticsearch로 전송하고, Kibana로 시각화하는 방식이었다. 당시 나는 Java와 Spring을 잘 모르던 상태였기 때문에, 다른 팀원이 AOP를 적용해 모듈별로 발생하는 로그를 모아 TCP로 Logstash에 전송해 주면, 그 뒤부터의 처리를 맡았다.

이 때를 돌이켜 보면, 너무 많은 삽질을 했다는 것밖에 기억이 나질 않는다. ELK stack 각각을 Docker container로 띄웠는데, Docker가 뭔지도 잘 모르는 상태에서 컨테이너 간 네트워크 연결을 하고, 세 개의 컨테이너와 Spring 어플리케이션이 연동되도록 하는 것이 쉽지 않았다. 배포는 그보다도 어려웠는데, 간편결제 앱이 배포되는 사내 클라우드 환경이 K8s이다 보니(엄밀히는 K8s를 wrapping했다고 해야 하나..), K8s 환경에서도 각 스택이 동작할 수 있도록 각종 매니페스트 파일을 작성해야 했었다.

로그 대시보드를 만드는 것도 어려웠다. Elasticsearch 쿼리에 익숙하지 않다 보니 대시보드를 만들기 위해 필요한 데이터를 쿼리해 오는 것도 힘들었고, Kibana도 처음이다 보니 interactive한 대시보드를 만들지도 못했다. 개발자 입장에서 보기 편한 대시보드가 무엇일까 고민을 많이 했는데, 머릿속에서 그려지는 것만큼 근사한 결과가 나오지는 않았다.

그래도 어려움이 많아서였기 때문인지, 팀원들과 빠르게(?) 친해질 수 있었다. 로그를 어떻게 정제해야 할지, 컨테이너 오류를 어떻게 해결해야 하는지, yaml 파일 어떻게 써야 하는지, 여기 저기 열심히 물어보고 토론했었다. 결과적으로 아래는 그 결과물. 뭣도 없지만 예쁘다고, Kibana 고수라고 기를 세워준 팀원들에게 이 자그마한 자리를 빌려 소소한 감사를…

기타

그 외에 다음의 것들도 열심히 했었다.

• Java 공부. Python, Javascript 밖에 접해 보지 못했기 때문에, 솔직히 조금 어려웠다.
• 쿠폰 시스템 설계. 회사는 1년 가량 다녔지만, 백엔드 개발자로서는 신입이었기에, 신입의 마음가짐으로 Java, Spring 공부하면서 토이 프로젝트로 쿠폰 시스템을 개발해 보려고 했다. 근데, 보면 볼수록 DB 스키마가 복잡하더라. API는 더더욱.
  • ‘간단하게 생각하자’ 하다가 ‘아니 근데 이것도 고려해야 하지 않나? 이거는? 저거는?’ 하면서 결국 포기했다. 그런데 최근 이종립 님의 더 나은 쿠폰 서비스 아이디어 기록 를 보다 보니, 당시의 내 상황이 꼭 ‘급하게 만든 쿠폰 서비스’에 등장하는 상황과도 닮아 참으로 웃펐다.
  • 여담이지만, 그냥 아주 간단하게라도 해 봤으면 어떨까 싶다. 너무 생각이 많아서 시작하지 못한 게 아쉽다.
• 면담(…). Tmax의 꽃이랄까. 잔다르크가 되어야 한다(…)는 숙명과 함께 입사 후 4번째 면담을 했는데, 결과는 좋았지만 정말 힘들었었다.
• 스터디. 회사 사람들과 K8s 스터디와 Java 스터디를 했다. 자료를 좀 더 잘 정리했더라면 하는 아쉬움이 남는다.

2Q

회사의 방향과 달라 서비스로 출시하지는 못했지만, 이것 저것 열심히 백엔드 찍먹

미디어 서비스 개발

사내 서비스에 사용될 정적 미디어 파일 서빙을 위한 서비스를 개발했다. 웹 서버에 파일 업로드, 다운로드, 삭제를 진행할 수 있는 CGI 스크립트를 작성하는 방식으로 개발했는데, CGI 공부해 봐서 궁금한데 제가 해볼래요하고 시작한 프로젝트였다. 아주 오랜만에 블로그 글을 남기기도 했다.

Nginx에서 CGI 방식으로 Python 스크립트를 실행시키는 것이 어려워 애를 먹었던 기억이다. 대부분 스크립트 실행 권한 관련 문제였는데, 리눅스 사용자 및 권한에 대해 제대로 알지 못한 채, 에러가 발생하면 표면적으로 해결하기 급급했다. 이 에러 해결하고 나서 알고 보니 권한 문제, 저 에러 해결하고 나서 알고 보니 권한 문제, 이런 식이었다. 그 때는 왜 이렇게 참고할 만한 문서가 없는가 답답해 했었는데, 지금 생각하니 당시 내가 구글링하던 키워드도 방향이 맞지 않는 것이었다. 어쩌면 그냥 리눅스 권한과 네트워크에 좀 더 익숙했다면 쉽게 해결할 수 있었던 것이었다.

과정이 어찌 되었든 팀을 옮기고 나서 처음으로 서버실에 배포한 서버였다. 감사하게도 리뷰 서비스 담당 팀원 분이나 본부 다른 팀원 분들이 적극적으로 사용해 주셨다. 덕분에 성능 테스트란 것도 해봐야 겠다 싶어 jmeter를 이용해서 부하 테스트도 진행해 봤는데. 결과는 그다지 좋지 못했다. 해본 것에 의의를. AWS S3가 얼마나 잘 만들어진 서비스인지 느낄 수 있었던 시간이었다.

경로 탐색 서비스 개발

간편결제 앱 사용자로부터 가맹점까지의 경로를 안내하기 위한 서비스를 개발했다. 이상적으로는 경로탐색 알고리즘을 구현해야 하지만, 세상에는 오픈소스가 많으니, 네이버 지도 주니어 개발자도 사용한다는(DEVIEW 2020 기준) 오픈소스 경로탐색 엔진 OSRM을 이용하기로 했다.

API 자체는 많지 않았고, DB도 필요 없는 아주 간단한 서비스였다. 입력으로 사용자 위도, 경도, 가맹점 위도, 경도를 받아서, 출력으로 소요 시간과 거리를 반환해 주는 단순한 API 하나일 뿐이었는데. Spring 어플리케이션에서 JNI를 이용해 C++로 작성된 OSRM 라이브러리를 호출하는 것이 상당히 어려웠다. 과장 없이 OSRM 엔진 빌드하는 데에만 일주일, JNI 사용법 익히는 데만 일주일 걸린 것 같다. 특히 JNI 관련해서는 도저히 도움을 구할 곳이 없어 아주 용감하게 본부장님에게 도움을 청하기도 했다.

그래도 어찌 저찌 만들어 내고 나니 너무 뿌듯했다. 테스트 성공하고 나서 날아가는 줄 알았다. 그 후에는 서비스를 확장해 보고 싶어서, 사용자가 여러 곳의 가맹점까지의 위치를 조회하는 API도 만들어 보려고 했다. 그리고 이 과정에서는 다건 조회 시 일부는 성공하고 일부는 실패하는 경우 사용자에게 어떻게 응답을 주어야 하는지 고민했었다. 주변 팀원들과도 많이 이야기 해 봤는데, 하나만 실패해도 다 실패한 것으로 본다는 의견도 있었고, 실패한 것은 실패한 대로 두고 성공한 것만 반환한다는 의견도 있었다. 어떻게 설계할 때 더 좋은 서비스가 될 수 있을지 고민해 볼 수 있던 시간이었다.

기타

그 외에 이것들도 했다.

• Spring, JPA 공부. 김영한 님의 인프런 강의와 백기선 님의 유튜브 동영상을 자주 봤다. 대단하신 분들..
• 3차례의 세미나. 주제는 미디어 서비스 개발 과정, 미디어 서비스 부하테스트 결과, 경로탐색 엔진 OSRM의 경로탐색 알고리즘.
• 스터디. 회사 팀원들과 Java 스터디(나름 Effective Java로 진행된 심화 코스였다..!), 클린 아키텍처 스터디를 했다. 다만, 스터디를 하면서도 클린 아키텍처가 무엇인지는 풀지 못한 의문으로 남았다.