JOBKOREA X ALBAMON
보일러플레이트 도입기, 그런데 이제 KLiK을 곁들인
보일러플레이트 (a.k.a 자바표준 프로젝트) 도입기에 대한 그런데 이제 KLiK을 곁드린 이야기를 해보려고 합니다.
응답하라 1998
내용에 앞서 간략하게 잡코리아의 과거를 들춰 보겠습니다.
1998년 잡코리아, 2004년 알바몬 의 탄생시점만 해도 국내외 asp-classic asp.net 의 인기는 2024년의 spring의 인기가 우스울 정도였던 거 같습니다.
제가 잡코리아에 합류하게 된 2022년도부터 현재,
글로벌 시장에서 ASP.NET은 여전히 강력한 입지를 가지고 있었지만, 우리 서비스에 적용되어 있던 버전 4.x는 지원 종료(EOS) 상태에 있습니다. 이에 따라, 우리는 ASP.NET Core로의 업그레이드나 Spring과 같은 Java 기반 프로젝트로의 전환을 고려해야 했습니다.
Java 의 풍부한 생태계 및 시장의 트렌트에 맞춰 우리는 Java 전환을 선택하였으며, 2022년 알바몬 서비스를 마이크로서비스 아키텍처(MSA)로 전환하는 것을 시작으로, 점진적으로 전환을 진행하고 있습니다. 🏃🏻
표준을 만들어보자 a.k.a 보일러 플레이트
Java 전환을 효율적으로 수행하고, 개발 과정에서의 일관성과 협업을 강화하기 위해, 우리는 Spring 프로젝트에 대한 표준 가이드라인(a.k.a 보일러플레이트)을 정의하고 배포하였습니다.
이번 글에서는 “보일러 플레이트 프로젝트”의 구성부터 이를 적용한 첫 서비스 “KLiK 서비스 런칭”을 겪은 개인적인 회고에 대한 내용을 담아 보았습니다.
시작은 스터디
우리 팀은 한 달간 4인 1조로 보일러 프로젝트 구성을 위한 스터디를 진행했습니다. “.NET 개발 n년 + Java 개발 n년”, “Java 개발 n년”, “.NET 개발 n년” 등 다양한 경력을 가진 팀원들이 함께 모여 스터디를 진행하며, 각자의 기술적 도전과 러닝커브를 경험했습니다.
스터디 기간 동안 데일리 스크럼과 스프린트 회고를 포함한 애자일 방식을 채택했습니다. 이 과정에서 하루 동안 깊이 고민한 내용을 데일리 미팅에서 공유함으로써, 짧은 시간 내에 책임감을 가지고 문제에 포커싱 할 수 있는 동기부여가 되었습니다. 또한, 데일리 및 스프린트 회고 미팅을 통해 팀원들의 다양한 관점을 이해하며 더 좋은 해결책을 함께 찾아나갈 수 있었습니다.
업무적으로 교류가 적었던 팀원들과는 월간 회고를 통해 아이스브레이킹과 감정 회고를 진행함으로써 팀원들 간의 유대감을 키우는 좋은 기회가 되었다고 생각합니다. 🙌🏻
그런데 이제 KLiK을 곁들인
한 달간의 스터디 이후 저는 외국인 채용 사이트(KLiK) 신규 개발TFT로 투입되었습니다.
KLiK-TFT(이하 K-TFT)는 여러 팀에서 모인 TFT로 구성된 팀이었으며, 기획부터 운영 및 배포까지 총 11주(4월 말 ~ 7월 초) 만에 빠르게 진행된 프로젝트였습니다.
우리 팀 구성원들의 주된 역할 중 하나는 보일러플레이트에 대한 지식 전파였습니다. 프로젝트를 진행하며 틈틈이 문서화를 진행하며, 해당 프로젝트에대한 이해도를 더 높이는 시간이 되었던 것 같습니다.
이쯤에서 공감대를 높이기 위해, 보일러플레이트 구성에 대해 간단히 설명드리겠습니다. (이 글의 목적이 회고이므로, 해당 내용은 간략하게 소개하겠습니다.)
Modular Monolithic Structure
위의 러닝커브 그림에서 눈치채셨겠지만, 보일러플레이트의 핵심 키워드는 “Modular Monolithic Structure”입니다.
각 프로젝트에서 필요한 기능이 명확하지 않은 상황에서, 보일러플레이트를 구성하기 위해 Modular Monolithic 구조가 가장 적합하다고 판단했습니다.
모듈 분리의 이점은 코드 재사용성을 향상시키고, 확장에 용이하며, 특정 기능이나 서비스를 독립적으로 배포할 수 있게 한다는 점입니다. 이러한 이점 덕분에 새로운 기능을 더 빠르고 안정적으로 릴리즈할 수 있을 것이라는 기대 아래, 이 구조를 선택했습니다.
K-TFT를 진행하면서, 모듈 단위의 구조가 제공하는 이점을 직접 경험할 수 있었습니다.
프로젝트 진행 중에는 조직 구성의 변화에 따라, 물리적인 리포지토리 측면에서도 프로젝트의 분리 및 통합에 대한 필요성이 발생했습니다.
도메인 단위로 모듈화된 프로젝트 구성은 이러한 변화에 유연성을 제공하여, 효율적으로 문제를 해결할 수 있었습니다.
또한, 프로젝트에서 각 도메인이 독립된 데이터베이스 환경을 갖추게 됨에 따라, “공고/지원” 도메인에서 지원자의 “프로필” 스냅샷을 생성하는 로직 처리를 위해 Amazon SQS(Simple Queue Service)의 필요성이 생겼습니다.
이 문제를 해결하기 위해, 보일러플레이트에 미리 구성된 SQS 모듈을 활용하고 필요한 API 모듈에 의존성을 추가함으로써, “각 기능별 독립적인 모듈 설계”를 통한 “생산성 향상”을 경험을 할 수 있었습니다.
테스트 코드
프로젝트 분리 및 통합 작업에서 중요한 역할을 한 것은 바로 테스트 코드였습니다. 우리는 짧은 개발 일정에도 불구하고, 테스트 코드 커버리지를 70%로 설정하여 프로젝트를 진행했습니다.
프로젝트 분리 및 통합 과정에서는 CI 파이프라인을 통해 테스트 코드에 대한 Validation 을 수행했습니다. 이 과정을 통해 모듈이 분리되거나 통합될 때 리그레션 테스트를 실행함으로써 기능의 안정성을 보다 확실하게 보증할 수 있었습니다.
성능테스트
프로젝트 구성원분들의 많은 노력 끝에 마침내 성능 테스트 단계까지 도달했습니다. 👏
개발 및 운영 서버를 대상으로 k6 스크립트를 사용해 성능 테스트를 진행했습니다. 테스트 중에 최종단 전시API에서 공고API 호출 시 계속해서 Retry가 반복되는 문제를 확인했고, 전시API의 p(95) 시간을 기준으로 Resilience4j의 TimeLimiter 값을 조정하여 재시도 횟수를 줄이는 방식으로 문제를 해결했습니다. 또한, Database의 Timeout시간 및 HikariCp의 Connection Pool 최적화를 통해 애플리케이션의 안정성을 향상시켰습니다.
개인적으로 처음으로 참여한 성능 테스트였으며, 애플리케이션의 응답 시간, 처리량, 리소스 사용량 및 시스템의 한계를 파악하는 것뿐만 아니라, 시나리오 작성의 중요성, 모니터링 도구의 적절한 사용법, 그리고 인프라 설정과 관련된 많은 Lesson Learned 을 얻어 갈 수 있는 경험이었습니다.
마무리
정신 차리고 보니 스터디를 시작한 올 2월부터 지금까지 정신없이 달려왔으며, 현재도 KLiK 프로젝트를 진행한 회고를 작성하고 있지만, 현재는 전체 잡코리아의 Modernization을 위한 거대한 프로젝트에 투입되어 다음 달 첫 번째 모듈의 1차 오픈을 앞두고 있습니다. 🧑🏻🌾
아직은 썸네일의 심사위원(강레오) 앞의 참가자(최강록) 처럼 아직은 빠른 속도로 변화되는 낯선 문화 새로운 지식의 습득 약간은 정신이 혼미하지만, 개인적으로 좋은 기회를 얻었다고 생각합니다.
배울 점이 많은 동료들 사이에서 기술적 스킬뿐만 아니라 소프트 스킬까지 성장할 수 있는 환경이 마련되었다고 생각하며, 힘들지만 커리어를 발전시킬 수 있는 소중한 시간이 되었으며, 될 것이라고 생각합니다. 😎
