김승원

처음엔 Spring MVC의 스레드 풀 방식이 납득되지 않아 WebFlux를 도입했지만, 복잡한 구조로 인해 오히려 생산성이 떨어지는 문제를 겪었습니다. 이 경험을 통해 새로운 기술은 도입 자체보다 트레이드오프, 그리고 실질적 효과가 더 중요하다는 점을 느꼈습니다. WebFlux의 동작 원리를 깊이 이해하고 싶어 Project Reactor, Netty까지 학습했고, Redis/Lettuce의 Reactive Command 부분의 오픈소스에도 기여했습니다. 기술적으로는 큰 성장의 계기였지만, 무조건적인 비동기 구조가 성능 개선으로 이어지지 않는다는 현실적 인사이트도 얻었습니다. 단순히 새로운 걸 해보는 것을 넘어, 어떤 기술이 서비스에 어떻게 기여할 수 있을지 고민하는 태도가 개발자로서 더 중요하다는 걸 배운 프로젝트였습니다.

도메인 주도 설계를 처음 적용했을 땐, 책과 블로그에서 본 개념을 그대로 가져와 사용했습니다. 하지만 결과적으로 불필요하게 복잡한 구조를 만들었고, 팀원 간 소통에도 문제가 생겨 개발 초기 안정성이 떨어지는 아쉬움이 있었습니다. 이 경험을 통해 ‘기술을 도입할 때 무엇을 해결하고 싶은지, 서비스에 어떻게 기여를 하는지’를 먼저 고민해야 한다는 것을 배웠습니다. 이후에는 우리 팀의 개발 방식에 적합한 개념만 선별하고 단순화해 적용했습니다.또한, Gradle 멀티 모듈 구조를 도입할 때는 팀원들의 이해를 돕기 위해 개발 가이드를 직접 문서화하고 공유했습니다. 이 과정을 통해 기술의 난이도보다 팀이 함께 이해하고 유지할 수 있는 구조가 더 중요하다는 사실을 체감했고, 기술 도입의 관점을 실무적으로 바꿀 수 있었습니다.