[회고] 2022년

이번 년도는 작년에 들어온 팀원과 함께 특히 리팩토링 작업을 많이 진행했다. 기존에 작성된 Spring Boot 프로젝트를 좀 더 객체지향적이고 유지보수하기 편한 코드로 개선해보자는 것에 초점을 맞추고 진행했는데, 이 과정에서 책도 찾아보고 코드리뷰에서도 깨닫고 이전보다 많이 배운 것 같은 느낌이 들어 보람을 많이 느낀 해였다. 기존 프로젝트에 헥사고날 아키텍쳐를 도입했는데 외부, 내부 요소를 구분하기 쉬웠고 인터페이스 분리나 테스트 코드 작성 면에서 이용하기가 좋아보여서 장기적으로 헥사고날 아키텍처 설계로 개발하기로 정했다.

 

그리고 객관적으로 보았을 때 기존에 오래 계신 팀원분들은 아무래도 PHP에 익숙한 분들이라 Spring Boot 와 관련한 코드리뷰를 함께 진행하면 아무래도 한계가 있었다. 올해에 들어서서 이번에 들어온 팀원과 함께할 때는 성장에 관심이 많아 서로 대화도 잘 되어 내가 기존에 작성했던 코드들에 대해서도 다시 돌아보고 리팩토링을 하는 경우가 많은 해였다.

 

정책 서비스 연동 고도화

Fact

올해 초반에는 예전에 진행했던 정책 관리 시스템을 좀 더 많은 서비스와 실시간으로 연동되도록 하는 작업을 진행했다.

기존 레거시 시스템에서는 대부분 하드코딩으로 구성된 정책을 가지고 이용되는 부분이 아직도 많이 남아있어 그 부분들을 연동하는 작업을 진행했다. 이번에는 주로 백오피스와 관련된 작업들이 많았다.

 

Feeling

여러 명이 붙어서 한 번에 연동 작업을 마무리하고 싶었지만 팀 사정상 한계가 있어 계속 발목이 잡히는 것 같은 느낌이 들었다. 수정 작업 자체는 간단한데 검증 작업이 더 중요하기도 했고, 이 부분에 집중적으로 시간을 투자하다보니까 시간이 오래 걸리기도 했다.

PHP4로 작성된 기능들의 수정이 30% 정도의 분량을 차지했던 것 같은데 근본적으로는 PHP4를 사용하지 않도록 해야 할 것으로 보인다. 이 부분은 어쨌든 나중에 이전될 것 같았다.

 

Finding

처음에 기간이 어느 정도 걸릴지 알 수가 없어서 이번에 정책 항목별로 일정을 산정하여 대부분 1주씩 할당해서 진행했는데 조금은 줄여도 괜찮을 것 같다.

 

Future Action

어쨌든 남겨진 정책 항목들을 연동하는 작업을 마무리했다. 다른 정책 항목들은 길이 체크와 같은 유효성 검사 부분이긴 한데 우선순위가 낮았고 개발팀에서도 중요하다고 생각하지 않는 부분이라 당장은 진행하지 않는 것으로 결정됐다. 하지만 나중에 추가적으로 정책으로 관리해야 하는 부분이 생긴다면 추가 작업은 진행해야 할 것으로 보였다. 다만, 검증 작업에 일정을 다소 많이 잡은 것 같아서 다음엔 조금 줄여서 진행해야 겠다.

 

Feedback

기술적인 요소보다는 단순 연동 작업이 많아서 큰 어려움은 없었다. 또한 프로젝트 완료 후 적용하고 나서도 별 다른 이슈는 존재하지 않았다.

 

등록 체크 서비스 개선

Fact

사내에 DB 부하가 많은 서비스 중 하나였고, 외부에서 어뷰징하는 사람들까지 있을 정도로 요청하는 횟수가 많은 서비스였다. 특히 내부적으로도 DB를 조회하는 프로세스가 많아 DB Pool 을 지원하지 않는 PHP로 요청이 올 때마다 커넥션이 새롭게 만들어졌고, 오후 시간대에 샤크라맥스를 통해 현황을 파악하면 적어도 50개 이상의 DB 세션이 활성화된 것을 자주 볼 수 있었다.

 

전사 기준 모니터링으로 Oracle 세션이 평균 600개가 거의 active 한 상태를 유지했고 900개 정도의 세션이 맺어지면 장애가 나곤 했다. 기존에도 간헐적으로 장애가 나곤 했는데 작년 말에 페이스북 사명 변경으로 메타라는 키워드 때문에 10배 이상의 요청이 갑자기 들어와서 전사 장애가 났다. 근본적인 문제를 해결하기 위해서는 DB 접속 세션을 줄여야만 했는데 PHP로 해결하기에는 어려웠다.

 

Feeling

원래 업무 계획에는 없었지만 반드시 해결해야 하는 문제였고 이런 상황이 발생하면 회사 업무에 불일치건으로 다른 팀에도 사이드 이펙트가 계속 발생했기 때문에 더 이상 영향을 주면 안되겠다고 생각했다. 그래서 팀장님에게 본인이 직접 나서서 해결하겠다고 말하고 사이드 프로젝트처럼 개선 작업을 진행하려고 했다. 항상 팀 내에서 책임감있고 말보단 행동을 하려는 모습 덕분인지 팀장님도 이에 대해 신뢰하고 내게 프로젝트를 진행해도 된다고 긍정적인 모습을 보이셔서 조금은 뿌듯했다.

 

Finding

사실 PHP 이어도 sqlrelay 라고 하는 도구로 DB Pool 을 위한 환경을 따로 구성해서 프록시처럼 사용할 수 있는 도구를 발견했었다. 하지만, 정작 인프라팀에서 지원해주어야 가능한 것이었고, 개발팀에서 애플리케이션을 바꾸는 것만으로도 문제를 해결할 수 있는 상황이라고 판단했기에 Spring Boot 를 이용한 API 로 새롭게 만들기로 하면서 개발 작업을 진행했다.

 

기존 코드에서는 불필요한 로직이 너무나도 많았다. 특히, DB를 불필요하게 조회하는 코드가 많아서 이번에 작업하면서 불필요한 것들은 모두 삭제헀는데 커밋 이력을 보니 오래 전부터 존재했던 코드들이었고, 유지보수를 하면서 불필요한 로직들이 중간 과정에서 생기게 된 것으로 보였다.

 

검증은 예전에 판매가 계산 로직을 검증할 때와 비슷했다. 개발팀과 논의 후 트레이드 오프를 감안해 기존 로직에서 신규 로직 API 를 동시에 호출한 다음, 결과를 비교한 후 다른 부분이 있으면 Sentry 로 모니터링이 되도록 진행했다. 속도가 좀 느려지지만 항상 결과 값을 더 중요하게 생각한 결정이었다.

 

스테이징 환경에서 테스트를 진행했을 때 기존 로직에서는 응답을 받을 때 적어도 1초 이상이 무조건 걸렸지만, 신규 로직에서는 빠르면 300ms 까지 평균적으로 500ms 정도로 빠르게 응답을 가져오는 것을 확인할 수 있었다. 시행사가 얼마나 빠르게 응답을 가져다주느냐가 응답 시간의 대부분을 좌지우지하였지만 이 정도의 평균이면 양호했다. JMeter를 이용해서 100개 이상의 동시 요청에서도 DB 세션이 HikariCP에서 지정한 Pool 개수만큼 사용해서 이루어지는 것을 확인하였다. TPS는... 시행사 레이턴시 자체가 길었기 때문에 낮아서 큰 기대는 하지 않았지만 아쉽긴 했다.

 

Future Action

급한 불을 끄긴 했지만 적용해야 할 사이트가 아직 2개가 더 남아있다. 다행히 한 곳은 트래픽이 많이 없어서 괜찮지만 향후 과제로 작업해야 할 사항으로 남게 되었다.

 

Feedback

프로젝트는 크게 성공적으로 끝냈다. 해당 작업을 진행한 이후로 Oracle 부하로 인한 전사 장애가 한 번도 일어나지 않았고, 이사님은 프론트에 나타나는 등록 체크 결과가 눈에 띌 정도로 빠른 것을 보고 크게 만족하셨다.

 

JIRA 도입

Fact

팀에서는 직접 종이로 여러 장의 보고서를 출력하여 주 1회씩 모두 모여 지난 주에 어떤 일을 했고, 이번 주에는 어떤 일을 할 것인지 논의한다. 모두 Redmine 을 통해 프로젝트 일감을 각자 작성하고, 이 일감들을 취합해서 업무 보고서를 만들고, 출력하고, 직접 대면으로 만나서 회의를 한다.

 

하지만 몇 가지 불편한 사항이 있었다.

• Redmine 을 프로젝트 관리보다는 주로 보고를 하기 위한 용도로 사용하고 있었다. 좀 더 적극적으로 다른 기능들과도 함께 이용할 수 있으면 했다.
• Redmine 에서는 프로젝트와 SVN 저장소가 서로 연동되어 있어, 파일 commit 시 Redmine 일감에 자동으로 작업 이력을 남길 수 있었다. 하지만, GIT 으로 이전함에 따라 연동이 불편하여 어려워지게 되었고 이에 따라 작업자가 같이 이력을 남기는 경우가 거의 사라지게 되어 이슈트래킹 누락 문제가 있었다.
• 코로나 이후로 일일 업무 보고를 작성하도록 지시가 내려왔다. 회사에서 개개인들의 업무를 일별로 확인하기를 원했고, 회사 규모가 중견기업으로 성장함에 따라 감사로 인해 작업 기록을 남기는 것이 더욱 중요하게 되었다.

이런 이유로 프로젝트 관리 도구를 바꾸는 것도 괜찮을 것 같다고 생각했다. 우리팀을 비롯한 사내 팀들은 YouTrack, Jira, Confluence, Notion, Redmine 등 여러 도구로 프로젝트를 관리하는 방식이 다양했다. 그 중에서 개발팀에서는 Jira 를 선호했는데 그 이유는 아래와 같았다.

• 소규모 팀이기에 10명 이하이면 무료로 사용할 수 있다.
• 사내에서 공통적으로 Confluence 를 사용하는데 만약, Jira 와 연동하여 Confluence 문서 작성 시 Jira 에 작성한 이슈를 가져올 수가 있어 다양한 업무 활용이 가능하다.
• GitLab 에서는 Jira 연동 후 MR, Issue 내용 또는 댓글에 프로젝트 키 언급 시 바로 Jira 에 관련 GitLab 활동 내역이 등록되는 점이 있다.
• UI 가 좀 더 깔끔하고 직관적이었고, 대시보드나 필터 기능으로 각자 어떤 일을 하는지 출력할 수가 있다.

사내에 설치형 Jira 를 사용하고 있는 다른 팀이 있었는데 경영진에서는 비용을 들이고 싶지 않아 했고, 사업팀에서 10명 그 이상으로 팀원을 받지 않겠다고 답변을 들었으며, 설치형 Jira 는 Atlassian 에서 지원을 종료했기 때문에 결국 설치형이 아닌 클라우드형 Jira 를 바라보게 되었다. 기획팀에서는 보고만 할 수 있으면 어떤 업무 도구를 사용하던 상관없다고 답변을 받았다. 그렇게 해서 올해 4월부터 우리 개발팀에 내가 한번 해보자고 먼저 제안했고, 시험적으로 사용하면서 사용성을 검증해나갔다.

 

Feeling

처음으로 이런 관리형 업무를 하면서 굉장히 많은 부담을 느꼈다. 이사님 인상도 상당히 무서운 것도 있었지만 다행히 팀원들이 힘내라고 응원을 계속 해주었다. 서툴었지만 이사님에게 어떤 이점이 있는지를 가지고 설득하였고, 모두가 사용할 수 있도록 한번 바꾸어보라고 나에게 지시를 다시 내리시곤 다른 팀원분들에게도 협조를 부탁하셨다. 이 과정에서 나는 이사님에게 "사내에서 모두가 같은 도구를 사용하면서 관리하면 편하지 않을까요?"라고 물어봤는데 윗선에서 그렇게 하는 것이 상황상 쉽지 않다고 했다. 무엇이 문제인지 정확한 이유는 듣지는 못했지만, 정황상 자유롭게 사용하도록 하는 것 같았다.

 

Finding

개발팀 내에서 먼저 어떻게 할지 정하긴 했지만, 같이 사용할 기획팀과도 함께 프로젝트 이름이나 에픽 등을 어떻게 사용할 것인지 정했다. 특히, 나이가 드신 분들이 많다 보니 사용하는 방법을 가르칠 때에는 문서보다 직접 구두로 말하는 것이 상당히 효과적인 것을 알았다. 이 과정에서 대시보드나 필터 기능보다도 이전처럼 종이로 보고서를 직접 출력해서 진행하기를 더 선호한다는 것도 알았다. 이 부분에서는 내가 시간을 좀 투자해서 보고서 앱을 하나 만들어 해결했다.

그리고 Workflow 같은 기능으로 프로젝트 이슈 상태를 단방향으로 변경하는 것이 생각보다 괜찮다고 느꼈는데 의외로 다른 분들은 조금 불편해 하셨다. 이런 부분은 Workflow 에서 다시 이전 상태로 돌아갈 수 있도록 흐름을 추가해서 해결했다.

 

참고로 이번에 보고서 앱을 위해 Atlassian 에서 제공하는 Forge 라이브러리를 가지고 React 앱을 만들었는데 Atlassian 에서의 보안 때문에 그런지 개발하기 매우 번거로웠고, 사용성에도 제한되는 사항들이 많아서 불편했다. 이 부분은 문서로 미리 기록하지 않으면 팀원들이 나중에 수정할 때 쉽지 않을 것으로 보여서 문서로 작성해두었다.

 

Future Action

이번에 Jira 도입을 추진하면서 이사님에게 설득할 때 문서로 미리 준비해서 발표했으나 설명을 잘 하지 못했다. 중간에 말하실 때 목소리도 크셔서 그런지 도중에 위축되는 느낌을 많이 들었지만, 다행히 팀원분들이 정말 좋은 분들이셔서 주변에서 잘 설명해주고 독려해주었다. 이번 일로 서툴었지만 말을 전달하지 못한 나의 부족한 점을 알 수 있었다. 보통 이렇게 설득하는 자리가 없었으므로 천천히 말하는 연습이나 스피킹도 한 번이라도 미리 따로 연습해두는 것이 좋을 것 같다고 생각했다.

 

Feedback

이사님으로부터 매우 긍정적인 반응을 받았다. 오히려 반대하실 줄 알았는데 관리 도구보단 내가 만들었던 팀원들의 일일 업무 내용을 하나로 취합해서 보여주는 기능에 엄청 만족하셨다. 이전에는 팀원들이 사내 게시판에 각각 일일 업무 보고를 올리고, 이사님이 하나씩 들어가면서 살피셨는데 이번에 한 번에 다 볼 수 있어서 정말 좋아하셨다. 팀원들도 적극적으로 사용하는 모습을 같이 볼 수 있었다.

소규모 팀인 상황에서 다들 좋은 분들이었기에 가능했다고 생각했고 부담감도 많고 힘들었지만 보람있었다.

 

구매대행 자동화

Fact

2020년 중순, 2개월 동안 구매대행 상담 신청의 리뉴얼 작업을 한 적이 있었다. 당시에는 상담 신청 부분의 고도화를 진행했는데 이번에는 중개 사이트에서 판매하는 상품을 자동화를 통해 신청, 구매하고 바로 사용할 수 있도록 하는 작업을 진행했다.

 

Feeling

기획에서 요구사항이 사소한 것부터 계속 변경되었다. 심지어 프로젝트가 끝난 후에도 변경되었다. 사전에 심도있게 고려하지 않으신채로 기획안을 작성하셔서 그런지 오히려 내가 체크해야 할 부분들을 알려주는 사항들이 더 많았다. 예를 들면, 주문 페이지에 [환율정보 표시] 라는 부분이 기획서 안에 있었는데 정작 어떻게 보여주어야 할지를 구체적이고 명세를 하지 않은 부분들이 많았다. 이런 부분에서 하나씩 질문하고 답을 듣으면서 진행했는데 계속 이것이 반복되니까 힘들었다. 아쉬운 부분이었다.

 

Finding

이번 작업은 상담없이 고객들이 바로 구매하는 형태였으므로 신청서와 주문서를 동시에 생성해서 진행해야 했다.

상담할 때는 신청서만 받았는데 이번에 주문서도 같이 쌓아야 했었다. 주문서는 따로 API 로 호출하면 되었지만 신청서는 기존 PHP에 있던 로직이 다른 서비스 로직하고 같이 붙어 있어서 이번에 분리하게 되었는데 Spring Boot 환경으로 다시 제작했다. 기존 코드를 보면서 왜 유지보수와 확장성을 고려하면서 설계를 해야 하는지 다시 알 수 있는 부분이었다.

 

Future Action

이번에 팀 내에서 장기적으로 결제 후 상태 변경 분기 로직을 따로 빼낼 계획을 가지게 되었는데 앞으로 구매대행 뿐만 아니라 다른 서비스도 차후에 진행해야 할 것으로 보였다. 이번에 구매대행 작업을 진행하면서 이 부분을 먼저 작업한 케이스가 되었다.

 

Feedback

프로젝트가 완료된 이후에도 기획에서 요구사항이 계속 변경하면서 다른 프로젝트 일정에 영향이 갔다. 개발 작업은 당초 산정된 일정 안에 마무리했으나 변경 사항 때문에 2개월 간 더 길어지면서 팀원들로부터 힘내라고 듣던 프로젝트였다.

 

구 백오피스 이전

Fact

사내 백오피스 관리 페이지들은 주로 PHP4 로 작성된 부분이 많았다. Try-Catch 구문을 지원하지 않아 예외를 처리하기가 매우 힘들다 보니 코드가 If-Else 로 얼룩진 경우가 태반이었고, 예외 처리도 제대로 구현되어 있지 않아 오류 원인을 파악하기도 너무 어려웠다. 프론트와 벡엔드 또한 전혀 분리되어 있지 않아 다른 기능을 위해 확장하기 쉽지도 않았고 버전도 매우 낮아 composer 와 같은 의존 관리 도구를 사용하여 여러 오픈소스 라이브러리를 사용하기에도 어려웠다.

 

개발 환경 세팅도 쉽지 않았다. 각 파일마다의 include, require 가 상대 경로가 아닌 절대 경로로 사용된 것들이 많아서 경로를 다시 변경해주어야 했고, 오래된 파일의 경우 상용 서버에서의 직접 수정 기록이 남아 있어서 저장소와의 실제 코드가 서로 차이가 있는 것을 나중에야 인지하는 경우도 있었다.

 

ISMS 심사 인증으로 PHP 버전을 2023년까지 적어도 PHP5 이상으로라도 업그레이드해야 한다고 SE로부터 권고도 받았다. 이사님과 개발팀 의견에 따라 일부는 PHP 버전 업그레이드를, 일부는 Spring 으로 진행하게 되었다. 그래서 Spring Boot 와 Vue 를 이용한 새로운 백오피스 프로젝트를 저번에 들어온 신입이 설계하고 개발하고 있었는데 이 작업에 속도를 내기 위해 추가적으로 나도 투입되었다.

 

Feeling

프론트엔드는 Vue 로 작성되었지만 기본적인 기능만 알고 있어도 문제될 것이 없어서 딱히 어려울 것 없이 작업은 순조롭게 진행했다. Vue 를 알고 있었다면 더 좋을 것 같긴 했지만 당장 작업은 진행해야 해서 어쩔 수가 없었다.

 

Finding 

openapi-generator 를 이용하여 swagger 에서 뽑아내는 openapi 명세를 TypeScript 로 API 인터페이스를 자동으로 작성되도록 하는 스크립트를 이용해봤다. API 호출 부분을 개발자가 작성하지 않아도 자동으로 작성해주기에 편하게 이용할 수있어서 꽤 괜찮았는데 작업 시간도 줄일 수 있어서 인상 깊었다.

 

Future Action

이번에 리셀러 관련 기능들을 이전하는 작업을 진행했다. 아직도 옮겨야 할 기능들이 남아 있었는데 많지는 않아서 아마 나중에 신입이 들어오면 하게 될 것 같았고, 나중에 신입이 들어올 경우에 대비하여 개발 환경을 세팅하는 방법을 문서로 정리하는 것이 좋아보였다.

 

Feedback

이후에 버그 사항만 간간히 존재했고 백오피스에서 관리되는 부분이었기에 문제되는 부분은 없었다.