몇 해전에 새로운 버전의 ITSM을 개발하기 시작하면서 JPA 기술 도입을 두고 고민했던 내용을 이제는 한 번쯤 정리해야 할 시점이라고 생각했다. 비단 JPA뿐 아니라 Spring Boot, Thymeleaf, Kotlin과 같은 새로운 개발 기술이나 Git, Gradle, Slack, PR처리 등 새로운 업무 환경까지 상당한 변화를 시작한 프로젝트였기 때문에 고민되는 것이 한두 개가 아니었지만 가장 길고 심각하게 고민했던 부분이라 따로 기록을 남겨본다.

 

이 글은 기술적인 내용은 아니고 어떻게 보면 당연하고 일반적인 내용이지만 다음 기회에 새로운 기술, 환경, 프로세스에 대한 도입을 검토할 때 조금이나마 도움이 됐으면 하는 마음이다. 여기에선 기술적인 내용에 대한 설명을 덧붙이지 않는 것은 관련된 내용은 'JAVA', 'ORM', 'JPA' 등으로 검색만 해도 비슷한 글들이 넘쳐나는 상황에 하나 더 덧붙이는 건 별로 의미가 없어 보이기 때문이다.

 

 

1. ORM에 대한 갑을논박

 

ORM에 대한 검색을 해보면 정말 여기서 다시 얘기하고 싶지 않을 정도로 오랜 시간동안 많은 사람들의 많은 의견들이 쏟아져 나온다. 게다가 더욱 혼란스러운 점은 구구절절 옳은 말들이라는 점이다.

 

여기서 뭔가 딱 부러진 결론을 내는 것은 불가능하고 너무 많은 의견들을 접하면서 점점 혼란스러워졌다. 대표적으로 참고 삼아 [자바 ORM 표준 JPA 프로그래밍]을 쓰신 김영한님의 글로 추정되는 링크 하나 투척~ https://okky.kr/article/286812

 

 

2. 우리에게 중요한 것

 

2.1. 진입장벽 : 진입장벽… 이 높다한들 하늘 아래 뫼… 일까?

 

어떤 기술이든 진입장벽은 그 도입 여부를 결정하는 가장 중요한 요소이다. 개인적으로 스터디를 하거나 한번 써보고 싶은 마음에서라면 진입장벽이 높을수록 구미가 당기는 변태적인 성향이 있는 사람도 있겠지만 이게 업무적인 접근이고 다른 팀원들과 함께 해야 하는 것이라면 진입장벽이 높이에 따라서는 그 기술의 효과가 인정되어도 도입이 쉽지 않은 것이 사실이다.

 

JPA는 많은 사람들이 진입장벽이 높은 편이라고 입을 모아 말한다. 검토를 위해 살짝 들여다 보았을때도 쉬워 보이진 않았다. 말 그대로 ORM을 잘 쓰기 위해서는 Object와 Model에 대한 깊이 있는 사전 지식과 그 둘을 Mapping하는 개념적인 체계가 머리 속에 있어야 충분히 활용할 수 있을 것 같았다.

 

진입장벽이란 것도 사실 상대적인데 당시에 판단으로 우리 팀에서 도입하기에 진입장벽은 중상(中上)이라고 생각했다. 잘 자리잡기 쉽지 않을 것이고 시간도 오래 걸리리라 생각이 들었다. 이러한 점을 만회할 장점이 있는지 고민이 필요했다.

 

2.2. 제품 특징 : 우리가 만드는 제품/프로젝트의 특징에 맞는가?

 

당시에 새롭게 시작되는 프로젝트에서 만드는 제품은 기존 Zenius ITSM 시스템의 새로운 버전이다. 업무적으로 여러가지 특징이 있지만 Model과 관련되어서는 상대적으로 복잡한 구조라 할 순 없었고 극단적인 성능과도 거리가 좀 있다. 상대적으로 깔끔하고 명확한 모델링이 훨씬 더 중요하다고 판단했고 이러한 면은 JPA도입에 대한 긍정적인 입장을 가지게 했다. 쿼리와 관련되어서 수많은 간단한 작업들을 효과적으로 할 수 있을거란 기대감…

 

만약 만들려고 하는 제품이 특정 RDBMS에 의존적이거나, 혹은 인수인계나 유지보수가 어려울 정도로 비즈니스부터가 복잡한 형태라서 JPA를 쓰면서도 많은 성능 튜닝과 Native Query를 사용해야 하는 상황이거나 한다면 상황은 약간 달라졌을 것이다.

 

제품의 특징과 더불어 현재 프로젝트의 특성도 같이 살펴봐야 한다. 레거시 시스템의 업그레이드인지, 이번 프로젝트처럼 완전히 새 판에서 시작하는 게 가능한 상황인지… 새로운 제품을 만드는 프로젝트가 납기일이 정해진 프로젝트보다 나은 점은 그나마 초기 학습과 관련된 투입을 감안하기가 좀 더 수월하다는 점이다. SI같은 성격의 프로젝트라면 내부 고객뿐 아니라 상대방 고객도 설득해야 하는 문제점이 더 크다.

 

그런 면에서 이번 프로젝트는 JPA를 도입하거나 적용하기엔 괜찮은 상황이라는 게 결론이었다.

 

2.3. 조직/인력 구조 : 바로 우리가 쓰는 기술이다. 기술도 중요하지만 우리도 중요하다.

 

제목처럼 아무리 좋은 기술이라도 우리에게 맞냐는 게 결정적이다. 아래와 같은 질문들을 던져 보았다.

 

 

결론적으로 반반이었다. 우리 팀은 JPA에 대해서 아는 바가 거의 없는 상태였다. 게다가 지금이야 JPA를 사용하는 사람들도 더 늘어난 것 같고 우리 회사의 위상도 달라졌지만 당시의 우리 회사의 규모나 채용 형태를 봤을 때 관련된 개발자를 충원하는 것도 쉽지는 않을 것 같았다.

 

반대로 새로운 기술 도입에 대해서 강한 의지까지는 아니라도 긍정적은 자세를 가진 팀원과 초기 삽질에 대해서 어느 정도 감내할 수 있는 회사라는 것이 당시의 생각이었다.

 

그래도 반이 어디냐…는 게 최종 결론이었다.

 

2.4. 재미 : 그래서 땡기냐?

 

이성적이고 객관적인 여러 사실들을 매트릭스화해서 평가를 하면서도 스스로에게 던지는 마지막 질문은… 그래서 땡기냐는 거다. 모든 수치가 부정적인데도 끝까지 미련을 버리지 못하고 하고 싶은 경우가 있고, 모든 결과가 긍정적인데도 뭔가 하기 싫은 경우가 많은데, 결국 그것들은 결과로 이어지더라.

리누스 토발즈가 커널을 업그레이드할 때 가장 중요한 점으로 “얼마나 재미”가 있냐는 점이라고 얘기 했다는데, 우리는 그 정도 레벨의 개발자는 아직(!) 아니지만 우리에게도 “재미”는 가장 중요한 결정요인 중 하나이다.

 

스스로에게 물어보자. 재미있어 보이나? 그리고, 당시에 나에게는 무척 설레었던 일이었음을 고백해야겠다.

 

 

3. 염려스러운 점

 

3.1. 회귀본능

 

아직 익숙하지 않은 상태에서 개발을 진행하다 보면 도무지 JPA에서 왜 이런 쿼리를 만들어내는지 이해하기 어려운 경우를 종종 만난다. 혹은 익숙한 SQL이 머리속에서 막 떠오르는데 JPA로 적용하기 위해서 이런저런 삽질을 하다 보면… 아… 그냥 쿼리를 직접 짤까? Native Query도 Mybatis도 지원한다던데…

 

분명 이런 순간이 올 것이라고 예상했다. 공부를 하는 것도 좋지만 회사에서 업무로 일정에 맞춰 무언가를 만들어내야 하는 압박감은 따로 누가 주지 않아도 가지고 있는 것이니…

 

침착하자. 익숙하지 않고 힘들다고 나도 모르게 무언가 자꾸 길을 벗어나고 있는 건 아닌지 계속 주의 깊게 들여다 봐야 한다.

 

결론적으로 지금에 와서 돌이켜보면 초반에는 의도대로 생성되지 않는 쿼리들에 당황하긴 했지만, 약간의 삽질 후에는 왜 그런 상황이 발생되는지 알기가 어렵지는 않았다.

 

언젠가는 복잡한 통계나 로직 때문에 Native Query를 쓰게 될 날이 오겠지만 아직은 아니다.

 

3.2. 학습곡선

 

도입하려는 기술에 따라, 혹은 구성원의 사전 지식에 따라 학습곡선은 상당히 다양한 형태로 나타나는데, 평균적으로 JPA의 학습곡선은 전반적으로 경사가 아주 완만하다고 판단했다. 즉 도입 검토 시점의 진입장벽은 그 자체로 염려스러운 점이었다. 그 얘기는 수준을 일정수준 이상으로 끌어올리기 위해서 많은 시간과 노력이 팀 차원에서 필요하다는 얘기였고 필요로 하는 사전지식도 꽤 있을 듯 했다. 게다가 여러 가지 이유로 개인별로 나타나는 학습곡선도 많이 다르리라 예상했다.

 

뭔가 기막힌 해결책이 있으면 좋겠지만, 책을 구매해서 읽고 유료 강의, 무료 강의들을 공유하고… 서로서로 도와가며 공부하는 클래식한 정공법을 택했다. (그만큼 사실 효과는 기대하기 힘들다는 것도 알지만…)

 

지금 생각해보면 어떤 기술이나 프로세스든 누군가 소수의 인원이 먼저 출발해서 끌어줄 수 있는 형태가 되는 것이 제일 나은 것 같다. 서로서로 도움을 주면서 같이 커가는 모양새가 될 수 있을 듯 한데 우리는 그렇지는 못했고 모두가 공평(?)하게 모르는 상태에서 스타뜨~

 

JPA의 도입에 대한 학습곡선은 최종적으로 도입을 결정하는데 마지막까지 고민을 하게 했던 점이었다.

 

3.3. Mapper는 누가?

 

자, 우리는 Object도 Model도 이제까지 다 개발자가 했다. Object야 당연히 개발자가 만들어야 하겠지만 큰 기업에서처럼 DBA가 있거나 화면을 퍼블리싱해주거나 하지 않는다. 우리는 우리가 화면, 미들웨어, DB까지 직접 만들고 컨트롤 해왔다. 그게 좋은 것이냐의 문제를 여기서 얘기하자는 게 아니라 현실이라는걸 얘기하는 거다.

 

우리 팀원 모두가 JPA 초보이다. Mybatis를 사용하고 Spring을 사용해봤다고 하지만 ORM이나 SQL Mapper에 대한 심도있는 고민은 부족한 상황.

 

앞으로 JPA에서 Object와 Model은 그렇다고 해도 Mapper역할은 또 필요하지 않을까? 그런 가이드는 또 누가 해야 하나… 모든 개발자에게 알아야 한다고 말할 수 있지만 모든 개발자에게 팀에서 잘하는 메인이 되라고 하기엔 좀 애매한 영역이란 게 항상 있다.

 

프로그램의 오브젝트와 DB의 모델을 연결하는 Mapper를 잘 구성할 경험이 많은 개발자가 없다는 점은 학습곡선과 더불어 JPA 도입을 망설이게 했던 주요 고민이었다. 결론적으로 선임 개발자를 중심으로 착실히 스터디를 잘 해주었고 제품의 특성상 그렇게 복잡한 관계를 매핑할 일이 많지 않아서인지 초반에 몇 번 팀원들이 같이 머리를 싸매고 논의했던 것 외에 문제는 없었다.

 

 

4. 결론(현재까지는…)

 

도입 결정 후 꽤 긴 시간 제품을 만들고, 이제는 고객사에 납품도 하면서 기능을 계속 추가하고 있는 이 시점에서 돌아보면, 어떤 부분은 팀원들이 너무 잘해주고 있고, 어떤 부분은 전혀 예상하지 않은 형태로 진행이 돼서 난감한 경우도 있지만 전체적으로는 아주 만족하고 있다.

 

정확하게 측정을 하진 못했지만 쿼리를 직접 짜면서 개발을 진행하는 것보다 생산성 측면에서 확실히 나아졌다고 느끼고 있고 그 효과는 초반에 투입된 시간에 비례해 앞으로 더욱 더 기대된다.

 

만족하고 있다고는 했지만 여기서 만족이라는 게 성과나 기술적인 완성도에 대한 절대적인 만족은 아니다. 다만 아직 우리 제품에 대한 아쉬움을 가지는 것이 JPA 때문은 아니라는 점은 확실하다.

 

JPA가 유행에 따라 생긴 기술이라고 하기엔 너무 오래된 기술이지만 그래서인가 ORM 자체에 대한 흥미도 점점 더 해가고 있다. JPA도 ORM에 대한 가장 최근의 시도중 하나겠지만, 앞으로 어떤 식으로 발전해 나갈지, 그에 따른 개발 업무는 또 어떤 식으로 변화가 있을지도 궁금하고…

 

어쨌든, 지금으로서는 다시 돌아가진 않을 생각이다.