프로그래밍, 구현이 더 중요? 설계가 더 중요?

 

© annca, 출처 Pixabay

​

"프로그래밍은 잘 동작만 하면 된다"

프로그래밍을 하는 사람이라면 누구나 한 번쯤은 언젠가 들어봤을 이야기입니다. 맞는 말입니다. 하지만, 오해를 부르기도 좋은 말입니다.

​

이 말은 마치,

"[설계를 대충 해도,] 프로그래밍은 잘 동작만 하면 된다"

라고 말하는 것처럼 보입니다.

​

이렇게 한 번 비유해볼까요.

"설계를 대충 해도, 집은 잘 살기만 하면 된다"

어떤가요? 제가 느끼기엔, 앞뒤가 안 맞는 말로 보입니다. 집을 대충 설계하고 지었는데 잘 살아질 리가 없죠. 어딘가 분명 문제가 있을 겁니다. 고려되지 않은 배선, 수도관, 보일러, 에어컨 위치, 방음재, 단열재, 마감, 바닥재 등등등... 고려할 것이 많은 만큼, 살기 좋은 집을 지으려면 집을 대충 설계할 순 없습니다.

​

다시 말해서, "설계를 대충 해도, 프로그래밍은 잘 동작만 하면 된다?" 위 비유와 마찬가지로, 그럴리 없다고 생각합니다. 만약 대충 짰는데 잘 돌아갔다면 운이 좋은 것이겠죠. 프로그래밍을 운빨에 맡기겠다면 말리진 않겠습니다만, 저는 그렇게 코딩하진 않겠습니다. 왜냐하면... 매번 사는 로또마다 꽝이었거든요.

​

"프로그래밍은 잘 동작만 하면 된다"는 이야기는 객체지향 설계에 대한 중요성이 크게 강조되지 않았던 10~20여년 전쯤부터 줄곧 들었던 말입니다. 제가 코딩을 시작한 것이 10여년 전이니, 훨씬 더 옛날부터 쓰여왔겠죠. 즉, 이미 20년 이상 낡은 페러다임이라고도 볼 수 있습니다. 과거에는 객체지향을 쓰니 마니부터 심심치 않게 논쟁을 하던 시기라, 객체지향도 심판대 위에 올리는데 설계는 명함도 못 내밀었을 것 같네요.

​

그래서 결론은 설계가 먼저냐?

아뇨. 아직 결론을 내긴 이릅니다.

​

잠깐 시나리오에서의 "플롯(Plot)"을 이야기 해보겠습니다. "플롯"은 이야기의 사건과 인과관계의 엮임, 즉 구성을 일컫는 말입니다. 이야기의 설계라고도 볼 수 있습니다. 인물A와 인물B, 사건A와 사건B 가 있을 때, 이 요소들 사이의 관계와 상호작용을 엮어 플롯이 완성됩니다. 다양한 인물들이 등장할 수도 있고, 그런 인물들도 각각의 사건과 관계를 가지며 상호작용합니다. 이렇듯 전자기장처럼 이야기의 요소들을 엮는 구성을 플롯이라고 하며, 플롯이 곧 이야기의 근간이 됩니다. 즉, 작문이 이야기를 만드는 것이라면, 플롯은 작문에 포함되는 작업이고, 포함 관계이기 때문에 둘의 중요도를 구분하는 것은 무의미합니다.

​

저는 프로그램 설계가 이야기의 플롯과 유사하다고 생각합니다. 인물과 사건들의 관계 구성을 설계하듯, 프로그램의 설계도 데이터와 동작, 알고리즘의 관계를 구성하는 작업입니다. 객체지향프로그래밍이라면 객체들간의 관계가 되겠죠. 데이터과 로직의 관계, 책임과 동작의 배치 등등 모두 구현 작업에 포함된 것들입니다. 플롯을 만드는 것이 곧 작문인 것처럼, 설계는 프로그램 구현에 완벽하게 포함됩니다.

​

"이야기를 먼저 쓰고 플롯은 나중에 쓰겠다"는 말이 성립할 수 없는 것처럼, "구현을 먼저 하고 설계는 나중에 하겠다"는 말 역시 성립될 수 없습니다. 프로그램을 설계하는 것이 곧 구현의 일부이기 때문입니다. 만약, "빠른 구현을 위해 설계는 포기하고 나중에 하겠다"는 생각을 가진다면, 그건 그저 "구현을 엉터리로 하겠다"는 말과 같습니다.

​

프로그램을 구현한다는 것은 설계와 더불어, 입력 처리, 로직, 데이터 추가, 예외처리 등 모든 작업요소를 아우릅니다. 결과적으로, 구현과 설계 중 무엇이 중요하냐는 의문은 큰 의미가 없습니다. 구현이 중요하다면 당연히 그 속에 포함된 설계도 중요한 것이고, 설계가 중요하다면 설계를 포함하는 구현 역시 중요하다는 말과 같기 때문입니다.

​

결론,

설계는 구현에 포함관계이기 때문에, 좋은 설계는 좋은 구현으로 이어지고,

구현이 중요하다면 그 속의 설계도 그만큼 중요해집니다.

​

덧) 좋은 설계가 결코 과(過)설계는 아닙니다. 현실적으로 한정된 여러 자원에 맞게 합리적인 설계를 좋은 설계라고 할 수 있습니다.