워드 커닝햄(Ward Cunningham)이 소프트웨어 개발에서 '복잡성'과 '단순함'의 진정한 의미를 깊이 있게 설명합니다. 그는 우리를 성장시키는 '힘을 주는 복잡성'과 단순히 진행을 방해하는 '어려움'을 구분하며, 단순함이란 결국 '해결책으로 가는 가장 짧은 길'이라고 정의합니다. 특히 개발 과정에서 벽에 부딪혔을 때, 완벽함 대신 "작동 가능한 가장 단순한 것"을 먼저 시도함으로써 사고의 흐름을 뚫고 앞으로 나아가는 통찰력을 제시합니다.
1. 우리를 성장시키는 복잡성 vs 괴롭히는 어려움
빌 베너스(Bill Venners)와의 대화에서 워드 커닝햄은 먼저 단순함과 복잡성에 대한 자신의 철학을 이야기합니다. 그는 모든 복잡성을 싫어하는 것은 아닙니다. 오히려 자신에게 도전 의식을 주고 능력을 키워주는 복잡성(Complexity that Empowers)은 즐긴다고 말합니다.
하지만 반대로 능력을 뺏어가는 복잡성(Complexity that Disempowering)은 경계합니다. 이런 복잡성을 이해하려고 노력하는 것은 지루한 노동일뿐이며, 자신의 능력 향상에 아무런 도움이 되지 않기 때문입니다. 워드는 친구의 말을 빌려 '문제(Problem)'와 '어려움(Difficulty)'을 명확히 구분합니다.
"세상에는 문제와 어려움이 있습니다. '문제'는 음미할 만한 것입니다. '음, 흥미로운 문제네. 잠시 생각해 보자'라고 말하며 생각하는 과정을 즐길 수 있죠. 해결책을 찾았을 때 깨달음을 얻기 때문입니다.
반면 '어려움'은 다릅니다. 컴퓨터는 어려움을 만들기로 유명하죠. 어려움은 단지 진행을 가로막는 장애물일 뿐입니다. 이것저것 시도하다가 마침내 작동하게 되더라도, 그것은 당신에게 아무것도 가르쳐주지 않습니다. 내일이면 상황이 또 달라질 테니까요. 컴퓨터를 작동시키려는 노력은 너무나 자주 '어려움'을 처리하는 과정이 됩니다."
우리가 혐오해야 할 대상은 바로 '어려움'을 만드는 복잡성입니다. 세상 자체는 원래 복잡하고 그 복잡함은 아름다울 수 있습니다. 그것을 이해하고 정복함으로써 배울 점이 있다면 그 복잡성은 가치가 있습니다. 🧠
2. 단순함: 해결책으로 가는 가장 지름길
그렇다면 단순함(Simplicity)이란 무엇일까요? 워드는 이를 "해결책으로 가는 가장 짧은 경로"라고 정의합니다.
예를 들어, 어떤 수학 문제를 20페이지에 걸쳐 증명했다고 칩시다. 나중에 누군가가 새로운 수학 이론을 도입해 이를 10페이지로 줄였다면, 비록 새로운 이론을 배워야 할지라도 더 짧은 경로이기에 '더 단순하다'고 볼 수 있습니다. 소프트웨어 개발도 마찬가지입니다.
🛤️ 프로그램을 다듬는 과정 (Working the Program)
소프트웨어에서 우리는 문제 해결의 가치를 얻기 위해 가장 쉬운 방법을 찾으려 노력합니다. 처음에는 자신이 생각한 최단 경로로 코드를 짜지만, 문제의 본질을 깨닫게 되면서 코드를 다시 작성합니다. 이 과정은 마치 수학 증명을 반복해서 다듬는 것과 같습니다.
- 30줄짜리 코드를 15줄로 줄일 수 있는 새로운 기능을 발견하면 코드는 더 이해하기 쉬워집니다.
- 이렇게 코드를 단순화하는 노력은 내일의 나를 더 강력한 프로그래머로 만듭니다.
✂️ 불필요한 것 덜어내기
단순함의 많은 부분은 '무엇이 중요하고 무엇이 중요하지 않은지'를 아는 데서 옵니다. 프로그램이 복잡해지는 이유는 종종 불필요한 세부 사항에 집착하기 때문입니다.
예를 들어, 모든 인자(argument)가 범위 내에 있는지 확인하는 코드가 프로그램의 절반을 차지한다면, 이는 프로그램을 더 좋게 만드는 게 아니라 더 나쁘게 만드는 것입니다. 물론 실수가 발생했을 때 프로그램이 즉시 멈추는 'Fail Fast'는 중요하지만, 어디서 체크할지 선택하는 것이 바로 단순화의 기술입니다.
워드는 아인슈타인의 유명한 말을 인용하며, 단순함과 기능 사이의 균형을 강조합니다.
"아인슈타인은 말했습니다. '가능한 한 단순하게, 하지만 그보다 더 단순하게는 안 된다(As simple as possible, but no simpler).'
그는 자신의 이론이 뉴턴보다 복잡하다는 비난에 대해 이렇게 답했습니다. 설명되지 않던 사실들을 설명하기 위해 모델이 더 복잡해졌지만, 그만한 가치가 있다는 것이죠. 그는 필요한 만큼 단순하게 만들었지만, 그 이상 단순화해서 본질을 해치지는 않았다는 뜻입니다."
오늘 우리가 작성한 단순한 프로그램은 내일 더 많은 기능을 수행하기 위해 복잡해질 수 있습니다. 하지만 우리는 내일의 필요에 맞춰 '다시 가능한 한 단순하게' 유지하려고 노력해야 합니다.
3. 막혔을 때는 "작동 가능한 가장 단순한 것"을 코딩하세요
워드 커닝햄은 익스트림 프로그래밍(XP)의 선구자인 켄트 벡(Kent Beck)과 스몰토크(Smalltalk) 언어로 함께 작업하던 시절의 일화를 들려줍니다. 스몰토크는 매우 강력해서 때로는 코딩이 놀라울 정도로 술술 풀렸지만, 때로는 꽉 막혀서 꼼짝도 못 할 때가 있었습니다.
그럴 때마다 워드는 켄트에게 마법 같은 질문을 던졌습니다.
"켄트, 작동 가능한 가장 단순한 방법(the simplest thing that could possibly work)은 무엇일까?"
💡 질문의 힘: 목표에 집중하기
이 질문의 핵심은 사고의 전환입니다.
- 내일 코드를 읽을 사람을 걱정하지 마세요.
- 효율적인지 고민하지 마세요.
- 심지어 이게 진짜로 작동할지조차 걱정하지 마세요.
그저 "지금 당장 작동할 가능성이 있는 가장 단순한 것"이 무엇인지만 생각하는 것입니다.
일단 코드를 작성해서 화면에 무언가 나타나게 하면, 우리의 생각은 정리됩니다. 머릿속에만 있던 모호한 아이디어가 눈앞의 구체적인 코드로 바뀌면, 비로소 우리는 "아, 이제 어떻게 해야 할지 알겠어"라고 말할 수 있게 됩니다.
🚦 명령이 아닌 질문
워드는 이 문장이 "작동 가능한 가장 단순한 것을 해라(Do)"라는 명령형으로 변질되는 것을 우려합니다. 명령이 되면 사람들은 "이게 진짜 제일 단순한 건가?"라고 분석하고 고민하느라 오히려 더 복잡해지기 때문입니다.
원래 의도는 "무엇이 가능할까?"라고 묻는 것이었습니다. 아무것도 없는 상태에서 벗어나, 화면에 뭐라도 띄워놓고 보자는 전략입니다.
"우리는 항상 최대한 많은 것을 하라고 배웁니다. 항상 예외를 체크하고, 가장 일반적인 경우를 처리하고, 친절한 에러 메시지를 출력하라고 하죠. 해야 할 게 너무 많아서 생각할 여유가 없습니다.
저는 말합니다. 그 모든 걸 잊어버리고 스스로에게 물어보세요. '작동 가능한 가장 단순한 방법은 무엇일까?'"
🧠 인지 부하 줄이기
이 방법의 진짜 가치는 머릿속에 담아둬야 할 정보의 양을 줄여주는 데 있습니다. 5가지를 동시에 생각하며 결정하기 힘들다면, 3가지로 줄이고, 그래도 안 되면 단 1가지만 생각하세요.
때로는 선형 탐색(Linear Search) 같은 무식하고 단순한 코드가 답일 때가 있습니다. 나중에 다른 프로그래머가 보고 "왜 여기서 이진 탐색을 안 썼지? 바보 아냐?"라고 할 수도 있습니다. 하지만 그 단순한 코드가 작성 당시에는 작동하는 해결책이었고, 덕분에 다음 단계로 넘어갈 수 있었습니다. 게다가 단순한 코드는 누가 봐도 1분 만에 이해할 수 있다는 장점도 있죠! 👍
마무리
워드 커닝햄은 개발 과정에서 겪는 '막막함'을 해결하는 가장 강력한 도구로 단순함을 제시합니다. 우리가 코드를 짤 때 겪는 어려움의 대부분은 너무 많은 것을 한꺼번에 완벽하게 처리하려는 욕심에서 비롯됩니다.
복잡한 요구사항과 의무감에 짓눌려 앞으로 나아가지 못하고 있다면, 잠시 멈춰서 스스로에게 물어보세요. "지금 당장 작동할 수 있는 가장 단순한 건 뭐지?" 그 작은 단순함이 꽉 막힌 문제 해결의 물꼬를 트는 시작점이 될 것입니다.