왜 우리는 프로토타입을 만들어야하는가?

프로토타입은 정답을 만드는 단계가 아니다

프로젝트를 작업할 때 나는 우선 프로토타입을 먼저 만들어보는 편이다.

그런데 돌이켜보면 프로토타입을 만드는 과정에서 프로젝트를 포기하는 경우가 많았다.

이유는 단순했다.

나는 프로토타입의 의미를 잘못 이해하고 있었다.

프로토타입은 왜 만드는가?

프로토타입은 정답을 만드는 단계가 아니다.

프로토타입은 무엇을 만들어야 하는지 알아내는 단계다.

예를 들어 요즘 나는 토이 프로젝트로 탑뷰 던전 게임을 만들고 있다.

기대하는 결과는 아이작과 비슷하다.

절차적으로 룸이 생성되고, 방과 방이 연결되며, 플레이어가 던전을 탐험하는 구조다.

그런데 단순히 “맵 제너레이터를 만든다”는 생각만 해도 고민이 많아진다.

1. 방의 타입은 무엇이 있어야 할까?
   몬스터방, 황금방, 희생방?
2. 방의 구조는 어떤 형태여야 할까?
   직사각형, 정사각형, L자 구조, 다각형?
3. 각 층마다 방의 개수는 몇 개가 적절할까?

하지만 이런 고민들은 프로토타입의 첫 단계에서 전부 해결할 필요가 없다.

프로토타입에서는 우선 러프하게 동작하는 형태를 만들고,

그 결과를 보면서 다음 질문을 던지는 것이 더 중요하다.

예를 들면 처음에는 방 5개만 생성해도 된다.

모든 방은 사각형이어도 된다.

방 타입도 시작방, 일반방, 보스방 정도면 충분하다.

중요한 것은 완벽한 던전 구조가 아니다.

중요한 것은 “이 방식이 게임으로서 가능성이 있는가?”를 확인하는 것이다.

Code Complete 2에서 말하는 첫 번째 버전

Code Complete 2에서는 Fred Brooks의 말을 인용한다.

“Plan to throw one away; you will, anyhow.”

번역하면 다음과 같다.

“첫 번째 버전은 버릴 생각으로 만들어라. 어차피 버리게 된다.”

처음부터 완벽한 구조를 만들 수는 없다.

오히려 너무 이른 시점에 미래의 모든 요구사항을 예상하려 하면

구조가 불필요하게 커질 수 있다.

그래서 프로토타입 단계의 코드는 버릴 수도 있다고 생각하고,

가능한 싸게 만드는 것이 좋다.

여기서 말하는 “싸게”는 아무렇게나 만든다는 뜻이 아니다.

이름, 책임, 흐름은 알아보기 쉽게 만들되,

미래의 모든 가능성을 위해 과한 추상화를 하지 않는다는 뜻이다.

미래를 예측하는 설계는 자주 틀린다

내가 프로토타입에서 구조를 과하게 고민하는 이유는

나중에 어차피 구현해야 할 것들이라고 생각하기 때문이다.

방 타입도 결국 필요할 것이다.

다각형 방도 언젠가 필요할 수 있다.

층마다 방 개수도 조절해야 할 것이다.

방과 방의 연결 구조도 필요하다.

그러면 이런 생각이 든다.

“어차피 나중에 만들 거면 지금부터 제대로 구조를 잡는 게 맞지 않을까?”

하지만 문제는 미래의 요구사항을 지금 정확히 알 수 없다는 점이다.

지금은 다각형 방이 중요해 보일 수 있다.

하지만 실제로 플레이해보면 다각형 방보다 좁은 복도와 손전등 시야가 더 중요할 수 있다.

지금은 특수방이 중요해 보일 수 있다.

하지만 실제로는 몬스터의 등장 타이밍과 공포 연출이 더 중요할 수 있다.

즉, 프로토타입 이전의 설계는 실제 결과가 아니라 상상에 기반한 설계다.

그리고 상상에 기반한 설계는 자주 틀린다.

프로토타입은 실패를 발견하는 단계다

프로토타입은 성공 가능성을 확인하는 단계이기도 하지만,

더 정확히는 실패 원인을 발견하는 단계에 가깝다.

예를 들어 처음에는 랜덤 던전 생성이 이 게임의 핵심이라고 생각할 수 있다.

하지만 막상 만들어보니 랜덤 던전보다 손전등 시야가 더 재미있을 수도 있다.

처음에는 방의 형태가 중요하다고 생각했지만,

막상 플레이해보니 방의 형태보다 문을 열고 들어가는 순간의 긴장감이 더 중요할 수도 있다.

이런 사실은 머릿속에서 설계만 해서는 알 수 없다.

직접 만들어보고, 직접 플레이해봐야 알 수 있다.

그래서 프로토타입의 목적은 완성형 구조를 만드는 것이 아니다.

프로토타입의 목적은 내가 무엇을 잘못 생각하고 있었는지 확인하는 것이다.

좋은 구조보다 먼저 필요한 것

개인 프로젝트나 게임잼에서는 특히 더 중요한 기준이 있다.

완성된 기능은 100점이다.

하지만 동작하지 않는 좋은 구조는 0점이다.

예를 들어 A 개발자는 완벽한 룸 생성기 구조를 만들었다.

인터페이스도 있고, 전략 패턴도 있고, 팩토리 패턴도 있다.

하지만 아직 플레이할 수 있는 게임은 없다.

반대로 B 개발자는 코드가 조금 지저분하다.

if문도 많고, 하드코딩도 있다.

하지만 플레이어가 방을 이동하고, 몬스터가 나오고, 게임을 플레이할 수 있다.

출시 관점에서는 B가 이긴다.

유저는 코드 구조를 보지 않는다.

유저는 게임이 재미있는지를 본다.

좋은 코드는 무엇인가?

Code Complete 2를 읽으며 내가 이해한 좋은 코드의 기준은 다음과 같다.

좋은 코드는 멋진 구조를 가진 코드가 아니다.

좋은 코드는 복잡도를 줄이고,

사람이 이해하고,

수정하기 쉬운 코드다.

그래서 지금 내가 생각하는 개발 순서는 다음과 같다.

내가 생각하는 개발 순서

1. 먼저 그냥 만든다

단, 막 만들지는 않는다.

이름, 책임, 흐름은 알아보기 좋게 만든다.

2. 두 번째로 비슷한 요구가 나오면 분리한다

처음부터 확장성을 만들려고 하지 않는다.

반복이 보일 때 구조화한다.

3. 세 번째 변경이 보이면 추상화한다

“이 부분은 계속 바뀌겠구나”가 확실해졌을 때

인터페이스, 전략 패턴, 데이터화 같은 방법을 사용한다.

프로토타입에서 버려도 되는 것과 버리면 안 되는 것

프로토타입 코드는 버려도 된다.

첫 번째 버전은 어차피 부족하다.

처음 만든 구조도 틀릴 수 있다.

하지만 프로토타입에서 얻은 경험은 버리면 안 된다.

왜 재미없었는지.

왜 복잡했는지.

왜 필요 없었는지.

어떤 기능이 생각보다 중요했는지.

어떤 기능이 생각보다 중요하지 않았는지.

이런 경험은 다음 개발 단계에서 가장 중요한 기준이 된다.

결국 첫 번째 버전은 버려도 된다.

하지만 첫 번째 버전에서 얻은 교훈은 버리면 안 된다.

결론

프로토타입의 목적은 정답을 만드는 것이 아니다.

프로토타입의 목적은 무엇을 만들어야 하는지 알아내는 것이다.

처음부터 완벽한 구조를 만들려고 하면 오히려 시작이 어려워진다.

미래의 모든 요구사항을 예상하려 하면 구조는 커지고,

구현은 느려지고,

프로젝트는 멈출 가능성이 높아진다.

그래서 프로토타입에서는 먼저 작게 만들어야 한다.

동작하게 만들고,

직접 확인하고,

그 결과를 바탕으로 다음 구조를 결정해야 한다.

좋은 개발은 처음부터 완벽한 설계를 하는 것이 아니다.

좋은 개발은 틀릴 수 있다는 사실을 인정하고,

작게 만들고,

확인하고,

수정해가는 과정이다.

 

그럼 좋은 코드는 무엇인가?

프로토타입에 대한 생각을 정리하다 보니 다음 질문이 생겼다.

 

프로토타입은 일단 동작하게 만드는 단계라고 하자.

그렇다면 실제 프로젝트 단계에서는 무엇을 기준으로 코드를 작성해야 할까?

 

나는 오랫동안 좋은 코드란

복잡한 구조,

많은 디자인 패턴,

높은 확장성,

인터페이스가 가득한 구조라고 생각했다.

 

하지만 Code Complete 2를 읽으며 생각이 조금 바뀌었다.

 

좋은 코드는 미래를 맞추는 코드가 아니다

Code Complete 2에서는 리팩토링을 다음과 같이 설명한다.

 

"Make it easier to understand and cheaper to modify."

 

내가 이해한 의미는 단순하다.

 

좋은 코드는 미래를 완벽하게 예측한 코드가 아니다.

좋은 코드는 미래가 틀렸을 때 수정하기 쉬운 코드다.

 

개발을 하다 보면 예상은 항상 틀린다.

처음에는 필요할 것 같았던 기능이 사라지기도 하고,

전혀 예상하지 못한 기능이 중요해지기도 한다.

 

결국 중요한 것은

얼마나 많은 미래를 예측했는가가 아니라

얼마나 쉽게 변경할 수 있는가이다.

 

복잡한 구조보다 이해 가능한 구조

Code Complete 2에서는 지속적으로 복잡도(Complexity)를 줄이는 것을 강조한다.

 

내가 읽으며 가장 크게 느낀 점은 이것이다.

 

복잡한 문제를 해결했다고 해서 좋은 코드가 되는 것은 아니다.

복잡한 문제를 단순하게 표현해야 좋은 코드가 된다.

 

예를 들어 300줄짜리 메서드 하나가 있다고 하자.

 

동작은 완벽할 수 있다.

버그도 없을 수 있다.

 

하지만 내가 3개월 뒤에 다시 봤을 때

이해하는 데 1시간이 걸린다면

좋은 코드라고 보기 어렵다.

 

반대로 기능은 동일하지만

함수가 나뉘어 있고,

이름이 명확하고,

흐름이 보인다면

수정 비용은 훨씬 줄어든다.

 

사람이 읽기 위한 코드

Code Complete 2에는 이런 내용도 나온다.

 

"Programs are written for people to read."

 

결국 코드는 컴퓨터가 실행하지만

읽는 것은 사람이다.

 

그래서 내가 최근 중요하게 생각하는 기준은

컴퓨터보다 사람에게 친절한 코드다.

 

• 변수 이름만 봐도 역할을 알 수 있는가?
• 함수 이름만 봐도 의도를 알 수 있는가?
• 주석 없이도 흐름이 보이는가?
• 수정해야 할 위치를 쉽게 찾을 수 있는가?

 

이런 질문들이

디자인 패턴을 몇 개 사용했는지보다 훨씬 중요하다.

 

내가 생각하는 좋은 코드 작성 순서

현재 내가 내린 결론은 다음과 같다.

 

1. 먼저 동작하게 만든다

프로토타입 단계에서는 특히 중요하다.

정답을 찾기 위해 만든다.

 

2. 이해하기 쉽게 만든다

변수명,

함수명,

책임 분리를 통해

다시 봤을 때도 이해할 수 있게 만든다.

 

3. 반복이 보이면 분리한다

비슷한 코드가 두 번 나오기 시작하면

그때부터 구조화를 고민한다.

 

4. 변경이 반복되면 추상화한다

세 번째,

네 번째 변경이 발생하기 시작하면

인터페이스,

전략 패턴,

데이터화를 고려한다.

 

내가 내린 결론

예전의 나는

좋은 코드를 만들기 위해 구조를 고민했다.

 

지금의 나는

좋은 코드를 만들기 위해 수정 비용을 고민한다.

 

좋은 코드는 가장 똑똑한 코드가 아니다.

좋은 코드는 가장 오래 살아남을 수 있는 코드다.

 

그리고 오래 살아남는 코드는

복잡한 코드가 아니라

사람이 이해할 수 있는 코드다.