'Jürgenized’라는 용어의 유래와 실제 사례를 정리합니다.
Jürgenization의 정의
Spring Data 프로젝트를 이끌었던 Oliver Drotbohm은 2013년에 Jürgenized라는 글에서 이 용어를 사전 항목 형식으로 정의했습니다. 번역하면 아래와 같습니다.
Jürgenization (명사)
당장의 문제를 푸는 데는 충분해 보이는 코드를, 견고하고 품질이 보증되며 완벽하게 문서화되고 확장 가능한 코드로 바꾸는 과정. 이 과정은 원래 코드의 전면 재작성(Karma level 0)부터 사소한 수정(Karma level 10)까지 다양한데, 보통 코드 작성자가 이 과정을 얼마나 자주 통과해 봤는지에 따라 달라진다.
이 글은 용어의 유래도 밝힙니다. Spring Framework에 들어올 기여 코드를 다루는 Juergen Hoeller의 방식에서 나온 말로, 코드를 core codebase에 넣으려면 코드와 그 작성자가 함께 jürgenized 되어야 한다는 것입니다. 글이 쓰인 시점에는 Spring 생태계 프로젝트 전반의 코드 품질 보증 과정을 가리키는 말로 의미가 넓어져 있었습니다.
Spring Project Infrastructure 발표와 Refactor Type 분류
저는 이 단어를 SpringSource의 Gunnar Hillert와 Roy Clarkson이 2013년에 발표한 Spring Project Infrastructure라는 슬라이드에서 처음 봤습니다. Spring 프로젝트들이 GitHub로 이전하고 PR로 기여를 받는 과정을 소개하는 발표인데, 후반부에 'Jürgenization’이라는 슬라이드가 등장합니다. 같은 제목의 발표 영상에서는 이를 Juergen Hoeller의 코딩 스타일과 기준에 맞는 코드 품질과 엄격함이라고 설명합니다.
이 용어를 리팩터링의 한 유형으로 분류한 문서도 있습니다. Refactoring 정리 노트는 Refactor Type을 TDD, Boy Scout Rule, Comprehension, Preparatory, Planned, Long term으로 나열하는데, 그 목록의 마지막 항목이 Jürgenizing입니다. 출처로는 앞서 소개한 Oliver Drotbohm의 글을 링크하고 있습니다.
머지 대신 직접 커밋: PR #23200의 처리 과정
spring-framework 저장소의 PR 목록을 보면 Stéphane Nicoll 같은 커미터는 올라온 PR을 그대로 merge해 주는 경우가 많습니다. 반면 Juergen Hoeller는 PR을 리뷰하고 참고하되, 반영은 본인의 커밋으로 직접 하는 방식을 선호하는 듯합니다.
앞의 PR #23200도 그렇게 처리됐습니다. 흐름을 따라가 보면 Jürgenization의 축소판을 볼 수 있습니다.
-
제안자가 bean destroy 실패 로그를
info에서 더 높은 레벨로 올려달라는 PR을 올렸습니다. -
Juergen Hoeller가 리뷰하면서 새로운 관점을 제시했습니다. 이 로그는 Spring 5.0/4.3에서는
warn레벨이었는데 5.1에서 로그 레벨 정책을 정비하다가 생긴 회귀라는 점을 짚었고, 제안대로error까지 올리는 방안에는 bean destroy 실패가 여러 단계로 이뤄지는 소멸 과정의 부분적인 실패일 뿐이므로 불필요한 노이즈를 만든다며 선을 그었습니다. -
결론은 PR의 merge가 아니었습니다. Juergen Hoeller가 직접 작성한 커밋이 "Bean destruction exceptions consistently logged at warn level"이라는 메시지와 함께 반영됐고, PR은 이 커밋의 "Closes gh-23200"으로 닫혔습니다.
제안한 사람의 문제의식은 받아들이되, 원인 분석과 최종 코드는 자신의 기준으로 다시 만들어내는 과정이 그대로 드러납니다.
Rod Johnson이 꼽은 가장 생산적인 프로그래머
Juergen Hoeller의 이런 위상을 보여주는 인터뷰가 있습니다. Ed Burns가 쓴 Secrets of the Rock Star Programmers(2008, 번역서 제목은 '세상을 뒤흔든 프로그래머들의 비밀')에 실린 Rod Johnson 인터뷰입니다. 제 기억에 따르면, 함께 일했던 프로그래머 가운데 가장 생산적이었던 사람이 누구냐는 질문에 Rod Johnson은 생각할 것도 없이 Juergen Hoeller라고 답합니다. 이어서 Juergen Hoeller가 개발 속도와 품질 모든 면에서 가장 뛰어난 결과를 보이며, 자신이라면 여러 번의 시행착오를 거쳤을 문제를 그는 한 번에 해결할 것이라고 말합니다. (번역판 p32~33 쪽)
(이미지 출처 : https://www.yes24.com/product/goods/3691866)
(이미지 출처 : https://openlibrary.org/isbn/9780071490832)
원서에서 해당 부분은 15쪽에 있습니다.
Ed: Who is the most productive programmer you’ve ever worked with? What was it about them that made them that way? Did they just crank out lots of code? Did they get things done faster than everyone else? What do you say about that?
Rod: Jürgen Höller. Undoubtedly.
Ed: And what is it about Jürgen?
Rod: It’s basically all of the above, which is kind of demoralizing. Maybe the difference isn’t that big between Jürgen and other good people, but I’ve worked with some people that I would rate as better overall, but I’ve never worked with or encountered anyone who’s better in every way. For example, if I look at the other people in the Spring team, some are faster [than others], but do higher-quality code. Others do higher-quality code, but are slower. Some of them, other than Jürgen, are probably better overall, but, nevertheless, you can break it down and see differences and weaknesses. Whereas, Jürgen, compared to anyone I’ve ever seen, is faster and his code is better. You asked how does he do it? I don’t know. From what I’ve seen, it’s not just my opinion. Jürgen’s pretty legendary. What I’ve seen is that he works in a very different way from me or anyone else that I know. For example, my way of working is very iterated. If it’s a really complex problem, my first version would be embarrassing to look back on, my second version wouldn’t be too bad, and the third version would be quite good. Jürgen would start with a problem like that, and this would take maybe a lapse time of ten hours' programming if it was a reasonably hard problem. Jürgen would start off by thinking deeply about it for three hours. Then he’d spend two hours writing code, and it’d probably be perfect. I can’t work like that.
20년 가까이 지난 인터뷰인데, Juergen Hoeller는 지금도 Spring Framework의 리드로 활동하고 있습니다. 2024년에는 Spring Framework 1.0 릴리스 20주년을 맞아 Rod Johnson과 함께 팟캐스트에 출연했고, Spring I/O 2025의 발표 무대에도 함께 섰습니다. 한 프레임워크를 20년 넘게 같은 기준으로 지켜온 셈이니, 'Jürgenized’라는 용어도 당분간 유효할 듯합니다.
Twitter
Facebook
Reddit
LinkedIn
Email