백기선 : 현재 개인적으로 관심 있는 어떤 기술이나, 방법론이나... 그런 거 없을까요?
박미정 :...(중략) 어떤 기술이나 방법론을 특정 짓기보다..... (중략) 저는 마이크로서비스 아키텍처나 모놀리식 그런 용어를 별로 중요하게 생각하지 않아요. '우리 MSA 해야 돼! ~~ 해야 돼!' 시작이 그게 아니고.. '우리가 어떤 문제를 갖고 있는데'이어야 되거든요..
* 유튜브 백기선 채널 박미정 님 인터뷰 Ep3 (링크 : https://youtu.be/tPOudSNxi8E?t=281)
현재 무신사 개발팀장으로 계신 박미정 님이 백기선 님의 채널에서 몇 년 전 진행한 인터뷰의 일부이다.
최근 훌륭한 개발자들과 인터뷰할 일들이 많아지면서 유튜브와 같은 SNS 채널을 통해서도 개발 리더들의 의견들을 챙겨보고 있다.
'난 저런 거 써본 적 없는데, 뭐부터 공부해야 되는 거지'
한때 유니콘기업들의 채용공고들을 볼 때마다 느꼈던 점이다. 예를 들어보자.
몇 년 전부터 시작된 MSA에 대한 유행은 여전하다. 기업들의 채용공고 우대사항에는 'MSA를 경험하신 분, MSA로 전환을 해보신 분,....' MSA 언급이 즐비하다. 또 비슷한 예로 JPA가 있다. 과거에는 국내에 JPA 도입 사례가 없다시피 하고 책도 유명한 책 한 권으로 공부했었는데, 이제는 많은 회사들이 JPA로 전환했는지, JPA가 하나의 기술 셋 레벨로 언급되는 공고들도 많다. (개인적으로 JPA는 툴에 불과할 뿐 기술 stack이라고 불릴 만큼 엄청난 인터페이스인지 모르겠다. JPA를 잘 다루면 java 가 더 깔끔해지고 객체지향적이 되는 것에 동의한다)
여기까지 생각하면 난 개발자지만 내가 현재 실무에서 쓰는 기술들은 다 업계에 뒤쳐져서 사장되어 가는 기술들이고, JPA를 실무에서 써야 인정해 줄 거 같은데 마이바티스는 이제 쳐다보기 싫고, 한편으론 연차만 쌓인 것 같아 무엇이든 신기술을 공부해야 될 것 같은 생각이 든다.
새로운 기술을 공부하는 것보다 우선시돼야 하는 것은
장담컨대, 수많은 솔루션들이 당장 마이바티스를 JPA로 전환하는 것보다 다른 것을 더 먼저 해야 하는 상황이다. 지금 서비스가 장애가 나는 이유가 JPA가 아니어서인가? 마이바티스는 이미 충분히 상용 서비스에서 운용되어 왔다. 난 마이바티스 찬양론 자도, JPA 찬양론 자도 아니다. 내가 얘기하고 싶은 것은 마이바티스도 JPA도 그저 RDBMS에 접근하고자 하는 툴일 뿐 그 본질은 RDBMS와 RDBMS에 접근하는 웹 애플리케이션에 있다는 것이다.
마이바티스에서 직면하는 N+1 문제는 JPA에서도 마찬가지이다. JPA를 공부하기에 앞서 SQL 실행 계획 정도는 분석할 수 있는가? 테이블에 인덱스를 추가해서 SQL 성능 최적화를 이루어본 적이 있는가? 적어도 본인 기술 셋에 JPA를 적겠다면 JPA 메서드 작성하는 동시에 머릿속에서 쿼리문이 다 작성이 되어야 한다. 안 그랬다간 상용 환경에서 무수한 데이터 세례를 맞다가 디비 CPU는 가득 차 서버는 저세상을 가게 된다. JPA라고 해서 최첨단 신개념 문법의 SQL 질의를 날리는 게 아니라는 것을 알지 않는가.
MSA가 요즘 유행이라서 공부해야 하는 것이 아니다
시스템이 분산되어있지 않아서 배포 한번 할 때마다 모든 개발자가 신경이 곤두서고, 장애가 나고, 시스템 전체 롤백하고, 다운타임이 생긴다면 자연스럽게 이 컨텍스트들을 분산하고 싶어 질 것이다. 그럼 이제부터 이 방법에는 어떤 것들이 있을지 찾아보고, MSA의 개념을 맞이하고, 어떻게 전환하면 좋을지 방법론을 고민하면 되는 것이다.
개발자의 본질은 문제를 해결하는 일이라는 것
채용공고를 보며 MSA를 운용해 본 적 없는데, 어떡해야 하지 고민해 봤자, 회사가 당신에게 그것보다 더 궁금한 건 "어떤 문제를 직면했고 어떻게 해결했는가?"이다. 현재 재직하는 회사도 당신에게 성능 쩔어주는 메시징 시스템을 가진 아키텍처를 공부해서 도입하길 원하는 게 아니라, 현재 우리 팀이 직면한 과제를 해결해 주길 바란다. 내가 작성한 JPA는 걸핏하면 디비 CPU를 잡아먹는 쿼리만 날려대는데, 정작 본인은 노드 공부하러 간다고 정시퇴근하는 상황이라면 이 개발자를 '본인 역량을 위해 열심히 공부하는 좋은 개발자'라고 볼 수 있을까.
개발자가 가져야 하는 진짜 중요한 것은, (1) 어떻게 문제를 정의하고, (2) 문제 해결을 위해 어떤 옵션을 마련하며 (3) 논리적으로 최종 옵션을 선택하여 문제를 해결하는 것 이 3가지 프로세스를 우아하게 갖추는 것이다. 이 세 가지가 JPA, MSA, docker, Kubernetes보다 훨씬 중요하다. 이게 쩔어주는 개발자는 상황에 따라 아주 적절하게 JPA를 선택하고, MSA 전환을 고려해 낼 것이다. 기술은 도구에 불과하다 정말로.
자꾸 JPA를 예로 들어서 양심에 찔려 한 가지만 말하자면, JPA가 좋은 점은 개발자 편해서가 아니다. 왜 JPA가 아주 좋은 옵션이 되었는지를 생각해 보자. 개발자가 비즈니스를 작성하다 보니 주구장창 반복적으로 CRUD 쿼리들이 생기고, 이렇다 보니 객체지향적인 프레임 워크가 탄생하는 게 아니라 디비 테이블 지향적인 프레임 워크가 탄생한다. 여기서 탈피해서 자바 객체지향에 더 집중하고, 과거 수도 없이 반복되던 쿼리들로부터 집중을 조금이나마 더는 것이 옵션의 이유이다.
* 나중에 JPA 스킬이 완벽해지면, JPA에 대해 조금 다른 관점에서 바라보는 포스팅을 해보고자 한다.
난 어떤 문제를 직면했을 때 새로운 기술을 맞이해봤는가
- 토큰 기반의 사용자 인증
- 스프링 프로필과 젠킨스
- 저장 프로시저 걷어내기
- 생각 안 나지만 기타 등등
난 토큰이 좋아 보이고, 대세 같아 보여서 토큰을 쓴 것이 아니다. 내가 유지보수하는 시스템이 이원화된 서버 아래 세션 유지를 못하고 있었고, 독립된 세션 저장소를 구축하기에는 부담이 있어서 공부해서 적용한 것이 토큰이다. (당시 세션 클러스터링, 레디스 등을 고민했고 일정상 즉시 적용이 가능하다고 판단한 토큰을 적용했다)
매번 배포를 할 때마다 테스트 서버용 코드, 운영서버용 코드들을 주석처리해 가면서 배포했다. 당연히 이는 문제가 있다고 생각했고, 옆에 시니어분께 물어보니 스프링 프로필을 적용해 보라고 했다. 그게 스프링 프로필의 첫 만남이었다. 상용 서버에 직접 접속해서 쉘 커맨드를 작성하다 보니 실수도 몇 번 있었다. 이 배포작업을 자동화가 될 순 없을까라는 고민 끝에 젠킨스를 알게 되었고 도입했다.
프로시저를 걷어냈던 이유는 서비스가 운용될 때 빌어먹을 로깅하기가 너무 힘들어서다. 로깅을 하기 위한 테이블을 만들어서 로깅하는 프로시저를 프로시저 안에서 호출하고 있다. 또 하나의 이유는 형상관리다. PL은 우리 성실하신 개발자분들이 정성스럽게 패키지에 주석으로 달아주시는 것이 형상관리의 전부이다. 난 이 상용 환경에서 문제를 느꼈고 곧장 다음 개선작업에서 앞단으로 프로시저 로직을 가져왔다. 난 이 이유 외에도 몇 년간 프로시저 기반의 시스템을 바라보면서 PL은 지양하자는 확신을 가지게 되었다.
다시, 개발자는 문제를 해결하는 사람이다.
이 포스팅에서 언급한 몇가지 기술은 나의 개인적인 기호와 전혀 무관하다. JPA를 처음 접했을 때 너무 환상적이었고, 지금 신규 서비스를 내 맘대로 개발해 보라면 닥치고 JPA로 간다. 그러나 내가 하고 싶은 말을 전하기 위해 노골적으로 언급해봤다.
개발자가 문제를 해결하기 위해 MSA로 전환하고, 때로는 다시 모놀리식으로 돌아오고 이 과정들은 문제를 해결해 나가는 과정이며 그때마다의 선택들이 충분히 합리적이면 그만이다. 새로운 기술을 도입하고, 더 효율적이고, 트렌드에 걸맞은 기술을 사용하는 과정인 것도 맞으나 이는 그다음에 오는 것이다.
https://youtu.be/tPOudSNxi8E?t=281
댓글