Refactoring.fm

Martin Fowler Interview

[마틴] 물론 주니어 개발자의 가장 중요한 특성 중 하나는 그들을 시니어 개발자로 키울 수 있다는 사실입니다. 그리고 그것이 모든 조직에 필요한 핵심적인 것 중 하나죠. 조직 내에서 더 많은 인력을 길러낼 수 있는 능력이 필요합니다. 제 말은, 쏘우트웍스(ThoughtWorks)에서 우리의 가장 큰 강점 중 하나는 항상 가능성 있는 주니어들을 정말로 뛰어난 시니어 인재로 성장시키는 데 매우 능숙하다는 것이었습니다. 그리고 그것이 핵심 강점이죠. 음, 내부적으로 우리가 여전히 그 가치를 인정하고 있다는 점을 기쁘게 생각합니다. 왜냐하면 끊임없이 변화하는 기술의 역할을 활용하는 법을 배워감에 따라 미래에는 이것이 점점 더 중요해질 것이기 때문입니다. 그리고 다른 조직들도 이 점을 살펴봐야 한다고 생각합니다. 경험이 적은 소프트웨어 개발자가 가진 가장 중요한 가치는 그들을 더 경험 많고, 여러분의 도메인을 이해하며, 여러분이 속한 기술 환경을 어떻게 활용할지 아는 사람으로 성장시킬 수 있는 능력입니다.

[루카] 안녕하세요, 루카입니다. 리팩토링 팟캐스트의 새로운 에피소드에 오신 것을 환영합니다. 저희는 2주마다 세계에서 가장 뛰어나고, 사려 깊으며, 성공한 기술 리더들을 인터뷰합니다. 오늘의 게스트는 정말 소개가 필요 없는 마틴 파울러입니다. 마틴은 쏘우트웍스의 수석 과학자이며, 애자일 선언문의 원년 멤버 중 한 명이고, 여러 전설적인 책의 저자입니다. 그중에는 이 팟캐스트 및 뉴스레터와 이름이 같은 '리팩토링'도 있습니다. 마틴과 함께 개발 프로세스부터 인간의 학습과 이해가 어떻게 변하는지, 그리고 소프트웨어 엔지니어링 직업의 미래에 이르기까지 AI가 소프트웨어 개발에 미치는 영향에 대해 이야기했습니다. 그런 다음 기술 부채(technical depth)라는 은유가 왜 그렇게 성공적이었는지, 그리고 그것을 다루는 마틴 자신의 조언에 대해 탐구했습니다. 마지막으로, 애자일의 현주소, 오늘날에도 여전히 많은 애자일 프랙티스에 대해 존재하는 저항, 그리고 엔지니어링 효과성을 측정하는 방법에 대해 이야기했습니다. 자, 그럼 바로 본론으로 들어가 보겠습니다. 스폰서의 짧은 소개 말씀 후에 말이죠.

[나레이터] 이 에피소드는 워크OS(WorkOS)가 후원합니다. 만약 여러분이 SaaS 앱을 만들고 있다면, 어느 시점에는 고객들이 SAML 인증, SCIM 프로비저닝, 세분화된 권한 부여와 같은 엔터프라이즈 기능을 요청하기 시작할 겁니다. 바로 이때 워크OS가 필요합니다. 앱에 엔터프라이즈 기능을 빠르고 고통 없이 추가할 수 있게 해주죠. API는 이해하기 쉬워서 신속하게 배포하고 다른 기능 개발에 집중할 수 있습니다. 워크OS는 또한 '오스키트(AuthKit)'라는 무료 사용자 관리 솔루션을 제공하는데요, 이는 즉시 사용 가능한 완벽한 사용자 관리 시스템으로 최초 백만 명의 사용자까지는 무료입니다. 오스제로(Auth0)를 바로 대체할 수 있으며, 도메인 인증, 역할 기반 접근 제어, 봇 방지, MFA와 같은 유용한 기능들이 기본으로 제공됩니다. 이는 래딕스(Radix) 컴포넌트를 기반으로 하므로 디자인에 어떠한 타협도 없습니다. 무한한 커스터마이징이 가능하며, 빠른 통합을 위해 설계된 모듈식 템플릿도 제공됩니다. 오늘날 커서(Cursor), 버셀(Vercel), 퍼플렉시티(Perplexity)와 같이 여러분이 아마 아실 만한 곳을 포함하여 수백 개의 가장 빠르게 성장하는 스타트업들이 워크OS를 사용하고 있습니다. 더 자세히 알아보시려면 workos.com을 확인해 보세요. workos.com입니다.

[루카] 안녕하세요, 마틴. 오늘 저희와 함께해 주셔서 정말 감사합니다.

[마틴] 초대해 주셔서 감사합니다. 만나서 반갑습니다.

[루카] 감사합니다, 마틴. 당신은 정말 소개가 필요 없는 분이죠. 쏘우트웍스의 수석 과학자이시고, 소프트웨어 개발의 전설이며, 애자일 선언문의 원년 멤버 중 한 분이십니다. 그리고 제 뉴스레터와 이름이 같은 '리팩토링'을 포함한 많은 책의 저자이시죠. 이건 우연이 아닙니다. 당신의 작업, 책, 그리고 블로그가 제가 뉴스레터를 시작할 때 큰 영감을 주었거든요. 우선 그 모든 것에 대해 감사드립니다.

[마틴] 감사합니다.

[루카] 당신은 또한 refactoring.com의 소유자이시기도 하죠. 그래서 제가 이 대화를 통해 혹시 그 도메인을 팔 생각이 있으신지 여쭤볼 수도 있겠네요.

[마틴] 아니요, 죄송하지만 그럴 생각은 없습니다. 제가 그 도메인에 대한 애착이 확실해서요. 그래서 계속 가지고 있을 겁니다. 지금이라면 아마 그렇게 안 했을 수도 있어요. 왜냐하면 모든 것을 martin.com 도메인에 올리고 있고, 별도의 도메인을 갖는 것이 조금 더 번거롭기 때문이죠. 하지만 애정이 있어서 계속 가지고 있을 겁니다.

[루카] 네, 한번 여쭤봐야 했어요. 괜찮습니다. 하지만 예상했던 답변이네요. 그럼 본론으로 들어가 보죠. 제가 당신의 블로그를 언급했는데, 정말 좋아합니다. 사실 제가 뉴스레터를 시작했을 때, 제가 좋아하던 몇몇 뉴스레터와 블로그가 있었는데 당신의 것이 단연 그중 하나였습니다. 그리고 지난 몇 년간, 당신이 쏘우트웍스의 다른 저자들과 함께 발행한 글들, 예를 들어 AI와 함께 코딩하는 것에 대한 글을 정말 감명 깊게 읽었습니다. 그래서 이 주제에 대해 당신의 생각을 듣고 싶었습니다. 우리 모두가 AI가 코딩하는 방식, 더 나아가 소프트웨어 개발 수명 주기 전반을 어떻게 바꾸고 있는지 실험하고 있는 것 같거든요. 이것에 대해 어떻게 생각하시나요?

[마틴] 음, 제 주된 생각은 아직 기술 발전과 우리가 이 기술을 어떻게 가장 잘 사용할 수 있는지에 대한 이해 모두 비교적 초기 단계에 있다는 것입니다. 저는 AI를 직접 실험하는 데 그다지 적극적이지는 않습니다. 부분적으로는 제가 제 동료들만큼 소프트웨어 개발 프로젝트의 일상에 깊이 관여하고 있지 않다는 것을 알기 때문이죠. 그래서 제가 직접 노력하기보다는 제 동료들이 탐구하고 발견한 것을 설명하는 데 도움을 주는 것이 더 낫다고 생각합니다. 그리고 이것은 요즘 제 글쓰기 철학 전반에 걸쳐 사실입니다. 저는 5만 피트 상공에서 내려와 제가 보고 있는 것에 대해 추측하기보다는 제 동료들의 소통을 돕는 데 더 관심이 있습니다. 네, 그리고 제가 특히 이 분야에 집중하고 있는 동료는 비르기타 뵈클러(Birgitta Böckeler)입니다. 그녀는 제 웹사이트에 생성형 AI 소프트웨어 개발 탐구에 대한 작은 페이지를 정기적으로 (더 정기적이었으면 좋겠지만요) 업데이트하고 있습니다. 쏘우트웍스에서 그녀의 역할은 사실상 우리가 소프트웨어 개발에서 AI를 어떻게 사용하고 있는지, 무엇을 배우고 있는지를 조율하는 것입니다. 그리고 그녀는 자신이 발견한 것들과 우리 다른 동료들이 발견한 것들에 대해 꽤 정기적으로 글을 올립니다. (더 자주 올렸으면 하지만요). 그리고 그것이 제가 특히 참고하는 것 중 하나입니다. 그녀가 발견하고 있는 것들이죠. 전반적인 메시지는 AI가 일반적으로 초안을 만드는 데는 능숙하지만, 그 초안을 반드시 검토해야 한다는 것입니다. 왜냐하면 실수가 포함될 것이고, 더 명확할 수 있었던 부분들이 있을 것이기 때문입니다. 그 초안들을 보고 작업해야 합니다. 어떤 면에서는 슬픈 일이죠. 많은 개발자들이 다른 사람의 코드를 리뷰하는 것을 싫어하니까요. 그리고 물론 AI는 다른 사람의 코드이고, 여러분은 그것을 리뷰해야 합니다.

[루카] 네, 네, 네. 정말 동의합니다. 그리고 저도 그렇게 듣고 있습니다. 사실 몇 주 전에 최신 DORA 보고서를 살펴봤는데, 이것을 가장 많이 들여다보는 팀들의 AI 사용에 대한 많은 통찰력을 탐구했더군요. 적어도 저에게는 놀라운 발견들이 있었습니다. 놀랍지 않은 발견 중 하나는 개인의 생산성, 개인의 처리량을 증가시켰다는 것이었습니다. 하지만 동시에 AI를 많이 사용하는 팀들은 안정성이 떨어지고, 배포 성공률이 낮아졌으며, 버그가 더 많아지는 경험을 했습니다. 그래서 저는 아마도 우리가 더 많은 코드를 생성하지만 그 코드는 우리 자신의 통제하에 있지 않다는 의미라고 생각했습니다. 그래서 이걸 어떻게 받아들여야 할지 모르겠지만, 우리가 훨씬 더 많은 코드를 생성하지만 그것을 어떻게 유지보수해야 할지 모르거나, 인간이 쓴 코드만큼 잘 이해하지 못하는 미래는 어떤 모습일까요?

[마틴] 네, 그리고 이 문제의 골치 아픈 측면 중 하나는 학습을 감소시킨다는 증거도 있다는 것입니다. 개발팀이 자신이 만드는 코드, 자신이 만드는 시스템에 대해 덜 배우고, 또한 이 과정의 일부로 지원하는 비즈니스 프로세스에 대해서도 덜 배우게 된다면, 그것은 그들이 할 수 있는 일에 중대한 중기적 영향을 미칠 것입니다. 그들이 무엇을 달성하려 하는지 이해하지 못하기 때문에 일을 쉽게 바꿀 수 없을 것입니다. 그리고 그것 또한 지켜봐야 할 특히 골치 아픈 점입니다. 개발팀의 학습은 결과물의 일부이기 때문이죠. 좀 이상하게 들릴 수 있지만, 소프트웨어는 한 번 전달하고 끝나는 제품이 아니라, 끊임없이 진화하는 제품이라는 점을 기억하면 중요합니다. 따라서 효과적인 제품, 좋은 제품을 만드는 것이 무엇인지 생각할 때, 제품을 만드는 과정 자체도 제품 품질 평가의 일부로 고려해야 합니다. 이것은 우리가 다른 많은 곳에서는 흔히 볼 수 없는 일입니다.

[루카] 네, 전적으로 동의합니다. AI 사용이 학습을 감소시킬 수 있다고 말씀하셨는데, 그것은 개발자들이 AI가 만든 초안을 별 생각 없이 내놓기 때문에, 즉 더 쉬워 보이기 때문이라고 생각하시나요?

[마틴] 음, 그것이 한 부분이라고 생각합니다. 다른 부분들도 있는데, 예를 들어 AI의 가장 유용한 점 중 하나는 익숙하지 않은 프레임워크에서 작업할 때 정말 도움이 된다는 것입니다. 새로운 프레임워크나 플랫폼을 가져오면 AI가 그 프레임워크를 사용하는 많은 것들을 생성해 줄 수 있어서 훨씬 더 빨리 움직일 수 있죠. 하지만 문제는 그러면 여러분이 실제로 그 프레임워크를 배우고 있느냐는 것입니다. 만약 여러분 자신이 배우고 있지 않다면, 그것을 효과적으로 활용하는 방법, 그것의 능력, 그리고 그것과 정말로 어떻게 작업할 수 있는지에 대한 이해가 부족하게 됩니다. 그리고 그것은 앞으로 여러분의 효율성을 떨어뜨릴 것입니다. 그리고 마찬가지로, 제가 말했듯이 비즈니스 맥락도 마찬가지입니다. 여러분은 비즈니스 측의 사람들과 상호작용하며 그들의 필요와 욕구를 이해하고, 소프트웨어가 어떻게 그들을 가장 잘 지원할 수 있을지 알아내고 있나요? 지적되었듯이, AI와 소프트웨어에 대한 많은 관심은 프로그래밍 측면, 즉 코드 작성, 테스트 작성 등에 집중되어 있습니다. 하지만 그것은 사실 소프트웨어 개발자 업무의 일부에 불과합니다. 소프트웨어 개발자 업무의 많은 부분은 어떤 소프트웨어를 작성해야 하는지 이해하는 것입니다. 사용자와 다른 고객들이 무엇을 달성하려 하는지 이해하고, 소프트웨어가 그들이 하는 일을 어떻게 도울 수 있는지 알아내는 것이죠. 그리고 많은 AI 노력들은 그 부분에 그다지 초점을 맞추지 않고 있습니다. 사실 그 부분은 저희 동료들 중 일부가 더 집중해 온 분야입니다. 저희는 '헤이븐(Haven)'이라는 도구를 준비해 왔는데, 이것은 저희가 내부적으로 사용하지만 외부에도 공개한 것입니다. 그 아이디어는 소프트웨어의 코드 부분뿐만 아니라 예를 들어 위협 모델링 같은 다른 것들을 지원하는 것입니다. 위협 모델링 측면에서 꽤 좋은 질문들을 생각해 낼 수 있나요? 왜냐하면 AI는 질문과 아이디어를 생성하는 데 매우 능숙하기 때문입니다. 그리고 나서 우리의 일은 인간으로서 그것들에 반응하고, 이 아이디어들이 좋은 아이디어인지 아닌지 판단하고 그것을 바탕으로 작업하는 것입니다.

[루카] 네, 맞아요. 지금까지 주된 초점은 코딩에 있었지만, 평균적으로 개발자들이 코딩에 쓰는 시간은 전체 시간의 15%에서 최대 20% 정도라는 보고서들이 있습니다. 그러니 만약 AI를 이용한 코딩으로 생산성 향상을 기대한다면, 그것은 넘어설 수 없는 꽤 명확한 상한선이 있는 셈이죠.

[마틴] 바로 그거죠. 네.

[루카] 그리고 예를 들어 일반 코드 작성과 테스트 작성에서의 사용을 언급하셨는데, 물론 테스트는 당신이 가장 많이 탐구한 분야 중 하나입니다. AI와 인간이 업무를 분담할 것이라고 생각하시나요? 예를 들어 인간은 테스트를 작성하고 AI는 개발 코드를 작성하거나, 아니면 AI가 그냥 모든 것을 작성하게 될까요? 테스트와 일반 코드 사이에서 인간과 AI가 어떻게 업무를 나눌지에 대해 주의 깊게 봐야 할 부분이라고 생각하시나요?

[마틴] 그 점은 현시점에서 명확하지 않습니다. 제 생각에 AI는 테스트의 첫 번째 초안을 만드는 데 있어서 코드의 첫 번째 초안을 만드는 것만큼이나 유용할 수 있습니다. 그리고 어쩌면 "여기 코드가 있고, 여기 테스트 스위트가 있는데, 내가 뭘 놓치고 있지?"라고 말하며 테스트를 비평하는 역할도 할 수 있겠죠. 왜냐하면 그것은 아이디어를 생성하는 것이기 때문입니다. 생성형이라는 부분은 아이디어를 생성하고 초안을 생성하는 것이며, 이는 다양한 곳에서 일어날 수 있습니다. 하지만 중요한 것은 인간으로서 여러분이 그것들을 보고 "이 아이디어는 좋고, 저 아이디어는 별로 좋지 않네"라고 말하며 그것들을 걸러내는 방법을 아는 것입니다.

[루카] 네, 네, 전적으로 동의합니다. 그리고 물론 AI에 대한 낙관론자와 비관론자들이 있고, 이것이 고용 시장과 소프트웨어 엔지니어의 역할에 미치는 영향에 대해서도 여러 의견이 있습니다. 초기 보고서에 따르면 주니어 엔지니어들이 더 힘든 시기를 겪을 수 있다고 합니다. 왜냐하면 어떤 맥락에서는 AI가 매우 다작하는 주니어 엔지니어처럼 행동하기 때문이죠. 그리고 이것은 아마 당신이 이전에 말한 AI가 학습을 감소시킨다는 점과도 연관이 있을 수 있습니다. 젊은이들이 코딩 기술만 가지고 취업 시장에 진입하기가 어려워질 수도 있죠. 왜냐하면 AI가 협업이나 시스템 설계 같은 다른 능력과는 달리 바로 그 코딩 기술에서 가장 뛰어나기 때문입니다. 그래서 어떻게 생각하시나요? 엔지니어에게 요구되는 기술이 바뀔 것이라고 생각하시나요? 고용 시장에서 다른 종류의 사람들을 위한 다른 공간이 생길까요? 이것에 대해 생각해 보신 적이 있나요?

[마틴] 오, 기술의 변화는 분명히 있습니다. 우리가 알아야 할 기술 중 하나는 AI를 어떻게 가장 잘 활용할 것인가 하는 것입니다. AI가 유용해지는 부분에서, 즉 초안과 최종 결과물의 차이를 아는 기술뿐만 아니라, AI로부터 최대한의 것을 얻어내기 위해 어떻게 프롬프트를 작성할 것인지도 알아야 합니다. 소프트웨어 개발자에게 종종 잘 알려지지 않은 기술 중 하나는 효율적으로 검색하고 정보를 찾아내는 능력, 그리고 검색했을 때 옥석을 가려내는 능력이었습니다. 이는 중요한 부분이죠. 그리고 AI에서도 마찬가지로, 프롬프트를 가장 잘 사용하는 법과 어떤 종류의 능력이 있는지 배워야 합니다. 물론 도구가 도움이 될 수 있습니다. 저희가 헤이븐(Haven)으로 했던 일 중 하나는 프롬프트를 풍부하게 하고 미세 조정하여 사람들이 그 정교한 부분을 그렇게 많이 알 필요가 없도록 하는 것이었습니다. 그들은 단지 자신이 얻으려는 것에만 집중할 수 있었죠. 그래서 그것이 하나의 기술이 됩니다. 그리고 저는 그것이 분명한 기술의 변화라고 생각합니다. AI를 작업에 통합하는 방법을 아는 것이죠. 왜냐하면 소프트웨어 개발자들이 AI 때문에 불필요해질 것이라고는 생각하지 않지만, AI를 사용하지 않는 소프트웨어 개발자들은 그것을 효과적으로 사용하는 사람들에 의해 쓸모없게 될 것입니다. 이는 IDE나 데이터베이스, 혹은 인프라스트럭처 애즈 코드(infrastructure as code) 같은 어떤 도구에도 해당되는 말입니다. 기술을 가장 효과적으로 사용하는 방법을 배워야 할 필요가 있는 것이죠. 저는 주니어들에게는 추가적인 어려움이 있다고 생각합니다. 왜냐하면 여러 면에서 AI는 시니어 개발자의 좋은 취향을 복제하지는 못하지만, 주니어 개발자의 열정과 많은 것을 쏟아내는 능력은 복제할 수 있기 때문입니다. 하지만 물론 주니어 개발자의 가장 중요한 특성 중 하나는 그들을 시니어 개발자로 키울 수 있다는 사실입니다. 그리고 그것이 모든 조직에 필요한 핵심적인 것 중 하나죠. 조직 내에서 더 많은 인력을 길러낼 수 있는 능력이 필요합니다. 제가 쏘우트웍스에 있었던 지난 20년 동안 우리의 가장 큰 강점 중 하나는 항상 가능성 있는 주니어들을 정말로 뛰어난 시니어 인재로 성장시키는 데 매우 능숙하다는 것이었습니다. 그리고 그것이 핵심 강점이죠. 음, 내부적으로 우리가 여전히 그 가치를 인정하고 있다는 점을 기쁘게 생각합니다. 왜냐하면 끊임없이 변화하는 기술의 역할을 활용하는 법을 배워감에 따라 미래에는 이것이 점점 더 중요해질 것이기 때문입니다. 그리고 다른 조직들도 이 점을 살펴봐야 한다고 생각합니다. 경험이 적은 소프트웨어 개발자가 가진 가장 중요한 가치는 그들을 더 경험 많고, 여러분의 도메인을 이해하며, 여러분이 속한 기술 환경을 어떻게 활용할지 아는 사람으로 성장시킬 수 있는 능력입니다.

[루카] 네, 전적으로 동의합니다. 그것이 가장 중요한 장기적인 관점이라고 생각합니다. 또한 단기적으로는 젊은 엔지니어들에게 유리한 반론도 있다고 생각합니다. 어쩌면 젊은 친구들이 AI 사용을 더 능숙하게, 그리고 더 적극적으로 받아들일 수 있다는 것이죠. 어쩌면 더 경험 많은 시니어들보다 말입니다. 그래서 아마 젊은 엔지니어들에 대한 이 모든 걱정은 조금 과장된 것일 수도 있습니다. 다른 사람들이 이 도구들을 사용하는 데 더 저항하는 동안, 그들은 엄청나게 생산적으로 뛰어들 수 있으니까요.

[마틴] 네, 저 같은 늙은 화석들이 최신 기술을 배우는 데 그다지 능숙하거나 열정적이지 않다는 점을 항상 염두에 두는 것이 중요하죠. 물론 저는 반박할 수 있습니다. 제가 지난 수십 년간 거둔 성공의 비결 중 하나는 장기적으로 중요하지 않은 것으로 판명된 것들을 매우 잘 무시해왔다는 것입니다. 그리고 현재 저는 확실히 AI를 무시하고 있지 않습니다. 저는 그것이 장기적으로 중요한 것이라고 생각합니다. 예를 들어 블록체인과는 다르죠. 블록체인은 제가 대부분 무시해서 기뻤습니다.

[루카] 처음부터 무시하셨나요? 그러니까 당신의 취향이 처음부터 그것이 중요하지 않다고 시사했나요?

[마틴] 네. 제가 블록체인을 봤을 때, 제 느낌은 아마도 그 안에 가치 있는 것이 1%나 2% 정도 있을 수 있다는 것이었습니다. 네. 그리고 제가 배운 것은, 아니, 그 1%나 2%조차도 없다는 것이었습니다. 음, 항상 까다롭습니다. 왜냐하면 제가 틀릴 때도 있다는 사실을 항상 염두에 둬야 하니까요. 그래서 무언가를 무시할 때조차도 제가 틀릴 수 있다는 사실을 경계합니다. 하지만 아니요, 저는 블록체인에 대해 항상 꽤 부정적이었습니다. 정말 설득력 있는 이야기가 없다고 느꼈습니다.

[루카] 네, 하지만 "중요하지 않은 것을 무시하는 데 능숙하다"는 당신의 말은 정말 마음에 듭니다. 그래서 약간 주제를 벗어나 보려고 하는데요, 새로운 트렌드나 매우 자주 변하는 것들이 있을 때, 그리고 항상 기회비용이 존재할 때, 즉 그것을 살펴보는 데 시간을 쓰고 싶지만 중요하지 않을 수도 있고, 혹은 너무 빨리 변해서 배운 것이 내일은 중요하지 않게 될 수도 있습니다. 어떻게 결정하시나요? 마틴 파울러 당신은 어떤 것이 당신의 관심을 받을 가치가 있는지, 지금 당장 더 깊이 파고들 가치가 있는지, 아니면 무시하거나 살짝 발만 담가볼 것인지를 어떻게 결정하시나요? 그것에 대한 사고 과정이 있으신가요?

[마틴] 음, 제 주된 방법 중 하나는 제 동료들의 말을 듣는 것입니다. 수년에 걸쳐 제가 큰 존경심을 쌓아온 동료들이 있습니다. 그들이 어떤 것에 대해 의견을 가질 때, 저는 그 말을 경청합니다. 그것이 중요하죠. 그래서 일반적으로는 좋은 취향을 가진 사람들의 네트워크를 구축하고 그들의 말을 듣는 것이 매우 중요합니다. 그리고 그것은 당신의 전문 분야 안팎에서 중요한 특성입니다. 특히 당신의 전문 분야 밖에서 신뢰할 수 있는 좋은 사람들을 두는 것이 가치가 있습니다. 네, 그리고 그런 사람들을 구별하는 특징은 아마도 가장 유망한 것들에 대해서도 합리적으로 회의적인 태도를 보이는 사람들입니다. 어떤 것을 항상 완전히 무시하는 것이 아니라, 신중한 회의주의, 즉 지나치게 열광하지도 않고 그렇다고 해서 모든 것을 버리지도 않는 태도입니다. 저는 그것이 가치 있는 태도라고 생각합니다. 그리고 결과에 집중하는 것, "이것을 유용하게 어디에 쓸 수 있을까?"라고 생각하는 것입니다. 그것이 어떻게 작동하는지에 대한 세부 사항에 파고드는 것과는 대조적이죠. 물론 그들은 그것이 어떻게 작동하는지에 대한 세부 사항을 알아야 하지만, 또한 그것이 제공하는 가치, 즉 결과물을 이해할 필요가 있습니다. 그래서 그런 종류의 성격, 또한 뉘앙스와 복잡성을 찾고 추구하는 성격, 만약 누군가 "이것에 대한 간단한 답이 있다"고 말하면, 그것은 즉시 그 사람이 말하는 것의 가치에 대한 제 의문을 불러일으킵니다. 왜냐하면 저는 인생에서 일들이 간단한 답을 갖는 경향이 없다는 것을 발견했기 때문입니다. 숨겨진 복잡성이 있는 경향이 있죠. 그래서 저는 그 뉘앙스나 복잡성을 숨기려 하지 않고 그것이 존재한다는 것을 이해하는 것처럼 보이는 사람들을 찾습니다. 누군가가 무언가를 말했는데 그것이 너무 좋거나 너무 간단해서 사실이 아닐 것 같을 때, 그것은 보통... 제가 그렇게 표현한 것 자체가 그런 암시를 주네요. 이것들이 제가 제 네트워크에서 찾는 것들 중 일부입니다. 그리고 일반적으로 제가 웹에서 읽는 전문가나 그런 사람들에게서도 마찬가지입니다. 저는 제가 말했듯이 그 뉘앙스와 복잡성을 받아들이고 그것을 피하려 하지 않는 사람들, 두 가지가 서로 긴장 관계에 있을 수 있다는 것, 즉 두 가지 모두 좋지만 경우에 따라서는 그렇게 좋지 않을 수 있다는 것, 그리고 그 둘 사이에서 균형을 잡아야 한다는 것을 이해하는 사람들을 항상 찾습니다. 어떤 것의 '양'이 유익한 약과 독의 차이라는 것을 깨닫고, 그 '양'의 한계가 어디에 있는지에 관심이 있는 사람들, 그런 것들이 좋은 신호라고 생각합니다. 그리고 그 외에는, 특히 글을 쓸 때 10년, 20년 후에도 여전히 중요할 것이라고 생각하는 것들을 찾으려고 합니다. 대부분의 경우, 다음 6개월 동안만 가치가 있을 글을 쓰고 싶지 않습니다. 그래서 저는 장기적인 것들을 찾으려고 노력합니다. 그래서 특정 라이브러리나 프레임워크보다는 일반적인 원칙, 아키텍처 또는 디자인 패턴을 찾는 경향이 있습니다. 왜냐하면 특정 패턴을 이해하고 나면, 많은 언어와 프레임워크에 걸쳐 수많은 곳에서 그것을 사용할 수 있기 때문입니다. 그리고 그것은 정말로 가치가 있을 수 있습니다. 그 예로, 제 마음에 강하게 남아 있는 것은 제가 처음으로 스몰토크(Smalltalk)에서 map, reduce, filter와 같은 소위 '컬렉션' 함수형 컬렉션 메서드를 발견했을 때입니다. 그리고 저는 "아, 여기 강력한 라이브러리가 있구나"라고 깨달았지만, 이 연산들을 조합하여 무엇을 할 수 있는지에 대한 일반적인 원칙이 있다는 것을 알게 되었습니다. 그리고 그것들은 점점 더 많은 언어로 퍼져나갔습니다. 하지만 중요한 점은 제가 한 언어에서 배운 교훈이 즉시 다른 언어로 넘어간다는 것입니다. 그래서 저는 스몰토크와 루비(Ruby)에서 그것들을 사용하는 데 매우 익숙해졌습니다. 처음으로 통계에 기반한 매우 이상하고 다른 프로그래밍 언어인 R 프로그래밍 언어로 작업하기 시작했을 때, 저는 즉시 "아, 이것이 이러한 기능을 지원한다는 것을 안다. map을 쓸 수 있고, filter를 쓸 수 있다. 바로 어떻게 해야 할지 안다"라고 말할 수 있었습니다. 그리고 저는 즉시 루비와 스몰토크에서 쌓아온 모든 지식을 가져와 이 전혀 다른, 매우 생소한 환경으로 가져갔습니다. 하지만 핵심 원칙을 어떻게 사용하는지 알기 때문에 믿을 수 없을 정도로 생산적일 수 있었습니다. 그래서 제가 종종 찾는 것은 바로 그것입니다. 어떤 것의 특정 장소에서의 구현보다는 그 배후에 있는 핵심적인 기본 원칙이 무엇인지 생각하는 것입니다. 만약 여러분이 그 원칙을 이해한다면, 그 원칙들을 수많은 다른 방식으로 가지고 다닐 수 있습니다.

[루카] 정말 좋습니다. 이 답변 정말 마음에 듭니다. 저는 또한 이러한 종류의 추상화를 만들고 기술이나 패턴 등을 가치 있게 만드는 근본 원리로 돌아가는 능력이 훌륭한 엔지니어의 핵심 자질 중 하나라고 생각합니다. 그리고 이것이 또한, 만약 당신이 소프트웨어 엔지니어링의 책들과 기초적인 저작들을 본다면, 당신이 쓴 것들과 다른 사람들이 쓴 것들, 즉 프로그래밍 패턴과 접근법을 강조하는 것들이 모두 20년에서 25년 정도 되었지만, 우리가 이 기간 동안 기술, 언어, 프레임워크를 계속 바꿔왔음에도 불구하고 그 원칙과 접근법들은 거의 그대로 유지되는 이유 중 하나라고 생각합니다. 당신이 말했듯이, 제 생산성은, 아이디어를 가져와서 원하는 만큼 많은 프로그래밍 언어와 상황에 적용할 수 있고, 다른 시스템 디자인 패턴이나 당신이 가진 것들도 마찬가지입니다. 만약 당신이 근본 원리로부터 얻는 그런 추상화 능력을 추구한다면, 이 아이디어들은 시간의 시험을 견뎌냅니다.

[마틴] 네, 그리고 그것이 제가 정말로 집중하고 싶어 하는 것들 중 하나인 이유입니다. 부분적으로는 제가 그것들을 가장 흥미롭게 생각하기 때문이기도 하지만, 또한 물론 제가 그것들을 가장 가치 있다고 생각하기 때문이기도 합니다.

[루카] 네, 전적으로 동의합니다. 그럼 이제 제가 말하고 싶은, 언제나 시들지 않는 주제이자 제 뉴스레터에서 가장 인기 있는 주제인 '기술 부채'로 넘어가 보겠습니다. 제가 이 주제에 대해 이야기할 때마다 소프트웨어 엔지니어, 관리자, 기본적으로 모든 종류의 이해관계자들로부터 항상 강한 반응이 나옵니다. 그리고 당신은 '리팩토링'이라는 책을 쓰셨는데, 그 실천 방법은 많은 경우에 우리가 '기술 부채'라고 부르는 것을 줄이는 것과 관련이 있습니다. 우선, 이것은 당신이 이전에 언급한 것들과 유사하게 비유, 은유, 일종의 원칙입니다. 왜 이것이 그렇게 성공적이었고 많은 사람들에게 공감을 얻으며, 기술 분야의 거의 모든 사람이 널리 사용한다고 생각하시나요?

[마틴] 그것이 왜 그렇게 사람들에게 깊이 와닿고 공감을 얻었는지는 매우 흥미로운 질문입니다. 저는 아마도 재정적 부채가 우리 삶의 다른 부분에서 우리에게 매우 민감하고 큰 문제이기 때문이라고 생각합니다. 따라서 프로그래밍 시스템에서 느끼는 것과 프로그래머가 아닌 사람들도 이해할 수 있는 더 넓은 세상에서 느끼는 것 사이에 그 연결을 만드는 것, 그것이 둘을 함께 연결할 때 정말 강력한 연결고리가 됩니다. 음, 네, 저는 종종 그 번역 과정에서 많은 것이 손실될 수 있다고 느낍니다. 하지만 그것이 공감대의 일부라고 생각합니다. 저는 또한 그것이 소프트웨어 개발의 가장 어색한 요소 중 하나와 관련이 있다고 생각합니다. 즉, 우리 삶의 많은 것에서 우리는 높은 품질을 비싼 것으로 보지만, 소프트웨어를 작성할 때에는 높은 품질이 실제로 더 저렴하다는 사실입니다. 그리고 부채라는 은유는 사람들이 약간이나마 붙잡을 수 있다고 느끼는 소프트웨어의 그 비직관적인 특성에 접근하는 한 가지 방법입니다. 하지만 그것은 부채와의 관계의 본질에 대한 온갖 다른 것들과 함께 섞여 들어갑니다. 그 자체로도 복잡한 것이죠.

[루카] 네. 그래서 이 점을 탐구해보고 싶습니다. 결국 그것이 좋은 비유라고 생각하시나요? 아니면 소프트웨어를 다루는 방식에는 실제로 적용되지 않는 다른 관련 개념들을 떠올리게 하나요? 예를 들어, 그 부채를 갚아야만 한다는 것 같은... 모르겠습니다. 이 비유가 부족한 부분이 있나요?

[마틴] 오, 물론 그 비유에는 문제가 있습니다. 그리고 문제는 때때로 그것이 단지 비유일 뿐이라는 사실 때문에 발생하며, 사람들은 그것을 마땅히 그래야 하는 것보다 더 멀리 확장하려고 합니다. 네. 하지만 또한 사람들이 금융 부채 자체에 대해 반드시 좋은 이해를 가지고 있지 않기 때문에, 그들의 이해 부족으로 인해 비유를 잘못된 방식으로 사용하기도 합니다. 그래서 분명히 문제가 있습니다. 제가 그 비유에서 가장 매력적으로 느끼는 부분, 그리고 제가 그것을 가장 많이 사용하는 곳은, 부채가 있을 때 "이자를 계속 낼 것인가, 아니면 원금을 갚을 것인가"라는 결정을 생각하게 만든다는 점입니다. 그 선택이 저에게는 그 비유가 흥미로운 핵심입니다. 그리고 이 문제의 핵심은 이자 지불이 우리 코드베이스에 이러한 불완전성이 있다는 사실 때문에 작업을 수행하는 것이 얼마나 더 어려워지는가 하는 것입니다. 따라서 3일이 걸릴 작업이 대신 4일이 걸리거나, 우리가 가진 부채 수준에 따라 6일이 걸립니다. 그리고 나서 우리는 그 이자를 계속 지불할 것인가, 아니면 문제의 원인이 되는 것을 해결할 것인가, 즉 사실상 원금을 갚는 것인데, 이는 미래의 이자 지불을 줄일 것입니다. 그리고 그 트레이드오프가 제가 생각하기에 부채 비유가 가장 가치 있는 지점입니다. 왜냐하면 그것은 사람들에게 "아, 이것이 우리가 원금을 갚아야 하는 이유구나. 왜냐하면 미래의 이자 지불을 줄여줄 것이기 때문이다"라는 느낌을 주기 때문입니다. 혹은 "음, 사실 이자 지불이 그렇게 크지 않으니, 원금을 갚으려고 노력할 필요는 없다"는 결정을 내리게 하죠. 그리고 저는 그것이 그 결정을 구체화하는 데 도움을 주고, 또한 그 결정 과정을 소프트웨어 팀 외부의 다른 사람들에게 전달하는 방법을 제공하는 방식을 좋아합니다. 그리고 저는 그것이 그 비유가 가장 강력한 지점이라고 생각합니다. 저는 사실 '기술 부채'라는 용어를 그렇게 많이 사용하는 것을 좋아하지 않습니다. 제 글에서 실제로 그 용어를 그렇게 많이 사용하지 않는 것을 발견하실 겁니다. 그리고 제가 소프트웨어에 있는 나쁜 것들, 즉 우리의 노력을 유발하는 원금이라고 할 수 있는 것들에 대해 이야기할 때, 저는 그 문제에 대해 '기술 부채'라는 단어를 사용하지 않습니다. 저는 '크러프트(cruft)'라는 단어를 사용하는데, 이것은 또 다른 오랜 기간 사용된 프로그래머 용어입니다. 그 이유는 제가 그것을 비유와 분리하고 싶기 때문입니다. 기술 부채는 우리가 '크러프트'를 어떻게 다룰지 생각하는 데 도움을 주는 비유이지, 그 자체는 아닙니다. 저는 그것을 별개의 항목으로 생각하고 싶습니다.

[루카] 네, 동의합니다. 저는 그 비유가 이자를 낼 것인지, 아니면 원금을 갚을 것인지와 같은 종류의 결정을 내려야 할 때 유용하다고 생각합니다. 하지만 많은 경우에 순수하게 소프트웨어를 다룰 때는 그런 식으로 생각할 필요가 없으며, 그래서 그 비유가 오히려 방해가 될 수도 있습니다. 그리고 크러프트를 다룰 때, 리팩토링이나 다른 글에서 당신의 많은 조언은 기본적으로 그런 일들이 일어나지 않도록 예방하는 것에 관한 것입니다. 코드의 이 부분이나 저 부분을 변경하는 과정에 있을 때 항상 작은 규모의 리팩토링을 하고, 뭔가 나쁜 냄새가 나는 것을 발견하면 그 자리에서 리팩토링하는 것이죠. 당신은 그것이 사람들이 실천해야 할 주된 방식, 즉 사람들이 이런 종류의 활동을 할 수 있도록 개발 과정에 약간의 여유를 두어 부채나 크러프트가 쌓이는 것을 막는 주된 프로세스라고 생각하시나요?

[마틴] 네, 저는 확실히 내부 품질을 높게 유지하고 따라서 비용을 낮게 유지하는 가장 좋은 방법은 크러프트를 최소화하는 실천법에 집중하는 것이라고 생각합니다. 그리고 그것은 정말로 익스트림 프로그래밍(XP)의 핵심 실천법들로 귀결됩니다. 리팩토링은 물론 그중 하나지만, 좋은 테스트를 갖추는 것도 중요합니다. 그래야 무언가를 바꿀 때 망가뜨리지 않는다는 확신을 가질 수 있습니다. 그리고 지속적 통합(CI)을 통해 오늘 내가 한 일이 내일 다른 사람을 망치지 않는다는 것을 알 수 있습니다. 그리고 이것들이 그 그림의 핵심 요소입니다. 그리고 이것이 여전히 제가 이런 것들을 처리하는 데 있어서 찾아낸 가장 좋은 방법입니다. 하지만 어려운 점은 그런 세상에서 살아보지 않은 사람들에게 그것을 전달하는 것입니다. 저는 켄트 벡(Kent Beck)과 그의 딸 베스 앤더스 벡(Beth Anders Beck)이 최근에 이야기하고 있는 '숲과 사막'이라는 또 다른 비유에 특히 매료되었습니다. 그 비유는 우리가 크러프트를 통제하고 이런 건강한 방식으로 일하는 환경은 숲에서 사는 것과 같다고 말합니다. 그리고 이런 세상을 접해보지 못한 대부분의 사람들은 사막에 살고 있습니다. 그들은 숲이 어떤 모습일지 상상할 수 없습니다. 왜냐하면 환경이 너무나 다르기 때문입니다. 어떤 사람들은 숲에서 시간을 보내다가 사막으로 가기도 하고, 그 반대의 경우도 있으며, 그들은 그 차이를 보기 시작합니다. 하지만 많은 사람들에게는 숲에서 무엇을 할 수 있는지, 얼마나 빨리 움직일 수 있는지, 그리고 사막에서는 그저 평범한 일상인 그런 것들에 의해 방해받지 않는다는 것을 전달하기가 매우 어렵습니다. 네, 그리고 그 많은 것이 이러한 실천법에 기반을 두고 있습니다. 저는 정말 그렇게 느꼈고, 그것은 더욱 강화되었습니다. 저는 쏘우트웍스에서 일하면서 비교적 숲이 우거진 환경에 살고 있습니다. 왜냐하면 우리는 조직 전체적으로 매우 강력한 XP 지지자들이기 때문입니다. 네, 물론 우리가 더 강해질 수도 있겠지만요. 하지만 전반적으로 우리는 대부분의 곳보다 훨씬 낫고, 그것이 우리에게 다른 그림을 줍니다. 하지만 그곳에 도달하기 위해 무엇이 필요한지 전달하기는 어렵습니다. 그리고 또한 너무나 많은 사람들이 그곳에 도달하는 빠른 과정을 원하지만, 그것은 그렇지 않습니다. 정말 신중한 노력이 필요합니다. 그리고 더 어렵게 만드는 것은 인간적인 설정, 즉 이것이 작동하도록 인간 관계를 설정하는 것입니다. 팀의 심리적 안전과 같은 것들이 중요해집니다. 당신은 건강한 팀의 징후 중 하나가 사람들이 정기적으로 "아, 내 실수야, 미안해"라고 말하는 것이라는 전 동료의 최근 글을 본 적이 있을 것입니다. 그렇게 실수를 인정하는 것이 자연스러워지고 우리가 일하는 방식의 일부가 됩니다. 그리고 만약 사람들이 절대로 그런 말을 하지 않는 팀에 있다면, 그것은 당신이 실제로 나쁜 곳에 있거나 그런 곳으로 향하고 있다는 신호입니다.

[루카] 네, 전적으로 동의합니다. 그리고 저는 이것이 기술 부채 관련 주제에 있어서 사람들이 정말로 가장 어려움을 겪는 분야 중 하나라고 생각합니다. 그것을 예방하기 위한 실천법, 즉 소프트웨어 개발에서 좋은 실천법을 위한 공간을 유지하는 것에 있어서도 그렇고, 그것을 갚는 것에 있어서도 그렇습니다. 보통 제가 발견한 것은, 문제는 적어도 자주 기술적인 작업이 특별히 어렵다는 것이 아니라, 비기술적인 이해관계자들에게 그것을 옹호하기가 어렵다는 것입니다. 그리고 그 지점에서 비유가 깨진다고는 말하지 않겠지만, 비유는 어느 정도까지만 도움이 됩니다. 왜냐하면 사람들은 숲을 정말로 이해할 수 없기 때문입니다. 그렇다면 어떻게 다른 사람들이 숲이 어떻게 작동하는지 이해하게 만들고, 다른 이해관계자들에게 강력한 기술 작업을 어떻게 옹호하시나요? 당신의 경험은 어떻습니까?

[마틴] 그것이 바로 어려운 점입니다. 사실, 저 같은 사람들의 실패는 우리가 숲을 우리가 생각했던 것만큼 널리 퍼뜨리지 못했다는 것이라고 주장할 수도 있습니다. 음, 제가 항상 강력하게 주장하는 한 가지는 우리는 숲에 있는 것의 경제적 이점에 집중해야 한다는 것입니다. 누군가가 저에게 와서 "이 코드베이스에 대해 리팩토링을 충분히 하고 있지 않아요. 상사들이 리팩토링할 시간을 주지 않거든요" 라고 말하거나, 혹은 "전문가로서의 책임감"이라는 측면에서 "우리는 테스트를 작성하는 데 시간을 들이지 않아서 적절한 소프트웨어 개발자로서의 역할을 다하지 못하고 있어요"라고 말하기 시작하면 저는 항상 불안해집니다. 왜냐하면 저는 그 시점에서 그들이 이미 졌다고 느끼기 때문입니다. 그들은 "우리가 더 나은 일을 할 수 있도록 경제적 비용을 지불해야 한다"는 식으로 이야기를 구성하고 있기 때문입니다. 하지만 그렇게 작동하지 않습니다. 우리가 테스트를 작성하고 싶어 하는 이유, 리팩토링을 하고 싶어 하는 이유, 이런 것들을 하고 싶어 하는 이유는 더 많은 것을 생산하기 위해서입니다. 비용을 낮추고 더 많은 가치를 생산하기 위해서죠. 그리고 우리는 항상 우리가 하고 싶은 이런 종류의 실천법들을 "이것은 우리를 더 빠르게 만들고, 더 많은 가치를 생산하게 한다"는 관점에서 설명해야 합니다. 왜냐하면 그것이 우리가 그것을 하는 이유이기 때문입니다. 저는 단지 어떤 점수판을 채우기 위해 테스트를 작성하는 데 관심이 없습니다. 그냥 켄트 벡의 승인을 받거나 하는 것에는 관심이 없어요. 제가 신경 쓰는 것은 일을 더 빨리 끝낼 수 있는가 하는 것입니다. 그리고 저는 많은 테스트를 작성함으로써 디버깅하는 데 시간을 덜 쓰기 때문에 일을 더 빨리 끝낼 수 있다는 것을 발견했습니다. 저는 실제로 여러분의 소프트웨어를 사용하는 사람들과 이야기하면, 그들이 무엇을 하려고 하는지 이해하기 때문에 더 가치 있는 소프트웨어를 만들 수 있다는 것을 발견했습니다. 그 결과, 여러분은 그들이 소프트웨어가 그들을 돕기 위해 무엇을 할 수 있는지에 대해 생각해내지 못했을 아이디어를 생각해 낼 수 있습니다. 그리고 종종 어떤 소프트웨어가 유용할지 알아내는 방법은 그것의 간단한 버전을 만들어보고 사람들이 그것을 편리하게 생각하는지 보는 것입니다. 그리고 5번 중 4번은 여러분이 틀려서 사람들이 그것을 편리하게 생각하지 않을 수도 있지만, 그 다섯 번째는 다른 모든 것을 만회할 만큼 가치가 있습니다. 하지만 여러분과 고객, 여러분과 사용자들 간의 지속적인 대화 없이는 그것을 할 수 없습니다. 그래서 이런 종류의 것들은, 우리가 그것들을 하는 이유는 어떤 도덕적인 의미에서 그것들이 '옳기' 때문이 아니라, 그것들이 우리를 더 효과적이고 생산적으로 만들기 때문이며, 경제적인 이유 때문입니다. 그러니, 이런 실천법 중 하나를 옹호하고 싶은 유혹을 느끼고, "이것이 좋기 때문에 해야 한다"고 말하고 싶을 때, 손목을 찰싹 때리세요. 아니, 당신이 그것을 하는 유일한 이유는 경제적인 이유 때문입니다. 그리고 만약 당신이 경제적인 이유를 앞세우고, 항상 경제적인 이유에 집중한다면, 제 믿음은 그것이 당신을 어딘가로 이끌 것이라는 것입니다. 네, 하지만 제가 말했듯이, 우리는 지난 20년 동안 숲을 퍼뜨리는 데 제가 바랐던 만큼 성공적이지는 못했습니다. 그러니 아마도 여러분 젊은이들이 우리 늙은 화석들이 시도해보지 못한 새로운 기술을 개발해야 할지도 모르겠네요.

[루카] 저는 제 역할을 하려고 노력하고 있습니다. 아직 새로운 기술은 없지만요. 하지만 제 작은 경험으로는 당신이 말씀하신 것에 전적으로 공감합니다. 문제 중 하나는, 생산성 향상이나 개발자 경험 개선에 관한 어떤 작업을 옹호할 때, 그것이 결코 독립적으로 존재하지 않는다는 것입니다. 그것은 항상 제품에 대한 다른 계획들과 경쟁하게 됩니다. 트레이드오프인 셈이죠. 그리고 제품에 대한 새로운 기능이나 작업들은 많은 경우에 측정하기 쉬운 비즈니스에 직접적인 영향을 미칩니다. 예를 들어, 결제 단계에서의 전환율 증가나 매출 증가 같은 것들이죠. 반면에 이런 다른 것들은 피드백 루프가 더 길고 증명하거나 보여주기 어려운 2차적인 효과를 가집니다. 그래서 예를 들어 엔지니어링 생산성 지표나 팀 성과 측정에 대한 모든 대화가 나오는 것이죠. 왜냐하면 저는 그것이 부분적으로 우리가 더 나아지고 있다는 것을 측정할 수 있는 방법이라고 생각하기 때문입니다. 당신은 엔지니어링 프로세스를 더 측정 가능하게 만들고, 우리가 얼마나 잘 일하고 있는지, 얼마나 많이 생산하고 있는지에 대한 확실한 수치를 얻는 것을 믿으시나요? 아니면 그것들도 조금 과대평가되었다고 생각하시나요?

[마틴] 네, 여기에 긴장감이 있습니다. 한편으로는 우리가 더 나은 측정 방법을 찾아내는 것이 중요하다고 생각합니다. 더 넓게 말하면, 엔지니어링 프로세스의 효과성, 코드 품질 등을 평가하는 더 나은 방법을 찾아내는 것이죠. 다른 한편으로는, 그것이 얼마나 어려운지, 측정치가 얼마나 쉽게 잘못 사용될 수 있는지를 인식하고 있습니다. 사람들은 종종 유용할 수 있는 측정치에 집착한 다음, 상황에 맞지 않게 사용하고 많은 어려움에 빠지곤 합니다. 하지만 그 작업을 어느 정도 인식하는 몇몇 사람들이 있습니다. 예를 들어, DORA를 기반으로 구축된 SPACE 프레임워크 같은 것들, 니콜 포스그렌(Nicole Forsgren)이 그것으로 한 작업들, 우리가 다차원적인 것을 다루고 있다는 이해, 그런 종류의 것들은 정말로 가치가 있을 수 있습니다. 저는... 지금 필사적으로 기억해내려고 노력하고 있습니다. 왜냐하면 개발자 경험에 대해 델(Dell)의 몇몇 분들과 정말 좋은 이야기를 나눴기 때문입니다. 하지만... 정말 다시 한번, 종종 정성적인 정보를 이해하는 데 집중해왔습니다. 그것은 다른 어떤 것만큼이나 가치가 있을 수 있습니다. 저는... 지금 좀 허둥대고 있습니다. 왜냐하면 필사적으로 이 글을 쓴 사람의 이름을 찾으려고 하는데 머리에 떠오르지 않아서 그의 이름을 말하고 싶은데 당황스럽네요.

[루카] 전혀 문제없습니다.

[마틴] 네, 찾았습니다. 아비... 아니, 그건 다르네요. 그는 그것에 대해 조금 이야기했고, 이것을 이해하는 데 있어서 정성적인 데이터의 중요성에 대해 이야기했습니다. 그리고 저는 최근에 그와 다른 사람들이 그런 종류의 것을 보기 시작한 몇몇 글들을 봤습니다. 그리고 그런 종류의 것들은, 다시 말하지만, 많은 부분이 뉘앙스에 집중하고, 다시 한번, 복용량의 차이를 이해하는 것입니다. 그것이 혜택과 독의 차이죠. 네, 이런 종류의 것들이 그가 집중해 온 것들입니다. 그리고 우리는 좋은 측정치들을 보기 시작했다고 생각합니다. 또한 아담 쏜힐(Adam Thornhill), 'Your Code Is a Crime Scene'의 저자도 정말로 흥미로운 작업을 해오고 있습니다. 이 사람들은 올바른 방향으로 나아가고 있다고 생각합니다. 네, 저는 항상 '측정'이라는 단어에 조심스럽습니다. 왜냐하면 저에게 측정은 어떤 것에 대한 간단한 정량적인 그림을 의미하는 경향이 있기 때문입니다. 그리고 우리는 그것과는 거리가 멉니다. 그래서 저는 '평가'나 '진단'과 같은 모호한 단어를 좋아합니다. 그것은 이것이 다차원적인 공간이라는 사실을 포함하지만, 우리는 그 모든 세부 사항을 어떻게 얻을 수 있는지 정말로 모릅니다. 하지만 사람들이 그것에 집중하기 시작하고, "이 측정치를 어느 정도 사용할 수 있지만, 이 길로 너무 멀리 가고 싶지는 않고, 그것이 어떻게 쉽게 조작되거나 오용될 수 있는지 조심하라"고 말할 때, 저는 제가 편안하게 들을 수 있는 것들을 듣기 시작하고, 우리가 약간의 진전을 이루고 있다고 생각합니다. 그리고 그것이 저를 격려합니다.

[루카] 네, 전적으로 동의합니다. 특히 정량적 데이터, 소위 측정치와 정성적 데이터를 결합하는 것에 대해서요. 사람들과 대화하고, 설문조사를 하고, 원격 측정(telemetry)이라고 부를 수 있는 것을 통해 측정하기 어려운 것들을 실제로 파악하는 것이죠. 네, 전적으로 동의합니다. 그리고 이전에 말씀하신 것으로 돌아가고 싶습니다. 지난 20년 동안 당신의 의견으로는 숲을 퍼뜨리는 데 그다지 성공적이지 못했고, 당신과 다른 사람들이 옹호해 온 이 실천법들을 퍼뜨리지 못했다고 하셨습니다. 그래서 저는 기본적으로 올해 초 켄트(벡)가 팟캐스트에 나왔을 때 했던 것과 같은 질문을 하고 싶습니다. 왜 TDD, 페어 프로그래밍, 심지어 어떤 분야에서는 지속적 통합(CI)과 많은 애자일 실천법들이 여전히 논란이 되거나 저항에 부딪힌다고 생각하시나요?

[마틴] 네, 이제 제가 기억력이 더 좋았으면 하는 부분입니다. 왜냐하면 제가 그 인터뷰를 들었는데 켄트가 뭐라고 했는지 기억이 안 나서 그냥 앵무새처럼 따라 할 수가 없네요. 어떤 면에서는, 문제는 우리가 왜 그런지 모른다는 것입니다. 왜 그런지 알았다면 고쳤겠죠. 저는 그 일부가 직관에 반하는 요소들 때문이라고 생각합니다. 즉, 고품질 코드가 더 저렴하다는 개념은 직관에 반하는 개념입니다. 왜냐하면 네, 아시다시피, 우리가 다른 것들을 접하는 방식과는 다르기 때문입니다. 그래서 그것의 일부는 직관에 반한다는 것입니다. 특히, 다시 말하지만, 만약 당신이 숲에 가본 적이 없다면 말입니다. 사람들이 리팩토링에 대해 이야기할 때 "리팩토링은 싫어요. 내 코드가 며칠 동안 망가져 있을 거거든요" 라고 말하는데, 이것은 즉시 그들이 리팩토링을 이해하지 못한다는 것을 말해줍니다. 네, 그런 종류의 것은 어렵습니다. 왜냐하면 저는 숲의 조각들이 어떻게 작동하는지, 그리고 그것들이 모두 함께 어떻게 작동하는지는 말할 것도 없고, 숲에서 약간의 시간을 보내야 그것들을 이해할 수 있다고 생각하기 때문입니다. 왜냐하면 그것들은 모두 함께 작동하기 때문에 작동하는 것입니다. 만약 당신이 좋은 테스트 없이 리팩토링을 하려고 한다면, 당신은 불쾌한 경험을 하게 될 것입니다. 그래서 그것이 그 그림의 일부입니다. 음, 일부는 또한 어떤 맥락에서는 작동하는 것들에 의해 주의가 산만해지기 쉽고, 그런 다음 다른 맥락으로 퍼져나가는 것 때문이기도 합니다. 제게 가장 인상 깊었던 것은 물론, 이제는 풀 리퀘스트 프로세스의 일부로서 통합 전에만 하는 것으로 여겨지는 코드 리뷰의 지배적인 개념입니다. 이것은 오픈 소스 세계에서 나온 개념으로, 그곳에서는 매우 적합합니다. 그리고 그것이 맥락이 변하여 더 이상 효과적인 접근 방식이 아닌 많은 환경으로 가져와졌습니다. 이것은 패턴 세계에서 우리가 어떻게 문제, 맥락, 해결책에 대해 이야기했는지와 같은 경우입니다. 특정 맥락에서 문제가 있으면 이 해결책이 좋지만, 맥락을 바꾸면 그 해결책은 더 이상 좋은 해결책이 아닙니다. 바로 그 맥락에 대한 이해 부족이 커밋 전 코드 리뷰의 지배를 야기했고, 그것이 결코 가서는 안 될 곳으로 퍼져나갔습니다. 그리고 물론 그것에 대한 가치 있는 점 중 하나는 사람들이 코드 리뷰가 다른 많은 곳에서 일어난다는 것을 깨닫지 못한다는 것입니다. 저는 6개월 전에 썼던 제 오래된 코드를 다시 만질 때마다 그 코드를 리뷰하고 있습니다. 그것은 리뷰입니다. 그리고 저는 때때로, 종종 그것이 부족하다는 것을 발견하고 고칠 것입니다. 그리고 건강한 팀에서는 그런 과정이 있습니다. 그래서 리팩토링이 조직 내에 그렇게 깊이 뿌리내려야 하는 이유입니다. 왜냐하면 여러분은 끊임없이 코드를 리뷰하고 있고, 이 코드가 커밋되면 무엇을 할 것이라는 생각에 기반하여 리뷰하는 것이 아니라, 지난 6개월 동안 무엇을 했는지에 기반하여 코드를 리뷰하고 있기 때문입니다. 이것은 훨씬 더 많은 정보이며, 따라서 여러분은 훨씬 더 나은 코드 리뷰 프로세스를 가지게 됩니다. 하지만 만약 사람들이 그런 종류의 지속적인 코드 리뷰를 코드 리뷰의 일부로 생각하지 않고, 코드 리뷰가 어떻게든 프로세스의 특정 시점에서만 일어날 수 있다고 생각한다면, 그들은 너무나 많은 것을 놓치고 있는 것입니다.

[루카] 네, 저는 그것이 어떤 일을 하는 이유에 대해 근본 원리로 돌아가지 않고, 오히려 모두가 그렇게 하거나 어떤 영향력 있는 사람이 그렇게 하기 때문에 실천법을 맹목적으로 추종하는(cargo culting) 아이디어로 귀결된다고 생각합니다. 그리고 그것을 당신의 상황에 적용하면 작동하지 않죠. 저는 코드 리뷰가 환상적인 장점을 가지고 있지만, 잘못 수행되면 수많은 팀의 배포에 엄청난 병목 현상을 만드는 완벽한 예라고 생각합니다.

[마틴] 네, 맞습니다. 저는 문제가, 숲이 여러 실천법들의 조합인데 그중 많은 것이 직관에 반하는 것처럼 들린다는 점이라고 생각합니다. 그리고 아마도 그중 가장 심한 것이 페어 프로그래밍일 것입니다. 많은 사람들이 정말 힘들어하죠. 제가 알기로는 우리가 고객들을 설득해야 하는 가장 어려운 것들 중 하나입니다. 네, 하지만 아시다시피, 그것은 우리가 이야기하고 있는 이 모든 것들과 매우 밀접하게 연관되어 매우 다르고 더 생산적인 환경을 만들어냅니다. 네, 우리는 그것을 완전히 전달하는 데 어려움을 겪어왔습니다. 사실 제가 독립적으로 활동하는 대신 쏘우트웍스에 그렇게 오랫동안 관여해 온 이유 중 하나는 제가 숲을 만들고 싶었기 때문입니다. 적어도 사람들이 잠시 머물면서 그것이 무엇을 할 수 있는지 볼 수 있는 곳으로서요. 그들은 숲이 어떤 모습인지 볼 수 있습니다. 그리고 그것이 저에게는 숲을 퍼뜨리는 가장 가치 있는 방법입니다. 그냥 "이리 와서 어떤지 봐"라고 말하는 것이죠. 그러면 그들은 "아, 이 모든 모래 속에서 계속 살 필요는 없구나. 매일 매시간 태양 아래 있을 필요는 없구나. 실제로 대안이 있구나"라고 깨닫습니다. 그리고 그들이 가는 곳에서 아주 좋은 대안을 만들 수는 없을지 모르지만, 적어도 그들은 차이점을 느끼게 되고, 그것이 우리를 앞으로 나아가게 할 수 있습니다. 하지만 제가 말했듯이, 숲이 얼마나 더 나은지를 고려하면, 주변에 더 많은 숲을 보지 못하는 것은 좀 슬픈 일입니다.

[루카] 네, 네. 하지만 페어 프로그래밍을 생각할 때, 매우 의견이 분분하다고 말씀하셨죠. TDD도 마찬가지로 의견이 분분하다고 할 수 있습니다. 혹은 직관에 반한다고 말하는 것이 더 낫겠네요. 당신이 다른 사람들에게 숲을 그 깊이까지 보여줄 때, 그리고 이것이나 저것에 대해 회의적인 사람을 만날 때, 예를 들어 페어 프로그래밍에 대해서요, 그리고 그들이 그것을 완전히 경험하게 할 때, 그들이 신봉자가 되나요? 아니면 많은 경우에 개인적인 취향의 문제인가요? 저는 많은 사람들이 "이것은 내가 하는 올바른 방식이다"라고 말하는 대신 "나는 원래 이러니까 이건 나랑 안 맞아"라고 변명하는 것 같거든요.

[마틴] 여기에는 개인적인 취향의 요소가 있습니다. 제가 가끔 여기서 생각하는 것은 저와 제 여동생이 휴가를 접근하는 방식의 차이입니다. 제 여동생은 모든 것을 계획하고 싶어 합니다. 3개월 전에 이 날에는 이 식당에서 식사를 할 것이라고 말이죠. 모든 것이 마지막 세부 사항까지 계획되어 있습니다. 반면에 저는 "음, 이 나라에 도착해서 아마도... 그리고 실제로 그렇게 한 적도 있는데, 비행기에서 가이드북을 읽고 가면서 무엇을 할지 정하는" 그런 타입입니다. 그리고 저는 그 정도의 불확실성과 그에 대한 대응력에 편안함을 느낍니다. 그것은 때때로 믿을 수 없을 정도로 유익했습니다. 이탈리아에서 휴가를 보냈는데, 우리는 휴가 대부분을 하이킹을 할 계획이었습니다. 우리는 열렬한 하이커거든요. 그런데 일주일 전에 허리가 나가서 하이킹을 할 수 없게 되었습니다. 만약 우리가 모든 것을 미리 신중하게 계획했다면 재앙이었을 것입니다. 하지만 실제로는 "아, 이탈리아에는 항상 할 일이 있지"라고 생각하고 다른 할 일을 찾아냈습니다. 그런 외부 변화에 대응하는 것이 물론 매우 적응적인 접근 방식을 취하는 것의 큰 장점입니다. 하지만 어떤 사람들에게는 "아, 정확히 5일 후에 내가 무엇을 할지 모른다"는 불확실성을 정말 싫어합니다. 그리고 그 성격의 변화는 존재합니다. 그리고 그것은 제가 간과하기 쉬운 것입니다. 왜냐하면 저는 적응적인 접근 방식에 편안함을 느끼기 때문입니다. 그리고 그것은 페어링에 영향을 미칩니다. 어떤 사람들은 자신이 내성적이기 때문에 페어링을 좋아하지 않는다고 말합니다. 그것은 차이가 아닙니다. 왜냐하면 저는 내성적이고 페어링을 꽤 즐기기 때문입니다. 자주 할 기회는 없지만, 할 때면 즐깁니다. 왜냐하면 그것은 저에게 내성적인 방아쇠를 당기지 않는 다른 종류의 사람들과의 상호작용이기 때문입니다. 네, 하지만 그것이 페어링을 불편하게 느끼는 사람들이 없다는 것을 의미하지는 않습니다. 그리고 자연스럽게 그들은 다른 길을 찾아야 합니다. 저는 팀들이 자신들을 가장 효과적으로 만드는 방법을 찾아야 한다고 매우 굳게 믿습니다. 그리고 그것은 제가 선택할 방법이 아닐 수도 있습니다. 왜냐하면 다른 사람들은 다르기 때문입니다. 네, 하지만 저는 숲을 즐길 수 있는 많은 사람들이 그것을 경험하지 못했고 경험해 본 적이 없다고 생각합니다. 그리고 어떤 사람들은 숲에 와서 "나는 사막이 싫고, 숲도 싫다. 나에게는... 모르겠다, 다른 것을 달라. 대초원 같은 것을 달라"고 말할 수도 있습니다. 그것이 내가 원하는 것이다. 그리고 그것은 괜찮습니다. 하지만 저는 사람들이 숲을 경험할 기회를 가져야 한다고 생각합니다. 그러면 그들은 차이점에 대한 실제적인 이해와 지식을 바탕으로 그곳이 자신들이 머물고 싶은 곳인지 결정을 내릴 수 있습니다.

[루카] 네, 네. 훌륭한 답변이라고 생각합니다. 그리고 이런 아이디어들이 직관에 반하거나 때로는 불편하게 느껴지는 것 외에, 그것들이 더 널리 퍼지지 않은 사실 뒤에는 그것들이 또한 제대로 제시되지 않았다는 요소가 있다고 생각하시나요? 많은 경우에 애자일 자체가 종종 강압적으로 인식된다는 사실이 떠오르네요. 켄트가 인터뷰에서 애자일이 권위에 의해 전유되었다고 말했죠. 네. 그래서 그런 요소가 있다고 생각하시나요?

[마틴] 오, 네. 음, 그건 항상 이런 것들의 방식이죠. 그렇죠? 이런 것을 생각해 내면, 항상 그런 일이 일어날 위험이 있습니다. 제가 좋아하는 문구가 있는데, 찾아야겠네요. 왜냐하면 정확하게 인용하고 싶거든요. 알리스터 코번(Alistair Cockburn)의 말입니다. 잠깐 찾아보죠. 언제든지 음... 네, 찾았습니다. 제가 이와 관련하여 좋아하는 문구는 알리스터 코번의 말입니다. 그는 이렇게 말했습니다. "당신의 훌륭한 아이디어에는 두 가지 중 하나만 일어날 것입니다. 왜곡되거나 오용되거나, 아니면 무시되거나. 그리고 당신은 그 둘 중 어느 것이 일어날지 선택할 수 없습니다." 저는 애자일이 무시될 것이라고 생각했습니다. 그리고 제 목표는 최소한 애자일과 XP를 우리가 쏘우트웍스에서 할 수 있는 것으로 만들고 싶다는 것이었습니다. 그냥 바로 나눠주고 "아니, 당신은 비효율적인 방식으로 일해야 해. 숲에 들어갈 수 없어, 사막에 있어야 해"라고 말하는 것이 아니라요. 그리고 어느 정도 우리는 그것에 성공했다고 생각합니다. 우리는 "네, 우리는 여러분이 효과적이라고 생각하는 방식으로 일하기를 원하고, 여러분이 우리에게 그 방식을 가르쳐주기를 원합니다"라고 말하는 고객들을 찾습니다. 그리고 그들은 적어도 숲을 잠깐이나마 엿보고 그곳이 자신들이 가고 싶은 곳이라는 것을 깨닫습니다. 그리고 그 점에서 우리는 엄청나게 성공했습니다. 왜냐하면 저는 사실 그렇게 멀리 갈 수 있을 것이라고 생각하지 않았기 때문입니다. 하지만 사막의 바다 한가운데 있는 앙상한 나무 한 그루를 보고 "저게 숲이야. 저 나무가 숲을 되찾아왔어"라고 말하는 사람들에 의해 도움이 되지는 않습니다. 그리고 많은 안전한 애자일 커뮤니티 세계는 불행하게도 몇 그루의 나무를 보고 그것을 숲으로 착각합니다. 그리고 그것은 큰 안타까움입니다. 왜냐하면 그것은 그것이 아니기 때문입니다.

[루카] 네, 네, 전적으로 동의합니다. 하지만 우리가 여기저기 좋은 숲 구역들을 가지고 있고, 그 안에서 번성할 수 있는 한...

[마틴] 네, 숲 구역들이 있겠지만, 사람들이 번성할 수 있는 곳이죠. 그리고 아마도 제가 생각했던 것보다 더 오래 걸릴지도 모릅니다. 저는 항상 이것이 세대가 걸릴 변화라고 느꼈습니다. 저는 제가 늙고 쇠약해질 때쯤에는 실질적인 진전을 보기 시작할 것이라고 기대했습니다. 저는 이제 늙고 쇠약해졌고, 진전은 제가 기대했던 것보다 적었습니다. 하지만 네, 그렇다고 해서 제가 멈추는 것은 아닙니다. 저는 계속 밀고 나갈 것이고, 제 젊은 동료들이 계속해서 그것을 앞으로 밀고 나가는 것을 도울 수 있는 일을 계속할 것입니다. 그리고 그것이 지금 제 역할입니다. 길을 비켜주고 젊은이들이 밀고 나가는 것을 돕는 것이죠. 그리고 바라건대 그들이 제가 가고 싶었지만 가지 못했던 곳에 도달할 수 있기를 바랍니다.

[루카] 글쎄요, 당신은 분명히 저를 도와주셨습니다. 그래서 다시 한번 정말 감사합니다. 그리고 저도 제 역할을 하도록 노력하겠습니다.

[마틴] 좋습니다. 숲을 더 퍼뜨리기 위해 계속 밀고 나가세요. 저는 우리가 숲에서 더 많은 진전을 이룰 수 있다고 생각합니다. 그리고 만약 그렇지 않더라도, 적어도 우리는 숲에 있잖아요.

[루카] 정확합니다. 정확해요. 그것이 희망적인 측면이죠. 마틴, 이 대화 정말 감사했습니다. 정말 즐거웠습니다. 쇼에 나와주셔서 정말 감사합니다.

[마틴] 초대해 주셔서 감사합니다.

[루카] 들어주셔서 정말 감사합니다. 이 대화가 유익했다면, 유튜브, 애플 팟캐스트, 스포티파이 또는 즐겨찾는 팟캐스트 앱에서 쇼를 구독하실 수 있습니다. 또한 평점을 주거나 리뷰를 남겨주시면 다른 청취자들이 쇼를 찾는 데 정말 큰 도움이 됩니다. 모든 지난 에피소드는 refactoring.fm에서 찾으실 수 있고, 쇼에 대해 더 자세히 알아보실 수 있습니다. 다음 에피소드에서 뵙겠습니다.