설계를 잘하는 방법

1. 사업적 목표(Business Goal)를 먼저 정의하라.

왜 새로운 소프트웨어가 필요한지를 정의해야 한다. 이루고자 하는 것이 무엇인지, 왜 투자되는지를 생각해야 한다.

“개발자의 눈으로 Business Roadmap을 해석하는 것을 Technical Roadmap이라고 한다.”

이것은 개발자 및 기획자들의 불필요한 노력을 줄여주고, 협업 구성원들이 쉽게 이해하게 함으로써 조직 역량을 쉽게 집중할 수 있게 해준다.

2. 사용자(User)가 서비스를 어떻게 사용하는지를 정의하라.

사용자는 “직접적인 사용자”를 말한다. 사용자가 이 서비스를 어떻게 사용할지 상상이 되지 않는다면, Architecture를 그리기 시작해서는 안된다. 이 상상은 예외로 인한 에러나 오류가능성을 줄여준다. 이 상상이 많을수록 Architecture의 Detail 이 높아진다.

좀 더 현실에 가까운 시나리오를 찾아서 정의하고, 구성원들간에 공유해야 한다.

3. 시나리오를 너무 일반화하지마라.

개발자가 하나의 모듈로 이것도 할 수 있고 저것도 할 수 있다고 말하는 것은 좋은 것이 아니다. 이 모듈이 얼마나 서비스 요건을 정확하고 빠르게 구현해 주는지에 초점을 맞추어야 한다.

너무 일반화하면, 구현해야 할 기능이 모호해지게 된다. 명확할수록 구현하기 쉬워진다.

4. 누가 어떻게 유지보수할 것인가를 생각하라.

“유지보수 하기 힘든 소프트웨어는 쓰레기다.”

서비스나 소프트웨어는 살아움직이는 것이다. 운영될 때 주로 어떤 일들이 일어나는지 미리 확인하고 정의해야 한다.

오픈소스나 상업용 패키지의 white paper가 말하는 유지보수의 편의성은 자주 “서버개발을 아주 잘 이해하고 지식이 풍부한 초급 웹개발자가 쉽게 할 수 있는 일”(대단히 모순적인)로 정의되어 있기도 하다. 초급 웹개발자가 할 일인지. 중급 서버개발자가 개발할 일인지 어떤 언어를 쓸건지 결정을 해야 한다.

유지보수할 개발자를 구할 수 없으면, 그 서비스나 소프트웨어의 생명주기는 다 했다고 보아야 한다.

5. 서비스가 잘 되면 어떤 이슈들이 생길 것인가?

Architecture란, 서비스가 잘 될 경우 Flexibility를 확보하기 위해 사용을 하는 것이다. 중요한 것은 대용량 트래픽에 대한 Flexibility 인지, 신규 서비스 로직에 대한 Flexibility 인지에 따라 구현해야 할 요건이 틀리게 된다.

모든 걸 다할 수 없기 때문에, 어떤 부분이 부족한지를 이해하고 있어야 한다.

6. 고객을 분석할 수 있는 로그 데이터를 남겨야 한다.

“고객 로그 데이터”는 사업에 있어서 매우 중요한 것이다.

로그를 무의미하게 남기고 무의미하게 지워버리는 일은 하지 마라. 로그는 Architecture에서 빼놓지 않고 설계해야 할 중요한 요소이다. 사용자 로그는 서비스나 소프트웨어의 투자방향을 결정짓는 제 1의 데이터 요소이다.

7. 프로세스 자동화는 반복작업이 있을 때만 의미가 있다.

2년에 한 번 쓰일 작업을 위해 3개월 동안 개발하는 것은 아주 어리석다. 그냥 삽질하는게 낫다. 프로세스가 자주 발생되고 중요하게 될 때 자동화하는게 좋다. 문제에 대처하기 위해 절차를 우선시 하는 것은 좋지 않다.

8. 부가가치는 사람에 의해서 만들어진다.

좀 철학적인 이야기지만, 단순화된 자동화 프로세스나 서비스에서 정말 핵심적인 부가가치는 만들어지지 않는다. 결정적인 부가가치를 만드는 것은 사람의 생각과 노력이 들어가야 한다. 좋은 설계는 사람이 개입하는 부분을 현명하게 남겨둔다.

누가, 왜, 어떻게, 어느 부분에 개입되는지를 남겨두어야 한다.

출처: https://subokim.wordpress.com/2011/08/30/how-to-design-software/