반복영역 건너뛰기
주메뉴 바로가기
본문 바로가기
제품/서비스
EMS Solution
Features
클라우드 관리
AI 인공지능
서버관리
데이터베이스 관리
네트워크 관리
트래픽 관리
설비 IoT 관리
무선 AP 관리
교환기 관리
운영자동화
실시간 관리
백업 관리
APM Solution
애플리케이션 관리
URL 관리
ITSM Solution
서비스데스크
IT 서비스 관리
Big Data Solution
SIEM
Dashboard
대시보드
Consulting Service
컨설팅 서비스
고객
레퍼런스
고객FAQ
문의하기
가격
자료실
카탈로그
사용자매뉴얼
회사소개
비전·미션
연혁
2016~현재
2000~2015
인증서·수상
투자정보
재무정보
전자공고
IR자료
새소식
공고
보도자료
오시는 길
채용
피플
컬처
공고
FAQ
블로그
열기
메인 페이지로 이동
블로그
기술이야기
블로그
최신이야기
사람이야기
회사이야기
기술이야기
다양한이야기
카프카를 통한 로그 관리 방법
메모리 누수 위험있는 FinalReference 참조 분석하기
김진광
2023.10.12
페이스북 공유하기
트위터 공유하기
링크드인 공유하기
블로그 공유하기
[행사] 브레인즈컴퍼니 ‘가을문화행사 2023’
Java에서 가장 많이 접하는 문제는 무엇이라 생각하시나요? 바로 리소스 부족 특히 ‘JVM(Java Virtual Machine) 메모리 부족 오류’가 아닐까 생각해요.
메모리 부족 원인에는 우리가 일반적으로 자주 접하는 누수, 긴 생명주기, 다량의 데이터 처리 등 몇 가지 패턴들이 있는데요. 오늘은 좀 일반적이지 않은(?) 유형에 대해 이야기해 볼게요!
Java 객체 참조 시스템은 강력한 참조 외에도 4가지 참조를 구현해요. 바로 성능과 확장성 기타 고려사항에 대한 SoftReference, WeakReference, PhantomReference, FinalReference이죠. 이번 포스팅은
FinalReference를 대표적인 사례
로 다루어 볼게요.
PART1. 분석툴을 활용해 메모리 누수 발생 원인 파악하기
메모리 분석 도구를 통해 힙 덤프(Heap Dump)를 분석할 때, java.lang.ref.Finalizer 객체가 많은 메모리를 점유하는 경우가 있어요. 이 클래스는 FinalReference와 불가분의 관계에요. 나눌 수 없는 관계라는 의미죠.
아래 그림 사례는 힙 메모리(Heap Memory)의 지속적인 증가 후 최대 Heap에 근접 도달 시, 서비스 무응답 현상에 빠지는 분석 사례인데요. 이를 통해 FinalReference 참조가 메모리 누수를 발생시킬 수 있는 조건을 살펴볼게요!
Heap Analyzer 분석툴을 활용하여, 힙 덤프 전체 메모리 요약 현황을 볼게요. java.lang.ref.Finalizer의 점유율이 메모리의 대부분을 점유하고 있죠. 여기서 Finalizer는, 앞에서 언급된 FinalReference를 확장하여 구현한 클래스에요.
JVM은 GC(Garbage Collection) 실행 시 해제 대상 객체(Object)를 수집하기 전, Finalize를 처리해야 해요.
Java Object 클래스에는 아래 그림과 같이 Finalize 메서드(Method)가 존재하는데요. 모든 객체가 Finalize 대상은 아니에요.
JVM은 클래스 로드 시, Finalize 메서드가 재정의(Override)된 객체를 식별해요. 객체 생성 시에는 Finalizer.register() 메서드를 통해, 해당 객체를 참조하는 Finalizer 객체를 생성하죠.
그다음은 Unfinalized 체인(Chain)에 등록해요. 이러한 객체는 GC 발생 시 즉시 Heap에서 수집되진 않아요. Finalizer의 대기 큐(Queue)에 들어가 객체에 재정의된 Finalize 처리를 위해 대기(Pending) 상태에 놓여있죠.
위 그림과 같이 참조 트리(Tree)를 확인해 보면, 많은 Finalizer 객체가 체인처럼 연결되어 있어요. 그럼 Finalizer 객체가 실제 참조하고 있는 객체는 무엇인지 바로 살펴볼까요?
그림에 나온 바와 같이 PostgreSql JDBC Driver의 org.postgresql.jdbc3g.Jdbc3gPreparedStatement인 점을 확인할 수 있어요. 해당 시스템은 PostgreSql DB를 사용하고 있었네요.
이처럼 Finalizer 참조 객체 대부분은 Jdbc3gPreparedStatement 객체임을 알 수 있어요. 여기서 Statement 객체는, DB에 SQL Query를 실행하기 위한 객체에요.
그렇다면, 아직 Finalize 처리되지 않은 Statement 객체가 증가하는 이유는 무엇일까요?
먼저 해당 Statement 객체는 실제로 어디서 참조하는지 살펴볼게요. 해당 객체는 TimerThread가 참조하는 TaskQueue에 들어가 있어요. 해당 Timer는 Postgresql Driver의 CancelTimer이죠.
해당 Timer의 작업 큐를 확인해 보면 PostgreSql Statement 객체와 관련된 Task 객체도 알 수도 있어요.
그럼 org.postgresql.jdbc3g.Jdbc3gPreparedStatement 클래스가 어떻게 동작하는지 자세히 알아볼까요?
org.postgresql.jdbc3g.Jdbc3gPreparedStatement는 org.postgresql.jdbc2.AbstractJdbc2Statement의 상속 클래스이며 finalize() 메서드를 재정의한 클래스에요. Finalize 처리를 위해 객체 생성 시, JVM에 의해 Finalizer 체인으로 등록되죠.
위와 같은 코드로 보아 CancelTimer는, Query 실행 후 일정 시간이 지나면 자동으로 TimeOut 취소 처리를 위한 Timer에요.
정해진 시간 내에 정상적으로 Query가 수행되고 객체를 종료(Close) 시, Timer를 취소하도록 되어 있어요. 이때 취소된 Task는 상태 값만 변경되고, 실제로는 Timer의 큐에서 아직 사라지진 않아요.
Timer에 등록된 작업은, TimerThread에 의해 순차적으로 처리돼요. Task는 TimerThread에서 처리를 해야 비로소 큐에서 제거되거든요.
이때 가져온 Task는 취소 상태가 아니며, 처리 시간에 아직 도달하지 않은 경우 해당 Task의 실행 예정 시간까지 대기해야 돼요.
여기서 문제점이 발생해요.
이 대기 시간이 길어지면 TimerThread의 처리가 지연되기 때문이죠. 이후 대기 Task들은 상태 여부에 상관없이, 큐에 지속적으로 남아있게 돼요.
만약 오랜 시간 동안 처리가 진행되지 않는다면, 여러 번의 Minor GC 발생 후 참조 객체들은 영구 영역(Old Gen)으로 이동될 수 있어요.
영구 영역으로 이동된 객체는, 메모리에 즉시 제거되지 못하고 오랜 기간 남게 되죠. 이는 Old(Full) GC를 발생시켜 시스템 부하를 유발하게 해요. 실제로 시스템에 설정된 TimeOut 값은 3,000초(50분)에요.
Finalizer 참조 객체는 GC 발생 시, 즉시 메모리에서 수집되지 않고 Finalize 처리를 위한 대기 큐에 들어가요. 그다음 FinalizerThread에 의해 Finalize 처리 후 GC 발생 시 비로소 제거되죠. 때문에 리소스의 수집 처리가 지연될 수 있어요.
또한 FinalizerThread 스레드는 우선순위가 낮아요. Finalize 처리 객체가 많은 경우, CPU 리소스가 상대적으로 부족해지면 개체의 Finalize 메서드 실행을 지연하게 만들어요. 처리되지 못한 객체는 누적되게 만들죠.
요약한다면 FinalReference 참조 객체의 잘못된 관리는
1) 객체의 재 참조를 유발 2) 불필요한 객체의 누적을 유발 3) Finalize 처리 지연으로 인한 리소스 누적을 유발
하게 해요.
PART2.
제니우스 APM을 통해 Finalize 객체를 모니터링하는 방법
Zenius APM에서는 JVM 메모리를 모니터링하고 분석하기 위한, 다양한 데이터를 수집하고 있어요. 상단에서 보았던
FinalReference 참조 객체의 현황에 대한 항목도 확인
할 수 있죠.
APM 모니터링을 통해 Finalize 처리에 대한 문제 발생 가능성도
‘사전’
에 확인
할 수 있답니다!
위에 있는 그림은 Finalize 처리 대기(Pending)중인 객체의 개수를 확인 가능한 컴포넌트에요.
이외에도 영역별 메모리 현황 정보와 GC 처리 현황에 대해서도 다양한 정보를 확인 할 수 있어요!
이상으로 Finalize 처리 객체에 의한 리소스 문제 발생 가능성을, 사례를 통해 살펴봤어요. 서비스에 리소스 문제가 발생하고 있다면, 꼭 도움이 되었길 바라요!
------------------------------------------------------------
©참고 자료
◾ uxys, http://www.uxys.com/html/JavaKfjs/20200117/101590.html
◾ Peter Lawrey, 「is memory leak? why java.lang.ref.Finalizer eat so much memory」, stackoverflow, https://stackoverflow.com/questions/8355064/is-memory-leak-why-java-lang-ref-finalizer-eat-so-much-memory
◾ Florian Weimer, 「Performance issues with Java finalizersenyo」, enyo,
https://www.enyo.de/fw/notes/java-gc-finalizers.html
------------------------------------------------------------
#APM
#Finalize
#제니우스
#메모리 누수
#Zenius
#FinalReference
#제니우스 APM
김진광
APM팀(개발3그룹)
개발3그룹 APM팀에서 제품 개발과 기술 지원을 담당하고 있습니다.
필진 글 더보기
목록으로
추천 콘텐츠
이전 슬라이드 보기
디자이너를 그만두고 개발 일을 하는 이유
디자이너를 그만두고 개발 일을 하는 이유
브레인즈컴퍼니에는 5개의 개발그룹이 있습니다. 그 중 브레인즈 대표 제품인 Zenius EMS의 웹 개발을 총괄하고 있는 개발2그룹의 그룹장, 성준님을 만나봤습니다. 성준님은 학석〮사로 산업디자인을 전공했는데요. 디자인 전공자가 어떻게 개발그룹장을 맡게 됐을까요? 성준님이 개발 일을 하게 된 사연 그리고 다양한 팀이 모여 있는 개발2그룹의 일하는 방식 등에 대해 이야기를 나눠봤습니다. ---------------------------------------------------------------------------- Q. 안녕하세요, 성준님. 자기소개 부탁드립니다. 연구개발본부 개발2그룹 그룹장으로, Zenius EMS의 웹개발을 책임지고 있습니다. 브레인즈컴퍼니에는 2010년 12월부터 근무하기 시작해 현재 12년째네요. 브레인즈에 오기 전에도 주로 웹개발을 했고, 때에 따라 SI프로젝트 PM도 했습니다. Q. 전공이 산업디자인이라고 들었습니다. 디자인 전공으로 석사까지 하신 후 개발자로 전향하신 계기가 있을까요? 대학교 1학년 때는 디자인 전공이 아니었고, 당시 학부별로 신입생을 뽑아서 자연과학부로 입학했어요. 2학년 때부터 산업디자인을 해야겠다는 마음을 먹고 겨울방학 때 한두 달 정도 미술학원에서 드로잉의 기초적인 것들을 배운 후, 대학 3년과 대학원 2년 동안 산업디자인 공부를 했습니다. 당시에 사용자 인터페이스에 관심이 많았고, 석사 논문도 사용자 인터페이스가 주제였어요. 석사 2년차 때, 대우전자와 삼성SDS에서 근무하던 선배를 통해 입사제안을 받았습니다. 그런데 행운인지 불행인지 두 회사의 면접일이 같아, 한 곳을 선택해야만 했어요. 대우전자에 가게 된다면 제품 디자인을, 삼성SDS는 소프트웨어 개발 관련 디자인 업무를 할 수 있었어요. 저는 사용자 인터페이스와 같은 소프트웨어 개발 쪽의 디자인 업무를 하고 싶어 삼성SDS로 면접을 갔고 삼성에 입사하게 됐습니다. 당시 삼성SDS(前 삼성데이터시스템)는 SI 사업도 하고 삼성 그룹 계열사의 SM 업무도 했습니다. 또 하이텔, 천리안과 같은 유니텔이라는 PC 통신 서비스도 제공하고 있어서, 입사 전에는 유니텔의 GUI를 담당하거나 UI 관련 업무를 할 것이라고 예상했어요. 그런데 제가 병역특례 전문연구요원으로 근무하는 것이라서, 제 예상과는 다르게 연구소 소속으로 소프트웨어 연구 및 개발 업무를 하게 됐습니다. 당시 삼성SDS에 입사하면 수 개월 동안 PowerBuilder, Oracle 같은 개발 교육을 받은 후에 부서로 배치됐고, 이런 교육 덕분에 소프트웨어 개발 업무에 쉽게 적응할 수 있었죠. 또, 학부 때 컴퓨터 프로그래밍 과목을 여러 개 수강하면서, 디자인보다는 소프트웨어 개발이 제 적성에 더 맞는다고 생각하고 있었고, 이렇게 첫 직장 생활을 소프트웨어 개발자로 시작하게 됐습니다. 이후 27년 동안 쭉 소프트웨어 개발을 하고 있습니다. Q. 이제 부서 이야기를 해볼게요. 개발2그룹에서는 어떤 업무를 진행하고 있나요? 개발2그룹은 인프라웹팀, ITSM팀, 디자인팀으로 구성돼 있습니다. 먼저 인프라웹팀은 우리 회사매출의 90% 이상을 차지하고 있는 Zenius EMS의 웹 업무를 담당하고 있어요. 신규 인프라 혹은 장비의 성능을 모니터링하는 기능을 추가하거나, 사용자 편의성 개선 등의 고도화 업무, 보고서/대시보드 같은 고객사별 커스터마이징 개발 등의 업무를 주로 하고 있습니다. ITSM팀은 IT 부서에서 IT 서비스를 운영하는데 필요한 업무 프로세스를 돕는 Zenius ITSM 제품을 개발하고 이를 기반으로 고객사에 구축하는 프로젝트를 수행하는 팀입니다. ITIL이라는 표준을 바탕으로 장애처리, 서비스요청과 같은 업무를 IT 부서에서 원활하게 수행할 수 있도록 프로세스를 구축하고 이를 시스템으로 처리할 수 있게 합니다. 최종적으로 IT서비스 수준을 한 단계 높이는 일을 하고 있어요. 마지막으로 디자인팀은 브레인즈의 모든 제품과 솔루션의 디자인을 책임지고 있습니다. 고객사별 대시보드 디자인을 하고, 모든 브레인즈 제품의 GUI 디자인, UI/UX 기획, 정보시각화 등의 업무를 합니다. Q. 팀마다 분위기가 다를 것 같은데요. 각 팀별 일하는 방식에 대해 설명해주세요. 아무래도 팀별로 업무가 아주 다르다 보니, 일하는 방식도 업무에 맞춰서 변하는 거 같습니다. 인프라웹팀은 코드리뷰와 공유 회의를 통해서 업무가 진행됩니다. 다양한 고객사로부터 다양한 요구사항이 들어오기 때문에 이전에 했던 유사한 개발 업무가 무엇이었는지, 어떻게 개발했는지 개발자끼리 공유하는 일이 매우 중요해요. 회의를 통해서도 공유하지만, 다음 개발자를 위해 개발 이력도 문서화를 잘 해놓고 있어요. ITSM팀은 팀장이 주도적으로 제품 개발을 리딩하면서, 개발자 모두가 하나의 목표로 똘똘 뭉칠 수 있게 개발자 한 명 한 명을 독려하면서 일하고 있습니다. 디자인팀의 경우, 결과물은 눈에 보이지만 고객의 요구사항은 눈에 보이지 않고 설명하기 어렵기 때문에, 타 부서 및 팀 내에서도 커뮤케이션이 활발하게 이뤄지고 있어요. 또, 브레인즈의 디자인 아이덴터티를 견고하게 만들기 위해서 디자인 크리틱도 자주 합니다. Q. 개발2그룹에 신규 입사자가 들어온다면, 어떤 스타일의 동료가 합류했으면 하는지 궁금합니다. 신뢰할 수 있는 동료. 제가 지금까지 직장생활을 하면서 가장 중요하다고 생각하는 것은 신뢰입니다. 항상 솔직하게 말하고, 자기 말에 책임지는 행동을 하는 동료였으면 좋겠어요. 아무리 실력이 좋더라도 신뢰할 수 없다면, 그 실력도 신뢰하기 어렵게 되는 거 같아요. 모든 인간이 완벽할 수 없기 때문에 조금 실력이 부족하더라도 신뢰할 수 있는 사람이라면, 동료와 서로 부족한 부분을 채워 나가며 무슨 일이든 해낼 수 있다고 생각합니다. Q. 신규 입사자는 브레인즈컴퍼니에서 어떤 성장을 기대할 수 있을까요? 인프라웹팀에서 일하게 되면 1,000여 개의 레퍼런스를 가진 제품은 어떤 모습이어야 하는지를 배울 수 있습니다. 많은 고객들의 다양한 요구사항을 어떻게 제품에 녹여야 하는지, 그리고 그 많은 사이트를 어떻게 관리해야 하는지를 배울 수 있어요. 또, 성능상의 문제없이 방대한 양의 성능 데이터를 어떻게 다뤄야 하는지도 배울 수 있습니다. ITSM팀에서는 다양한 회사에서 IT서비스를 어떻게 관리하는지 직접 경험하고, 이를 제품에 어떻게 포함하는지 배울 수 있어요. 현재 최신 버전의 Zenius ITSM이 고객을 하나씩 늘려가고 있는데요. 새 버전의 제품이 어떻게 업그레이드돼 가는지, 고객의 요구사항은 무엇이고 이것을 제품에 어떻게 녹이는지도 경험하면서 제품과 함께 자신도 성장해 나가는 경험을 할 수 있습니다. 디자인팀에서는 패키지 소프트웨어의 GUI 디자인을 직접 경험할 수 있고, UI/UX 기획도 해 볼 수 있습니다. 다양한 고객들이 원하는 디자인은 무엇인지, 고객과 커뮤니케이션은 어떻게 하는지 등도 경험해 볼 수 있어요. 아무래도 대시보드 디자인 업무를 많이 하다 보니, 다양하고 많은 정보를 어떻게 시각화해야 하는지 연구하고 디자인할 수 있습니다. Q. 브레인즈에 장기근속 중이신데요. 입사 초와 현재를 비교해 보자면? 입사 초기의 브레인즈가 중학생이었다면, 현재는 대학생이 된 것 같습니다. EMS가 성공하면서 상장한 회사가 됐다는 점이 가장 큰 변화라고 생각해요. 또, 상장을 했다는 건 기업이 갖춰야 할 투명성과 성장성이 검증된 것이라고 봅니다. 지금까지 그래 왔듯이 브레인즈는 앞으로도 꾸준히 발전할 것이라고 믿습니다. Q. 그동안 가장 힘들었던 순간과 보람을 느꼈던 순간은요? Zenius EMS 7.0을 개발하고 오픈할 시점이 가장 힘들었습니다. 일이 정말 많았거든요. (웃음) 개발해야 할 인프라가 열 개가 넘었고, 프리랜서 개발자까지 포함해서 30여 명 정도가 매달려서 일했습니다. 개발 업무가 많아 야근하는 것도 힘들었지만, 그룹장이기 때문에 많은 개발자를 관리하는 일이 개발 업무보다 더 힘들었어요. 또, “새 버전이 이전 버전처럼 많은 매출을 울릴 수 있을까”하는 걱정도 한몫 했습니다. 정말 정신없던 때였네요. 반대로 가장 보람찼던 순간은 상장했을 때입니다. 우리 회사가 상장하는 데 제가 5% 정도는 기여하지 않았을까 생각합니다. (웃음) 사실 다니던 회사가 상장한다는 건 일생에 한 번 경험할까 말까 한 일이라고 생각합니다. 단지 운이 좋아서 입사하자마자 상장한 게 아니라, 10년 동안 브레인즈에서 열심히 일해왔고, 그래서 상장하는 데 작은 기여를 했다고 생각하기 때문에 더 기뻤어요. 그 밖에도, 우리 제품이 장애를 미리 발견해 큰 사고가 발생하는 것을 막았다는 이야기를 들을 때면, “내가 한 일이 다른 누군가에 실질적인 도움이 되는구나”라는 성취감을 느껴요. 고객사 기사에서 우리 제품이 기사 사진에 보이거나, 간접적으로 소개되는 것을 볼 때도 보람을 느낍니다. Q. 앞으로 브레인즈컴퍼니에서 꼭 이뤄보고 싶은 목표가 있을까요? 공개할 수 없지만, 현재 브레인즈에서는 새로운 기술로 새로운 제품을 만들고 있는데요. 제가 작게나마 기여를 했으면 좋겠고, 이왕이면 그 제품이 대박을 터트리면 더욱 좋겠습니다. (웃음) 그리고 소박한 목표가 하나 더 있어요. 브레인즈에서 정년까지 일하고 싶습니다. (웃음)
2022.09.16
브레인즈컴퍼니, KB저축은행에 '제니우스 ITSM 3.0' 구축
브레인즈컴퍼니, KB저축은행에 '제니우스 ITSM 3.0' 구축
‘Zenius ITSM 3.0’ 성공적 시장 진입 향후 ITAM, PMS로 도메인 확장 브레인즈컴퍼니(대표 강선근)는 KB저축은행 차세대 시스템 구축 프로젝트에서 자사 ‘제니우스(Zenius) ITSM 3.0’으로 IT 서비스 체계 표준화 및 IT 관리업무 자동화 시스템을 구축했다고 3일 밝혔다. 이번 ITSM(IT Service Management) 구축으로 KB저축은행은 차세대 IT 서비스 플랫폼을 통해 IT 서비스에 대한 사용자 요청을 접수하고, 처리하는 과정과 그 이력을 단일 시스템에서 관리할 수 있게 됐다. 또 방화벽, 원장, 형상관리 등 10개의 시스템과 연동해 IT 관리업무를 자동화할 수 있게 됐다. Zenius ITSM 3.0은 로우코드 기반의 워크플로우 엔진과 구성정보데이터베이스(CMDB) 엔진을 탑재했으며, 워크플로우를 쉽게 생성하고 수정할 수 있는 프로세스 및 폼 디자이너를 포함하고 있다. 워크플로우는 기업마다 다른 IT 서비스를 각자 환경에 맞게 일의 순서와 역할을 손쉽게 편집할 수 있으며, 코딩없이 15개 이상의 다양한 폼 컴포넌트를 통해 업무 신청서를 쉽게 디자인할 수 있다. CMDB 엔진은 IT 서비스와 연관된 인프라, 소프트웨어, 다양한 문서 등을 생명주기에 따라 다양한 세부 항목으로 관리할 수 있다. 정희찬 ITSM 개발팀장은 “Zenius ITSM 3.0은 ITSM 구축 프로젝트 특성상 갖게 되는 시스템 통합(SI) 사업의 한계를 극복하기 위해 관리 프로세스를 모듈화함으로써 필요한 프로세스를 선택적으로 도입할 수 있다. 향후 유연하게 프로세스를 확장할 수 있는 플랫폼 개발에 역량을 집중한 제품”이라며 “다음 목표는 사용자 편의를 위한 부가기능을 강화하면서 Zenius ITSM의 워크플로우 엔진을 기반으로 ITAM(IT Asset Management), PMS(Projenct Management System) 등을 통해 도메인을 확장하는 것”이라고 말했다. 브레인즈컴퍼니는 올해를 기점으로 ITSM 수요가 가파르게 증가할 것으로 예상하고 있다. 2018년 신외감법 개정으로 내부회계관리제도가 감사로 상향 조정돼 많은 기업들이 내부회계관리제도의 '정보기술일반통제(ITGC)' 위험요소에 대응하기 위해 ITSM 도입을 고려하기 때문이다. 그러나 기업들이 ITSM 도입에 있어 도입 및 관리 비용에 부담을 느끼고 있는 실정이다. 이 가운데 이번 KB저축은행의 차세대 ITSM의 성공적인 공급은 Zenius ITSM 3.0이 다양한 고객의 요구사항을 보다 넓은 관점에서 충족시킬 수 있는 솔루션임을 입증한 것이다. 강선근 브레인즈컴퍼니 대표는 “2005년 첫 출시된 Zenius ITSM은 최근 로우코드 기반으로 고객이 직접 커스터마이징하고, 기존 제품 대비 쉽고 빠르게 고객의 요구를 반영할 수 있도록 업그레이드한 제품”이라며, “그 결과 수익성을 확보하면서 고객 편의성을 제고시킨 Zenius ITSM 3.0을 출시했고, 향후 소규모 기업이나 스타트업 등에서도 적은 비용으로 ITSM 솔루션 도입이 가능한 SaaS(Software as a Service, 서비스형 소프트웨어) 형태의 서비스 출시를 계획하고 있다”고 밝혔다.
2022.11.03
JPA 도입을 위한 고민_ORM 기술을 써야 하나?
JPA 도입을 위한 고민_ORM 기술을 써야 하나?
몇 해전에 새로운 버전의 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에 대한 가장 최근의 시도중 하나겠지만, 앞으로 어떤 식으로 발전해 나갈지, 그에 따른 개발 업무는 또 어떤 식으로 변화가 있을지도 궁금하고… 어쨌든, 지금으로서는 다시 돌아가진 않을 생각이다.
2023.01.03
‘Zenius ITSM 3.0’ GS인증 1등급 획득!
‘Zenius ITSM 3.0’ GS인증 1등급 획득!
브레인즈컴퍼니(099390)는 IT 서비스 관리 소프트웨어 ’Zenius(제니우스) ITSM v3.0’이 한국정보통신기술협회(TTA)로부터 GS인증 1등급을 획득했다고 13일 밝혔다. GS인증은 국산 소프트웨어의 품질을 증명하는 국가 인증제도다. 국제표준화기구(ISO)가 정한 표준을 기반으로 소프트웨어의 기능적합성, 성능효율성, 사용성, 신뢰성, 보안성 등 9가지 항목을 점검해 인증을 부여한다. Zenius ITSM(IT Service Management system)은 국제표준 ITIL(IT Infrastructure Library)을 기반으로 IT 서비스 부서의 업무 프로세스를 자동화 및 통합하는 소프트웨어로서, IT 문제 해결과 개선을 위한 체계적이고 모범적인 프로세스를 제공한다. Zenius ITSM v3.0은 로우코드 기반의 워크플로우 엔진과 구성정보데이터베이스(CMDB) 엔진을 탑재했으며, 워크플로우를 쉽게 생성하고 수정할 수 있는 프로세스 및 폼 디자이너를 포함하고 있다. 강선근 브레인즈컴퍼니 대표는 “브레인즈컴퍼니는 Zenius ITSM v3.0을 소규모 기업, 스타트업, 공공시장 등 다양한 시장에 공격적으로 확대해 나갈 예정이며, 적은 초기 비용으로 도입이 가능하도록 SaaS(Software as a Service, 서비스형 소프트웨어) 형태의 서비스 출시를 준비 중”이라고 밝혔다.
2023.04.13
다음 슬라이드 보기
