클린 스프링 - 인프콘 2024

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

 

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

 

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

 

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

 

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

 

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

 

깔끔한 코드를 작성하는 것은 스스로를 전문가(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 다시보기 강의 | 인프런 - 인프런

 

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

 

친절하자

 

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

 

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

 

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

 

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

 

 

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

 

 

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

 

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

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

 

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

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

 

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