Design 원칙

켄트 벡의 방한으로 Responsive Design 세미나 내용이 여러 사람들에 의해 회자되고 있다. 사실 3일 동안의 애자일 워크샵에 신청했다가 회사에 거부 당한 이후 조금 마음이 상한 상태였지만 Design 논란은 쉽게 지나칠 수 없어서 Design에 대한 내 생각을 정리해 보았다. (참가비 180만원. 경기가 안좋고 회사는 긴축 재정. so what? 그래서 투자도 안하는건가? 아니면 내가 그 이상의 가치를 회사에 가져다 주지 못할 것이라 판단한 것일까? 부자 회사에 있었으면 됐을까? 이해는 되지만 실망스럽다.)

켄트 벡의 신기한 점은 고민을 구체화시키고 정리하고 단순화하는 능력인 것 같다. 자신이 코딩을 하면서 디자인을 하는 순간들을 인덱스 카드에 바로 바로 적은 후 그 카드들을 종류별로 분류를 했더니 다음과 같은 4가지 선택이 있었다고 한다. (이에 대해 정리된 글은 쉽게 찾아볼 수 있을텐데, 노파심으로 링크 하나 추가해 본다. Xper 메일링 리스트에 남긴 창준님 의견)

• Leap – 도약
• Parallel – 병렬
• Stepping Stone – 징검다리
• Simplification – 단순화

그래서 난 인덱스 카드에 적어보진 않았지만 내가 프로그래밍을 하거나 시스템 구조를 설계할 때 어떤 고민을 하고 어떤 행동을 취했는지 되돌아 보았다.

머리 속에서 코딩하기 – 조금 복잡한 문제는 바로 코딩을 하지 않고 머리 속으로 전체 구조를 그려본다. 이때 전체 구조는 거의 코드 레벨로 메소드 또는 그보다 작은 기능 덩어리로 머리 속에서 구체화되고 그 후에 실제 코딩을 시작한다. 이렇게 개발할 때는 이미 정리된 전체적인 모습을 코드로 옮기기만 하면 되기 때문에 TDD를 하지 않는다. 장점은 완결된 형태로 기능이 잘 구현되는 것이고, 단점은 패턴으로 연결된 요소가 아닌 하나의 흐름 덩어리로 코드가 만들어지는 것이다.

한 단계씩 밟아가기 – 무엇을 만들어야 하는지 확실하지 않을 때는 테스트 케이스를 먼저 만들면서 문제 자체를 구체화 해간다. 이때는 TDD를 하게 되는데 보통 PP를 할 때도 TDD를 같이 수행한다. 또는 구현하려는 기능에 대해 구현법 자체가 모호할 때(자주 사용하지 않는 java package를 사용하는 경우)도 한 단계씩 밟아 나가면서 문제를 해결한다.

장애처리 또는 디버깅 하기 – 이때는 일반적인 방법을 활용한다. 가장 최근에 변경된 사항 살펴보기, 문제의 가장 핵심 지점을 찾고 그 원인을 해결하기, 구조적 모순을 찾고 다른 방식으로 이 문제 해결하기 등을 사용한다. 이때 관건은 정확하고 필요한 정보를 어떻게 얻어낼 수 있냐인 것 같다.

재미 없는 개발하기 – 단순한 운영툴이나 외부 연동을 통한 지루한 작업을 할 때는 PP를 선호한다. 뭐랄까 꾸역꾸역 해나가는 맛이 있다고 할까? 이때 만들어야 하는 output(화면, UI)부터 만들어서 server side로 거꾸로 개발을 하면서 개발의 흐름의 끈을 놓치지 않는 것이 중요하다.

이렇게 정리를 해보니 Design 문제가 아니라 개발 practice들이 나열이 된 것 같다. 아마 켄트 벡은 이런 practice를 말하는 것을 조심스러워 하기 때문에 더 원론적인 얘기를 하게 된 것이 아닐까. context 없이, 원칙 없는 실천법은 그 의미를 잃을 수 밖에 없으니까 정제된 원칙에 대한 깨달음을 전달해주고 있는 것 같다.

여하튼 한번쯤은 켄트 벡 방식으로 내 머리속의 흐름을 눈 앞에 꺼내볼 필요가 있다. 그리고 그 속에서 패턴을 찾아 발전시켜 나가면 내 자신에게도 그리고 내 주위의 사람들에게도 도움일 될 것이다.