이 글은 필자 개인의 생각이 담긴 글이며, 틀린 내용이 있다면 언제든 말씀해 주세요 🙂
IT 회사에서는 서비스 규모가 커질수록 필요한 소프트웨어의 복잡도 역시 증가한다. 특히 단일 모듈로 시작한 프로젝트는 서비스 규모가 커짐에 따라 여러 한계를 드러낼 수밖에 없다.
내 경험에 비추어 보면 이런 상황에서는 멀티 모듈 구성이 효과적인 해결책이 될 수 있다.
B2C 서비스의 경우, 사용자가 많아질수록 늘어나는 트래픽을 감당하기 위해 멀티 모듈 구성이 필요하다.
트래픽뿐만 아니라 새로운 기술을 적용하기 위해서도 모듈을 분리하면 기존 기술을 손쉽게 대체할 수 있다.
또한, 도메인이 점점 세분화되고 코드량이 증가함에 따라 모듈을 분리해 과도한 역할과 책임을 방지할 수 있다.
B2B 솔루션에서는 고객사의 다양한 요구를 충족하기 위해 멀티 모듈 구성이 유용하다.
위와 같은 경험이 없더라도 왜 멀티 모듈을 공부해야 하는지 곰곰히 생각해 본 결과, 아래와 같이 정리했다.
회사에 투입되기 이전부터 프로젝트가 멀티 모듈로 구성되어 있는 경우.
현재 프로젝트가 단일 모듈로 관리하기 어려울 정도로 서비스 규모가 커진 경우.
멀티 모듈이 무엇인지 제대로 알고 싶고, 실제로 설계와 적용 과정을 통해 그 장점을 직접 체감하고 싶은 경우.
필자는 위 세 가지 중 일부가 겹치긴 하지만, 마지막 세 번째 이유가 가장 와닿아 이 글을 작성하게 되었다.
이번 글에서는 멀티 모듈이 무엇인지 개념을 살펴보고, 실제로 제가 어떻게 적용했는지, 그리고 그 결과 어떤 장단점이 있었는지 정리해보고자 한다.
2024 당근 테크 밋업 중 SERVER 파트에서 관심있는 세션들을 들으면서 인상 깊었던 부분들과 개인 생각을 간단히 메모하고자 이 글을 작성했습니다.
실제 세션 내용은 2024 당근 테크 밋업 에서 발표한 영상을 참고해 주시면 됩니다.
부제목: 확장성과 설정 가능성
발표자:
Julius(당근 - 운영개발팀 고객경험파트)반복되는 비슷한 코드 작업에 지치신 분, 더 효율적이고 생산적으로 일하고 싶은 모든 개발자에게 이 세션이 인사이트를 제공할 수 있길 기대합니다.
아래는 K6의 공식 문서 와 23년 2월 Tech 세미나 - 성능 테스트와 K6 도구 소개 영상에서 본 내용을 기반으로 정리한 글입니다.
K6 도구를 공부하게 된 계기는 접근성과 실용성 때문이다. IT 커뮤니티 동아리인 SIPE에서 스프링 퍼포먼스 트랙 이라는 주제로 나를 포함한 7명이 모였고, 여러 성능 테스트 도구 중에서 다수결로 K6가 선정되었다.
나는 현재 회사에서 nGrinder를 사용해 성능 테스트를 수행하고 있다.
하지만 nGrinder는 Jython/Groovy 기반의 스크립트 작성을 요구해, 이러한 언어에 익숙하지 않은 사람들에게는 복잡하게 느껴질 수 있다.
반면 K6는 간결하고 직관적인 JavaScript 기반 스크립트 방식을 제공해 누구나 쉽게 접근할 수 있다.
또한, K6는 사용자 친화적인 인터페이스와 효율적인 CLI 기반 환경 덕분에 새로운 사용자도 빠르게 적응할 수 있다.
Prometheus 같은 모니터링 도구와의 연동이 잘 되어 있어 성능 테스트와 모니터링을 통합적으로 수행할 수 있다는 점도 큰 장점이다.
K6 공식 문서가 잘 정리되어 있고, Github 기준으로도 다른 성능 테스트 도구보다 높은 star 수(26k)를 기록해 레퍼런스 자료가 풍부하다는 점도 마음에 들었다.
(참고로, nGrinder는 2k star에 머물러 있다)
이러한 이유들로 K6를 선정하게 되었고, 개념을 간단히라도 정리하기 위해 이 글을 작성하게 되었다.
성능이라는 개념을 공부하기 전에, 왜 이 개념과 관련 도구들이 필요하게 되었는지 궁금했다.
나는 아직 사용자 1000만 명 이상의 대규모 서비스를 개발한 경험이 없지만, 지금까지의 경험을 바탕으로 생각해보면 다음과 같다.
서비스 사용자가 증가할수록 트래픽 양도 함께 늘어나며, 서버가 이를 감당할 수 있는지 성능 테스트를 통해 확인하고 그에 맞게 대응하고 보완해야 한다.
성능 테스트는 다양한 상황에서 시스템의 안정성과 효율성을 확인하는 데 중요한 역할을 한다. 내가 생각하는 성능 테스트의 활용 사례는 다음과 같다:
서비스를 출시하기 전, 예상되는 트래픽의 양을 서버가 감당할 수 있는지 성능 테스트로 파악한다. 일반적으로 예상 사용자 수의 3배로 부하 테스트를 수행해 예기치 않은 트래픽 급증에도 대비할 수 있도록 한다.
기존 서비스를 운영하면서 선착순 이벤트 등으로 갑자기 트래픽이 몰릴 때 발생하는 병목 지점을 성능 테스트(예: 스파이크 테스트)를 통해 식별한다.
멀티스레드 환경에서 비즈니스 로직을 비동기 방식으로 처리할 때, 논블로킹 방식 등을 고려하여 성능을 개선하기 위해 응답 속도와 TPS(초당 트랜잭션 수)를 성능 테스트로 측정한다.
아래는 최근 내가 공부한 성능 개념과 주요 병목 지점, 그리고 성능 테스트에 대한 내용을 정리한 내용이다.
최근 내가 하고 있는 일이 너무 많아서 머릿속이 복잡해졌다. 그래서 생각을 정리하고자 2024년 3분기 회고 글을 작성하게 되었다.
지금 내가 생활할 수 있는 기반을 제공하는 회사가 무엇보다 중요하다고 생각한다. 그만큼 회사에 대한 애정을 갖고, 주어진 기간 안에 업무를 집중하여 정확하게 처리해야 한다고 믿고 있다.
최근에는 코드와 설계에 관심을 갖고, 관련 기술들을 공식문서/책/영상 등으로 공부하고, 예제를 만들어서 실험을 해본 뒤에 적용하는 식으로 진행하고 있다.
또한 기존 서비스의 백엔드 코드를 리팩터링하면서 유지보수하기 쉽게 개선하고 있다. 최근 읽고 있는 좋은 코드, 나쁜 코드 와 이전에 읽은 내 코드가 그렇게 이상한가요? 가 많은 도움을 주었다.
리팩터링에는 정답이 없다고 생각하지만, 적어도 팀원이나 제3자가 이전보다 쉽게 이해할 수 있도록 만드는 것이 중요하다고 본다.
비록 지금 회사에서 오래 일하지는 않았지만, 주도적인 자세가 중요하다는 점을 많이 깨닫고 있다.