Xeraph@NCHOVY

오늘도 술을 좀 먹고 들어오는데..
(벌써 수, 목, 금, 월 아아아이고-_-)

주 전임님이 말씀하시길, 음..설계를 잘 할라면 아무래도 특정 분야의 솔루션만 5~6년을 개발해봐야 깔끔한 설계를 낼 수 있는게 아닌가 생각이 든다고 하시길래. 그건 설계를 잘 할 줄 아는게 아니라 수 년의 삽질스러운 시행 착오로 얻어낸 경험이라고 얘기했다.

나는 Bottom-up 방식을 더 좋아하긴 하지만 당연히 적절한 정도의 초기 설계는 해야된다고 생각한다. 아예 스케치조차 안 하면 안 해도 될 삽질을 쓸데없이 많이 하게 될 가능성이 높으니까.

그렇지만 완전히 Model Driven으로 가는 것은 어떠냐면 그건 반대다. 원래 훌륭한 아이디어는 추상적인 계층과 구체적인 계층을 왔다리 갔다리 해야만 튀어나오는 것이기도 하고. 너무 관념적인 계층에 매달려 있으면 구체적인 계층의 문제를 간과하기 쉽고, 반대로 구체적인 계층에 매달려 있으면 큰 그림을 보기 어렵기 때문에 커다란 블럭을 쌓아올리는 생각을 하기 어렵다.

결국은 일단 현업에서 사용되는 핵심 개념부터 먼저 명료하게 정리한 다음에, 필요한만큼 모델링하고, 구현하고, 또 모델링하고, 구현하고, 이것을 반복해나가는 것이 좋다고 생각한다. 물론 비슷한 솔루션을 구현한 경험이 꽤 있다면 어떻게 하는 것이 좋고 나쁜지 감각이 있을테니까 자기가 자신있는만큼은 한 방에 설계를 해도 좋겠지만, 역시 너무 앞서나가지는 않는 것이 좋다.

그렇지만 다들 학교에서 배워먹은게 있기 때문에, 뭐든지 up-front로 하지 않으면 안 될 것 같은 그 강박관념을 피하기는 꽤나 어렵다. 요구분석을 다른 것보다 먼저 해야 해요. 인터랙션 디자인을 다른 것보다 먼저 해야 해요. 시스템 설계를 다른 것보다 먼저 해야 해요. 데이터 스키마 설계를 먼저 해야 해요. 이 책 보고 저 책 보면 서로 이거를 먼저 하는게 이득이 된다고들 난리다. 개별로 따져보면 맞는 말 같지만 결국은 그걸 합쳐야 된다는건데, 우겨대는대로 순서만 매기다보면 결국 고통스러운 폭포수 모델만 남을 뿐이거든.

나도 말은 이렇게 하지만 실천하는 것은 대단히 어려운 일이어서, 아니 그리고 어차피 나 혼자 튄다고 되는 개발도 아니기 때문에, 데이터베이스 설계 다 나와있고, 그 상태에서 데이터 플로우 정도는 다 그려놓고 코딩하고 있기는 하지만, 하여간 waterfall은 뭐가 제대로 굴러가고 있기는 있는지 확인이 어렵기 때문에 꽤 불안할 수 밖에 없다. 원래 이런 상황을 관리하기 위해 어지간히도 감당 못할 문서들을 찍어내는 것이기도 하고. 하여간 가능한 인수 테스트를 기준으로 Function Driven Development를 지향하려고 노력하고 있기는 하지만, 모듈 별로 역할 분담해놓은 상태에서는 다들 자기 모듈만 따로 일정 질러나가기가 쉬운 법이라, 이것을 설득하고 제어하는 것은 그리 만만한 일은 아니다.

쓰다보니 삼천포다.
역시 자야 될 시간인가.

아..그리고 객체 모델링 방법은 공부를 많이 해두면 확실히 좋다. 꼭 정규화 정해진 규칙대로 진행하는 것처럼 모델링도 그렇게 해버리기 때문에 아무 생각 없는 것처럼 보여도 착착착~