<켄트 벡의 Tidy First?> 역자 북토크 Q&A
설계: 생각을 ‘차려’ 물질로 만드는 힘
어제 한빛미디어 리더스홀에서 <켄트 벡의 Tidy First?>를 번역하며 알게 된 것들 행사를 즐겁게 마치고 왔습니다.
그야말로 홍콩(?) 같은 더위에 잘 준비된 무대 위에서 평일 퇴근 후에 오셔서 집중해서 들어주시는 청중 앞에서 발표하는 일은 도리어 제가 에너지를 얻어가는 기분이었습니다. 그 고마움에 작게나마 보답하려고 30분 남짓 진행한 Q&A의 시간 제약[1] 때문에 빠트렸을 수 있는 내용을 보완하기 위해 구글 닥스의 사전 질문과 Sli.do의 현장 질문에 대해 다시 글로 답을 남겨 볼까 합니다.
두꺼운 책은 아니지만 읽은 후의 내용이 휘발되기도 쉬울 것 같은데요 역자님이 생각하시는 이 책을 활용하고 내용을 체화할 수 있는 가장 좋은 방법이나, 아직 읽지 않은 사람이 있다면 어떤 방식으로 읽으면 좋을지 권해주실 수 있을까요?
1부에 중점을 두고 읽으시기를 권합니다. 그리고 반드시 자신이 작성한 코드와 연결 지어서 책 내용을 소화하실 것은 권하고 싶습니다. 1부 내용에 대해 절차 기억(손발이 함께 기억하기)이 없다면 사실상 2부는 소용없는 내용입니다. 그런데, 경험 부족으로 1부의 15가지 코드 정리법을 내 코드에서 발견할 수 없다면, github에서 관련 내용을 찾아보고 내 경험으로 흡수하는 방법을 권합니다. 그런데, github에서 어떻게 찾아야 할지 모르겠다면 다른 개발자와 협력하여 공부하시길 권합니다.
주변에 코드 정리에 관심을 두는 개발자가 없다면 한국 Tidy First 모임 커뮤니티를 이용하세요. 지금은 조용한데, 조만간 함께 책 읽는 모임이 발족하면 교류할 수 있을 겁니다.
번역하시는 과정에서 어떠한 도전과제가 있었는지 가장 어려웠던 점은 어떤 게 있을까요? / 안녕하세요. 저도 언젠가는 해외에 출판되어 있는 클라우드 관련 서적을 번역을 해보는 것에 관심이 있는데 혹시 어떤 과정을 거쳐서 책의 번역 작업을 하게 되셨는지 여쭈어봐도 될까요?
책 한 권 분량 번역은 처음 하는 일이며 본업이 회사 경영이라는 시간을 쪼개서 완주하는 일이 가장 어려운 일이었습니다. 그래서, '지속 가능하게 만드는 장치'를 사전에 만들었습니다. 먼저 스스로의 비전을 분명하게 했습니다. 번역서 부록에도 있지만 '다시 켄트 벡의 말들을 만나 성장 속도를 높이고 싶다'는 목적을 명확하게 했습니다. 그럼에도 불구하고 부족한 시간과 역량을 채우기 위해 에드워드 요던에 대한 존경심을 갖고 있고 더불어 번역에 대한 애정도 많으신 Charlie 님을 초반부터 베타리더로 초대했습니다.
여기에 더하여 공개적으로 베타 리더 모집을 초기부터 하고 초안 작업을 구글닥스에서 공유하고 일정과 진척도 모두 공개했습니다. 이렇게 하니 십시일반 도와주시는 분들도 주체적이 되고, 그분들의 기여 덕분에 책임을 진 제가 게을리할 수 없었습니다.
'성장'이라는 키워드를 어떻게 정의하시는지 궁금합니다. 저는 공식문서/책/강의/컨퍼런스 등을 통해 공부를 하고 인사이트를 얻곤 하는데요. 역자님께서는 베터코드를 이끌면서 수많은 주니어/시니어/리드/CTO 분을 면접 보거나 같이 일해보셨을 것 같은데, 특정 구간 또는 해당 직급에서 정의하는 '성장'이라는 의미가 다른지, 다르다면 어떻게 다르고 어떤 걸 중요하게 봐야 되는지 궁금합니다.
성장이라는 키워드를 특별히 생각해 본 일이 없네요. 항상 무언가 개발(develop)하는 삶을 살다 보니 굳이 따로 성장을 고민할 필요가 없었던 것이 아닌가 싶습니다. 아마 안정적인 조직에 몸을 담고 있으면 저와는 입장이 달랐을 것이라 생각하지만, 저는 그런 경험이 없어서 답변하기 어렵네요. 다만, 저에게 성장은 결국 (자기) 개발의 연속이었다고 말할 수 있습니다.
직급 별 성장에 대해서는 말할 수 있을 듯합니다. 함께 일하는 사람이 늘거나 책임지는 범위가 늘면 이를 다루는 방법이 바뀌며 도전 과제가 생깁니다. 혼자서 코드를 잘 짜는 일로 문제 해결이 되지 않을 때는 인간관계에 대해 깊이 고민하게 됩니다. 개인적으로는 마흔이 넘어서야 '개취 인정'의 경험을 통해서 함께 일하는 모두가 각자의 개성 속에서 일할 때 최고의 결과가 나온다는 사실을 깨달았습니다. 그리고 사업을 책임지는 사람과 소통하는 역할을 하게 되면 또 시장과 가치, 고객의 의미를 알기 위해 귀를 기울이는 법을 배워야 합니다. 그런데 이들은 사전에 노력해서 준비하는 일이 아니라 오늘의 시간에 정성을 다하는 일로 만들어진다고 생각합니다.
제 연차(4년 차)에서 이것저것 도입하고 공부해 보는 게 좋은 건지, 아닌지 궁금합니다! 아직 충분하지 않지만 3년 동안 백엔드/프런트 가리지 않고 기능개발 위주(서비스 플랫폼)로 했었는데요. 작년에 도커/쿠버네티스/카프카를 현업에서 사용하게 되어 공부했고 현재는 APM(프로메테우스, 그라파나), CI/CD(github actions, jenkins) 등 운영에 관심을 가지게 되었습니다. 저는 한 분야만 깊게 파는 것도 좋지만 개발 전체적인 관점에서의 다른 분야까지 경험해 보는 게 좋다고 생각합니다. Java Spring을 해왔다면 Kotlin Spring도 해보고 Go, Flutter 등 새로 나온 언어도 공부하기 같은 것들이요. 나중에 시니어가 되면 팀 매니징, 팀 빌딩을 해야 하고 가정이 생기기 때문에 이것저것 공부할 시간이 부족할 것도 같다고 생각합니다. 현재 제 연차에서 이것저것 도입하고 공부해 보는 게 좋은 건지, 아닌지 역자님의 고견이 궁금합니다!
잘하고 계신다고 말씀드리고 싶습니다. 다만, 기술 선택의 문제에 있어서는 판단 기준을 구체적으로 갖고 있을수록 시간을 아끼고 효과도 높다고 말씀드리고 싶습니다. 다시 말해 스스로 다루기 쉽고 애정을 가진 코드 덩어리를 기준으로 흥미를 갖게 하는 코드를 적용해 보는 방법으로 채택 여부를 판단하는 방법을 제안드리고 싶습니다.
한편, 혼자서만 공부하기보다는 피드백을 받기 위해 다른 사람을 가르쳐 보는 방법을 제안합니다. 최근에 개발자 교육계의 스타로 부상한 백기선 님이나 김영한 님의 경험을 보아도 배운 것을 남에게 설명하는 과정에서 많이 성장했다는 점으로 근거를 추가합니다.
켄트벡의 사상을 좋아하는 사람입니다. 그런데 이 책의 글을 읽다 보면 저자가 무엇을 말하려는지 명확하게 알 수 없을 때가 있습니다. 중간에 엉뚱한 문장이 들어있는 느낌인데 번역을 잘못했다기보다는 원문 자체의 표현이 그렇지 않았을까 생각이 듭니다. 문화 차이로 인한 표현방식이 달라서 인지는 모르겠지만 번역에 어려움이 많았으리라 생각이 듭니다. 겐트벡님이 좀 모호하게 표현하고 있다고 생각이 들지는 않으셨는지 궁금합니다.
문화적으로 이질적으로 느껴지는 부분은 링크드인으로 켄트 벡과 소통하면서 최대한 번역에 담아내려고 노력했습니다. 다만, 그럼에도 불구하고 켄트 벡이 함축적으로 쓰는 부분이 있다고 생각합니다. 그런데 그 부분은 경험의 차이에서 비롯하는 것이라 켄트 벡의 현재 방식이 최선이라고 생각합니다. 그가 아니면 책으로 나올 수 없는 내용이니까요. :)
저는 옮긴이 노트를 굉장히 인상적으로 읽었는데, 질문 한 땀 한 땀에서 많은 고민이 느껴졌습니다. 켄트벡과 나눈 질문 중에는 번역과정에서 함께 고민한 다른 이들도 있던 것 같은데 그분들은 혹시 동료일까요?
회사 일로 번역한 것이 아니라 직장 동료는 아닙니다. 하지만, (같은 가치관을 지닌) 동료라고 생각했으니 베타 리더를 제안하고 함께 했겠죠.
책을 끝까지 읽어보지는 못했지만 서문이 인상 깊었습니다. 궁금한 점은 '경험과 사고'입니다. 재밌거나 힘들었던 경험을 2가지 관점으로 질문합니다.
1. <켄트 벡의 Tidy First?> 역자
2. 프로그래머의 삶
역자로서는 애초에 번역을 안 했으면 정독을 안 했을 것이라는 저에 대한 예측에 의해 번역 초기에 이미 정독이 끝났다는 점이 흥미로웠습니다. 하지만, 정독이라는 제1 목표 달성 이후에 몇 배의 시간을 번역서라는 완성품을 내놓기 위한 시간이 필요했다는 점입니다. 여기서 내가 기대했던 것을 얻기 위해서는 생각하지 못했던 노력을 비용으로 지불해야 한다는 사실을 배운 것이 큰 것 같습니다.
두 번째로 프로그래머의 삶에 대해서는, 여전히 개발자들과 일하지고 제품 개발과 관리에 관여하지만, 직접 코드를 작성하지 않아 왔는데요. 개발자를 위한 책을 번역한 계기로 다시 코드와 친해지는 데에 약간의 시간을 들이게 되었습니다. 회사를 운영하면서 시간 운영에 대한 요령이 생겨서 앞으로 제한적이나마 프로그래머로서의 삶도 병행하고자 합니다.
다음은 sli.do 질문입니다.
책이 나오기 전에 온라인에서 훑어보고 정독을 위해 번역을 할 것인가 말 것인가를 결정했습니다. 그래서, 책을 다 읽은 시점은 번역 중간쯤이었습니다. 흔히 독자들이 접하는 방식이나 경험과는 사뭇 다르죠.
아래 그림은 제가 책을 보고 그린 그림에 더하여 질문하는 내용을 대응시켜 본 것입니다. 코드 정리는 개발자의 일상 작업 속에서 설계(구조화)를 다루는 가장 경제적인 작업 단위를 다루고 있습니다. 그야말로 Fundamental이라고 할 수 있는 테크닉이죠. 하지만, 시스템은 우리가 사는 자연처럼 유기체적으로 복잡하게 얽혀 있습니다. 다양한 범주가 있고, 각 단계 별로 상이한 힘(?)이 작용합니다.
그래서 '벡엔드와 프론트엔드는 어떻다'라는 형식의 모호한 분류는 마치 보수와 진보의 구분처럼 모호한 이야기로 그칠 가능성이 높다고 생각합니다. 그래서, 코드 정리법은 어떤 코드를 다루든 아주 기본적인 사항을 탄탄하게 익히는 데에 초점이 있다고 할 수 있습니다.
이건 현장에서 즉답을 못했는데, Gemini에게 물어보니 그럴싸하게 답해 주네요. :)
아니요. 코드 정리는 1부의 범주를 벗어나는 규모 혹은 비가역성을 지닌 리팩토링은 다루지 않습니다. 아마도 그런 변경은 다음에 나올 책 <Tidy Together?>에서 다룰 듯합니다.
주니어라면 더 많은 경험을 통해 나의 한계를 만나고 도전하고 성취감(혹은 작은 좌절 극복)을 맛보시라고 하고 싶습니다. 기술 서적은 최근 책은 아니고 Tidy First? 외에는 XP 책을 권하고 싶습니다.
AI와 개발자 취업 시장에 대해서는 그 분야 전문가가 아니라 조심스럽지만, 최근 경험한 하나의 현상을 말한느 것으로 답을 대신하겠습니다. 한빛 팀장님 한 분이 전해 주신 이야기가 있는데요. 주니어 개발자가 코파일럿 사용으로 짠 코드에 대해 시니어가 '왜 이렇게 짰냐?'라고 물었더니, 로직에 대해 답을 하지 못하고 '코파일럿이 이렇게 만들었고, 잘 돌아간다.'라고만 답했다고 합니다.
저는 그런 분들은 일자리를 잃기 쉽다고 말씀드리고 싶습니다. 최근 개발 팀장급에 있는 지인 두 명이 저에게 코파일럿을 예찬(?)하면서 주니어 고용 없이 더 많은 작업을 할 수 있다고 흥분해서 이야기하는 것을 들은 일이 있기 때문입니다. 이제 프로그램 작동 원리를 이해하고 구성을 정의할 수 있다면 내용물을 채우는 일은 인공 지능이 꽤나 잘 해내기 때문에 거꾸로 작동 원리나 구조적 이해가 없다면 알파고와 경쟁하는 바둑 기사의 처지가 되지 않을까요?
관리자로 적용하고 있지는 않습니다. 은유적으로 '정원관리'를 하고 있긴 하죠. 그보다는 역자로서 이번 발표처럼 책의 맥락을 소개하면 많은 개발자들이 일상 기술로 코드 정리를 익히시길 바라며 보급하고 있기는 합니다.
주석
[1] 30분에 15개 질문에 답해야 하니 질문 당 2분이고, 질문 중에 반이 넘는 8개는 즉흥 질문이었습니다.
지난 설계: 생각을 ‘차려’ 물질로 만드는 힘 연재
1. 내가 아닌 다른 사람은 모델링을 왜 하게 되는가?
4. 설계가 잘 쓰이려면 독자와 쓰임새가 분명해야 한다
7. Event Driven의 기원과 현실적인 활용 방법
