카카오톡, Java App Server 리팩토링으로 가변 Context 10개→3개 축소 및 순환 의존성 제거

카카오톡 메시징 파트가 Java App Server의 레거시 코드를 리팩토링해 라이브 서비스의 성능 저하 없이 유지보수성과 테스트 용이성을 대폭 개선했다. 핵심은 과도하게 사용되던 가변 Context 클래스를 정리하고, 복잡한 서비스 간 순환 의존성을 끊어내는 것이었다.

가변 Context 클래스 축소

12주년을 맞은 카카오톡 메시징 서버는 로그인 상태, 채팅 참여 상태 등 다양한 상태를 담는 가변 Context 클래스가 10개 이상 존재했다. 이러한 클래스들이 서로 변수를 주고받으며 전역 변수처럼 사용되어 디버깅과 코드 이해를 어렵게 만들었다. 개발자는 Context를 파라미터로 전달하기보다 필요한 값만 명시적으로 받거나 리턴하는 방식으로 변경했다. 또한 DB 조회 결과를 Context에 캐싱하지 않고 루프 밖의 지역 변수로 처리하도록 수정했다. 그 결과 Context 클래스를 3개로 줄이고 수백 줄의 코드를 삭제하면서도 동일한 기능을 유지했다.

고차 함수를 통한 의존성 분리

스프링 기반 프로젝트에서 흔히 발생하는 순환 의존성(Circular Dependencies) 문제를 해결하기 위해 함수형 인터페이스를 활용한 고차 함수 방식을 도입했다. 기존에는 서비스 객체 간 필드 주입으로 강한 결합이 발생했으나, 이를 함수 의존성으로 변경했다. 예를 들어 ServiceA가 ServiceB에 의존하던 것을 ServiceB의 메서드를 Function 타입으로 전달받아 호출하도록 수정했다. 이 방식은 스프링 컨테이너나 Mockito 없이도 객체를 직접 생성해 단위 테스트를 수행할 수 있게 하며, JShell을 통한 빠른 코드 검증도 가능하게 한다.

코드 복잡도 관리

**Cyclomatic Complexity(CC)**와 NPath Complexity 지표를 활용해 코드 복잡도를 정량적으로 관리했다. 하나의 함수에 여러 책임을 부여하던 코드를 Extract Function 기법으로 분리하고, 중첩 조건문을 Guard Clauses로 변경해 가독성을 높였다. 다만 가독성 개선이 NPath 수치 증가로 이어질 수 있어, else if 구조를 명시적으로 사용하는 등 수치와 가독성의 균형을 맞췄다. 리팩토링 후 라이브 서비스에 반영했으나 운영상 성능 저하는 발생하지 않았다.