설계 필요한 것일까요?

[이춘식]

안녕하세요? 다소 촌스러운 질문일까요?

여기에 계신 훌륭한 분들의 의견을 듣고 싶습니다.

여기서 찾은 인상 깊은 글은 여기에 있고, https://groups.google.com/d/msg/xper/9Ae5MvPDfmY/UnuVij4bTbgJ

제가 드린 질문에 이렇게 좋은 답변도 해주셨습니다. http://allofsoftware.net/entry/IsDesignNeeded

설계와 설계서를 구분할 필요는 있겠지만, 설계서가 필요한가에 대한 의문을 제기하시는 분들도 많은 듯 합니다.

많은 의견 부탁드립니다.

[gyehong park]

allofsoftware.net 에 있는 블로그에는 좀 이상한 부분이 보이네요.

논의는 다른 분이? ^^;;; ㅜㅡ

2011년 12월 23일 오전 11:49, 이춘식 <choo...@gmail.com>님의 말:

[Sangcheol Hwang]

안녕하세요.

두번째 링크에 나온 내용도 대체로 맞는 내용인거 같습니다.

다만 스펙의 예가 조금 거시기 하네요. 1~5년 이내에 생길 일에 대한 스펙을 예로 들고
있는데 그런 문제는 당장 설계를 잘못했다고 문제가 되기 보다는 1~5년 후에 생기지 않을까요. ^^;
오히려 당장 구현하려는 기능과 직접 관련된 스펙이 중요할거 같아 보입니다.

계홍님 생각하시는 이상한 부분은 어떤 부분이신가요?

2011/12/23 gyehong park <gyeho...@gmail.com>

--
Blog: http://pragmaticstory.com
Twiter: @k16wire

[June Kim (김창준)]

질문이 너무 추상적이고 광범위해서 제가 답을 하기가 무척 어렵네요.

우선 "설계"를 어떻게 정의하느냐에 따라 논의가 많이 달라지지 싶습니다. (하지만 어떻든 답이 "이것은 절대 아니고 오로지 저것이다"라고 명백하게 나오지는 않을 것 같습니다)

그리고, 링크 건 글에서...

스펙이 이러한 내용들이 누락이 되어 있으면 설계가 어떻게 될지 상상해보라.

• 지금은 고객이 10개 회사인데 5년 안에 1,000개의 고객사를 확보할 것이다.
• 지금은 국내 판매를 대상으로 하는데 1년 후 부터는 세계 200개 회사를 대상으로 마케팅을 할 것이다.
• 현재의 시스템은 내년에 회사의 다른 시스템들과 통합하는 작업이 진행 될 것이다.
• 현재는 C/S 구조인데 2년 안에 Web을 지원해야 한다.
• 현재는 Windows만 지원하는데 1년 안에 MacOS, 2년 안에 iPhone과 Android 폰을 지원해야 한다.
• 지금은 모델이 3개지만 내년까지 100개의 모델이 5년 안에 5,000개의 모델이 생산될 것으로 예상된다. (사업이 잘 될 경우)
• 지금은 카메라 모듈을 한 가지만 지원하지만 5년 안에 100개 이상의 카메라 모듈을 지원해야 할 가능성이 80%이다.
• 현재 만든 Framework로 2년 안에 사내의 모든 TV의 Firmware를 교체할 예정이다.

위 예는 실제 현장에서 발생할 수 있는 수백만개 경우 중 몇 개일 뿐이다.

이러한 내용들이 설계에 적절히 고려되지 않는다면 미래에 큰 댓가를 치루게 된다. 이러한 것을 설게에 잘 반영하도록 설계를 하는 사람들을 Architect라고 부른다.

라는 부분이 있는데...

"지금은 고객이 10개 회사인데 5년 안에 1,000개의 고객사를 확보할 것이다."

에서 "5년 안에 1000개의 고객사를 확보할 것이다"는 말 그대로, we don't know입니다. 얼마나 확실하냐는 문제가 있습니다. 기업들이 하는 이런 예측들 중에 정말 몇 퍼센트가 맞아 들어갈까요.

"현재는 Windows만 지원하는데 1년 안에 MacOS, 2년 안에 iPhone과 Android 폰을 지원해야 한다."

고 하는데, 1년도 안되어서 회사가 망할 수도 있습니다.

이런 부분까지 고려해서 설계를 하는 것은 비용효과적이지 못하다고 봅니다.

우리는 성공적인 시스템이 있으면 "설계를 잘해서일거야, 그런 저런 요소들을 미리 다 고려했겠지"하고 생각하는 경향이 있습니다. 그래야 내 머리가 편하거든요. 이걸 심리학자 키스 소여(Keith Sawyer)는 대본사고(script-thinking)라고 부릅니다[1].

흔히 알려진 예로 혼다의 미국 진출 사례가 있습니다. 슈퍼컵이라는 소형 오토바이를 미국에 소개해서 대 성공을 했죠. 보스턴 컨설팅 그룹에서 분석하기로 진입 전부터 매우 성공적인 전략과 계획을 세운 훌륭한 사례라고 보았습니다. 하지만 실제 혼다의 해당 프로젝트에 참가했던 사람을 인터뷰 했던 사례연구에서는 정반대로 나왔습니다. 사실 우리 전략은 정반대였다(대형 오토바이 시장에 진출). 우연과 점진적 학습에 의해 그런 결과가 나오게 되었다.

경영학자 민츠버그는 이렇게 말합니다[2].

Brilliant as its strategy may have looked after the fact, Honda's managers made almost every conceivable mistake until the market finally hit them over the head with the right formula. The Honda managers on site in America, driving their products themselves (and thus inadvertently picking up market reaction), did only on thing right: they learned, firsthand.

경영전략(일종의 밑그림이자 설계)에 대한 경영자들의 관점과, 소프트웨어 설계에 대한 소프트웨어 제작자(프로그래머, 아키텍트 기타 등등)들의 관점을 병치해서 비교해 볼 필요가 있다고 봅니다. (교각이나 거대건물과의 비교는 이제 좀 줄이거나, 아님 차라리 실제 건설 전문가의 의견을 듣거나 하는 쪽으로 바꾸고)


[1] 그룹 지니어스 http://www.yes24.com/24/goods/2803467
[2] Mintzberg, Henry (1987) Crafting Strategy, Harvard Business Review July-August, p. 70. http://hbr.org/product/crafting-strategy/an/87407-PDF-ENG

2011/12/23 이춘식 <choo...@gmail.com>

[이춘식]

질문이 추상적인 것 같습니다. 제가 질문을 올린 이유는 아래와 같습니다.

제가 다니는 회사에서 S/W 를 잘 해보겠다고 노력 중입니다.

많은 사람들이 (개발을 담당하던, 개발 주변에 있던) 문제가 지적하는 내용이 설계입니다.

"설계 없는 개발 활동을 하니깐 우리가 못하는 거야!"

"설계를 잘할 수 있는 아키텍트를 키워!"

"코딩으로 바로 들어가는 것이 문제야!"

"개발 역량, 설계 역량이 너무 부족해!"

그래서 팀을 만들었습니다. S/W를 잘 해보기 위해서 말이죠.

그래서 해야할 많은 일들 중에, 설계를 잘 할 수 있는 방법이 뭘까 고민하면서,

설계 템플릿을 만들어 가이드하고, 이를 작성하도록 돕는 일부터 시작하게 됩니다.

여기서, 강한 거부감을 만납니다.

"설계서 만들라고? 문서 문서 문서!!"

"우리 같은 회사 (저희는 휴대폰 제조사입니다.)는 설계가 필요없어!"

"다 가져다 쓰는 소스를 포팅하고 안정화 하는 일이 전부인데 무슨 설계!"

"설계할 시간이 어딧어!"

"설계하면 뭐가 좋아지는데? 설명을 해줘봐!"

그래서 많은 얘기들도 해보고 고민도 합니다.

정말 "설계 혹은 설계서가 필요한 것일까?" "설계하면 뭐가 좋아질까?" 하는

촌스럽고 근본적인 질문을 해봤던 것입니다.

그래서 선배 아키텍트, 컨설팅 하시는 분들께 조심스럽게 메일을 보내봤고,

적혀진 2번째 링크는 블로그를 통해 받은 답변 글입니다.

여기에 올린 이유는, 애자일이라는 큰 흐름을 이끄시는 분들은 어떻게 생각하시는지,

너무나  궁금했습니다.

[이광운]

안녕하세요. 

"설계서"란 단어가 주는 무게가 사고를 어렵게 만드는 것 같습니다.

프로젝트가 처한 경우의 수가 많고 다양해서 "설계서(?)"가 '꼭 필요하다' ,'아니다' 섣불리 확정하기도 어렵네요.

그렇지만 그래도 답변한다면  

"세월(시간)"을 견디게 하려면 "업데이트되는 최소한의 설계서(?)"라도 남겨야 한다고 봅니다.

그렇지 않으면 이 업계의 최종병기 "차세대"를 하고 계실 수 있습니다.

2011년 12월 23일 오후 4:32, June Kim (김창준) <june...@gmail.com>님의 말:

[Sangcheol Hwang]

설계에 대한 좋은 글 하나 추천합니다.

Martin Fowler의 Is Design Dead? 입니다.

http://blog.naver.com/j6040148/120015111138

2011/12/23 이광운 <ultr...@gmail.com>

[Hubert Shin]

Jake Kim 님의 설계에 관한 의견은 저도 매우 동의하고 있습니다만.. 

하지만" 설계가 필요할까?" 라는 글의 실제 내용은

"설계가 필요할까?" 라기 보다는 "설계를 어떻게 해야 하는가?" 라는 질문에 대해 

개인의 의견을 말하는 내용인 것인 것 같습니다.

그러니까..  질문과 하는 내용을 보면, 

• SW 개발에 설계가 과연 필요한가?  --> 설계는 반드시 해야 한다
• 설계서를 작성할 필요가 있을까? --> 설계는 필요한 만큼 하는 것이다. 
• 설계는 어떤 기법을 사용해야 하나? --> 설계에 반영해야 할 내용에는 이런 것들이 있다.
• 설계툴은 UML을 꼭 사용해야 하나? --> 툴은 효율적으로 사용해야 한다. 

뭐 이런 내용인 것 같습니다만..  결국 일반적인 내용이라 생각됩니다 ^^:

제 개인적인 생각으로는,

실제 프로젝트 일원이 궁금해하는 내용은

설계 그 자체를 수행하고 아닌가의 문제가 아니라.. 

"그런 복잡한 문서를 꼭 써야돼?" 가 아닐까요? 

^^;

2011/12/23 이광운 <ultr...@gmail.com>

--

[배정일]

재밌네요 ^^
상황 context에 따라 다르다고 생각합니다 개집 정도면 바로 개발하면 되고 복잡도가 증가되면 각각의 도메인별로 설계가 필요합니다 paper이라도 ^^

[이광운]

올려주신 내용에 같이 실무하는 입장으로 설계(?)의 변을 달아봅니다.

"설계서 만들라고? 문서 문서 문서!!"

=> "코드 작성 전에 특정한 양식에 완벽한 설계서(문서)를 만들어야 설계다" 라는 선입견이 있을 수 있다.

=> 세월은 모든 것을 변하게 만든다. "처음부터 완벽한 양식의 설계(문서)는 없다."라는 점을 받아들이는 마음 가짐이 필요

=> 세월이 흐르면서 코드랑 완전히 일치하는 설계서(문서)를 만드는 것은 경험상 불가능하다.

=> 문서는 최소한으로 정보를 파악하는데 필요한 만큼(?) 유지한다.

=> 우리가 보게 되는 최신 문서는 바로 소스 코드

=> 소스코드를 잘 작성하고 테스트하는 방법부터 바로 좋은 설계의 실천(네이밍, 테스트, 버전관리…기타 등등)

(설계 도구는 따로 없다.…구글 닥스나 이슈트래커로 서로 정보를 공유하는 차원부터가 시작이라고 생각합니다.)

"우리 같은 회사 (저희는 휴대폰 제조사입니다.)는 설계가 필요없어!"

"다 가져다 쓰는 소스를 포팅하고 안정화 하는 일이 전부인데 무슨 설계!"

=> "새로 만드는 것에만 설계가 필요하다."라는 선입견이 있을 수 있다.

=> 유지보수, 포팅을 잘하기 위한 것도 설계(전략/방법)다.

=> 안드로이드 포팅/안정화로 보자면 각자 개발자가 맡은 기능(내부 앱)들을 

주어진 기간 내에 포팅/테스트/디버깅을 잘 해결하기 위해서 세우는 계획/방법/전략도 설계의 일부분이다.

(TDD, Android TDD, Android Monkey…등등 코드에 관한 테스트/디버깅 설계)

"설계할 시간이 어딧어!"

=> 설계는 따로 특별한 설계 일정(?)을 잡고 해야한다는 선입견이 있을 수 있다.

=> 프로젝트 초반에 도메인 지식은 정확도가 떨어진다. 오히려 프로젝트 마지막이 설계에 관련된 도메인 지식이 많다. 

=> 그러니 따로 설계는 근사하게(?) 일정을 잡고 해야한다는 선입견을 버리자.

=> 고객(제조사)의 요구사항/할 일을 파악하고 일정을 예상하는 것이 바로 설계의 한 영역 이다.

(참고, 애자일의 유저 스토리)

"설계하면 뭐가 좋아지는데? 설명을 해줘봐!"

=> 설계(?)를 통해 프로젝트의 이슈(TODO)에 좀 더 가까이 접근할 수 있다.

이슈를 멀리서 그냥 대충 보다 코드를 작성하는 것보다

가까이 가서 직접 최대한 상세히 보는 것이 정확성을 높일 수 있다.

퇴근 전에 급히 쓰다보니 여기 저기서 본 내용을 짜집기 한 것 같네요.;;;;

2011년 12월 23일 오후 5:15, 배정일 <har...@gmail.com>님의 말:

[Minjae Kim]

안녕하세요, 김민재라고 합니다.

1. 설계는 필요하다고 봅니다.
2. 그렇지만 설계를 문서로 꼭 하실 필요는 없습니다. 문서로 할 때의 효용성은 있습니다만 효용성이 떨어진다고 판단되면 안해도 무방하리라 봅니다. 만약 코드가 잘 쓰인 문서처럼 가독성이 뛰어나다면 코드 자체가 설계 문서일 수 있다고 보구요.

부연 설명 드립니다,

1. 설계 필요함
• 사실 저는 도메인주도설계 사상을 좋아하는 사람 중 한명이라 모델 주도 설계가 꼭 필요하다고 봅니다. 공통의 언어로 기준에 대한 의사소통 없이 개발할 수는 있지만, 이는 adhoc 방식이고 성숙도가 떨어지며 기능은 빠르게 구현할 수 있으나 중복코드가 늘어나고 유지보수 비용이 많이 들어서 롱 텀으로는 비효율적이라고 생각합니다.
2. 설계서는 구지 없어도 됨
• DDD(Domain-Driven Design, 도메인 주도 설계)에서는 단일 모델이어야 한다고 주장합니다. 분석 모델, 설계 모델을 이원화하면 안된다고 얘기하죠. 컨셉과 매커니즘 구현이 서로 다른 모델에서 각각 진행이 되면 의사소통에 방해가 된다는 입장입니다.
• 결국 단일 모델에 분석 및 설계의 결과를 계속적으로 녹여 넣자는 것이구요. 그것으로 공통의 언어를 만들어 이해관계자 간에 의사소통을 하자는 얘기입니다. 의사소통은 언어로 하죠. 그래서 그 언어의 형태가 문서로 국한될 필요는 없다고 봅니다. 특히 코드와 싱크가 안 맞는 문서는 없는게 낫죠. 실행가능한 문서가 곧 코드니 실행가능하지 않은 doc 형태가 괜히 있어서 코드와 맞지도 않고, 의사소통에 방해만 된다면 그런 설계서는 존재 가치가 없다고 봅니다.
• 대신 구두로 회의를 진행한다거나, 그림을 그린다거나 효과적인 문서 작업을 해서 도메인의 여러 특징을 모델에 녹여 내는 지속적인 모델링 작업을 브레인스토밍 하듯이 계속적인 실험을 통해 해 보는 것이 핵심입니다.

제 소견을 적어 보았습니다.

2011년 12월 23일 오후 5:59, 이광운 <ultr...@gmail.com>님의 말:

--

========================================================

Deep & Supple

김민재 부장

Mobile : 010-7138-5108

E-Mail : con...@gmail.com

Facebook: http://www.facebook.com/profile.php?id=100000118624897

========================================================

[YoungSu Son]

설계는 필요하다고 봅니다. 

중요한건 설계가 아키텍트만의 전유물이 되어서는 안됩니다. 개발자, 테스트 모두 이해를 해야 되는 산물입니다.

물론 개집을 만드는데는 그럴 필요가 없겠죠.  

설계 철학이 모든 사람들에게 공유되어야만 아키텍쳐가 무너지지 않고, 튼튼한 시스템을 만들수 있다고 전 생각합니다 .:) 

2011/12/24 Minjae Kim <con...@gmail.com>

--
손영수

http://www.arload.net
아키텍트로 가기 위해 내가 넘어야 하는 것들..  (Load to Architect)

[Minjae Kim]

간단한 코멘트를 덧 붙이면,
설계는 매우 중요하고 꼭 있어야 합니다.

설계가 없다면, why와 what, how가 없이 dododo만 하는 꼴인 셈이죠.
단일 설계 모델에 why, what, how를 잘 의사소통이 되게 만드는 작업이 아키텍팅, 분석/설계, 즉 구조설계, 상세설계 영역이라고 생각합니다.

기준 없이 dododo만 하면 액티비티 트랩이란 것에 빠지고, 결국 burnout 되죠.

2011년 12월 24일 오전 2:01, YoungSu Son <indig...@gmail.com>님의 말:

[June Kim (김창준)]

우리가 생각해봐야 할 부분은 과연 무엇이 설계(design)인가 하는 것인데...

우선 내가 생각하는 "설계가 전혀 없는 프로그램", "설계를 최대로 한 프로그램", "설계를 한 건지 안 한건지 애매한 프로그램"의 예를 각기 하나씩이라도 생각해 보시면 내가 주로 생각하는 설계의 정의에 대한 몇 가지 힌트를 얻으실 수 있을 것 같습니다(참고로 사람에 따라 위 세가지 범주에 대한 답 하나 이상이 공집합일 수 있습니다).

여기에 추가적으로 생각해볼 질문 몇가지입니다:

0) 설계는 활동(activity)일까요, 결과물(artifact)일까요 아니면 양자 모두일까요? 각각의 범주는 어디까지일까요? 나는 주로 어떻게 "설계"라는 단어를 쓰나요? (이하 질문에서 나오는 "설계"라는 단어는 행동 혹은 결과물 혹은 양쪽으로 모두 해석가능합니다)
1) 특정 형태의 설계문서가 있으면 "설계가 있는 것"이고, 그 형태의 설계문서가 없으면 "설계가 없는 것"이라고 할 수 있을까요?
2) 소스코드(및 주석) 외에 별도의 종이문서, 전자문서가 없는 시스템이 있을 경우 "설계가 없다"라고 할 수 있을까요?
3) 만약 어떤 프로그래머가 한참을 골똘히 생각하더니 프로그램을 작성해서 완료했습니다. 이 프로그램은 설계 없는 프로그램인가요, 아니면 설계 있는 프로그램인가요?
4) 어떤 프로그래머가 별 생각 없이 프로그램을 시작하면서 하는 도중 간간이 골똘히 생각을 하면서 프로그래밍했습니다. 이 프로그램은 설계 있는 프로그램일까요 아닐까요?

2011/12/24 Minjae Kim <con...@gmail.com>

[Park albert 규진]

모두들, 메리 크리스마스!
크리스마스 이브에 이렇게 화기애애한 분위기로 토론을 하며 함께하는 엑스퍼를 보니 만감이 교차하네요. ...

사실 우리가 만드는 결과물은 소스코드가 아니라 동작하는 소프트웨어죠. 소스 코드를 동작하는 소프트웨어로 만들어주는 과정은 거의 모든 것이 자동화되어 컴퓨터가 대신합니다. 그리하여 우리는 그 과정이 있다는 사실 조차 쉽게 인지하지 못하고 있는 것 같습니다. 

다시말해 다른 공업 프로세스에 비유하자면 소스코드를 만드는 우리의 일은 사실 처음부터 끝까지 '설계'일 뿐입니다. 

큰 그림을 뎃생을 하다보면 분명 최대한 비슷하게 그리고 있음에도 어느순간 기괴한 괴물이 되어있습니다. 대부분 각 부분들의 균형이 무너져서 머리는 크고 팔은 작고, 또 그런 부분들을 억지로 이어붙이다보면 더더욱 기괴해져 가는데 그게 마치 소프트웨어의 설계 문제와 닮아있는 것 같다는 생각으 합니다.

 잘 그리는 사람들을 보면 부분에 집중하더라도 절대로 전체적인 균형감각을 놓치지 않고 그려냅니다. 균형이 무너질 것 같다 싶으면 한숨 돌리면서 다시한번 생각한 이미지 뿐만 아니라 현제 그려진 부분들을 다시 확인하며 맞춰가죠.

아마도 그런 전체적인 시야를 보여주고 개발중 그 균형을 맞추어 가길 바라며 만드는 것이 개발 설계서일 텐데 사실 어느정도나 그 효과를 볼 수 있을진 모르겠습니다. 차라리 전체를 바라보려 노력을 했다는 것을 증명하기 위한 문서가 된다면, 정규화된 문서가 아닌 전체적인 밑그림을 바라보며 하는 간단한 메모로 (윗선에서) 받아들일 수 있다면 좋을 것 같습니다. 

감사합니다. 

Albert 규진 Park

[CharSyam]

김창준님 말씀대로 "설계" 란 무엇인가 부터 고민을 해야할 것 같습니다.

그리고 최초에 이춘식님이 말씀하신게, 단순한 기술인지, 아니면 문화인지에 대한 고민이 필요할 것 같습니다.

단순히 설계가 필요한가라고 말하면, 기술적인 부분에만 생각이 모이는데,

이춘식님의 질문은 그것보다는 "문화"에 대해서 고민을 해야만 답이 나오지 않을까 하는 추상적인 생각이 드네요 ^^

On Dec 24, 9:38 pm, June Kim (김창준) <junea...@gmail.com> wrote:
> 우리가 생각해봐야 할 부분은 과연 무엇이 설계(design)인가 하는 것인데...
>
> 우선 내가 생각하는 "설계가 전혀 없는 프로그램", "설계를 최대로 한 프로그램", "설계를 한 건지 안 한건지 애매한 프로그램"의
> 예를 각기 하나씩이라도 생각해 보시면 내가 주로 생각하는 설계의 정의에 대한 몇 가지 힌트를 얻으실 수 있을 것 같습니다(참고로 사람에
> 따라 위 세가지 범주에 대한 답 하나 이상이 공집합일 수 있습니다).
>
> 여기에 추가적으로 생각해볼 질문 몇가지입니다:
>
> 0) 설계는 활동(activity)일까요, 결과물(artifact)일까요 아니면 양자 모두일까요? 각각의 범주는 어디까지일까요? 나는
> 주로 어떻게 "설계"라는 단어를 쓰나요? (이하 질문에서 나오는 "설계"라는 단어는 행동 혹은 결과물 혹은 양쪽으로 모두 해석가능합니다)
> 1) 특정 형태의 설계문서가 있으면 "설계가 있는 것"이고, 그 형태의 설계문서가 없으면 "설계가 없는 것"이라고 할 수 있을까요?
> 2) 소스코드(및 주석) 외에 별도의 종이문서, 전자문서가 없는 시스템이 있을 경우 "설계가 없다"라고 할 수 있을까요?
> 3) 만약 어떤 프로그래머가 한참을 골똘히 생각하더니 프로그램을 작성해서 완료했습니다. 이 프로그램은 설계 없는 프로그램인가요, 아니면
> 설계 있는 프로그램인가요?
> 4) 어떤 프로그래머가 별 생각 없이 프로그램을 시작하면서 하는 도중 간간이 골똘히 생각을 하면서 프로그래밍했습니다. 이 프로그램은
> 설계 있는 프로그램일까요 아닐까요?
>
> 2011/12/24 Minjae Kim <con...@gmail.com>
>
>
>
>
>
>
>
> > 간단한 코멘트를 덧 붙이면,
> > 설계는 매우 중요하고 꼭 있어야 합니다.
>
> > 설계가 없다면, why와 what, how가 없이 dododo만 하는 꼴인 셈이죠.
> > 단일 설계 모델에 why, what, how를 잘 의사소통이 되게 만드는 작업이 아키텍팅, 분석/설계, 즉 구조설계, 상세설계
> > 영역이라고 생각합니다.
>
> > 기준 없이 dododo만 하면 액티비티 트랩이란 것에 빠지고, 결국 burnout 되죠.
>

> > 2011년 12월 24일 오전 2:01, YoungSu Son <indigog...@gmail.com>님의 말:

>
> > 설계는 필요하다고 봅니다.
> >> 중요한건 설계가 아키텍트만의 전유물이 되어서는 안됩니다. 개발자, 테스트 모두 이해를 해야 되는 산물입니다.
>
> >> 물론 개집을 만드는데는 그럴 필요가 없겠죠.
> >> 설계 철학이 모든 사람들에게 공유되어야만 아키텍쳐가 무너지지 않고, 튼튼한 시스템을 만들수 있다고 전 생각합니다 .:)
>
> >> 2011/12/24 Minjae Kim <con...@gmail.com>
>
> >>> 안녕하세요, 김민재라고 합니다.
>
> >>> 1. 설계는 필요하다고 봅니다.
> >>> 2. 그렇지만 설계를 문서로 꼭 하실 필요는 없습니다. 문서로 할 때의 효용성은 있습니다만 효용성이 떨어진다고 판단되면 안해도
> >>> 무방하리라 봅니다. 만약 코드가 잘 쓰인 문서처럼 가독성이 뛰어나다면 코드 자체가 설계 문서일 수 있다고 보구요.
>
> >>> 부연 설명 드립니다,
>

> >>> 1. 설계 필요함
> >>> - 사실 저는 도메인주도설계 사상을 좋아하는 사람 중 한명이라 모델 주도 설계가 꼭 필요하다고 봅니다. 공통의 언어로

> >>> 기준에 대한 의사소통 없이 개발할 수는 있지만, 이는 adhoc 방식이고 성숙도가 떨어지며 기능은 빠르게 구현할 수 있으나 중복코드가
> >>> 늘어나고 유지보수 비용이 많이 들어서 롱 텀으로는 비효율적이라고 생각합니다.

> >>> 2. 설계서는 구지 없어도 됨
> >>> - DDD(Domain-Driven Design, 도메인 주도 설계)에서는 단일 모델이어야 한다고 주장합니다. 분석

> >>> 모델, 설계 모델을 이원화하면 안된다고 얘기하죠. 컨셉과 매커니즘 구현이 서로 다른 모델에서 각각 진행이 되면 의사소통에 방해가 된다는
> >>> 입장입니다.

> >>> - 결국 단일 모델에 분석 및 설계의 결과를 계속적으로 녹여 넣자는 것이구요. 그것으로 공통의 언어를 만들어

> >>> 이해관계자 간에 의사소통을 하자는 얘기입니다. 의사소통은 언어로 하죠. 그래서 그 언어의 형태가 문서로 국한될 필요는 없다고 봅니다.
> >>> 특히 코드와 싱크가 안 맞는 문서는 없는게 낫죠. 실행가능한 문서가 곧 코드니 실행가능하지 않은 doc 형태가 괜히 있어서 코드와
> >>> 맞지도 않고, 의사소통에 방해만 된다면 그런 설계서는 존재 가치가 없다고 봅니다.

> >>> - 대신 구두로 회의를 진행한다거나, 그림을 그린다거나 효과적인 문서 작업을 해서 도메인의 여러 특징을 모델에 녹여

> >>> 내는 지속적인 모델링 작업을 브레인스토밍 하듯이 계속적인 실험을 통해 해 보는 것이 핵심입니다.
>
> >>> 제 소견을 적어 보았습니다.
>

> >>> 2011년 12월 23일 오후 5:59, 이광운 <ultrak...@gmail.com>님의 말:

>
> >>> 올려주신 내용에 같이 실무하는 입장으로 설계(?)의 변을 달아봅니다.
>

> >>>> *"설계서 만들라고? 문서 문서 문서!!"*

>
> >>>> => "코드 작성 전에 특정한 양식에 완벽한 설계서(문서)를 만들어야 설계다" 라는 선입견이 있을 수 있다.
>
> >>>> => 세월은 모든 것을 변하게 만든다. "처음부터 완벽한 양식의 설계(문서)는 없다."라는 점을 받아들이는 마음 가짐이 필요
>
> >>>> => 세월이 흐르면서 코드랑 완전히 일치하는 설계서(문서)를 만드는 것은 경험상 불가능하다.
>
> >>>> => 문서는 최소한으로 정보를 파악하는데 필요한 만큼(?) 유지한다.
>
> >>>> => 우리가 보게 되는 최신 문서는 바로 소스 코드
>

> >>>> => 소스코드를 잘 작성하고 테스트하는 방법부터 바로 좋은 설계의 실천(네이밍, 테스트, 버전관리...기타 등등)
>
> >>>> (설계 도구는 따로 없다....구글 닥스나 이슈트래커로 서로 정보를 공유하는 차원부터가 시작이라고 생각합니다.)
>
> >>>> *"우리 같은 회사 (저희는 휴대폰 제조사입니다.)는 설계가 필요없어!"*
>
> >>>> *"다 가져다 쓰는 소스를 포팅하고 안정화 하는 일이 전부인데 무슨 설계!"*

>
> >>>> => "새로 만드는 것에만 설계가 필요하다."라는 선입견이 있을 수 있다.
>
> >>>> => 유지보수, 포팅을 잘하기 위한 것도 설계(전략/방법)다.
>
> >>>> => 안드로이드 포팅/안정화로 보자면 각자 개발자가 맡은 기능(내부 앱)들을
>
> >>>> 주어진 기간 내에 포팅/테스트/디버깅을 잘 해결하기 위해서 세우는 계획/방법/전략도 설계의 일부분이다.
>

> >>>> (TDD, Android TDD, Android Monkey...등등 코드에 관한 테스트/디버깅 설계)
>
> >>>> *"설계할 시간이 어딧어!"*

>
> >>>> => 설계는 따로 특별한 설계 일정(?)을 잡고 해야한다는 선입견이 있을 수 있다.
>
> >>>> => 프로젝트 초반에 도메인 지식은 정확도가 떨어진다. 오히려 프로젝트 마지막이 설계에 관련된 도메인 지식이 많다.
>
> >>>> => 그러니 따로 설계는 근사하게(?) 일정을 잡고 해야한다는 선입견을 버리자.
>
> >>>> => 고객(제조사)의 요구사항/할 일을 파악하고 일정을 예상하는 것이 바로 설계의 한 영역 이다.
>
> >>>> (참고, 애자일의 유저 스토리)
>

> >>>> *"설계하면 뭐가 좋아지는데? 설명을 해줘봐!"*

>
> >>>> => 설계(?)를 통해 프로젝트의 이슈(TODO)에 좀 더 가까이 접근할 수 있다.
>
> >>>> 이슈를 멀리서 그냥 대충 보다 코드를 작성하는 것보다
>
> >>>> 가까이 가서 직접 최대한 상세히 보는 것이 정확성을 높일 수 있다.
>
> >>>> 퇴근 전에 급히 쓰다보니 여기 저기서 본 내용을 짜집기 한 것 같네요.;;;;
>

> >>>> 2011년 12월 23일 오후 5:15, 배정일 <haru...@gmail.com>님의 말:

>
> >>>> 재밌네요 ^^
> >>>>> 상황 context에 따라 다르다고 생각합니다 개집 정도면 바로 개발하면 되고 복잡도가 증가되면 각각의 도메인별로 설계가
> >>>>> 필요합니다 paper이라도 ^^

> >>>>> On Dec 23, 2011 5:08 PM, "이광운" <ultrak...@gmail.com> wrote:
>
> >>>>>> 안녕하세요.
>
> >>>>>> "설계서"란 단어가 주는 무게가 사고를 어렵게 만드는 것 같습니다.
> >>>>>> 프로젝트가 처한 경우의 수가 많고 다양해서 "설계서(?)"가 '꼭 필요하다' ,'아니다' 섣불리 확정하기도 어렵네요.
>
> >>>>>> 그렇지만 그래도 답변한다면

> >>>>>> *"세월(시간)"을 견디게 하려면 "업데이트되는 최소한의 설계서(?)"라도 남겨야 한다*고 봅니다.
>
> >>>>>> 그렇지 않으면 이 업계의 최종병기 *"차세대"*를 하고 계실 수 있습니다.
>
> >>>>>> 2011년 12월 23일 오후 4:32, June Kim (김창준) <junea...@gmail.com>님의 말:

>
> >>>>>>> 질문이 너무 추상적이고 광범위해서 제가 답을 하기가 무척 어렵네요.
>
> >>>>>>> 우선 "설계"를 어떻게 정의하느냐에 따라 논의가 많이 달라지지 싶습니다. (하지만 어떻든 답이 "이것은 절대 아니고 오로지
> >>>>>>> 저것이다"라고 명백하게 나오지는 않을 것 같습니다)
>
> >>>>>>> 그리고, 링크 건 글에서...
>
> >>>>>>> 스펙이 이러한 내용들이 누락이 되어 있으면 설계가 어떻게 될지 상상해보라.
>

> >>>>>>>> - 지금은 고객이 10개 회사인데 5년
>
> ...
>
> read more >>

[글뻥]

안녕하세요?
설계지상주의자(?)인 민신현입니다.
먼저 질문의 내용이 매우 추상적이라 유감스럽습니다.

제가 해석한 의미는 다음과 같습니다.
1. 설계서가 필요한것 같은데, 이상한 분들이 딴지를 거니 지원사격해달라.
2. 설계서가 필요없다는 분들이 계신데 설득해달라.

이렇게 해석해놓고 보니 1, 2의 본질적인 질문은 그리 다르지 않다고 생각됩니다.
이 질문은 마치 "작전계획서가 필요한가? 불필요한가?"라는 질문과 같습니다.

고대 이례로 수 많은 직업군인들이 지적했다시피...
"작전계획은 전투개시 1분을 못틴다"고들 합니다.
그럼에도 21세기 전장터는 아직도 수많은 작전계획과 계획서를 산출물로 만들어 냅니다.

공사 현장에서도 수많은 설계서를 만들어냅니다. 설계과정에서 수많은 계산을 수행하고 원가와 공기를 산출해 냅니다.
제조업에서도 설계과정이 있고 설계서가 있으며 이를 토대로 제품을 만들어 냅니다.
그런데 무형의 S/W는 설계보다는 결과물에 집중합니다. (물론 우리의 현실입니다. 일본, 미국과 일해 본 경험에 의하면 코딩보
다 더 많은 시간을 설계에 투자하지요.)

그렇다면, 왜 우리는 S/W의 설계/설계서의 무용론을 주장할까요?
이 시점에서 제럴드 와인버그의 고견을 인용하는 편이 좋을 듯 합니다.
"설계과정후에 나온 설계서를 나중에 본다는 것은 극히 어렵다."

아마도, 이게 핵심이 아닐까 싶습니다.
왜 안보게 될까요?
왜 설계서에 우리는 큰 가치를 부여하지 않을까요?

결론은 "볼 일이 없다"는 겁니다.

그 이유는 다음과 같습니다.
1. 고객은 자신의 욕구인 요구사항을 제대로 이해하고 있지 않으며 개발팀도 요구사항의 정체인 욕구를 이해하고 있지 못해 요구사
항 자체가 엉터리로 나옵니다.
2. 요구사항을 테스트하지 않습니다. 그래서 요구사항이 엉터리인지 모릅니다. (그게 규모가 큰지 작은지 알수가 없지요.)
3. 작동하는 S/W에 집중하다보니 설계시간과 테스트 시간이 매우 작게 산정됩니다. (한마디로 엉터리 요구사항으로 만들어진 엉터
리 일정표를 가지고 있습니다.)
4. 결정적으로 업무 비전문가가 프로젝트에 참여하고 있고, 개발전문가들은 업무 전문가의 이야기를 한귀로 듣고 한귀로 흘립니다.
(게임산업에 와보니 이 쪽도 똑같더군요. 예를 들어, 골프게임을 만드는데 골프전문가가 참여하지 않거나, 당구게임을 만드는데 당
구 전문가가 참여하고 있지 않으며, FPS를 만드는데 군 전문가가 참여하고 있지 않더군요.)
5. 더 큰 문제는 설계전문가가 프로젝트에 참여하고 있지 않습니다.
6. 또 하나의 문제는 설계서를 최대한 빨리 구현할 목업 또는 프로토타이핑을 개발계획에 넣고 있지 않습니다. (설계를 테스트할
방법이 없습니다.)

요약하자면, 비전문가가 요구사항을 내고, 비전문가가 일정을 잡으며, 비전문가가 개발일정에 따라 개발하고, 비전문가가 개발이 완료
된 후에 제출 목적으로 설계를 만드는 현실을 보면, 설계 및 설계서는 반드시 해야하는 높은 가치의 일이 아니라, 높은 Risk
를 가진 낮은 Value의 업무입니다.
(가치-비용 모델에 따르면, 높은 가치,높은 비용의 일부터 하라고 되어 있지만 반대로, 낮은 가치, 높은 비용의 일은 버리라고
하지요. 이게 그대로 적용됩니다. 단지 좋은 도구를 사용하면 Risk/Cost를 낮출수 있기 때문에 ER-WIN이나
Powerpoint, UML Tool을 사용해서 가치-비용 모델에서 이야기하는 맨 마지막 작업으로 설계를 한다는 현실이 상기한다
면 그대로 맞아 떨어지죠)

산출물 자체로 보면 설계/설계서는 한국 개발풍토에서 적대적으로 가치없는 일이면서도 Risk(Cost)는 매우 큰 일임에 분명합니
다.

하지만, 과정에 더 많은 가치를 부여하면 이야기는 달라진다고 생각합니다.
1. 중복작업을 없앨 수 있습니다.
2. 수 많은 토론과 시뮬레이션을 통해 개발팀원 모두가 그 내용을 공유할 수 있습니다.
3. 요구사항을 테스트할 수 있으며, 설계자체도 테스트 할 수 있습니다.
4. 개발진척도를 설계대비 몇 %로 가시화할 수 있습니다. (Method의 수나 Function Point활용)
5. 어떤 개발자가 어떤 일을 하고 있고 생산성이 어떻게 되는지 명확하게 측정가능합니다. 등등등

이렇게 설계서가 아닌 설계 자체에 Focus한다면 설계는 High-Value, High-Risk(Cost)가 되어 가장 먼저해야
할 작업으로 인식되게 됩니다.

단지 설계서는 그 과정에서 나오는 산출물일 뿐이라는 이야기입니다. (개발중에 도출되는 설계의 문제는 설계를 고치면 될 일이니,
설계서에 목숨 걸지 말자라는 이야기와 동일합니다.)

On 12월22일, 오후9시49분, 이춘식 <choon...@gmail.com> wrote:
> 안녕하세요? 다소 촌스러운 질문일까요?
>
> 여기에 계신 훌륭한 분들의 의견을 듣고 싶습니다.
>

> 여기서 찾은 인상 깊은 글은 여기에 있고,https://groups.google.com/d/msg/xper/9Ae5MvPDfmY/UnuVij4bTbgJ
>
> 제가 드린 질문에 이렇게 좋은 답변도 해주셨습니다.http://allofsoftware.net/entry/IsDesignNeeded

[Jaepyoung Kim]

메리크리스마스.. 

김창준님 말씀 대로 설계와 설계서는 구분해야 할거 같습니다. 용어정리가 항상 중요한거 같습니다. 

설계는 말씀 하신 대로 개발하기 위한 지적인 노력을 설계로 봐야하고, 설계서는 그러한 지적인 노력을 커뮤니케이션을 위한 산출물이라고 생각을 합니다. 

개집을 만들기 위해서도 어떻게 만들어야지 하는 생각이 있기 때문에 항상 설계라는 행동은 하지만 설계서를 만드느냐는 개집을 만드는 사람에 달리거 같습니다.

설계는 개발자 자신이 하는 행동이지만, 설계서는 개발자와 다른 협업하는 사람을 위한 산출물이라고 생각을 합니다. 

두사람이 개발하는 프로젝트에서는 설계서라는 산출물이 별로 필요하지 않은거 같습니다. 

하지만, 100명이 개발하는 프로젝트는 그냥 냅프킨에그린 설계서로는 커뮤니케이션이 어렵기 때문에 더 정형화된 설계서가 필요한거 같구요. 

결군 설계라는 행동은 개발에서 빠질 수 없는 활동이고, 설계서를 제작할 것인가 아닌가는 팀의 상황에 따라서 결정해야 될 문제라고 생각을 합니다. 

앞에서 말씀 하셨듯이 설계서 작성시 Redundancy는 최소한으로 해야 하겠지요.. 

2011/12/25 글뻥 <vicvi...@gmail.com>

--
Jaepyoung Kim
(Cellular phone) 1-310-848-7774

[글뻥]

위의 가치-Risk 모델은 다음의 링크에서 찾아 보실 수 있습니다.
http://www.agilebok.org/index.php?title=ROI,_NPV_and_IRR

제목 : Risk vs. Value Matrix
가장 먼저해야 할 일 : 가치높음, 리스크높음
두번째 해야 할 일 : 가치높음, 리스크낮음
세번째 해야 할 일 : 가치낮음, 리스크낮음
피해야 할 일 : 가치 낮음, 리스크높음

> > 많은 의견 부탁드립니다.- 원본 텍스트 숨기기 -
>
> - 원본 텍스트 보기 -

[이춘식]

모두들 크리스마스 잘 보내셨는지요?

크리스마스를 지나고, 이곳에 많은 의견을 주셔서 마음이 따뜻해집니다.

설계와 설계서를 구분해야한다는 말씀에는 공감은 합니다만, 아래와 같은 의문이 듭니다.

설계를 한다면, 설계의 기술된 형태의 산출물, 즉 설계서가 있어야 하지 않을까?

반대로, 설계 문서가 없다면, 설계를 했다고 할 수 있을까요?

설계 문서가 필요없는 이유가 "볼 것이 없다"라면 설계 활동을 잘 못한 것이 될 것 같습니다.

현장에서는 두기지 상반된 목소리를 듣습니다.

"설계 활동을 어떻게 하는지 가이드 해줘봐! 뭐를 어떻게 하란 말이야!"

"이런 템플릿에 맞쳐서 설계하는 건 문서를 위한 문서야!"

사실, 이런 얘기를 드리는 것이 부끄러울 때가 있습니다.

수백명이 붙어서 개발하고 있는 환경에서 말이죠.

여러분의 회사에서는 설계 활동을 어떻게 하고 있나요?

[dong kyu hyun]

안녕하세요. 매일 눈팅만 하다, ;

아래 규진님 댓글에 많은 공감이 가서 .. 평소 생각하던 주제라 감히 끼어들었습니다.^^; 

1. 공감가던 설계의 정의 

어떤 책에도 있던 내용(제목이 가물가물.. 파란 표지의 양장본이었는데..)이었는데, 소스코드가 곧 설계다 라는 문구가 있었습니다.

그책에서 하는 말이..

건축과 소프트웨어가 상당히 많은 부분을 비교하고 있는데,

가장 오해하는 부분이, 건축에서의 인부는 소프트웨어에서 코더라고 비교하고, 

문제를 공학적으로 접근 한다는 부분이었습니다.

하지만 사실 소프트웨어에서 인부 역할(실제 구현)은 컴파일러 라는 것이죠. 

그러면서, 우리는 최고의 인부를 가졌기 때문에, 언제나 설계(소스코드)를 쉽게 변경할 수 있고, 빨리 구현할 수 있다.

이것이 건축과 가장 다른점이다. 라는 결론이었던것 같습니다. (건축은.. 설계(소스코드)가 변경되면, 그 여파가 어마어마 하겠죠..) 

그렇게 소스코드에 집중하게 되면, 자연스레 설계에 집중하게 되는것입니다.

2. 마이크로 설계, 매크로 설계

더 나가서.. 저는 설계에도 세부 단위 구현을 위한 마이크로한 설계, 세부 단위를 조합하는 매크로한 설계가 있다고 보고 있습니다. (두개는 상대적으로 보고 있구요..)

마이크로한 설계는 도메인 문제를 해결하는 방법에 가까운 설계 이겠고, 매크로한 설계는 디자인 패턴과 같은 각 마이크로한 설계의 변화에 대응하는 설계로 보고 있습니다. 

이 두가지도.. 프로젝트 할때마다 접근 방법이 달랐었는데요.

한번도 해보지 않았고, 어떻게 될지 몰랐던 프로젝트에는 마이크로한 설계에서 매크로 설계를 뽑아내고, 다시 마이크로를 고치고.. 이런 바텀업 위주로 진행을 했었고,

그렇지 않고, 하기 전부터 머리에 그려지던(또는, 누군가를 벤치마킹해서 비슷한 것을 만드는;;;;) 프로젝트에서는 매크로에서 마이크로를 만들고, .. 그러다 매크로를 다시 고치는 탑다운 위주로 진행을 했었습니다.

중요한건 어떤 방식이든, 마이크로 설계, 매크로 설계는 계속 변하더군요.

3. 중요지점 테스트 작성

쌩뚱맞게 설계 이야기를 하다가 테스트가 나왔습니다.

다시 건축에 비교하면, 건축에서는 설계 -> 구현 -> 안전검사, 무슨 검사, 어떤 검사 등등등 -> 완성  과 같이 대략 생각합니다.

소프트웨어도 사실 비슷합니다. 설계 -> 구현 -> 테스트 -> 완성 ...

그런데, 엄청 다른건 건축에서는 무슨 검사에서 실패하면, 최악의 경우에는 건물을 다시 헐어 버릴수도 있겠죠.. 설계했던 사람은.. 다 짤리겠고, 몇년의 시간을 버릴수도 있습니다.

소프트웨어는.. 설계(소스코드)를 바꾼다 한들 구현에 몇초 안걸립니다. 건축으로 따지면 매번 허물고 새로 지어버리는 거죠..

그과정에서 중요지점 자동화된 테스트가 있다면, 설계를 바꾸고 완성까지 걸리는 시간은 더 줄어 들겠죠.. 

4. 문서

문서이야기를 하는 이유는, 설계 이야기를 할때.. 문서 이야기가 딸려나왔기 때문일것 같습니다..

제가 생각하는 효율적인 문서는.. 문서를 보는 주체가 누구냐에 따라 달라지는것 같습니다.

정해진 스펙, 정해진 방법에 따라.. 공식처럼 따라다니는 문서가 아닌..

문서를 보는 사람이 비즈니스 담당자에게 설명하기 위한 내부 문서다! 라는 정의가 내려지면, 그에따른 비즈니스 가치 창출에 초점을 맞춘 문서가 만들어 질것이고,

외부 모듈 연결자에게 제공될 문서다! 라는 정의가 내려지면, 모듈을 연동할 수 있는, 인터페이스 문서(API), 튜토리얼, 사용례, 테스트 방법, 내부 로직 간략 흐름도 등등의 문서가 만들어 질것 입니다.

말하고 싶은건, 공식처럼 나온 문서는.. 별로 의미가 없어 보였고, 소스코드가 나오기 전에 문서는 대다수 공식 문서로서의 의미는 없었습니다..

늦은밤 두서 없이 쓴 답변 읽어주셔서 감사합니다.^^;

2011년 12월 25일 오전 3:58, Park albert 규진 <albert...@gmail.com>님의 말:

[배정일]

설계에 대한 정의와 설계의 필요성에 대한 이야기를 흥미롭게 읽었습니다. 제 견해는 양자의 의견을 모두 존중합니다. 

설계는 어떻게 구현할 지에 대한 방법을 명시화한 것이라고 생각합니다. 설계의 목적은 구현과정을 실수없도록 하며 anyone, anytime 반복가능하게 하는 것입니다 레고성의 매뉴얼처럼 말이죠 

소프트웨어 개발 시 모델링은 필수적인 일입니다 데이터, 프로세스, 룰 등 ...

안타까운 현실은 이를 제대로 하는 개발자가 많지 않다는 것입니다

클래스나 메소드의 이름은 모델링의 결과이며 역할과 책임의 시작입니다 

이 모든 것은 설계과정이 필요한 이유입니다 하지만 과도한 설계를 좋아하지는 않습니다

악보를 못보는 연주가나 악보만 그리고 악기를 못다루는 건 문제가 되겠죠 교향곡에 지휘자가 필요하고 악보없이는 불가능하겠죠

["신병호(akaYUZI)"]

���迡 ���� Ȱ���� �ǰ߱�ȯ�� �ѹ�¦ ���� ���� �ͳ׿�.
��������� ���ǿ� ���� ����� �ʿ��� ������ ����, ���迡 ���ؼ� ���� �ý��ϴ�.

����� ���ڷ� Design�̶� ǥ������.

��� Design�� â���� ��� �ð������� ���������ν�
������� �ൿ�� ��ȭ��Ű�� ������� ���ϴ�.

Design�� �����ϵ��� ���踦 �����ϰ� �ְ��
���蹰, ���輭�� Design�� �ð�ȭ ������ �����ϰ� ���� �ֽ��ϴ�.

����, �ð�ȭ�� ����� (��� ���·ε� ����) �������� ������
Design�� (������) ���� ���� ������ ���մϴ�.

�̷��� ���� �ð�ȭ�� Design ����� �Ӹ������� ����ϴ���� ���������ν�

1. ���ذ���ڵ� ���� ����� �ϰ�, ���̵��/�ǰ�/������ �����ϰ� ���ݴϴ�.
2. �ý��۰� ��ü������ ��ü������ �ĺ��ϰ� ���ְ�, ����ִ� ���п��ΰ� ���ո����� �巯���ְ�
3. (���� ����) ��� ����ڵ鿡�� ����� �˷��༭ �����ϰ� ����� ��� ����ϰ�
4. �ð�ȭ�� �͵� ���� ��� communication�ǰ� ��޵Ǿ, (���������) ����Ȱ���� ������ġ�� ������ �ְ�
5. ���濡 ���� ������ �ٿ��� ���ο� ��Ʈ�ʸ� ����� �ڱ��� �����ϴµ� ������ �Ǵ�

���� ���� ������ ���ؼ� ��� ���輭�� �ݵ�� �ʿ��ϴٰ� ���մϴ�.
�ٸ�, å�� �����ִ� ���ø��� ��� ���輭�� �� �ǹ̰� ��ٰ� �����.
Design���ν��� ���踦 �Ͽ��� ���� �����ϴ� �ð��� ��� ����� �ȴٰ� ��dz׿�.

...





2011-12-26 ���� 12:57, ������ �� ��:

���迡 ���� ���ǿ� ���� �� �ʿ伺�� ���� �̾߱⸦ ��̷Ӱ� �о���ϴ�. �� ���ش� ������ �ǰ��� ��� �����մϴ�. 

����� ��� ������ ���� ���� ����� ���ȭ �� ���̶�� ���մϴ�. ������ ������ ���������� �Ǽ���� �ϸ� anyone, anytime �ݺ������ϰ� �ϴ� �� �Դϴ� ���?�� �Ŵ���ó�� ������ 

����Ʈ���� ���� �� �𵨸��� �ʼ����� ���Դϴ� �� ����, ���μ���, �� �� ...

��Ÿ��� ������ �̸� ����� �ϴ� �����ڰ� �� �� �ʴٴ� ���Դϴ�

Ŭ������ �޼ҵ��� �̸��� �𵨸��� ����̸� ���� �� å���� �����Դϴ� 

�� ��� ���� ��������� �ʿ��� �����Դϴ� ���� �� ���� ���踦 ���������� �ʽ��ϴ�

�Ǻ��� ��� ���ְ��� �Ǻ��� �׸��� �DZ⸦ ��� ��� �� ������ �ǰ��� ���� �����ڰ� �ʿ��ϰ� �Ǻ����̴� �Ұ����ϰ���

 

 

�ź�ȣ  �濵��ι� ��ȹ������  Tel : 02-3485-4698 / Fax : 02-3438-4909 / Mobile :011-892-8653 E-mail:yu...@xener.com Homepage:http://www.xener.com ����� ������ ����2�� 261���� �������ڷ��� ���� 5�� (��)���ʽý�����

Contact Me

[gyehong park]

좀 늦었지만 상철님 질문에 답변드립니다.

제가 이상하다고 했던 이유는 상철님과 창준님이 이야기해 주신 스펙 관련된 부분입니다.

그 부분을 지적하고 싶었던 이유는 이춘식님의 글을 살짝 잘못 이해한 부분이 있었습니다.

"제가 드린 질문에 이렇게 좋은 답변도 해주셨습니다."

==> 이 말을 위와 같이 궁금한 것이 있었는데 인터넷 블로그에서 좋은 답변을 찾았다고 이해했습니다.
정말로 질문을 하셨고 답변을 블로그로 받은 것인 줄은 몰랐습니다. ^^;

그리고 좋은 답변을 "정답"으로 인식하고 있다고 해석을 했습니다.

그런데 그 블로그 글에 빨간색으로 강조된 부분이 저에게는 이상했습니다. 블로그에 좋은 부분도 많았기에 저에게 이상한 것으로 보이는 부분을 이야기할 필요가 있다는 생각이 들었습니다. 

덫붙여서 과도한 설계(?)라는 것을 제가하고 있는 프로젝트에서 느끼고 있기도 했습니다.

여러 종의 디바이스를 다루는 프로젝트를 하고 있습니다. 그런데 이 디바이스마다 연동되는 레거시 시스템이 조금씩 달라집니다. 실제 서비스는 간단하지만, 이런 것들 때문에 프로젝트는 훨씬 커지고, 여러가지 문제도 많이 생기고 일정도 계속 연기가 됩니다. 그래서 이런 생각들을 하고 있었습니다.

• 먼저 한가지 디바이스를 다루는 프로젝트를 해서 서비스를 했으면 어땠을까?
• 한 가지 서비스가 성공한 이후에 또 몇 종, 그 이후에 또 몇 종을 했으면 어땠을까?

프로젝트 전체를 잘 몰라서 그런 생각을 하는 것 같기도 하고,

그렇더라도 뭔가 더 좋은 방법이 있는 것 같은 고민도 하고,

이런 식의 진행에는 애자일 방법론으로 하면 아주 잘 될 수도 있다는 생각도 하고,

그러던 차에 요즘 많이 드는 제 생각과 대치되는 글을 읽으니 무엇인가 이상하다는 느낌이 들었습니다. ^^*

2011년 12월 23일 오후 3:02, Sangcheol Hwang <k16...@gmail.com>님의 말:

[gyehong park]

아래에 창준님이 하신 말씀을 따라가면서 제 생각을 정리 해 봤습니다. 

창준님 글에 코맨트 달았습니다.

제 생각이 맞다, 안 맞다라기 보다는 생각을 해 보는데 의미를 뒀습니다.

그런데 웬지 제가 한 정의를 따라가면 창준님의 질문이 별 의미가 없는 것 같습니다.

무엇인가 크게 잘못 생각하고 있는 것일까요? 

제가 정의한 설계라는 단어는 크게 의미가 없는 느낌도 들고......

다른 분들은 어떤 생각을 하실지 궁금하네요.

2011년 12월 24일 오후 9:38, June Kim (김창준) <june...@gmail.com>님의 말:

우리가 생각해봐야 할 부분은 과연 무엇이 설계(design)인가 하는 것인데...

소프트웨어 설계란 무엇인가? 요구사항을 만족하는 소프트웨어를 어떻게 만들지 계획하는 것.

따라서,

완변한 설계는 있다. 요구사항을 어떻게 만족하면 될지를 완벽하게 계획할 수 있다.

요구사항에 맞는 가장 좋은 설계는 없다. 시스템, 언어, 개발자 등에 따라서 다른 설계가 더 좋을 수 있다.

설계가 변하는 것이 아니라 요구사항이 변하는 것이다.

우선 내가 생각하는 "설계가 전혀 없는 프로그램", "설계를 최대로 한 프로그램", "설계를 한 건지 안 한건지 애매한 프로그램"의 예를 각기 하나씩이라도 생각해 보시면 내가 주로 생각하는 설계의 정의에 대한 몇 가지 힌트를 얻으실 수 있을 것 같습니다(참고로 사람에 따라 위 세가지 범주에 대한 답 하나 이상이 공집합일 수 있습니다).

위 정의로 하면 웬지 별 의미가 없는 것 같습니다.

• 설계가 전혀 없는 프로그램 : 없다. 어떤 프로그램이든지 만들기 전에 조금이라도 계획을 한다.
• 설계를 최대로 한 프로그램의 예 : "hello world"를 출력하는 간단한 프로그램 만들기. 자신이 잘 아는 언어로 원하는 환경에서 특정 출력 수단을 이용해서 어떻게 "hello world"를 출력할 수 있는지 알 수 있을 것이다.
• 설계를 한 건지 안 한건지 애매한 프로그램 : 없다.

이렇게 하면 의미가 있을까요?

• 설계가 가장 잘된 프로그램.
• 모든 요구사항을 만족한다.
• 가장 단순한 코드로 구성된 프로그램.
• 설계가 가장 잘못된 프로그램
• 모든 요구사항을 만족하지 못한다.
• 설계가 잘못된 프로그램
• 일부 요구사항을 만족하지 못한다.
• 모든 요구사항을 만족하지만 속도가 느리다.

여전히 별 의미가 없는 듯한.

여기에 추가적으로 생각해볼 질문 몇가지입니다:

0) 설계는 활동(activity)일까요, 결과물(artifact)일까요 아니면 양자 모두일까요? 각각의 범주는 어디까지일까요? 나는 주로 어떻게 "설계"라는 단어를 쓰나요? (이하 질문에서 나오는 "설계"라는 단어는 행동 혹은 결과물 혹은 양쪽으로 모두 해석가능합니다)

설계는 활동이다.

 

1) 특정 형태의 설계문서가 있으면 "설계가 있는 것"이고, 그 형태의 설계문서가 없으면 "설계가 없는 것"이라고 할 수 있을까요?

그렇지 않다.

 

2) 소스코드(및 주석) 외에 별도의 종이문서, 전자문서가 없는 시스템이 있을 경우 "설계가 없다"라고 할 수 있을까요?

없다.

 

3) 만약 어떤 프로그래머가 한참을 골똘히 생각하더니 프로그램을 작성해서 완료했습니다. 이 프로그램은 설계 없는 프로그램인가요, 아니면 설계 있는 프로그램인가요?

설계가 있는 프로그램이다.

 

4) 어떤 프로그래머가 별 생각 없이 프로그램을 시작하면서 하는 도중 간간이 골똘히 생각을 하면서 프로그래밍했습니다. 이 프로그램은 설계 있는 프로그램일까요 아닐까요?

설계가 있는 프로그램이다.

[harukee]

0) 설계는 활동(activity)일까요, 결과물(artifact)일까요 아니면 양자 모두일까요? 각각의 범주는 어디까지일까
요? 나는 주로 어떻게 "설계"라는 단어를 쓰나요? (이하 질문에서 나오는 "설계"라는 단어는 행동 혹은 결과물 혹은 양쪽으로
모두 해석가능합니다)

양자 모두라고 생각합니다. 비즈니스 프로세스에서는 결과물이 없는 활동은 의미가 없으니까요.

1) 특정 형태의 설계문서가 있으면 "설계가 있는 것"이고, 그 형태의 설계문서가 없으면 "설계가 없는 것"이라고 할 수 있을까
요?

형태는 중요하지 않지만 결과물이 있어야 할 것 같습니다.

2) 소스코드(및 주석) 외에 별도의 종이문서, 전자문서가 없는 시스템이 있을 경우 "설계가 없다"라고 할 수 있을까요?

소스코드 및 주석도 문서화의 한 방법이므로 설계가 있다고 할 수 있습니다.

3) 만약 어떤 프로그래머가 한참을 골똘히 생각하더니 프로그램을 작성해서 완료했습니다. 이 프로그램은 설계 없는 프로그램인가

요, 아니면 설계 있는 프로그램인가요?

설계가 있는 프로그램입니다. 요구사항에 대해 잘 알고 있는 경우에 해당하겠죠.

4) 어떤 프로그래머가 별 생각 없이 프로그램을 시작하면서 하는 도중 간간이 골똘히 생각을 하면서 프로그래밍했습니다. 이 프로그

램은 설계 있는 프로그램일까요 아닐까요?

설계가 있는 프로그램입니다. 처음부터 생각할 수 없는 것을 만들 때도 있으니까요.
이런 때는 직접 코딩해가면서 새로운 사실을 발견하기도 합니다.

위의 질문에 덧붙여 이야기 하자면
그래도 중요 도메인에 대해서 보다 형식을 갖춘 문서가 필요하다고 생각합니다.

[글뻥]

조금 정리해보았습니다.
내용이 많아서 블로그에 링크 올렸어요.

http://www.wolfpack.pe.kr/712

On 12월23일, 오전11시49분, 이춘식 <choon...@gmail.com> wrote:
> 안녕하세요? 다소 촌스러운 질문일까요?
>
> 여기에 계신 훌륭한 분들의 의견을 듣고 싶습니다.
>

> 여기서 찾은 인상 깊은 글은 여기에 있고,https://groups.google.com/d/msg/xper/9Ae5MvPDfmY/UnuVij4bTbgJ
>
> 제가 드린 질문에 이렇게 좋은 답변도 해주셨습니다.http://allofsoftware.net/entry/IsDesignNeeded

[Jake Kim]

제 경험담을 말씀드리고 싶네요.

현재 제가 몸 담고 있는 회사에서 제가 현재 하고 있기 때문에 현실성이 없다고 말할 수는 없습니다.
저희는 설계를 합니다. 다만 모든것을 문서화하지는 않습니다.
개발과 테스트에 필요한 인원이 모여서 설계를 합니다. 설계의 목적은 서로의 이해를 돕기 위한 것입니다. 이러이러한 기능이 들어
갈 것이고 이것들은 어떻게 구현이 될 것이며 이러이러한 테스트가 필요할 것 같다.... 이러한 내용으로 미팅을 합니다.

저희는 소스코드에 설계가 있습니다. 따라서 코드리뷰를 중요하게 생각합니다. 매니저가 쓴 코드도 일반 개발자가 리뷰를 합니다. 어
떤 때는 변수 이름까지도 지적을 할때가 종종 있습니다. 그리고 코드에 대한 코멘트를 중요하게 생각합니다. 나중에 누가 봐도 왜
이 한줄의 코드가 들어가 있는지 이해할 수 있게 하기 위함입니다. 물론 모든 코드에 코멘트를 달지는 않습니다. 백그라운드 이유
가 복잡할 경우 코드보다 많은 양의 코멘트를 적는 경우가 많습니다. 이 두가지로 만족을 못하는 경우를 문서로 남깁니다. 전체적
인 그림에 대한 이해가 필요한 경우, 왜 이러한 아키텍쳐적인 결정을 내렸는지에 대한 문서를 남깁니다.

저희가 이러한 방법을 채택하게 된 것은 이런것이 가장 좋을 것이라는 생각을 했기 때문이 아니라 이런 저런 방법을 찾다 보니 여기
에 도달한 것이라고 말씀드릴 수 있습니다.
누구에게나 맞는 방법은 없습니다. 어느 조직이든 그 조직에 가장 적합한 방법이 있다고 생각합니다.

[문 병조]

설계란 무엇인가? 라는 질문으로 바뀌는 듯한 느낌이네요. 

비개발자로서 바라보니 형식, 비형식으로 구분되거나, 형태의 유무로 구분되는 등 고민의 내용이 다양한 것 같습니다. 

저희 회사에서 요즘 한창 초등생용 영어교재를 만들고 있는데 처음 진행하다보니 담당하시는 분이 이만저만 고생하는게 아닙니다. 비전문가가 헤드매니저인지라 초기 "설계"에 많은 공을 들였습니다. 등산으로 비유하자면 설악산과 지리산의 장단점을 비교하기 위해 열번정도 왕복해봤다고 할까요. 저 또한 영어 사운드 녹음문제 때문에 (저 역시 이 부분 비전문가지요) 업체들 만나고 면담하는 등 시간을 많이 투자해 업무파악을 했습니다. 저는 사운드 관련 설계도는 없지만 과정과 결과를 정리해 담당자에게 전달했습니다. 

문제는 비전문가인 담당자가 자신의 설계도를 믿지 못하는 것입니다. 해보기 전에 결과를 정확히 알 수 있다면 좋겠지만, 현실적으로 어려운 일이니 결정된대로 밀고나갔으면 좋겠는데 일정에 억지로 끌려가는 모양새입니다. 

이야기가 산으로 올라갔네요. 

제가 드리고 싶은 말은 설계도는 최초 또는 최고 담당자만 알 수 있는 그림을 구체적으로 표현한 것이고, 다른 사람들에게 추상적으로 전달하면 안되기에 만들어내는 결과물이라는 겁니다. 

그룹에서 설계도를 작성하는 것은 규약을 만드는 것으로 보면 되는 것이겠죠? 혼자서 만들때야 굳이 설계도라는 것이 필요친 않을 것 같구요. 머릿속에 떠오르면 실행하면 되겠죠. 

결론은 "누군가와 함께" 결과물을 내려면 "어떤 형태던지" 설계도는 필요하다라는 게 제 생각입니다. 

*** 아침 출근길에 쓰고 저녁 퇴근시간에 올리니 글이 엉망입니다. 그나마도 보내지 못하면 그냥 묻힐까 두려워 글을 내보냅니다. 그런데 하나 궁금한 것이 생겼습니다. 잘하고 있다고 평가를 내려주는데도 자신감이 떨어지는 경우의 직원에게는 뭐라고 얘기해줘야 할까요? 윗글에서 썼던 동료에게 솔직하게 얘기해주는데도 너무 힘들어하기만 하는군요. ***

사람과 사람 사이를 고민합니다. 

2011. 12. 23. 오전 11:49 이춘식 <choo...@gmail.com> 작성:

안녕하세요? 다소 촌스러운 질문일까요?

여기에 계신 훌륭한 분들의 의견을 듣고 싶습니다.

여기서 찾은 인상 깊은 글은 여기에 있고, https://groups.google.com/d/msg/xper/9Ae5MvPDfmY/UnuVij4bTbgJ

제가 드린 질문에 이렇게 좋은 답변도 해주셨습니다. http://allofsoftware.net/entry/IsDesignNeeded

[Steve Yoon]

안녕하세요? 윤경록입니다.

재미있는 글타레라고 생각되어 숟가락 얹어봅니다. 히히.

1. 설계가 전혀 없는 프로그램: 동작되지 않는 프로그램

2. 설계를 최대로 한 프로그램: 개발자가 자신의 필요에 의해 만든 혼자만 쓰는 프로그램

3. 설계를 한 건지 안 한건지 애매한 프로그램: 고객이 영업사원에게 요청하고, 영업사원이 개발 팀장에게 요청하고, 개발 팀장이 팀원에게 지시한 프로그램 (단, 의사소통이 고객-영업사원, 영업사원-개발 팀장, 개발 팀장-팀원만 가능하고 "왜"라고 질문하기 어려운 문화일 때)

0) 설계는 활동(activity)일까요, 결과물(artifact)일까요 아니면 양자 모두일까요? 각각의 범주는 어디까지일까요? 나는 주로 어떻게 "설계"라는 단어를 쓰나요? (이하 질문에서 나오는 "설계"라는 단어는 행동 혹은 결과물 혹은 양쪽으로 모두 해석가능합니다)

: 저는 주로 소프트웨어 개발을 할 때 관련된 사람들과 '의사소통'을 하고 그것으로부터 '결정된 사항'들을 설계라고 생각하고 그렇게 이야기 합니다. 그래서 설계는 활동이자 결과물이라고 생각합니다.

1) 특정 형태의 설계문서가 있으면 "설계가 있는 것"이고, 그 형태의 설계문서가 없으면 "설계가 없는 것"이라고 할 수 있을까요?

2) 소스코드(및 주석) 외에 별도의 종이문서, 전자문서가 없는 시스템이 있을 경우 "설계가 없다"라고 할 수 있을까요?

: 설계를 관련된 사람들과의 '의사 소통'이라는 활동과 그것으로부터 '결정된 사항'이라는 결과물로 보고 있기 때문에, 특정 형태의 설계 문서가 설계 유무의 조건으로 생각하지 않습니다. 다만 기록으로서 특정 형태의 설계 문서를 남길 수는 있을 것 같습니다. 그리고 코드와 주석으로 기록할 수도 있을 것이라고 생각합니다.

3) 만약 어떤 프로그래머가 한참을 골똘히 생각하더니 프로그램을 작성해서 완료했습니다. 이 프로그램은 설계 없는 프로그램인가요, 아니면 설계 있는 프로그램인가요?

4) 어떤 프로그래머가 별 생각 없이 프로그램을 시작하면서 하는 도중 간간이 골똘히 생각을 하면서 프로그래밍했습니다. 이 프로그램은 설계 있는 프로그램일까요 아닐까요? 

: 그 프로그램이 혼자서 쓰는 것이라면 설계가 있는 프로그램이라고, 그 프로그램이 남을 위해 작성한 것으라면 설계를 한건지 안한건지 애매한 프로그램을 만든거라고 생각합니다.

이 글을 쓰면서 즐거웠던 점이, 생각을 정리해볼 수 있는 시간이 되었다는 것 입니다.

모두들 즐거운 연말 되시길 바랍니다.

윤경록 드림

--
-----------------------------------------------------------------
Name : 윤경록
MSN : steveyoon77@지메일.com
Blog : http://steveyoon77.tistory.com
twitter : @steveyoon77
- 日新又日新