Martin Fowler & Kent Beck: Frameworks for reinventing software, again and again
🎙️ 도입 및 인삿말: 전설들의 등장과 TDD의 명암
진행자: 환영합니다 여러분. 여러분 모두를 뵙게 되어 정말 기쁩니다. 아는 얼굴들도 많이 보이네요. 방금 전 마틴(Martin)과 켄트(Kent)를 만나서도 정말 좋았습니다. 행사 전에 가볍게 농담도 했지만, 마틴 파울러와 켄트 벡이 이렇게 가장 핫한 AI 스타트업들이 모인 자리에 걸어 들어올 줄은 정말 예상치 못했습니다. 하지만 결국 우리는 여기 모였고, 아주 좋은 이유로 이 자리에 함께하고 있습니다.
켄트 벡: 뭐라고요? 대체 그게 무슨 뜻입니까? (웃음)
진행자: 아이고, 시작이군요. 오늘 제가 켄트를 '오래된 가구(고인물)'라고 한 번 불렀기 때문에 아마 절 미워하실 겁니다.
켄트 벡: 그건 공평하지 않은 것 같네요.
진행자: 오래된 가구 맞잖아요. 이 무리에서 제일 나이가 많으시니까요.
마틴 파울러: 전 적어도 켄트보다는 한 살 어립니다.
진행자: 두 분 모두 이 자리에 와주셔서 정말 기쁩니다. 일주일 전, 저와 마틴, 켄트, 그리고 여러 사람들이 유타주 디어 밸리에서 마틴이 주최한 소프트웨어 엔지니어링의 미래 컨퍼런스에 모여 흥미로운 사상가들과 이야기를 나눴습니다. 25년 전 애자일 선언문(Agile Manifesto)이 만들어졌던 때를 회상하니 감회가 새롭더군요. 17명의 사람들이 있었고, 두 분도 그 자리에 계셨죠. 그 이후로 두 분은 소프트웨어 엔지니어링의 형태를 잡고 큰 영향을 미치며 막대한 공헌을 해오셨습니다. 두 분께 묻고 싶습니다. 지난 수십 년 동안 엔지니어들에게 어떤 피드백을 받아오셨나요? 어떤 아이디어가 엔지니어들에게 가장 깊게 남았고, "이것 덕분에 정말 감사합니다"라는 말을 가장 많이 듣는지 궁금합니다.
마틴 파울러: 정말 흥미로운 질문이네요. 사실 그 부분에 대해 깊이 생각해 본 적은 없습니다. 많은 사람들이 우리가 작업했던 것들에 대해 전반적으로 이야기합니다. 넓게는 애자일, 혹은 제 경우엔 제가 썼던 책인 리팩토링(Refactoring)에 대해서요. 하지만 그중 어떤 특정 요소가 가장 크게 남았는지는 잘 모르겠습니다.
켄트 벡: 저는 테스트 주도 개발(TDD)에 대해 정말 감사하다는 인사를 많이 받습니다. 반면에 이런 피드백도 받죠. "이놈의 테스트 주도 개발이 내 인생을 망쳤어. 내 개도 도망가고, 집도 불탔고, 이게 다 당신 때문이야." 뭐 대충 이렇습니다. 대답이 되었나요?
진행자: 제 생각에 TDD는 굉장히 호불호가 갈리는 주제 같습니다. 저도 어느 순간에는 광신도였다가, 또 어느 순간에는 혐오하게 되기도 했거든요. 하지만 흥미로운 건 이 많은 개념들이 애초에 도발적이고 사람들을 밀어붙이려는 의도로 만들어졌다는 겁니다.
켄트 벡: 맞습니다. 어제 AI 분야의 최전선에 있는 분과 이야기를 나눴는데, 그분이 이러더군요. "지난 20년 동안 당신이 TDD를 밀어붙여 준 덕분에 정말 다행입니다. 지금 AI 에이전트 시대에 그게 정말 중요해졌거든요." 그런 피드백을 듣는 건 꽤 흥미롭습니다. 저는 제가 듣고 싶은 말이기 때문에 항상 이런 칭찬을 의심하곤 합니다. '내가 그냥 지어내서 좋게 생각하는 건가?' 하고요. 하지만 거대하고 강력한 '지니(Genie, 요술램프 요정)'가 생겼을 때, 그 지니가 나를 위해 올바른 일을 하고 있는지 검증하는 방법을 배워야 한다는 건 정말 말이 됩니다.
진행자: 우리가 지난 25년 동안 연습해 온 바로 그 검증 말이죠.
켄트 벡: 네. 뭐, 제 자신이 거대하고 강력한 지니는 아니었지만, 제가 제대로 된 일을 하고 있는지 확인하기 위해 항상 테스트가 필요했으니까요.
🔍 거장들의 근황: 답이 없는 시대의 탐험
진행자: 여기 계신 많은 분들이 저와 함께 했던 팟캐스트나 두 분의 책을 통해 두 분을 알고 계실 겁니다. 마틴, 당신은 완벽한 작가입니다만 요즘은 어떻게 지내시나요? 일상적인 업무는 어떠신가요? 기술 트렌드와는 어떻게 접점을 유지하고 계시나요? 사실 링크드인에서 어떤 무례한 댓글을 보고 싸워야만 했습니다. "저 컨퍼런스는 기술 트렌드에 뒤떨어진 작가들을 부르고 있네"라길래 제가 "당신 마틴 파울러랑 켄트 벡이 누군지나 알아?"라고 했죠. 아무튼 진지하게, 요즘은 어떤 일에 집중하고 계신가요?
마틴 파울러: 음, 5~6년 전쯤 리팩토링 2판 작업을 마쳤을 때, 새로운 책을 쓸까 고민했었습니다. 절반쯤 쓰다 만 책들도 몇 권 있었고요. 하지만 그러지 않기로 결심했습니다. 대신, 실제 프로젝트에서 실제 코드를 작성하며 일하고 있는 사람들과 협력해서, 그들의 아이디어와 배움을 세상에 끌어내는 일을 하기로 했죠. 그게 이후 제 주된 프로젝트가 되었고, 주로 martinfowler.com 웹사이트에 집중하고 있습니다. 그곳은 제가 온전히 통제할 수 있으니까요. 대기업이 갑자기 끼어들어 엉망으로 만들 일도 없고요. (물론 제가 돈을 잔뜩 받고 팔아넘기지 않는 이상 말이죠.)
AI 바람이 불어오면서 저는 이 흐름을 포착하고 싶었습니다. 요즘 저의 가장 큰 관심사는 사람들의 '세부적인 워크플로우'를 다시 이해하는 것입니다. 정확히 무슨 일을 하고 있는지, 켄트가 말한 그 '지니'와 어떤 대화를 나누고 있는지 파악하는 거죠. 코드를 리뷰할 때는 무엇을 찾고 있는지, 특히 '우리 인간이 아직도 내리고 있는 결정'은 무엇이며, 그 의사결정의 흐름이 어떻게 변하고 있는지에 관심이 많습니다. 즉, 제가 직접 무언가를 한다기보다는, 동료들이 무엇을 하고 있는지 관찰하고 그것을 널리 퍼뜨리는 것이 제 목표입니다.
켄트 벡: 제 인생의 개인적인 사명은 "긱(Geeks, 기술자/괴짜들)들이 이 세상에서 안전함을 느끼도록 돕는 것"입니다. 그런데 지금 우리 긱들은 전혀 안전하다고 느끼지 못하고 있습니다. 타당한 이유도 있고, 그렇지 않은 이유도 있죠.
제가 깨달은 점 중 하나는 지난 25년 동안 우리는 항상 '답'을 가지고 있었다는 것입니다. 누군가 와서 "버그가 너무 많아요"라고 하면 "자, 여기 테스트 작성법이 있습니다"라고 답했고, "테스트를 어떻게 쓰는지 모르겠어요"라고 하면 "자, 테스트를 작성할 수 있게 디자인하는 방법입니다"라고 답했습니다. 마치 녹음기의 재생 버튼을 누르는 것과 같았죠. 하지만 지금 달라진 점은, 이 순간에는 그 누구도 어떤 것에도 정답을 알지 못한다는 것입니다.
그래서 제가 요즘 하고 있는 일은, 제 자신의 긱스러운 호기심을 충족시키기 위해 다시 '탐험 모드'로 돌아가는 것입니다. 이 새로운 도구들을 어떻게 해야 효과적으로 사용할 수 있는지 최대한 찾아내고, 그것을 다음 세대에게 보여주려 합니다. 항상 '답'을 얻는 데 익숙해져 있던 세대 말입니다. "문제가 생기면 책에서 지난 20년간 통했던 해결책을 찾아보자"라는 방식이 지난 1년간은 통하지 않았고 앞으로도 한동안 통하지 않을 것입니다. 따라서 시니어로서 우리의 역할은 단순히 도구를 효과적으로 사용하는 법을 보여주는 것을 넘어, '도구를 효과적으로 사용하는 방법을 스스로 알아내는 법'을 보여주는 것이라고 생각합니다. 이는 완전히 다른 차원의 기술 세트이니까요.
🌊 과거의 기술 혁신과 AI의 비교
진행자: 아무도 앞으로 어떻게 될지 모르고, 모두가 스스로 알아내야 한다는 말씀이시군요. 두 분의 커리어 여정으로 돌아가 보겠습니다. 두 분은 저를 포함해 이 자리에 있는 많은 사람들보다 훨씬 더 많은 것을 경험하셨습니다. 지금의 AI처럼 예측 불가능하거나 두렵게 느껴졌던 기술 변화의 시기가 있었나요? 커리어에서 가장 비슷했던 사건은 무엇이었습니까?
마틴 파울러: 음, AI의 위력과 규모에 비견될 만한 타격을 준 것은 없었습니다. 이것은 우리가 이전에 직면했던 그 어떤 것과도 차원이 다른 거대한 변화입니다. 조금 더 작은 규모로 이야기하자면, 우리는 객체지향(Object-Oriented) 언어의 성장에 깊이 관여했습니다. 당시 많은 사람들이 그것을 두려워했지만, 우리는 그 흐름의 일부였기 때문에 그렇게 두렵진 않았죠. 모두에게 엄청난 타격을 준 건 단연코 '인터넷'의 등장입니다. 그리고 우리가 '애자일 소프트웨어 개발'의 도전 과제를 널리 알릴 때도 그랬습니다. 당시 조직들이 얼마나 강하게 저항했는지 보면 그 파급력을 알 수 있죠.
하지만 AI가 다른 점은, 과거에 우리가 기술의 중요성과 가치를 설명하고 사람들을 설득하려 노력해야 했다면 (놀랍게도 인터넷 초기에도 그게 안 중요하다고 생각하는 사람들이 있었습니다), AI는 그것이 얼마나 중요한지에 대해 아무도 논쟁하지 않는다는 점입니다. 아무리 눈을 가리고 현실을 부정하려 해도 이 기술의 중요성은 부인할 수 없습니다.
켄트 벡: 제가 생각하는 또 다른 비유는 '마이크로프로세서(Microprocessor)의 도입'입니다. 그 이전의 컴퓨터는 거대한 상자였습니다. 옮길 수도 없었고, 하나 더 사고 싶으면 집을 다시 담보로 잡아야 할 만큼 엄청난 일이었죠. 인텔 4004 칩이 처음 나왔을 때, 프로그래머였던 아버지와 함께 실리콘 밸리에 살던 어린 저는 이렇게 생각했습니다. "잠깐, 저게 컴퓨터라고? 맙소사." 갑자기 가능성이 폭발적으로 확장된 겁니다. 소프트웨어를 작성하는 법을 알아내고, 이 작은 칩을 중심으로 하드웨어를 설계하는 법을 알아낸다면, 우리가 상상조차 하지 못했던 일들을 갑자기 해낼 수 있게 된 거죠. 저는 AI의 핵심 중 하나가 바로 이 '상상력의 확장'이라고 생각합니다. 그래서 저는 지금 말도 안 되게 야심 찬 프로젝트들을 진행하고 있습니다. 영구적인 스몰토크(Smalltalk) 시스템을 작업해 보거나, Rust로 라이브러리 수준의 코드를 작성해 보는 식이죠. 상상할 수 있는 모든 걸 시도해 보는 중입니다. 물론 그중 상당수는 실패하겠지만, 그건 이 과정의 일부일 뿐입니다. 하늘이 열리고 수많은 새로운 기회가 쏟아진 것이 역사상 이번이 처음은 아닙니다.
진행자: 객체지향이 확산될 때나 마이크로프로세서가 등장했을 때, 업계의 분위기는 어땠나요? 이 새로운 세계에서 번성했던 숙련된 전문가들과, 솔직히 말해 뒤쳐졌던 사람들 사이의 차이는 무엇이었습니까?
마틴 파울러: 그 모든 기술 변화에는 과대광고(hype)를 쫓는 사람들과 "이거 별거 아니야"라고 치부하는 사람들 사이의 혼재된 분위기가 항상 존재했습니다. 가장 중요한 것은 '회의주의(Skepticism)'와 '호기심(Curiosity)' 사이의 균형을 유지하는 것입니다. 물론 선택적이어야 합니다. 예를 들어 저는 거대한 변화라고 떠들썩했던 블록체인(Blockchain)에 대해서는 완벽하게 회의적이었습니다. 업계에서 수년간 가짜 약(snake oil)을 파는 걸 너무 많이 봤기 때문에 제 회의주의는 근거가 확실하죠.
하지만 저는 제 회의주의가 절대적이어야 한다고 생각합니다. 즉, "나 자신의 회의주의에 대해서도 회의적이어야 한다"는 뜻입니다. 그러려면 호기심이 필요합니다. "이게 가짜 같아 보이긴 하는데, 혹시 아닐 수도 있지 않을까? 여기 진짜 무언가가 있다는 신호를 감지하려면 어떻게 찔러보고 실험해봐야 할까?"라는 호기심 말입니다.
켄트 벡: 맞습니다. "이 주장이 사실인지 나 스스로 만족할 수준으로 검증하기 위해 내가 실행할 수 있는 가장 작은 실험은 무엇인가?"라는 질문을 던져야 합니다. 모든 사람의 만족 기준은 다르겠지만, 이 질문을 던지는 기술이 지난 1년간 수천 배는 더 가치 있는 기술이 되었습니다.
마틴 파울러: 하지만 거기에 한 단계가 더 있습니다. 여러분의 초기 경험과 상호작용이 항상 진실된 신호는 아닐 수 있다는 점을 인지해야 합니다. 제가 1년 반쯤 전에 처음 코파일럿(Copilot) 같은 AI 도구를 가지고 놀기 시작했을 때, 저는 꽤 실망했습니다. 저는 이맥스(Emacs) 유저거든요 (유일하고 진정한 에디터죠). 이맥스에서 자동 완성 프롬프트를 설정해서 3~4일 정도 써봤는데, 가끔 멋진 결과를 내놓기도 했지만 대부분은 당장 지워버리고 싶을 만큼 쓰레기 같은 결과를 내놓아서 금방 질려버렸습니다.
만약 그것이 제 AI에 대한 최종 인상이었다면, 블록체인 때처럼 즉시 '무시 스위치(Bozo switch)'를 켜버렸을 겁니다. 하지만 동시에 저는 계속 탐색을 하고 있었습니다. 이 모든 과정에서 제가 얻은 가장 큰 수확은 옆방에 있는 시몬 윌리슨(Simon Willison)의 블로그를 읽은 것이었습니다. 거기서 배운 한 가지는 "이 도구를 잘 사용하려면, 잘 사용하는 법 자체를 배워야 한다"는 거였습니다. 객체지향 때도 마찬가지였죠. 사람들이 "오, 객체지향 짱이야!"라고 해서 코드를 보면 객체를 전혀 제대로 안 쓰고 있었습니다 (C++나 Java를 쓰면서 실제로는 객체지향 설계를 안 했던 거죠).
핵심은, 밖에 있는 사람들의 이야기를 비판적인 시각으로 읽고 파악할 수 있어야 한다는 겁니다. 만약 시몬 윌리슨 같은 사람을 발견했다면, 그 사람이 모든 걸 훌륭하다고 과대 포장만 하는지, 아니면 실제 문제점도 인식하면서 나에게 객관적인 사실을 전달하는지 판단해야 합니다. 장단점의 균형을 알려주고, 특히나 "나도 잘 모르겠다"라고 솔직하게 말할 준비가 된 사람들의 말은 귀 기울여 들을 가치가 있습니다. 시몬 윌리슨이나 제 쏘트웍스(Thoughtworks) 동료들(Mike Mason, Bit Berkel 등)이 바로 제 초기 반응에만 너무 의존해서는 안 된다는 걸 보여주었죠.
켄트 벡: 네, 그리고 상황은 매주 바뀔 수 있습니다. 이번 주에 제미나이(Gemini)로 시도해 봤더니 처참하게 실패하고, 클로드(Claude)로 했더니 잘 작동하다가, 다음 주엔 똑같은 걸 제미나이로 했는데 잘 되고 다른 건 안 되는 식이죠. 사람들은 항상 '정답'을 원하지만 정답은 계속 변하고 있습니다. 이 환경에서 여러분은 정답을 가질 수 없습니다. 이것이 나쁜 소식이죠. 하지만 좋은 소식은, 다른 누구도 정답을 모른다는 것입니다. 여러분이 다른 모두와 마찬가지로 무지하다는 건, 곧 여러분이 다른 모두만큼이나 똑똑하다는 뜻이기도 합니다.
진행자: 그거 위로가 좀 되시나요? (청중들에게) 위로가 되시면 손 좀 들어보시죠.
📜 애자일과 AI의 평행이론: 인센티브와 뱀장수들
진행자: 거의 정확히 25년 전, 17명의 이름이 적힌 웹사이트와 함께 애자일 선언문이 발표되었을 때와 지금이 상당히 비슷하다는 생각이 듭니다. 참고로 켄트 벡이 첫 번째로 이름이 올라가 있었죠. 왜 첫 번째였나요?
켄트 벡: 철자(알파벳) 순이었습니다. 아주 철저하게 알파벳 순이었지만 저에게 끝없는 기쁨의 원천이 되고 있죠. (웃음)
진행자: 그 선언문은 업계에 정말 흥미로운 파장을 일으켰습니다. 제 해석으로는 이랬습니다. "이 애자일이라는 걸 쓰면, 이해하기 쉽고 공감하기 쉬운 4가지 원칙을 통해 더 나은 소프트웨어를, 더 빠르고, 더 저렴하게, 더 높은 품질로 만들 수 있다." 지금 많은 기업들이 AI를 도입하는 이유도 똑같습니다. 더 좋고, 더 빠르고, 더 저렴하게 만들 거라는 기대감이죠. 뱀장수(snake oil) 이야기가 나왔으니 묻고 싶은데, 애자일이 실제로 어떻게 흘러갔는지 회고해 주실 수 있나요?
켄트 벡: 음, 알고 보니 사람들은 '더 빠르고, 더 저렴하고, 더 나은 것'을 원하지 않았습니다.
진행자: 자세히 설명해 주시죠.
켄트 벡: 회사 내부의 인센티브 구조는 그것(빠르고 싸고 좋은 것)을 달성하는 것과 완전히 어긋나 있었습니다. 그래서 우리 같은 기술자들이 그걸 달성하려고 "효율이 40% 좋아졌고, 비용이 12% 절감되었습니다"라고 말해도, 그게 조직 내부 사람들의 인센티브와 일치하지 않으면 오히려 벌을 받았습니다. 이상적인 조직이라면 모두가 같은 목표를 중요하게 생각하겠지만, 현실은 그렇지 않죠. 이 문제는 아직도 해결되지 않았습니다. 만약 AI가 나타나 똑같은 약속을 한다면, 우리는 완전히 동일한 반응(조직의 저항과 인센티브 충돌)을 보게 될 것입니다.
진행자: 그 부분에 대해 묻고 싶었습니다. 25년 동안 훨씬 느린 속도로 전개되었던 애자일의 역사를 되돌아볼 때, 현재의 AI와 어떤 유사점이 보이나요? 그리고 업계를 아주 천천히 폭풍 속으로 몰아넣었던 애자일 운동과 지금의 AI는 무엇이 확연히 다릅니까?
마틴 파울러: 확연히 다른 점은 AI가 부딪히고 있는 압도적인 규모와 속도입니다. 이건 분명 다릅니다. 하지만 여전히 비슷한 점들이 있을 거라고 봅니다. 그중 하나는, 도구를 잘 쓰는 사람과 못 쓰는 사람 사이에 엄청난 격차가 생길 거라는 점입니다. 핵심은 도구를 잘 사용하는 법을 파악하고, 거기에 노력을 기울이는 것입니다. 이 두 그룹 간에는 큰 차이가 생길 겁니다.
또 다른 유사점은 바로 생태계입니다. 애자일과 익스트림 프로그래밍(XP) 이면의 핵심 개념은 견고하고 훌륭했지만, 그 주변에 거대한 가짜 약(snake oil) 산업이 생겨났습니다. 제가 '애자일 산업 복합체(Agile industrial complex)'라고 부르는 것들이죠. 지금 AI에도 똑같은 일이 벌어지고 있습니다. 어디가 진짜 기술이고 어디가 약팔이인지 구분하기가 종종 어렵습니다. 따라서 대상을 바라볼 때 항상 끊임없이 탐색하고 경계해야 합니다.
켄트 벡: AI는 '증폭기(Amplifier)'입니다. 만약 당신이 젊고 빠르게 학습하는 사람이라면, AI는 그것을 엄청나게 증폭시켜 줄 수 있습니다. 그래서 저는 개인적으로 지금이 '주니어 프로그래머들의 황금시대'라고 생각합니다. 저한테 와서 "제 아들이 컴퓨터공학 2학년인데, 미술사 같이 좀 더 상업적인(?) 분야로 전공을 바꾸고 싶어 해요"라고 걱정하는 분들이 많습니다. 저는 이렇게 답합니다. "당신이 목수인데 방금 원형 톱이 발명된 상황과 같습니다. '아, 이제 목수는 끝났어. 아무나 집을 지을 수 있겠네'라고 생각하시나요? 아니죠, 그저 더 강력한 도구를 가지게 된 겁니다. 구질구질한 잡무를 해야 할 시간이 줄어든 거죠."
빨리 배우는 젊은 사람들은 훨씬 더 빨리 배울 것이고, 이미 효과적으로 일하고 있던 숙련자들은 더 빠르고 효율적으로 일하게 될 것입니다. 제가 우려하는 건 바로 '중간 계층'입니다. 닷컴 붕괴 사태를 돌아보면, 단순히 돈을 벌기 위해 프로그래밍에 뛰어들었던 중간 계층의 사람들이 꽤 많았고, 그들은 대부분 부동산 등 다른 업계로 떠났습니다. 저는 지금의 중간 계층이 어디로 갈지 모르겠습니다. 25년 전보다 지금 그 중간층이 훨씬 더 크거든요.
마틴 파울러: 소프트웨어 업계의 구조조정과 제로 금리 시대의 종말 등으로 인해 그 중간 계층은 이미 어느 정도 쓸려나가고 있습니다. 이건 아주 흥미로운 차이점입니다. 왜냐하면 우리는 현재 AI 붐과 지난 2~3년간의 경제적 역풍을 동시에 맞고 있기 때문입니다. 90년대 닷컴 붐 때는 그냥 전체가 탄탄한 호황장이었기 때문에 지금과는 상황이 많이 다릅니다.
켄트 벡: 또 다른 흥미로운 요소는, 업계에 주기적으로 "야호! 이제 프로그래머들을 다 해고해도 된다!"라는 환상이 반복된다는 겁니다. 비즈니스 분석가들이 직접 프로그램을 작성할 수 있어서 더 이상 프로그래머가 필요 없을 거라고 믿었던 COBOL 시대부터 시작됐죠. 이런 환상은 계속 반복됩니다.
물론 애자일은 절대 그런 방향이 아니었습니다. 우리는 프로그래머들이 자신의 일에서 더 효과적이기를 원했고, 우리 스스로가 프로그래머였기 때문에 그 아젠다를 꽤 성공적으로 밀어붙일 수 있었습니다. 하지만 지금 다시금 "이제 프로그래머들을 다 없애버릴 수 있어"라는 반복되는 환상이 도래했습니다. 그렇다면 우리 프로그래머들은 왜 그들이 자꾸만 우리를 없애고 싶어 하는지에 대해 진지하게 고민해봐야 합니다. 그 이유의 일부는 우리에게 책임이 있고, 일부는 그렇지 않지만, 분명 우리에게 기인한 부분도 있습니다. 모두가 경험하고 있는 이 '공포(fear factor)'는 여기서 증폭됩니다.
마틴 파울러: 사람들이 "이제 코드의 시대는 끝났다. 6개월 후면 아무도 코드를 짜지 않을 것이다"라고 말하는 걸 들을 때마다 저는 스스로에게 묻습니다. "그렇다면 당신이 말하는 '코드'란 대체 무엇인가?" 그 말은 아무도 아무것도 작성하지 않는다는 걸 뜻하는 것 같습니다. 하지만 적어도 우리는 여전히 프롬프트를 작성하고 있고, 지니(AI)와 상호작용하고 있습니다. 그 상호작용의 형태가 어떤 방식이든 그것 역시 일종의 코드가 아닐까요? 앞으로 코드가 무엇인지에 대한 본질은 급격하게 달라질 가능성이 높지만, 어떤 형태로든 그것을 생산하고 상호작용해야 할 필요성은 여전히 존재할 것이라고 생각합니다.
🏢 엔터프라이즈의 현실과 프로그래밍의 고립화 (Resiloing)
진행자: 두 분을 진심으로 존경하는 이유 중 하나는 두 분 모두 두 발을 단단히 현실에 디디고 계시다는 점입니다. 우리는 놀라운 기술을 만들지만 동시에 자사 제품을 홍보해야만 하는 선도적인 연구소들의 이야기도 듣고, 많은 통찰력을 가진 사람들의 이야기도 듣습니다. 마틴, 당신은 쏘트웍스(Thoughtworks)를 통해 거대하고 보수적인 대기업뿐만 아니라 스타트업들과도 컨설팅 및 자문을 진행하며 많은 교류를 하고 있습니다. 켄트도 마찬가지고요. 현장에서 직접 보실 때, 이런 대기업이나 전통적인 기업들이 이 기술을 가지고 무엇을 하고 있으며 어떻게 생각하고 있는지, 놀라운 점은 무엇인가요?
마틴 파울러: 음, 현재 전반적인 분위기는 '대규모 혼란과 패닉(Confusion and panic)'입니다.
진행자: 만약 혼란과 패닉이 전략이라면 딱 정중앙에 계신 거네요.
마틴 파울러: 대기업들은 얽히고설킨 복잡한 시스템 안에 엄청난 양의 코드를 가지고 있습니다. 누군가 "이 AI 도구들이 100만 줄의 코드를 다룰 수 있나요?"라고 묻는다면, 그들 시스템 기준에서 100만 줄은 아주 작은 규모에 불과합니다. 스타트업 세계와는 상황이 완전히 다릅니다. 이들은 항공사 시스템을 하루 이틀 마비시킬 만한 위험을 감수하고 싶어 하지 않습니다. 그건 고려할 가치도 없는 선택지죠.
게다가 다른 리스크들도 있습니다. 놀라울 정도로 규모가 큰 회사들의 일부 그룹에서 이런 말을 하는 걸 여러 번 들었습니다. "LLM(대규모 언어 모델)에게 우리 이메일의 완전한 통제권을 주자. 내 이메일을 전부 읽고, 대부분의 이메일에 알아서 답장을 쓰게 하자." 그러면 저는 속으로 비명을 지릅니다. "안 돼! 제발! 무슨 소리야!" 그로 인한 보안 리스크는 상상을 초월합니다. 사람들이 이런 위험에 주의를 기울이지 않고 있기 때문에, 올해 아주 심각한 보안 사고가 터질까 봐 진심으로 우려됩니다. 그저 멋져 보이는 것에 눈이 멀어 달려들면서 진짜 우려해야 할 것들을 놓치고 있는 상황입니다.
켄트 벡: 제가 현장에서 보는 큰 트렌드 중 하나는 '프로그래밍의 재고립화(Resiloing)'입니다. 익스트림 프로그래밍(XP)의 큰 부분 중 하나는 본질적으로 '반사회적(antisocial)'인 프로그래머들을 위해 안전한 사회적 환경을 조성하는 것이었습니다. 단순히 비사교적(asocial)인 게 아니라 반사회적인 사람들 말입니다. XP 팀의 상호작용 수준을 생각해 보면, 사람들은 하루에도 몇 시간씩 서로 대화를 나눴고 그 환경이 긍정적인 경험을 주도록 설계되었기 때문에 기꺼이 그렇게 했습니다.
그런데 지금 제가 보는 현상은 이렇습니다. "나는 프로그래머고, 내 밑에 AI 에이전트 6개가 있어. 그러니까 나는 사실상 팀을 관리하는 매니저야." 아니요, 당신은 그저 한 번에 6개의 도구를 사용하고 있을 뿐입니다. 물론 그것 자체는 괜찮습니다만, 나와 믿음이 다르거나 오늘 나침반(에너지 레벨)의 방향이 다른 '진짜 사람'과 대화하는 것과는 완전히 다른 차원의 일입니다.
우리는 예전에 각자의 개인 사무실을 가졌던 시절을 기억할 겁니다. 문을 닫아버리고 그 밑으로 피자나 밀어 넣어주던 시절 말입니다. 매니저 입장에선 관리하고 통제하기 쉬웠죠. 그러다 갑자기 지저분하고, 사회적이고, 복잡하며, 혼란스러운 프로세스(애자일/XP)가 등장했는데, 공교롭게도 그게 정말 좋은 결과물을 냈습니다. 매니저들에겐 그게 너무 불편했죠.
그런데 이제 이렇게 생각하는 겁니다. "아싸! 50명의 팀원 대신 이제 5명만 있으면 되네. 얘네들은 서로 말 섞을 필요도 없고 각자 10개의 에이전트만 쥐여주면 똑같잖아!" 하지만 이건 절대 똑같지 않습니다.
마틴 파울러: 네, 저번 주에도 논의했던 질문 중 하나죠. 에이전트(AI)는 피자를 먹지 않기 때문에 기존의 '투 피자 팀(Two pizza teams, 두 판의 피자로 식사를 해결할 수 있는 규모의 팀)'이 '원 피자 팀'으로 줄어들 것인가? 아니면 투 피자 팀의 규모는 유지되되 훨씬 더 효율적이고 유능해질 것인가?
켄트 벡: 아니면 피자를 먹지 못하는 지니를 만들어낼 수도 있겠죠!
마틴 파울러: 제 예상은 '더 효율적인 투 피자 팀'에 걸겠습니다. 요즘 페어 프로그래밍(Pair programming)과 관련해서도 재미있는 피드백을 받기 시작했습니다. 사람 하나와 지니 하나가 짝을 이룬 것을 페어 프로그래밍이라고 부를까요? 아니면 사람 두 명과 여러 개의 지니가 함께하는 것일까요?
만약 사람 두 명이 함께한다면, 우리는 지니들을 조금 더 잘 통제할 수 있을 테고 인간끼리의 상호작용도 그대로 유지할 수 있습니다. 그래서 사람들이 그런 방식을 시도해 보고 어떤 결과를 얻었는지(페어 프로그래머들이 지니를 통제하는 방식, 나아가 몹 프로그래밍과 지니의 결합 등) 듣는 게 매우 흥미로울 것 같습니다. 저는 '한 사람이 여러 지니를 다루는 것'이 꼭 정답이라고는 생각하지 않습니다.
켄트 벡: 단지 이해하기에 가장 직관적이고 쉬운 프레임일 뿐이죠. 하지만 제 경험상 인간 2명과 지니(들)가 짝을 이뤄 작업했을 때의 결과는 매우 긍정적이었습니다. 그리고 지니들이 처리 속도가 느리다는 게 오히려 참 좋았습니다. 모델이 업데이트될 때마다 속도가 빨라지는데, 저는 "아, 대화할 시간이 줄어들었네"라며 아쉬워합니다. 프롬프트를 던지고 나면 AI가 3분 정도 묵묵부답일 때, 우리는 그 시간 동안 변수 네이밍 철학에 대해 토론하거나, 조건문을 어떻게 표현할지, 다음엔 뭘 해야 할지 대화를 나눌 수 있거든요. 만약 AI가 15초 만에 결과를 툭 뱉어낸다면 그런 대화를 나눌 틈이 없어집니다.
🛠️ 소프트웨어 장인을 위한 조언: 통제력을 놓고 도메인에 집중하라
진행자: 이제 마지막 질문을 드리고 Q&A로 넘어가겠습니다. 기술적 장인정신(Craft)을 사랑하고 이 업계를 사랑하게 된 소프트웨어 엔지니어와 리더들이 있습니다. 하지만 지금 많은 것들이 변하고 있습니다. 코드를 직접 쓰지 않게 되면서 통제력을 잃고 있죠. 이 거대한 추상화(Abstraction)의 변화 속에서 무너지지 않고, 나아가 성공적으로 살아남기 위해 이들에게 어떤 조언을 해주고 싶으신가요?
마틴 파울러: 지난주에 누군가 했던 말이 떠오르는데(누가 한 말인지는 기억 안 나지만), "개발자 경험(Developer experience)과 에이전트 경험(Agent experience)의 벤 다이어그램은 완벽한 원 하나로 겹친다"는 말이었습니다.
이 말의 요지는 에이전트에게 좋은 것은 결국 인간에게도 좋은 것이고, 그 반대도 마찬가지라는 뜻입니다. 요즘 "코드를 잘 모듈화해두면 에이전트가 작업하기 훨씬 쉬워진다"는 피드백을 많이 듣습니다. 또한 "좋은 테스트 코드에 집중하는 것은 인간뿐만 아니라 에이전트에게도 큰 도움이 된다"는 것도 이미 입증되고 있죠. 이 부분에서 엄청난 잠재적 시너지가 있다고 봅니다. (제가 그렇게 믿고 싶어서 하는 희망 사항일 수도 있지만, 적어도 당분간은 이 믿음을 밀고 나가보려 합니다.)
그러니 기존의 그 '장인정신의 기본 요소'들에 계속 집중하십시오. 그리고 그것을 활용해 에이전트를 가르치고, 최선의 표현 방법을 찾기 위해 에이전트와 함께 일하는 데 집중하세요. 제 동료 우나시와 대화하며 흥미로웠던 점은, 그가 에이전트와 일할 때 가장 효과적인 방법이 '도메인에 대해 에이전트와 소통하기 위한 정밀한 언어를 개발하는 것'이라고 말한 대목입니다. 이건 우리가 익히 알고 있는 모델 빌딩, 언어 구축, 도메인 주도 설계(DDD)와 완전히 같은 방식입니다. 단지 대화의 상대가 에이전트로 바뀌었을 뿐이죠. 이런 점들을 볼 때, 우리의 훌륭한 기존 관행과 앞으로 AI 시대에 필요한 역량 사이에는 분명 엄청난 교집합이 존재한다고 확신합니다.
켄트 벡: 저로 말하자면, 완벽한 코드 한 줄을 깎는 장인정신에서 일종의 강박적(OCD) 즐거움을 느끼는 부류의 사람입니다. 하지만 이제 저는 그것을 놓아주어야 합니다. 이 작은 함수 하나를 완벽하게 고쳐 썼을 때 느끼는 그 쾌감이, 이제는 전체적인 시스템 관점에서는 더 이상 큰 의미(차이)를 만들어내지 못하기 때문입니다.
이 말을 하면서도 참 슬픕니다. 저는 무아지경(in the zone)에 빠지는 걸 정말 좋아하거든요. 엉망진창인 거대한 파일 하나를 열어서, 아주 작고 안전한 단계들을 밟아가며 리팩토링합니다. 처음엔 이게 어디로 갈지 모르지만, 조금씩 희미한 빛이 보이기 시작하고, 마침내 탁! 하고 초점이 맞춰지며 모든 게 명확해지는 그 순간의 짜릿함! 아, 그 기분은 정말 최고였습니다. 하지만 이제는 그런 방식으로 일할 수가 없습니다. 저수준의 코드 깎기는 더 이상 레버리지(지렛대 효과)가 없기 때문입니다.
대신, 저는 제가 하고 있는 일에 대한 전체적인 이해(Overall understanding)를 발전시킬 수는 있습니다. 예전에는 프로그램 자체를 도메인으로 삼고 그것을 계속 다듬어가는 것에 집중했다면, 이제는 도메인 그 자체를 이해하고, 그 도메인이 내 프로그램과 어떻게 연결되는지 이해하는 것에서 즐거움을 찾는 방향으로 제 초점을 옮겨야만 합니다.