Toby's Epril

클린 스프링 - 인프콘 2024

PaxCaelo — Tue, 10 Sep 2024 22:54:46 +0900

두 번째 인프콘 발표를 한 달 전에 마쳤다.

성장을 주제로 한 발표를 해야 한다는 요구에 처음으로 기술 이야기가 아닌, 그동안 품고 있었던 나의 이야기를 나눌 수 있었던 작년 발표에 이어 이번엔 클린 스프링이라는 주제로 또 다른 이야기를 하게 됐다.

다시 발표를 한다면 클린 코드 이야기를 하겠다는 생각을 해왔다. 클린 코드라는 꽤 괜찮은 책을 너무 가볍게 보고 몇 가지 피상적인 원칙만 이야기하는 모습이 아쉬워서였다. 특히 개발 실력을 빠르게 향상해야 하는 주니어 개발자에게는 이 클린 코드가 정말 중요한 길잡이가 되어줄 수 있다는 나름의 확신이 있었기 때문에, 진정한 클린 코드가 무엇인지 말해주고 싶었다. 사실 로버트 마틴 책에 이미 모든 내용이 다 들어있다.

하지만 다들 책을 잘 안 읽는 걸.

그래서 저자가 독자를 향한 조언과 경고를 담은 서문을 썼고, 그 내용을 바탕으로 책에서 무엇을 봐야할지, 책을 읽고 나서 클린 코드를 실전에서 활용한다는 것이 무엇인지에 대해서, 이왕이면 스프링 개발의 예를 들어가며 설명할 준비를 해왔다.

발표에서 하려고 했던 이야기를 틈나면 메모해 둔 문서를 열어보니 이런 얘기들이 적혀있다.

깔끔한 코드를 작성하는 것은 스스로를 전문가(professional)라고 부르기 위해 반드시 해야 하는 일입니다.
최선을 다하지 않는 것에 대한 그럴듯한(합리적인, 납득할 만한, 타당한, 정당한) 변명은 없습니다.

로버트 마틴 책의 부제에 나오 듯이 이 책은 장인정신(craftsmanship)에 관한 이야기다.

장인 정신은 원칙, 패턴, 실천 그리고 장인이라면 알고 있을 실용적이고 신속하게 답을 구하는 방법(heuristic)을 포함하는 지식을 익히며, 열심히 노력하고 연습해서 그 지식을 손가락, 눈, 그리고 몸에 갈아 넣어서 체득하는 것입니다.

클린 코드는 그저 이름 잘 짓고, 함수 작게 만들고, 주석 달지말고, 스타일 통일하고, 디미터 법칙 지키자라는 수준의 피상적이고 기계적인 주장을 하는 캐치프레이즈가 아니다. 대부분 앞부분만 보고 6장 넘어서 나오는 내용에 대해서는 얘기도 하지 않는, 책에 나오는 저자가 꽤나 고민하면서 수집하고 애써 만진 코드는 술렁술렁 넘기고 말 책이 아니란 말이다.

저자 스스로가 많은 독자들이 책에 넣은 코드와 책 후반부에 집중적으로 나오는 예제에 대해서는 대충 넘어가고, 스스로 코드를 만들고 고쳐보면서 고민하지도 않은 채로 몇 가지 기억했다 써먹기 좋은 원칙스러운 표현들만 가져다 들이밀고 말 것을 예측했는지 초반부터 많은 경고를 책에 남겨놨다. 이걸 내 언어로 정리해서 발표에서 하려고 했던 이야기는 그래서 이런 것들이었다.

클린 코드를 작성하는 법을 배우는 건 어려운 일이다. 지식 이상이 요구된다. 땀을 흘려봐야 한다. 연습해야 한다. 실패하는 경험을 해야 하고, 헤매다 다시 돌아오기도 하고, 잘못된 방법의 결정을 내렸던 것의 비용과 결정에 대해서 분노도 해봐야 한다. 더 어려운 작업에, 계속 복잡도가 증가하는 케이스에 도전하고, 많은 문제를 작은 문제로 줄여보는 것을 해야 한다.

이 책을 읽을 때 케이스 스터디를 스킵해버리고 이론만 읽는다면 그저 좋은 코드를 작성하는 책을 읽어서 기분만 좋은 것일 뿐이다.

작은 스텝을 밥으며 매 순간의 결정을 따라가세요. 그러면 언젠가 너도 클린 코드를...

이 책을 읽거나 공부하면서 14장 Args 구현(개선)부터 이후의 케이스 스터디를 직접 시도해 보고 저자의 코드와 비교해 보고, 따져본 사람이 얼마나 될까. 아니 그전 장에 나오는 예제들도 하나하나 직접 코드를 보면서 같이 궁리를 해보긴 했을까.

아무튼 이런 얘기가 하고 싶었다. 발표에서 케이스 스터디를 스프링으로 개발하는, 혹은 스프링을 확장하며 프레임워크를 만드는 과정을 담아서 하려고 준비하고 있었다.

그런데, 요즘은 클린 코드에 대해서 어떤 이야기를 하는지 궁금해서 유튜브에서 검색해본 게 화근이었다.

개발자들에게 가장 큰 영향력을 가진 이동욱 aka 향로, 조졸두 님이 개발바닥 유튜브 영상에서 클린 코드를 하면 개발 능력이 떨어지고 개발 속도가 떨어진다는 심각한 이야기를 하신 게 아닌가. 끝까지 보면 대략 어떤 의미로 이런 이야기를 했는지 이해는 되지만.

어쨌든 피상적이고 정인정신이라곤 찾아볼 수 없는 프로 답지 않은 수준으로 끌어내린 탓에 클린 코드의 반짝 인기가 이제 안티 클린 코드를 만들어 내고 있다는 심각한 느낌을 받았다.

그래서 준비했던 발표 내용을 모두 취소하고, 이런 현상 속에서 원래 클린 코드가 추구하려고 했던 의미 있는 목표와 시도가 무엇인지를 설명하기 위한 준비를 시작했다.

테스트, TDD가 그랬던 것처럼 결국 생산성과의 충돌이 현장에서의 문제라는 생각을 했다. 장인정신이고 뭐고, 몇 가지 가독성이 좋은 이해하기 좋은 코드를 작성하려는 시도조차도 아무런 준비 없이 들이 대면 결국 문제를 일으킨다. 장인정신이 지식과 함께 치열한 수련이 필요하다는 걸 이해 못 하면서 아주 피상적인 지식만 알고 있으면, 결국 클린 코드하니까 테스트나 리팩터링은 필요 없잖아요 같은 말을 하는 거겠지.

그래서 우선 제대로 적용된 클린 코드는 생산성을 올려줄 수 밖에 없다는 이야기를 해줘야겠다 싶었다.

워드 커닝험의 부채 은유가 설명에 딱 들어맞는 소재라는 생각을 했고, 클린 코드가 표면적으로 추구하는 유지보수성은 결국 생산성도 함께 끌어올리게 되고, 이는 부채 은유에서 설명하듯이 시간을 빌려서 얻게 되는 더 많은 배움을 리팩터링을 통해서 부채 상환하는 사이클로 가져갈 수만 있다면, 유지보수성과 생산성은 서로 배타적이 아니라 서로 영향을 주면서 상승시킬 수 있는 사실상 같은 목표, 클린 코드의 지향점이라는 설명으로 이야기를 풀어보기 시작했다.

너무 딱딱해지면 그러니까, 아이스 브레이킹을 위해서 또 한번 향로 님을..

아무튼. 그렇게 두 가지 속성을 다루고 나니, 뭔가 허전했다.

그러다 대부분 주니어로 구성된 팀과 함께 코드를 만들면서 여러 경험을 쌓아왔던 최근 5년 정도의 시간을 돌이켜 봤다. 두 번의 팀 개발 경험을 하면서 느꼈던, 팀으로 일을 한다는 것이 주는 가치와 효과를 생각해 보니, 결국 이것도 클린 코드에서 빠질 수 없는 것이라는 생각이 들었다.

내가 작성하는 모듈의 코드는 거의 나만 작업하던 때도 있었는데, 다른 주니어 개발자들도 봐야하고 만져야 하는 상황에서는 스스로 스타일이나 작업 난이도, 패턴 등을 함께 하는 동료에게 맞춰서 조정했던 경험이 있다. 그리고 기술적인 결정과 그에 따른 결과를 함께 지켜보고 피드백을 얻고, 그 속에서 무엇인가 배우고 느끼는 순간을 같이 해보려는 시간들이 떠올랐다. 그냥 나 혼자 하면 훨씬 빨리 할 수 있는 작업도 있었지만, 함께 하면서 더 크게 얻는 것들이 있는데, 가장 큰 건 팀으로 성장하는 느낌이었다.

그래서 단순히 유지보수성과 생산성, 그 선순환을 이끄는 동력인 리팩터링, 또 그걸 지지해주는 테스트 작성을 넘어서 팀워크도 클린 코드를 지탱하는 하나의 축이라는 생각이 들었다.

그러고 나니 최근 네플릭스에서 보고 감동했던 삼체라는 드라마가 생각이 났다. 드라마가 너무 재밌어서 원작 책도 구해 놓고 보려고 하고 있었는데, 아무튼 3가지 서로 영향을 주는, 그냥 놔두면 어떻게 영향을 주면서 어디로 튈지 모르는 세 가지 강한 중력을 가진 천체의 이야기인 삼체와 클린 코드의 세 가지 속성이 너무 닮았다는 생각이 들었다.

그래서 삼체 이야기를 넣었다. 이게 몇 마디 원칙으로 해결되는 간단한 문제가 아니고, 꽤나 고민하고 답을 찾기 위해서 많은 수고를 해야 하는 클린 코드의 장인정신에 잘 맞는다는 생각이 드니, 모든 이야기가 잘 풀렸다.

이미 발표 영상은 인프런에 공개됐으니 자세한 얘기는 거기서 보면 될테고.

https://www.inflearn.com/course/%EC%9D%B8%ED%94%84%EC%BD%982024-%EB%8B%A4%EC%8B%9C%EB%B3%B4%EA%B8%B0

[지금 무료] 인프콘 2024 다시보기 강의 | 인프런 - 인프런

인프런 | 성장하는 IT인들의 축제, 인프콘 2024에서 진행된 오프닝 및 발표 세션을 영상으로 다시 보실 수 있습니다., ✅ 확인해주세요이 콘텐츠는 2024년 8월 2일 금요일 진행된 인프콘 2024 발표 녹

www.inflearn.com

처음 클린 코드 이야기를 하겠다고 마음먹었을 때부터 마지막에 꼭 하고 싶었던 말이 있었다.

친절하자

개발이란, 그것도 처음 개발 후에 계속 유지보수하며 발전하고 바뀌고 온갖 상황과 버그와 씨름해야 하는 거대한 코드를 다루는 작업은 스트레스가 많다. 그래서 다들 날카롭고 거칠어진다. 쉽게 공격하거나 상처를 주고, 또 받는다. 그런데 정말 일을 잘하는 팀은 친절하다는 걸 안다. 스프링 코어 개발자들이 주류 자바 엔터프라이즈 기술을 다루는 사람들로부터, 혹은 다른 언어와 프레임워크 개발자와 사용자들로부터 얼마나 거친 공격을 받았는지 20년 넘게 지켜봐 왔기 때문에 잘 알고 있다. 그런데도 스프링 개발팀은 항상 참 젠틀하다는 생각을 했다. 그들의 말투와 대응하는 태도 모두 어떻게 이럴 수 있을까 감탄할 때가 많았다. 나는 그걸 개발팀이 서로 존중하고 친절했기 때문이라고 생각했다. 기술을 사용하는 사용자에게나, 같은 개발 팀원들에게, 그리고 생태계의 많은 이해관계자들에게, 그리고 자기 자신에게도 친절했기 때문이라는.

친절한 팀은 함께 결정하고, 함께 호기심을 가지고 탐험하고, 그 과정을 통해서 학습하고 배운다. 그리고 그걸 반복하는데, 결국 그게 팀 모두가 성장하는 결과를 가져온다. 성장은 그걸 추구해야 하는 목표라기보다는 이런 과정 속에서 자연스럽게 얻게 되는 결과인데, 이걸 가장 효율적으로 이끄는 것이 친절한 팀과 함께 탐험하는 순간이라는 걸, 나는 최근 시간을 통해서 경험했고 확신을 가지고 있다.

아무튼 그런 얘기를 주절주절했지만, 이번엔 40분 발표시간을 겨우 1분을 넘겨 끝냈다. 뿌듯.

그런데 지난 5월에 다녀온 코틀린 컨퍼런스에서 Daniel Terhorst-North의 발표를 듣다가, 내가 하고 싶었던 이 이야기가 결론에 나오는 걸 보면서 가슴이 뛰었다. 나와 똑같은 생각을 하는 사람이 있구나, 이런 느낌 정말 짜릿하다. 나만 이상한 생각을 한 게 아니구나 하는 안심도.

https://www.youtube.com/watch?v=D6aUoGK2rkk

클린 코드 쉬운 거 아니다, 정신 바짝 차리고 제대로 공부하고 제대로 훈련하라는 설교를 할 뻔했는데, 동욱 님 덕분에 뭔가 다른 고백을 하고 온 듯했다. 전날 밤에 도착해서 계절이 바뀌는 충격을 그대로 안고 몽롱한 정신에 이야기를 했지만, 그래도 이야기를 마치고 나니 마음이 정말 시원했다. 듣는 분들은 무슨 생각을 했는지 잘 모르겠지만.

함께 팀으로 일해줬던 사람들에게 고마움도.

좀 더 친절하지 못해서 미안했을 뿐.

아무튼 클린 코드 포기하지 말고 계속했으면 좋겠다.

그리고 책 좀 제대로 읽고 공부하고 책에 나온 코드와 씨름하자.

참, 제목을 왜 클린 스프링이라고 했는지는 발표에서 설명했고, 사실 클린 스프링이라는 이름의 로드 맵을 만들어서 강의를 준비하고 있다. 발표에서 했던 이야기가 잘 녹아드는 개발 현장의 느낌을 살려보고 싶은데, 잘 모르겠다. 그래도 한번 해봐야지.

Homo Faber - 도구를 만드는 개발자

PaxCaelo — Mon, 11 Mar 2024 16:59:30 +0900

내가 브리즈번에서 가장 좋아하는 스시 일식당인 Takashiya는 함께 비즈니스 하는 분들과 축하할 일이 있거나, 고마움을 표현해야 하는 분이 있을 때 방문한다. 얼마 전엔 결혼 25주년 기념으로 아내와 함께 하려고 계획한 한 달간의 식사 코스 첫 날로 이곳을 찾았다. 평일 저녁이고 상대적으로 덜 붐비는 마지막 프리미엄 세션이라 나이가 지긋한 호주인 커플과 우리 부부만 자리해서 편안하게 식사를 하게 되었다. 평소엔 꽤 높은 텐션으로 분주하게 움직이며 요리를 준비하고 밝게 잘 웃던 셰프 Takashi Nami도 이날은 차분하게 음식을 준비하고 서빙하면서 조용히 이런저런 이야기를 들려주었다. 호주 전역에서 나는 특색 있는 해산물과 뉴질랜드, 일본, 스페인에서 직접 구해온 좋은 재료를 가지고 매번 예상을 넘어서는 맛과 향을 가진 창의적인 코스를 준비해 주는 건 여전했고.

그런데 이날은 앉은 위치 때문인가 바로 앞 벽에 걸린 칼들이 눈에 들어왔다. 스시 셰프에게 가장 중요한 도구를 꼽자면 아마 칼일 거다. 좋은 재료를 구하면 이를 잘 손질해서 손님 앞에서 꺼내 마지막 썰어내기에 좋은 크기로 준비하고, 마지막 세밀한 손놀림과 함께 최적의 모양과 크기로 잘라내어 하나의 초밥이나 회를 이용한 요리를 완성하는데 데 칼만큼 중요한 도구는 없을 거다. 큰 참치 등을 다룰 때 쓰는 양날을 가진 큰 칼부터 세포의 손상까지 고려해서 빠르고 선명하게 부드러운 횟감을 잘라낼 때 쓰는 가늘고 날카로운 칼까지, 내가 잘 모르지만 아무튼 여러 용도에 쓰일 것 같은 크기와 특징을 가진 칼들이 잘 손질되어 준비되어 있는 게 보였다.

세션 중간에 몇 개의 칼을 꺼내어 설명해주었는데 가장 인상에 남은 건 크기가 다르지만 실은 같은 종류인 칼 두 개를 비교해서 보여준 것이었다. 원래 칼은 왼쪽의 크기인데 Takashi 셰프가 이걸 36년 동안 계속 손질해서 사용하면서 날이 닳아서 크기가 작아진 게 오른쪽의 칼이다. 36년 동안 이걸 계속 사용했다니.

Takashi 셰프는 홋카이도 출신이다. 15살 때 스시 요리사가 되기 위해 식당에서 도제식으로 셰프를 희망하는 젊은 사람들을 쓰는 식당에 견습생으로 들어갔다. 종일 보이지 않는 곳에서 궂은일을 했고, 식당이 문을 닫은 뒤에야 혼자 연습하며 실력을 키우며 셰프의 꿈을 위해 버텨왔다고 한다. 보통 일본 스시 식당 견습생들은 5년 이상 버티고 실력을 인정받아야 겨우 손님 앞에서 칼을 잡을 수 있는 기회가 주어진다. 그런데 Takashi 셰프는 매일 밤마다 칼을 가지고 재료를 준비하는 연습을 치열하게 한 끝에 2년 만에 칼을 잡고 보조 셰프로 일을 시작할 수 있었다. 그때부터 40년을 일본과 호주에서 스시 셰프로 일하면서 장인의 수준에 오르게 됐다. 지금은 자신의 이름을 건 식당을 브리즈번의 강남이라고 할 수 있는 사우스뱅크에 열고, 평론가와 손님들의 찬사를 받으며 지금 까지 마스터 셰프로 일을 하고 있다.

이날 미소를 지으며 자랑스럽게 보여준 이 칼은 36년간 사용했다고 하니 아직 성인이 되기도 전인 어린 시절부터 사용해온 것이겠지. 칼의 크기가 점차 달라지면 쥐고 움직이는 방법도 바뀌어야 했을 것이다. 여유가 생기면 원래 크기와 비슷한 좋은 칼을 새로 구해서 써도 그만이었을 것인데, 자신이 소중하게 사용해서 셰프의 자리에 오르기까지 매일 밤 손에 쥐고 연습해 왔던, 떨리는 마음으로 처음 손님 앞에서 재료를 손질해서 음식을 낼 때 잡았던 도구를 정말 소중하게 계속 간직하고, 계속 연마하면서 작아지는 칼에 맞춰 자신의 손의 움직임도 계속 따라 연습을 해온 게 분명하다.

자신이 하는 일에 도구가 얼마나 중요하고 소중한지 잘 알고, 이걸 계속 손질하고 관리해서, 궁극적으로 손님을 만족시키는 좋은 요리를 만들어내는데 사용할 줄 아는 사람. 바로 도구를 사용해서 자신의 운명과 환경을 제어할 수 있는 인간을 가리키는, 도구의 인간이라는 뜻의 Homo Faber가 아닐까 하는 생각이 들었다.

저 두 개의 칼을 들고 활짝 미소짓고 있는 Takashi 셰프의 모습은 꽤 오래 기억에 남을 듯하다.

도구를 사용하는 개발자

원래 개발자는 원래 무엇인가 창조하는 일을 하는 사람이다. 어제는 없던 코드를 설계하고 작성해서 오늘은 누군가 사용할 수 있는 동작하는 소프트웨어를 만드는 사람이니까. 그런데 때로는 주어진 도구를 기계적으로 활용해서 매번 비슷한 결과물을 내는, 약간의 훈련만 되어있으면 별 다를 바 없는 작업을 반복하기만 하는 단순 노동자로 취급되기도 한다. 백엔드 개발자는 JSON으로 포장된 데이터의 상하차 작업을 하는 사람이라는, 농담이라고 하기에도 너무 허탈하게 느껴지는 이야기를 하기도 하는데.

그건 아니라고, 우리는 꽤 창조적인 작업을 하는 사람들이다.

개발자가 창조적인 작업을 하는 사람이 될 수 있는 건 무엇인가 만들어낼 때 적절한 도구를 사용할 줄 알기 때문이다. 바보같은 컴퓨터가 알아먹을 수 있는 바이트를 뽑아내는 컴파일러를 만들고,그 위에 얹을 표현력이 좋은 구조를 가진 언어를 만들고, 반복적으로 사용되는 코드를 라이브러리로 만들고, 그걸 이용해서 온갖 애플리케이션과 시스템 프로그래밍을 한다. 단순한 텍스트 에디터로부터 모든 개발 작업을 한 곳에서 다 처리할 수 있는 통합개발환경(IDE), 그리고 각종 플러그인과 부가 기능, 서비스, 도구를 얹고 또 얹어서, 예전 같으면 상상도 못할 속도로 소프트웨어를 만들어낸다.

소프트웨어 개발자만큼 도구를 다양하게 많이 활용하는 사람도 없을 것 같다.

그런데 그러면 충분한가?

도구를 만드는 개발자

나는 처음 기업에서 개발을 시작한 뒤로 오랜동안, 고객이 원하는 애플리케이션을 만드는 중에도 끊임없이 내 작업을 더 효과적으로, 더 빠르게, 더 편리하게 해 줄 수 있는 무엇인가 만드는데 집착해 왔다.

90년대 처음 웹 개발이란 걸 CGI 방식을 이용해서 시작했는데, 웹 서버가 프로세스를 띄워서 코드를 실행해주면 데이터 등을 가져와 로직을 적용한 다음 브라우저에 돌려줄 HTML을 printf()로 출력해야 했다. printf("<HTML>..."); 이런 C 코드를 길게도 작성했다. 며칠이 지나자 저 문자열에 HTML 태그와 데이터를 이리저리 합성해서 출력하는 코드를 만지는 게 불편해졌다. 내가 이런 작업에, 오타 때문에 툭하면 잘못된 결과가 나서 고쳐대야 하는 노가다를 해야 하는가라고 생각을 했다. 비록 주변 개발자들은 묵묵히 그렇게 개발하고 있었지만. 그래서 편집을 안 해도 되는 HTML 코드만 있는 파일을 만들고, 동적으로 변경되는 정보를 넣어줄 수 있는 위치를 마킹한 뒤에 그걸 읽어서 C 코드를 생성하는 프로그램을 만들었다. 지금으로 치면 템플릿 엔진 비슷한 코드 생성기를 만든 것인데, 반나절쯤 여러 케이스를 다 지원하도록 그 작업을 하고 났더니, 다음 날부터 전에는 반나절 걸리던 작업이 30분이면 끝이 났다. 나머지 시간은 새로운 웹 개발 기술이 뭐가 나오고 있는지 찾아서 공부하는데 시간을 썼지.

고정사이즈 문자열을 프로토콜에 맞춰서 전문으로 보내거나 파싱해서 처리해야 하는 은행 서비스 개발을 할 때도 비슷한 생각을 했다. 프로토콜을 정의한 엑셀 문서에 나온 내용에 맞춰서 전문을 생성하거나 파싱 하는 코드를 만들면 편리하지 않을까 생각했고 남들 모르게 라이브러리를 만들어 다음부터는 그냥 찍어내 듯이 쉽고 정확하게 동작하는 코드를 만들 수 있었다.

개발자라면 자신이 만드는 코드에서 반복적인 작업이 자주 등장하고, 이를 재사용할 수 있는 필요가 있다면 당연히 도구를 만들어야 한다고 생각했다. 라이브러리나 프레임워크를 만들기도 했고, 사용하는 개발툴의 확장 기능을 만들기도 했다. 필요하면 소스코드를 구할 수 있는 서버 프로그램을 뜯어고치기도 했고.

자바로 넘어오니 이건 완전 내 세상이었다. 상용 서버 코드도 Jar 파일 압축을 푼 뒤 나오는 클래스파일을 디컴파일하면 내부 구조가 보였다. 설명은 없지만 그래도 디컴파일해서 보면 어떻게 동작하는지 보였고, 클래스 로딩 순서를 강제로 바꿔서 내가 고쳐 만든 클래스로 대체될 수 있게 해서, 서버를 내가 원하는 방식으로 동작하도록 바꾸는 일도 했다. 본격적으로 오픈소스라는 걸 만나면서는 정말 환상적이었지. 당시 나온 프레임워크, 빌드 도구, 서버 따위를 프로젝트 초반에 내가 원하는 스타일로 튜닝하거나 기능을 추가해서 사용하는 걸 즐겨했다. 새 버전이 나오면 이번 것은 어떻게 만질 수 있을까 살펴보는 게 즐거움이었고.

이클립스를 사용하니 플러그인을 만들 수도 있었다. 메이븐도 플러그인과 각종 설정을 건드리면 기본 방식을 내가 좋아하고 편하다고 생각하는 걸로 변경해서 쓸 수 있었다. 내가 좋아하는 방식으로 모든 걸 고쳐서 써야 마음이 편했으니, 한동안 기본 세팅으로 써본 툴이 거의 없을 정도였다. 물론 버전업 될 때마다 계속 손이 가야 했지만.

스프링은 그때 만난 최고의 도구였다. 세상에 이렇게 멋진 도구가 있을까 싶었다. 내가 스프링을 교육할 때 자주 하는 질문이 있다. 스프링은 뭘로 만들었을까인데. 뭐 자바로 만들었겠지. 근데 내가 원하는 답은 그게 아니었다. 스프링은 스프링으로 만들었다. 스프링은 가장 기본이 되는 DI 기본 기능과 그 확장 포인트를 가지고 스스로 끊임없이 확장하고, 확장해서 만든 것이다. 거의 모든 기능이 그렇다. 거의 DSL 수준으로 기능을 외워서 써야 하는 애노테이션 범벅이 되었을 때도 마찬가지 었다. 그것도 스프링의 기존 기능을 확장하는 방식으로 만들었다. 스프링 코드를 뜯어 고쳤다는 게 아니라, 제공되는 유연한 확장 포인트를 가지고 기존 코드에 영향을 주지 않은 채로 기능을 추가할 수 있었다. 이게 바로 그 짜릿한 OCP구나라는 걸 매번 느끼면서. 이렇게 강렬하게 자신을 확장해서 써보라는 프레임워크들이 너무 좋았다. 객체지향 프레임워크라면 당연히 확장해서 개발하는 프로젝트에 맞게 만들어 쓰는 게 당연하다고 생각하고 이야기해 왔고.

대부분 오픈소스인 도구들도 마찬가지였다. 소스 코드를 받아서 내부 동작원리를 보고, 확장 포인트를 찾아서 이리저리 만져보는 게 즐거웠다.

근데 어느 때부터인가, 그런 작업을 하지 않게 되었다. 튜닝의 끝은 순정이라는 따위의 말을 하면서 도구를 만든 사람들이 준 기본 방식을 따라서 잘 쓰면 된다, 없으면 안 쓰면 그만이라는 생각이 서서히 들어왔다. 귀찮은 건지, 기본 도구들이 너무 발전한 것인지 모르겠지만. 그래서 빌드 툴의 플러그인을 만드는 것도, 라이브러리나 프레임워크를 확장한 기능을 만드는 것도 어느새 시들해져 갔고, 이젠 남들이 만들어 놓은 게 있으면 쓰고 아님 말고, 약간의 코딩 노가다는 치매 예방에도 좋으니까 하면서 살기 시작한 지가 제법 된 듯하다.

직접 만들고 손질할 가치가 있다

자신만의 도구를 소중하게 30년 넘게 손질하고 그에 맞춰 계속 자신의 실력을 쌓아왔던 Takashi를 보고 나니, 갑자기 부끄럽다는 생각이 들었다. 내가 그분보다 어릴 텐데, 그리고 도구를 손질하고 만드는 데 훨씬 유리한 개발 일을 하고 있는데 이렇게 느긋하게 살고 있다는 게 뭔가 싶었다.

얼마 전 테스트 코드에서 기존 스프링이 제공하는 방식으로는 맘에 들지 않는 코드를 매번 추가해야 하는 케이스가 나왔다. 이전 같으면 그냥 그렇게 테스트 만들면 그만이지라고 생각했는데, 최근 함께 일하게 된 개발자에게 그런 모습을 보여주고 싶지 않았다. 그래서 이거 스프링 테스트 프레임워크를 기반으로 조금 확장한 기능을 만들면 테스트 코드도 깔끔해지고 가독성도 높아지고 이후에 변경에 흔들리지 않는 좋은 코드를 만들 수 있다고 설명하고, 함께 테스팅 프레임워크를 확장한 애노테이션과 이를 활용한 테스트 프레임워크 확장 기능을 만들었다. 별 거 아니지만, 만들고 나니 예전에 도구를 만들어 적용하고 날 때마다 짜릿했던 기억이 떠올랐다.

그래서 다시 나와 우리 개발팀이 필요한 도구를 본격적으로 만들어볼까라는 생각을 하기 시작했다.

최근에 개발하면서, 더 빠르게, 더 간단하게, 잘 만들고 싶은 건 테스트이다. 시간을 최소한으로 쓰면서 우리 프로젝트의 특성에 맞게 더 간결한 테스트를 만들 수 있는 여러 가지 방법에 대한 아이디어가 있는데, 매번 그냥 있는 거 쓰고 말지라고 넘어갔다. JUnit 5만 해도 확장 포인트가 잔뜩이고, 스프링 테스팅 모듈과 각종 Mock 프레임워크들도 마찬가지지. 최신의 테스트 지원 방식을 조합해서 핵심에만 집중한 이해하기 쉬운 테스트를 만들 포인트들이 보이거든. 거기에 IDE 플러그인까지 만들어 단축키와 메뉴를 이용하게 만들면 더 즐겁겠지.

그런데 개발 도구를 연마하는 걸 오랫동안 게을리했더니 따라잡으려면 꽤 시간을 투자해야 할 거 같다. 대부분 그래왔듯이 아마도 혼자 작업을 할테고 조금은 외롭기도 하겠지. 그래도 시작을 해볼까 싶어졌다. 예전에 이클립스 OSGi 플러그인을 이용해서 개발하는 걸 열심히 해봤던 것처럼, 이제 IntelliJ의 확장 기능과 플러그인을 만드는 걸 본격적으로 해보고 싶다. IntelliJ 커뮤니티 버전은 다 오픈소스다. 거기에 IDE 핵심은 다 들어있거든, 원하면 IntelliJ 커뮤니티 버전 자체를 확장해 보는 것도 할 수 있다. 코틀린 플러그인 개발은 또 얼마나 좋은 기회가 많은지. 스프링 이니셜라이저는 사실 스프링부트 프로젝트 만들라고 제한해 놓은 도구가 아니다. 얼마든 회사 내부에서 쓰는 표준 레이아웃과 기본 구성을 가진 프로젝트를 손쉽게 생성하는 데 사용할 수 있다. 코드를 다 분석하고 이걸 어떻게 쓸지 다 설계도 해놨는데 코딩을 안 하고 10년은 미뤄온 듯하다. 해볼 게 참 많구나.

다시 도구를 만드는 재미를 느껴보고 싶어졌다. 그걸로 최종 애플리케이션을 개발하는 걸 더 잘해야겠지. 그게 아니어도, 도구를 만드는 것만으로도 충분히 즐거움을 느낄 수 있는 걸. 몇 명이라도 같이 만드는 걸 즐겨주면 좋겠고.

그럴 가치가 있다.

얼마 전에 본 김영재 님의 발표에 이런 이야기가 나온다.

문제에 적중하는 시스템이 없다면, 만들자
어떤 도구로도 우리만의 문제를 해소하지 못한다면
우리 문제를 완벽하게 해결하는 정답 같은 경험이라면
직접 만들 가치가 있다

뭐가 됐든 도구를 찾고 다듬고 필요하면 고치거나 새로 만든다.

도구의 인간, 도구의 개발자니까.

직접 만들 가치가 있다.

....

이날 프리미엄 코스는 너무 좋았다. 예약을 할 때 무슨 특별한 날이냐고 묻길래 몇 주 후에 결혼 25주년이라고 했더니 축하하는 메시지를 담아서 메뉴 노트를 준비해준 것도 고마웠고. 셰프의 제자로 일을 배우고 있는 걸로 보이는 젊은 호주 직원이 내 취향을 듣고는 추천해준 Eigashima 일본 위스키도 놀라웠다. 고급 식재료를 쓴 여러 요리가 있었지만 가장 기억에 남는 건 일본 블루핀 참치를 아삭한 호주 야채로 감싸고 바삭하게 튀긴 케이퍼를 얹은 것이었는데, 맛과 식감이 너무 감탄스러웠다. 서호주에서 난 식재료는 동부 태평양과는 다른 인도양의 해산물이라 같은 종류라도 맛이 차이가 나는게 많다고 퍼스의 스시 셰프에게 들은 적이 있는데, Takashi 셰프가 그 먼 서호주의 재료도 적절하게 활용해서 창조적인 음식을 구현해 내는 것도 인상적이었다. 계절마다 새로운 재료를 찾아서 메뉴를 새로 구성한다고 하니, 호주 겨울인 6월 쯤 다시 찾아야겠다.

36년은 아니더라도 3년 동안 만들어 다듬어왔다고 내놓을만한 도구를 하나쯤 꺼내 놓으며, 웃으면서 이야기를 들려줄 수 있게되면 좋겠다.

테스트가 관리하는 트랜잭션 - 향로 님의 @Transactional 글을 읽고

PaxCaelo — Mon, 4 Mar 2024 08:40:06 +0900

@Transactional의 테스트 사용에 관한 부정적인 이야기를 언제부터인가 듣기 시작했고, 예를 들어 안티패턴이니까 쓰지 말라는, 그게 무슨 얘기인가 궁금하던 중에 재민 님의 @Transactional 테스트 사용에 관한 영상을 보고 생각을 간단한 남겼다. 전에 향로 님이 @Transactional 롤백 테스트에 대해서 반대한다는 얘기를 어디선가 들은 기억이 나서 향로 님의 이야기도 자세히 들어보고 싶다고 남겼는데.

얼마 지나지 않아 이런 장문의 글을, 예제 코드까지 만들어서 공개를 해주셨다. 이런 감동은 오랜만이다. 함께 일하는 사람들과 오프라인에서 기술과 개발에 관한 이야기를 깊이 있게 나눌 기회가 거의 없는 나에겐 온라인에서라도 이야기를 이어갈 수 있는 이런 기회는 무척 소중하다.

https://jojoldu.tistory.com/761

테스트 데이터 초기화에 @Transactional 사용하는 것에 대한 생각

얼마 전에 2개의 핫한 컨텐츠가 공유되었다. 존경하는 재민님의 유튜브 - 테스트에서 @Transactional 을 사용해야 할까? 존경하는 토비님의 페이스북 2개의 컨텐츠에서 테스트 데이터 초기화에 @Transa

jojoldu.tistory.com

글을 읽으면서 들었던 여러 생각을 잘 정리해서 올리려고 마음을 먹었는데, 연말 바쁜 일정에, 안 쓰면 계속 안 쓰게 된다는 관성 탓에 계속 미루다가 이제 적어본다.

나는 스프링의 @Transactional을 이용한 롤백 테스트를 DB를 사용하는 테스트에 주로 사용한다. 필요한 경우엔 테스트 중에 커밋시키고 이를 클린업하는 방식의 테스트도 사용한다.

스프링 테스트의 트랜잭션 관리

스프링 테스트(TestContext Framework)는 TransactionalTestExecutionListener를 통해서 테스트가 실행되는 동안 트랜잭션을 관리한다. 스프링의 컨텍스트 테스트를 사용하고, PlatformTransactionManager 타입의 애플리케이션 빈이 구성되어 있고, 클래스 또는 메서드 레벨에 @Transactional이 지정되어 있고, 테스트가 실행하는 애플리케이션 코드가 스프링의 트랜잭션을 이용한다게 조건이다. 이 경우 스프링 테스트는 현재 테스트 메서드를 실행하는 스레드에 바인딩되는 트랜잭션을 생성하고, 테스트 메서드 실행이 끝나면 해당 트랜잭션을 롤백시킨다. 이게 흔히 말하는 @Transactional 롤백 테스트이다.

단순히 테스트 실행하고 롤백한다는 식으로만 알고 있다면, 향로 님이 만든 실패하는 테스트 케이스에서처럼 롤백이 안 된다거나 테스트가 기대한대로 동작하지 않는 경우를 만나게 될 수도 있다. 기본적으로 두 가지를 염두에 둬야한다.

첫째는 @Transactional 테스트는 애플리케이션 코드에 정의된 트랜잭션 전파(propagation) 속성이 REQUIRED와 SUPPORT 외의 것이 사용된 경우이다. 만약 REQUIRES_NEW가 사용되면 TransactionalTestExecutionListener에 의해서 시작된 테스트 트랜잭션 외에 별개의 트랜잭션이 만들어질테니 테스트 트랜잭션의 롤백으로 테스트 이전 상태로 돌리는 건 불가능할 수 있다.

두 번째는 스프링 테스트가 만드는 트랜잭션은 ThreadLocal을 이용해서 테스트 메소드를 실행하는 스레드에 바인딩되기 때문에 애플리케이션 코드에서 다른 스레드를 만들어 DB 작업을 수행하는 경우도 테스트에서 시작된 트랜잭션에 참여하도록 코드를 작성하지 않으면 추가 트랜잭션이 만들어지고, 여기서 다루는 코드는 롤백되지 않는다. 역시 향로 님이 간단한 예를 만들어서 어떤 일이 일어날 수 있는지 잘 보여주셨다. 테스트 방식에 따라 테스트 쪽에서 스레드를 추가로 만들기도 한다. 이것도 테스트 실행 스레드에 바인딩된 트랜잭션을 이용하는 롤백이 원하는 최종 상태를 만들지 못하게 할 수 있다.

이 두 가지는 스프링 테스트의 트랜잭션 관리 문서의 가장 앞부분에 등장하는, @Transactional 테스트를 사용하는 개발자라면 숙지하고 있어야할 기본적인 사항이다. 스프링 테스트에서 애플리케이션 컨텍스트를 변경하면 @DirtiesContext를 붙여야 하고, 스프링 빈은 기본적으로 싱글톤이다 수준의 상식이 아니던가?

여기에 하나를 더한다면 트랜재션의 시작과 종료가 일어나는 지점, 즉 트랜잭션 경계설정(demarcation) 위치가 테스트 메서드 실행 전후로 확장된다는 점이다. 이건 트랜잭션과 연결되는 JPA의 엔티티 매니저 생명주기를 연장시키기 때문에 테스트 결과가 거짓 음성(false negative)이 될 수 있다. 그래서 테스트에선 전혀 문제없던 코드가 사실은 JPA 관련 라이프 사이클 버그가 있어서 애플리케이션을 실행할 때 에러가 날 수도 있다. 이것도 @Transactional을 사용할 때 기억하고 주의해야 한다.

이 세 가지에 대한 주의를 기울인다면, 거의 대부분의 데이터를 사용하는 테스트에서 테스트 실행 후에 트랜잭션을 롤백한다는 방법은 매우 단순하고, 편리하고, 빠르게 데이터를 사용하는 테스트를 작성하고 수행하게 해준다. 스프링이 초기부터 테스트 트랜잭션을 관리하고 테스트 수행 후에 롤백하는 기능을 스프링 테스트에 넣은 이유이다.

요즘 개발자들은 @Transactional 테스트라고 기억하겠지만, 내가 이 방식의 스프링 테스트 트랜잭션 관리 방법을 만난 건 스프링 1.1이었고, 그때는 아직 자바 언어에 애노테이션도 없는 버전이 주로 사용되었고, JUnit 3.8로 만들어진 스프링 테스트 프레임워크를 사용하고 있을 때였다. KSUG의 기원이 된 Epril 1회 세미나에서 영회가 발표한 세션에도 이 내용이 들어있다. @Transactional이라는 애노테이션을 포인트컷 설정 방식의 하나로 추가하고 테스트의 트랜잭션 관리 방식용으로 활용하기 시작한 건 한참 뒤였다.

스프링의 테스트 트랜잭션 관리 방법은TransactionalTestExecutionListener 말고 TestTransaction을 이용하는 것도 있다. 이걸 쓰면 코드를 이용해서 세밀한 트랜잭션을 제어하면서 테스트를 수행하는 것도 가능하다. 테스트 코드 실행 중에 트랜잭션을 롤백 또는 커밋으로 세팅하고, 트랜잭션을 완료하고 다음 트랜잭션을 시작하는 등의 복잡한 작업을 간단히 수행할 수 있게 해 준다. 이걸 잘 활용하는 개발자는 아직 본 적이 없긴 하지만.

스프링 레퍼런스의 테스트 관련 문서를 찾아보면 테스트의 트랜잭션과 관련된 이런 내용이 아주 잘 정리되어있다. 스프링으로 개발하면서 테스트를 만드는 개발자라면 한 번쯤 읽어봤겠지.

우리는 트랜잭션을 테스트 하는가?

향로 님의 글에 대한 본격적인 피드백을 하기 전에 이 이야기를 먼저 하고 싶었다.

우리는 트랜잭션을 테스트하나? @Transactioanl 테스트를 쓰든 말든 상관없이, 어쨌든 DB를 이용하는 코드라면 어떤 식으로든 트랜잭션을 사용할 것이다. 그럼 정말 트랜잭션이 제대로 설정되어 있는지 테스트는 하고 있을까? 한다면 어떻게 하고 있는 걸까?

애플리케이션 코드에서 트랜잭션 위치를 @Transactional로 지정하든 TransactionTemplate을 사용해서 코드로 트랜잭션을 다루든 상관없이, 테스트에서 실행하는 애플리케이션 코드가 여러 번 데이터를 쓰거나 수정한다면, 이게 하나의 트랜잭션으로 묶여있는지 뭘로 확인하고 있나? 에러 나지 않고 JPA 관련 코드가 다 실행이 됐으니 트랜잭션이 시작되겠지라고 추정하는 건가? 당연히 트랙잭션이 없으면 엔티티 매니저의 기능이 제대로 동작하지 않고 에러가 날 테니 트랜잭션이 만들어졌겠지. 근데 그게 하나의 트랜잭션인 건 어찌 알 수 있을까? 중간에 부가적인 작업이 REQUIRES_NEW 속성으로 별개의 트랜잭션으로 돌아갔는지, NESTED 트랜잭션으로 설정해서 해당 부분만 롤백되어도 전체 트랜잭션은 커밋될 수 있는지는 어찌 아는 걸까?

나는 트랜잭션을 거의 테스트하지 않는다. 사실은 테스트 못한다. 엔티티를 5개 만드는데, 3개 만들고 에러가 나면 전체가 하나의 트랜잭션으로 묶여있어서 앞에서 추가한 데이터는 DB에 남지 않고 롤백되는지 테스트에서 검증하지 않는다.

왜냐하면 트랜잭션 자체에 대한 테스트는 매우 어렵고 번거롭고 때론 불가능하기 때문이다. 어떤 기술의 트랜잭션 관리 기능을 테스트하는 거야 적절한 학습 테스트를 만들면 된다. 하나의 트랜잭션 이어야지만 통과하는 학습용 코드와 테스트를 만드는 것이다. 중간에 예외를 강제로 던지게 만들고, 롤백되게 만드는 것이지.

근데 이걸 애플리케이션 코드는 어찌 검증할 수 있을까? 트랜잭션 매니저의 내부를 파고 들어가서 정말 모든 DB 관련 작업이 동일한 트랜잭션 안에서 일어나고 있는지 어찌어찌 확인할 방법이 있긴하겠지. 말도 안 되게 복잡한 테스트를 만들어야 하고, 프레임워크의 트랜잭션 기능을 직접 뜯어고쳐야 하겠지만. 혹은 트랜잭션이 만들어지고 사용되는 걸 확인하기 위해서 TRACE 레벨의 로그를 남겨서 눈으로 확인해 볼 수도 있긴 하다.

그런데 이걸 내가 만든, 반드시 하나의 트랜잭션으로 묶여서 동작해야 하는 코드마다 어떻게 검증할 수 있나. 하나의 트랜잭션으로 성공하는 줄 알았던 코드가 알고 보니 리포지토리 메소드 호출에서 트랜잭션이 없으면 자동으로 새로운 트랜잭션이 만들어서 에러가 나지 않아 테스트는 성공을 했는데, 실제로 여러 개의 트랜잭션으로 쪼개져 있었다면. 그래서 운영중에 발생한 문제 때문에 업데이트 중간에 예외가 발생하는 특별한 상황이 발행되면 앞의 작업은 롤백되지 않을 것이고, 심각한 데이터 오류가 방치되기도 한다. 다들 이런 경험 한 번쯤은 있지 않나? 나만 그런가.

트랜잭션 테스트는 어렵다. 차라리 @Transactional을 붙여서 잘 돌아갔는데, 애플리케이션 코드의 특정 메서드에는 @Transactional이 없어서 실제로 lazy loading으로 읽어와야 하는 엔티티를 못 가져와서 에러가 나는 상황은 쉽게 파악할 수 있고 해결하기 쉬운 것 아닌가. 그것보다 훨씬 심각할 수 있으면서 잘 드러나지 않는 트랜잭션 관련 버그는, @Transactional 테스트를 쓰지 않는 향로 님 같은 스타일의 테스트를 만든다고 쉽게 잡아낼 수 있는 게 아니다.

그래서 트랜재션 관련 실수를 하지 않기 위해서 여러 가지 가이드를 만들 수밖에 없다. 트랜잭션이 불필요하게 만들어지는 경우가 일부 있더라도 클래스 레벨에 @Transactional을 걸고 시작하고, 정적 도구와 코드 리뷰를 통해서 잘못 설정된 게 없는지, 전파 속성이나 고립도에는 문제가 없는지, 데드락이 발생할 수 있는 위험이 있지 않는지 계속 살피는 수 밖에 없다. Spring Data처럼 트랜잭션을 앞에서 시작하지 않아도 알아서 트랜잭션을 매번 따로 만들어주는 오지랍 기술 따위는... 하아, 이걸 끄는 방법을 찾겠다고 마음먹은 지 한참인데 요즘 너무 게을렀지.

아무튼 테스트에서 트랜잭션과 관련된 얘기가 나오고, @Transactional 때문에 예상치 못한 버그를 미리 못 막아서 놀랐다는, 그래서 아예 안 쓰겠다는 선택을 했다는 분들을 보면, 그 PTSD가 한편 이해가 되면서도, 과연...

향로 님의 예제에 나온 @Transactional 테스트가 실패하는 경우

REQUIRES_N EW

스프링의 테스트 관리 트랜잭션은 REQUIRED, SUPPORT 외의 전파 속성을 사용하는 경우에 별개의 트랜잭션이 만들어져 그쪽 데이터는 롤백이 되지 않을 수 있다. 그러면 테스트 메소드에서 트랜잭션을 커밋시키고(@Transactional(propagation=NEVER), @Commit 등등) 테스트에서 생성한 데이터를 정리하는 방법을 쓰면 된다.

그런데, 테스트를 작성하는 개발자가 자신이 다루는 코드에서 REQUIRES_NEW를 사용하는지 굳이 알 필요가 있을까. 굳이 그걸 의식하고 어떤 경우에는 테스트 후 커밋된 데이터를 정리하는 코드를 넣어야 하는거냐고 질문을 할 수 있을 텐데. 나는 알아야 한다고 생각한다. 자신이 만든 코드를 테스트하는 개발자 테스트를 작성하는 사람이라면, 기본적으로 블랙박스 테스트를 지향해야 하지만, 사용 기술에 관해선 화이트 박스 테스트로 만들 수도 있어야 한다.

REQUIRES_NEW를 쓰는 경우가 흔한가? 배치 특성을 가진 작업이나, 특별한 상황에서도 분리시켜서 성공 시키거나 독립시켜야 하는 멀티 트랜잭션 전략이 필요한 경우에 아주 가끔 사용될 수 있다. 일반 서비스 애플리케이션을 개발하는 경우 한 번도 경험해보지 못한 개발자도 많을 것이다. 그래도 JPA 학습할 때 필수로 한 번쯤 들어보는 것이니 필요한 경우에 사용하면 되긴 하지.

REQUIRES_NEW가 호출되기 전에 이미 REQUIRED 트랜잭션이 있거나, 반복적으로 REQUIRES_NEW를 호출하기도 할테니, 대부분 여러 개의 트랜잭션이 만들어진다. 트랜잭션이 어떤 식으로 만들어지고 동작하는지에 대한 검증은 없이 최종 결과만 달랑 테스트하는 코드를 만들고 만족할 것인가? 이 정도 수준의 트랜잰션 관리를 한다면 한 차원 높은 테스트 대상 코드에 대한 이해가 있어야 할 것이고, 그에 대한 테스트도 치밀하게 만들어야 한다.

몰랐는데 REQUIRES_NEW가 @Transactional 테스트가 실행하는 코드 내부에 있어서, 롤백이 안 되고 데이터가 남아서 다음 테스트에서 문제가 될 수도 있으니 @Transactional 테스트를 쓰지 말자, 이건 너무 성급한 결론 아닐까. 문제를 해결할 간단한 방법(REQUIRES 사용 테스트에선 커밋 테스트 후 데이터 정리)이 있는데 전체를 다 포기한다는 건, 영한이 말대로 빈대 잡으려다 초가삼간 다 태운다는 게 아닐런지.

비동기 메서드

간단한 예를 보여주는 용도로 충분하다고 인정해 주기에 향로 님의 예제에 나오는 CompletableFuture를 이용하는 코드는 많이 아쉽다. 기껏 CompletableFuture를 async로 만들고는 get()으로 블록킹 하는 코드라니. 이게 무슨 비동기 코드란 말인가. 스레드만 바꿔치기한 거 아닌가. WebFlux 였다면 BlockHound가 에러라도 냈을텐데 말이지. 차라리 스프링의 @Async를 써서 백그라운드에서 동작하는 별개의 작업을 병렬로 돌리는 테스트를 했다면 코드 레벨에서 여러 시도를 해보면서 흥미로웠을 것이고. 게다가 스프링 데이터가 만드는 리포지토리가 아니라면, 다른 스레드에서 리포지토리 사용하려고 하는 순간 트랜잭션이 없다고 에러가 나서 문제가 뭔지 금세 알게 될 거다.

스프링 테스트 관리 트랜잭션의 두 번째 주의사항인, 테스트에서 만들어지는 트랜잭션은 현재 테스트 스레드에 바인딩된다는 조건을 알고 있다면 이런 경우에 대해서 다른 대책을 가질 수 있었을 것이다.

테스트와 비동기라고 하면 내 생각엔 두 가지 경우가 떠오른다.

이런 식의 CompletaleFuture가 아니라 본격적인 WebFlux의 스케줄러가 사용되는 비동기 코드를 테스트한다고 해보자. 리액티브는 동기 스프링 MVC에서도 90% 기능이 사용될 수 있다. 굳이 이런 식의 비동기 코드가 필요하다면 스프링 리액티브 코드를 쓰면 된다. 스프링은 WebFlux에서 여러 스레드를 넘나들면서 하나의 요청을 비동기-논블록킹으로 처리하는 코드에 대한 트랜잭션 지원 기능을 제공한다. 그러니 이런 시나리오에도 사실 트랜잭션 문제가 없다.

리소스 최적화를 위한, 혹은 push 방식의 스트림을 처리하기 위한 리액티브 코드가 아니라 정말 병렬로, 혹은 백그라운드에서 비동기적으로 요청을 처리하면서 데이터를 건드리는 코드인 경우는 그러면 어쩔 것인가? 결국 커밋 테스트를 만들고 직접 데이터를 지워야 하려나?

이것 테스트 입장에서 생각해 볼거리가 많다. 테스트가 애플리케이션 코드를 실행했는데 중간에 스레드가 추가되어 별도의 작업이 시작된다. 테스트는 언제 그 결과를, 어떻게 검증해야 할까? 애플리케이션에서 웹 요청에 의해서 @Async 백그라운드 작업이 실행되는 경우, 보통 클라이언트에 바로 응답을 한다. 데이터를 건드리는 백그라운드 작업을 진행시키고 나서 최종 결과를 테스트에서 확인하려면?

어떻게든 새로 만들어지는 스레드의 정보를 받아서 해당 작업에 다 끝날 때까지 기다렸다가 최종 결과를 DB에서 확인하면 되긴하겠지. 그런데 왜 굳이 별도의 쓰레드를 돌리는 걸까? 그건 대부분 그 작업이 시간이 오래 걸리는 백그라운드에서 실행되다가 언젠가 종료되기만 하면 충분한 작업이라서겠지. 근데 테스트에서 새로 만들어진 스레드 정보를 가져와서(어떻게?) 종료될 때까지 대기했다가 결과를 테스트한다는 건, 과연 좋은 방법일까?

나라면 차라리 이렇게 하겠다. @Async 메서드를 mock으로 만들고, 호출되는지만 테스트한다. 그리고 @Async가 붙은 메소드를 테스트에서 직접 실행한다. 프락시가 생기지 않게 간단히 테스트 컨텍스트를 세팅하면 별도의 스레드 풀에서 동작하지 않는, 테스트와 같은 스레드에서 동작하는 코드가 될 거다. 그리고 그 작업의 결과를 롤백 테스트로 확인한다. 그러면 역시 별 문제가 없을 것 같은데.

그런데 이런식으로 비동기 실행한 작업의 결과를 get()으로 대기하는 코드를 누군가 만들었다면 코드 리뷰 때 세게 지적해서 그런 쓸데없는 방식을 쓰지 않게 변경할 것이고, 혹시 성능을 위한답시고 병렬로 스레드 풀을 돌려서 작업을 수행하면서 그 안에서 DB를 건드리는 코드라면, 당장 순차적인 코드로 바꾸라고 하겠다. IO 바운드된 코드를 왜 쓸데없이 쓰레드 풀을 만들어서 병렬로 돌리냐는 잔소리와 함께.

그래도, 어쩌다 보니 꼭 필요한 비동기 작업과 그 결과를 테스트하는 극히 드문 케이스가 나오면, 테스트 끝내고 그 안에서 일어난 DB 변경사항을 돌려놓는 코드를 넣으면 그만이고.

TransactionalEventListener

이것도 예상했던 내용이다.

먼저 이 얘기로 시작하고 싶다. 그냥 실행하면 되는 코드를 굳이 이벤트를 던지고, 그게 꼭 트랜잭션이 완료되어야만 실행되게 만들어야 할까? 그런데 이벤트를 던지는 코드에 대해서 테스트 하면서 그 이벤트를 구독해서 동작하는 쪽의 작업까지 테스트를 해야 하는 건가?

간혹 스프링의 이벤트 기능을 쓰면서, 이 이벤트로 인해서 어떤 코드가 실행이 되는지 꼼꼼히 메모해 놓는, 심지어는 이벤트 클래스의 javadoc에도 넣는다는 개발자의 이야기를 들은 적이 있다. 아니 도대체 왜 그러는 걸까. 나는 이벤트의 발행, 구독 모델을 즐겨 쓴다. 이걸 통해서 이벤트를 던지는 쪽과 이를 받아 쓰는 쪽의 결합도를 낮추는 것이 목적이다. 이벤트를 발행하는 코드는 이것 때문에 어떤 일이 일어날지에 대해서, 구독을 하든, 하다 말든, 트랜잭션을 끼고 하든, 외부 이벤트 서비스로 던져서 다른 서버에서 받든, 상관없이 그저 내가 한 일에 대해서 통보하고, 그걸 사용하는 코드는 알아서 하라는, 나는 내 할 일과 책임은 여기 까지라는 깔끔한 분리 때문에 그렇게 만든다.

그렇다면 이벤트를 발행하는 코드를 테스트할 때 이걸 구독하는 코드가 잘 실행되는지, 그리고 그 결과로 어떤 추가 작업이 일어나는지도 검증해야 하는 건가? 음.. 그럴 수도, 아닐 수도 있겠다.

트랜잭션이 완료되는 시점에 추가 작업이 일어나야 한다, 그걸로 상태가 변하고, 심지어 DB도 변경되어야 한다, 그래서 그걸 테스트에서 검증하고 싶은데 @Transactional은 롤백을 해버리니 그 동작이 일어나지 않는다는 게 요지일 텐데. 나는 왜 이걸 테스트해야 하는지부터 진지하게 생각해 보자고 하고 싶다.

트랜잭션이 끝나면 실행되게 만드는 작업은 기능적으로 메인 트랜재션 흐름에서 벗어난, 느슨하게 분리하고 싶은 작업일 수 있다. 이런 경우 굳이 스프링의 @TransactionalEventListener를 썼더니 정말 트랜잭션이 끝나면 리스너 메소드가 동작하네, 이걸 확인해보고 싶은 게 아니면, 그냥 그것도 테스트에서 호출해 버리면 되지 않을까? 나는 일단 롤백 테스트를 걸고 그 방법부터 생각해 보겠다. 트랜잭션이 끝났으니 로직을 처리하는 중에 데이터를 건드려야 하는 작업을 더 하지는 않을 것이고, 서버의 메모리에 있는 오브젝트의 상태를 건드려두고 다음에 참고하는 식의 코드 따위도 만들지 않을 테니, 아마도 다음 두 가지의 경우가 많지 않을까 싶은데.

하나는 메인 작업이 끝나면 외부 서비스를 호출하거나 통합하는 등의 작업을 수행하는 경우. 사용자가 등록됐다고 외부에 API를 이리저리 쏴야 하는데, 이때 트랜잭션을 계속 물고 있으면 낭비가 된다. 사실 트랜잭션을 커밋하고도 커넥션을 물고 있기만 해도 낭비다. 0.1초에 메인 작업을 끝냈는데 외부 서비스에 메일을 보내고, API를 쏘는데 1초가 걸리면 쓸데없이 10배 낭비가 되겠지. 그러니 빠르게 트랜잭션을 완료시켜서 DB 리소스를 해제해 주고, 아마도 @TransactionalEventListener를 @Async까지 걸어서 현재 웹 요청은 빠르게 응답해버리고, 부가 작업은 @Async 스레드 풀의 큐에 넣어두고 차근차근 처리하게 만드는 방식이 대부분이 아닐까 싶다.

다른 건, 메인 트랜잭션에 묶지 않지만 또 다른 부가적인 DB 작업을 수행하는 경우이다. 로그나 통계성 정보를 업데이트한다거나, 아무튼 뭐가 됐든, 역시 웹 요청에 대한 메인 작업이 끝났으면 빨리 응답을 해버리고, @Async 풀을 이용해서 단계적으로 다음 데이터 처리 작업을 수행한다. 이건 메인 트랜잭션과 묶이지 않았으니 부가 작업이 실패로 끝날 수도 있기도 하다.

아무튼 @TransactionalEventListener가 호출되는가를 검증되는 게 과연 테스트에서 중요한가? 이게 첫 번째 질문이고.

그리고 @Async를 쓴다면 역시 테스트에 의해서 비동기 작업이 실행될 때 발생하는 위해서 언급한 비동기 관련 테스트의 고민이 시작된다가 두 번째.

@Async의 스레드 풀의 코어 사이즈가 충분하지 않으면 큐에 대기를 한다. 테스트가 실행되는 조건 따라서 @Async가 붙은 @TransactionalEventListener 메소드는 테스트 메소드가 끝날 때까지 작업이 완료되지 않을 수도 있다. 이러면 어떻게 검증할 건데.

향로 님의 예제에서는 매우 아쉽게도 이벤트 리스너를 mock bean으로 만들어서 얘가 호출되는가만 체크했다. 뭐 그게 중요하고 전부일 수도 있겠지. 하지만 나라면 그런 테스트를 만들지 않을 것이다. Mock bean으로 만들면 내부에서 동작하는 기능에 대한 검증도 포기하겠다는 것인데, 그러면 @TransactionalEventListener 애노테이션이 잘 붙어있는지에 대한 테스트일까.

리스너 내부에서 DB와 관련된 작업을 @Async로 수행한다면, 이것 또 다른 차원의 검증을 요구하는 것일 테고. 잘 알려진 대로 트랜잭션널 이벤트 리스너에서 DB 트랜잭션을 또 시작하려면 REQUIRES_NEW 등을 활용하는 새로운 트랜잭션을 강제로 만드는 작업이 요구된다.

어떻게든 테스트에서 실제 애플리케이션이 동작하는 상황과 똑같은 순서로, 똑같은 방식으로 동작하는 걸, 그 특성을 다 살려서 테스트하기란 매우 어렵다. 가능은 하지만 비싸다. 그만큼 완벽한, 이후에 테스트만 성공하면 아무 문제가 없다는 확신이 들만한 테스트 코드를 만들기 위해 어디까지 노력을 해야하는 것일까.

테스트에 대한 생각 정리

쓰다 보니 향로 님의 글에 대한 반대 내지는 반박 비슷하게 보이기도 할 텐데, 나는 향로 님의 의견을 존중하고 상당부분 동의한다. 혹시 내가 중간에 참여하는 개발팀이 이미 향로 님 스타일로 테스트를 만들고 있다면 계속 그렇게 개발하자고 할 수도 있다.

하지만 스프링 테스트를 사용하는 개발자라면 스프링 테스트가 관리하는 트랜잭션 방식을 따라 @Transactional 테스트를 기본으로 쓰고, 주의할 상황을 잘 이해하고, 필요한 경우 데이터를 초기화하는 커밋 테스트도 만들면서, 심지어 TestTransaction을 이용해서 하나의 테스트에서 여러 개의 트랜잭션이 만들어지고 복잡하게 돌아가는 테스트도 만들 수 있어야 한다고, 그게 기본이면 좋겠다고 생각한다.

근본적으로 테스트는 애플리케이션 코드를 완벽하게 검증하고 모든 문제를 미리 다 파악할 수는 없지만 최선을 다해서 좋은 코드를 만드는데 도움을 주는 중요한 도구라는 생각을 한다.

향로 님 방식의 테스트로 기본적인 문제를 풀고, 어떤 기술적인 부분에 대해선 깊이 이해하지 않고도 손쉽게 테스트를 하면서 개발을 할 수 있겠지만, 다양한 트랙잭션을 검증하는 테스트로는 완전하지 않으며, 몇 가지 제약 사항도 있고, 불편함도 있다고는 해야겠다.

테스트가 끝날 때마다 메타 데이터를 읽어서 테이블을 다 초기화시키는 것, 나중에 테이블 개수가 많아지고 테스트 중에 넣는 데이터가 많다면 이건 테스트 성능을 떨어뜨릴 수 있을 것이다.

테스트 수행 성능이라면 테스트용 메모리 DB를 사용하면 된다고? 나도 좋아하는 방식이긴 하지만, 이거야말로 테스트와 애플리케이션이 실행되는 시점에 차이를 가져올 수 있는 숨은 폭탄이기도 하지 않나. 데이터 테스트를 완벽하게 통과하지만 실제 사용되는 DB에서는 미묘한 문제를 일으키거나 최적화된 SQL 작업을 못하게 하거나, 그걸 억지로 구분해서 넣는다면 테스트를 실행하는 조건이 매우 복잡하게 만들어버리는.

또 테스트에서 만든 데이터만 삭제하는 게 아니라 전체 테이블을 날리는 방식으로 하기 위해서 FK 제약조건을 빼버린다. 그게 테스트를 위한 것이고, 모든 데이터는 JPA를 통해서만 등록된다는 전제를 깔면 된다고 하겠지만 그러기엔 너무 위험하지 않나. 테스트용 스키마만 그런다면 모르겠지만, FK 제약 조건을 무조건 다 빼는 데는 나는 아직 찬성할 수 없고, FK가 깨진 데이터가 들어가고 그걸 잘못 만져서 매우 처치 곤란한 장애를 수도 없이 만나본 경험을 떠올린다면, @Transactional을 안 쓰겠다고 FK를 뺀다는 주장은, 물론 다른 이유로 FK 제약조건을 제한하는 것에 대해서는 동의하지 못하는 건 아니지만, 받아들이기 쉽지 않네.

마지막으로 테스트에서 항상 커밋하고 데이터를 다 초기화하는 방식으로 테스트를 만들면, 시드 데이터를 기준으로 테스트를 만드는 게 어려워진다. 나는 어느 정도 모델이 정리되고, 테스트를 위해 의미 있는 데이터가 준비되면, 테스트 실행 전에 기본 데이터를 로딩하고, 그 데이터에 대해서 @Transactional 테스트를 작성하는 방식을 선호한다. 매번 코드로 테스트에서 사용할 데이터를 준비하는 것은 언젠가 한계가 있다. 그런데 매번 테이블을 다 날려버리면 매번 테스트용 시드 데이터를 테스트마다 로딩하란 말인가? 롤백 테스트가 주는, 초기 DB 상태를 계속 유지하게 만드는 방식이 얼마나 편하고 빠른데.

향로 님의 정성스러운 글과 코드에 성의를 보이려고 오래간만에 길게 글을 적어봤다. 아무튼 피드백을 할만한 좋은 글을 남겨주셔서 다시 감사하고, 언젠가 오프라인으로 더 이어지는 얘기를 해봤으면, 혹은 내 유튜브 방송에서도 해도 되겠지.

그 외에도 데이터를 사용하는 테스트에 관해서 하고 싶은 얘기가 많긴 한데, 작년에 부러진 손가락이 아직도 말썽이라 글을 길게 쓰기도 쉽지 않구나. 차차 적어보자.

참, 이건 이번에 알게 된 건데, 스프링 테스트에서 트랜잭션 전과 후에 검증을 위해서 사용되는 메서드에 붙이는 @BeforeTransaction, @AfterTransaction이 있는데 스프링 6.1부터는 이 두 가지 애노테이션이 붙은 메소드에 파라미터를 넣을 수 있게 되었다고 한다. 그러니까 테스트 컨텍스트의 빈을 주입받을 수 있다는 건데, 뭔가 활용해보고 싶은 아이디어들이 떠오른다. 트랜잭션 전의 데이터 상태와 후의 데이터 상태를 검증하는 용도인데, 위의 롤백 테스트임에도 데이터가 남는 경우에 이를 확인하고 처리하는 코드 같은 걸 넣을 수 있지 않을까 싶기도 하고.

코드 한 줄 없이 말로만 떠들었더니.. 아쉬워서 스프링 테스트의 트랜잭션 관련 애노테이션이 나온 코드를 남겨본다. 스프링 레퍼런스에 있는 코드다.

@SpringJUnitConfig
@Transactional(transactionManager = "txMgr")
@Commit
class FictitiousTransactionalTest {

	@BeforeTransaction
	fun verifyInitialDatabaseState() {
		// logic to verify the initial state before a transaction is started
	}

	@BeforeEach
	fun setUpTestDataWithinTransaction() {
		// set up test data within the transaction
	}

	@Test
	// overrides the class-level @Commit setting
	@Rollback
	fun modifyDatabaseWithinTransaction() {
		// logic which uses the test data and modifies database state
	}

	@AfterEach
	fun tearDownWithinTransaction() {
		// run "tear down" logic within the transaction
	}

	@AfterTransaction
	fun verifyFinalDatabaseState() {
		// logic to verify the final state after transaction has rolled back
	}

}

토비의 스프링이 나오기까지

PaxCaelo — Sat, 13 Jan 2024 13:31:15 +0900

2010년에 책이 나온 뒤에 블로그에 썼던 토비의 스프링이 나오기까지라는 글을 모두 옮겨봤다. 길다.

토비의 스프링 3이 나오기까지 (1)

원고에서 손 뗀지 얼마 안됐는데 벌써 책 내용도 가물가물하다. 그러니 책을 써온 그 동안의 기억도 금세 사라지겠지. 더 잊기 전에 책을 써왔던 이야기를 적어놔야겠다.

IT서적은 국민학교 5학년 때부터 교보문고 컴퓨터 서적 코너에 수시로 들락거리면서부터 꾸준히 읽고 공부하기 시작했으니 대충 27년쯤 읽어온 것 같다. 하지만 한번도 내가 직접 책을 써볼까 하는 생각을 해본 적은 없다. 그래서 2006년 어느날 당시 마소 기자였던 희용이(지금은 마소 발행인이자 마소 인터렉티브 사장)가 "형 책 한번 써볼 생각 없어?"라고 지나가는 말로 물어봤을 때도 별 생각 없이 "기회되면 한번 해보지"라고 대답했던 것 같다. 누가 부탁하면 거절을 못하는 못된 습성 때문에 "안 써"라고 말할 수는 없었기 때문이었을 것이다. 그리고 어느날 희용이가 강남에서 출판사 관계자와 함께 만나자고 했을 때도 별다른 생각없이 희용이 얼굴이나 한 번 보려고 나갔다.

그날 에이콘 출판사의 김희정 편집장님(지금은 부사장님)을 처음 만나게 되었다. 한국 IT서적은 97년에 삼각형 출판사에 여러번 크게 데인 뒤로 다시는 국내 서적은 보지 않겠다고 결심하고는 10년간 전혀 읽지 않았다. 99년에 해외로 나갔으니 더더욱 한국 책은 볼 기회가 없었다. 그래서 국내 IT서적 출판사가 어떤 곳이 있는지 알지도 못하던 때였다. 당연히 에이콘 출판사는 이름도 들어보지 못한 곳이었다. 어쨌든 희용이가 잘 알고 친하게 지내는 곳이라고 해서 만남을 가졌다.

처음 만났던 김희정 편집장님은 말투는 상냥하지만 좀 차갑게 느껴졌다. 인사를 하고 식당으로 가서 식사를 하면서 처음 받은 질문이 아마 "책을 쓰실 수 있겠어요?"였을 것이다. 나는 희용이 소개로 그냥 인사나 하려고 만난 것이라고 생각했는데, 당시 받은 느낌은 내가 책을 내고 싶어서 출판사에 소개시켜달라고 해서 만난 것 같은 상황이었다. 게다가 출판사 편집장님의 눈빛이나 말투는 "정 기자가 소개를 해줘서 한번 만나기는 하지만, 어디서 이름도 못들어본 사람이 책을 내겠다고 하는데 과연 제대로 쓸 수나 있을까? 실력은 있는 것일까?" 하는 의심에 찬 것이었다. 물론 예상치 못한 질문에 당황한 나머지 그런 인상을 받았을 뿐 김희정 편집장님은 그런 뜻은 전혀 아니었겠지만.

아무튼 "네까짓게 책을 쓸 수 있어"라는 도전을 받은 듯한 느낌이 드니 오기가 발동했던 것 같다. 그래서 스프링이 얼마나 좋은 기술이고(당시만 해도 스프링 얘기를 꺼내면 다들 우습게 보던 시절이었다. 스트럿츠1 때문에 한국에서 스프링은 뜰 수 없다고 얘기하고 다니는 유명한 자바 개발자도 있었다. 오픈소스 기술은 절대 엔터프라이즈 개발에 쓸 수 없다고 블로그에 와서 훈계하고 가는 사람들도 있었다) 앞으로 전도 유망한지 열심히 얘기했던 것 같다. 아마 그런 열정을 보여서일까 그날 얘기는 긍정적으로 생각해보자는 선에서 마무리된 것 같다.

당시에 나는 카이스트의 모 프로젝트에서 스프링을 이용한 애플리케이션 프레임워크 개발을 책임지고 있던 시절이다. 2004년에 시작한 미국 프로젝트를 마치고 호주에 다시 돌아가려고 하던 차에 물개 승권이의 꼬임에 넘어가서 카이스트 프로젝트에 참여하게 되었다. 원래 한달만 참여해서 아키텍처만 잡아주면 된다는 것이 조건이었는데, 물개의 물귀신 신공에 넘어가서 한달이 6개월이 되고 6개월이 다시 일년이 되고, 2년도 되고 그러던 시절이었다. 사실 마소에 글을 쓰고 정기자를 알게된 것도 마소에 글쓰기가 귀찮아진 물개가 나한테 얼렁뚱땅 떠넘겼기 때문이다. 얼마나 원고 쓰기가 싫었던지 막판에는 내 블로그 글을 긁어다가 기사로 그대로 낸 적도 있는데(나한테는 일방적으로 통보만 해주고) 아마 그때 미안했는지 마소에 나를 추천해준 것이 정기자를 알게된 계기가 되었다.

그리고 그 해 겨울에 미국에서 열린 두 번째 스프링 컨퍼런스인 The Spring Experience 2006에 처음으로 참석하게 되었다. 담당 PM이 당황해서 프로젝트 중에 어디 가면 안된다고 말렸지만, 안보내주면 때려치겠다는 내 협박에 못이겨서 컨퍼런스 참여로 시간을 비우는 1주치의 급여를 받지 않는다는 조건으로 다녀올 수 있었다. 컨퍼런스 참가비와 여비, 못받은 급여 등을 합해보면 600만원 정도의 개인 비용을 투자한 셈이었다. 하지만 정말 10원도 아깝지 않은 시간이었다. Eric Evans를 만났고, 새로운 기술을 배운 것도 좋았지만 그보다는 전 세계에서 몰려든 스프링 개발자들과 교제하면서 그들의 실력과 열정에 도전 받게 된 것이 더 좋았다.

컨퍼런스에 다녀오는 내내 책을 어떻게 쓸까 하는 생각을 많이 해봤다.

기존에 봤던 스프링 책들은 모두 장단점이 있었다. 로드 존슨의 J2EE Development without EJB는 절반은 왜 EJB의 대안이 필요한지 설명하는 내용이었고, 나머지 절반도 스프링의 기초 개념만 살짝 다룬 책이라 실무에 적용할 구체적인 지식을 얻기는 힘들었다. 그래서 without EJB는 최초의 스프링 책이라고 볼 수도 있고, 아닐 수도 있다. 제대로된 최초의 스프링 기술 서적은 Spring in Action일 것이다. 하지만 SiA는 내가 궁금한게 많고 관심을 많이 가졌던 SpringMVC를 제대로 다루지 않아서 크게 실망한 책이었다. 600여페이지 밖에 안되는 얇은 책 주제에 Acegi니 Struts 같은 내용이 잔뜩 자리를 차지하고 있는 것을 보고 실망한 나머지 책을 구입한지 3일 만에 구석에 처박아 두고 다시는 보지 않았던 책이다.

당시엔 스프링 레퍼런스 문서는 100페이지도 안되는 얇은 분량이었다. 역시 SpringMVC에 관한 내용은 별로였다. 그래서 초기에 스프링에 대한 정보를 얻을 수 있는 거의 유일한 통로는 로드 존슨도 열심히 활동하던 스프링 사용자 포럼과 스프링 소스 코드였다. 어쩌면 스프링 소스를 들여다 볼 생각을 하고 거기서 많은 정보를 얻을 수 있다는 것을 알게된 것은 초기에 빈약한 스프링 관련자료와 서적 덕분이었을 것이다.

내가 가장 만족하면서 읽었던 스프링 책은 롭 해롭의 Pro Spring 1판이다. 2판은 저자가 바뀌면서 내용이 부실해져서 많은 원성을 들었지만, 1판은 정말 최고의 책이었다. 컨퍼런스에서 만났던 다른 스프링 개발자들에게 물어보면 다들 Pro Spring을 최고의 서적으로 꼽았다. 내가 Pro Spring에서 가장 좋았던 것은 단순히 스프링의 기술 사용방법 뿐 아니라, 그 원리와 기본이 되는 동작방식을 잘 설명해준 것과 POJO를 이용한 비즈니스 로직 작성의 중요성을 알려준 것이었다.

스프링 주요 개발자들이 함께 쓴 Professional Spring Framework도 물론 좋았다. 이 책에 나온 "스프링의 정수(essence)는 POJO에 엔터프라이즈 서비스를 적용시켜주는 것”이라는 설명은 지금도 내가 스프링을 설명할 때 자주 인용하는 것이다. 스프링이 POJO 프로그래밍을 위한 도구임을, 가장 중요한 것은 POJO로 만들어진 환경과 기술에 독립적인 애플리케이션 코드라는 것을 잘 알려주는 책이다. 이 책에서 가장 흥미롭게 본 것은 AOP다. AOP가 프록시 기술을 바탕으로 어떻게 만들어지고 적용되는지 매우 깊이있게 다뤄 준다. AOP가 어디선가 갑자기 떨어진 외계 기술이 아니라 자바의 고급 활용법에 불과하다는 것을 여기서 처음 알게되었다.

여러 가지 특징을 가진 스프링 책이 이미 존재하고 있고 또 계속 나오고 있는데, 과연 나는 어떤 책을 쓸 것인지, 어떤 독자를 대상으로 해야 할지 등등 여러가지 생각만 하면서 2007년을 맞았다.

토비의 스프링 3이 나오기까지 (2)

하늘이가 태어난 뒤로 아침에 평화를 준비시키고 도시락을 싸서 유치원에 데려다주는 것은 내 몫이다. 낮과 밤에 잠을 재우는 것도. 거기에 하늘이 분유 타는 것도 내 담당이다. 지난 밤처럼 2시에 먹고 아침까지 잔 날은 정말 해피하지만, 2-3시간마다 계속 깨는 날은 잠을 제대로 자기도 쉽지 않다. 동생이 생긴 뒤로 스트레스를 받아서 그런지 사소한 일에도 쉽게 울먹이는 평화랑 틈틈이 놀아주는 것도 큰 일이다. 장모님이 오셔서 많은 것을 도와주시기는 하지만 아내가 입덧을 심하게 하던 올 초 만큼 신경쓸게 많고 바쁘기도 하다. 그래도 뭔가가 마무리 된 후의 일인지라 마음은 참 편하다. 책 쓰는 것도 비슷하다. 책을 쓰는 중에 받는 스트레스와 쓰고 난 뒤에 받는 스트레스는 강도가 비슷하더라도 이를 상대하는 마음의 여유가 다르다.

다시 희미한 기억을 더듬어서 쉽지 않았던 시간 속으로 돌아가보자. 책을 쓰는 동안의 이야기를 적는 이유는 내 블로그가 원래 그런(내 삶의 기록을 남기는) 용도이기 때문이다. 그리고 이제 이 책에서 관심을 끊기 위해서다. 책을 마무리 할 때까지 가지고 있던 계획은 편집까지 마치면 예제에 대한 빠진 설명을 적고, 책을 쓰게 된 이야기를 적고 그리고 잠적하는 것이었다. 사실 하늘이가 생기기 전에는 호주 일주 여행을 떠나는 게 원래 계획이었다. 하늘이를 가진 것을 알고는 낳기 전에 시드니 여행을 다녀오는 것이었다. 하지만 책보다 하늘이가 먼저 나와버렸다. 아쉽지만 여행은 취소. 3×7일이 지나면 평화 데리고 바닷가에 연이나 날리러 가야겠다.

다시 어설픈 기억을 더듬어서 2007년 초로.

2006년은 물개 덕분에 여러가지 새로운 경험을 많이 했던 해였다. 사실 물개가 아니었으면 나는 한국에 체류할 일도 없었을테고 책을 쓸 기회도 없었을 것이다. 한국의 자바 커뮤니티와는 전혀 교류가 없던 나를 여기 저기 소개해주고, 추천해주고, 가끔 자기가 귀찮은 것을 떠밀어 맡기기도 하면서 그렇게 2005, 2006이 흘러갔다. JCO에서 발표를 하게 된 것도, 기묘에서 스프링 2.0 세미나를 하게된 것도, 마소에 기고를 하게 된 것(물개는 마소에 나를 두 번이나 추천해줬는데, 한번은 2005년에 기술 컬럼 담당으로, 다음 번은 편집진이 모두 교체된 뒤에 새로 들어온 정희용 (당시)기자에게 소개해준 것이다. 두 번 다 자기가 하다가 귀찮아져서 떠 넘긴 것으로 의심하고 있으나 사실은 순수한 의도로 그랬을 수도 있다)도 다 물개 덕이기도 하고 물개 탓이기도 하다. 잘 되면 물개 덕이고 안되면 물개 탓. 아무튼 물개의 농간에 넘어가서 점차로 한국의 개발자들을 알게 되고 마소의 정희용 기자도 알게 되고 에이콘 출판사의 김희정 편집장님도 알게 되고 하면서 2006년이 지나갔다.

그리고 내 인생에서 가장 바쁘고 정신없던 2007년이 시작됐다. 한국에서 장기간 체류하기로 결심하게 된 결정적인 계기는 사실 카이스트 프로젝트가 아니었다. 그건 1달, 6개월, 1년 하는 식으로 계약을 늘려갔기 때문에 나는 언제든지 빠져도 뭐라고 할 수 없는 상황이었다. 반면에 부모님의 권유는 거절하기가 힘들었다. 우리 부부는 결혼한지 7년 가까이 되던 그때까지 아기가 없었다. 나름 유명한 한의원에서 약도 먹어보고 호주에서 클리닉도 가봤지만 아이가 쉽게 생기지 않았다. 뭐, 안 생기면 말지라고 생각하긴 했지만, 그래도 아내가 다른 사람의 아이들을 끔찍히 이뻐하는 모습을 보거나 쇼핑몰의 아동복 코너를 지나가면서 옷이 참 이쁘네 하고 말할 때면 가슴이 아팠다. 2대 독자인 아들이 아이를 가지지 않는 것을 안타까워 하시는 부모님, 특히 엄마의 권유로 불임치료 강국이라는 한국에서 한 번쯤 시도는 해봐야겠다는 생각을 했다. 적어도 일년쯤은 시도를 해보고 그래도 안되면 포기해야지라는 생각을 했고, 그만큼은 한국에서 체류할 생각으로 대전에 내려가서 프로젝트에 참여한 것이다.

역시 세계 최고라는 한국의 불임치료 의술은 놀라웠다. 호주에서는 1년쯤 걸려서 천천히 강도를 높여가는 과정을 단 3주만에 패스. 다음 단계로, 다음 단계로. 그러더니 2006년 중반에 병원 다닌지 채 일년이 안되서 첫 임신을 했다. 하지만 안타깝게 첫 임신은 실패로 끝났다. 어느 정도 몸을 추스리면서 서서히 재시도를 하고 있던 2006말 우연히 알게된 한 교수님의 소개로 나와 아내는 국제적인 학교설립 프로젝트에 자원봉사자로 참여하게 되었고, 당시 카이스트 일을 파트타임으로 돌리고 S사 프로젝트를 준비하느라 바쁜 나를 대신해서 아내가 2007년 1월에 평양에 회의참석차 다녀오게 되었다. 지금이야 정치적인 상황이 복잡하지만 당시만 해도 남-북 분위기는 나쁘지 않았고, 북한은 호주의 정식 수교국가여서 비자를 받아서 쉽게 들어갈 수 있었고, 평양 방문(개고기 시식을 포함한)은 호주 교민들이 선호하는 인기 여행상품이기도 했다. 평양 방문 전에 시술을 했던 터라 혹시나 하는 생각에 돌아오자마자 검사를 해봤다. 두 번째 임신이었다.

새해 초부터 정신없이 시작된 2007년은 정말 새로운 일과 도전거리로 가득찬 버겨운 시간이었다. 아내는 입덧이 심해져서 일을 중단하고 서울 친정에 와서 지냈고, 나는 대전과 서울을 오가면서 두 개의 프로젝트를 진행하면서, 틈틈히 유지보수 프로젝트도 두 개를 더 하고 있었고. 영회를 포스트로 넣어두고 나는 밖으로 돌면서 여유있게 진행하려고 했던 S사 프로젝트는 프로젝트 진행 결재까지 나고 계약서도 들어간 즈음에 총수의 후계구도 정비를 위한 대대적인 조직개편에 휩싸여서 잠정 연기, 중단되더니 담당 조직이 공중분해되는 일을 겪어야 했다. 그러는 중에 물개의 농간으로 공동 발표하게 된 영회가 발표준비를 나한테 다 떠넘겨서 혼자서 영회 발표자료까지 다 만들어줘야 했던 JCO 컨퍼런스 발표를 하고, 스프링 컨설팅 업체인 Epril을 급조해서 만들었고, Epril 주최 스프링 세미나를 진행하고, 세미나 직후에 KSUG를 설립하고 KSUG 세미나를 5차례 더 진행했고, 영회가 튀는 바람에 공중에 떠버린 일을 추스리느라 우왕좌왕 했고, 유럽에서 열린 SpringOne유럽에 다녀왔고, 중국 연길에 특강하러 한번, 교육하러 한번, 리서치 하느라 한번, 회의 하느라 한번 해서 4번 방문했고, 북경에 두 번 방문, 샌프란시스코의 QCon참석, 알라바마에 물류 시스템 개발 프로젝트 하느라 한달간 체류, 그리고 SpringOne 미국 컨퍼런스에도 다녀왔고, 그러는 차에 호주 회사의 프로젝트 2개를 원격으로 진행했고, 한국 프로젝트 두 개 더와 한 차례 스프링 교육을 하고, 유료 세미나도 한번 하고,수많은 업체의 컨설팅 요청에 대응해야 했다. 특집 기획과 원고를 요청하는 정희용 기자/편집장의 요청도 다 들어줘야 했고. 그러는 와중에 평화가 태어났고, 병원으로 산후조리원으로 처가집으로 다시 본가로 이전해야 했고, 아내가 입덧으로 일찍 일을 그만 두는 바람에 생긴 공백을 메꾸기 위해서 땜빵 개발 일을 했고, 그러는 중에 카이스트 프로젝트가 오픈 몇달 남기고 O사의 공략에 프로젝트가 공중분해되는 일을 겪고, 물개가 홧김에 연구소 입구를 발로 뻥 걷어차며 나가는 것을 지켜봐야 했다. 헉헉. 그 외에도 많지만 대충 이만 생략.

이게 다 2007년 한 해에 일어난 일이다. 평범하게 일하는 중에 애기만 나왔어도 정신없었을 텐데. 다시 생각해봐도 참 정신없던 시간이었다.

여기에 하나를 더 얹어야 하는 것이 바로 스프링 책 저술 계약이다. 정확한 날자는 기억이 나지 않는다. 그 뒤로 여러 차례 이사를 하면서 저술(출판인가?) 계약서를 분실해서 계약 내용도 날자도 알 수가 없다. 출판사에서 "사실은 노예계약이었다"라고 해도 할 말이 없다. 아무튼 기억 나는 건 계약을 마치고 돌아오는 길에 김희정 부사장님과 아내의 입덧에 대해 얘기를 나눴던 것으로 봐서, 입덧 기간이었던 2007년 1~3월 사이라고 추정할 수 밖에.

어느날 김희정 부사장님께 연락이 왔다. "한번 봐요". 바빴지만 거절을 못하는 탓에 피할 방법은 없었다. 한창 정신 없이 시간을 보내던 그때, 시청 근처에서 김희정 부사장님과 스프링 관련 저서를 준비하고 있는 다른 저자 한분을 만났다. 다른 저자와는 우연히 시간이 맞아서 같이 만나게 된 것인지 아니면, 그 분이 먼저 기획하고 저술하고 있는 책이 스프링을 사용하는 것이라서 내가 쓸 책과 내용이나 대상 독자가 중복되지 않도록 조율해보라는 출판사의 배려였는지는 잘 모르겠지만, 아무튼 모 SI업체에서 스프링을 도입하려고 노력하고 있는 분을 만나게 되서 반가웠다. 식사를 마치고 커피숍으로 가서 조금 더 이야기를 나누던 차에 김 부사장님이 가방에서 얇은 서류 하나를 꺼내셨다. 저술(출판인가?) 계약서였다. "이게요. 특별한 것은 아니고요. 부담 가지실 필요 전~혀 없어요. 내용 신경쓰지 마시고 마음 편하게 그냥 싸인만 하시면 되요." 계약을 위한 만남으로 내가 미리 알고 그 자리에 나갔는지에 대해서는 기억이 잘 나지 않는데. 대뜸 들이미시는 계약서를 보고 흠짓 놀란 기억이 있는 것으로 봐서는 아마 몰랐을 것이라는 생각이 든다.

역시 거절을 못하는 탓에 "네!” 하고 바로 싸인.

그 전에 한번 만났을 뿐인데, 내가 저술 기획서를 만들어서 제출한 것도 아니었는데 왜 갑자기 계약을 하자고 했을까 하는 의문이 들었지만, 뭐든 계약서에 싸인하고 나면 기분 좋아지는 성격 탓에 굳이 물어볼 생각은 못했다. 첫 만남 뒤로 뒷조사를 했는데 모험해 볼 만하다는 평가가 있었던 것인지 어쨌는지는 지금도 잘 모르겠다.

아무튼 그렇게 저술 계약을 하면서 시작된 2007년은 앞에서 얘기한 대로 정신없는 일과 사건, 새로운 경험과 예상치 못한 일정으로 가득 찼다. 스프링 책을 써야지 하는 생각이 간간히 들기는 했지만, 구체적으로 할 일이 무엇인지 꼽을 수 없는 일들이 대부분 그렇듯이 항상 우선 순위가 밀렸고 선듯 손에 잡히지가 않았다.

그러는 중에 갑자기 정신이 번쩍 드는 일이 일어났다. 이 얘기는 내일 계속.

토비의 스프링 3이 나오기까지 (3)

흐릿하고 왜곡된 기억과 진하게 남은 느낌을 바탕으로 쓰는 토스3이 나오기까지 세 번째.

사람의 기억은 쉽게 왜곡된다. 굳이 심리학이나 정신병리학 이론 따위를 들먹이지 않아도 자신이나 주위의 경험을 살펴보면 쉽게 알 수 있다.

예를 들어, 예전에 어떤 사람이 "토비가 영회 멘토인데, 멘토가 제대로 가르쳐주지 않아서 영회가 저 모양이다"는 식의 글을 비아냥 거리기 위해서 써논 것을 본적이 있다. 당연히 나는 영회의 멘토가 아니다. 내가 영회한테 뭘 가르쳐주거나, 영향을 준 것도 없고, 영회는 내 말 따위는 한 귀로 듣고 다른 한 귀로 흘려버린다. 어쩌다보니 같이 활동을 많이 하게되고 미운정이 많이 들어 친한척 지내는 사이일 뿐.

영회와의 인연은 영회가 오래전에 스프링MVC 분석 글을 쓰면서 하도 틀린 얘기를 많이 해서 매번 가서 틀린 내용을 댓글로 지적해주다가, 어느날 우연히 찌질이 EJB빠가 등장해서 영회 글을 까는 것을 보고 영회(사실은 스프링)편을 들어준 덕에 어쩌다 친해진 것이다. 강한척 하지만 사실은 매우 소심한 영회는 내가 순수하게 기술적으로 잘못된 설명을 정정해 주는 글을 남겼던 것인데도, 그 일을 지금까지 마음에 품고 있다가 얼마전에 내 책을 마감하는 시점에 축하 댓글을 술김에 남기면서 "형이 4년전에 내 블로그에 와서 댓글로 깠던 것 이제 다 용서해줄께"라고 적을 만큼 마음이 여리다. 얘기가 샜는데, 더 이상 자기 얘기를 쓰면 "토스3 홍보대사를 그만 두겠다"고 협박한게 있어서 여기까지.

아무튼, 하려고 했던 얘기는 왜 그 사람이 나를 영회 멘토라고 오해했을까이다. 그 사람은 멘토인 내가 권유해서 영회가 모임에 나왔다고 소개하는 것을 분명히 들었다고 주장했다. 영회가 모 협의회 모임에 처음 나갔을 때 자기 소개를 하면서, 아는 형이 권유해서 나왔다는 식으로 얘기한 것을 "아는 형 + 모임 참석 권유 = 멘토가 하는 짓"라는 자신이 친숙한 공식을 적용해서 "영회는 토비라는 멘토가 있고, 그의 권유로 모임에 나왔다"라고 인식했을 것이다. 아마 그렇게 자신에게 익숙한 개념으로 입력이 전환되서 기억에 저장되면, 나중에 기억을 더듬어보면 그게 생성하게 사실인 것처럼 인식되기 쉽상이다. 영회가 당시에 미쳤거나 여친에게 혼나고 흥분 상태에 있던 것이 아니라면 "멘토"라는 평소에 절대 사용하지 않는 말 따위는 하지 않았을 것이 분명하다는 것이 내 판단이다.

그래서 하고 싶은 얘기는 내 얘기도 그런 식으로 살며시 왜곡되어서 저장된 것을 바탕으로 했을 수도 있다는 disclaimer. 물론 전혀 없는 사실을 상상하거나 꾸며낸 것은 아니니, 구체적인 인용에서 일부 표현이 달라졌으면 몰라도 내 얘기가 거짓은 아닐테다. 그리고 이 블로그는 내 어설픈 기억과 경험, 지식을 꺼내놓는 장소이니 뭐 어떤가. 출간할 책도 아니고.

다시 2007년. 계약을 하긴 했지만 사실 책을 어떻게 쓸지, 내용은 어떤 것을 담을지에 대해서 아무런 결정된 것이 없었다. 솔직히 말해 2007년엔 책을 단 한 줄도 쓴 것이 없다. 구상은 했지만 구체적으로 기록한 것도 없다. 지난 글에서 설명했듯이 정신없는 새로운 일과 도전으로 가득찬 한 해를 보내다보니 여유가 없어서 그랬을 수도 있고, 익숙하지 않은 것을 시작하는데 어려움을 겪는 내 성격 때문이기도 했을 것이다. 거기에 하나를 더 보태자면 그다지 출판사에서 압박 내지는 재촉을 받은게 없다는 사실이다.

나도 영회 못지 않게 마음이 여려서 부정적인 피드백이나 노골적인 지적을 받으면 감정이 쉽게 상하고 한동안 힘들어하는 편이다. 그래서 왠만하면 남에게 지적 받는 실수를 하지 않으려고 노력하고 모든 일을 완벽하게 하려고 애쓰는 편이다. 아마도 출판사에서 "책을 언제까지 쓸거냐. 왜 빨리 안쓰냐"라고 재촉했으면 결과는 두 가지 중의 하나로 났을 것이다. 책이 어설프게 나마 빨리(2007년 내에) 나오든가 아니면 아예 책 쓰는 것을 포기했을 것이다. 내 장점은 도저히 안되겠다 싶으면 뭐든 빨리 포기하는 것이다. 또는 욕을 먹거나 지적을 받으면 다른 일을 다 제쳐두고 밤을 새서라도 빨리 일을 마무리하기도 한다. 아무튼 수시로 연락해서 진도를 확인하고, 이런 저런 경고를 받았다면 만사를 제쳐두고라도 책부터 쓰지 않았을까 싶다.

하지만 출판사, 내가 가진 유일한 커넥션인 김희정 부사장님은 전혀 그런 것이 없었다. 초반에 출판사 사무실을 방문하고 출판사가 주관하는 번개나 모임 등에 가서 만났던 사람들은 내가 책을 쓰기로 했다는 얘기를 하면 주위를 살피고 조용히 이런 저런 충고를 해주었다. 거의 모든 사람이 공통적으로 한 얘기는 "김희정 부사장님을 조심하라"였다. Y,K,P 님의 설명에 따르면 김희정 부사장님은 번역이나 저술이 늦어져도 절대 재촉하거나 기분 나쁜 소리를 하지 않는다. 그런데 항상 친절한 말투로 편안한 이야기를 하는 데도 불구하고 막상 역자나 저자들은 강한 압박감을 받고 꼼짝 못한다는 것이다. 그래서 친절하게 대해준다고 방심하면 나중에 부담이 100만배로 늘어나서 꼼짝 못하게 될 것이니 조심하라는 조언을 들었다.

사실이었다.

2007년에 내가 쓴 책과 관련된 유일한 내용은 다른 직원 분을 통해서 요청을 받은 "목차"가 전부였다. 사실 당시에 내가 작성한 목차는 그냥 스프링 기술 목록을 쭉 나열해가면서 형식적으로 쓴 것이다. 아직 제대로 된 구상도 안된 마당에 목차가 어찌 나올 수 있을까. 그런데 얼마 후에 만난 김희정 부사장님은 "설마 이 걸 다 쓰실려는 것은 아니죠?"라는 말로 시작해서 책을 쓰는 데 필요한 일반적인 조언을 편안하게 해주셨다. 예를 들면 "책은 초보자들이 볼 수 있도록 쉽게 써야 해요. 욕심 내지 마시고 2권(2판 말고 2권)을 추가로 낼거라는 생각으로 꼭 필요한 내용만 뽑아서 먼저 1권을 써주세요. 뭘 넣을지 고민하지 마시고 뭘 뺄지 생각해보세요"와 같은 얘기였다. 일반적이고 편안한 얘기였는데 이 얘기가 한 번 두 번 반복되다보니 나중에는 원고를 쓰려고 워드를 열 때마다 머리 속에 "초보자, 쉬운 책, 2권 내용은 빼고 일단 1권용, 뭘 뺄까…"와 같은 말들이 머리 속에 떠돌아 다니는 정도가 됐다. 거의 강박관념이 되다보니, 한 문단을 써놓고 다시 읽어본 뒤에 "이걸 더 쉽게 풀어 써야햇"이라는 생각에 그걸 다시 풀어서 2페이지로 늘려 쓰게 되는 식이었다. 편안한 말투와 조언에도 순진하고 착한 나같은 엔지니어 출신 초보 저자가 얼마나 쉽게 세뇌될 수 있는지를 나중에야 깨달았다.

아무튼, 아무리 진도가 나가지 않아도 충격적인 얘기나 경고 같은 것은 전혀 들을 수 없었다. 오히려 내가 가장 많이 들은 얘기는 "많이 기대하고 있어요"였을 뿐. 또는 다른 책 얘기, 다른 번역 얘기, 다른 저자 얘기 등등. 과도한 친절을 받았을 때 쌓이는 부담감이 그렇게 늘어나고 있을 때 어느날 충격적인 얘기를 들었다.

바로 나를 출판사에 소개시켜준 정희용 편집장(아마 당시엔 마소 편집장이었을 것이다)이 어느날 메신저에 들어오더니 "형, 제발 책좀 빨리 써줘. 출판사 들어갈 때마다 내가 맨날 혼나. 도데체 이 사람은 책을 언제 쓰는 거냐고 나만 깨진단 말이야"라는 말을 남겼다.

두둥. 이런 저런 다른 바쁜 일들이 거의 머리 속을 점령하고 있어서 가끔 떠오르는 책을 써야겠다는 부담감을 자꾸 뒤쪽으로 몰아내고 있던 차에, 그런 얘기를 들으니 얼굴이 화끈거리고 가슴이 두근두근. "알았어 빨리 쓸게 걱정마"라고 말을 하고 나니 식은 땀이 흘렀다.

물론 그 일이 있고 나서도 2007년이 끝나기까지 원고는 한 줄도 쓰지 않았지만, 이전보다는 훨씬 커진 부담감으로 책의 내용과 구성을 구체적으로 생각하게 됐다. 그로부터 2년 넘게 더 시간이 걸리긴 했지만 그래도 그때 긴장속에서 구상했던 내용과 구성이 지금 책의 바탕이 되었다. 책 내용을 구상한 얘기는 다음에 하고, 일단 그때 느낌을 조금 더 적어봐야겠다.

희용이의 얘기를 듣고 나니 나에게 조언해주던 여러 다른 역자, 저자 내지는 출판사에 들락 거리던 사람들의 얘기가 떠올랐다. 편안하게 대해준다고 내가 너무 방심했나하는 생각이 들기도 했다. 그러면서 한편으로는 의심이 들기도 했다. 과연 희용이의 얘기는 얼마나 진실일까? 지금까지도 의문이다. 세 가지 가정을 해봤다. 첫째는 정말 김 부사장님은 내가 책을 빨리 안써서 대단히 화가 나있었고, 그 때문에 나를 추천해준 희용가 정말 매번 혼났다는 것. 그래서 맘 착한 희용이가 견디다 못해 나한테 얘기를 했다는 생각. 두 번째는 사실 김 부사장님은 편안하게 "책이 좀 늦어지는 것 같은데, 어쩌나"라는 식으로 편안하게 얘기했지만 희용이가 이를 과정해서 자기가 맨날 혼난다고 중간에서 상황을 조작했다는 것. 경험도 없는 초짜 저자를 소개해준 사람으로서 부담이 있으니 그랬을 수도 있다는 생각. 마지막으로는 스스로 찔린 희용이가 얘기를 지어냈을 것이라는 것. 사실은 김 부사장님은 별다른 얘기가 없었음에도 진도가 안나가는 것을 눈치챈 희용이가 꾀를 내서 나한테 부담이 가도록 "내가 형 때문에 맨날 혼나. 살려줘"라고 했을 수도 있다는 생각.

얼마전에 처음으로 확인해보니 희용이는 당연히 첫 번째라고 대답했다. 나는 세 번째라고 믿고 싶은데…

몇 가지 이후에 일어난 일을 참고해서 생각해보면 첫 번째였을 가능성이 높다. 예를 들어 책이 거의 마무리될 즈음에 아마도 내가 부담이 많이 없어졌을 것이라고 생각하셨는지 김희정 부사장님은 이런 얘기를 하셨다. "그동안 재촉해 드리지 못해서 미안해요. 재촉한다고 빨리 썼을 것도 아니고해서…". 또, 희용이는 추천사에 "책이 나오지 못하게 될까바 조마조마 했다"고 쓰기도 했다. 흑.

남은 의문은 희용이가 나에게 그 얘기를 전달한 것이 단지 나랑 친한 사이였고, 소개한 사람 입장에서 얘기를 해줘야 겠다는 스스로의 판단에서 였는지 아니면 김 부사장님의 고도의 계산, 즉 측면 공략의 결과였는지이다. 원래 군대나 직장에서도 고참이 신입에게 직접 뭐라고 하지 않는다. 다 중간을 불러서 대신 깬다. 사실 신병 입장에서는 그게 더 견디기 힘들다. 내가 이병 때 당시 소속해 있던 군악대 분위기가 좀 늘어졌을 때가 있었다. 특히 행사나가서 삑사리 나는 게 늘면서 당시 최고참들이 좀 화가났던 것 같다. 연습실로 집합. 그리고 자기 바로 아래 교육 기수를 불러내서 우리가 보는 앞에서 교육 기수를 굴렸다. 차라리 다 같이 깨주면 좋은데… 그 뒤에 일어난 일은 설명 안해도 알만할 것이다. 사실 직접 구를 때는 맘이라도 편하다. 오히려 우리가 잘못한 것 때문에 중간 기수가 깨지는 것을 보는게 더욱 힘든 일이었다.

차라리 내가 직접 잔소리를 들었다면 나았을 텐데, 착한 희용이가 나 때문에 맨날 혼나고 다닌 다는 얘기를 들으니 두 배로 마음이 아팠다. 부담은 세 배로 커졌고. 내가 궁금한 것은 과연 그 때 일이 고도의 계산에 따라 일어난 일이지의 여부인데. 그 뒤로도 직접 대면하거나 대화를 할 때는 나에게 계속 친절하게만 얘기해주신 것을 보면 이게 참 헷갈린다. 적당히 의심은 가지만 사실 확실히 알 수 없을 때 사람은 더 긴장하게 된다. 아마 나에게 조언해 줬던 역자, 저자 분들이 경험했던 강한 압박감도 아마 그런 혼란이 가중되서 발생한 것이 아닐까. 친절한 정면 공략과 강력한 측면 공격의 콤보.

그 날 이후로 책을 빨리써야 겠다는 생각과 부담 없이 하루도 잠자리에 든 적이 없는 것 같다. 문제가 있으면 그걸 해결해야 부담이 풀린다. 일 때문에 받은 스트레스는 일을 해버리면 풀린다. 그런데 이 놈의 책은 하루 이틀에 쉽게 해결할 수 있는 것이 아니니, 그 스트레스가 얼마나 대단했을까.

그런 부담 속에서 본격적으로 시작된 책 구성과 저술 시작, 그리고 호주로의 이주 등등에 대해서는 다음 시간에 계속.

토비의 스프링 3이 나오기까지 (4)

토비의 스프링 3이 나오기까지의 이야기를 담은 토비 스토리 네 번째 이야기.

다시 2007년. 스프링 책을 어떤 식으로 쓸 것인지 질문을 받으면 항상 이런 얘기를 했다. 기존 스프링 책들은 1장에서 스프링 역사로부터 시작해서 J2EE과 스프링의 관계 등등의 장황한 스프링 소개를 한 뒤에, 바로 2장에서 IoC를 몽땅 다루고, 3장에서 AOP를, 4장에서 JDBC를 다루는 식으로 접근한다. 내가 느낀 문제는 스프링을 처음 접하는 사람에게 스프링의 프로그래밍 모델이 뭔지 감을 잡기도 전에 2장에서 스프링의 모든 DI 고급기법까지 다 설명하는 것이다. DI가 뭔지 아직 감을 잡지도 못한 사람한테 나도 아직 잘 사용하지 못하는 빈의 라이프사이클 메소드니 빈/빈팩토리 포스트프로세서니 하는 것까지 다 설명을 해버리면 여기서 벌써 기가 죽는다. 머리 속에선 스프링이란 뭔가 복잡한 설정방법을 알아야 하는 것이라고 단정짓게 된다. 그리고 나서 바로 AOP로 넘어간다. AOP는 더 가관이다. AOP를 다루는 장의 처음 몇 페이지는 온통 생소한 용어소개 뿐이다. AOP, 애스팩트, 조인포인트, 포인트컷, 위빙, 어드바이스, 인트로덕션, 횡단관심이 어쩌고 저쩌고. 아무리 깔끔한 정의를 적어놨다고 한들 용어가 머리속에 제대로 들어올리가 없다. AOP를 이용한 로깅이니 보안이니 하는 예제까지 다루고 포인트컷 표현식 따위나 포인트컷 확장 빈 등록, 자동 빈 생성기 이런 것들이 마구 소개되는 것을 보면 일단 AOP는 제껴두자고 마음을 먹게 된다. SpringMVC는 어떤가? 갑자기 7가지 디스패처서블릿의 전략이 쭉 소개된다. 그리고 공포의 SimpleFormController가 떡 하니 등장하면 정말 기가 팍 죽는다. 어려운 SpringMVC를 쓰느니 익숙한 스트럿츠1을 사용하든지, 아니면 일단 처음 접근(만)은 간단한 웹워크, 스트럿츠2가 더 나아보일 것이다.

모 교육센터의 강사로 활동했던 친한 형 한명은 스프링을 제대로 공부해보겠다고 여러 책을 붙잡고 밤낮을 끙끙댔음에도 도무지 뭐가 뭔지 모르겠다는 푸념을 하기도 했다. 특히 AOP는 설명을 아무리 읽고 또 읽어도 이해가 되지 않는, 안드로메다 외계 테크롤로지로 보인다는 것이다. 그냥 배껴서 쓸 수 있는 예제 하나 없을까 찾기에 바빴다. 아마 적지 않은 개발자들이 그런 비슷한 과정을 밟지 않을까 하는 생각이 들었다. 스프링이 유행이라니까 다음 프로젝트부터 적용하라는 위로부터의 일방적인 지시가 떨어지고, 급한 마음에 시중에 나와있는 책들을 구해서 공부를 해보는데 이게 난생 처음 들어보는 용어와 복잡해보이는 XML이 난무하고, 책의 예제를 따라해봐도 대충 어떻게 배껴서 비슷하게 만들면 되겠다는 감은 오지만 도대체 스프링이 뭔지, 뭐하러 쓰는지 마음에 다가오는 것이 없고, 이걸 도대체 뭐하러 써야 하나하는 불만이 들기 쉽상일 것이다. 내가 직접 들은 그런 불만만 해도 적지 않다. 사실 그런 유행에 휩쓸려 스프링을 급하게 사용하기 시작하다가 스프링에 안좋은 인상만 남게 되는 일도 흔했다. 그래서 한동안은 스프링을 쓰지 말라고 말려야 겠다는 생각이 들기도 했다. 그래서 블로그에 "스프링을 쓰기 위해서 스프링을 쓰지 말자"라는 얘기를 적기도 했다. 단지 스프링이 유행이니까 사용해야겠다는 생각으로 스프링을 사용하지는 말라는 얘기다.

스프링은 쉽지 않다. 왜냐하면 스프링은 쉽지 않은 자바 엔터프라이즈 애플리케이션의 개발을 다루고 있기 때문이다. 또 스프링은 한 가지 단순한 접근방법만 파는 대신 수 많은 옵션과 다른 프레임워크와의 조합을 적극적으로 제공하기 때문이기도 하다. 자유도가 매우 높은 RPG 게임과 비슷하다고나 할까. 대신 스프링을 관통하는 기본 원칙과 프로그래밍 모델, 디자인 패턴은 매우 명확하고 분명하다. 문제는 스프링 책이나 교육이라는 것이 지면과 시간의 한계 때문에 레퍼런스식 설명에 그치거나 아니면 간단한 예제 하나에 매몰되기 쉽상이라는 것이다. 특히 예제 중심의 접근은 초반에는 쉬워보이지만, 자칫하면 특정 방식의 스프링 사용방법이 전부이거나 가장 좋은 것이라는 잘못된 인식을 줄 수 있고, 예제 코드를 기계적으로 복사해서 전혀 컨텍스트가 다른 곳에서 사용하는 일이 일어날 수도 있다. 스프링이 지지하는 탄탄하고 일관된 프로그래밍 모델 + 다양한 기술의 선택과 조합 대신 개념 없는 대충대충 프로그래밍 모델 + 특정 기술과 개발 패턴의 기계적인 적용만 남게 되는 문제가 일어날 수 있다는 뜻이다.

물론 현명한 개발자들은 그런 자료와 서적, 교육 등을 통해서 얻은 지식을 기존 경험과 잘 결합시켜서 스프링의 본질이 무엇인지 깨닫고 지혜롭게 응용할 줄 알 것이다. 하지만 적지 않은 초보자들은 그런 오해를 하기 쉽다.

그래서 스프링 책을 쓰기가 막막했다. 어쨌든 스프링의 기술을 다뤄야 하니, IoC, AOP, JDBC, MVC 등의 내용을 하나씩 설명할 수 밖에 없을테고, 동시에 스프링을 통해서 만들어지는 엔터프라이즈 애플리케이션의 전체 그림, 그리고 실제 코드를 예제로 보여주지 않을 수도 없는 노릇이니 내가 우려하던 그런 문제들을 쉽게 피할 방법은 없다고 생각이 됐다. 그래도 스프링 설명을 너무 관념적으로 가져가거나 현실과 동떨어진 설명을 택하는 것은 피해야겠다고 생각했다. 예를 들어 DI를 설명하면서, 절대로 실전에서는 경험해본 적이 없을 것이 분명한 도메인 오브젝트 내의 DI를 들어 설명하는 것 따위는 피해야 할 것이라고 생각했다. 실전에서 자주 접하는 코드이면서, 그래도 스프링의 특징을 잘 드러낼 수 있는 POJO에 로직이 잘 드러나있는 그런 코드가 뭐가 없을까 하는 고민을 계속 했다.

그래서 한 동안은 쌈박한 예제 하나만 먼저 만들어보면 책을 쓰는 것은 어렵지 않겠다고 생각했다. 프로그래밍 서적에서 자주 사용되는 쇼핑몰이나 블로그 따위는 사실 스프링으로 만들만한 애플리케이션도 아니고, 스프링의 POJO 중심의 개발이 주는 장점을 보여줄만한 예제로서 적합하지도 않았다. 그래서 실제 SI현장의 도메인에서 예제를 찾아보려고 했다. 그렇다고 특정 도메인의 예제를 사용하면 도메인을 이해하지 못하는 독자들에게 이중의 부담이 될 수 있으니 누구나 쉽게 이해하고 알만한 것이 뭐가 없을까 고민했다. 나는 스프링으로 제조업체의 ERP 전체를 개발해본 경험이 있으니 제조업체의 다양한 도메인에 스프링을 어떻게 적용할지에 대한 충분한 이해는 있었다. 그 중 쉬운 것을 찾자면 재고 관리 시스템에 괜찮다는 생각이 들었다. 다양한 재고 관리 기법을 DI를 이용해서 교체해서 로직을 적용하는 것도 구상해봤다. 하지만 깔끔하게 책의 예제로 쓸만한 도메인 로직으로 축소해 내기가 쉽지는 않았다. 그래서 주변의 SI 전문가-컨설턴트에게 예제에 사용할만한 도메인 모델을 좀 요청해봤다.

여러명의 SI업체나 금융계에서 활동하는 컨설턴트에게 요청을 해봤지만 다들 대답만 시원하게 했을뿐 건네주는 것이 없었다. 실제 도메인의 모델을 다 주자니 복잡하기도 하고, 보안의 문제도 있고 그렇다고 책의 예제로 할만큼 단순화 하자니 귀찮고, 그래서 대답만 하고 다들 나몰라라. 대표적으로, 개발자가 아닌 CBD와 모델링 컨설턴트 출신의 영회는 자기가 교육할 때마다 쓰던 모델이 있으니 걱정말라고 큰소리만 뻥뻥 치고는 끝까지 모델 그림 한장 제공해주지 않았다.

그렇게 시간이 지나면서 쌈박한 예제 하나만 있으면, 이를 만들어가는 과정을 담아서 책을 쓰면 되겠다는 환상이 서서히 깨지기 시작했다. 예제에 사용할 도메인 모델과 로직은 얼마든지 내 스스로 만들어도 그만이라고 생각을 했지만, 문제는 특정 예제 하나를 중심으로 스프링을 설명하는 것이 얼마나 위험한지에 대한 염려가 커졌기 때문이다.

2007년 봄에 벨기에에서 열린 스프링원 유럽에 참석했을 때 스프링 2.1(당시엔 2.5가 아니고 2.1이 계획이었다)에 포함된 애노테이션을 이용한 DI 방식이 나온다는 것을 처음 알게됐다. 그리고 얼마지나서 2.1이 2.5로 버전이 바뀌어서 출시되면서 새롭게 @MVC 웹 기술이 포함되었다는 것도 보게됐다. 그 외에도 제법 다양한 방식으로 스프링의 기술의 폭이 넓어졌다. 스프링 애플리케이션을 만들 때 선택할 수 있는 옵션의 종류가 많아진 것이다. 그리고 그해 11월 샌프란시스코에서 열린 QCon에 참석했을 때 로드 존슨의 스프링 2.5 세션에 들어갔는데, 로드 존슨이 2.5의 새로운 기능을 소개하기에 앞서서 ‘스프링은 선택이다(Spring is about choice)’라느 유명한 말을 던지면서 스프링을 사용할 때 적절한 기술을 선택하고 조합하는 것이 얼마나 중요한지 강조하는 것을 들었다. 1.x에서는 엔터프라이즈 개발에 꼭 필요한 필수 기술을 추가하는 것에 집중했다면, 2.x에 들어와서는 다양한 기술과 설정에 대한 접근방법을 제공해서 개발자 자신의 선택의 폭을 넓히는 데 주력했다고 보여졌다. 그런 마당에 특정 접근방법 한 두가지밖에 적용할 수 없는 예제 하나로 책을 써버리면 적지 않은 사람들이 그게 스프링을 사용하는 유일한 내지는 최고의 방법이라고 오해하기 쉽상일 것이라는 걱정이 들었다. 그래서 그 즈음에 엔터프라이즈 애플리케이션 예제 하나를 완성해나가는 과정을 담아서 책을 쓰겠다는 생각을 포기했다.

또, 다시 고민 시작. 그러는 중에 정희용 편집장을 통한 측면 공격으로 상당한 내상을 입은데다, 쏟아져 나오기 시작하는 스프링 2.5책을 보면서 책을 빨리 내야 한다는 부담이 크게 가중되고 있었다.

그런데 사실 그때 가장 큰 고민은 앞으로 어디에서 살아야할 것인가 였다. 평화는 태어났고, 일단 처가와 본가를 오가며 생활은 할 수 었지만, 어디엔가 정착이 필요했다. 여러 가지 후보가 있었다. 일단 한국에서 계속 지낸다면 쉽게 일은 할 수 있을 듯 싶었다. 당시에 많은 기업에서 스프링 컨설팅이나 프레임워크 개발요청이 끊이지 않았다. 일은 내가 맘에 드는 것을 골라서 얼마든지 할 수 있는 상황이었다. 재외동포비자를 받았으니 장기체류를 하면서 내국인과 동일한 혜택을 받고 일하는 데도 아무런 문제가 없었다. 한편으로는 미국으로 가고 싶은 마음도 들었다. 미국에서도 끊임없이 호출이 있었다. 내가 말하기도 전에 먼저 이민변호사와 협의해서 이민에 필요한 수속과정을 알아보고 있던 기업도 있었다. 스폰서가 되줄테니 오기만 하라는 기업이 여럿 있었으니 원한다면 얼마든지 미국으로 가서 생활하고 장기적으로 미국으로 영구이주하는 것도 고려할 수 있는 상황이었다. 동시에 중국으로 가고 싶은 마음도 들었다. 2007년에 처음으로 방문했던 중국은 상당히 매력적이었다. 중국에 비즈니스를 시작하고 한국과 호주에 연계해서 일을 할 수 있겠다는 생각도 들었다. 투자를 하겠다는 사람도 나왔고 비즈니스 리서치를 위해서 여러 번 방문도 했고, 현지 코디네이터를 해주실 전문가도 알아두었다. 무엇보다도 한국과 가깝다는 것이 매력적이었다. 이렇게 한국, 미국, 중국을 놓고 저울질 하고 있었지만 한편으로는 호주 생각이 간절했다.

나의 20대 후반과 30대 초반을 보낸 곳. 안정적인 한국의 직장 생활을 포기하고 바닥으로 내려가 모든 것을 다 도전하면서 생활해왔던 시간들, 그리고 내가 좋아하는 깨끗하고 아름다운 자연과 친절한 사람들, 여유있는 삶 등등. 나에게는 제2의 고향과도 같은 곳이고 마음의 안정을 누릴 수 있는 곳이기도 하다. 특히 평화가 태어나고는 복잡한 서울이 싫어졌다. 뭔가 새로운 도전을 하면서 다른 곳으로 갈 수도 있었지만 아마도 그런 삶을 살다보면 평화와 같이 시간을 많이 보내기 힘들 것이라는 생각이 들었다. 돈이나 성공, 직업과 비즈니스의 안정보다는 가족과 많은 시간을 보낼 수 있는 평화로운 삶을 선택하고 싶다는 생각이 들었다. 한국에서 생활하는 동안 아침 6시에 집을 나서서 밤 11시 반이 되야 돌아오는 생활에 익숙해있었다. 평화는 자는 모습 밖에 보지 못했다. 주말에도 세미나나 각종 모임에 나가느라 많은 시간을 보낼 수 없었다. 같이 다닐만한 곳도 많지 않았다.

그래서 많은 고민 끝에 다시 호주로 돌아가기로 마음을 먹었다. 그와 동시에 본격적으로 책을 쓰는데 시간을 쓸 수 있겠다는 기대가 들었다.

그러던 어느날 기선이와 함께 분당의 KT IDC에 서버 작업 때문에 방문할 일이 있었다. 분당으로 가면서 기선이랑 이런 저런 얘기를 하는 도중에 갑자기 애자일 자바(Agile Java)라는 책이 떠올랐다. 애자일 자바는 테스트 코드를 이용해서 자바의 기능을 설명하는 독특한 방식으로 주목을 끌었던 자바 입문서이다. 영회가 만들어서 한 동안 활발한 활동을 펼치다 지금은 사라진 애자일 자바 네트워크(AJN)는 바로 이 책을 이용해서 스터디를 하는 모임으로 출발한 것이다. 아무튼 그 책의 독특한 설명방법이 떠오르면서, 스프링도 그렇게 설명할 수 있지 않을까 하는 생각이 들었다. 스프링과 테스트는 뗄 수 없는 관계다. 스프링이 POJO 프레임워크라고 본다면 POJO 프레임워크로서 스프링의 가치는 절반은 기술과 환경에 독립된 코드라는 것이 둘 수 있고 다른 절반은 POJO가 가지는 테스트 편의성에 둘 수 있을만큼 테스트는 스프링에서 아주 중요한 의미를 가진다. 당연히 스프링 책에서 테스트에 대한 내용을 충분히 넣고, 강조할 생각은 가지고 있었지만 아예 테스트를 이용해서 스프링의 기술을 설명할 생각은 미처 못하고 있었다. 그런데 갑자기 애자일 자바가 떠오르면서 내 책도 그렇게 가야겠다는 생각이 들었다. 책 이름은 애자일 자바를 배껴서 애자일 스프링!

일단 잠정적으로 책 이름은 애자일 스프링으로 정했고, 학습 테스트 코드를 활용해서 스프링의 다양한 기능을 보여주고 설명하는 방식으로 내용을 작성해야겠다는 생각이 들었다. 그러면 특정 방식에 제한되는 예제에 매몰되지 않고 스프링의 다양한 접근방법을 보여줄 수 있겠다는 생각이 들었다.

이렇게 해서 2007년이 지나가고 드디어 스프링 책을 쓰기 시작한 2008년 밝았다. 여기서부터는 내일 다시.

토비의 스프링 3이 나오기까지 (5)

책이 출간되기 전에 얼릉 지난 이야기를 끄적여놓고 출간과 동시에 잠적하려고 했던 계획이 실패했다. 뭐, 내가 계획했던 일이 다 그렇지.

일년여의 고민끝에 스프링 책을 어떻게 쓸지 큰 그림을 그린 채로 2007년을 마감했다. 책 제목은 일단 애자일 스프링이라고 하기로 했고, 단일 예제 중심의 설명보다는 애자일 자바 스타일로 학습 테스트를 이용한 코드를 중심으로 각 기술의 다양한 옵션을 보여주는 것으로 그림을 그렸다. 테스트 코드는 독립적으로 동작하고 그 결과를 확인할 수 있으면서도 매우 간결하게 작성할 수 있다는 장점이 있으니, 최소한의 코드로 스프링 기술의 다양한 조합을 제한된 지면 내에서 적절히 보여줄 수 있을 것이라고 생각됐다.

2007년 12월에는 2006년에 이어서 두 번째로 미국에서 열린 The Spring Experience 컨퍼런스에 참석하게 되었다. 첫 컨퍼런스 참석 때처럼 설레이는 것은 없었지만 2.5가 나온지 얼마되지 않은 시점에 열린 컨퍼런스라 재밌는 새로운 이야기를 들을 것이 많았다. 또, 한가지 반가웠던 것은 한국에서 온 다른 참석자를 몇 명 만나게 된 것이다. 컨퍼런스 첫날 저녁 식사를 하면서 같은 테이블에 앉은 사람들에게 내 소개를 할 기회가 있었다. 언제나 그렇듯이 일단 한국에서 왔다고 하면 다들 신기한 눈으로 바라본다. 처음 나를 보고는 중국이나 일본에서 왔거나 아니면 미국이나 캐나다에 사는 이민자 정도로 생각했을 것이기 때문이다. 그런데 옆 자리에 있던 스프링소스 직원 한명이 갑자기 반가운 얼굴을 하고는 SDS에서 왔냐고 물었다. 아니라고 대답하고, 어떻게 SDS를 아느냐고 물었더니 최근에 스프링소스의 컨설팅을 받은 업체라서 잘 알고 있다고 했다. 그래서 혹시나 하는 마음에 세션에 참석할 때마다 한국에서 온 참석자가 있는지 살펴보았다.

아마 둘째 날이었을 것이다. 스프링소스 주관 컨퍼런스가 대체로 휼륭한 강사와 세션으로 구성되 있기는 하지만, 강사 개인에 따라서 지루하고 졸린 발표를 하는 사람이 있다. 여독이 풀리지도 않은 채로 첫 날부터 강행군을 했더니 둘째날 오후에는 피로가 심하게 몰려왔다. 게다가 하필이면 선택한 세션의 강사는 거의 자장가 같은 목소리로 중얼중얼 지루한 발표를 하는 사람이었다. 이미지 관리를 위해서 사람들이 없는 뒷쪽 구석에 자리를 잡고 졸다 듣다를 반복하고 있었다. 그런데 갑자기 앞에 앉은 검은 머리의 남자 한명이 눈에 띄었다. 발표를 들으면서 노트북으로 뭔가 열심히 하는 모습이 보였는데, 자세히 보니 노트북 화면이 낯이 익다. 흐리멍텅한 녹색 바탕의 네~이버였다. 끝나고 슬그머니 다가가서 인사를 했다. SDS의 김창제 (당시)팀장이라고 소개를 해줬다. 나중에 알고 보니 스프링 기반의 한국형 오픈소스 SI 프레임워크인 애니프레임의 기획과 개발을 책임지는 팀장이었다. 김창제 (지금은) 수석님은 이후에도 몇 번 만날 기회를 가졌고, 고맙게도 내 책의 추천사도 써주셨다. 한국의 SI업체에는 숨은 고수들이 많이 있다고 했는데, 바로 김창제 수석님이 그런 분이었다. 이미 그 당시 애니프레임 개발팀은 테스트 커버리지 90%를 달성하지 못하면 인사고과에 반영할 정도로 강력한 클린코드 정책을 유지하고 있었다. X인터넷이나 특정 벤더 종속적인 프레임워크가 점령하고 있는 척박한 SI환경에서 오픈소스 기술을 중심으로, 그것도 스프링을 기반으로 프레임워크를 만들어서 보급하고 있는 모습에 놀랐다.

아무튼, 그렇게 해서 2008년을 맞았다. 우선 호주로 돌아가는 일을 준비하는 작업을 시작했다. 2005년에 달랑 가방 두 개들고 한국에 들어왔는데 서울-대전-다시 서울 생활을 하다보니 짐이 많이 늘었다. 처분할 짐을 제외하고 호주로 보낼 살림살이를 먼저 국제이사업체를 통해서 보냈다. 배편으로 가는 짐은 빠르면 보름에도 가지만 늦어지면 3개월도 걸린다. 짐이 들어오면 컨테이너를 채우다가 컨테이너가 꽉 차야 해당 컨테이너를 배에 선적하고, 배도 일정 분량 이상 짐이 실려야 출발하기 때문이다. 많지는 않지만 이삿짐을 보내고 나니 마음도 이미 호주로 떠난 듯 설레였다.

한국에서 관여했던 회사 일도 정리하기 시작했다. 미국에 있는 고객사의 프로젝트가 하나 준비되고 있었는데, 나는 호주로 가서 가족과 함께 지내기로 결심한 만큼 미국에 보낼 다른 사람을 물색하고 있었다. 그 전에 미국 일 얘기가 나왔을 때는 영회가 자기를 보내달라고 했다. 하지만 그 뒤로는 그런 얘기가 다시 없었다.

그러던 중에 기선이가 미국으로 가고 싶다는 뜻을 밝혔다. 좀 애매한 상황이긴 했지만 기선이를 그 자리에 넣어두고 나는 일에서 손을 뗄 준비를 했다. 물론 기술적인 지원이나 기타 관리는 내가 맡아서 원격에서 참여할 계획이었다. 어쨌든 현장에서 고객들을 상대하고 일을해야 할 사람 중에서 나랑 손발이 잘 맞을만한 사람이 한명 필요했고, 그 역할을 기선이가 잘 해줄 것으로 기대했다. KSUG에서 활동하는 동안에 종종 만나기는 했지만 기선이와는 그리 친하게 지내지는 않았다. 나는 주로 집이 가까운 찬욱이랑 친하게 지냈고, 기선이에게는 영회가 잠수탔을 때 관련자들의 연락처를 물어보느라 몇번 연락했을 뿐이다. 좀 까칠해보이긴 하지만 성실하게 자기 몫은 잘 해내는 모습이 마음에 들었다.

가족이나 친척, 기타 일과 관련된 사람들과는 별 부담없이 인사도 하고 정리를 할 수 있었는데, 가장 끝까지 좀처럼 얘기를 꺼내지 힘들었던 사람이 바로 김희정 부사장님이다. 큰소리 치고 계약한지 일년이 다 되가는데 진도가 나간 것도 없고, 그러는 와중에 호주로 떠난다고 하면 얼마나 황당해 하실까 걱정이었다. 얘기를 꺼내기 힘들어서 한동안 질질 끌다가 결국 말씀을 드렸다. "어머나". 나는 호주 이민자고 한국에 계속 체류할 것이 아님을 한번도 감춘적이 없었지만, 그래도 어느날 갑자기 떠난다는 말을 들으셨으니 얼마나 놀랐을지 모르겠다. 그것도 스프링 최신 버전이 나오고 관련 책들도 쏟아져 나와서 인기를 끌고 있는 마당에 스프링 책을 쓰겠다는 저자가 원고도 안넘기도 멀리 가버린다니! 가까이 있다면, 정 안되겠으면 납치(에이콘 출판사에 대해서 사람들에게 물어보면 다들 저자나 역자를 납치하는 것으로 유명하다는 얘기를 해주는데 그게 무슨 얘긴지 지금까지도 잘 모르겠다)를 해서 사무실에 감금하고 창틀로 먹이를 던져주며 원고를 쓰게라도 할텐데, 호주는 비행시간만 10시간 떨어진 곳이라 관리하기가 쉽지 않다. "한번 봐요"가 안 통하는 곳. 그때 김 부사장님이 어떤 얘기를 하셨는지는 잘 기억이 나지 않는다. 단지 "호주로 쫒아가서라도 원고를 받아내고 말겠다"는 굳은 의지를 느꼈던 것을 기억할 뿐.

2008년 3월에 떠나기 직전까지 일이 몰렸다. 프레임워크 제작, 교육, 기타 컨설팅 등등. 일부 일은 호주에 도착하고 나서도 계속 진행해야 했다. 게다가 거의 일년 가까이 기획해온 큰 프로젝트 하나가 기다리고 있었다. 호주에 와서는 임시로 친척집에 머물면서 집을 구하고 다시 정착하기 위해서 계속 뛰어다녀야 했다. 다행히 살 집은 빨리 구할 수가 있었다. 원래는 친구 집에 6개월 정도 머물면서 랜드+하우스 패키지를 사서 집을 직접 디자인해서 지을 생각이었다. 그런데 우연히 고모님이 소개해준 집을 보고 맘에 들어서 덜컥 계약을 해버렸다. 교통이 매우 좋은 곳에 있으면서도, 조용한 동네고, 땅크기도 830m2정도로 넉넉해서 나중에 집을 다시 지어도 좋겠다 싶었다. 아직 돌도 안된 평화도 있는데 집 보러 다니느라 매일 돌아다니고 고민하고 시간을 끌지 않는 것이 좋겠다는 생각 때문이었을 수도 있다. 게다가 집 가격도 저렴했고. 책과 옷, 그릇, 식탁과 침대 하나를 빼면 거의 모든 가구와 가전제품을 모두 새로 구입하느라 매일 쇼핑센터와 이베이를 전전. 낮에는 낯선 곳에 정착하기 위해서 열심히 뛰고 밤에는 개발과 프로젝트 기획 등으로 정신없는 시간을 보냈다.

그렇게 지낸 시간이 다시 몇 달. 한국에서는 떠날 준비하느라 바빠서, 호주에 와서는 정착하느라고 바빠서. 이런 저런 핑계로 책을 쓰는 일은 다시 저 멀리로 보내놓고 6월을 맞았다. 그러는 중에도 때때로 책을 써야 하는데라는 부담이 거대하게 몰려올 때가 있었다. 혹시나 김희정 부사장님이 메시지를 보내지 않을까 해서 MSN 메신저를 켜지도 못했다. 3-4개월에 한번씩 김 부사장님 대신 황지영 대리님으로부터 "저술 진행 문의" 메일이 왔다. "원고 진행은 잘 되고 계세요? 초벌 원고가 나올 때 갈은데요. 진행이 어떻게 되는지 알려주세요"라는 똑같은 레파토리의 메일이 날라왔다. 나는 한번도 제대로 답장을 할 수가 없었다. "진행이 전~혀 안되고 있어요"라고 말할 수는 없었으니까. 그리고 내가 아무리 "잘 되고 있습니다. 조금만 더 기다려주세요"라고 뻥을 쳐봤자, 눈치 빠른 김 부사장님은 아직 시작도 안했구나라고 금새 알아차릴 것이 분명했다.

그런데, 나중에 알게된 사실이지만 김 부사장님은 영회를 스파이로 사용하고 있었다. 영회한테야 방심한 채로 책이 진도가 나가는지 어떤지를 다 얘기하고 있었다. 그것을 눈치챈 김 부사장님은 영회에게 정기적으로 보고를 받으면서 책을 얼마나 썼는지, 지금 쓰고 있는지, 질질 끌고 있는지 등등을 파악하고 있었다. 나한테 별 관심이 없는 영회가 수시로 "형. 책 얼마나 썼어?"라고 물어볼 때 눈치챘어야 했는데…

그러는 중에 6월이 됐다. 그리고 충격적인 얘기를 들었다. 지난 일년간 준비해온 중요한 프로젝트가 갑자기 무산됐다는 소식이었다. 이미 담당자를 통해서 기획서가 작성돼서 회장의 결재까지 다 끝났고 예산도 이미 잡혀 있어서 진행만 하면 되는 상황이었는데 무슨 일인가 해서 알아봤다. 알고보니 국제적인 경제위기로 수익이 줄어든 다국적 기업 S가 코묻은 돈까지 다 싹쓸이하자는 전략을 세워서 우리 고객사에까지 접근을 한 것이었다. 그리고 고가의 제품을 덤핑 수준의 가격으로 제시하면서 담당 임원을 공략했다. 국제적인 브랜드에 넘어간 해당 임원이 갑자기 기존 기획을 취소 시키고 해당 제품을 들이기로 결정했다. 요즘 J모 언어를 말아먹는다고 말이 많은 O모사에게 프로젝트를 막판에 뺐긴 카이스트에서의 일이 다시 재현된 것이다. 카이스트 일이야 진행할만큼 하고나서 넘어간 것이라 그래도 덜 억울했는데, 이건 비용도 적지 않게 들여서 기획을 다 해놨는데 초장에 일을 뺐겼으니 더욱 황당했다.

이미 다 따논 일이라고 안심하고 있었는데 일이 날라가면서 갑자기 공중에 붕 뜬 꼴이 됐다. 호주를 떠나기 전에 진행하던 로컬 비즈니스는 잠정적으로 중단시켜논 상황이었고, 일단 기존 프로젝트를 진행하면서 호주 비즈니스는 차근 차근 셋업해 나갈 계획이었는데, 갑자기 할 일이 날라가버렸으니!

남자는 직업을 잃을 때 가장 큰 충격에 빠진다고 한다. 거의 배우자가 바람핀다는 것을 알게됐을 때의 충격이라고 한다. 나는 뭐 직업을 포기해야 하는 것은 아니었지만, 다 따논 일을 이렇게 막판에 날리면 충격이 크다. IMF로 핵심 공급업체 두 군데가 부도가 나서 일년 넘게 준비한 인터넷 서비스를 그대로 접어야 했을 때, 9/11 사건의 여파로 다 된 프로젝트를 날려버리고 준비중이던 50여명의 프로젝트 팀원에게 돌아가서 각자 살길을 찾으라고 말해야 했을 때나, 큰 일을 함께 추진하던 파트너 업체가 사실은 부도 직전이라는 것을 알게 됐을 때, 조직개편으로 프로젝트 진행 부서가 통채로 공중 분해됐을 때, 프로젝트를 진행하던 연구소의 출입문 비밀번호가 바뀌고 연구소가 폐쇄됐다는 것을 알았을 때 등등. 그런 경험이 적지 않았지만 아무튼 매번 충격이다.

6월. 호주의 살을 에이는 듯한 추운 겨울이 다가오고 있을 무렵이었다. 며칠을 멍하니 앉아서 이제 무엇을 해야하나 하고 고민을 했다. 그리고 결심했다. 책을 쓰자. 일은 나중에 하고 일단 책을 먼저 빨리 마무리 해야겠다는 생각이 들었다. 그때가 절호의 기회라고 생각이 들었다. 진행 중인 프로젝트는 모두 마무리 되었고, 앞으로 하려고 했던 프로젝트는 날라갔다. 호주에서 함께 일했던 비즈니스 파트너들에게서 연락이 와서 새로운 일을 벌이자는 요청이 있기는 했지만 일단 모두 거절했다.

그리고 나도 로드 존슨이 J2EE D&D를 처음 쓸 때처럼 한 일년쯤 책 저술에만 매달려야 겠다는 생각을 했다.

그렇게 해서 드디어 토비의 스프링 3을 처음 쓰기 시작했다. 그게 몹시 춥던 2008년 6월이었다.

토비의 스프링 3이 나오기까지 (6)

토비의 ‘이제는 말할 수 있다’ 여섯 번째 이야기.

본격적으로 책을 쓰기로 결심하고 나서 가장 먼저 시작한 일은 스프링 공부였다. 스프링에 대해서는 누구보다 더 많이 연구했고 알고 있다고 자신하지만, 그래도 내가 자주 사용하지 않는 옵션들과 접근방법들에 대해서 꼼꼼하게 점검해볼 필요가 있다는 생각이 들었다. 스프링 2.5.6의 레퍼런스 매뉴얼을 처음부터 꼼꼼하게 읽어나가면서 그 내용 하나 하나를 학습 테스트로 만들기 시작했다. 코드를 만들어 확인해보지 않은 지식은 내 지식이라고 할 수 없다는 평소의 지론대로 내가 써보지 않은 옵션과 조합, 설정 방식 등을 모두 한 번씩 적용해가며 테스트 코드를 만들어 나가기 시작했다. 학습테스트를 이용한 학습방법은 내 블로그에도 한 번 썼듯이 매우 유용하고 확실한 기술 습득 방법이다. 애자일 자바는 자바 언어 수준에서 초보적인 학습테스트를 활용한 것이다. 그렇게 레퍼런스의 내용을 빠짐없이 테스트로 만들어나가면서 스프링의 다양한 기술조합을 공부하다보니 시간이 적지 않게 흘렀다. 내가 익숙지 않은 몇 가지 기술과 테스트 작성하기가 힘들어보이는 웹 기술을 빼고 나머지 모든 스프링 기술에 대해서 학습 테스트 작성을 끝내고 나니 9월 말이었다. 3개월의 시간을 그렇게 쏟아붓고 나니 머리 속에 스프링의 전 기능에 대한 지도가 그려진 것 같은 느낌이 들었다. 그렇게 만들어진 학습 테스트 코드는 나중에 책을 쓸 때 매우 유용하게 활용했다. 책의 2부는 바로 그렇게 학습 테스트를 만들어가면서 공부하는 식의 내용이다. 물론 책의 예제로 들어가는 테스트는 3.0에 맞춰서 모두 새롭게 쓰긴 했지만, 어쨌든 처음 만들어둔 테스트가 아주 중요한 역할을 한 것은 분명하다.

그리고 10월이 되서 처음으로 책 원고를 쓰기 시작했다. 처음 저술요청을 받았을 때 페이지 분량을 확인해보는 용도로 쓰라고 김 부사장님이 주신 원고 템플릿 파일이 있다. 그 워드 파일의 포맷에 맞춰서 글을 쓰면 대략 몇 페이지쯤 된다는 것을 파악할 수 있게 만들어진 것이다. 그런데 아무리 찾아도 그 파일이 보이지 않았다. 다시 달라고 할까 싶었지만 그랬다가는 아직 시작도 안한 것을 들키고 말테니 안되겠다 싶었다. 그래서 나보다 먼저 에이콘 출판사를 통해서 책을 출간했던 현철주님 한테 원고 샘플을 요청을 했다. 현철주님은 스트럿츠2 책을 쓰신 멋진 분이다. 그 책을 쓸 때 사용한 워드 파일이 있을테니 그 파일을 가지고 글을 쓰면 출판사에서 원하는 페이지 분량에 맞출 수 있을 것이라고 생각했다. 그렇게 받은 스트럿츠2 원고 파일을 기준으로 스타일을 만들어서 내 책의 템플릿 파일을 작성했다. 그리고 꼼꼼히 확인하려고 인쇄된 책을 가져다가 가로 세로 글자 수와 줄 수를 세어서 실제 책의 페이지 분량과 일치하는지도 확인했다.

그런데, 그렇게 준비된 템플릿을 이용해서 원고를 작성했음에도 막상 최종 편집을 하고 보니 워드 파일보다 페이지 수가 훨씬 늘어났다. 부록을 빼고 내가 출판사에 넘겨드린 워드 파일의 페이지 수는 1030페이지쯤 됐다. 그런데 꼭꼭 눌러서 편집을 했음에도 최종 편집 결과는 1400페이지 가까운 것이었다. 어떻게 30% 가량 차이가 났는지는 지금도 의문이다. 그 사이 출판사의 책 크기와 폰트, 간격, 여백 등의 기준이 바뀐 것인지, 아니면 내가 뭔가 착각을 해서 템플릿 파일의 페이지 크기 조절을 잘못한 것인지 모르겠지만. 아무튼, 나는 1400페이지짜리 두꺼운 책을 쓰려고 한게 절대 절대 아니다! 이 얘기는 나중에 다시.

원고 템플릿을 만들고 나서 처음 한 일은 제목과 부제를 쓰는 것이었다. 물론 책 판매에 중요한 영향을 미치는 책 제목과 부제는 나중에 출판사의 결정에 따라서 바뀌게 된다는 사실을 잘 알고 있지만, 일단 내가 쓰고 싶은 것으로 적었다. 제목은 ‘애자일 스프링’. 부제는 ‘스프링과 함께 더 나은 개발자가 되는 법’. 내가 이 책에서 하고 싶은 얘기가 무엇인지 다시 생각해봤다. 단지 스프링을 어떻게든 빨리 사용하도록 안내하는 책인가? 아니면 스프링 기술을 깊이 파는 마니아를 위한 책인가? 아니면 뭘까? 2004년부터 시작된 나의 스프링 경험을 돌아보면 가장 내 기억에 남는 것은 스프링을 공부하고 적용하면서 프로그래밍에 대한 나의 생각과 시각, 습관이 바뀐 것을 느낄 수 있었다. 처음엔 그저 XML에 빈 설정하고 컨테이너 만들어서 DI방식으로 오브젝트가 생성되게 해서 쓰는 것이 전부라고 생각했던 스프링이 사실은 그보다 더 중요한 원리를 충실히 따르면서 자연스럽게 만들어진 것을 깨달았다. 그리고 스프링에 적용된 그 원리와 프로그래밍 습관이 내가 작성하는 코드에도 서서히 녹아어가기 시작했음을 알고 짜릿했던 순간들. 그동안 공부했던 다양한 프로그래밍 원칙과 패턴이 자연스럽게 엔터프라이즈 환경에 실체화된 것이 스프링이라는 사실을 하나씩 구체적으로 발견했던 기억들. 아무튼 그 속에서 내가 스프링을 사용하기 전보다 좀 더 나은 개발자가 되었음을 얘기하고 싶었다.

물론 내가 생각했던 제목은 나중에 김희정 편집장님이 단칼에 "애자일? 절대 안돼요!”라고 잘라버리셔서 전히 빛을 볼 수 없긴 했지만. 사실 그 뒤에 생각했던 몇 가지 제목이 더 있는데 차마 말을 꺼낼 수도 없었다. 뭐, "스프링 공중부양"이라든가 "엣지있게 스프링" 따위. 최종 제목과 부제는 모두 김희정 부사장님의 정하셨다. 나는 단지 "어때요" 하셔서 자동으로 "네"라고 했을 뿐. 책 제목에 내 이름(토비)이 들어가는 것이 처음에는 좀 그랬는데, 워낙 스프링 책이 많다보니 책 이름이 아무래도 혼동되기 쉬울 것 같고, 뭔가 확연하게 구분되려면 좀 독특한 이름을 쓰는 것도 나쁘지 않겠다고 생각됐다.

빈 원고에 제목 두 줄을 쓰고 나니 정말 책을 쓴다는 느낌이 들었다.

그리고 서문을 쓰기로 결정했다. 사실 김희정 부사장님은 "서문은 일단 쓰지 마세요"라고 했다. 물론 왜 쓰지 말아야 하는지 설명은 없이. 대충 짐작이 가는 바가 있었지만, 그래도 나는 나중에 버리는 한이 있더라도 서문을 쓰고 싶었다. 영회가 그렇듯이 나도 한 때는 책의 서문과 목차, 추천글 등을 제끼고 바로 1장으로 들어가는 버릇이 있었다. 1장이 만약 역사니 의미니 하는 내용이 나오는 것 같으면 1장도 제끼고 본격적인 내용이 시작되는 2장으로 넘어가기도 했다. 그런데 언젠가 책의 서문에 저자가 남긴 내용이 얼마나 중요한지 알게된 후로는 책의 서문을 꼼꼼하게 읽는다. 그러면 그 책을 어떻게 읽어야 할지 그림이 그려진다. 물론 성의 없이 쓴 듯한 서문은 좀 그렇지만.

보통 서문을 읽어보면 서문을 먼저 쓰고 본문을 썼는지 아니면 그 반대인지 알 수 있다. 보통 책을 다 쓰고 나서 쓴 서문이 많은 것 같다. 그래도 나는 일단 서문을 쓰고 싶었다. 내가 이 책을 왜 쓰는지, 어떤 얘기를 하고 싶은지 내 자신한테 얘기하고 싶어기 때문이다.

코드를 작성하면서 스프링 기능을 정리할 때는 PC에서 작업을 하는 것이 수월했지만 막상 책의 원고를 쓰기 시작하려니 좀 더 집중할 수 있는 환경이었으면 좋겠다 싶었다. 그래서 10월 초부터 브리즈번 강가에 있는 퀸즈랜드 주립 도서관에 다니기 시작했다. 이 도서관에는 서고, 열람실과 별도로 아무나 자유롭게 들어와서 PC도 사용할 수 있고 다양한 모양의 의자와 소파 등에 앉거나 누워서 공부도 하고 책도 볼 수 있는 공간이 있다. 특히 무선 인터넷과 전원이 공짜로 제공되기 때문에 유학생들이 즐겨 찾는 장소이기도 하다. 노트북을 들고 기차를 타고 시내로 나가서 강가를 따라 걸어서 도서관으로 갔다. 그렇게 3일 동안 도서관에 다니면서 5페이지짜리 서문을 완성했다. 그게 따듯한 봄이었던 2008년 10월이었다.

물론 서문을 쓰지 말라고 했음에도 써버린 나는 결국 김희정 부사장님의 주문에 따라 서문을 대신할 ‘들어가며’라는 스프링 소개 글을 다시 써야 했다. 그래도 서문에 썼던 얘기의 상당부분은 그대로 ‘들어가며’ 안에 남겨둘 수 있어서 다행이긴 하다. "쓰지 말라는 서문을 왜 썼어욧!"이라고 혼나지 않은 것만 해도 다행이었다.

내 원고는 PC와 서버에 git 리포지토리를 만들어서 관리했다. 완성된 서문을 git 리포지토리에 처음 커밋한 것이 10월 13일이다. 그리고 그 뒤로 약 500번 정도 커밋을 더 하고나서 책이 완성됐다.

서문을 마치고 1장을 시작했다. 나도 다른 책의 따분한 1장이 싫었다. 특히 기술의 역사가 나오면 가장 짜증났다. 내가 알고 싶은 것은 지금 내가 사용할 버전의 기술이지, 장황한 기술 역사와 그 역사를 꿰고 있다는 저자의 자랑이 아니었다. 물론 그렇다고 특정 기술설명이나 코드로 바로 들어가는 것은 적절해보이지 않았다. 스프링을 예제와 사용법 위주로 공부하면 전체를 꿰뚫는 프로그래밍 모델과 철학을 놓치기 쉽다. 프레임워크를 사용하는데 개발철학 따위야 꼭 필요한 것은 아니지만 스프링은 예외다. 스프링은 기본을 알면 이해하고 응용하기가 아주 쉬운데 그렇지 않고 개별 기술을 따로 따로 공부하면 그 방대한 양에 금세 지쳐버린다. 게다가 스프링 만큼 오해가 많은 것도 없다. 그래서 일단 1장에서 스프링이란 도대체 뭐고, 뭐에 쓰는 것이고, 스프링이 어떤 유익을 주는지에 대해서 적기로 했다. 대신 스프링의 역사 따위는 한 문장 쯤으로 끝내버리고.

거의 한 달만에 1장을 완성했다. 물론 책 쓴다고 손가락 빨고만 있을 수는 없으니 부담 없이 장기간 진행할 수 있는 가벼운 프로젝트를 준비하기도 해야 했다. 11월 중순에 2장을 시작했다. 1장의 제목은 ‘스프링이란 무엇인가’ 였고, 2장의 제목은 ‘애자일 개발과 스프링’으로 정했다. 다른 책의 제목을 흉내낸 것이긴 하지만 일단 애자일 스프링이라고 정한만큼 애자일 개발 방법과 스프링의 상관관계를 POJO와 테스트편의성을 중심으로 설명해봤다. 사실 2장의 목적은 테스트의 중요성을 강조하기 위한 것이었다. 애자일은 그냥 테스트에 대한 이야기를 풀어내기 위한 도입기재로 사용한 것이고.

2장을 쓰는 중에 영회가 자꾸 책 진도를 물어왔다. 그래서 1장을 마쳤으니 한번 읽어보라고 1장 원고를 넘겨줬다. 2장은 완성되면 줘야지 하고 아직 넘기지 않았다. 진득하게 기술을 공부하고 연구하는 것보다는 사람들과 어울려서 수다떠는 것을 더 좋아하는 영회인지라 원고가 넘어가고도 한참이 지나서야 겨우 읽은 듯 했다. 다 읽었다고 하길래 어땠냐고 물어봤다.

그 질문을 한 것이 일생일대의 실수였다.

돌아온 영회의 피드백은 충격적이었다. 사실 기대한 것은 스프링에 대해서 이렇게 설명하는 것보다는 이렇게 하는 것이 좀 더 이해하기 쉽지 않겠냐라든가 스프링의 정의에 이런 요소를 넣었으면 좋겠다와 같은 실제 1장의 의도에 맞는 분석이나 제안이었다. 하지만 영회는 원래 그런 것에 별 관심이 없다. 평소에 문과 출신이고 IT계에서 흔치 않게 인문학적 소양이 높다는 점을 자랑했듯이 돌아온 피드백도 스프링의 기술과 본문의 내용과는 상관없는 단순 인상비평이었다.

"지루해. 문장이 번역투 같애"

영회의 평소 언행을 생각해보면 그다지 좋은 얘기가 나올 것을 기대할 수는 없었지만, 그래도 좀 심하다 싶은 얘기들이 돌아왔다. 자기야 그냥 느낌을 얘기하는 것이겠지만, 평소에 "자기는 글을 잘 쓰지만 나는 못쓴다"고 주장했던 것을 생각해보면 내용과 그 의미 보다는 책으로 쓰여진 글의 짜임새나 문장력을 평가한듯 싶었다. 문장이야, 나중에 나도 읽어보면서, 좀 늘어지고 어색하다고 느낀 부분이 제법 있기는 했지만, 그래도 로드 존슨 책처럼 간결하게 핵심을 짚은 내용을 최대한 함축적으로 나열하려고 한달간 매일 열시간 이상 끙끙대면서 쓰고 고치고 했던 내용을 칭찬 한마디 없이 그런 식으로 싸잡아서 비판 하는 것을 들으니 눈물이 핑돌았다.

위기가 왔다.

속도 상하고 화도 많이 났다. 책을 쓴다고 5개월 가까이 투자해 왔는데 건질게 없는가 해서 좌절감이 몰려왔다. 나는 책을 쓸 자질이 없다는 생각이 들었다. 그리고 결국 때려치기로 마음을 먹었다. 나야 몇 달의 시간을 투자한 것을 버리면 그만이었다. 그런데 출판사와 김희정 부사장님이 문제였다. 원고를 장기간 끄는 저자 때문에 당시 잘 나가는 스프링 관련 책도 못내고, 그렇다고 닥달도 못하고 속앓이만 하고 있을 김 부사장님한테 미안했다. 그래도 어쩌겠는가. 이왕 해외로 나온거 그냥 도피해야겠다고 생각했다. 다시 한국에 돌아가서 일 할 것도 아니니 아쉬울 것도 없었다. 이참에 인연을 끊어보자고 생각했다. 블로그는 폐쇄하고, 메신저는 다 끊고, 한국에서 걸려온 전화는 무시하면 그만이겠구나 싶었다.

이런 저런 생각을 하면서 며칠을 허탈하게 보냈다.

그래도 포기하지 말자는 생각을 했다. 영회가 평소에 하도 씹어대서 내가 글을 잘 못쓴다는 것은 진작에 알고 있었지만, 사실 책에 들이는 정성에 비하면 거의 장난삼아 쓰는, 구성과 내용은 물론이고 오자가 넘처나는 내 블로그 글도 누군가 꾸준히 와서 보고 도움을 받는다고 얘기하던 것을 생각해봤다. 그냥 블로그 쓰는 만큼, 그 수준으로 쓰자. 설마 누군가에게는 도움이 되겠지라, 내 경험을 나누면서 쓰는 블로그 글처럼 내 책도 그런 수준이면 되지 않겠는가 하는 생각을 했다. 영회 같은 까칠대마왕이 아니라면 뭐 문체를 따지고 그럴까 하는 생각도 했다.

그렇게 다시 며칠을 마음을 비웠다. 그리고 그 때까지 쓴 1,2장 원고를 모두 버렸다.

다시 처음부터 시작.

책의 구상부터 다시 새롭게 하기로 마음 먹었다. 그때가 2008년 11월이었다. 그리고 12월에는 미국에서 열리는 스프링원(TSE가 S1 America로 이름을 바꿨다)에 참석하기 위해서 미국에 가면서 한국에도 들리기로 했다. 도피하듯 나온 터라 제대로 인사도 못했던 김희정 부사장님을 한 번 볼 수 밖에 없는 상황이었다. 계약한지 2년 가까이 되가는 마당에, 그나마 썼던 원고는 영회의 이단 옆차기로 모두 날려버린 상태. 그리고 완전히 백지에서 다시 쓰기로 마음먹은 상황에서 김희정 부사장님을 만나게 된 이야기. 그리고 영회에 대해서 복수의 칼을 갈기 시작하고 일년 간의 치밀한 계획 끝에 복수에 성공한 이야기 등등은 내일 계속.

토비의 스프링 3이 나오기까지 (7)

영회가 생각없이 던진 돌에 정통으로 맞아 쓰러지고 나서 시간이 조금 흐르니 오히려 마음이 편해졌다. 어짜피 내가 아무리 용을 쓰고 책을 잘 써봤자 영회같은 인간들이 분명히 나타나서 이런 저런 시비를 걸 것이 분명했다. 어짜피 어떻게 해도 욕먹을 거라면 그냥 내가 쓰고 싶은 대로, 내가 하고 싶은 얘기를 하면 되겠다고 생각하니 그때까지 가졌던 긴장감이 다 풀렸다. 잔뜩 주고 있던 힘이 빠지고 나니 오히려 그 다음은 쉬웠다.

날려버린 1장을 처음 쓸 때 사실 힘들었다. 그 1장에는 코드 한줄 나오지 않는다. 대신 3만피트 상공으로 올라가서 스프링 세계를 내려다보며 스프링이 이렇게 생겼네라고 구름 위에서 얘기하듯이 설명하는 내용이다. 그래서 신경쓸 것은 단어, 표현 등이었다. 함축적인 단어를 어떻게든 잘 골라서 이런 저런 스프링의 특징을 깔끔하게 묘사해야 할텐데라는 고민으로 대부분의 시간을 보냈다.

나는 그런 식의 얘기가 편하지 않다. 내가 가장 편한 시간은 코드를 앞에 놓고 코드에 대해서 이야기 할 때다. 열 줄 정도의 코드만 있어도 재미나게 한 시간쯤은 수다를 떨 수 있다. 지난 27년간 거의 매일 만들고 다듬고 뜯어보고 감상해왔던 것이 코드다. 그래서 누군가에게 기술을 설명해줄 때도 코드를 놓고 이야기해야 편하다. 특히 어설픈 코드를 만들어 놓고 그것을 다듬고 발전시켜서 아름다운 코드로 만들어내는 과정을 즐기는 것이 좋다.

그래서 다시 1장을 쓰면서 가장 먼저 코드 하나를 들이 밀었다. 초난감 DAO. 왜 하필 DAO로 시작했을까? 사실 1장은 스프링의 DI를 설명하려고 쓴 것이다. 보통 스프링 서적이나 교육시간에는 다형성이 적용가능한 도메인 모델을 가져다가(예를 들면 찬욱이가 잘 쓰는 피자 주문 어쩌고 같은) XML로 설정을 바꿔가며 DI하는 모습을 보여주는 것이 일반적이다. 하지만 나는 그런 현장감이 없는 코드가 싫었다. 개발자라면, 심지어 이제 막 자바 교육과정을 마친 초보 개발자라도 쉽게 이해할 수 있는 익숙한 코드를 가지고 설명하고 싶었다. 그래서 선택한 것이 가장 간단하고 단순한 DAO 코드이다. DAO 코드만 가지고도 DI를 설명하기에 충분하다.

나는 이미 이전에 간단한 DAO 코드를 가지고 스프링의 DI를 설명해본 경험이 있다. 2007년 (북반구) 여름에 연변자치주 내의 연길시에 있는 연변과학기술대학(YUST)에 방문한 적이 있다. 그냥 방문이 아니고, YUST의 IT교육센터에 초빙강사쯤으로 간 것이다. 거기서 2주정도 체류하면서 조선족 대학졸업자를 대상으로 진행하던 4개월간의 합숙 교육과정의 마지막 단계인 프로젝트 실습시간을 맡아서 자바의 기초를 이제 막 배운 학생들과 함께 교육과정을 마무리 하는 프로젝트 교육을 진행했다. 당시 교육과장에 참여했던 20여명의 학생 중에서 소수만이 북경에 있는 SI업체에 취업이 확정된 상태이고 다른 학생들은 아직 일자리를 찾지 못하고 있어서 기운을 잃고 있던 상황이었다.

YUST의 IT교육센터는 YUST가 그렇듯이 조선족 젊은이들에게 양질의 교육 프로그램을 제공해서 중국 사회, 나가서는 세계적으로 실력있는 전문가를 만들어내려는 목적으로 2007년 초에 설립되었다. 매일 새벽 운동으로 시작해서 밤 12시까지 교육과 실습 시간을 가지고 학교내의 기숙사에 머물면서 강도 높은 교육을 진행한다. 이 교육센터를 설립하고 강사로 일하는 분들은 모두 자원봉사자들이다. 다들 한국에서 이름을 날리던 IT전문가, 유명 강사들인데 자신의 삶에서 몇 년의 시간을 떼어서 자원의 제약이 많은 지역에 살고 있는 사람들에게 지식을 나누고 꿈을 심어주기 위해서 아무런 댓가도 없이 이국땅에 모인 존경스러운 분들이다.

아무튼 거기서 보낸 2주간의 시간은 참 행복했다. 학생 대부분은 IT전공자가 아니다. 심지어 영어를 전혀 못하는 사람도 있었다. 연변자치주 내의 조선족 학교에 다녔던 학생들은 중고등학교 시절에 영어가 필수 과목이 아니었다고 한다. 보통 일본어를 더 많이 공부했고, 대학에 진학해서야 교양과목 수준으로 영어를 배운 사람들이 많다. 그래서 일부는 대졸자임에도 알파벳에도 익숙하지 못한 사람들이 있었다. 그래서 알파벳과 영어단어를 읽는 것부터 가르쳐야 했다.

이 교육센터의 특징은 24시간 선생님과 학생들이 함께 하는 것이다. 물론 가족이 있는 선생님은 학교 주변의 숙소에 머물긴 하지만, 정규 교육시간이 끝나고 집에 가서 저녁 식사를 하고 야간 실습시간이 되면 다시 학교로 올라와 12시, 심지어는 새벽까지 그날 공부한 내용을 학생들이 실습해보면서 막히는 것이 있으면 옆에 붙어서 가르쳐 주고, 개인적인 상담도 해주기도 했다. 일부 학생들는 ABC부터 공부해가면서 그렇게 열심히 자바를 배웠다. 그 와중에 SCJP시험도 공부해서 대부분 SCJP도 딴 상태였다(학생들을 받아주기로 한 업체의 요구사항의 하나였다고 한다). 하지만 막상 내가 프로젝트 수업을 어떻게 진행할까 고민하면서 그동안 공부한 내용을 살펴봤을 때는 참 막막했다. 자바 언어와 JDBC, DB(SQL), HTML/자바스크립트, 서블릿, JSP 모델1 정도를 배운 것이 전부였다. 사실 맨땅에서 그만큼이라도 공부한 것은 대단했다. 나름 공부한 내용은 끊임없이 실습하고, 반복해서 학습했기 때문에 익숙했다.

4개 조를 나눠서 주어진 요구사항을 충족하는 웹 애플리케이션을 만들도록 했다. 스프링 따위는 사용할 엄두도 낼 수 없었고, 내가 하루 밤 사이에 급조해서 만든 초간단 MVC 프레임워크를 사용해서 모델2로 만들도록 했다. 매일 새벽 1시에 건물을 관리하는 분이 나가라고 찾아올 때까지 함께 코드를 만들어가면서 그렇게 열흘 정도를 보내고, 기대 이상의 멋진 결과물을 만들어서 YUST 전산과 교수님들을 모아 놓고 발표회를 가질 수 있었다. 내가 일했던 회사의 개발자들에 비하면 다들 형편없는 수준의 초보자였지만, 하나도 놓치지 않고 배우고자 하는 열정과 끈기가 대단했고, 교육해주는 강사에 대한 고마운 마음과 존경심이 대단했다. 참 행복한 시간이었다. 처음엔 취업이 되지 않아서 실망하고 열정도 잃었던 학생들이 코드를 만들어나가면서 동작하는 애플리케이션을 보고 환호하고 서서히 자신감을 찾아나가고 미래에 개발자로서 살아갈 꿈을 꾸는 모습을 보는 것이 즐거웠다.

다행히 대부분의 학생들은 북경과 상해의 여러 업체에 취업이 되었고, 일부 학생들은 한국 SI업체의 북경지사에 취직해서 프로젝트 하러 한국에 다녀가기도 했다.

그런데, 기껏해야 내가 만든 간단한 MVC 프레임워크(URL 컨트롤러 매핑은 프로퍼티 파일을 사용하게 했다)와 원시적인 JDBC API로 만들어진 DAO를 이용하는 코드를 만들어본 경험이 전부인 초보자들인데, 일부 SI업체들은 전혀 교육도 시켜주지 않은 채로 스프링을 써야하는 프로젝트에 마구 투입했다. 내 생각에는 아마 프로젝트에 비용을 맞추기 위해서 신입들을 머리수 채우는 용도로 넣은 것이 아닌가 싶다. 아무튼 그렇게 여러 사람들이 스프링 개발을 해야 하는데 막막해 하고 있다는 얘기를 전해 들으니 가슴이 아팠다. 그렇다고 내가 뭔가 뾰족하게 도와줄 방법도 없었다. 그저 책과 자료를 알려주고 차근차근 공부하라고 할 수 밖에. 하지만 내가 아는 스프링 책들과 인터넷의 자료들은 그저 자바기초와 JDBC, JSP 정도를 아는 경험없는 초보 개발자들이 쉽게 독학으로 스프링을 익힐 수 있는 것들이 아니었다.

그러던 즈음에 IT교육센터에 보조강사로 남은 졸업생의 한 명인 향화가 스프링을 알려달라고 연락이 왔다. 향화는 YUST를 졸업하고 유학을 준비하던 즈음에 강사로 간 분의 꼬임에 넘어가 IT교육센터에 입학했다. 내가 가르쳐본 경험으로는 가장 우수한 학생이었다. 한족이지만 한국어를 제법 잘해서 교육을 함께 받았던 소강이와 함께 가장 학습능력이 뛰어나고 프로그래밍 실력이 좋은 학생이었다. 그래서 마음만 먹으면 얼마든지 원하는 회사에 갈 수 있었지만, 자기는 연길에 남아서 후배들을 가르치는 일을 하고 싶다고 취업을 포기하고 보조강사로 IT교육센터에 남은 기특한 아이였다. 막상 보조강사는 하고 있지만 교육센터의 프로그램은 IT 기초소양교육과 자바 프로그래밍 기초였기 때문에 스프링과 같은 고급 기술을 배울 기회가 없었다. 그런데 막상 현장에 나가서 일을 하는 졸업생들은 스프링은 어디가나 다 쓰기 때문에 꼭 배워야 한다는 얘기를 전해오고 있었으니, 자신도 스프링을 좀 준비해둘 필요가 있다고 생각한 것이다.

내가 놀랐던 사실 하나는 2007년 여름에 중국 아마존 사이트에 등록 되어있는 스프링 2.0 서적이 무려 20권이나 있다는 사실이었다. 한국에는 2.0책이라곤 SiA 2판이 겨우 나왔을 때였는데 말이다. 그만큼 중국에서는 스프링을 많이 사용한다. 뭐, 일본도 그렇고 전세계가 다 그렇지만. 아무튼 한국과 비교했을 때 당시 중국의 스프링 도입률이 훨씬 높았다.

아무튼, 당시 나는 서울에서 일을 하고 있었고 향화는 중국 연길에 있었다. 교육을 해준다고 해도 기껏해야 스카이프와 메신저가 전부였다. 그나마 코드는 SVN을 이용해서 서로 공유해서 볼 수 있었지만. 향화는 공대출신이기는 하지만 IT전공자가 아니었으니, 자바 지식이라곤 교육센터에서 4개월 배운 것이 전부였다. 따라서 자바 언어 기초, JDBC/DAO, 서블릿/JSP 정도는 확실하게 알고 다룰 수 있는 실력이지만 그 외의 프레임워크니 기술은 전혀 사용해본 경험이 없었다.

그래서 향화에게 어떻게 스프링을 가르쳐 줄까 고민하다가 생각한 것이 그나마 향화가 가장 익숙하고 많이 만들어본 DAO였다. 초보 개발자들이 교육센터 등에서 만드는 DAO 수준은 뭐 뻔하다. try/catch/finally라도 적용했으면 다행이고, 그렇지 않은 경우도 많았다. JDBC API를 사용해서 돌아만 가는 CRUD만 만들 수 있어도 잘하는 것이었으니까. 물론 향화는 내가 교육하면서 try/catch/finally나 안전한 DAO를 만드는 방법에 대해서 확실하게 교육했으니 잘 알고 있었지만.

그래서 향화가 그나마 잘 아는 DAO 코드를 하나 만들어줬다. 그리고 그 코드의 문제점이 무엇인지 찾아보고 그 코드를 매일 매일 조금씩 개선하면서 OO적인 코드로 다듬는 것을 알려줬다. 그렇게 짬짬이 원격 교육을 하면서 서서히 DAO코드를 다듬어서 DataSource에 대한 DI도 적용하고 템플릿/콜백도 만들어가는 식으로 설명을 해줬다. 그냥 XML 설정파일 만들고 DAO와 DataSoruce 빈을 등록하고, CRUD는 JdbcTemplate가져다 쓰고, web.xml에 컨텍스트로더리스너 등록해서 돌리라고 가르쳤으면 일주일이면 충분했을 것을 몇 달에 걸쳐서 설명을 해줬다. 하지만 그렇게 스프링을 이해하고 배우는 것이 나중에 내가 더 이상 스프링을 가르쳐 주지 못하고 혼자서 공부할 때 분명 도움이 될 것이라는 확신이 있었다. 결국 나중에 나는 너무 바빠서 교육은 기선이에게도 부탁했다. 교육센터의 보조강사는 기숙사에서 함께 생활하면서 24시간 학생과 함께 지내야 한다. 특히 실습과 시험준비 등으로 새벽까지 남아서 공부하는 학생이 있으면 끝까지 옆에 붙어서 도와줘야 한다. 그래서 나중에는 너무 바빠서 더 이상 충분히 공부할 시간이 없어서 스프링 공부는 흐지부지 끝나고 말았다.

다시 1장을 쓰기로 마음먹고 무엇인가 코드를 일단 던져 놓고 시작을 해야겠다라고 생각했을 때 향화에게 스프링을 가르쳐 주던 생각이 났다. 그때 사용했던 DAO코드를 개선해 나가면서 스프링을 적용하는 과정을 이용하면 되겠다는 생각이 들었다. 김희정 부사장님이 만날 때마다 하셨던 얘기는 "책을 쉽게 써야 한다"였다. 보통 처음 책을 쓰는 사람은, 욕심에 책을 어렵게 쓰는 경향이 있다. 자기 주변에 잘 하는 사람들이 많이 있을테니 그 사람들이 봐도 있어보일만한 책을 쓰려는 욕심이 들기 쉽다. 또, 독자들이 자기 주변의 사람들 처럼 이미 선지식이 충분히 있을 것이라고 착각하기도 쉽다. 당연히 JUnit도 척척 쓸 줄 알고, 자바 언어와 디자인패턴도 완벽히 꿰고 있을 것이라고 착각하기 쉽다. 하지만 대부분의 독자는 그렇지 않다. 나도 현장을 다니면서, 나름 유명한 기업의 개발팀 사람들이 JUnit을 들어본 적도 없다는 사실에 놀라기도 했다. 가장 기본이라고 생각하는 자바 콜렉션 프레임워크의 semantics에 대해서도 제대로 이해를 못하는 사람도 많았다. 당장 현장에서 돌아가는 애플리케이션을 만들고 관리하는 것이 주업무였고, 컨설턴트나 아키텍트가 만들어준 템플릿을 이용해서 기계적인 반복 코딩을 했기 때문일 수도 있고.. 뭐 이유는 많겠지만.

물론 주변에서 "한국에도 이제 중고급자(만)을 위한 책이 나와야 하자나요. 마음 것 고급내용으로 어렵게 쓰세요"라고 꼬시는 사람들이 있었다. 하지만 그럴 때마다 어려운 책을 붙잡고 씨름하다 막막해 하는 향화나 교육센터 졸업생들을 생각해봤다. 그래서 그들도 볼수 있도록 책을 쓰자고 결심했다. 또는 그런 비슷한 수준의 초보 개발자들, 또는 자바 입문자들도 공부할 수 있도록 써야 겠다고 생각했다. 물론 자신을 고수라고 생각하는 일부 개발자들은 "책이 너무 쉽다. 블로그 글을 보고 그 수준으로 기대하고 샀는데 사기 당했다"라고 원망할 수도 있을 것이다. 물론 치밀한 나는 그런 사람들을 위해서 중간 중간에 난이도가 높은 내용을 틈틈히 박아두기는 했지만.

아무튼, 그렇게 해서 1장을 썼다. 막상 코드를 꺼내놓고 얘기를 풀어 나가니 줄줄 잘 써졌다. 코드만 만지면 이게 무슨 짓을 하는 것인지 정리가 안될테니 중간 중간에 이런 저런 이론을 가지고 배경을 설명하려고 노력했다. 물론 그런 이론 얘기가 나오면 경기를 일으키는 개발자들도 있기 때문에 이런 얘기는 몰라도 그만이라고 둘러대고 넘어가야 했지만. 사실 스프링의 DI를 XML 설정파일이라고 착각하는 개발자들이 많다. 소위 대안 언어씩이나 한다는 사람들이 스프링도 별거 없다고 까면서 흔히 꺼내는 것이 바로 XML 설정파일 같은 거 써야 하는 자바 언어의 후진성에 관한 얘기다. 물론 다 DI의 D자도 제대로 모르기 때문에 나오는 헛소리다. 스프링이 말하는 DI는 평범한 프로그래밍 원리일 뿐이고 자바 언어만으로 충분하다. DI로 검색하면 DI에 대한 정의 – 애플리케이션 코드와 어셈블러(의존관계 설정의 책임을 맡은 놈)를 분리해서 개발하는 방법 – 가 널려있는데, 그걸 자꾸 언어의 한계 때문에 XML 설정파일을 사용하는 프레임워크가 필요한 기술이라고 왜곡 시키는 사람들을 나는 도무지 이해할 수 없다.

그래서 XML 한 줄 없이, 스프링 코드 전혀 없이 DI를 적용하는 모습을 보여주고 싶었다. 그래서 100페이지쯤 되는 1장의 절반이 될 때까지 DI를 줄곳 설명하고 코드를 보여주지만 스프링은 전혀 등장하지 않는다. DI에 스프링이 필요한게 아니니깐 등장할 필요도 없다. 그리고 나서 DI컨테이너(또는 프레임워크)로서 스프링을 활용하면 그 때까지 평범한 자바로 했던 DI작업이 좀 더 편해진다는(물론 규모가 있는 DI적용의 경우에) 설명을 곁들여서 DI와 DI프레임워크의 차이점을 보여주려고 했다.

제법 빠른 속도로 그렇게 1장을 써나가던 12월 초에 드디어 스프링원 아메리카 참석차 한국을 거처 미국으로 떠나게 되었다. 친절한 민호가 나와 기선이 모두 스프링 컨퍼런스에 다녀올 수 있도록 후원해주겠다고 했다. 가는 길에 한국에 일주일 먼저 들리기로 했다. 물론 이 선택은 나중에 후회를 했는데, 갈 때는 한국에 스톱오버를 해서 쉬었다 가서 괜찮았지만 올때는 바로 갈아타고 호주로 오느라 거의 24시간 가량 쉬지 않고 비행기를 타야했고, 엉덩이는 거의 의자 모양(비상구 좌석)에 맞게 네모로 변했고, 완전 녹초가 되버리고 말았다. 왜 어떤 사람들이 비행기에서 협소공포증을 느끼고 뛰어내리고 싶어하는지 살짝 이해가 가기도.

아무튼 한국을 간다는 소문이 나자 김희정 부사장님이 만나자고 연락이 왔다. 두둥.

호주로 갑자기 떠났던 불량 저자가 온다고 하니 이 참에 확실히 교육시켜야 겠다고 벼르고 계실거라는 생각이 들었다. 덜덜덜. 그래도 어쩌겠는가. 시내에서 영회와 때마침 한국에 온 성훈이 부부와 함께 김희정 부사장님을 만났다. 성훈이는 MIT에 있던 2007년부터 같은 팀에서 함께 일을 한 적이 있어서 친하긴 했지만 한번도 얼굴을 본적은 없었다. 다른 사람들과 함께 만나서 다행이었다. 설마 3자 앞에서 너무 면박주지는 않을테니까.

차마 진도가 어느정도 나갔다는 얘기는 못했다. 대신 용기를 내서 스프링 3.0이 내년(2009년) 봄에 나온다는데 이왕이면 3.0에 맞춰서 책을 내는게 어떻겠는가 하고 얘기를 꺼냈다. 이미 2.5 책들은 여러 권이 나와서 팔린 상태였고 3.0이 나오는 마당에 2.5 책을 내버리면 뒷북치는 꼴이 되버리는 것이 아니겠냐는 논리였다. 물론 나는 어떻게든 가능한 시간을 벌려는 속셈이었다. 마치 책을 마무리 해가지만 3.0을 기다렸다가 3.0 맞춰서 수정해서 빠르게 3.0 책으로 내는 것이 마케팅 측면에서도 더 낫지 않겠느냐는… 개발자 출신 저자의 얕은 속셈을 다 꿰뚫어 보고 있지만 그럼에도 항상 상냥한 김희정 부사장님은 예상과 달리 "2.0 책 낸다고 계약했는데 3.0까지 가면 어떡해욧"이라고 하지 않으시고 "그럼 3.0에 맞춰서 내는게 좋겠어요. 사장님께도 그렇게 말씀드릴께요"라고 답하셨다. 그런 표현은 없었지만 기획한 책이 빨리 안나온다고 사장님께 혼난다는 눈치였다. 호랭이 희용이가 김 부사장님께 시달린다고 얘기할때와 비슷한 상황이었다. 한편으로는 "도대체 어디까지 질질 끌려나 한번 두고 보자. 3.0이든 4.0이든 어디 한번 해봐라"는 자포자기한 마음에서 나온 얘기가 아니었을까 생각이 들기도 했다.

어쨌든 시간을 좀 벌었으니까 일단 한숨 돌렸다. 점심으로 먹던 중국 요리가 목에 반쯤 걸려있었는데 갑자기 쑥 내려가는 느낌이었다.

스프링 3.0이 2009년 4월에 나온다는 것이 스프링소스의 공식 발표였다. 그런데, 솔직히 말하자면 스프링소스는 약속한 날자에 한번도 스프링 새버전을 릴리스를 한 적이 없다는 사실을 나는 너무 잘 알고 있었다. 그러니 4월에 나온다고 하면 빨라야 8-9월에나 나올 것이 분명했다. 하지만 그런 얘기는 차마 할 수가 없었다. 그때문에 더 죄송했지만 내 코가 석자라.

아무튼 3.0에 맞춰서 내는 것을 허락받고 나니 마음이 한결 가벼워졌다. 물론 김희정 부사장님은 "굳이 정식버전이 다 나오지 않아도 책을 내도 괜찮아요. 일단 RC버전이라도 최대한 내용을 맞춰서 일단 책을 내고, 2쇄 할 때 최종 버전이 나오면 좀 더 보충하는 식으로 해도 돼요"라고 설명해주시면서 릴리스 일정 핑계대서 질질끌지 말고 가능한 빨리 내야 한다는 눈치를 주시긴 했다.

하지만 스프링 개발팀은 내 예상을 훨씬 넘어서 처음 약속보다 8개월이 지난 12월에야 3.0을 내 놓았다. 내 책은 그 뒤로 다시 8개월이 지나서 나오게 되었고.

본격적으로 책의 내용을 써내려간 이야기. 그리고 다음 해 9월 한국 방문과 그 때 벌어진 KSUG 회장 전격 교체작전 등등에 대해서는 내일 다시.

토비의 스프링 3이 나오기까지 (8)

두세 편이면 충분했을 것이라고 생각했는데 벌써 여덟 번째 이야기.

사실 그동안 내 이야기에 나온 사람들은 모두 내가 좋아하는 사람들이다. 책을 쓰는 동안에 나에게 나쁜 짓을 하거나 안좋은 영향을 준 사람들도 있지만 당연히 그런 사람들에 관한 얘기는 적고 싶지 않다. 그래서 여기에 언급된 사람들은 모두 내가 아끼는 사람들이고 여러모로 고맙게 생각하는 사람들 뿐이다. 어떤 상황에서도 프로의 모습을 잃지 않으시며 역자와 저자에 대해 미스테리한 마력을 가진 김희정 부사장님과 멋쟁이 김창제 수석님을 제외하면 나를 포함한 나머지 사람들은 모두 나사가 한두 개쯤 풀려있긴 하지만, 그래도 다들 마음이 따듯하고 알고보면 착한 사람들이다.

그동안 영회는 줄곳 나를 괴롭히는 악당으로 등장했지만, 그건 저술기간 동안 얼마나 힘들었는지를 설명하기 위해서 그런 사건(물론 100% 실제 있었던 일들이다)만 골라 넣었기 때문이지 사실 영회가 항상 나를 괴롭히기를 즐기는 나쁜 사람이기 때문은 절대 아니다. 이참에 실추된 영회의 이미지를 회복시켜주기 위해서 잘 알려지지 않은 영회의 선행을 하나 공개하겠다.

내가 다녀왔던 연변과기대 내의 IT교육원에는 종종 한국의 IT전문가들이 학생들을 위한 특강차 방문하곤 했다. 나도 프로젝트 교육 이전에 한번 특강을 위해서 방문한 적도 있고. 그래서 그 후로 여러 사람들에게 특강을 위해서, 또 새로운 자극과 휴식을 위해서 한번 쯤 연변을 방문하기를 권유해왔다. 보통 일주일 정도 방문을 하면 IT교육원 학생들을 위한 특강 시간을 한번 가지고 기회가 되면 학부 학생들이나 선생님, 교수님들을 위한 세미나를 열기도 한다. 대신 IT교육원은 영리를 목적으로 운영되는 기관이 아니기 때문에 모든 방문자들은 항공권을 포함해서 모든 경비를 스스로 지불해야 한다. 특강을 마치고 학생들과 식사를 할 때도 식사 비용을 방문자가 내는 것이 관례이다. 대신 IT교육원 선생님들이 시간을 내서 도문이나 용정 같은 곳에 데려가 관광시켜 주기도 하고, 현지의 독특한 음식을 맛볼 기회도 제공해준다. 무엇보다도 순수한 마음을 가진 학생들에게 특강을 통해서 무엇을 준비하고 어떻게 살아야할지 이야기 해줄 수 있는 기회를 가진다는 것이 가장 보람있는 일이다.

하지만 이런 얘기를 해줘도 대부분은 시간과 비용에 부담을 느껴서 선듯 가겠다고 나서지 못했다. 일년에 겨우 일주일 정도 휴가를 가지는 것도 쉽지 않은 빡빡한 환경에서 그 시간을 모두 들여서 특강을 위해 외국을 다녀오는 것은 쉬운 일이 아니다. 그런데, 그 얘기를 영회한테 했을 때 영회는 주저 없이 가보겠다고 했다. 마침 영회가 참여했던 큰 프로젝트가 하나 끝나고 프로젝트 포상 휴가가 기다리고 있을 때였다. 영회는 그 시간을 사용해서 연변을 방문하기로 했다. 기꺼이 자신의 시간을 기꺼이 들여서 처음 만나는 학생과 강사들에게 좋은 지식과 경험을 나누고 보람있는 시간을 보내고 돌아왔다.

그런데 정작 내가 감동한 것은 그 후의 일이다. 영회가 특강을 했던 교육원 4기 학생들이 교육을 마치고 수료할 때가 되었다. 보통 졸업식 직전에 1박2일로 MT를 간다. MT 프로그램 중에 항상 빠지지 않는 것은 한국에 있는 IT전문가들의 만들어서 보내준 영상 축하 메시지를 보는 시간이었다. IT교육원을 설립하고 운영하는 데 가장 중요한 역할을 한, MSSQL의 대가인 원혁이 형이 주로 축하 메시지를 보내주는 단골이다. 그런데 4기 졸업 때는 영회도 자진해서 축하 메시지 영상을 만들어서 보냈다는 얘기가 들려왔다. 담당자를 이리 저리 꼬셔서 어렵사리 얻어낸 그 동영상은 지금 다시 봐도 참 감동적이다. 평소에 보이는 잘난척 하는 듯한 말투와 까칠한 눈빛은 보이지 않고 순박하고 착한 형이 동생들에게 해주는 듯한 따듯한 메시지가 담여있다. 특히 꾸미지 않은 쌩얼과 평소에는 잘 쓰지 않는 두툼한 안경을 쓴 모습이 일품이다. 이 영상만 봐도 영회가 얼마나 따듯한 마음씨를 가졌는지 알 수 있을 것이다.

하지만 겸손한 영회는 자신의 선행이 알려지는 것을 극도로 꺼려해서 그 동안 이 영상을 공개적으로 공유할 수 없었다. 하지만 아쉬움은 이제 그만. 가끔 영회가 술 마시고 들어와서 생각없이 블로그 글을 남겼다가 욕을 먹었던 일이나, N모씨에 의해서 한국의 3대 돌팔이라고 비난당해왔던 일 등을 생각하면 이쯤에서 잘못 알려진 이미지를 회복하는 것이 좋겠다고 생각된다. 그래서 쑥스러워 하는 영회의 만류에도 불구하고 그 영상을 내 블로그에 처음으로 공개한다. 이런 영상은 포털 메인에 올라가야 마땅한 건데… 다들 각자 블로그에 퍼가도 좋겠다.

[영상은 생략]

영회의 명예회복을 시켜줬으니 다시 내 책 얘기로 돌아가자.

김희정 부사장님을 만나서 3.0으로 책을 내도 좋다는 허락을 받은 뒤 스프링원 아메리카 2008의 참석을 위해서 영회, 케누형, 기선이 등과 함께 미국으로 향했다. 나는 스프링소스의 컨퍼런스에 네번째로 참석하는 것이었다. 첫 번째 참석과 비교해 보면 한국, 중국, 일본 등지에서 온 아시아 개발자들의 참여가 늘었다는 것이 가장 인상적이었다. 2006년에는 아시아에서 참석한 사람은 나와 일본 NTT시스템즈에서 온 이시모로가 전부였는데 불과 2년 만에 D사와 S사에서 온 여러 명의 개발자들, 그리고 개인비용을 들여서 온 영회나 광남이 형 등을 포함해서 10명이 넘는 한국인들이 참여한 것을 보니 그동안 한국에서 스프링의 인기와 위상이 얼마나 높여졌는지 실감할 수 있었다.

컨퍼런스를 마치고 알라바마의 고객사에 일주일 방문해서 시스템을 점검해주고 다시 호주로 돌아왔다. 그리고 컨퍼런스에 맞춰서 공개된 스프링 3.0의 첫 번째 릴리스인 3.0 M1을 이용해서 1장의 내용을 열심히 마무리해나갔다. 기존에 JavaConfig이라는 이름으로 2년여간 질질 끌어오던 프로젝트가 스프링 3.0에서 코어 프레임워크로 통합되었다. 자바 코드를 이용한 설정 메타정보를 작성하는 기법은 내가 1장에서 추구해온 자바 코드에 의한 평범한 DI를 스프링을 이용한 프레임워크 기반의 DI로 옮기는 데 아주 좋은 연결고리가 되어주었다. 1장의 포인트는 바로 그것을 이해하는 데 있다.

1장을 끝내고 나니 자신감이 붙었다. 일단 코드를 손에 쥐니 그것을 이리 저리 만져가면서 그 과정을 옆자리에 있는 후배에게 설명하듯이 얘기를 풀어나갈 수 있었다. 보통 기술을 설명할 때 나는 먼저 간단한 그림을 종이에 그려가면서 코드의 구조와 동작하는 순서를 설명하는 습관이 있는데, 그런 내용이 필요하다 싶을 때마다 꼬박꼬박 다이어그램을 그렸다. 처음엔 UML 툴 같은 모델링 툴을 사용할까 했는데, 나중에 이미지로 옮겨와 붙이는 것도 귀찮고, 내가 자유롭게 그림을 그리고 싶을 때 불편할 듯 싶어서 손이 많이 가고 시간은 더 들지만 워드의 그림툴을 사용해서 모든 다이어그램을 만들었다.

1장은 그 뒤로 가장 많이 다시 손을 봤지만 지금까지도 제일 아쉬움이 남는 장이다. 가장 중요하지만, 가장 쉽게 써야 했고, 가장 많은 용어가 갑자기 튀어나와서 이를 수습해야 했고, 가장 많은 코드의 변화가 있는 장이다. 사실 1장은 스프링을 통해서 만들어지는 코드가 어떤 것이라는 기본을 소개하는 장이고, 2장부터 7장까지는 1장에서 소개한 내용을 다시 다양한 엔터프라이즈 기술 영역에서 응용하는 방법을 보여주는 것이다. 사실 그게 스프링의 전부이고, 그것만 잘 알면 스프링의 기술을 빠르고 쉽게 이해할 수 있다. 그래서 가장 많은 정성을 쏟기도 했고, 가장 많이 뜯어고쳐야 했다.

2장은 1장에서 main() 메소드로 만들었던 원시적인 테스트를 JUnit을 이용해서 전환하면서 자동화된 테스트의 필요성을 설명하고 테스트 코드를 작성하는데 필요한 기초적인 지식을 다루었다. 2장은 1장에 비해선 부담없이 쓸 수 있었다. 2장까지 모두 마무리하고 나니 2009년도 절반 가까이 흘렀다.

먹고 살아야 하니 그 사이 크고 작은 일도 맡아서 해야 했다. 그래서 예상했던 것보다 시간이 많이 소요됐다. 그래도 급하게 다음 장으로 넘어가지 않고 책을 쓰는 기본 틀을 다지는 데 많은 시간을 들이는 것이 낫다고 생각했다. 이야기를 풀어나가고 그에 맞게 코드와 다이어그램 등을 넣는 방법에 익숙해지고 나니 그다음 부터는 속도가 빨라졌다. 3장은 1장의 2/3쯤 되는 적지 않은 분량인데도 단 8일만에 완료했다. 정말 흐름을 타고 술술 써내려져가는 느낌을 받았다. 상대적으로 양이 적은 4장은 단 4일만에 끝냈다. 마틴 파울러와 로드 존슨이 트위터에서 책을 쓰다가 어느 순간 흐름을 타는 것을 느낄 때가 있다고 얘기한 적이 있는데 그때가 바로 그런 느낌이었다. 5장도 적지 않은 분량임에도 11일만에 끝냈다. 6장은 1부에서 가장 양이 많은 장이고 가장 난이도가 높다. 지금까지 누구도 하지 않았던 새로운 방법으로 난해한 AOP를 설명하려고 노력했다. 그러다 보니 등장한 코드(리스트) 갯수만 100개이고 다이어그램도 25개나 됐다. 보통 코드를 만들고 다듬는 시간이 절반, 그리고 그 코드를 다시 처음부터 풀어가면서 글로 남기는 시간이 절반 정도 들었다. 6장에 사용할 코드를 만들고 다듬은 후에 그 내용을 써내려갈 때는 정말 쏟아져 나오는 생각과 말을 정신없이 타이핑한다는 느낌이 들 정도였다. 그렇게 150페이지 분량의 내용을 준비하고 작성 완료하는데 한달이 채 걸리지 않았다.

그러는 사이 사촌동생의 소개로 작지만 매우 급한 개발 프로젝트 하나를 맡게 됐다. 그 프로젝트를 진행하는 한달 가까이는 책에 손을 대지 못했다. 그런데 프로젝트를 하느라 종일 코딩과 테스트에 매달려야 했지만 그 사이 내 머리 속에선 그 다음에 풀어갈 내용들이 계속 흘러다녔다. 완전히 흐름을 탄 느낌이었다.

그 사이 평화는 처음으로 어린이집에 다니게 되었고, 아내는 호주를 떠나면서 중단했던 대학원을 마저 다니기로 했다. 아내가 학교를 가는 날은 평화를 돌보고 어린이집에 데려다 주고 오고, 돌보는 일이 모두 내 책임이었다. 어린이집을 가지 않는 날은 온 종일 집에 있는 평화를 상대해야 했다. 가장 힘든 일은 밥을 먹이는 것과 낮잠을 재우는 것. 평화는 먹는데 취미가 없다. 게다가 입맛이 까다로워서 주는 대로 먹지 않는다. 보통 2-3가지 음식을 준비해서 시도해야 겨우 한가지 먹을까 말까. 음식을 들이밀어도 아예 입도 대지 않으려는 때가 더 많았다. 평화를 키우면서 들어가는 수고의 70%쯤은 밥을 먹이는데 들어갔다. 까다로운 입맛에 맞춰서 음식을 준비해야 하고, 한번 시도해서 안되면 다시 다른 음식을 준비해야 했다. 아무거나 주면 잘 먹고 자기가 먼저 밥 달라고 한다는 애들 얘기를 들으면 그렇게 부러울 수가 없었다. 물론 평화가 더 어렸을 때는 주는 대로 잘 받아먹었고, 우리도 음식을 골고루 먹이려고 제법 많은 노력을 들였다. 인스턴스나 미리 준비된 음식은 거의 먹이지 않고 다양한 재료를 골고루 먹게 하려고 노력했다. 하지만 입맛 까다로운 나를 닮은 평화는 자기가 음식을 거부할 수 있음을 알게되면서부터는 쉽게 입을 열지 않았다. 게다가 자기 그릇에 놓인 음식이 맘에 안드는데 자꾸 먹으라고 채근하면 짜증이나서 음식이나 그릇을 던져버리는 일도 있었다. 그때마다 혼을 내고 타일러봐도 별 소용이 없었다. 그렇게 하루 하루가 전쟁이었다. 잠을 재우는 것도 쉽지 않았다. 낮잠을 제대로 못자면 저녁 때 힘들어하고 짜증을 많이 내기 때문에 낮잠을 꼭 재워야 하는데, 이게 타이밍을 놓치면 쉽지 않다. 정 안되면 차를 태우고 한 바퀴 돌면서 재우기도 했는데 어떨 때는 한 시간 넘게 운전을 해도 잠이 들지 안을 때도 있었다.

아내가 학교 가는 날은 그렇게 평화랑 종일 씨름하다가 조금씩 틈이 날 때 잽싸게 책을 쓰거나 일을 해야 했다. 어떨 땐 짜증을 참지 못하고 한바탕 혼을 낸 뒤에 펑펑 우는 평화를 붙잡고 달래며 시간을 보내야 했다. 태어나서 처음으로 엄마랑 떨어져 지내는 시간이 쉽지 않았을 텐데, 게다가 어린이집이라고 일주일에 이틀씩 보내는 곳은 집에서 듣던 것과 전혀 다른 언어로 이야기 하는 선생님과 친구들 뿐. 이런 저런 스트레스가 대단했을 텐데 그것을 다 받아주지 못하고 종종 화를 냈던 것이 지금도 미안하다.

책을 쓰면서 가장 힘들었던 순간은 평화가 방문을 열고 와서 자기와 놀아달라고 내 손을 잡아 끄는데 그것을 거절해야 했을 때다. 어떨 땐 방문을 잠궈보기도 했는데, 그러면 방문 앞에서 문을 두드리면서 ‘아빠’라고 수십번씩 목놓아 부르기도 한다. 아빠가 필요한데 자기랑 놀아주지 않고 손을 밀어내며 키보드만 두드리는 아빠가 얼마나 원망스러웠을까.

아무튼 그렇게 쉽지 않은 환경에서 꾸역꾸역 원고를 채워나가던 중에 한국을 다시 방문할 기회가 생겼다. 이번엔 일이나 컨퍼런스 때문이 아니라 장인어른 팔순 잔치 때문이었다. 사실 잔치는 장인께서 원치 않아서 따로 하지는 않았지만, 팔순인 만큼 온 가족이 다 모이기를 강력히 희망하셔서 미국에 사는 큰 처형과 호주에 있는 우리 가족을 포함해서 온 가족이 모이는 시간을 가졌다.

오늘은 오랜만에 비가 와서 그런지 날씨도 꿀꿀하고 기분도 왠지 울적해서 글도 잘 안써진다. 오늘 얘기는 여기서 대충 줄이고 내일 다시 더 써야겠다. 그래도 이제 끝이 보인다.

토비의 스프링 3이 나오기까지 (9)

책을 쓰는 동안 가장 힘든 것이 무엇이었냐고 누가 물어온다면 수많은 일들이 머리에 떠오르겠지만, 그 중에서 가장 대표적인 두 가지만를 꼽자면 내가 쓰려고 하는 내용이 공격 받는 것을 발견하는 것과 끊임없이 발생하는 호기심을 억눌러야 하는 것 두가지를 들고 싶다.

책이 나오고 책의 내용이 공격 받는 것은 차라리 나을 것 같다. 이미 출간되서 독자 손에 들어갔으니 뭐 어쩌겠는가. 자기들끼리 지지든 볶든 상관할 바도 아니고, 상관해봤자 온라인으로 출판된 글과 달리 인쇄된 책의 내용을 고칠 수도 없으니 차라리 마음이 편할지도 모르겠다는 생각을 했다. 물론 속은 많이 상하겠지만.

사실 책의 내용에 대한 공격은 원고가 내 손을 떠나기 전에 이미 시작된다. 책을 쓰는 내내 저자 머리 속에서 치열한 전쟁이 벌어지기 때문이다. 내가 쓴 글을 다시 읽을 때마다 과연 이 얘기가 정말 맞는 것일까 혹은 잘못 설명한 것은 아닐까 하는 의심이 끊임없이 들었다. 책을 쓰기 전에는 분명한 확신을 가지고 어디서든 당당하게 얘기했던 내용조차도 책의 원고에 넣고 나면 갑자기 수상하게 보였다. 그래서 관련된 책을 찾아보고 인터넷을 뒤지면서 내가 설명하는 내용이 타당한지 검토하고 또 검토했다. 물론 논쟁거리에 속하는 그런 주제는 어쩔 수 없다. 그건 내가 어느 한편을 지지하든지 아니면 적절한 선에서 양다리를 걸치든지 하는 수밖에. 대신 독자들이 최종 판단을 내릴 수 있도록 충분한 근거들을 나열해주는데 신경을 썼다. 때로는 한 문단의 내용을 뒷받침 해주는 근거를 뽑아내기 위해 책 한권을 통채로 읽은 적도 있다.

내 스스로 확신이 없는 않는 내용은 책에 넣지 말자는 생각이었다. 물론 내 확신이 틀린 수도 있지만 그거야 어쩔 수 없고. 그동안 다른 책을 읽으면서 잘못된 주장이나 왜곡된 사실이 얼마나 많이 책에 들어가는지 놀랄 때가 많았다. 저자가 지지하는 기술을 위해서 경쟁관계에 있는 기술을 폄하하는 모습을 보면 짜증도 났다. 특히 스프링은 그런 공격을 가장 많이 받은 기술이다. 희한하게도 스프링은 사람들의 심기를 건드리는 뭔가가 있는 듯 하다. 자신이 지지하는 개발철학이나 기술을 절대적으로 신봉하는 사람은 그래서 스프링이 불편하다. 물론 나중에 스프링이 대세다 싶으면 자신이 비난했던 일은 쏙 감추고 스프링 전문가 행세를 하고 다니기도 하지만.

저자의 성의가 부족해서 잘못된 사실이나 설명을 책에 남기는 것은 어떻게든 피하고 싶었다. 그래서 스프링 기술에 대한 설명은 문서만 참고해서 작성하지 않고 일일이 학습테스트를 만들어서 내 눈으로 동작하는 것을 직접 확인하려고 노력했다. 2부 예제인 Part2 프로젝트의 학습 테스트 코드는 그렇게 만들었던 테스트의 일부를 독자들도 참고해보라고 넣은 것이다.

문제는 1부였다. 코드야 거의 TDD에 준하는 테스트를 계속 작성해가면서 만들었으니 기능적으로는 문제가 없을 것이다. 하지만 스프링의 프로그래밍 모델과 개발철학을 이해하는데 도움이 될 것이라고 생각해서 동원했던 다양한 이론과 원칙, 패턴들에 대해서는 간단히 검증할 수 있는 것이 아니라서 고민을 많이 했다. 처음엔 애자일 개발 이론을 동원해서 스프링의 특징을 설명하려고도 노력했는데, 애자일은 너무 방대하고 내가 도저히 감당할 수 있는 주제가 아니라고 판단되서 그 내용은 모두 제거했다. 대신 가장 단순하고 명확한 한 가지 이론을 꺼내서 그것에 대한 이론적인 설명대신 그 이론이 코드에 적용되서 코드가 발전하는 모습을 보여주려고 노력했다. 이론이 눈에 보이는 코드에 적용되서 더 나은 코드가 되는 모습을 보여주고 싶었다. 반대로 그런 코드의 개선 이유를 설명할 수 있는 용어와 이론을 알려주고 싶었다. 그리고 그렇게 개선된 코드가 바로 스프링의 핵심 기술이고 스프링이 개발자들에게 권장하는 코드라는 것을 보여주기 바랬다. 그래서 선정한 가장 간단하고 명료한 개발 이론이 바로 관심사의 분리(SoC)였다. SoC도 깊이 들어가면 복잡하고 방대한 주제긴 하지만, 그냥 그 용어의 표면적인 의미만 가지고도 충분히 내가 원하는 설명을 이끌어낼 수 있을 것이라고 기대했다. OO원칙이니 패턴이니 하는 얘기를 너무 자주 들먹이면서 설명을 하면, 그런 이론을 좋아하는 사람들은 만족할지 모르겠지만 그렇지 않은 개발자들은 오히려 피로를 느낄 수 있기 때문이었다. 그래서 가장 단순한 "관심이 다른 코드는 분리하는 것이 좋다"는 명제 하나를 가지고 코드를 살펴보는 것으로 스프링의 모든 개발철학과 핵심기술을 설명하려고 시도했다.

스프링의 DI는 기본적으로 SoC를 바탕으로 한다. DI는 의존관계에 대한 것인데, 의존관계가 성립하려면 적어도 두 개의 구분된 존재(오브젝트)가 필요하다. 그래야 한 쪽이 다른 한 쪽을 의존할 수 있고, 그래야 DI도 성립하니까. 그래서 DI의 기본 전제는 분리다. 사람들이 스프링을 왜 제대로 사용하지 못할까를 고민하면서 내가 내린 결론은 겨우 3계층으로 구분하고 나면 더 이상 분리를 할 줄 모르기 때문에, DI할 필요를 찾지 못하기 때문이라는 것이다. 성격이 다른 코드를 하나의 클래스와 메소드에 마구 우겨 넣어놓았으니 무슨 DI가 가능하겠나. 가장 원시적인 DI가 적용된 템플릿/콜백도 의미있는 분리가 기본 전제다. 그렇게 따져보면 스프링의 모든 기술은 다 적절한 관심사(책임, 변경조건, 성격.. 뭐라고 해도 좋다)에 따라 코드를 분리하는 데서 시작된다. SoC라는 용어가 소프트웨어 개발의 가장 근간이 되는 기본적인 원칙으로 자리를 잡게 된 것도 비슷한 맥락이라고 봤다.

내 책을 본 사람들은 알겠지만 1장의 앞부분에서부터 이 SoC가 등장한다. 사실 SoC라는 용어가 중요한 것은 아니니 그 뒤로는 그냥 "관심(책임, 변하는 성격)이 다른 것이 같이 있네? 분리해 보고 어떻게 되나 살펴보자"라는 식의 설명으로 바꾸긴 했지만, 이 원칙을 1부 내내, 7장까지 끊임없이 반복해서 적용한다. 그러면 스프링 다운 코드가 되고 스프링 자신이 된다. 짜잔. 이제 1부의 내용이다. 거창한 객체지향이니 원칙, 패턴 같은 것도 따져보면 여기서 부터 출발하는 것이라고 생각했고, 그런 패턴의 기계적인 적용에 앞서서 먼저 적절하게 분리되야 할 코드를 살피는 것(물론 응집도를 높이기 위해서 분리한 것을 다시 유연한 방식으로 결합하는 주제도 나오지만)에만 충실해도 도움이 될 것이라고 생각했다.

그리고 1부의 마지막인 8장에서는 스프링이 이 적절한 분리(SoC)를 통해서 엔터프라이즈 개발의 복잡함을 효과적으로 다룰 수 있게 해준다는 결론을 내렸다.

그런데 어느날 우연히 "SoC가 가져오는 복잡성을 극복하는 방법"이라는 글을 봤다. 글의 취지나 내용은 대충 이해하지만 이 제목과 SoC, 복잡함이라는 단어를 사용하는 방식에는 동의할 수 없었다. 그런 자극적인 문구를 보니 갑자기 내가 썼던 글들이 온통 부정당하는 느낌이 들었다. 지금까지 SoC가 어떻게 복잡함을 극복하는지에 대한 이야기를 풀어나가고 있었는데 SoC가 복잡성을 가져온다니! 그 글에선 SoC라는 단어를 극히 협소하고 제한된 의미로 사용하고 있다고 생각됐다. 게다가 복잡함에 대한 설명도 받아들이기 힘들었다. 글의 취지는 이해하지만 그래도 마음이 불편하고 신경 쓰였다.

그래서 블로그에 가볍게 반박하는 글을 썼다. 글 전체에 대한 반박이라기 보다는 복잡함과 SoC라는 단어 사용에 대한 반론이었다. 글을 썼던 S님도 내 블로그를 찾아와 "의견 고맙다"는 답글도 달아줬다.

나오지도 않은 책의 내용을 반박당하는 듯해서 찝찝했던 기분은 다시 좋아졌고 다시 내 주장을 계속 펼쳐나가면 되겠다고 생각했다. 그런데 그 때 사고가 터졌다. 블로그계의 악동 영회였다. SoC에 관한 글에서 복잡함이라는 주제에 대한 내용은 내가 충분히 반박할 수 있다고 생각했지만, 글의 결론으로 나오는 UML모델링 툴의 사용이 해결책이다라는 내용은 내가 그 툴을 거의 써본 적이 없고 모델링 툴을 통한 접근방법에 대해서는 별 관심도 없었기에 내가 다룰 내용이 아니라고 생각했다. 대신 평소에 모델링툴 만능주의자들을 끊임없이 비난해왔던 CBD 모델링 컨설턴트 출신의 영회가 생각났다. 게다가 언급된 툴은 마침 영회가 잘 안다고 하던, 그래서 블로그에 소개도 자주 하던 것이었다. 그래서 마침 메신저에 들어온 영회에게 그 글을 보여주면서 의견을 물었다. 영회도 그 내용이 불만이었다. 그래서 자기도 글을 하나 쓰겠다고 했다.

그런데 웬걸 다음날 아침에 난리가 났다. 영회가 또 사고를 쳤다는 얘기가 들려왔다. 영회 블로그를 급히 가보니 S님의 글을 링크해놓고 "아직 경험이 없고 어려서 뭘 모른다"거나 "닷넷 개발자들은 수준이 낮다"는 식의 자극적인 얘기가 적혀있었다. 모델링 툴에 대한 그 글의 해법에 대해서 의견을 써보라고 했더니 그런 얘기는 없고 인신공격으로 보일 수 있는 글을 적어놨다.

그때문에 한동안 시끄러웠다. 사실 영회 글의 파급력이 엄청났기 때문에 내 글은 묻혔다. 게다가 S님은 내가 영회랑 짜고 자기를 공격했다는 식으로 나를 비난하기 시작했다. 억울했다. 해명을 하려고 메신저로 연결해서 이야기를 나눴지만, 영회의 공격에 감정이 많이 상한터라 반응이 안좋았다. 공격의 화살은 오히려 내게로 돌아왔다. 내가 영회한테 시켜서 그런 글을 쓰게했다는 식의 얘기가 떠돌았다. 영회가 그렇게 오해하기 딱 좋은 댓글("형이 시켰자나")을 써놨기 때문이다. 영회한테 글을 알려주고 글을 써보라고 했지만 그게 자신의 평소 주장을 이용해서 글의 내용을 반박을 하라는 거였지, 닷넷 개발자를 깔아뭉개거나 엄마젖 더 먹고와라는 식의 글을 쓰라는 것은 아니었는데 내가 그런 악의적인 글을 쓰도록 뒤에서 조종한 사람 취급하는게 억울했다.

영회도 막상 일이 커지니 당황해서 글을 수정하고 지우고 자극적인 문구에 대해 사과하는 등 수습하느라 바빴다.

피곤한 경험이었다. 물론 나중에 S님을 잘 달래서 오해는 풀어줬고 좋은 사이가 될 수 있었지만 서로에게 조금씩 상처를 남긴 유쾌하지 않은 기억이다. S님 기분을 풀어주기 위해서 N모씨가 쓴 영회에 대한 인신공격/비방 글을 모두 찾아서 보여주기도 했다. 그리고 인터넷에 글을 남기고 활동하는 것은 언제든 이런 공격을 받을 수 있다는 것, 그리고 그런 위험을 감수할 수 밖에 없다는 것에 대해서 설명했다. 나도 "xxx에 경험도 없는 놈이~"라는 식의 인신공격을 받아본 적이 있기 때문에 그 심정을 대충 이해한다. 인신공격을 이용해서 자기 주장을 내세우는 것은 치사하지만 상당히 효과적이다. 그래서 더 나쁘다. 상대방의 발언 내용에 대해서 논리를 가지고 반박하는게 아니라, "너는 경력이 얼마 안되자나. 그러니까 네 주장은 틀렸다"는 식으로 몰고가는 것이다.

책의 내용이 공격받는 듯한 느낌이 들어서 시작하긴 했지만 순수하게 글의 내용만 가지고 토론했다면 감정 상하지 않고 적절하게 마무리할 수 있는 일이었는데 하는 아쉬움이 남는다. 스프링 포럼에서 기술적인 토론이 벌어지면 상당히 강한 공격과 반박이 오고 간다. 하지만 그 토론의 내용는 모두 객관적이고 기술적인 것이고, 개인적인 공격이나 그런 공격을 이용한 치사한 주장 같은 것은 찾아보기 힘들다. 그래서 격렬한 토론이 오고 간 뒤에도 기분 좋게 끝낼 수 있고, 또 그러는 사이에 많은 것을 배울 수도 있다. 하지만 한번 인격을 공격하기 시작하고 그것을 자기 주장의 근거로 삼으려는 시도를 하고 나면 지저분해질 수 밖에 없다. 사실 그런 유혹은 항상 있고, 사적인 대화나 술자리에서는 그런 얘기가 쉽게 오고가기도 한다. 하지만 공개된 블로그 등에서 그런 얘기를 하는 것은 차원이 다르다. 누군가는 크게 기분을 상하고 의욕을 잃을 수도 있다. 영회만 그런 실수를 하는 것은 아니다. 세계적으로 유명한 개발자나 IT계 종사자들 사이에서도 그런 일이 종종 발생한다. 얼마전에는 유명 블로거인 조엘이 밥 마틴과 켄트 벡을 영회와 비슷한 방식으로 비꼬았던 일이 있었다. 나중에 공개적으로 자신의 그런 발언에 대해 사과를 하기는 했지만, 그러는 사이에 밥 마틴은 물론이고 평소엔 잘 흥분하지 않는 켄트 벡까지도 감정이 실린 글을 썼고 댓글을 통해서 심한 이야기들이 오고가는 것을 봐야 했다. 개빈 킹은 예전에 화가나면 문장이 F로 시작하는 글을 남기기도 했다. 그래서는 건전한 기술 토론이 이어질 수가 없다.

아무튼, 그런 일로 또 몇 날을 진도도 제대로 못나가고 신경만 잔뜩 쓰면서 보내야 했다. 좋지 않은 경험을 하고 나니, 그 뒤로 책의 내용과 관련된 글이나 스프링을 공격하는 글을 봐도 그냥 무시하고 넘어가거나 아니면 혼자서 투덜대고 말아야 했다.

어쨌든, 책을 쓰는 동안 저자의 머리 속에서는 보이지 않는 치열한 전쟁이 일어나는 것 같다.

두 번째는 책의 주제에만 장시간 집중해야 하니 다른 기술에 호기심이 일어나도 자제해야 했던 것이다. 나는 오랫동안 프로그래밍을 취미로 해왔다. 새로운 것을 좋아하고 무엇인가 창조적인 일을 하는 것에 관심이 많은 나에게 끊임없이 새로운 기술이 쏟아져 나오고 원하는 대로 만들고 실행하고 남들이 사용하는 것을 지켜볼 수 있는 프로그래밍은 최고의 취미였다. 우연한 기회에 아르바이트로 일을 시작했다가 현장에서 일을 해야지만 만질 수 있는 대형 시스템의 매력에 빠져서 아예 직업으로 선택하게 되었지만. 일을 하는 중에 어떤 일을 할지 선택할 수 있는 기회가 주어지면 나는 항상 내가 해보지 않은 새로운 기술과 언어, 환경, 도메인에 우선순위를 두었다. 끊임없이 내 호기심을 자극해줄 수 있는 일을 찾았다. 그래서 프로젝트를 마칠 때면 고객사로부터 특채로 뽑아줄테니 직원으로 들어와서 일을 하라는 제안을 받았지만, 한 회사에서 한 가지 시스템을 몇 년씩 만져야 하는 일은 정말 지루해 보여서 도저히 받아들일 수 없었다.

그런 내가 스프링, 그것도 스프링의 기초와 핵심 기술 몇 가지에 매달려서 연구하고, 그것을 이리 저리 풀어서 설명하는 책을 쓰는 일에만 2년 가까이 집중해야 했던 것은 정말이지 고문이었다. 물론 책을 쓰면서 시간을 따로 떼서 다른 기술을 공부할 수도 있었지만, 계속 해서 밀리는 일정과 그에 따른 부담이 커지면서 책의 내용 외에 관심을 두는 것은 왠지 외도하는 느낌이 드는 데다 출판사에 미안한 마음 때문에라도 자제할 수 밖에 없었다. 블로그 글도 책에 넣으려고 공부핬는 스프링 3.0에 대한 이야기나 써야 했고. 다른 기술이나 책 내용 이외의 스프링 고급 기술에 대해선 깊이 파고 들어갈 마음의 여유를 가질 수 없다.

그런데 1,2장이 끝나고 슬슬 책을 쓰는 데 가속도가 붙기 시작하게 되니 마음에 빈틈이 생겼을까 자꾸 다른 재밌어 보이는 다른 기술에 눈이 가기 시작했다. 그래도 본격적으로 손을 대지는 못하고 있었는데, 어느날 한 출판사에서 연락이 왔다. "XXX 기술에 관한 책이 있는데 한번 번역하지 않으시겠어요?"라는 내용이었다. 내가 블로그에 그 기술에 대한 글을 몇 번 적은 적이 있는데 그것을 보고 내가 관심이 있어하지 않을까 해서 연락을 한 듯 했다. 갑자기 유혹이 몰려오기 시작했다.

일단 스프링 3.0에 맞춰서 책을 내기로 허락을 받았으니 마음에 여유가 조금 있었다. 게다가 3장 이후로는 엄청난 속도로 책이 써지는 것을 보면서 이 대로라면 3.0이 출시될 때 맞춰서 여유있게 책을 마무리 할 수 있을 것 같았다. 게다가 하루 종일, 일주일 내내 스프링 생각만 하면서 지내는게 너무나 지겨웠다. 뭔가 기분을 전환하고 다른 주제로 관심을 돌리는 시간이 필요할 듯 싶었다. 그래서 일단 긍정적인 답변을 했다.

그리고 나서 걱정이 됐다. 계약한지 2년이 넘도록 책도 마무리 못하고 있는 불량 저자 주제에 다른 책을 번역하는 것은 무책임한 짓이 아닌가 하는 생각이 들었다. 하지만 한편으로는 책을 쓰는 동안에는 다른 일을 안하겠다고 한 것도 아니고, 게다가 이미 스프링 3.0 출시에 맞춰서 책을 내기로 했으니 그 약속만 지킨다면 다른 일을 하든 책을 번역하든 괜찮지 않을까 하는 생각도 들었다. 한편으로는 포기할까 생각했지만, 그래도 자꾸 그 기술이 눈에 들어왔다. 사실 번역은 내 관심사가 아니다. 하지만 책을 번역하면 내가 관심이 있는 기술을 꼼꼼히 공부할 기회가 주어질 것 같아서 맘이 자꾸 끌렸다.

그래도 일단 김 부사장님께 말씀을 드리고 허락을 받는 것이 예의라고 생각을 했다. 그래서 연락을 해서 어렵사리 말을 꺼냈다. "번역 제의가 들어왔는데요. 제가 관심이 많은 주제라… 혹시 해도 될지.." 말이 미처 끝나기도 전에 대답이 돌아왔다. "절대 안돼요". 한마디라도 더 했다간 지난 2년간 제대로 책도 안쓰고 질질 끌던 것까지 함께해서 콤보로 혼날 것 같았다. "네".

책을 빨리 안 쓴 내가 잘못이지. 결국 그 출판사에는 개인 사정으로 번역은 못하겠다고 얘기했다. 그리고 더 열심히 더 빨리 스프링 책을 마무리 해야 겠다고 결심했다. 그 뒤로 무서운 속도로 책을 써나가기 시작했다. 그리고 1부의 내용이 제법 마무리 되가던 가을에 한국을 방문하게 됐다. 2부는 별로 걱정이 안됐다. 2부는 레퍼런스 식으로 각 기술의 사용방법과 기술선택에 관한 내용을 적으면 되기 때문에 별로 고민할게 없었다. 그동안 준비해놨던 방대한 양의 학습테스트 코드와 스프링의 깔끔한 API 문서, 레퍼런스 문서 등을 참고하면 1부보다 3배는 빠르게 쓸 자신이 있었다. 그러니 1부의 내용이 어느 정도 정리가 되가자 슬슬 눈을 딴데 돌리기 시작했다.

장인어른 팔순 때문에 평화와 아내와 함께 한국을 방문하기로 하고 준비하고 있던 어느날 또 다른 출판사에서 연락이 왔다. 역시 번역제안이었다. 기존에 내가 하고 싶었던 기술과 갈은 것이지만 다른 책이었다. 처음 제안받은 책은 바이블 성격의 두툼한 책이지만 두 번째 제안받은 책은 양도 작고 내용도 가벼운 입문자용 책이었다. 문장도 쉽고 코드도 많았다. 스프링을 잠시라도 벗어나야 숨이 트일 것 같은 기분으로 살고 있었기 때문이었을까. 덜컥 하겠다고 말해버렸다. 당시 스프링 3.0은 연말이나 되야 나올 스케줄로 진행되고 있었고 책은 그 때까지 충분히 마무리할 수 있을 것 같았다. 800페이지 짜리 책을 쓰기로 했는데 이미 500페이지가 넘었고, 2부는 더 쉽게 쓸 수 있을 것이라고 생각했으니까. 어쨌든 책을 먼저 마무리 하고 번역은 슬슬 진행하다가 스프링 책 원고를 넘기고 나서 집중적으로 하면 2010년 봄 쯤에 마무리 할 수 있을 것 같았다. 하루에 5페이지 정도만 한다면 2시간 정도 시간을 내면 될 듯 했고. 그 정도라면 평소에 책을 쓰다가 머리를 식히려고 보내는 시간 정도만 할애해도 충분할 듯 싶었다.

문제는 무서운 김 부사장님께 말씀드리는 것인데. 분명 몇달전에 안된다고 하셨는데 또 하겠다고 나오면 완전 반항으로 비칠듯 싶었다. 그래서 이를 어째야 하나 계속 걱정을 하면서 지내다가 한국을 방문하게 되었다.

가족과 함께 시간을 보내고 나서 돌아가기전에 김희정 부사장님을 만나기로 약속을 잡았다. 참석 가능한 KSUG 멤버들 몇 명도 자리를 함께 하기로 했다. 장소는 교보빌딩 1층의 모 식당에서 저녁 7시.

그런데 우연이겠지만 그날 같은 장소에서 몇 시간 전에 번역을 하기로 한 책을 낼 출판사 이사님과도 만나기로 했다. 그 장소가 출판인들에게 인기있는 장소였을까. 아무튼 그날 만남은 번역 계약서를 작성하는 자리였다. 일단 저술하는 책이 있으니 당분간은 그 책에 전념을 해야겠지만, 서서히 진행하다가 스프링 책이 완료되면 빠르게 마무리 하겠다고 말씀드렸다. 그 때까지 김 부사장님과 에이콘 직원분들 외에 내가 만났던 출판사 관계자는 출판사 사장님이 전부였다. 그런데 출판사 분들은 다들 왜 그리 친절하고 이해심 많고 저자나 역자를 끔찍히 배려해주는 데다 상냥하기도 한지. 그날 만난 이사님도 정말 천사같았다. 그러니 내가 거절을 못했을지도.

번역 계약을 마친후 서점에서 조금 시간을 보내다 저녁때 김희정 부사장님과 영회, 세원님 그리고 성철이 형을 만났다. 하필이면 앉은 자리도 오후에 번역 계약을 하러 다른 출판사 분을 만났을 때 앉았던 같은 자리였다. 김 부사장님을 만나면 번역 하기로 했다는 얘기를 꺼내야겠다고 마음을 먹긴 했는데 막상만나고 나니 말이 목에 걸려서 도저히 나오지가 않았다. 그날 내가 가장 많이 한 말은 그냥 "네".

게다가 그 날은 김희정 부사장님이 내 책에 대해서 이런 저런 주문을 많이 하셨다. 책의 분량은 800페이지 정도로 하기로 이미 여러번 합의를 보았지만 1부 내용이 조금 길어지는 것을 느끼면서 그보다 조금 더 늘어날 것 같은 느낌이 들었다. 김 부사장님은 만날 때마다 책 분량에 대해서 다시 확인하신다. 맨날 까먹으시는 것인지 아니면 저자가 욕심을 내서 분량을 늘릴까바 걱정되서 그러시는 것인지는 모르겠지만. 아무튼 그날 내가 "800정도 쓰려고 하는데요.. 근데.."라고 말이 꺼냈더니, "설마 800페이지 이상 쓰실려는 것은 아니죠?"라는 날카로운 목소리의 답변이 돌아왔다. 평소의 친절하고 상냥한 목소리와 톤이 일단 다른 데다 눈꼬리가 살짝 올라갔음을 눈치채고 나능 황급히 "물론 800이에요"라고 대답할 수 밖에. 뭔가 눈치를 채셨는지 "책을 쓸 때 뭘 넣을지가 중요한게 아니라 뭘 뺄지가 중요해요"라는 설명이 다시 이어졌다. 괜한 욕심부리지 말고 얼릉 마무리 하라는 얘기로 들렸다. 까짓거 일단 써보다가 800 페이지가 넘으면 일부 내용을 빼서 PDF로 만들어 따로 공개하면 되겠지라고 생각하면서 일단 그렇게 마무리.

평소와 다르게 그날은 실제적인 저술 방법에 대한 주의사항이 이어졌다. 대부분 내가 안지키고 있던 것들이었다. –_-;;;

"혹시 각주 넣으셨어요?". 물론 넣었다. 간단한 용어 설명이나 참고 정보는 각주로 뽑았다. 왠지 있어보이니까. 하지만 넣었다고 하면 혼날 것 같았다. 뻥을 쳤다. "아..니요…". 별 다른 설명이 뒤따르지 않았던 것으로 봐서는 그래야만 했던 것 같다. 이왕이면 저술을 시작할 때 그런 주의사항이나 가이드라인을 미리 주셨으면 좋았을텐데라는 아쉬움이 있었지만, 뭐 어쩌겠는가. 다시 호주에 돌아오자마다 각주는 모두 본문에 삽입하거나 박스에 넣어서 정리했고 새롭게 받은 가이드라인에 따라서 기존에 쓴 내용을 정리하느라 다시 며칠을 보내야 했다.

아무튼 처음으로 저술 방식과 형식 등에 대해서 한참 교육을 받고 나니 긴장이 더 됐는지, 결국 그날은 번역에 대한 얘기를 꺼낼 용기를 내지 못했다. 뻔뻔한 영회 같으면 그냥 얘기하고 말았을텐데.

내일 다시 적겠지만 그때 예상은 다 틀렸다. 스프링은 그해 12월에 나왔지만 내 원고는 올해 3월에야 겨우 마무리 했고, 생각보다 긴 교정시간을 거쳐서 5월에서야 겨우 초고를 넘길 수 있었다. 번역은 상당히 재밌는 경험이었고 책을 쓰는 것에 비하면 스트레스도 훨씬 적었다. 기대했던 대로 스프링과 완전히 다른 성격의 기술을 살펴보는 것은 머리를 식히는 데 최고였다. 물론 스프링 책에 우선순위를 두기로 한 결정은 그대로 지키려고 했고. 그래서 스프링 책의 마무리가 늘어지면서 번역작업도 같이 지연되었다. 결국 번역을 마무리 하고 초고를 보낸 것은 지난 7월이었다.

물론 김희정 부사장님께는 뒤늦게 다 실토했다. 한번 혼나고. 흑.

토비의 스프링 3이 나오기까지 (11)

점점 지겨워지긴 하지만 마무리는 해야 하니까. 처음 이 글을 쓰기 시작했을 때 생각처럼 어떤 시간이었든 책을 써왔던 지난 시간을 한번 정리하고 나서 다 잊어야지. 차마 글로는 옮길 수 없는 유쾌하지 못했던 기억들이 더 많았던 지난 2년여간의 시간들. 어쨌든 정리는 하고 넘어가야 하니까.

한국에서 돌아온 뒤 거의 하루 15시간 이상 책을 쓰는 데 매달렸다. 일단 흐름을 타고 나니 1부를 마무리 하는 것은 쉬웠다. 스프링 핵심기술 소개는 6장에서 마무리했지만 거기서 만족할 수 없었다. 단지 스프링이 이렇게 OO와 DI를 비롯한 핵심가치를 자신에게 적용했다는 것을 이해하는데 만족하지 말고 그것이 스프링 사용자 자신의 코드에도 그대로 적용될 수 있기를 바랬다. 그래서 7장을 썼다. 내용은 엉성할지 모르겠지만 7장은 내가 이 책에서 가장 아끼는 장이다. 책을 통해서 내가 가장 하고 싶었던 이야기이기도 하고. 그리고 1부의 마무리로 처음 써놨던, 버리려고 했던 1장을 넣기로 했다. 물론 거의 새로 쓴 것이긴 하지만. 원래 가장 먼저 얘기하려고 했던 도대체 스프링이란 무엇인가라는 질문과 그에 대한 내 생각을 간략하게 정리했다. 1부 끝. 한국을 다녀와서 며칠 지나지 않아 1부를 마쳤다.

그리고 스프링의 기술을 주제별로 설명하는 2부 시작. 2부는 1부보다 훨씬 쉬울 것이라고 생각했다. 그저 스프링의 기술을 쭉 나열해가며 사용방법을 설명하고 평소에 생각해뒀던 선택 기준에 관한 내 의견을 넣으면 될 테니까. IoC/DI를 다루는 10장에서 이미 600페이지가 훌쩍 넘었다. 800페이지가 목표니까 이제 얼마 안남았다고 생각했다. 미리 준비해뒀던 학습 테스트 코드도 많은 도움이 됐다. 그리고 스프링 3.0도 RC버전이 출시되고 최종 릴리스가 눈 앞에 보였다.

이제 끝인가 보다 생각하면서 12월이 시작됐다. 그리고 처음으로 용기를 내서 김희정 부사장님께 먼저 연락을 했다. 늦어도 12월 말까지는 초고를 드릴 수 있을 것 같다고 말씀드렸다. 스프링은 예상과 달리 계속 지연되서 12월 중순에나 나오게 됐고 약속대로 스프링 출시에 맞춰서 책이 나올 수 있을 것 같다고 얘기했다. 물론 스프링이 늦게 나올 것이란 건 충분히 예측했던 일이었으니 다르긴 뭐가 달라. –_-; 죄송하니까 말이라도 그렇게 했어야지.

아내도 11월 말에 학기를 마쳤고 집안일을 전담할 수 있게 됐다. 나는 그저 12월 무더위와 싸우면서 미친듯이 마무리 해나가면 될 것 같았다. 하지만 예상치 못했던 일이 생겼다. 아내가 임신을 한 것이다.

결혼 후 거의 7년만에 평화를 가질 때는 병원의 도움을 받아야 했다. 쉽게 아이가 생기는 체질이 아니라고 했다. 아내는 계속 둘째를 원했다. 혼자는 외로우니까 친구처럼 지낼 형제가 있어야 한다고. 나도 둘째가 있으면 좋겠다고 생각은 했다. 하지만 쉽게 생길 것이라고 기대를 하지는 않았다. 아마 또 병원에 다녀야 하지 않을까 싶었다. 그런데 어느날 갑자기 둘째가 생겼다.

병원에 가보니 5주라고 했다. 한편으로 기뻤지만 다른 한편으로는 걱정이 시작됐다. 평화를 가졌을 때 지독하게 심한 입덧을 했던 것이 기억났다. 입덧이 없거나 가볍게 지나는 사람도 있지만 지독하게 심한 입덧을 경험하는 사람도 있다. 오죽 심하면 출산 때의 고통 때문이 아니라 입덧 때문에 아이를 가지는 것이 두렵다는 얘기를 할 정도다. 아내가 딱 그랬다.

입덧이 서서히 심해지면서 중병을 앓는 사람처럼 누워있어야만 있어야 했다. 물 조차도 마시기 힘들어 했다. 겨우 물 한모금을 마셔놓고 그보다 훨씬 더 많이 토하기도 했다. 평화를 가졌을 때 입덧하면서 자주 먹었던 누릉지를 만들어서 끓여주었지만 그것도 거의 입에 대기 힘들어했다. 평화 때보다 훨씬 빨리 입덧이 시작됐고 훨씬 더 심하게, 오래 진행됐다. 원래 둘째는 입덧이 덜하다는 얘기도 있는데 다 뻥이다. 평화 때처럼 친정에 가있을 수도 없었다. 그렇다고 누군가 와서 도와줄 사람도 없었다. 하루 종일 침대에 누워서 괴로워하다가 물 몇 모금, 묽게 만든 누릉지 조금 먹고 그리고 수시로 토하고. 냄새 때문에 방 밖으로 나오기도 힘들었다. 평화랑 놀아주는 것도 물론 불가능했다. 갑자기 모든 집안 일과 평화를 돌보는 것이 내 책임이 됐다. 겨우 짬을 내서 회사 일에 시간을 쓰고 나면 원고를 쓸 시간이 없었다.

아침에 일어나면 평화를 어린이집에 보낼 준비부터 해야 했다. 평화 점심 도시락을 만들고 간식과 준비물을 챙기고 평화를 깨워서 씻기고 아침을 먹이고 어린이집에 데려다 주고 왔다. 돌아오면 집안 청소와 설거지, 세탁을 하고 아내 상태에 따라서 먹을 음식을 준비해야 했다. 평화를 가졌을 때는 다른 음식에는 전혀 손을 대지 못했지만 누릉지 끓인 것은 겨우 겨우 먹었던 기억이 났다. 한국에서처럼 누릉지를 쉽게 구할 수 없으니 내가 직접 만들어야 했다. 밥을 후라이팬에 얇게 깔고 가장 약한 불에 1-2시간 두면 그럴싸한 누릉지가 만들어진다. 입덧이 심하면 맹물도 제대로 못삼킨다. 억지로 마셨다가 토하면 오히려 수분이 더 빠져나가서 좋지 않다. 그래서 누릉지를 끓어서 먹이려고 노력했다. 그것도 며칠 가지 못했다. 아예 하루 종일 물 몇 모금 말고는 아무것도 먹지 못하기 시작했다.

도저히 안되겠다 싶어서 병원에 가봤다. 의사는 상태가 안좋다고 구토억제제를 처방해줬다. 하지만 약을 먹어도 별 효과가 없었다. 입덧을 시작하고 입덧 시작하고 2주가 지났을때 몸무게가 5킬로나 빠져있었다. 동네 병원에서 검사를 해보더니 상태가 많이 안좋다고, 그대로 있으면 엄마도 태아도 위험하니 얼른 종합병원 응급실로 가라고 했다. 응급실 의사는 입원을 해야 할 수도 있다고 했다. 그나마 응급실에서 구토억제제 주사와 수액 두 팩을 맞고 나니 겨우 혈색이 돌아왔다. 수분이 공급되면서 상태가 호전되니 입원은 하지 않아도 괜찮겠다고 했다. 대신 보통 구토억제제로는 안될 것 같고 말기 암 환자나 수술한 환자들이 먹는 쎈 구토억제제를 먹으라고 했다. 그나마 그 약을 먹으면 잠시라도 역겨운 것이 덜해서 물이라도 조금씩 마실 수 있게 됐다.

평화도 당황했다. 항상 자기랑 놀아주고 안아주던 엄마가 하루 종일 침대에 누워있기만 한데다 엄마 곁에 가지 못하게 내가 자꾸 떼어 놓으니 속상했을 것이다. 나도 종일 집안일을 하거나 틈틈이 원고 몇 줄이라도 써야 했기에 평화랑 놀아줄 시간이 별로 없었다. 낮에는 어린이집에 보내고 돌아오면 좋아하는 비디오를 틀어주고 앉혀놓는 수밖에. 어린이집에 안가는 날은 하루 종일 비디오와 TV만 봤다. TV가 지겨워지면 나에게 와서 놀아달라고 칭얼거리며 손을 잡아 끌었다. 잠시 놀아주다가 괜찮은 것 같아 자리에 돌아와 원고를 좀 더 쓰고 있으면 어느새 다시 달려와서 나를 잡아 끌었다. 낮잠은 물론이고 밤에도 내가 평화를 재워야 했다. 운이 좋으면 같이 누워서 30분만에 잠들기도 하지만 보통 잠이 들려면 1-2시간은 걸렸다. 잠이 든 걸 확인하고 나와서 다시 아내를 돌보거나 집안일을 해야 했다.

집안일이라는게 정말 끝이 없었다. 아내는 본격적으로 구토억제제를 먹기 시작하면서 그나마 속에서 받아주는 시원한 수박이나 오렌지같은 과일 그리고 패들팝아라는 아이스크림을 계속 원했다. 매일 장을 봐와야 했다. 일주일에 3일은 평화를 어린이집에 보냈는데 그런 날은 좀 더 시간을 벌 수 있을 것 같지만 막상 도시락을 준비하고 짐을 챙겨 데려다 주고 데리고 오고 하는 시간을 고려해보면 어린이집에 가지 않는 날에 비해서 겨우 3-4시간 정도 시간을 벌 뿐이다. 아내 먹을 것을 준비하고 집안일을 하다보면 다시 평화를 데려와야 할 시간이 되는 경우도 흔했다.

막막했다. 도저히 책을 쓸 수 있는 시간이 없었다. 그나마 어린이집에 평화를 보내고 아내 필요한 것을 챙겨준 뒤에 잠깐, 그리고 평화를 재운 뒤에 늦은 밤 중에 잠깐. 그게 내가 낼 수 있는 시간의 전부였다. 운이 좋은 날은 4-5시간 어떤 날은 2-3시간씩 밖에 쓸 수 없었다. 고객사의 요구가 들어오면 한밤중에라도 일을 해야 했다. 2010년 계약을 다시 하기 위해서 분석자료를 준비하고 제안서를 쓰는 시간도 필요했다.

12월 말까지 원고를 마무리하겠다고 큰 소리쳐놨는데 12월 한달 내내 그나마 쓰던 장도 마무리를 할 수 없었다. 원래 계획은 12월 말에 초고를 넘기고 1월에는 마음 편하게 휴가를 떠나는 것이었다. 12월부터 1월은 호주의 최대 휴가철이다. 그때가 가장 더운 여름이니까. 하지만 계획은 다 무산됐다. 크리스마스고 연말연시고 그런 것도 없었다. 매일 매일 끝이 보이지 않는 막막함 뿐이었다. 아내는 끝도 없이 계속 되는 심한 입덧으로 매일 힘겨워 했고, 나는 다시 끝이 보이지 않는 책의 마무리에 괴로워 했다.

지금은 이렇게 담담히 글로 적지만 그때는 정말 견디기 힘들만큼 괴로웠다. 내 인생에서 그렇게 힘든 시간은 처음이었다. 도무지 끝날 것 같지 않은 막막함이 들 땐 그 상황을 벗어나는 길은 죽음 뿐이라는 생각도 들었다. 한 자도 못쓰고 종일 뛰어다니다가 걱정 속에서 잠이 들때도 많았다. 고통스러워 하는 아내를 보면서, 뭔가 변한 엄마 아빠 모습에 스트레스를 받는 평화를 보면서도 내가 아무 것도 해줄 수 있는 게 없다는 사실이 괴로웠다. 여유를 가지고 집중하기 힘들었지만 그래도 죽을 힘을 다해서 빨리 마무리 하려고 노력했다. 겨우 겨우 1월 말에 11장을 끝냈다. 처음 생각대로라면 12월에 한 주면 다 썼을 것인데 무려 두달이나 걸렸다. 12월 말에는 초고를 넘긴다고 큰 소리 처놨는데 또 연락이 없으니 김 부사장님은 얼마나 더 실망했을까하는 걱정도 들었다.

그런데 11장을 끝낼 즈음에 내가 큰 착각을 하고 있다는 것을 깨달았다. 약속한 페이지를 맞추기 위해너 나름 재밌고 깊이 있는 내용은 다 빼고 꼭 필요하다고 생각되는 중요한 내용만 고르고 골라서 넣었는데도 11장을 끝냈을 때 이미 페이지가 750이었다. 아직 2부에서 가장 중요하다고 생각하는 MVC/@MVC와 Aspect/AOP, Test 기타 기술 등등이 남았는데 남은 페이지는 겨우 50. 그동안 계속 800을 채우면 끝이다라고 생각하면서 썼는데, 사실은 분량조절을 잘못해왔다는 것을 그제야 깨달았다. 스프링 기술의 선택가능한 옵션을 빠짐없이 소개하고 간단한 선택 가이드를 제공해 주면 되는 2부도 생각보다 쓸게 많다는 것을 그제야 깨달았다.

이미 여러번 800페이지 정도만 쓰겠다고 장담을 했는데 이제와서 분량을 더 늘리겠다고 할 수도 없었다. 그렇다고 이미 써논 것을 다시 편집해서 내용을 줄이자니 그것도 막막했다. 처음부터 끝까지 하나의 코드가 계속 연결되는 1부는 어떻게 건드릴 자신이 없었다. 그래서 일단 그냥 되는데까지 쓰기로 작정했다. 책을 다 쓰고 800페이지를 넘어가는 내용은 빼서 PDF로 공개하든지 그냥 버리든지 할 생각이었다. 아깝지만 그나마 생략해도 어색해보이지는 않는 7장과 8장은 빼버릴까도 생각했다. 적절하게 주제별로 비율을 따져보고 미리 페이지 분배를 꼼꼼하게 하지 않고 써논 것이 잘못이었다.

한숨이 나왔지만 어쩌겠는가 계속 써야지. 그렇다고 MVC/@MVC를 대충 쓸 마음은 전혀 없었다. 그리고 여전히 칭얼대는 평화와 입덧하는 아내를 돌보며 집안일에 매달려야 했지만 마지막이라고 생각하고 죽을 힘을 다해서 12장,13장을 써내려갔다. 그리고 단 20일만에 당시 편집하던 워드 파일로 210페이지(실제 책에서는 270페이쯤 되는 것 같다)에 달하는 MVC/@MVC를 다 써버렸다. 테스트 코드는 이전보다 더 많이 만들었고. 초기에 학습 테스트를 만들 때는 웹 기술의 테스트를 만드는 것이 너무 어려워서 생략을 했다. 그래서 12장을 쓰면서야 겨우 MVC 테스트를 하기 위한 간단한 지원 도구를 만들었다. 그리고 방대한 스프링MVC 내용을 하나씩 다 테스트 해가면서 넣었다. 기존 MVC에 비해 기능은 방대하고 내부 동작 방식도 복잡한 @MVC는 문서가 너무 빈약했다. 레퍼런스나 API문서만 가지고는 보이지 않는 프레임워크 내에서 일어나는 일과 규칙을 다 파악할 수 없었다. 그래서 스프링 @MVC 소스 코드를 모두 분석해야만 했다. 그렇게 분석한 내용을 가지고 가정을 세우고 그것을 2-3중의 테스트로 검증하고난 뒤에야 겨우 그 내용을 추가하는 식으로 써 나갔다. 문서와 소스를 분석하고 테스트를 만들어 검증하는 시간을 빼면 거의 하루에 20페이지씩 쓴 것 같다. 지금 다시 돌아봐도 어떻게 그 여유도 없는 상황에서 그 많은 내용을 다 썼는지 상상이 되지 않는다. 더 이상은 물러날 곳이 없다는 절박함 때문에 초인적인 힘이 났던 것일까.

그리고 14,15,16장을 열흘만에 다 써버렸다. 그렇게 해서 3월 4일 초고를 끝냈다.

마지막 장의 정리 절을 쓰고 나니 1000페이지가 조금 넘었다. 저장 버튼을 누르는 데 눈물이 났다. 지난 2년 넘는 시간동안, 특별히 지난 3개월의 끔찍했던 시간이 떠오르면서 이제야 살았다는 생각이 들었다. 아직 원고를 리뷰하고 교정하는 시간이 남았지만, 그래도 일단 마무리 했다는 것에 안도할 수 있었다. 정말 기분이 좋았다. 그 뒤로 리뷰를 마치고 초고를 넘겼을 때, 출판사 편집을 거쳐서 최종 원고 수정을 마쳤을 때, 책이 인쇄되서 나왔다는 얘기를 들었을 때, 그리고 책을 받았을 때도 기쁘긴 했지만 처음 원고를 마쳤던 그날만큼은 아니었다.

출판사에서 특급우편으로 보내준 내 책이 며칠전에야 도착했다. 책을 받아서 가장 먼저 아내에게 건내주었다. 나랑 함께 그 힘든 시기를 보내왔던, 답답하게 오랜시간 책을 쓰고 있는 남편을 보면서 한번도 잔소리도 한 적이 없는 착한 아내. 책을 살펴보라고 건네주고 잠시 방에 들어왔다 다시 나와보니 아내가 울고 있었다. 힘들었던 그때가 생각나서, 그래서 더 감격스러워서 우는 것이라고. 아내도 그때 참 많이 힘들었던 것 같다.

지금까지 별 시덥지 않은 얘기와 투덜거림으로 긴 글을 써온 것은 사실 오늘 이 얘기를 적고 싶어서였다. 그때는 이런 글을 쓸 수가 없었다. 책을 마무리 하지 못한 나는 죄인이었다. 맘 편하게 내가 즐기고 싶은 기술을 살펴보는 것도 용납하기 힘들었고, 내가 다 잘못해서 책을 완료하지 못한 주제에 힘든다는 말을 하는 것도 비겁해 보였다. 그래서 힘들어도 힘들다고 내놓고 말을 할 수가 없었다.

하지만 이제는 괜찮겠지. 다 지났으니까. 긴장했던 시간들, 짜증났던 시간들, 가끔 재미와 행복을 느꼈던 시간들, 그리고 견디기 힘들만큼 힘들었던 시간들.. 그 과정을 거쳐야 책이 하나 탄생하는 것인가. 나만 그런거겠지.

2010년 1월 1일. 새해 첫날이었지만 별 다른 것은 없었다. 여전히 괴로워 하며 끙끙 앓는 아내와 바뀐 환경에서 힘들어하던 평화, 그리고 잠시라도 짬이 나면 크리스마스든 새해 첫날이든 상관없이 자리에 앉아서 DI가 어떻고 @Inject가 어떻고 하는 얘기를 써나가야 했던 나. 그냥 달력을 보면서 2010년인가보다, 여전히 책을 끝내지 못한 책로 2010년을 맞았구나 하는 생각을 했다.

그리고 일년에 겨우 한 두 번쓰는 일기를 썼다. 차마 블로그나 공개된 곳에는 쓸 수 없었던 나 혼자만의 이야기를 가끔 적는다. 거기에 2010년 새해 목표를 적었다. 살아남기. 올해목표는 일단 성공한 듯. 그 일부를 여기다 옮겨본다. 이제는 얘기해도 되니까.

—————————–

1 Jan 2010

힘겹게 시작한 2010년. 새해가 시작한다는 느낌도 없다. 아니 느낄 조그마한 여유도 없다. 입덧하는 은성. 거의 폐인이나 다름없이 온종일 누워서 앓기만 한다. 엄마의 변화 때문에 힘겨워하는 평화. 전에 안하던 짓들을 슬슬 한다. 손에 잡히지 않는 일. 시간도 돈도 여유가 없는데 왜 이렇게 몸이 더딜까. 그나마 는 것은 집안 일 실력 뿐.

평화가 말을 듣지 않는 것 때문에 미친 듯이 흥분하는 내 모습을 보면서 아빠로서 기본적인 자격도 없는 것이 아닐까 하는 괴로움.

막막함.

그래도 절망하거나 힘겨워 하지 않고, 그래도 하루 하루 산다. 오늘 못하면 내일 하고, 오늘 조금 잘못했으면 내일 조금 덜 잘못하려고 하고, 그렇게 포기하지 않고 산다. 이제 내 목표는 어떤 멋진 꿈이 아니라, 포기하지 않고 살아남는 것. 이 삶을 살아 내는 것이다. 살아남자.

…

휴. 힘을 내자.

아자 아자.

내가 잘하는 한가지.

포기하지 않는 것.

지저분하게라도, 서글프게라도, 꿋꿋하게 사는 것.

2010. 시작이다.

—————————–

토비의 스프링 3이 나오기까지 (12)

왜 그런지 연재가 끝났다고 생각하는 분들도 있지만 제목이 ‘토스3이 나오기까지’인데 아직 안 나왔으니까 계속.

일단 원고를 완성하고 나니 기분도 좋아졌고 마음에 여유도 생겼다. 때마침 아내도 입덧이 좋아져서 조금씩 식사를 하고 기력을 회복하게 되었다. 끝이 보이지 않던 터널을 빠져나온 느낌이었다.

원고 리뷰를 시작했다. 어색한 문장이나 설명 고치고 최신 버전에 맞춰서 코드 점검하는 정도만 하면 될 것 같았다. 길어야 한달이면 충분하겠지라고 생각했다. 1000페이지니까 일주일에 200. 5일만 일하면 하루에 40페이지. 40페이지 리뷰라면 껌이구나.

거의 일년 3개월 전에 썼던 1장부터 다시 보기 시작했다. 맘에 안들었다. 아무래도 감을 잡기 전이라 1장은 좀 이리 저리 고민해가면서 쓰긴 했지만 이 정도일 줄은 몰랐다. 문장은 질질 늘어지고 어떤 건 너무 급하게 설명하고 넘어가고 어떤건 횡설수설. 코드를 발전시켜나가는 흐름과 그것을 이용한 스프링 설명방식은 맘에 들었지만 그 외에는 너무 한심했다.

확 다 지워버리고 다시 쓰고 싶었지만 도저히 그럴 수는 없고, 어색하다고 보이는 문장은 모두 고치고 맘에 안드는 문단은 통채로 다시 썼다. 거의 30%쯤은 다시 쓴 듯. 1장은 나중에 한번 더 봤는데 그때도 맘에 안들었다. 열번이고 맘에 들때까지 고치고 싶었지만 결국 두번 보고 "에라 모르겠다" 하면서 그냥 포기. 나름 초보자도 이해할 수 있게 쉬우면서도 독특한 방법으로 스프링의 DI 개념을 설명하고, 1부에서 계속 얘기 할 내용의 핵심 메시지를 담고 싶었는데… 과연.

코드도 모두 다시 검증해서 넣었다. 원고 있는 코드를 가지고 다시 맨땅에서 부터 프로젝트를 만들어서 테스트를 하고 검증이 되면 그것을 다시 붙여넣는 식으로 작업을 했다. 맘에 안드는 다이어그램도 다시 수정. 그리고 가을에 만났을 때 김 부사장님이 알려준 기준에 맞게 일부 구성도 수정했다. 각주(-_-;;)도 모두 본문에 넣거나 박스로 뽑아냈고.

가장 손이 많이 간 것은 리스트나 그림의 번호를 참조(그림 1-1을 보시라 같은)하는 부분이다. 한장에 수십에서 백여개까지도 나오는 리스트는 번호 자동 생성기능을 이용해서 만들었기 때문에 중간에 삽입하거나 제거한다고 해도 자동으로 번호가 갱신되서 일일이 번호를 수정하는 번거로움은 없다. 하지만 본문에서 참조한 부분은 일일이 하드-코딩(?)을 한 탓에 리스트의 번호가 달라지면 모두 찾아서 수정을 해줘야 하는 번거로움이 있었다. 자동으로 리스트 번호와 연동이 되면 좋을텐데라고 투덜거리면서 작업을 했는데, 알고보니 워드에 그런 기능이 이미 있었다. 상호참조라고.

내용도 확정했고 특별히 더 넣거나 뺄 리스트나 그림은 없으니 그냥 한번씩 확인만 하고 말까했지만, 영양가 없을 때만 꼼꼼해지는 성격상 몽땅 다 상호참조로 바꾸기로 했다. 어떤 장은 백개도 넘는 리스트와 장마다 수십 개에 달하는 그림의 참고글에 상호참조 적용하는 것만 해도 방대한 작업이었다. 그게 메뉴를 타고 들어가서 매번 제일 앞으로 돌아가는 목록을 뒤져서 번호를 삽입하는 식이다 보니 작업이 무척 더뎠다. 그런데 막상 그렇게 확인을 하면서 상호참조를 넣다보니 안했으면 큰일날 뻔 했다는 생각이 들었다. 그 사이에 글을 수정하면서 본문에서 참조한 리스트나 그림의 번호가 틀린게 많았다.

일부 코드는 아예 수정이 필요한 것도 있었다. 1장을 쓸 때는 스프링 3.0이 겨우 M1이었다. 그때는 아씨아씨(이클립스에서 ACAC라고 치고 컨트롤-스페이스를 누르면 내가 테스트 만들 때 애용하는 AnnotationConfigApplicationContext이 나온다)가 없었기 때문에 XML없이 자바코드만 가지고 @Configuration를 사용하게 하려면 여러 줄의 코드가 필요했다. 하지만 나중에 ACAC가 나온 뒤로는 컨텍스트 생성자로 충분했다. 이런 식으로 원고를 쓸 때의 스프링 버전과 달라진 점이나 개선된 내용을 찾아서 적용하는 것도 큰 작업이었다.

처음 생각엔 이틀이면 충분했을 것 같았는데 1장을 퇴고(나도 폼나는 말 좀 써보자)하고 나니 이미 2주가 지났다.

다행히 2장부터는 그나마 수정할 데가 많지는 않았다. 1장을 마무리 할 때쯤엔 글을 쓰는 감도 조금 잡히고 리듬도 타고 하니 아무래도 처음 보다는 덜 어색해졌나보다. 표현이 어색한 것은 나중에는 크게 손대지 않았다. 고쳐봐야 여전히 어색하고. 차라리 출판사에서 편집하면서 세련되게 다듬어주기를 기대하는 것이 나을 듯 싶었다. 편집과정에서 어색한 문장과 표현은 모두 깔끔하게 다듬어 준다는 얘기를 어디선가 들은게 있으니까.

대부분 내용이나 코드는 크게 바뀔 것은 없었지만 일부 테스트 코드는 좀 더 나은 아이디어가 보이면 과감히 수정하기도 했다. 스프링에 관한 모는 내용을 다 넣은 것은 아니지만, 나름 중요한데도 깜빡하고 빼먹은 것이 보이면 추가하기도 했다. 일관성 없는 코드(리스트)도 통일을 해야 했다. 코드가 조금씩 바뀌면서 진행되다 보니 클래스 전체를 보여주는 경우는 드물었다. 물론 바뀔 때마다 전체 코드를 넣을 수도 있지만 양을 늘리기 위해서 별짓 다한다는 얘기를 듣기 딱 좋다. 그래서 바뀌는 부분만 골라서 삽입했다. 전체 코드의 변화를 보려면 아무래도 52단계로 쪼개서 넣은 CD의 예제 코드를 보거나 아니면 본인이 직접 해볼 필요가 있다.

남은 건 package와 import를 넣는냐의 문제였다. 클래스의 일부분이지만 그래도 어느 패키지의 어떤 클래스인지는 알려줘야 했다. 그래서 처음 클래스가 등장할 때는 package는 넣었다. 그게 예제라고 하고 파일 경로를 적는 것보다 나아보였다. 문제는 import. 이게 한 둘이 아닌데 이걸 다 넣으면 코드의 양이 두 배는 될 테고 책도 100-200페이지는 더 늘어날 것 같았다. 그래서 정말 특별한 경우에만 한 두 개의 import를 넣고 나머지는 다 생략했다. 이 때문에 책만 보고 코드를 따라하는 경우 이클립스에서 타입 이름을 보고 import를 자동으로 삽입해주는 Organize Imports 기능을 잘 사용하지 못하는 사람이라면 import문 때문에 고생할 수도 있겠다는 생각이 들었지만 어쩔 수가 없었다. 대신 쌩 초보자를 위해서 1부의 내용을 코딩하는 동영상을 만들고 이를 공개해주면 괜찮겠다 싶었다. 물론 책이 끝날 무렵엔 에너지를 다 소진해 버려서 아직도 그 동영상은 못 만들고 있긴 하지만. –_-;;

일부 부족한 설명과 중요한데 깜빡하고 빼먹은 내용 등을 추가한데다 캡션 없이 코드를 넣었던 것도 대부분 리스트-xx를 넣달아주고, 코드에 package나 import를 생략했다는 표시를 넣다보니 20페이지 정도 더 늘었다.

책을 쓰는 중에는 다들 하는 베타 리딩을 할까 생각했다. 하지만 원고를 마무할 즈음엔 베타 리딩이 엄두가 안났다. 오탈자나 기술적인 문제를 지적해주면야 고맙지만 구성이나 전개방법, 내용 등에 관한 피드백이 들어오면 아마 기절할지도 모를 거란 생각이 들었다. 그래도 기술적인 설명과 코드, API 사용등에 관해서 한번은 다른 사람의 점검을 받아야 겠다고 생각했다. 7년가까이 매일 만져오던 스프링이지만 내가 자주 사용하지 않아서 익숙하지 않은 기능을 설명할 때 실수했을 수도 있고, 아니면 내가 뭔가 착각하고 있었거나, 작성한 코드에 결함이 있을 수도 있었다. 게다가 자기가 쓴 글은 틀린 게 잘 안보인다. 그래서 기술적인 내용에 관한 검증을 기선이에게 부탁했다. 기선이는 스프링에 관해서는 오랜 동안 깊이 연구했고 최신 버전의 기능에도 익숙한데다 꼼꼼하기까지 해서 제격이었다. 기선이는 자기 할 일로 바쁜데도 흔쾌히 응해줬다. 그리고 내가 리뷰 하는 내내 책의 내용을 빠짐없이 읽고 코드를 모두 테스트 해보고 기술적인 설명은 근거가 될만한 레퍼런스 문서나 API항목을 일일이 찾아보면서 검증하는 등의 수고를 해서 오탈자를 제외하고도 수십 개의 크고 작은 오류를 지적해줬다.

기선이가 없었다면 아마 내가 그런 작업을 직접 해야 했을 거고 적어도 한 두 달은 시간이 더 걸렸을 것이다. 단지 오류를 발견해서 알려주는 것이 전부가 아니라 모든 기술적인 설명에 근거를 일일이 찾아서 점검도 해야 했기 때문이다. 기선이는 최종 원고 수정을 마칠 때까지 꼬박 두 번에 걸쳐서 책을 샅샅이 읽고 점검해줬다. 중간중간에 책을 읽은 느낌이나 생각을 블로그에 적기도 했다. 아참. 그래서 하고 싶은 얘기는 테크니컬 리뷰어는 기선이니까 설명에 기술적인 오류가 있다면 기선이에게 항의를… ( ”)

주로 내용과 코드, 설명을 점검하는 1차 퇴고를 마치고 나니 두달이 조금 넘었다. 거기에 틈틈이 기선이가 체크해서 보내준 내용을 적용했고. 원래 계획은 한번 더 전체 내용을 읽으면서 문장을 다듬어보는 것이었지만 이미 에너지는 거의 바닥나 있었다. 초고를 마무리 하느라 전력질주를 한데다 리뷰과정 중에도 거의 매일 12시간 이상 눈이 빠지게 모니터만 들여다 보고 있었으니 남은 기운이 없었다. 그래서 1장과 10장 정도만 다시 조금 손을 본 뒤에 5월 20일에 책 원고를 출판사에 보낼 수 있었다. 맨날 답이 없는 유령 저자에게 저술진행 확인 메일을 보내느라 수고해왔던 황지영 과장님에게 드디어 원고를 보내드립니다라는 답장을 보냈다.

그리고 책의 탈고를 알리는 블로그 글을 썼다.

저술 계약한지 3년이 넘도록 한번도 진행중인 원고를 출판사에 보낸 적이 없었다. 그 때가 처음이자 마지막이었다. 과연 출판사는 뭘 믿고 경험도 없는데다 약속을 밥먹듯이 어기는 저자를 원고 확인도 없이 기다려 주었을까 궁금했다. 나라면 수시로 원고 쓴 거 달래서 확인을 해봤을텐데. 내 책은 이미 포기한 것은 아닐까라고도 생각했다.

한편으로는 원고를 보냈으니 편집을 마치고 내가 다시 리뷰할 때까지 푹 쉴 수 있다는 생각에 마음이 편하면서도 다른 한편으로는 편집과정이 얼마나 험난할까 하는 걱정도 들었다. 주위에선 "안드로이드 같은 최신 기술이 워낙 인기라 스프링 같은 비인기 책은 아마 편집 작업에도 밀려서 찬밥일 것이다" 또는 "편집당해서 내용을 왕창 들어내야 할 것이다"라고 겁을 주기도 했다. 그래서 긴장도 많이 됐다.

이유야 어쨌든 처음 약속과 달리 1000페이지가 넘어버렸는데 이걸 내가 먼저 줄여서 넘길까 하다가 김 부사장님 반응을 먼저 살펴봤는데, 1000페이지라고 해도 크게 놀라시는 눈치는 아니었다. 일단 보고 판단하자는 생각이셨을까. 그래서 나도 모르겠다는 심정으로 원고에 손을 대지 않고 일단 그대로 넘겼다.

출판사에서는 편집 디자인, 최종 리뷰, 인쇄, 제본 등에 최소한 한달 반 정도의 시간이 필요하다고 했다. 늦어도 7월 초면 책이 나온다고 했다.

과연?

토비의 스프링 3이 나오기까지 (13)

드디어 마지막. 이렇게 길어질 줄은 몰랐는데. 내가 도대체 왜 시작한거지… 어휴.

초고를 넘기면 3주 정도 후에 편집된 원고를 받을 것이고 내가 최종 확인해서 넘겨주면 내 일은 끝이라고 들었다. 하지만 그 외에도 몇 가지 남은 작업이 있었다.

책에 나오는 내용을 담은 예제 프로젝트는 꼼꼼하게 만들어서 1부 52개, 2부 1개의 이클립스 프로젝트로 구성을 해두었다. 그런데 학습 테스트와 점진적인 빈 개발 스타일로 만들다 보니 정작 서버에 배치해서 돌려볼 수 있는 완전한 애플리케이션이 없다는 것이 마음에 걸렸다. 스프링의 많고 많은 접근방법 중에서 한 가지를 선택해서 예제를 만드는 식으로 책을 쓰는 것은 원치 않았지만 그래도 간단히 살펴볼 웹 애플리케이션 예제 하나쯤은 있어야 하지 않을까하는 생각이 들었다. 2부의 스프링@MVC에서 설명한 내용, 특히 폼과 바인딩 하는 부분은 실전에 적용된 샘플을 참고하도록 제공할 필요가 있을 듯 싶었다. 그래서 간단히 스프링사용자모임(springusergroup)이라는 이름으로 예제를 만들었다. 회원 등록과 로그인, 관리가 전부인 초간단 예제였지만 그래도 책에서 설명했던 내용을 최대한 반영해보려고 했다. JDBC와 JPA를 동시에 사용하는 DAO라든가 세션 스코프를 이용한 로그인 정보 관리, 또 도메인 오브젝트를 유지하면서 폼 바인딩을 하는 방법을 담으려고 노력했다. 책에서 끊임없이 테스트가 중요하다고 떠들어댔으니 테스트도 빼먹을 수 없었다. 단위테스트, 통합테스트 등을 적절히 섞어서 테스트 코드도 꼼꼼히 만들었다. 좀 더 복잡한 예제를 만들면 좋았겠다 싶지만 그것도 사실 겨우 만들었다. 점점 책과 관련된 일이 하기 싫어지는 걸 느꼈다.

부록도 썼다. 이미 오래전부터 스프링의 의존 라이브러리와 모듈 의존관계 등을 분석하고 블로그에 연재해온 것이 있으니 그걸 참고해서 부록을 작성하는 것은 어렵지 않았다. 사실은 SpEL 문법을 부록-C로 넣으려고 생각은 했지만 양도 많은 데 그것까지 굳이 넣어야 하나 고민하다 과감히 나몰라라 생략.

1부 코드를 작성하는 것을 동영상으로 만들어서 공개하기로 한 계획은 일단 취소. 도저히 기운이 없었다. 원고를 넘기고 긴장이 풀리면서 힘이 하나도 없어서 뭔가 할 의욕이 나지 않았다. 책과 관련된 모든 일에서 가능한 빨리 손을 떼고 싶었다.

편집을 기다리는 시간은 매우 길게 느껴졌다. 가장 궁금했던 것은 책의 분량이었다. 나는 처음 약속과 달리 1030페이지나 썼다. 다시 100-200페이지쯤 줄여야 하는 것일까, 뺀다면 뭘 뺄까 그런 생각을 하고 있었다. 그런데 어느날 놀라운 얘기를 들었다. 책을 편집해보니 1400쯤 나온다는 것이었다. 꺅. 내가 분명히 에이콘 기존 서적과 비교해서 페이지 분량이 일치하도록 템플릿 파일을 만들어서 썼는데 이게 무슨 일인가. 무려 400페이지나 더 늘어나다니!! 김 부사장님은 일단 편집을 통해서 최대한 페이지 수를 줄이도록 하고 있지만 그래도 얼마 안될거라고 하셨다. 그리고 1400페이지면 책 두께가 너무 두꺼워 지고 제본도 곤란하니 200페이지 정도 분량을 줄여보는 것이 어떻겠냐고 하셨다.

책의 내용을 줄일 각오는 하고 있었으니까 그건 문제는 아니었는데 책이 그래도 1200페이지나 된다고 하니 놀랄 수 밖에. 그런데 뭘 빼야 할까. 중복된 내용이 있으면 빼라고 하셨지만 중복이라고 생각되는 부분은 없었다. 차라리 덜 중요하거나 중요하지만 빼도 흐름에 지장을 주지 않는 장을 통채로 빼는게 나을 것 같았다. 예를 들면 스프링 학습방법을 설명하고 기타 기술 내용을 담은 16장이나, 스프링의 개념을 담은 8장 또는 내가 가장 아끼기는 하지만 빼도 다른 내용에 영향을 주는 것이 아닌 7장 같은 것을 생각하고 있었다. 또, 9장의 스프링 툴 소개 같은 것도 빼도 될 것 같고. 이런 내용은 PDF로 만들어서 CD에 넣거나 그냥 공개해버려도 되지 않을까도 생각했다.

이런 저런 생각을 하면서 며칠이 흘렀는데 다시 김 부사장님으로부터 연락이 왔다. 사장님께서 책 내용을 줄이지 말고 그대로 내라고 지시하셨다고. 저자가 힘들게 썼는데 왜 줄이냐고 하셨다는 것이었다. 감동이 몰려왔다. 원래 사장님이 쫌 멋지다는 건 알고 있었지만… 찡. 그런데 문제는 1400페이지로 책을 내려면 하드커버 제본을 해야 한다고 하셨다. 그리고 두께를 줄이기 위해서 질이 좋은 얇고 질기지만 무거운 종이로 해야 하고. 그래야 두께를 20%쯤 줄일 수 있다. 대신 종이와 제본 등에서 비용이 증가하기 때문에 책 값은 처음 계획보다 올라갈 수 밖에 없었다. 그래서 결국 1400페이지짜리로 무게가 살짝 나가는, 좋은 종이를 쓴 그러면서도 가격은 적당한 책이 나오게 된 것이다. 예상과 달리 두꺼운 책이 나온다는 사실에 놀라기도 했고, 그래서 책이 잘 안팔리면 어쩌나 걱정도 살짝 됐지만 그래도 기분은 좋았다.

7월 중순에 편집본이 왔다. 처음 예상과 달리 편집이 늦어진 것은 분명 내 탓일 것이다. 페이지 수는 거의 두 배 가까이 늘었고, 게다가 엉망인 문장 천지라 다듬고 정리하는 데도 시간이 많이 들었을 것이다. 또, 헤드퍼스트 흉내낸다고 코드에 일일이 화살표나 박스를 달고 코멘트를 넣은 것 때문에도 시간이 더 들었을 것이고. 처음엔 그냥 번호나 달고 코드 아래 본문에다 설명을 달았는데 분량은 늘어나는 데다 코드와 설명이 따로 있어서 읽기 불편할 것이라는 생각에 공간이 허용하는 만큼 코드 주위에 직접 설명을 달려고 노력했다. 편집본을 받아서 최종 리뷰를 하고 오탈자를 찾아내고 하는 작업에 다시 일주일쯤 시간이 걸렸다. 일주일 정도 매달려서 작업한 끝에 7월 19일에 최종 수정본을 보냈다.

추천인들이 결정되고 추천사도 받았고, 들어가며와 저자의 말도 다시 썼다. 저자의 말을 쓰면서 지난 3년의 시간을 다시 돌아봤다. 책 한권이 나오기까지 나에게 영향을 준 많은 사람들이 떠올랐다. 또, 겁도 없이 책을 쓰기로 하고, 적지 않은 스트레스 속에서 책을 쓰기 위해서 고군분투했던 시간, 실망하고 좌절하기도 했고 때로는 기쁘고 흥분했던 시간들이 생각이 났다. 책에 들어갈 내용이니 그런 얘기를 일일이 다 적을 수는 없었다. 간단한 소감과 책을 쓰는데 직접 도움을 주거나 영향을 주신 분들에 대한 감사의 말을 남겼다.

저자의 말의 원고를 넘기고 나니 정말 모든 것이 끝난 기분이었다.

하지만 인쇄되서 배포되는 책에는 차마 담을 수 없었던 지난 이야기를 어딘가 남기고 싶었다. 부끄러운 얘기도 있고, 밝혀지면 누군가 기분 나쁠 얘기도 있었지만 뭐.. 그래도 한번은 꼭 다 털어놓고 싶었던 지난 3년 간의 내 모습과 생각들이고 블로그는 그런데 쓰라고 만든 거니까. 시간이 좀 더 지나면 잊혀질지 모르는 내 기억과 느낌, 생각을 그래서 모두 꺼내봤다.

이제 속이 후련하고 마음이 편하다.

이제는 지난 시간들을 다 잊어버리고 다시 앞을 향해서 달려 나갈 수 있을 것 같다.

네트워킹, 우모(Umoh)

PaxCaelo — Wed, 11 Oct 2023 14:24:12 +0900

원래 숫기가 없고 극도로 내성적인 성격을 가진 나는 처음 보는 사람들을 만나서 이야기를 나누고 관계를 형성한다는 네트워킹이란 정말 나와는 관련 없는 다른 세상 얘기라고 생각했다. 내가 좋아하는 건 조용히 관찰하는 것이고, 그래서 새로운 사람들을 만나는 모임에선 항상 사람들의 모습을 유심히 관찰을 하다가 조용히 사라지곤 했다.

그런 내가 네트워킹에 흥미를 가지게 된 건 90년 대 후반부터 열심히 참석하던 개발자 행사, 특히 해외에서 열리는 컨퍼런스 때문이다. 보통 3-4일 일정으로 열리는 컨퍼런스에선 매일 저녁 스폰서가 주최하는 네트워킹 파티가 진행된다. 행사가 열리는 호텔이나 전시장에서 하는 경우도 있지만 근처의 유명 펍이나 식당을 통째로 대여해서 열리기도 한다. 음식과 음악 정도 제공되는 공간에 다들 서서 돌아다니면서 곳곳에서 몇 명씩 모여서 이야기를 한다. 종일 어려운 기술 발표를 듣고 토론하고 했던 사람들이 또 무슨 할 얘기가 그렇게 많은지 열심히 이야기를 나눈다. 한동안 그러다, 또 흩어져서 다른 그룹에 들어가거나 마음이 맞는 상대가 있으면 바닥에 앉아서 1:1로 진지한 이야기를 이어가기도 한다.

벨기에에서 열린 스프링원 2007에서 네트워킹 시간

나는 이미 그룹이 형성되어있으면 슬쩍 끼어들어서 무슨 얘기를 하나 듣기만 했다. 별별 얘기들이 오간다. 자기소개 그런 것도 없이 대뜸 누가 흥미로운 주제의 이야기를 시작하면 돌아가면서 자기 생각을 편하게 얘기하다 흩어진다. 한국이었다면 일단 모이면 명함부터 돌릴 텐데 서양 애들은 세일즈 쪽이 아니면 명함 따위를 가지고 다닐 리가 없지. 아무튼 그렇게 새로운 사람을 만나고 새로운 이야기를 듣고 자기 생각을 나누는 시간도 있지만, 자신이 어떤 일을 하고 어떤 이유로 행사에 참석했는지 앞으로 어떤 구상을 하고 있는지, 자신에 관한 이야기를 나누기도 한다. 엄청난 속도로 기술 토론을 할 때는 엄두를 못 내던 나도 그런 분위기에서 조금씩 이야기를 꺼낸다. 내가 최근에 참석한 해외 컨퍼런스는 스페인에서 열린 유럽 개발자 행사인 Spring I/O였는데 그때까지도 참석자 중 동양계는 극소수였다. 일본에서 참석한 사람이 가끔 보이고, 어쩌다 한국의 대기업에서 오신 분들이 있긴 하지만. 어쨌든 소수였기 때문에 말을 꺼내기 시작하면 다들 흥미롭게 들어준다. 한국인이라고 했지만 알고 보니 호주에 산다고 하면 더더욱. 참석했던 행사 대부분이 미국이나 유럽에서 열리는 것이라 호주에서 간 사람들도 극히 드물었으니까.

얘기를 나누다 다음을 기약하기도 했는데, 특히 일본이나 동양에서 온 소수의 참석자들과는 뭔가 정이 들기도 하고 그랬는지, 앞으로 한국-일본 개발자들이 모여서 우리만의 컨퍼런스를 만들어보자고 의기투합도 해보고 서로 연락처도 주고받고 그랬던 것 같다. 비즈니스 네트워킹이라고 하기에는 다들 기술에만 관심 있는 너드 같은 사람들이어서 그랬는지, 온라인 커뮤니티 등에서 얼마든지 교류할 수 있어서 그랬는지 모르겠지만 행사 이후 만났던 사람들과 관계가 이어진 경우는 별로 없어 보였다. 특히 멀리서 참석한 나 같은 경우엔.

그러던 중에 호주에서 SME(Small and Medium-sized Enterprises) 경영진들을 대상으로 세미나가 열린다고 호기심에 한번 참석을 했다. 마지막 시간 발표 주제가 비즈니스 네트워킹이었다. 네트워킹이 왜 중요한지 어떻게 해야하는지 열정적으로 설명하던 발표자가 이제 실습을 해봅시다라고 하고는, 옆에 앉는 사람들과 네트워킹 연습을 시켰다. 워낙 오래전이라 행사 이름이나 다른 발표 내용은 기억이 나지 않지만 그때 한 네트워킹 실습은 오래 기억에 남았다.

옆자리에 정장을 하고 온 나이가 지긋한 분과 자기소개를 하고, 행사 때 들은 이야기 중에서 서로 관심이 있을만한 주제를 골라서 각자 하고 있는 비즈니스의 예를 들어가면서 대화를 나눴다. 강사가 요구했던 것은 공통의 관심사를 찾아보라는 것이었다. 그걸 주제로 조금 더 깊이 얘기를 해보고 세미나에서 배운 걸 앞으로 어떻게 적용해 볼지 구상도 나누게 했다. 그러고 나서 괜찮다면 서로 이메일을 교환하라고 했다. 그땐 아직 소셜미디어가 활성화되기 전이라 소통 방식은 전화 아니면 이메일일 텐데, 행사에서 만나서 네트워킹을 한 사람과 만든 연결점을 확대할 수 있는 방법으로 이메일을 보내는 걸 추천했다.

방법은 이렇다. 나와 공통적인 관심사를 가진 사람을 만나서 이야기를 나누었다면 메일 주소를 정중하게 요청한다. 그리고 일주일 이내에 메일을 보낸다. 지난 번 행사에서 만나서 어떤 주제로 얘기를 나눴던 사람입니다라고 자신을 소개한다. 어차피 명함을 주고받은 것도 아니고, 시간이 조금 지나면 이름도 까먹겠지만 서로 관심 있는 주제를 가지고 이야기를 나눴던 사람이라고 소개한다면 기억을 떠 올 릴 수 있다. 그때 무슨 얘기를 했던 사람이라고 좀 더 구체적이고 특징적인 언급을 해도 좋다. 그리고 행사 이후에 자신은 어떻게 해보고 있고 또 생각은 어떻게 발전했는지 등을 가볍게 나누고 상대는 어떤지 질문을 가볍게 해 본다. 행사나 모임 등을 통해서 만드는 네트워킹은 상대의 기억에 들어가는 게 중요하다. 아, 그때 이런 말을 했던 사람, 이런 고민이 있다고 꺼냈던 사람, 내가 관심 있어 하는 주제에 대해서 흥미를 보이고 깊이 생각해봤다고 느꼈던 사람, 아니면 뭔가 재밌는 말을 했거나 튀는 옷을 입었다거나, 뭐가 됐든 상대의 기억 속에 단기적으로라도 남을 수 있다면 시작할 수 있다.

함수형 프로그래밍 구루이고 LINQ와 RX를 만든 것으로도 유명한 에릭 마이어는 항상 입고 다니는 화려한 셔츠 때문에 기억에 남는다. 나에게는 QCon에서 만난 하와이안 셔츠를 입고온 재밌는 아저씨로 기억된다.

메일로 서로의 소식과 관심을 나누고 나서 더 관계를 발전시키고 싶다면 이제 가볍게 티타임을 가지자고 요청을 해도 된다. 그렇게 네트워킹을 통해 시작된 연결이 단단해지다, 잘하면 비즈니스 관계로도 발전시킬 수 있다, 뭐 대충 그런 이야기였다. 나도 그때 만났던 분에게 메일을 보냈고 답장을 받았다. 워낙 다른 섹터에 있는 분이라 그 이후에 더 관계를 발전시키지는 못했지만.

지난 8월에 열린 인프콘이라는 행사엔 1800명 정도 개발자들이 참석했다. 다들 열정적이고 기술과 사람에 관해서 관심이 많은 듯 보였다. 나는 발표자로 참석했다. 발표자는 별도의 공간에서 안락하게 대기하거나 쉴 수 있게 해줬지만 해외에 사는 나에게는 흔치 않은, 사람들과 접점을 만들 수도 있는 기회라고 생각되어서 줄곳 발표장 근처 로비 한쪽에 자리 잡고 있었다. 아직도 나를 기억해 주는 사람들이 있어서 많은 분들이 와서 사인을 받거나 사진을 함께 찍고 가셨다. 가끔 명함을 주고 가신 분들도 있고. 뒤에 줄 서서 기다리는 분들이 있어서 그랬는지, 더 깊은 얘기를 하기엔 내가 부담스러웠는지, 굿즈 받으러 빨리 가야 했는지 모르겠지만 가벼운 인사 이상의 대화를 나누진 못했다. 온라인 커뮤니티에서만 뵀던 몇몇 분들과 인사하고 잠시 이야기를 한 정도 외에는.

나랑 같이 사진을 찍은 분들이 꽤 많았지만 나중에라도 나에게 사진을 보내주신 분은 없었다. 내 소셜 미디어는 잘 알려져 있고, 책에 내 이메일 주소도 있으니까 얼마든 보내줄 수 있겠지만, 굳이 그럴필요가 있을까라고 생각했는지 모르겠다. 이제 이야기할 딱 한 분 빼고는.

오후 늦게 시작된 내 세션에서 열심히 발표를 마쳤고, Q&A 시간을 가져야 해서 준비된 장소로 이동했다. 많은 분들이 오셔서 질문을 하기도 하고, 사인을 받거나 사진을 찍기도 했다. 몇 분들은 자신의 명함을 주고 가셨다. 그러던 중에 어떤 분이 명함을 건네셨는데 거기에 글이 적혀있었다. 발표를 듣고 뭐라도 피드백을 하고 싶어서 급하게 가지고 있던 자신의 명함에 글을 써서 주셨다고 했다. 발표 내용에 대한 동감과 고마움을 담은 짧은 글이었는데, 이런 걸 받아본 건 처음이어서 그런지 눈에 확 들어왔다. 발표 끝나고 긴장도 풀어지고 정신도 없어서 전해주신 분이 누구였는지 기억은 전혀 나지 않았지만 명함에 글을 써서 주신 분이 있었다는 건 컨퍼런스 날에 남은 가장 강렬한 기억이 됐다.

그리고 며칠 뒤에 페북에 명함 사진과 함께 그 이야기를 올렸는데 어떤 분이 자신이 준 것이라며 댓글을 달았다. 그리고 나랑 같이 찍은 사진도 보내주셨다. 그날 나랑 사진을 찍은 많은 분들 중에 사진을 보내준 유일한 사람이다.

네트워킹은 연결되고 싶은 사람에게 자신의 기억을 남기는 것이 시작이다. 기억이 남으려면 구체적이어야 한다. 마주친 수십, 수백 명 중에서, 아 그 사람이 있었지라고 생각이 날만하게. 보통은 대화를 나누다가 관심 있는 이야기가 오고 가거나 인상적인 내용이 있으면 기억하기 쉽다. 나에게 와서 스프링 잘 쓰고 있어요, 다음 책이나 강의는 언제 나오나요,라고 질문하시면 친절하게 답변은 드리겠지만 누가 그런 질문을 했는지 기억할 수 없다. 그런데 최근 온라인 강의에서 이런 말씀을 하셨는데, 그 내용이 너무 좋아서 실무에 이런 식으로 적용을 해봤어요, 그리고 이런 효과를 얻어서 좋았습니다라고 말을 해준 분이 있다면 나도 바로 좀 더 도움이 될만한 설명을 하려고 노력했을 것이고, 어떤 분인지 한번 더 살펴보고, 그 기억이 오래 남았을 것이다.

그렇게 기억이 있다면 접점이 만들어진 것이고, 오랜 시간이 지나기 전에 그걸 강화하는 다음 스텝이 필요하다. 기억을 상기시키면서 좀 더 대화를 이어가거나 이후에 또 다른 만남의 기회를 만드는 것이겠지.

나에게 글이 적힌 명함을 주셨던 분은 내가 글을 올린 뒤에 댓글을 남기고 사진을 보내셨다. 그리고 얼마 지나지 않아서 자신이 일하고 있는 스타트업에 방문해서 커피챗을 할 수 있겠냐고 물으셨다. 기억에 강하게 남은 분의 요청이니 한번 만나봐야겠다 싶어 그러겠다고 하고, 일하는 회사를 방문했다. 그분이 어떻게 개발을 하고 있는지, 어떤 고민을 하고 있는지, 비즈니스는 어떤 것인지 더 깊이 이야기를 듣게 되었다. 그리고 이야기를 듣던 중에 개발과 관련해서 몇 가지 안타까운 생각이 들었다. 주니어로만 구성된 소규모 스타트업 개발팀이 가지는 어쩔 수 없는, 하지만 개선할 수 있다면 좋을만한 상황이었다. 그래서 내가 조금 도움을 드릴 수 있는 방법이 있을지 묻고 계속 이야기를 이어나가게 됐다.

관계가 지속 되려면 상호적(mutual)이어야 한다. 일방적인 건 오래가지 못한다. 내가 도움을 주거나 알려주고 싶은 것이 있다면 나도 뭔가 받을 게 필요하다. 그게 꼭 비슷한 레벨의 지식이거나 경험 등이 아니어도 괜찮다. 관계를 통해서 진행되는 일에 대한 상세한 피드백도 좋다. 나처럼 지식을 나누는 일을 하기 좋아하는 사람에게는 피드백만큼 값진 것도 없다. 새로운 경험을 만들 수 있는 도전거리, 알고 있던 지식을 확장해보고 싶게 동기를 만들어주는 요청, 그리고 돈을 받고 일해주는 사람들에게서는 흔히 받기 어려운 고마움의 표현도 나쁘지 않다. 보람을 느낄 수 있다면 그만한 것도 없다.

이번엔 좀 독특한 경험이었지만, 아무튼 컨퍼런스와 같은 만남에서 네트워킹이 시작되어서 연결이 발전해나가는 경험은 항상 짜릿하다.

그런데. 나야 사람들에게 많이 알려져있어서 먼저 다가와주는 분들이 많고 원한다면 어떤 식으로든 네트워크를 만드는 게 가능할 것이다. 그러면 그날 온 1,800명의 사람들은? 원래부터 잘 알고 있던 지인들이 있다면 반갑게 인사하고 함께 시간을 보냈겠지만 그렇지 못한 분들이라면 어떨까 항상 아쉬움이 있다.

그런데 이번 인프콘에는 짧지만 오후에 네트워킹 시간과 장소가 제공됐다. 나도 들어갔다가 여기저기 그룹에 끌려가서 이야기를 나눴다. 시간과 장소가 주어지니 다들 잘 하시는 것 같다. 젊은 분들이라 그런가. 저녁이 되기 전에 끝나는 하루짜리 행사임에도 그런 시간이 있다는 게 정말 좋더라. 시간이 너무 짧은 게 아쉬웠지만.

이런 생각을 해봤다. 행사에 참석한 사람들 중에서 네트워킹을 원하는 사람이 있다면 보다 쉬운 방법으로 각자 자기를 소개하고 관심사를 나눌 수 있고, 그래서 접점을 만들 수 있는 도구가 있다면 어떨까. 가능하면 행사 중에 잠깐 만남을 가질 수 있는 방법이 있다면.

그러던 중에 최근 발견한 흥미로운 서비스가 하나 있다. 이름은 우모(Umoh)이다. 한국의 스타트업이 만든 서비스이다.

컨퍼런스나 세미나 같은 행사나 온/오프라인 커뮤니티에 모인 사람들이 서로 연결될 수 있는 방법을 제공하는 솔루션이다.

우모(Umoh)는 온•오프라인 커뮤니티를 연결하는 네트워킹 솔루션입니다. '사람과 사람을 더 빠르게 연결한다'는 비전 아래, 이벤트 참가자 간 효율적이고 지속적인 네트워킹을 지원하는 B2B SaaS입니다. 행사 기획부터 운영까지, 우모와 함께 성공적으로 진행해 보세요!

시작된 지 얼마 되지 않은 서비스인데 이미 국내와 미국의 상당한 행사에서 활용되고 있다고 한다. 이거 꽤나 흥미롭다. 아직은 나도 직접 사용해 본 건 아니라서 자세히는 모르겠지만, 홈페이지와 소셜 미디어에 올라온 안내와 글을 보니 이게 내가 생각해 온 네트워킹의 도구로 잘 활용될 수 있지 않을까 싶은 기대가 생겼다. 행사를 주관하는 단체에서도 그저 퍼블릭한 강의를 전달하거나 정해진 프로그램을 운용한 것으로만 끝나는 게 아쉽다면 이런 도구를 잘 활용해 봐도 좋겠다. 이런 행사의 주인공은 앞에서 발표를 하거나 주관하는 기업이 아니라 서로 연결될 가능성을 가지고 모인 참석자들이다. 그래서 이 서비스가 어떻게 발전하고 성장하는지, 사람들에게 어떤 영향을 주는지 지켜볼 생각이다.

많은 사람들이 좋은 연결점을 찾고 유익한 관계를 만들 수 있다면 조금 더 행복해지지 않을까.

https://umoh.io/kr

테스팅 프레임워크는 직접 만들어 써보자

PaxCaelo — Tue, 10 Oct 2023 11:08:55 +0900

기존 블로그에 있던 글 중에서 남기고 싶은 것들을 옮겨봐야겠다.

2008년에 쓴 글이다. TDDBE/테스트주도개발 책을 읽으며 가장 감탄하게 만들었던 xUnit 만들기에 관한 이야기이다.

한참 뒤에 라이브코딩으로 xUnit 만드는 걸 유튜브에 공개했다.

xUnit의 시초이자 자동화된 테스팅 프레임워크 붐의 기원은 잘 알려진 대로 JUnit이다. 물론 그 이전에도 여러 개발자들이 스스로 테스트 코드를 작성하기 위해서 여러 가지 툴을 직접 만들어서 사용했다고 한다. 하지만 JUnit처럼 공개된 단순한 프레임워크이면서 빠르게 많은 개발자들에게 영향을 주고, 실질적인 테스트의 가치를 느끼게 하고 테스트 작성을 실천하게 도와준 것은 없었다.

JUnit의 첫 버전은 Erich Gamma와 Kent Beck이 함께 97년 OOPSLA에 참여하기 위해서 쮜리히에서 애틀란타로 가는 비행기 안에서 작성되었다고 한다. 그 짧은 시간 동안 (그것도 노트북 배터리의 제한을 받아가면서) JUnit을 개발했다는 것이 잘 믿어지지 않을지 모르지만 사실이다.

JUnit was born on a flight from Zurich to the 1997 OOPSLA in Atlanta. Kent was flying with Erich Gamma, and what else were two geeks to do on a long flight but program? The first version of JUnit was built there, pair programmed, and done test first (a pleasing form of meta-circular geekery).

- XUnit

JUnit의 기원은 Kent Beck이 94년 즈음부터 만들어 써오던 SUnit이다. SUnit은 사실 어떤 특정 프레임워크를 지칭하는 것은 아니다. 스타일과 구조는 비슷할지 몰라도 Kent Beck은 매 프로젝트마다 그에 적합하게 테스팅 프레임워크를 만들어서 사용했고, 다른 개발자들도 그렇게 하기를 원했다.

There was no single kent-beck-smalltalk-unit-testing framework. Kent wants people to control their own environment, so he liked to have each team build the framework themselves (it only took a couple of hours), that way they would feel happy to change it to suit their particular circumstances – essentially it was really a Seedwork.

- XUnit

JUnit 문서에도 나와 있듯이 심플한 테스팅 프레임워크는 몇시간이면 개발이 가능하다. 물론 그 자체를 TDD로 개발하면서 말이다. 테스트주도개발(Test Driven Development by Example)에도 파이썬을 이용해서 xUnit을 TDD로 만드는 예제가 나와있다. 파이썬을 잘 아는 개발자라면 그것을 따라 하는데 한두 시간이면 충분할 것이다.

Kent Beck의 테스팅 프레임워크는 매우 간결하다. 그가 만들어 사용하던 테스팅 프레임워크는 초기부터 3개의 핵심 클래스로 구성되어있었다. 바로 TestCase, TestSuite, TestResult이다.

I wrote SUnit in 1994 I think.

…

I wrote this up as a little three class (TestCase, TestSuite, TestResult) framework with, I think, twelve methods. The clients were able to understand and use it (they still are to this day).

The framework was so simple that I couldn’t imagine that it had value, even though I thought it was aesthetically cool, so I gave it to the smartest programmer I knew and asked him to try it. When I didn’t hear back for a month I figured, “Okay, cool little idea but not big deal.”

- A Brief History of Test Frameworks에 나온 Kent Beck의 답변에서

이 간결함은 JUnit에도 그대로 이어져 오고 있다. 그 초기 디자인을 유지한 가장 최신 버전인 JUnit 3.8에 있는 문서에 나타난 JUnit의 핵심 클래스 구조에서도 여전히 3개의 클래스(Test Inteface가 그 연결역할을 해주기 위해서 들어갔지만)가 JUnit의 핵심인 것을 알 수 있다. 이 작은 핵심 클래스에 적용된 패턴들이란… ( ")!

- JUnit Cook’s Tour의 JUnit Patterns

JUnit의 정신은 심플함이다. 모든 개발자들에게 모든 상황에서 적용가능한 가장 최소한의 공통적인 기능만 제공한다는 것이 Kent Beck과 Erich Gamma의 JUnit에 대한 개발전략이다.

왜 그럴까? 그것은 처음 SUnit을 개발할 때부터 JUnit을 개발해 오는 지금까지 "개발자들이 자신의 환경을 직접 컨트롤할 수 있고 또 각 팀이 테스팅 프레임워크를 만들어 쓰는 것이 좋다(people to control their own environment, so he liked to have each team build the (testing) framework themselves)"는 철학을 가지고 있기 때문이다.

JUnit은 그 자체로 모든 것을 제공하지는 않고 오히려 그것을 쉽게 확장하고 자신의 프로젝트와 팀에 맡게 발전시킬 수 있도록 단순하고 유연한 모습을 유지하고 있는 것이다. JUnit의 사용하면서 종종 필요할지 모르는 일부 기능조차 extension이라는 별도의 패키지에 담아서 제공된다. 별로 사용하는 사람은 못 봤지만. 따라서 JUnit을 사용하는 개발자라면 적절히 그 기능을 확장하고 자신의 필요에 맞게 사용하는 작은 노력이 요구된다. 공개되어 있는 JUnit의 각종 extension과 addon은 적지 않다. 또 그것을 직접 확장해서 만드는 것도 매우 간단하다. JUnit을 직접 고치지 않아도 확장을 통해서 어떤 툴이나 IDE와도 손쉽게 연동할 수 있다.

JUnit을 잘 확장해서 사용한 좋은 예가 바로 스프링의 테스팅 프레임워크이다.

나는 개발자들이 이보다 더 나아가서 JUnit과 같은 테스팅 프레임워크를 직접 만들어보는 경험을 하는 것을 적극 권장한다. 물론 JUnit을 사용하지 말고 자신이 만든 것으로 대체하라는 말은 아니다. 뭐 못할 것도 없지만, IDE지원이 없으면 사용하기 불편할 것이다.

JUnit과 같은 테스팅 프레임워크를 직접 개발해 보는 것이 주는 장점은 여러 가지이다. 잘 알려진 xUnit 스타일의 개발을 먼저 따라 해보는 것을 권하고 싶다. TDDBE 책은 xUnit 프레임워크를 파이썬을 사용해서 TDD 방식으로 직접 만드는 과정을 매우 잘 설명해주고 있다. 나는 TDDBE를 처음 봤을 때 xUnit 프레임워크를 맨땅에서 TDD 방식으로 만드는 것을 보고 입이 쩍 벌어졌다. 그 이전에 TDD를 좀 안다고 생각했었음에도 상상도 못 했던 것이다. 그래서 나에게 TDD의 정신을 가장 확실하고 명쾌하게 느끼게 해 준 것이 바로 그것이다. Kent Beck은 새로운 언어를 학습하면 먼저 xUnit을 만들어본다고 한다. 물론 TDD로. 그 과정에서 그 언어에 대한 좋은 감각을 익힐 수 있음이 분명하다.

xUnit을 만들어보는 것은 TDD의 학습 자체에도 매우 큰 도움이 된다. 또한 xUnit에 나타난 다양한 디자인/구현 패턴에 대한 이해와 적용훈련도 될 수 있다. 내가 스프링의 소스를 보면서 또는 Rod Johnson의 초기 J2EE 책을 보면서 느꼈던 패턴의 적용에 대한 매력을 사실 JUnit 하나에서 거의 그대로 느낄 수 있었다. 다음은 JUnit에 적용된 패턴의 스토리보드이다. GML로 작성되어 있다. TDD를 통해서 자연스럽게 만들어지는 패턴에 대한 감각을 익히는데도 최고이다. Pluggable Selector와 같은 자바개발자들에게는 최근에 나온 Implementation Pattern에서나 찾아볼 수 있는 패턴도 이미 11년 전에 JUnit에 적용되어서 사용되었다.

- JUnit Cook’s Tour의 JUnit Pattern Storyboard

어제 기선이에게 xUnit을 한번 TDD로 만들어보라고 했는데, 오후 반나절 만에 뚝딱 다 완성하고 그 과정까지 블로그에 다 공개했다. TDD의 특성상 글로만 쓰기는 좀 그래서 조만간 스크린캐스트로도 공개할 예정이라고 한다.

TDDBE에 나온 xUnit 예제는 매우 간결한 편이고 자바에 그대로 적용하기에는 언어적인 차이 때문에 달라질 부분이 있다. 물론 처음엔 그대로 해봐도 상관없겠지만, 나중에는 JUnit 코드를 보고 따라 하는 것이 좋겠다.

JUnit의 소스는 4.0 이전버전을 참조하면 좋다. 3.x만 해도 벌써 이런저런 복잡한 변화가 있으니 그 이전버전을 소스를 참조해 보면 좋을 것이다. 처음에는 그냥 따라 하는 것을 두려워할 필요는 없다. JUnit 2.0부터는 JUnit 자체에 대한 테스트 소스가 함께 공개되는데 어렵사리 구한 JUnit 1.0에는 테스트 코드가 없는 것이 좀 아쉽다. 먼저 가장 단순하게 구현한 JUnit 1.0을 2.0의 테스트 코드를 참조하고(거의 비슷하다) TDDBE에 나온 순서를 잘 따라서 유사한 방식으로 만들어보면 좋을 것이다. 그리고 JUnit이 2.0, 3.0으로 바뀌면서 리팩터링 되고 추가된 기능들을 history 문서를 잘 보면서 비교해서 보도록 하자. JUnit의 발전과정을 잘 살펴보면 왜 "test"로 시작하는 테스트 메서드를 작성하게 되었는지 또 테스트 메서드는 public으로만 작성해야 했는지를 알 수 있을 것이다.

JUnit 소스는 내가 본 가장 심플하고 아름다운 코드 중의 하나이다. 이토록 짧은 코드를 통해서 이렇게 많은 것을 배울 수 있도록 해준 것은 JUnit 뿐인 듯하다. 스프링이 그다음.

2.0부터의 소스는 http://sourceforge.net/project/showfiles.php?group_id=15278&package_id=12472 에서 찾을 수 있다. 1.0은 http://members.pingnet.ch/gamma/junit-10.zip 여기에서 구할 수 있다. JUnit Cook’s Tour는 JUnit의 구조와 그 패턴에 관한 가장 잘 설명된 문서이다. JUnit을 만들어보는데 많은 도움이 될 것이니 필독.

JUnit 스타일로 프레임워크의 개발을 어느 정도 해봤다면 (1-2시간 정도로 충분히 된다 싶으면) 이제는 자신만의 테스팅 프레임워크를 자기의 감각으로 만들어보는 것도 좋겠다. JUnit을 의식하지 않고 스스로 테스팅 프레임워크를 창조적으로 만들어보는 것도 좋은 훈련이다. JUnit의 디자인 결정을 싫어하는 사람도 있다. 예를 들면 매 테스트마다 새 인스턴스를 만드는 것 따위말이다. 자신만의 더 나은 아이디어나 스타일이 있다면 그렇게 만들어보고, JUnit과 비교해 보는 것도 좋겠다.

테스팅 프레임워크는 프레임워크 기반의 접근방법(Framework Based Approach)을 배울 수 있는 가장 간단하고 좋은 예라고 생각된다. 또한 계층화된 프레임워크 구조와 확장포인트(extension point)에 대해서도 여러 가지 전략을 연습해 볼 수 있고. 따라서 프레임워크 개발자라면 반드시 한 번쯤 만들어봐야 할 것이다. FBA는 사실 Rod Johnson이 그의 책에서도 여러 번 강조한 것이다. 항상 프레임워크 기반의 접근방법을 사용하라라는 그의 주장이 잘 담긴 것이 바로 스프링이다. 스프링의 극대화된 유연성과 수많은 확장포인트들은 스프링 사용자들에게 스프링을 FBA 스타일로 사용하도록 권장하고 있다.

JUnit은 4.0에 들어서 획기적인 변화를 가져왔다. Java5의 언어의 변화를 받아들여 좀 더 사용하기 편하고 단순한 프레임워크로의 변신을 하게 된다. 사실 그 변화는 매우 중대한 것인데, 그 이전의 JUnit의 모든 디자인과 구조를 바꾸었기 때문이다. 어노테이션의 적용은 언어의 특징을 매우 크게 바꾸는 결과를 가져왔다. 덕분에 JUnit을 사용하기는 좀 더 편해졌지만 기존 디자인은 대부분 버려야 했고, 프레임워크 자체는 매우 복잡해졌다. JUnit팀은 4.0을 개발하는 과정이 상당히 즐거운 것이라고 하긴 했지만 이전의 심플한 OO스타일이 잘 녹아있는 JUnit은 4.x에선 사라져 버렸다. (물론 3.8 스타일의 패키지는 여전히 포함되어 있다). JUnit 4.0으로 가면서 변한 것과 여전히 유지하고 있는 것이 무엇인지, 그 과정에서 배운 교훈과 고민은 무엇이었는지는 Kent Beck의 JavaOne 발표를 들어보기 바란다.

JUnit 4는 얼마 전 4.5가 릴리즈 되면서 매우 빠르게 발전하고 있다. 한동안 정체되어서 프로젝트가 죽은 게 아니냐는 이야기를 들었던 JUnit이 맞나 싶을 정도로 그 발전과 변화가 빠르다. 특히 4.4에서의 다양한 변신은 JUnit을 더욱 매력적인 방법으로 확장해서 사용할 수 있도록 도와주고 있다. 스프링의 JUnit 4 Test가 그 좋은 예다.

주말쯤 해서 자신만의 테스팅 프레임워크를 만들어보고 공개해 보는 것이 어떨까? 또는 같은 개발팀의 개발자들과 함께 짝프로그래밍으로 팀을 위한 테스팅 프레임워크를 만들어보는 것도 좋겠다.

아티장 프로그래머

PaxCaelo — Sat, 7 Oct 2023 06:14:47 +0900

로버트 마틴의 대표작인 Clean Code의 부제는 A Handbook of Agile Software Craftsmanship이다. 애자일 소프트웨어 장인정신의 안내서. 그런데 여기서 craftsman이 성차별(sexism)적인 단어라서 이 책을 싫어한다는 글을 본 적이 있다.

나는 원래 장인을 뜻하는 단어 중에서 artisan을 좋아한다. 코딩과 함께 은퇴 후에도 계속해보고 싶은 건 빵을 만드는 일이다. 전통적인 방식을 따라서 멋진 빵을 만드는데 필요한 과학적인 지식과 섬세한 기술, 오랜 경험을 갖춘 숙련된 제빵사를 artisan baker라고 부른다. artisan은 뭐랄까, 무엇인가 만들어내는 일에 대해서 보다 예술적인 추구를 하는 사람을 가리키는 말이 아닐까 싶다. 누군가 사용/식용할 수 있는 무엇인가를 만들어내는 일에 대한 가장 진지한 태도를 가진 사람.

그래서 오래전부터 어떤 개발자라면 artisan 장인이라고 부를 수도 있겠다고 생각을 해왔다. 근데 최근에 김창준 님의 오래된 글을 하나 읽다가 '장인(artisan)으로서의 프로그래머'라는 이야기를 보고 몹시 반가웠다. 내가 생각해 왔던 장인 개발자의 모습에 대한 구체적인 설명이었다.

이 글에서 프로그래머, 프로그램을 제빵사와 빵이라고 바꿔도 자연스럽다. 전통적인 제빵 기법을 이용해서 만드는 사워도우 열풍을 일으킨 샌프란시스코의 타르틴 베이커리 설립자 채드 로버트슨은 끊임없이 세계 여러 곳에서 재배되는 다양한 곡물을 사용해서 빵을 만들어보는 연구를 하고 있다. 새로 발견하고 연구한 빵의 맛과 향, 제작 과정 등을 책을 통해서 공유하기도 한다. 본인을 그렇게 소개하지는 않지만 진정한 artisan baker다. 내가 여러 번의 실패 끝에 처음으로 천연효모를 이용한 사워도우를 만들어 낸 건 그의 책 덕분이기도 하다.

다음에 명함을 만들면 뻔한 타이틀 대신에 아티장 개발자. 혹은 아티장 프로그래머라고 넣고 싶다. 물론 자신을 artisan이라고 부르려면 아직도 더 훈련과 노력이 필요하겠지만.

Artisan은 영어로 발음하면 아티잔일 텐데 원래 불어 발음으로 적으면 아티장이 된다. 비모음의 표기법을 따른 것이다.

아티장 프로그래머. 내 다음 책 제목으로 정했다. 출판사에서는 그런 제목으로는 안 된다고 하겠지만. 부제로라도 넣어달라고 해야지. 아티장 프로그래머를 위한 안내서.

아래는 인터넷에서 찾은 김창준 님의 프로그램, 프로그래밍, 프로그래머라는 글의 일부이다. 2001년에 작성된 글이다.

== 과학자, 장인, 예술가 ==

앞서 설명한 표현 양식과 언어와 사고간의 관계 등을 고려해 볼 때 다양한 패러다임의 언어를 안다는 것(비슷비슷하거나, 자체의 일관된 철학 없이 수많은 기능만 끌어 모은 소위 '강력한' 언어는 별 도움이 안 된다)은 문제 해결자들에게 엄청난 무기가 될 수 있다. 이것이 필자가 말하고자 하는 '장인(artisan)으로서의 프로그래머'다.

자신의 몸의 훈련을 통해 도구를 마치 몸의 연장(延長)처럼 만들되, 하나의 도구에만 종속되지 않으며 재료에 알맞게 다양한 도구를 선택할 수 있어야 한다. 또한 자신이 만드는 프로그램 하나하나에 누가 감시하든 말든 성실하게 최선을 다하고 그것을 내 몸과 같이 아끼고 사랑할 수 있어야 비로소 '장인으로서의 프로그래머'가 될 수 있다.

이와 동시에 프로그래머는 예술가(artist)의 역할도 할 수 있어야 한다. 다익스트라는 "아름다움이 우리가 하는 일이오(Beauty is our business)"라는 명언을 남겼고, 크누쓰 교수의 기념비적 저서 「TAOCP」에도 예술(art)이라는 말이 들어간다 [주: 영어에서 art는 기술이라는 의미로 쓰이기도 하지만 크누쓰는 분명히 미적 가치를 추구하는 예술임을 밝히고 있다]. 과학우선주의 사회에서는 이런 예술이나 기술과 같은 것은 저열한 것으로 치부되고, 그것을 과학화해야 비로소 자랑스러워하는 경향이 강하다.

하지만 아인슈타인의 말대로 "수학의 법칙들이 현실을 언급하는 이상, 그것은 확실하지 않고 그것이 확실한 이상, 그것은 현실을 언급하지 않는다"는 사실을 기억해야 할 것이다. 프로그래밍이라는 것은 자연과학이 될 수 없다. 인간이라는 요소가 개입되기 때문이다. 결국 크누쓰가 말하는 것처럼 우리는 '아름다운 프로그램(beautiful program)을 만드는 심미적 목적을 가질 수밖에 없는 것이다.

물론 과학자로서의 프로그래머를 무시할 수도 없다. 비록 이론이 모두 적중하지 못하더라도 탄탄한 이론적 바탕은 우리의 수많은 시행착오를 절약할 수 있게 해준다. 분석적이고 논리적인 냉철한 사고를 갖고, 예술가로서의 감수성과 심미성을 추구하며, 자신의 몸 공부가 경지에 이른 장인이 바로 이 시대가 원하는 프로그래머일 것이요, 이 프로그래머가 역시 진정한 엔지니어의 요구사항을 충분히 만족시킬 수 있을 것이다.

사진 출처는 https://www.vogue.com/article/rising-star-chad-robertson-of-san-franciscos-tartine-bakery-cafe

작곡

PaxCaelo — Sat, 30 Sep 2023 20:42:50 +0900

https://youtu.be/rbSAIwBGCPA?t=1541

고1 때 작곡 공부를 시작하고 나서 두 번째로 만든 노래. 이 곡으로 친구가 기독교 창작곡 대회 본선에 진출했다. 정식으로 발매된 음반에도 실렸다.

친하게 지내던 친구가 어느 날 가사가 적힌 종이를 건네주면서 곡을 만들어달라고 했다. 당시 공부는 안 하고 맨날 기타만 친다고 아버지한테 혼나던 터라 틈을 내기가 쉽지 않았다. 아버지한테 걸리지 않으려고 어쩔 수 없이 새벽에 일어나 소리가 나지 않게 이불 뒤집어쓰고 조용히 기타를 치며 악보를 그렸다. 곡은 거의 하루 만에 완성했다. 나중에 듀엣으로 부를 수 있게 편곡하고 반주자를 위해서 피아노 악보도 만들었다. 녹음에 참여하는 밴드에게 연주 방법을 요청하는 글도 작성해서 전달했다. 대회에선 수상은 못했지만 후에 심사위원들이 내 곡이 좋다는 칭찬을 했다는 얘기를 들었다.

그 뒤로 친구들 요청으로 이런 저런 곡을 많이 만들었다. 곡을 쓰면서 화성의 흐름을 만들어 내는 게 재미있었다. 어렸을 때부터 코딩하며 느꼈던 것과 비슷한 쾌감이 있다. 소리가 정상파 속에 배수로 떨어지는 배음이 만들어지고 그것이 쌓였을 때 여러 가지 느낌의 화음이 만들어진다는 원리를 알고 나서는 더욱 빠져들었던 것 같다. 화성의 흐름은 긴장과 해결의 연속이다. 전통적인 4 성부 화성학은 거의 기계적으로 가져다 넣을 수 있을 정도로 긴장을 만들고 이를 해결하는 원칙이 분명했다. 근데 그걸 깨서 긴장을 해소하지 않고 유지하는 방식으로 텐션을 주는 재즈 화성도 좋았다. 나중에 대회를 주관하는 팀에서 초빙한 전문가가 후렴부를 앞에 넣으라는 의견을 주셔서 달라지긴 했지만 원곡은 4도로 시작하는 나름 흔치 않은 방식으로 만들었다. 전주에서 G-F-Eb로 떨어지는 것도 내가 흥미롭게 연습해보고 있던 약간은 몽환적인 코드 진행이었고.

80년대 후반이었으니 악보 그리는 프로그램 따윈 없었다. 그래서 항상 손으로 악보를 그렸다. 오선지가 없으면 줄도 그어가면서. 곡을 처음 쓸 때는 계속 고쳐야하니 연필로 그렸지만 완성된 후에는 펜으로 깔끔한 악보를 만들어야 했다. 틀리면 고치는 방법도 여러 가지 연구해서 사용했다. 초반엔 화이트를 주로 썼지만 그보다는 다른 종이를 잘라서 위에 붙여 넣고 다시 그리는 게 효과적이었다.

처음 시작은 중3때 음악 선생님의 권유였다. 음악 시간에 시킨 시창, 청음을 완벽하게 했다는 이유였는지, 어느 날 부르시더니 나에게 작곡을 전공하라고 권유하면서 공부를 시작할 수 있게 기초화성학 책을 소개해주었다. 그래서 중3 겨울에 4 성부 화음을 다루는 화성학 책을 공부하기 시작했다. 그런데 왜 그렇게 재밌었는지 정말 푹 빠져들었다. 고등학교 들어가서는 재즈화성이나 경음악 편곡 따위를 공부하면서 슬슬 곡을 만들어보기 시작했다.

내가 만든 게임 프로그램을 집에 놀러온 친구들이 즐기는 모습이 좋았던 것처럼 내가 만든 곡을 주변 사람들이 부르는 게 좋았다. 그렇게 즐겁게 작곡을 하던 게 시들해진 건 군악대 시절이다. 선임들의 강압적인 명령으로 군악대에서 사용할 악보를 수시로 그리고, 행사 지원 나갈 때마다 요청받은 곡을 브라스 밴드용으로 편곡하고 그러는 게 일상이 되니 오히려 재미가 없어졌다. 마지막으로 만든 곡은 주임 원사의 요청으로 만든 사단 하사관 단가. 그리고 손을 놓은 지 30년이 지났다.

일을 하면서 유튜브에 올라온 연주곡을 많이 듣는 편이다. 그러다 오늘 본 한 음악 영상에는, 모든 곡을 자기가 다 만들고 편곡한 거라는 설명이 달려있었다. 유명한 사람은 아닌 듯하고 아마도 취미로 곡을 쓰고 피아노 연주를 하는 분 같다. 곡이 너무 편안하고 부드럽고 상냥해서 그런가, 그냥 배경 소음 정도로 켜놓았는데 음악에 끌려 자꾸 집중하게 됐다. 그러면서 갑자기, 나도 다시 곡을 만들고 연주를 해서 사람들에게 들려주면 어떨까 하는 생각이 들었다. 영상도 찍고 연주한 곡을 넣어서 가볍게 유튜브 채널을 만들어볼까, 뭐 그런 생각.

어릴 때는 뭐가 됐든 내가 만든 것을 선물하기를 좋아했는데 요즘은 선물이 필요하면 남들이 만든 것 중에서 고른다. 그나마 가까이 있는 사람들에게는 가끔 빵을 구워서 선물하기는 하지만. 세상에 하나 밖에 없는 곡을 만들어서 선물할 수 있다면 어떨까.

PaxCaelo 관성을 거슬러서

PaxCaelo — Wed, 27 Sep 2023 07:02:43 +0900

생계를 위한 수단이 아닌 창작 활동에는 관성이 강하게 적용된다. 관성은 우주에 빌트인된 현재 상태를 유지하려는 수동적인 속성이다. 예외는 없어서 법칙이라고도 부른다. 일정하게 운동하고 있는 물체는 다른 힘을 가하지 않으면 그 운동을 계속한다. 반면에 멈춰있는 물체는 힘을 주지 않으면 그대로 멈춰있다. 저절로 상태가 변하지 않는다.

20년 전 블로그를 처음 만들었고 10여년 간 열심히 블로그에 글을 썼다. 그때 알았다. 블로그는 관성으로 한다는 것을. 아침마다 힘겹게 일어나 출근을 하는 건 그러지 않으면 상사나 고객이 화가 날 거고, 내 생계가 막막해질 수도 있다는 절박함이 있어서다. 하지만 아침에 블로그 글을 쓰는 건, 그저 어제 썼기 때문이다. 그제도 쓰고, 지난주에도 쓰고. 아침에 기술 뉴스 사이트를 훑어보다가 이거 재밌는데 싶으면 어느새 블로그 글쓰기 창을 열어 내용을 옮기고 내 의견을 더한다. 빠르면 5분, 길어도 10분이면 후다닥 한 편 끝. 한번 빠르게 적은 글은 다시 읽지 않는다. 맞춤법이든 띄어쓰기든, 단순 오타든 누가 와서 지적하기 전엔 별 신경도 쓰지 않았다. 왜냐하면 청탁 원고나 저술을 할 때처럼 정성을 기울여 쓰면 글을 남기던 관성에 외력이 가해져 점차 느려지고 결국엔 손을 놓게 될 걸 알았기 때문이다. 아침에 양치하듯이 별생각 없이 습관적으로 하는 게, 나같이 게으른 사람에게는 관성을 유지하는 길이라는 걸 알았다.

그래도 삶의 작은 마찰이 쌓이면 서서히 관성을 잃고 결국 글 쓰기를 중단한다. 한번 멈추게 된 것은 계속 멈춰있으려는 관성 때문에 다시 시작하는데 큰 힘이 필요하다. 그렇게 몇 달을 쉬다가, 컨퍼런스에 참석해서 두근거릴 정도의 큰 인사이트를 얻었다거나, 너무 재밌는 기술을 발견해서 나만 알고 있기가 너무 아깝다거나, 내가 좋아하는 기술에 대해서 저따위 헛소리를 하다니 싶은 글을 발견했다거나, 아니면 너무 외로움이 크게 느껴질 때 다시 글을 쓰기 시작했다.

결국 관성을 깨고 움직이려면 외부의 자극이 필요하다. 작은 자극이면 된다. 그게 내 안에 쌓아두었던 분출하고 싶었던 감정이나 생각, 나누고 싶은 지식 등을 꺼낼 수 있는 명분을 만들어주면 다시 움직인다.

하지만 내 책의 2판이 나온 2012년 이후로는 블로그를 방치했다. 전혀 글을 쓰지 않았다. 그러다 몇 년 전 블로그가 돌던 서버가 고장났고 백업 파일은 날아갔고, 에라 모르겠다 하고 정리해 버렸다. 몇 가지 이유가 있겠는데, 가장 큰 건 책을 쓰면서 내 생각을 바닥까지 꺼내기만 했지 채우지는 못했다는 억울함이다. 내가 더 이상 할 얘기가 없는데라고 생각할 정도로 1700페이지 넘게 끄적여놨으니 이젠 충분하다고 생각했겠지. 또, 페이스북과 같은 소셜 미디어를 통해서 가볍게 생각을 꺼내놓을 수 있었던 것도 영향이 있었을 것이다. 전에 블로그에서 그랬듯이 정제하지 않은, 그냥 넘어가고 싶지 않았던 생각 정도는 거기에 가볍게 흘리면 됐다. 어떨 땐 한 문장으로 끝나도 뭐라 할 사람도 없었고. 페이스북은 검색도 잘 안 돼서 남들이 볼까 하는 부담도 덜하다. 2000년대 초반에 쓴 블로그 글이 2010년대 중반까지 다른 사람들에게 회자됐던 건 다 그놈의 구글 검색 탓이다.

2000년 초반 웹 2.0 운동과 함께 인기를 얻었던 블로그 문화는 본격적인 소셜 미디어 플랫폼의 등장과 함께 점차 사그러들다가 2010년대 중반 이후 새로운 분위기의 플랫폼을 타고, 또 취업에도 도움이 되는 자기 컨텐트를 쌓고 싶은 개발자들의 관심을 받으며 다시 활기를 띄는 듯하다. 한때 전문가들이 블로그 시절은 끝났다고 얘기한 게 무색할 정도다.

남들이 어쨌 건 나는 관성으로 계속 멈춰있었는데.

얼마전부터 블로그에 글을 다시 쓰고 싶어졌다. 재미없는 내 일상을 남기는 웹로그를 하고 싶은 건 아니다. 그런 건 간단한 소셜 미디어가 있으니까. 그보다는 그냥 글을 쓰고 싶어졌다. 다나카 히로노부의 책을 다시 읽어서 그랬는지도 모르겠다. 내가 즐거워서 쓰는 글을 쓰고 싶고. 누군가에게 해주고 싶은 이야기가 있으면 남기고 싶기도 하다. 명분을 만들 자극이 필요했는데 최근 그런 영향을 주는 사람을 만나기도 했다.

서버가 또 날아가면 안 되니까. 이번엔 설치형 대신 클라우드 플랫폼을 선택했다. 쓰고 싶은 주제도 하나둘씩 메모해두고 있다. 멈춰있는 관성을 거슬러 일단 시작하면 운동하는 관성이 도와줄 테니까 한번 힘을 내서 시작해 보자.

티스토리가 다 좋은데 블로그 작성자 닉네임이 고유해야 한다는 문제가 있다. 내 이름인 Toby, 토비 다 뺐겼네. 그래서 PaxCaelo라고 하기로 했다. 팍스카엘로. 평화와 하늘이 이름을 라틴어로 적은 것이다. 내 가족신탁(family trust) 이름이기도 하다. 꽤 오랫동안 닉네임 없이 공식 영문 이름인 Toby를 써왔으니 이참에 닉네임도 하나 써보려고.

블로그 이름은 예전 그대로 Toby’s Epril이다. Epril은 파퓨아 뉴기니어로 4월이라는 뜻이다. 영어 기반의 혼성어(creole)라서 April과 비슷하다. 내 생일이기도 하고, 봄이기도 하고. 토비의 4월 혹은 토비의 봄. 내 회사 이름도 Epril이다.

그럼 시작해볼까.