wintiger's Life

[펌]

[지디넷코리아]IT는 서버, 네트워크, 프로그램 및 사람과 같은 구성요소가 복합적으로 작용하여 사용자에게 서비스를 제공하게 된다. IT의 구성요소 중에 하나라도 결함이 발생하게 되면, 이것은 IT서비스의 중단이나 품질저하 또는 보안 사고 등을 유발할 수 있다. 

IT의 구성요소 중, 특히 ‘프로그램’은 사용자와의 직접적인 접촉을 담당하고 있으며, 사용자의 요청을 처리하고, 다른 IT구성요소와 커뮤니케이션을 하는 중요한 역할을 수행한다.  

사용자가 IT조직의 담당자를 접촉하지 않고 프로그램과 직접 대화(?)하는 경우, IT조직은 이러한 대화에 끼어들 여지가 없다. 오직 사용자와 프로그램간의 무언의 접촉만이 존재할 뿐이다. 사용자 입장에서도 본인이 요청한 결과를 프로그램이 제때 제공만 해준다면 프로그램이 다른 IT구성요소와 어떤 행위를 하는 지에 대해서는 알 수도 없고, 또 참견할 이유가 없다.  

프로그램을 만든 IT조직 역시, 사용자가 특별한 불만을 제기하지 않는다면 사용자와 프로그램간의 커뮤니케이션이 잘 되고 있는 것으로 믿게 된다. 이러한 믿음은 프로그램을 사용자가 사용하는 운영환경에 출시하기 전에 충분하게 테스트를 했다고 IT조직이 믿는데(또는 믿고 싶은데) 근거한다.  

정말 프로그램들은 믿을만한가?  

사용자들도 자신들이 사용하는 프로그램이 안전한 방법으로 처리되어 결과를 제공하는 것으로 믿고 싶어한다. 그러나 IT에 종사하는 사람들은 IT조직의 수준에 따라 프로그램 신뢰도가 천차만별이라는 것을 알고 있으며, 함량 미달의 프로그램들로 인한 문제점들을 직간접적으로 경험해 오고 있다.  

■누더기 프로그램의 출현

국내 대부분의 IT조직들은 개발자 이외에는 프로그램 소스를 들여다 보지 않는 경향이 있다. 프로그램에 대한 테스트조차도 만들어진 프로그램을 이것 저것 클릭해보면서 사용자 입장에서 ‘작동’되는 지를 확인하는 데 그치는 경우가 많다.  

오래 사용돼 온 프로그램들 중에는 사용자 입장에서 작동은 되지만 처리 속도가 유달리 느리거나 뭔가 이상하다는 느낌을 주는 프로그램들이 있다. 특히 사용자 업무의 잦은 변경으로 빈번하게 프로그램 수정이 일어난데다, 개발자가 자주 바뀐 경우 미심쩍은 프로그램이 발생할 가능성이 높다.  

이런 프로그램의 소스를 들여다보면 ‘누더기’ 프로그램임을 발견할 수 있다. 누더기 프로그램이란 장황하게 긴 프로그램 소스 목록을 가지고 있다. 이에 개발자는 어떤 의도로 소스를 만들었는지를 타 개발자가 이해하기 어렵고, 이런 이유로 후임 개발자는 프로그램의 전체적인 맥락을 파악해서 수정하는 것이 아니라 임시방편으로 전임 개발자의 기존 소스에 덧대는 방식으로 유지해 온 프로그램들을 지칭한다.  

■누더기 프로그램의 이면  

누더기 프로그램은 IT조직의 바람직하지 못한 개발 관행의 폐해를 고스란히 담고 있다. 프로그램은 개발자의 개인 소유가 아님에도 불구하고, 프로그램을 만든 개발자 이외에는 프로그램을 이해하기가 매우 어렵다. 개발자가 평생 자신이 만든 프로그램을 돌보는 것이 아니라면 기본적으로 프로그램은 인수인계가 가능해야 한다.  

그러나 상당수 IT조직에서는 프로그램을 개발하면서 지켜야 하는 개발 원칙이 없거나 불분명한 경우가 많다. 프로그램 소스의 한 줄 한 줄은 나름의 이유가 존재한다. 개발원칙과 같은 서로의 약속이 없다면 수 백 줄 이상으로 자라나게 되는 프로그램 소스에 대해, 어떤 요구사항을 기반으로 개발자가 소스를 만들어낸 것인지를 파악하는 것은 매우 어렵다. 후임 개발자가 퇴직한 개발자들을 계속 귀찮게 하는 것도 이러한 상황 때문에 발생한다.  

■개발 자원과 시간의 부족  

IT조직 내에 누더기 프로그램을 탄생하게 만드는 이런 상황은 당연히 개발자의 잘못이 아니다. 해당 프로그램을 담당하는 개발자 이외에는 프로그램 개발 프로세스 내에서, 프로그램 소스를 열어서 검토할 수 있는 능력을 가진 사람을 배치하지 못하는 IT조직의 비용 문제가 그 원인 중 하나다.  

타인이 만든 프로그램 소스를 검토하기 위해서는 충분한 개발 경력을 갖춘 개발자가 필요하다. 그러나 이런 개발자를 프로그램 소스를 검토하는 데 전적으로 투입하는 것은 과다한 투자라고 생각하는 경향이 IT조직에 존재한다.  

시간이 부족한 것도 누더기 프로그램의 존재를 유지하게 만드는 원인이다. 적정한 수준을 가지는 프로그램을 만들기 위해 소요되는 시간을 무시하고 철야를 불사하며 개발자를 밀어붙이는 IT조직에서는 양질의 프로그램을 기대할 수 없다. 
 

■개발 프로세스의 한계  

IT조직의 프로그램 개발 프로세스는 ‘사용자요청->승인->소스코딩->테스트->승인->운영이관’의 순서를 기본으로 한다. IT조직의 규모나 특성에 따라 프로그램 개발 프로세스를 좀더 복잡하게 또는 요약된 형태로 운영된다.  

프로그램 개발 프로세스를 얼핏 보면 역할 및 책임이 분리돼서 프로그램이 잘 관리되는 것처럼 보이지만, 실제로는 소스코딩 이후의 전 단계에 있어, 프로그램 소스의 내용은 개발자 혼자만이 독점하고 있는 경우가 많다.  

승인이나 테스트 과정의 검증은 프로그램의 정상적인 작동에만 초점을 맞추어서 확인하는 관계로, 프로그램 소스 자체의 품질을 들여다 보는 ‘디테일’까지는 접근하지 못하고 있다는 것이다.  

■프로그램 소스와 보안 

프로그램 소스는 IT조직이 가지고 있는 보안의 ‘아킬레스건’이다. 대부분의 IT조직은 보안을 강화하기 위해 서버, 네트워크 및 데이터베이스 부분의 보안솔루션 도입에 투자를 집중하고 있다. 하지만 개발자가 프로그램 내부에 나쁜 의도의 소스를 삽입하는 경우와 같이 프로그램 소스 차원에서의 악의적인 행위에 대해서는 특별한 대응방법이 없는 실정이다. 
 

보안 측면에서 프로그램 소스 차원의 악의적인 행위를 차단하기 위해서는, 개발자가 작성한 프로그램을 소스 수준까지 들여다 보고 한 줄 한 줄의 소스가 정당하다는 것을 확인한 이후에만 운영환경에서 사용할 수 있도록 허용해야 한다. 

하지만 국내 IT조직은 대부분 프로그램 소스를 들여다 보고 있지 않고 있으며, 더 심각한 문제는 개발자에게 개발환경과 운영환경 모두를 접근할 수 있도록 허용하고 있다는 점이다. 나쁜 의도를 가진 개발자에게 이러한 상황은 완전 범죄를 보장해준다.  

나쁜 의도를 가진 개발자는 사용자가 프로그램 화면상에서 볼 수 있는 부분을 프로그래밍한 다음, 사용자들에게는 특별한 리액션이 없고 몰래 작동하는 프로그램 소스를 추가로 프로그래밍할 수 있다. 개발자는 혹시라도 프로그램 소스 검토를 할까 봐 승인 받을 때는 사용자가 요청한 부분만 포함된 프로그램소스에 대해서 승인 요청을 할 수 있다.  

개발환경과 운영환경 모두를 접근할 수 있는 개발자는 승인 이후에 몰래 작동하는 프로그램 소스가 포함된 다른 버전의 프로그램을 운영환경에 올리면 그만이다. 누가 알겠는가? 추후에라도 승인 프로그램이 운영환경의 프로그램과 동일한 것이라는 것을 검증하는 IT조직은 거의 드물기 때문에 이러한 시도가 적발될 가능성은 거의 없다.  

■프로그램 소스 검토의 혜택 

IT조직은 누더기 프로그램이나 보안의 문제를 해결하기 위해서는 프로그램 소스 검토 활동을 일상 활동으로 정착시켜야 한다. 프로그램 소스 검토 활동을 수행할 여유 개발자가 없다면 옆의 동료 개발자가 검토하도록 하는 방법이라도 적용할 필요가 있다.  

프로그램 소스 검토 활동이 일상화 되면 IT조직은 누더기 프로그램 제거와 보안 문제의 해결뿐만 아니라 여러 가지 추가적인 이득을 얻을 수 있다.  

첫 번째는 프로그램 개발자의 개발 능력이 급격하게 향상된다.  

사실 개발자는 혼자서 터득한 방법으로 프로그램을 만들어왔다. 그러나 다른 개발자의 프로그램 소스를 검토하는 과정에서 본인이 해왔던 프로그램 기법이 완전하지 않다는 것을 깨닫게 되고 다른 개발자의 좋은 프로그래밍 기법을 벤치마킹 하게 된다.  

두 번째는 프로그램 자체의 품질 수준이 높아진다.  

제조업의 경우, 과거 장인의 능력에 의존해서 제품을 만들던 시절에는 장인의 반발로 인해 장인이 만든 제품을 다른 사람이 평가하는 활동이 불가능했다. 장인이 독자적으로 만든 제품은 장인의 컨디션에 따라 품질이 들쭉날쭉 할 수 밖에 없었고 이것은 제품의 전반적인 품질을 저하시키는 원인이 되었다. 국내 제조업의 경우, 제품에 대한 품질 평가를 독립적으로 평가하기 시작하면서부터 제품의 품질이 좋아지기 시작했고 현재는 글로벌 최고 수준을 유지하고 있다.  

IT조직이 동료나 제3자에 의한 프로그램 소스 검토 활동을 정착시킨다면 양 쪽의 건전한 긴장 관계로 인해 프로그램의 품질 수준이 현격하게 높아지는 것을 경험하게 된다.  

세 번째는 프로그램의 장애가 줄어든다.  

프로그램 소스 검토 활동이 일상화되면, 여러 개발자를 거친 프로그램일지라도, 프로그램 소스에 대한 설명이나 로직이 명쾌해지기 때문에 프로그램의 수정을 자신 있게 할 수 있다. 프로그램 수정이 일어나는 부분이 다른 프로그램이나 IT구성요소에 어떤 영향을 미치는지를 파악하기 쉽기 때문에, 프로그램으로 인한 오류나 장애가 현격하게 줄어든다. 

■프로그램 소스에 대한 관심 필요
 
국내 IT조직들이 IT수준을 높이기 위해 많은 노력을 하고 있다는 것을 알고 있다. 하지만 그런 노력들 속에는 프로그램 소스에 대한 관심이 포함되어 있지 않다는 것을 느끼고 있다.  

수준이 높은 IT조직은 예외 없이 프로그램 소스 검토 활동을 수행하고 있다. 또 글로벌 IT 프로젝트에서는 프로젝트 기간과 프로젝트 이후에 프로그램 소스의 품질을 어떻게 보장할 것인가를 매우 중요한 항목으로 다루고 있다.  

국내 IT조직들이 높은 수준의 IT서비스를 제공하기를 원하고 국내 IT 시장에서 좋은 IT 품질로 생존하기를 원한다면, 이제 프로그램 소스와 관련된 활동을 시작해야 하는 시점이 아닌가 생각한다.

저번편에서는 과도한 압박이 실제로 어떤 부정적인 영향을 미치는지 알아보았습니다.

뭐 '좀비는 헤드샷'이라는 명쾌한 답을 제시해 주신 분들도 있고 스스로 좀비라고 자책하시는 분도 있었습니다.

제가 보기엔 스스로 좀비라고 자책하시는 분들은 약간의 보균자일뿐 아직 좀비는 아니실테니 걱정 안하셔도 될듯 합니다.(사실 진정한 좀비라면 이런 생각 이나 고민 자체를 하지 않습니다.)

사실 좀비는...

드마르코 형님의 책에서는 간단하게 나왔지만 많은 분들의 이해를 돕기위해 강조하였는데 의외로 좀비에 꽂히신 분들이 많아서 이걸 어떻게 풀어야 할지 많이 고민이 됩니다.

일단 이번엔 전편에 이어서 빨리 빨리와 압박을 실제로 구현하기 위해 관리자들이 저지르는 대표적인 바보짓 두개를 언급해 보겠습니다.

좀비들을 만들어내는 마스터(관리자)가 되는 법

아키텍트로서 성장하기 위한 길은 막막하게 느껴지곤 한다. 누구에게 아키텍트로서 가야 하는 길을 물어야 할 것인가? 산전수전 다 겪은 나이가 지긋한 아키텍트로 활동 중인 사람을 만나기란 하늘의 별따기다. 따라서 필자는 업계 최고의 아키텍트들의 조언을 모아 가상의 인터뷰를 진행해 봤다. 이 인터뷰의 내용은 필자가 PLoP라는 패턴학회에서 만난 해외 거장들과의 토론과 조만간 출간될 번역서인 『아키텍트가 알아야 할 97가지』의 내용을 모아 만들었다.

손영수 안녕하십니까? 여러 선배님들. 아직 ‘Architecture’의 ‘A’자도 깨우치지 못했지만, 여러 선배님들에게 아키텍트로 성장하기 위한 방법과 또 아키텍트로서 올바른 아키텍처를 바라보는 방법들을 여쭤 보고자 합니다. 많은 이들이 궁금해 하는 질문일텐데, 여러 선배님들처럼 훌륭한 아키텍트가 되기 위해선 어떠한 것들을 준비해야 할까요? 실제 현업에서 아키텍팅할 때 어떠한 부분을 고려해야 할지 여러분들의 얘기를 듣고 싶습니다.

 

요구사항

Rick Kazman

실제 프로젝트는 요구사항 분석에서부터 시작한다고 할 수 있죠. 이때 아키텍트가 가져야 할 중요한 덕목은 소통과 협상 능력입니다. 설계 능력 못지않게 중요한 능력이 Social Skill입니다. 다양한 이해당사자들이 모두 만족할 수 있는 시스템을 만든다는 것은 어쩌면 불가능에 가까운 일입니다.

이해당사자들의 요구사항들이 서로 충돌하는 경우도 많이 경험했습니다. 빠른 메시지 전송뿐만 아니라 높은 보안 수준을 요구한다거나, 자원의 제약이 심한 임베디드 시스템에서 고성능 PC에서나 가능한 퍼포먼스를 요구하는 것들을 예로 들 수 있죠.

아주 적은 금액으로 모든 문제를 해결해 엄청난 효과를 누리려는 이해당사자에게 정말 기간 내 구현 가능하고 필요한 기능을 뽑아 현실에서 실현 가능한 상황에 대해 이해시키는 것이 중요합니다. 만약 여기서 이해당사자들과의 합의를 이끌어내지 못하거나, 정확한 요구사항을 파악하지 못한다면 프로젝트는 초창기부터 산으로 가게 됩니다. 그 만큼 소통과 협상 능력은 아키텍트에게 설계 능력만큼 중요한 요소라는 점을 기억해 주시길 바랍니다.

Mark Richards 저도 비슷한 사례를 말하고 싶네요. 전 프로젝트를 시작할 때 항상 꺼내는 이야기가 있습니다.  소프트웨어 아키텍트들이 알아야만 하고, 이해해야 하는, 그리고 고객, 동료와 함께 꼭 프로젝트 시작 전 나눠야 하는 이야기가 있습니다. 1620년대에 스웨덴과 폴란드의 전쟁에서 나온 ‘Vasa호’라는 배 이야기입니다.

스웨덴 국왕은 전쟁을 빨리 끝내고 싶어서 Vasa호라는 특별한 배를 만들라고 주문했습니다. 이 배가 갖춰야 했던 조건(요구사항)들은 그 당시의 어떤 배와도 비교할 수 없었습니다. 선체가 200피트 정도 더 길고, 2개의 갑판에 64개의 총을 적재할 수 있고, 300명의 군사를 안전하게 태워 폴란드로 가는 바다를 가로지를 수 있는 수송 능력을 가져야 했습니다. 배를 건조하는 데드라인(시간)을 엄수해야 했으며, 재정(자금)적으로도 여유롭지 않았습니다.

또한 배 설계자(아키텍트)는 이렇게 생긴 배를 이전까지는 설계한 적이 없었습니다. 크기가 작고 총을 실을 수 있는 갑판이 한 개만 있는 배를 만드는 것이 그가 주로 한 일이었습니다. 그럼에도 불구하고, 설계자는 그의 예전 경험을 기반으로 추정하고 Vasa를 설계하고 건조하기 시작했습니다. 그 배는 결국 설계대로 건조되었고 마침내 배를 띄우는 날이 왔습니다. 어떻게 되었을까요? Vasa호는 위풍당당하게 항구를 출항했지만 예포를 쏘고 난 뒤 바로 바다 저 밑으로 가라앉고 말았습니다.

Vasa호의 문제는 명확합니다.

그 어느 누구도 1600~1700년에 큰 전투함에서 갑판을 본적이 없었고 이러한 배의 갑판은 특히 전쟁 중에 붐비고 안전하지 않다는 것을 알았습니다. 전투함과 운송선 2개의 역할을 다하는 하나의 배를 건조하는 것은 큰 실수였죠. 국왕의 모든 소원을 충족하려고 한 배 설계자는 균형이 맞지 않고, 불완전한 배를 만들 수밖에 없었던 것입니다. 저희 소프트웨어 설계자들은 Vasa호로부터 많은 것을 배울 수 있습니다. 이와 같은 불행한 사건을 소프트웨어 아키텍처의 설계에 적용할 수도 있겠죠. 하지만 Vasa호와 같이 모든 요구사항을 충족시키려는 시도는 궁극적으로 아무것도 수행할 수 없는 불완전한 아키텍처를 만들게 됩니다.

손영수 정말 깊이 새겨야 할 교훈이네요. 그렇지만 많은 관리자나 고객이 수많은 요구사항들을 결국 쏟아내는데요. 이 사람들을 설득하고 요구사항 간에 균형을 맞추는 방법은 무엇일까요?

Rick Kazman 이해당사자들 간에 서로 상충되는 요구사항들을 우선순위화해서 아키텍처를 도출하는 ATAM(Architecture Tradeoff Analysis Method)이라는 방법이 있습니다. 이해당사자들 간에 제한된 투표권을 준 다음 정말 중요한 것 몇 개만 선택하게 하는 거죠. 그래서 정말 중요한 것들을 우선순위화할 수 있게 됩니다. 좀더 자세한 내용은 제가 쓴 『소프트웨어 아키텍처 이론과 실제(Software Architecture in Practice)』에 자세히 설명되니 읽어 보시길 바랍니다.

손영수 그 외에 요구사항을 파악할 때 더 주의해야 할 것은 없을까요?

Eben Hewitt 여러분에게 시스템 구축을 의뢰한 고객은 여러분의 진정한 고객이 아닙니다. 여러분의 고객의 고객이 진정한 고객이지요.

손영수 무슨 의미인지 정확히 이해되지 않는데요. 좀 더 자세히 설명해 주십시오.

Eben Hewitt

여러분이 전자상거래를 구축해야 한다면 여러분의 고객보다는 최종 웹사이트를 이용하는, 즉 웹사이트에서 물건을 구매하는 사람들에게 더 주의를 기울여야 합니다.

실제 웹사이트 사용자들은 전송 보안(transport security)을 필요로 할 것입니다. 그들은 저장된 데이터 암호화가 필요한 것입니다. 여러분의 고객은 이러한 요구사항을 언급하지 않을 수도 있습니다. 고객의 고객이 필요로 하는 것을 여러분의 고객이 빼먹은 것을 안다면, 왜 이러한 것들이 필요한지 언급하고 그 이유에 대해 자세히 설명해야 합니다.

만약 여러분의 고객이 실제 웹사이트 사용자에게 꼭 필요한 기능에 관심이 없다면, 프로젝트에서 잠시 물러서 제 3자의 입장에서 고려하십시오. 공격적인 고객(Sally Customer)은 매년마다 SSL에 대해 라이선스 비용을 치르기를 원하지 않고, 구축비용이 적게 든다는 이유만으로 그들의 신용카드 정보가 간단한 텍스트로 저장되기를 원할 수도 있습니다. 이미 알고 있는 나쁜 생각들을 실행하는 것에 여러분이 동의하게 되면, 여러분은 요구사항 수집에 실패한 것입니다.

손영수 그런 깊은 뜻이 있었군요. 앞으로 명심하겠습니다. ‘고객의 고객을 고려하라.’ 정말 의미 깊은 조언이었습니다. 그럼 계속해서 다른 이야기를 나눠 보도록 하죠. 아키텍트로서 고려해야 할 다른 것들이 있으면 조언 바랍니다.

프로세스와 팀 구축

James O. Coplien 전 프로세스와 조직에 대한 이야기를 꺼내고 싶습니다. 혹시 Conway의 법칙을 아시나요?

이는 여러분이 하나의 컴파일러를 만들기 위해 4개의 팀을 만든다면, 여러분은 4단계(four-pass) 컴파일러를 얻게 된다는 것입니다. 즉 조직구조에 의해 소프트웨어 구조가 정해진다는 얘기입니다.

이미 팀이 구성된 후 요구사항을 분석한다면, 팀 구조에 맞춰 분석이 이뤄지기 때문에, 팀 구조 그대로 소프트웨어 구조가 나올 수밖에 없습니다. 소프트웨어의 특성을 파악하기도 전에 소프트웨어의 큰 구조를 정하는 우를 범한 것입니다.

만약 팀 구성 후, 어느 팀도 맡기 애매한 요구사항을 발견했다면, 이 사각지대를 서로 맡지 않기 위해 여러 가지 복합적인 일들(정치, 책임회피 등)이 발생하게 됩니다. 이 경우 종종 프로젝트가 산으로 올라가게 됩니다. 그야말로 길을 잃는 것이지요. 그래서 팀을 구축하기 이전에 비즈니스 프로세스를 정제할 필요가 있습니다. 비즈니스 프로세스를 정제한 후에 조직을 구성해야 책임의 사각지대가 생기는 것을 막을 수 있죠.

손영수 그렇군요. 효율적으로 팀을 구축하기 이전에 어떻게 해야 할까요?

Krysztof Cwalina

프로젝트 관리자는 팀을 구성하기 이전에, 애플리케이션의 특성을 고려해 ‘땅콩버터나 마천루(적합한 프로세스)’를 선택해야 합니다.

땅콩버터(Peanut Butter)는 ‘Feature들이 중심이 되어 소프트웨어를 만드는 Bottom-Up 방식의 프로세스’를 말합니다. Bottom-Up 프로세스는 기존의 비교 대상도 없고, 전혀 새로운 소프트웨어를 만들 때 주로 사용하는 방법입니다. 이 방식은 견고하고 더디지만 모든 Feature들이 골고루 기능 향상을 가져올 수 있는 장점이 있습니다. 실제 땅콩버터처럼 모든 기능들이 골고루 퍼지고 진화할 수 있어서 땅콩버터 방식이라고 말합니다. 흔히 하위 레벨의 프레임워크나 저 수준의 라이브러리를 개발할 때는 이러한 방식이 선호됩니다.

만약 여러분의 소프트웨어가 고객의 요구사항들을 다수 받아들여야 하고 다양한 시나리오를 요구하는 경우인데도 Feature에 초점을 맞춘 땅콩버터 식의 프로세스와 조직을 구성하게 되면 어떻게 될까요? 위에서 언급한 것과 같이 새로운 시나리오가 탄생하면 많은 조직들이 협업해야 될 뿐만 아니라, 기능을 명쾌하게 나누기가 애매한 경우 많은 정치와 책임의 분배 문제 등이 발생됩니다.

이와 상반된 방식으로 마천루(Skyscraper) 방식이 있습니다. 시나리오가 마천루처럼 높이 솟아 전체 소프트웨어의 기능을 구현하기 위한 좋은 기준이 된다는 것입니다. 명백한 기준이 있다는 것은 많은 시행착오를 줄일 수 있을 뿐만 아니라, 고객의 관점에서 소프트웨어를 생각할 수 있는 장점을 가질 수 있습니다. 흔히 우리가 알고 있는 시나리오를 만들고 프로토타입(Prototype) 방식으로 개발해 나가는 것이라고 생각하면 됩니다. 바로 Top-Down 방식의 프로세스가 여기에 해당되죠.

여러분의 소프트웨어가 상위 레벨의 응용 소프트웨어로서, 많은 사람들에 의해 사용된다면 당연히 시나리오 기반(Sky scraper)의 방식으로 팀을 구성해야 합니다.

손영수 제가 알기론 마이크로소프트에서는 Feature Crew라는 이름으로 이미 시나리오 기반으로 팀원들이 구성되어 있다고 들었습니다. 또한 애자일(Agile)에서는 Cross-Functional Team이라고 부르기도 합니다. 정말 시나리오 기반의 애플리케이션을 개발하는 곳에서는 좋은 방법일 것 같습니다.

Rick Kazman 좋은 얘기를 해주셨네요. 우리가 설계하고자 하는 최종 소프트웨어를 고려한 형태로 조직과 프로세스가 선택되어야 합니다. 단순히 애자일의 바람이 불어서, 또는 RUP가 좋으니 이걸 사용하자는 식보다는 소프트웨어의 특성, 조직의 문화 등을 고려해 적용하는 것이 중요합니다. UML의 창시자 Ivar Jacobson 역시 RUP를 넘어 EssUP(Essential Unified Process)라는 새로운 것을 내놓았는데, 핵심은 조직과 소프트웨어 특성에 맞게 적합한 프로세스를 고려하라는 것입니다.

설계

손영수 그럼 설계 시 고려해야 할 것은 무엇입니까?

Kevlin Henney 여러분이 설계 시 둘 중 하나를 선택해야 한다면 대부분은 중요한 것을 선택합니다. 하지만 설계(소프트웨어 또는 다른 것들) 시에는 그렇게 해선 안 됩니다. 두 가지 선택사항이 존재한다는 것은 설계 시 불확실성을 고려할 필요가 있다는 것을 알려주는 지표(indicator)입니다.

A와 B 두 가지 중 하나를 결정하려고 시도하는 것보다는 A와 B 사이의 결정을 덜 중요하게 만들기 위해 어떻게 설계해야 할지를 고민해야 합니다. 흥미로운 것은 A와 B 사이의 (적절한) 선택이 존재한다는 것입니다. 설계 시 변경되는 결정을 쉽게 수용할 수 있는 분할(separation) 또는 캡슐화 기법을 고민할 필요가 있습니다.

손영수 그럼 좀 더 SoC(Separation of Concerns)와 캡슐화를 잘 하기 위해선 어떻게 해야 할까요?

Einar Landre

넬슨 제독이 1805년 트라팔가에서 프랑스와 스페인 함대를 격파한 이후, ‘분할 후 정복(Divide and Conquer)’ 또는 ‘걱정거리의 분리(Separation of Concern)’는 복잡하고 어려운 문제를 다루는 슬로건(상징)이 되었죠. 걱정거리의 분리로부터 우리는 캡슐화를 얻게 되고, 캡슐화로부터 우리는 경계와 인터페이스를 얻게 됩니다.

Kevlin Henney가 말하는 것처럼 아키텍트가 가장 크게 겪는 난제는 동작하는 시스템을 구축하기 위해 필요한 인터페이스를 정의하고 경계를 정하는 자연스러운 위치를 찾는 것이죠. ‘결합도는 낮추고 응집도는 높여라’와 ‘정보 교환이 자주 발생하는 영역들은 나누지 말라’와 같은 오래된 명언들이 몇 가지 지침을 제공하지만, 어떻게 이해당사자들에게 가능성 있는 해결방안과 문제들에 대해 쉽게 소통할 수 있는지는 알려주지 않습니다.

손영수 그렇군요. 결국 이해당사자들과 소통 속에서 적합한 균형을 찾아야 된다는 말씀이군요. 그럼 어떻게 하면 이러한 균형을 잘 찾을 수 있을까요?

Einar Landre

Eric Evans의 책인 『Domain-Driven Design』에 나온 Bounded Context(문맥 정합)와 Context mapping(문맥 맵핑)의 개념이 앞에서 언급한 이해당사자들과 소통의 문제를 잘 해결해 줍니다. Bounded Context는 모델이나 개념을 고유하게 정의하는 영역입니다. 그리고 우리는 Bounded Context를 설명부를 가진 구름 또는 거품으로 표현합니다. 이 설명부는 도메인에 가까운 모델 또는 개념의 역할과 책임을 정의합니다. 한 가지 예를 들면, 운송 시스템은 화물 운송, 화물 일정, 항구 이송과 같은 Context(문맥)를 포함합니다. 다른 도메인에서는 다른 이름들을 사용하는 게 적합할 것입니다.

Bounded Context들을 화이트보드 위에 식별하고 같이 그림으로써, Context 간에 연관관계를 그리는 것을 시작할 수 있습니다. 이러한 연관 관계들은 조직적, 기능적, 기술적 의존성을 설명하면 좋습니다. 이러한 행위의 결과로, Context 간에 인터페이스와 동일한 의미로 인식한 Context의 집합을 나타내는 Context Map이 생기게 됩니다.

Context Map은 아키텍트에게 무엇을 같은 걸로 볼지, 별개의 것으로 볼지 초점을 맞출 수 있고, 좀 더 현명하게 대화를 나눔으로써 분할 후 정복할 수 있는 강력한 도구를 제공합니다. 이런 지침을 통해 약한 결합, 높은 응집, 잘 설계된 인터페이스로 구성된 시스템으로 재설계할 수 있습니다.

손영수 결국 고객의 대화를 잘 이해함으로써 이러한 균형점을 찾을 수 있다는 정말 와 닿는 얘기입니다. 그럼 아키텍트가 설계 시 추가적으로 고려해야 할 사항은 무엇일까요?

Doug Crawford 변화의 충격을 이해할 필요가 있습니다. 뛰어난 아키텍트는 복잡도를 최소한으로 줄일 수 있어야 하며, 단단한 기본 구조를 취하면서도 급변하는 상황에 적절히 대처할 수 있는 실용적인 해결책들을 설계할 수 있어야 합니다.

뛰어난 아키텍트는 고립된 소프트웨어 모듈에서뿐만 아니라 사람과 사람 사이, 시스템과 시스템 사이에서 일어나는 변화의 충격을 이해해야 합니다. 변화는 기능 위주의 요구사항 변경, 요구사항의 진화, 수정된 시스템 인터페이스들, 팀원의 변동과 같은 다양한 형태로 나타날 수 있습니다.

소프트웨어 프로젝트 변화의 광범위함과 복잡함을 미리 추측한다거나, 모든 잠재적 문제를 미리 예측해 해결한다는 것은 불가능합니다. 하지만 아키텍트는 이러한 변화가 발생했을 때, 다른 객체나 모듈에 변화를 전파시키지 않고 변화의 충격을 완화시켜 수용할 수 있는 시스템을 구축해야 합니다. 이러한 변화를 완화하기 위한 도구나 기법으로는 다음과 같은 것들이 있습니다.

• 반복 가능한 테스트 케이스를 만들고 자주 실행하기
• 쉬운 테스트 케이스를 만들기
• 의존성 추적하기
• 조직적으로 행동하고 반응하기
• 반복적인 태스크는 자동화하기

또한 위험을 미리 측정하는 Premortem은 어떠한 부분에 집중적으로 시간을 투자해야 할지 알려주는 유용한 도구입니다. 아키텍트는 프로젝트 범위의 관점에서 시간, 예산과 같은 변화의 영향을 미리 추정해야 하고 변화로 인해 엄청난 영향을 받는 부분에 더 많은 시간을 투자해야 합니다.

손영수 변화를 수용할 수 있는 구조, 소프트웨어 개발 생명주기의 관점에서 볼 때, 유지보수에 70%의 비용이 드는 관점으로 볼 때는 정말 중요한 말씀이군요. 저 같은 경우는 설계 시 실제 아키텍처를 검증하기 위해 몇 가지 프로토타입을 만들어 종종 검증합니다. 이것은 어떨까요?

Clint Shank

좋은 방법입니다. 애플리케이션 아키텍처를 구현하고 검증하고 진화시키는 유용한 전략 중 하나로 Alistair Cockburn이 이야기한 ‘걸어 다니는 해골(walking skeleton)’이 있습니다. 걸어 다니는 해골은 종단(예를 들어 UI부터 DB까지) 간을 오가며 수행되는 시스템의 가벼운 구현체입니다. 모든 주요 아키텍처상의 컴포넌트는 전부 연결합니다.

모든 호출(Com munication) 경로를 실험할 수 있게 작동하는 작은 시스템부터 시작한다면, 옳은 방향으로 설계 및 개발해 나갈수 있습니다.

손영수 그럼 이제 개발 과정에서 아키텍트는 어떠한 일을 하는지 궁금합니다.

개발

Erik Doernenburg 아키텍트는 현재 개발하고 있는 소프트웨어가 얼마나 잘 개발되고 있는지를 파악할 수 있어야 합니다.

사용자에게 가치 있는 소프트웨어도 중요하지만, 내부적으로 좋은 품질을 유지하는 것도 중요하죠. 좋은 품질을 얻기 위해서는 쉽게 소프트웨어를 이해, 유지보수, 확장할 수 있어야겠죠. 그럼 소프트웨어가 잘 개발되고 있는지 매 순간 상황을 파악하기 위한 방법에는 어떤 것이 있을까요?

많은 이들이 UML로 그려진 아키텍처 다이어그램을 사용합니다. 하지만 아키텍처 다이어그램에서 작은 상자들은 전체 시스템을 나타내며 상자 간의 선은 시스템 간의 의존성, 데이터 흐름, 버스와 같은 공유자원 등 모든 것이 될 수 있습니다.

마치 비행기에서 보는 풍경과 같은 30,000피트 뷰입니다. 너무나 추상화되어 있는 관점이죠. 반면에 0피트, 즉 바닥 레벨의 뷰를 보기도 합니다. 즉 소스 코드를 보는 것이지요. 바닥 레벨의 뷰는 연관 있는 몇 개의 객체 구조도 보지 못할 정도로 너무나 많은 정보를 제공합니다.

즉 이 두 뷰는 소프트웨어 품질에 대한 많은 정보를 제공하지 못한다는 것이지요. 그래서 0피트와 30,000피트 사이에 적절한 뷰가 필요합니다. 바로 1,000피트의 뷰입니다. Dependency Structure Metrics로 모듈 간의 의존성을 파악할 수 있으며 Code Metrics를 이용해 클래스의 크기를 파악할 수 있습니다.

특정 클래스가 거대하다는 것은 너무나 많은 책임(역할)을 가지고 있다는 의미죠. 이러한 다양한 지표들(클래스 팬아웃, 메소드 개수, Circular Dependency 등)을 지원하는 사용 툴들(NDepend, XDepend, JDepend)을 이용하면 됩니다.

손영수 1,000피트의 뷰라니 정말 멋있는 표현입니다. 저 역시 리팩토링할 때 DSM과 Code Metrics를 즐겨 이용하는 편인데, 다행히 방향은 제대로 잡은 것 같습니다. 그럼 다른 조언도 부탁합니다.

Dave Quick

거울로 보이는 문제는 실제 보이는 것보다 클 수 있습니다. 많은 소프트웨어 프로젝트에 참여했던 그 동안의 경험에 비춰 보면, 각 팀의 구성원들은 팀이 예상한 것보다 더 많은 문제를 가지고 있습니다. 소규모의 팀은 이런 문제들을 초기에 확인할 수 있지만, 대부분 잊어버리거나 무시합니다. 그 이유는 프로젝트 초기에는 이 문제가 얼마나 프로젝트 후기에 큰 영향을 미치는지를 이해하지 못하기 때문입니다. 이러한 문제를 초기에 대처하기 위한 몇 가지 전략이 있는데 다음과 같습니다.

• 리스크를 관리하는 조직화된 접근 방법을 만들어야 합니다. 리스크를 관리하는 간단한 방법은 여러분이 버그를 추적할 때와 같은 방식으로 리스크를 관리하는 것입니다. 누구나 리스크를 발견할 수 있고, 각각의 리스크가 더 이상 리스크가 아닐 때까지 추적할 수 있습니다.

그 후 리스크들에 우선순위를 매기고 리스크의 상태가 변화하거나 새로운 정보가 있을 때마다 리뷰를 합니다. 리뷰는 토론를 통해 감정적인 면을 배제하도록 도와주고 주기적으로 리스크를 재평가함으로써 쉽게 기억하도록 도와줍니다.

• 주류의 의견에 반대할 때는 나머지 팀원들이 자신의 의견을 더 쉽게 이해하도록 만드는 방법을 찾아야 합니다. 반대 의견의 가치를 인식하고 모든 팀원에게 용기를 주십시오. 그리고 토론 시 팀원들이 중립적인 자세를 가지도록 하십시오.
• ‘구린 냄새(Bad smells)’를 주의해야 합니다. 아직 명확한 근거가 없다면 사실을 확인할 수 있는 가장 간단한 테스트 방법을 찾으세요.
• 지속적으로 팀과 고객에 대해 이해하는 내용을 테스트해 보세요. 사용자 이야기(user story)로 우선순위 목록을 정하는 툴의 도움을 받을 수 있지만, 정기적으로 고객과 대화를 나누는 열려 있는 자세를 대체할 순 없겠죠.
• 맹점이란 그 말 의미 자체가 말해주듯이 스스로 인지하기 어렵습니다. 여러분이 필요로 할 때 말하기 힘든 사실을 말해주는 믿음직한 사람이 여러분의 귀중한 자산입니다.

손영수 개발 도중에도 아키텍처만 그려주고 사라지는 아키텍트가 아닌, 팀원 간 또는 이해당사자 간에 소통이 잘되는 문화를 만들고 잘못된 방향으로 흘러가면 가이드해서 바로 잡아야 한다는 조언이군요. 그럼 아키텍트가 가져야 할 자세에 대해서도 조언 바랍니다.

 

아키텍트로서 갖춰야 할 자세

 

 

Dave Quick 아키텍트는 자신이 최고라는 대문자 ‘I’보다는, 일원이라는 의미를 가지는 소문자 ‘i’의 자세가 필요합니다. 아키텍처를 수립할 때, 여러분 스스로가 최악의 적이 될 수도 있습니다. 여러분이 고객보다 요구사항을 더 잘 이해한다고 생각하거나, 개발자를 아이디어를 구현하기 위한 단순한 자원으로 보거나, 여러분의 생각에 도전하는 개발자나 팀원을 무시한 경험이 있습니까? 성공이나 사회적 지위로 인해 자만하거나 다른 사람들이 우리를 존경한다는 착각을 가지고 있고, 자신이 만든 설계에 도전하는 것을 여러분 자신의 인격에 대한 도전으로 받아들인 경험이 있을 것입니다. 이것은 과거의 성공에 빠져 여러분을 더 작은 한계에 가두는 짓입니다.

아키텍트로서 스스로 성장하고 성공하는 프로젝트를 만들기 위해서는 여러분의 마음가짐을 바꿔야 합니다. 전 후배 여러분들에게 다음과 같은 자세를 요구합니다.

• 요구사항은 거짓말을 하지 않습니다. 요구사항이 제공하는 비즈니스 가치를 이해하기 위해 고객과 가까이 일하십시오. 아키텍처를 여러분이 이끌려 하지 말고 요구사항이 이끌도록 하십시오. 여러분은 최선을 다해 그들의 필요를 섬겨야 합니다.

• 팀에 집중하십시오. 팀은 자원이 아닙니다. 그들은 여러분의 설계 협력자이자 여러분의 안전망입니다. 진가를 인정받지 못하는 사람은 보잘 것 없는 안전망을 만듭니다. 아키텍처는 팀의 것이지 혼자만의 것이 아닙니다. 여러분은 가이드라인을 제공하고 모든 사람이 협력해 함께 이끄는 것이라는 마음가짐을 가져야 합니다.

• 여러분의 업무를 점검하십시오. 모형은 아키텍처가 아닙니다. 이것은 아키텍처가 동작하는 방법에 대한 여러분의 이해일 뿐입니다. 프로젝트 아키텍처가 각 요구사항을 어떻게 지원하는지 검증하는 테스트 항목을 정하기 위해 여러분의 팀과 함께 일하십시오.

• 여러분을 돌아보십시오. 자기의 일을 방어하고, 이기적인 관심에 집중하고, 우리 자신을 방 안에서 가장 영리한 사람으로 여기는 우리의 본능과 싸워야 합니다. 매일 몇 분 동안 여러분의 행동에 심사숙고해 보십시오. 여러분은 모든 사람의 아이디어에 그들이 마땅히 받아야 할 존경과 인정을 주었습니까? 여러분은 선의의 참여에 부정적으로 대하지는 않았습니까? 누군가가 여러분의 접근 방법에 왜 불응했는지 이해하기 위해 노력해 보신 적이 있습니까? 자기 자신을 되돌아 볼 필요가 있습니다.

손영수 저도 그렇게 생각합니다. 제가 소문으로 들었던 몇몇 아키텍트들은 많은 반대에도 불구하고 자신의 생각을 관철시키곤 했습니다. 설계 자체의 옳고 그름을 떠나 개발자들과 소통 없이 일방적으로 자신의 생각을 강요했죠. 그 결과로 설계 따로, 개발 따로 하는 프로젝트가 되었다는 이야기를 들었습니다. 개발자를 이해하는 아키텍트, 그리고 아키텍트를 이해하는 개발자들이 모여야 정말 좋은 프로젝트로 갈 수 있을 것입니다. 마음가짐에 대한 또 다른 의견도 듣고 싶습니다.

David Bartlett    아키텍트는 쇼맨십을 뛰어넘는 가치 있는 청지기 의식(Stewardship)을 가져야 합니다.

아키텍트들은 프로젝트에 착수할 때, 자신의 가치를 입증하려는 갈망이 있죠.

소프트웨어 회사에서 아키텍트 역할을 맡는다는 것은 아키텍트의 기술적 리더십을 회사의 일부분으로 절대 신뢰한다는 의미입니다.

그런데 불행히도 자신의 가치를 입증하기 위해 개인의 기술적 탁월함과 쇼맨십으로 팀원들을 이끌어야 한다고 오해하는 아키텍트들이 있습니다. 사람들에게 어필하는 행동인 쇼맨십은 마케팅에서는 중요할지도 모릅니다. 하지만 소프트웨어 개발 프로젝트에 있어서는 역효과를 나타낼 뿐입니다.

아키텍트는 확고한 리더십으로 그들 팀의 존경을 얻어야만 하고 기술과 팀이 운영하는 비즈니스 도메인의 이해가 있어야 합니다. 책임지고 다른 이들을 돌보는 청지기 의식은 아키텍트에게 꼭 필요한 자질입니다. 아키텍트는 고객을 위해 최선을 다해야 하지, 고객의 요구를 이용하려고 해서는 안 됩니다.

소프트웨어 아키텍처는 고객의 요구들을 수행하는 것으로, 보통 탁월한 능력을 소유한 도메인 전문가의 방향 제시로 이뤄집니다. 성공적인 소프트웨어 개발을 추구하는 것은 아키텍트가 프로젝트에 주어진 시간과 노력에 대비해 구현의 복잡성과 비용 사이에 균형이 잡힌 절충된 솔루션을 만들게 합니다.

최신의 따끈따끈한 프레임워크나 기술 전문 유행어로 이뤄진 과도하게 복잡한 시스템은 비용 지출의 희생을 담보로 합니다. 아키텍트의 활동은 투자 브로커처럼 합리적인 ROI(투자 대비 수익률)를 창출할 수 있다는 전제 하에 고객의 돈을 사용하도록 해야 합니다. 여러분이 다른 사람의 돈을 사용하고 있음을 절대 잊어버려서는 안 됩니다.

손영수 아키텍트 명함을 가지고 다니는 사람들 중에는 신기술로 도배된 제품을 팔기 위한 비즈니스맨인지, 아키텍트인지 구분하기 힘든 이들이 있습니다. 청지기 의식이라는 것을 통해 많은 것을 되돌아보게 되었습니다.

지금까지 여러분의 소중한 조언을 들을 수 있었습니다. 설계만 잘하기 위한 공학적인 기법만큼 외부와 소통 및 협상하고, 팀원들을 이끄는 정신도 중요하다는 것을 깨우치는 시간이 되었습니다. 이 가상 인터뷰가 아키텍트를 꿈꾸는 많은 이들에게 유용한 시작점이 되었으면 합니다.

이 세미나는 PLoP이라는 패턴 학회에서 직접 경청한 내용을 다듬었습니다. Rebecca Wirfs-Brock이라는 아키텍트가 패턴의 아버지이자, 건축,철학의 대가인 Christopher Alexander의 서적들을 읽고 SW에 맞게 빚대어 설명한 내용입니다.

다소 추상적일 수도 있으나, 한번 보시는게 좋을거 같아 적어봤습니다. ( 동완이의 그림책을 위하여!! 추천 부탁드립니다.)

Rebecca Wirfs-Brock 국내에는 비교적 많이 알려져 있지 않지만, 정말 현실을 직시하는 몇 안되는 Architect입니다.

일전에 소개 드린것 처럼, 절대 어느 한가지 맞다고, 자기의 설계 기법이나, 방법을 따라야 한다는 몇몇 아키텍트와 달리.

여러가지 해결책을 펼쳐놓고, 주어진 상황에서 적합한 전략/솔루션을 선택하는 아키텍트 입니다.

아마도 패턴에 영향을 많이 받아서 그런거겠죠. 패턴 자체가 그러거니깐요.

패턴을 공부하다 보면 무엇이 맞다는 것 보다나는, 주어진 Context/Resulting Context를 심각히 고려하고 그중에 적합한 것을 선택하는 자세가 몸에 베이게 됩니다. 그게 아니면 제대로 패턴을 익힌거라고 할수 없으니깐요.

물론 저는 이제 아주 아주 조금 눈을 떠 가는 중이구요.

(전 애벌레입니다. :) - 몇몇 대단하게 보시는 분이 있어서. 오해를 하시지 마시기를...)

저도 많은 정보를 전달해 드리고 싶지만, 영어가 짧고, Nature of Order에 대한 선 지식이 없어서, 잘못된 내용이 있을수도 있습니다. (폭탄 발언?) 여튼 제가 이해하는 것이 잘못되었다고 생각하신 분은 댓글을 달아 주시면 바로 수정하겠습니다.

일단 잘못된 정보를 전달하면 안되기 때문에 글을 쓰지 말라는 분도 있지만, 누군가 정확한 의견을 전달해주면 그걸 수정하는 것이 맞지, 실패나 비난을 두려워해 아무것도 공유하지 않는 것은 정말 비겁한 자세라고 개인적으로 생각합니다. 전 정반합이 힘을 믿습니다.

Christopher Alexandar의 Nature of Order라는 서적은 크게 4가지 Volume으로 구성되어 있지만, Rebecca는 두권만 언급했습니다.

• 1st Volume은 the fifteen property of things (어떤 존재, 사물에 대한 15가지 속성)
• 2nd Volume은 Unfolding process for create“lively” things (살아있는 생명쳬를 만들기 위한 절차들)

오늘 Rebecca가 발표한 내용은 1st Edition에 나오는 15가지 속성을 기반으로 S/W에 빚대어 설명하는게 골자입니다.

1시간에 이런 무거운 내용을 전달하다 보니, 하고 싶은 얘기를 다 못껴내신거 같더라구요.

그리고 저 역시도 영어가 짧아서.. 이해를 다 하지는 못한거 같습니다.

Rebecca 아주머니는, Habitable Software라는 이야기를 꺼내며 화두를 시작했습니다.

사용하기 편하고, 경험하기 쉬운 소프트웨어를 말하는 데요. 이러한 시스템을 구성하기 위해 Alexandar가 말하는 15가지 속성으로 잘 구성되어야 된다고 얘기를 꺼냅니다.

Alexandar가 말하는생명체가 가지는 15개의 속성

• Levels of scale
• Strong centers
• Boundaries
• Alternating repetition
• Positive space
• Local symmetries
• Good shape
• Deep interlock and ambiguious
• Contrast
• Gradients
• Roughness
• Echoes
• The void
• Simplicity and inner calm
• No-separateness

 

 

 

1. LEVEL OF SCALE

유기적인 소통.

먼저 Chirstopher Alexandar가 언급한 이야기를 꺼내셨습니다.

"A good design has differing levels of scale, whereas ugly, lifeless designs don’t take into account the interplay between design elements at different levels of scale."

잘 설계된 것은 Scale이 다양한 범위를 가진다. , 반면 , 생명력이 없는 설계(잘못된 설계)는 (Sacle의 다양한 범위를 가진 ) 설계 요소들간에 상호작용을 고려하지 않았다.

 

 

 

Josef Albers의 그림들을 설명하며, Chirstopher Alexandar가 좋지 않은 설계라고 말한 예라고 합니다. 크기가 서로 다른 범위를 가지고 있지만, 사각형간에 어떠한 상호 작용도 없습니다. 완전히 서로 독립적이며, 유기적인 대화를 하지 못하니 좋은 구조라 아니라는 거죠.

이걸 우리가 아는 예로 바꾸면, 거대한 아키텍쳐 속에서 무수한 설계들이 들어가 있습니다. 즉 Architecture 안에 수많은 Design들이 존재하고 , 이들 간 잘 유기적으로 엮어야 한다는 것입니다. 주구 장창 말씀 드린것 처럼, 어떤 하나의 요소를 선택해, 가지는 사이드 이펙트를 보완하기 위해 또 다른 요소가 필요하고 이들 간에는 서로 연관관계 . 소통을 해야 된다는 겁니다.

PLoP Bootcamp때 나온 IO GateKeeper의 단점을 극복하기 위한 IO Triage 그리고 이 Triage가 동작하기 위해 Timestamp가 필요한 것처럼, 서로 다양한 크기의 Element가 유기적으로 엮여 있어야 된다는 것이죠. 우리의 소프트웨어로 보면 Architecture안에 무수한 Design이 들어가 있으며, 이들간에 소통/Collaboration이 있어야 된다는 의미 입니다.

범위의 크기에 따라 구조의 크기도 결정되어 진다라는 말을 했습니다. 그리고 이들 크기가 다르면 접근하는 것도 달라야 된다고 말했습니다.

Rebecca는 스케일이 단위를 이렇게 나누어 설명했습니다.

Conceptual level - Specification level ? Implementation level (이것은 Martin Fowler가 Analysis Pattern에서 언급한 내용입니다.)

• a conceptual level, where we speak of a class’s responsibilities;
• a specification level of operations, attributes,and test specifications; and
• an implementation level of class, method, and variable definitions.

이에 Rebecca는 다음과 같은 말을 했습니다.

• At a lower level of scale, individual methods shouldn’t be too big. (개별적인 메소드가 너무 커서는 안된다.)
• At the next higher level, we don’t want to pack too much behavior into any subsystem or component. (특정 subsystem이나 component가 너무 많은 behavior를 가져서는 안된다)
• 이런 각 레벨에 대한 기준을 다 알고 있어도, 각기 다른 level(크기)에 Center (뒤에 Strong Cent에서 언급)들이 가져야 하는 만족할만한 비율들을 찾기 어려웠다고 하네요.

Scale은 추상화를 기반으로 구축되어야 한다.

그래서 나온 결론이 추상화 입니다. 항상 우리가 디테일한 부분까지 결정을 하기 어렵기 때문에 추상화에 초점을 맞추어 전체의 흐름을 지배하라는 얘기를 했습니다.

"Scale in building upon Core Abstraction : an example found in the smalltalk collection hireachy." Smalltalk에는 template method로 형태로 구현되어 있기 때문에 쉽게 메소드를 추가할수 있는 구조라며 설명을 했습니다. ( smalltalk은 제가 잘모르니 pass~~~ smalltalk에 대해서 아시는분이 좀 comment를 해주시면 될듯하네요.)

아시다시피 Template Method는 전형적으로 일반적인 클래스 흐름에 역행하는 방법(IoC)입니다. 자식이 부모를 호출하는게 일반적이네, 부모가 자식을 호출하게 되죠. 즉 Concrete Class에서 세부적인 메소드를 지정하고 전체적인 흐름은 부모 클래스에서 결정하죠. 즉 부모 큰래스는 전체적은 흐름을 관장하여 큰 추상화를 얻게 됩니다. Concrete Class는 단지 부모 클래스가 정한 흐름에 맞게 호출만 될 뿐입니다. 즉 강력한 제약으로 확장성/일관성을 얻어내는 좋은 방법입니다.

여튼 추상화 기법들을 잘 이용해서 확장성 있게 만들고 이것을 통해서 다른 레벨의 컴포넌트들과 잘 통신하게 만들라는 얘기였습니다.

2. STRONG CENTERS

살아있는 모든 것들은, 각기 다른 레벨의 구조를 가지고 있고, 이 각기 다른 구조들은 각기 개별적인 자기 고유의 초점을 가지고 있다는 겁니다 . 예를 든다면, 심장은 산소를 골고루 전달 하기 위해서, 대장은 영양분 흡수를 위해서, 각기 이렇게 다른 역할을 가지고 있다는 것을 의미하죠. 이들 각각 강력한 Center 를 가져야 된다고 말했습니다.

Software에서 Center

• Well-defined role and patterns of interaction
• Control centers
• Domain models : a network of entities, values, aggregate roots, Domain and relationships between them.
• ??? (그외 몇가지것을 더 언급했는데 못 적었습니다 .T_T)

그러면서, 자기가 만든 RDD (Responsibility Driven Design)이 이러한 철학으로 설계 되었다고 얘기합니다.

위가 RDD에 대한 예 인데, Strong Center와 맟 닿아 있는 것을 알수 있습니다. 하나의 생명체가 여러가지 유기적인 요소로 구성되어 있고, 각각 자신의 역할들을 가지고 있다는 것죠. 그리고 RDD에서 설명한 Streotype들을 보여주었습니다.

• Information holder - knows and provides information. (정보를 알고 제공한다)
• Structurer - maintains relationships between objects and information about those relationships. (객체간의 관계와 객체가 가지는 관계에 대한 정보들을 관리한다. )
• Coordinator ? mechanically reacts to events. (event에 기계저으로 대응한다)
• Controller - makes decisions and closely directs others' actions. (결정을 내리고, 다른 행위를 직접 지시한다.)
• Interfacer - transforms information and requests between distinct parts of a system (시스템의 구분되는 요소들간에, 정보를 변환하고, 요청을 한다.)
• Service provider - performs work on demand (요구되어지는 일을 수행한다.)

이러한 것들이 Strong Center가 되겠구나 알수 있었습니다. 이러한 것들을 하나씩 설명하면서 각기 다른 레벨마다, Controller 하나에서 모든 것을 관리해야 튼튼한 구조를 가질수 있다는 말을 했습니다.

그리고 RDD의 디자인 원칙들이 Christopher Alexandar의 원칙과 맞닿아 있는 것을 알수 있었습니다.

• Maximize Abstraction Initially hide the distinction between data and behavior. Think of objects responsibilities for “knowing”, “doing”, and “deciding”
• Distribute Behavior Promote a delegated control architecture Make objects smart? have them behave intelligently, not just hold bundles of data
• Preserve Flexibility Design objects so interior details can be readily changed

3. BOUNDARIES

경계는 center 그 자체의 고유성을 강화시키고, center와 center 주위의 연관되어 있는 것들을 결속시키는 것 둘다를 의미합니다.

Rebecca는 "인터페이스를 어떻게 정할건가가 곧 Contract가 되고 , 이것이 자연스럽게 경계가 된다"라고 말했습니다. 그럼 어떻게하면 경계를 잘 정하느냐에 대한 고민에 Rebecca는 Eric Evans의 DDD에서 언급한 Domain Aggregates를 좋은 예로 설명했습니다. (자세한 내용은 링크를 참고하세요. )

A domain aggregates is a cluster of associated objects that is treated as a unit for the purpose of data change.

 

이때 순간 저의 머리를 스쳐간게 .NET Framework의설계자인 Krysztof Cwalina의 Component (Framework Desing Guidelines 2nd)정의였습니다.

하나의 Unit으로써 배포되어질수 있고, 계속해서 요구사항들을 수용하며 진화, 발전할수 있는 타입들을 묶어놓은 집합이 Component 이다.

 

바로 유기적으로 묶여, 변화를 같이 흡수하고 , 어떠한 행위를 할때 같이 움직이는 단위들을 말하고, 곧 이게 경계가 된다는 의미로 받아들여 졌습니다. 또한 경계는 서로간의 구분을 짖는 요소입니다. 어떤 변화가 하나의 Boundary(경계)안에서 흡수되지, 다른 곳에 전파되지 못하도록 막는 좋은 예가 될거 같습니다.

물론 경계를 정하는 방법은 상황에 따라 유동적으로 정해질 것입니다. 저의 생각으로는 아마 다양한 XXX-Driven Design이 나오는 것들도 그리고 Zachman 스타일 처럼, 다양한 View를 봐야 하는 것도 이러한 이유라고 생각이 듭니다. 인터렉션의 기준이 될수도 있고, 배포가 기준이 될수도 있겠죠. 아마 현재의 시스템을 가장 잘 파악할 수 있고, 유지하기에 좋은 방식을 취하는 게 좋을것 같다는 생각이 듭니다.

이것 역시 해당 도메인의 경험이 쌓여야, 또는 배우고, 수련해야 가능한 일이겠죠 :) 경계를 정해서 개별 Center의 응집성을 올리고, 서로간의 변화에 대한 전파를 상쇄시키는 관점으로 이해해 주시면 될듯 합니다.

4. ALTERNATIVE REPETITION (교차적으로 일어나는 반복)

시스템 요소간에, 상호보완적인 교차와 반복이, 단순한 Iterration의 반복이 아닌.., 시스템의 행위와 동적인 구조를 식별하고, 강화시키고, 견고하게 만든다는 것을 의미합니다.

Uncle Bob의 SOLID Principle이 이러한 좋은 예가 될수 있습니다.

• Single Responsibility Principle - A class should have one, and only one, reason to change.
• Open Closed Principle - You should be able to extend a classes behavior, without modifying it.
• Liskov Substitution Principle - Derived classes must be substitutable for their base classes.
• Dependency Inversion Principle - Depend on abstractions, not on concretions.
• Interface Segregation Principle - Make fine grained interfaces that are client specific.

OCP와 LSP는 확장성을 얻기위해 제약과 Concrete Class간에 Responsibility를 설명한 부분이며, ISP와 SRP는 객체와 인터페이스의 역할에 초첨을 맞쳐 너무 무겁지 않는 가벼운 객체를 만드는 겁니다. DIP는 좀 특수한 경우이지만, 굉장히 자주 사용되는 구조이죠. (좀더 관심이 있으신 분은 저희 스터디팀이 4년전쯤에 발표한 동영상 강의를 보시면 될듯 합니다. Uncle Bob의 원본 자료와 송치형/최상훈님의 마소 내용들을 버무려 무료 강의를 만들었습니다.)

디자인 패턴을 공부하시는 분이 가장 큰 실수를 하시는 것이 아 이러한 Structure를 가지고 있으면 Decorator 구나, Proxy구나 라고 이것을 하나의 단위로 인식할려고 하십니다. GoF 패턴 Template이 가져온 오해였죠.

여러분이 좀더 쉽게 GoF 패턴을 바라보는 방법은 위 5가치 원칙들이 이러 이러한 상황에 쓰이면 Decorator구나, 이러 이러한 상황에 쓰이면, Proxy구나 이렇게 받아 들이는 것이 좀더 패턴을 알수 있는 방법입니다. 바로 이러한 원칙들이 모여서 GoF 패턴이 만들어 진 것이고, GoF를 접착제로 해서, 더 큰 아키텍쳐 패턴들이 엮이게 됩니다.

좋은 구조라는 것은 이러한 SOLID 같은 원칙들(자원을 공유해서 쓸때, process와 thread의 scheduling 기법등..)이 지켜지며, 교차적으로 반복되어 견고한 구조 (strong center)를 만든다는 의미입니다.

또한 Rebecca는 반복되는 Collarboration Pattern들이 Software Control Center 부분의 설계를 강화시킨다는 이야기를 했습니다.

저의 경험상으로는 Broker를 예로 들수 있습니다. Fault Tolerance 한 시스템을 구축하기 위해 필요한 IO Gatekeeper , CORBA의 Object Request Broker, Android의 Binder가 바로 좋은 예가 될수 있습니다. Broker를 구축함으로써, 주고 받는 Client/Server는 많은 골치거리 일들을 Broker에게 맡기게 되어, 이로서 얻는 부수적인 이익들(모니터링, Collabration, Heterogeneouse한 환경 극복등..)은 엄청나죠.

 

 

5. POSITIVE SPACE

시스템을 구성하는 각각의 요소들(elements)은 완전하고, 잘 정의되어있어야 하며, 시스템 그 자체 역시 견고해야 합니다. 그리고 각각의 요소들이 전체적으로 시스템에 적합하게 구성되어 있어야 함을 의미합니다.

잘 설계되고, 구현된 소프트웨어 시스템들은 불필요한 Component나 Code들을 포함해서는 안되겠죠. 또한 불필요한 행위나 Dependency를 가지고 있어선 안됩니다. 제가 알기로는 Rebecca가 구체적으로 언급하지 않았지만 Xper의 글과 지금까지의 설계 방식을 보면 POSA1권에서 봤던 CRC(Class-Responsibility-Collaboration) Card, Diagramming , Code 를 통해 이러한 문제를 해결해 왔음을 알수 있습니다. 사실 Refactoring을 할때, 객체가 필요이상의 Responsibility를 가지고 있느냐가 좋은 기준이 됩니다.

Rebecca는 Refactroing을 할때 Responsibiities를 재할당 할것인지? Class간에 균형을 유지할 것인지 많은 고민을 한다고 합니다. 이때 중요한 기준이 positive space라고 말했습니다. 가장 간단한고 필수적인 기능을 가지고 있느냐? 각각의 Element가 하나의 목적을 위해 만들어졌는지 보라고 했습니다. Space를 구성하는 ( Level of Scale과 유사한 개념) 각각의 요소들이 이것을 보장한다면, 결국 Strong Center를 잘 준수한 상황으로 불수 있다고 합니다.

또한 DRY (Don't Repeat Yourself - 모든 지식은 시스템 내에서 단일하고, 애매하지 않고, 정말로 믿을만한 표현 양식을 가져야 한다) 원칙을 준수하라고 말했습니다.

저는 개인적으로 Statci Analysis 방법중에서 DSM을 통해서 필요이상의 의존성이 갔는지, Code Metrics를 통해 너무 특정 Namespace/Class가 큰것이 아닌지 조사하면서 Refactoring의 기준을 잡고, 좋은 구조를 잡고 있는지 살펴봅니다. 물론 더 좋은 방법이 얼마든지 있을수 있지만, 저의 지식의 한계로 이 두개를 주로 사용합니다. 혹시 좀더 좋은 지표와 가이드라인을 아

시는 분이 있으면 알려주시길 합니다.

6. LOCAL SYMMERIES

 

Relationship이 대칭적이며, 반대되는 Force(영향력 - 초점) 또는 Interaction에 균형을 맞출때, 연관된 설계 요소들의 그룹들은 더욱 강력하고, 더욱 높은 응집력을 가집니다.

Rebecca는 대칭을 통해 설계의 유사(친밀)성, 응집력, 이해력 향상을 가져 온다고 말했습니다. 장황한 메소드들을 작은 Helper Method를 이용해 추상화하여 서로 유사한 Step을 가질수 있도록 Refactoring 할수 있다고 말했습니다. 결국 이러한 대칭성을 통해서 작게는 학습 곡선을 줄이고, 나아가서는 Template Method 화 시켜서, 동일한 제어 흐름을 타게 만들고, Dependency Injection을 통한 유연성도 확보할수 있겠죠.

또한 우리 프로그래머는 별 생각없이 이렇한 대칭성을 유지할려는 습성을 가지고 있다고 말했습니다. 우리가 모든 Attribute에 setter와 getter를 정의할려고 하지요. 하지만 이런 방법이 좋은 접근 방법은 아니라고 말했습니다. 먼저 어떻게 Object가 사용될건지 고려하라고 말했습니다. 우리가 추가한 대칭성이 소프트웨어의 거대한 체계에 어떻게 적합하게 동작할건지 충분히 고려한 다음 반영되어야 된다고 말했습니다.

사실 이 이야기를 들을때 생각난 부분이 바로 .NET Framework 를 만든 Krysztof Cwalina가 제시한 Guideline들이 바로 확 떠올랐습니다다.

The Power of Sameness 그리고 You Need Feedbacks!! 입니다. 프레임워크의 생존 문제와 연관되어 있는 사용 용이성 (Usability) 문제죠. 얼마나 개발자가 직관적으로 쉽게 쓸수 있는 Framework를 만드냐는 관점에서 나온 대표적인 해결책이 바로 이 두 Guideline입니다.

• 동일함의 힘 - 한국에서 운전을 한 사람이, 미국에서 운전을 별 어려움 없이 하는 이유는 자동차의 인터페이스가(핸들, 제어법)등이 다 동일하기 때문입니다. 그렇기 때문에 유사한 목적을 가진 객체를 유사한 인터페이스로 만들어야 합니다. 개발자의 학습 곡선을 크게 감소시킬수 있습니다.
• 피드백을 받으세요 - 하지만 이러한 인터페이스 대칭성을 만들기 전에 가장 중요한 부분은 잘 만들어진 인터페이스 (객체 모델)를 만드는 것입니다. 나 혼자 이것저것 고생하는 것 보다는 다른 사람의 관점을 빌려, 몇몇 시나리오 별로 내가 만든 객체 모델을 사용한 Code Sample을 해당 분야에 경험이 많은 프로그래머 몇명들에게 나눠줘, 피드백을 받아 다듬은 다음 객체 모델을 정하라는 가이드라인입니다. 이러한 설계 가이드라인이 크게 대칭(Symmetry)에 모태를 두고 있다니 놀라웠습니다. :)

7. GOOD SHAPE

시간이 지나도 변경되지 않고 유지되는 컴포넌트들은 작고, 응집력이 강한 연관성있는 컴포넌트들로 구성되어 있습니다. 그리고 내부적인 대칭을 생성합니다.

견고한 시스템은 Prmitive Element (기본 요소)부터 거대한 구조의 시스템 아키텍쳐까지 잘 설계되고, 잘 구현되어 있어야 합니다.Rebecca는소프트웨어가 Good Shape (좋은 모양)을 가지기 위해 우리가 고려해야 되는 부분들을 다음과 같이 열거했습니다.

• roles and patterns of collaboration - 패턴이라는 것은 개별적으로 동작하는 것이 아니라. 유기적으로 엮여 사용됩니다. 패턴들을 통해 소프트웨어의 상호작용하는 패턴들과 개별적인 객체간에 롤을 파악할 수 있습니다.
• layers - 고유성을 강화시키고, 서로간에 경계를 명확하게 만드는 것. 그래서 변화의 전파 충격을 흡수하게 만드는 등 여러가지 장점을 얻을 수 있습니다. 위에 언급한 Boundary가 바로 여기에 해당됩니다.
• sub-assemblies , modules - 더 작은 boundary로 볼수있는 단위다. 사견으로, 이때 dll과 같이 물리적으로 잘 나누어 재컴파일 없이 확장성을 얻게 만드는 것이 중요하다고 말씀 드리고 싶습니다.
• domain-specific business rules - Domain에 특화된 Rule들을 잘 정제시키고, 잘 소프트에어 넣는 것이 중요하다.

8. DEEP INTERLOCK AND AMBIGUITY

깊은 연관성을 가지는 컴포넌트들은 잘 정의된 경계(Boundaries)를 공유하고 있다. 경계를 통해 (컴포넌트간에 불필요한 의존성을 만들어내지 않는) 응집성을 생성해 낸다.

위에서 Ambiguity는 모호성이 아니라, 다중성 즉 다양한 성격을 가지게 만들라는 의미입니다. 확정성을 고려하라는 것이지요. 어려운 얘기입니다. 깊게 응집성을 가지면서도, 확장성을 가져야 된다는 의미입니다. 우리가 알고 있는 응집력은 높이고, 결합도는  낮추라는 격언과 일치합니다.

Rebecca는 "두 시스템의 Context를 파악하고, 이 시스템의  잘 감 쌀 수 있는 균형잡힌  Inteface 영역을 어디에 둘거냐?"에 초점을 맞추라고 했습니다.   거대한 시스템은 개발과 유지보수를 간단히 하기 위해 잘 모듈화 되어 있어야 합니다. 모듈은 또한 Tighting Coupling을 피하면서, 시스템의 goal을 달성할 수 있게 응집력있게 구성되어야 합니다.   이 원칙 또한 위에서 언급한 Boundaries와 깊은 연관성을 가지는데. 시스템의 part (부분 요소)간에 경계들이 어떻게 서로 상호작용하는지 정의하는데 초점을 맞추고 있습니다.

Rebecca는 우리 소프트웨어에서 어떻게 상호작용을 해야 되는지 가이드라인을 제공해 주었습니다.

• Collaboration between roles - 먼저 Role을구성하고, Role(Responsibility)간에 어떻게 Collaboration하는지를 고려해라!    POSA1 서적에 보면 패턴마다 CRC 가 있습니다. 서로간에 Responsilbity(Role)을 기술하고, 연관되는 요소를  기술하게 되어 있죠.  Xper의 Rebecca 인터뷰에서 나온 것처럼  Rebecca가 CRC를 즐겨쓰는 방법이랍니다.
• Interface and Contract Definition - 그후 Interface와 Contract를 정의해 어떻게 계약을 할지 정의해라.  Role(Responsibility) 기준으로 (객체, 모듈, 레이어 등..) 나누게 되고, 그 성격에 따라 Interface와 Contract(주고 받아야 하는 데이터 , 선행조건)등을 기술해야 합니다.
• Dynamic clients-supplier relationship - 동적으로 Client/Supplier관계를 가지는 것을 파악하고 다룰 방안을 고려해라.

또 다른 저의 경험으로는 Bottom Up 으로 가든, Top Down으로 가든, 아키텍쳐 레벨에서는 굉장히 추상적인 방식(Protocol 또는 Message 전달 )으로 통신하게 만들고, 디자인 레벨과 구현 레벨에서도 확장 가능한 형태로 Parameter Object 나 DTO 와 같은 것들을 이용해서 변화의 전파 즉 확장성을 가질수 잇는 형태로 가져가는게 바람직합니다.

여기서 추가적으로 더 고려해야 하는 것은 소프트웨어 전체가 recompile없이 쉽게 확장, 추가 할수 있게 물리적인 단위 (dll 등..)로 나누는 것도 중요합니다.  제가 아는 뭐 회사는, 소프트웨어 설계는 잘했지만, 물리적으로 나누지 않아, 전체를 컴파일을 하는 상황도 보았기 때문입니다.

또한 이 원칙과 굉장히 깊은 연관서잉 있는 Post가 있습니다.  Microsoft 수석 프로그래머인 Einar Landre가 작성한 "아키텍트의 초점은 경계와 인터페이스에 있다"를 보시길 바랍니다.  이러한 경계를 잘 정하기 위해 DDD에서 언급한 Context Map을 통해 객체의 Role과 Interface를 정하는 방법을  제안합니다.

NOO 를 정리하면서..

현재 Nature of Order 서적을 전혀 읽지 않고, Rebecca의 강의를 시작으로 여러자료를 찾아보면서 정리했습니다. 아마도 NOO를 읽으신 분들이 더 정확한 관점을 말씀해 주실수 있을거 같네요.

일단 제가 Rebecca의 강의를 들은 한도 내에서, 그리고 제가 이와 비슷한 케이스를 경험한 측면 내에서 한번 정의해 보겠습니다. 물론 2년후에 얼굴이 화들짝할만큼. 부족한 생각으로 쓴 글이 될수도 있지만, 그렇다고 2년동안 묵혀 둘수도 없잖아요..

물론 안티가 양성될수 있겠지만요. :) Rebecca의 강의 (주) + NOO를 Software 빛댄 몇몇 논문들 + Xper 에서 NOO에 대해 돌아다니는 이야기들을 읽고 조율해 보았습니다 부디 이 글이 다른 분에게 설계에 대한 새로운 관점을 전달해 주고, 저 역시 저의 부족한 부분을 피드백을 받아 좀더 성장하는 계기가 되었으면 합니다.

1. 꾸준히 한다.

.프로그래밍언어도 언어(?)라서, 하루에 몰아서 하는 것보다 매일 꾸준히 하는 것이 중요하다.

 경력이 많은 프로그래머들도 몇달만 코딩을 안해도 감이 많이 떨어지는 것을 느낀다.

.특히 프로그래밍을 처음 배우는 사람이라면, 꼭 컴퓨터 앞에 앉지 않더라도 책을 항상 가까이해서

문법 및 표현에 익숙해지도록 하는 것이 중요하다. 자주보는 것이 중요하다.

2. 반복해서 한다.

.단지 태권도교본을 잘이해했다고 해서 멋진 발차기를 기대할수 없는 것처럼, 책의 내용을

 잘 이해했다고 해서 하루아침에 프로그래밍을 잘할수 있는 것은 아니다.

.이해한 내용을 바탕으로 수많은 반복연습을 통해서만 지식을 진정한 자신의 것으로 만들 수 있다.

 (같은 예제를 공부하더라도 이리저리 조금씩 변경해서 공부하는 것이 좋다.)

.처음 2~3번은 자세히 보고, 그 다음 부터는 하루에 10분간 10페이지를 훑어보는 식으로 반복하자.

 몇달안에 책에 있는 모든 목차와 예제의 위치와 주요내용을 모두 파악할수 있을 것이다.

 (적어도 언어책 한권, 데이터베이스책한권 정도는 이렇게 할 필요가 있다.)

3. 좋은코드를 많이 보고 따라한다.

 .이미 수많은 선배들이 여러문제들에 대한 코딩을 다 작성해 놓았다. 새로운 방법으로 문제를

  풀겠다고 도전하는 것은 별 의미가 없다. "이럴때는 이렇게 하는 구나..."라는 것을 배우고

  유사한 상황에서 활용하면 되는 것이다. 여러분들이 해야할일은 이러한 경험들을 많이 쌓아

  나가는 일이지, 기존과는 다른 새로운 코딩방식을 만들어 내는 것이 아니다.

 .좋은 코드는 보기에도 좋다. 잘정리되어 있고, 별로 특별한 것이 없다. 프로그래밍의 각요소들을

  잘이해하고, 각 요소들을 적재적소에 바르게 사용하면 되는 것이다. 

  단지 소스의 라인수를 줄인다고해서 좋은 코딩이 아닌것이다. 로직이 소스코드에 잘드러날수있게

  쉽고 평범하게 작성하는 것이 좋은 코드인 것이다. 이창호의 바둑이 평범하듯이...

4. 기본에 충실한다.

 .빨리 프로그래밍을 배워서 뭔가 해보고 싶은 여러분들의 마음을 이해하지 못하는 것은 아니다.

  그러나, 프로그래밍 하루이틀 할 것도 아니고... 처음에 기본을 잘배워놓지 않으면, 그 이후에는

  기회가 잘 없다. 실무에서는 매일 개발하기 바쁘고, 새로운 기술 배우기 바쁘고...

 .배울것이 많다고 생각할지 모르나, 실제로 원리는 모두 같다고 해도 과언이 아니다.

  하나를 깊이있게 파고들면 나머지는 다 여러분 손에 있을 것이다.

5. 코드를 작성하기전에 순서도를 그린다.

 ."프로그래밍 = 코딩"이 아니라 "프로그래밍 = 로직설계 + 코딩"이다. 필자가 생각하는 로직설계

   와 코딩간의 비율은 8:2정도이다.

 .포토샵만 잘한다고 디자이너가 아니라는것은 여러분들도 잘알고 있을 것이다. 새로운 기술이나

  프로그램을 공부하는 것도 중요하지만,  어떤 과제가 주어졌을때 이를 잘 분석하고 설계하는

  능력을 장기적으로 키워나가도록 노력해야할 것이다.(다양한 주제에 대해서 문제를 풀어보고

  다양한 종류의 책을 읽자.)

 .문제를 구성하고 있는 주인공들을 찾아서 나열해보라. 그리고 이들간의 관계는 무엇이고, 규칙은

  무엇인지 적어보라.(머릿속으로만 생각하지말고!!!)

6. 주석을 가능한한 많이 적는다.

 .주석은 매우 유용하고도 중요한 요소이다. 그럼에도 불구하고 많은 사람들이 이를 소홀히 한다.

  자신이 작성한 코드도 몇일만 지나면 이해가 안되는 경우가 많다. 적어도 이해하는데 시간이

  걸린다. 주석은 이러한 시간들을 절약해줄것이며, 보다 에러가 적은 코드를 작성하는데 도움을

  줄 것이다. 특히 여러사람이 공동작업을 하는 경우에는 더욱 더 중요하다. 서로를 위해서...

 .작업과 관련된 가능한한 많은 정보를 주석에 담도록 하자.

7. 작업일지를 작성한다.

 .과학자들이 매일 연구한 내용을 일지로 적듯이 여러분들도 일지를 적어보자. 오늘은 이렇게

  저렇게 해봤는데 잘안되었다... xxx.java의 코드를 이렇게 바꾸었다. 몇시몇분에 xx로 백업받아

  놓았다... 라는 식으로 가능한한 자세히 적도록 한다. 이렇게 함으로써 여러분들의 경험을 기록

  으로 쉽게 보관할수 있으며, 문제해결에 많은 도움이 된다.

8. 자신의 소스를 가꾼다.

 .보통 코딩을 마치고 나면, 모든 것을 덮어두곤 한다. 원하는 결과를 얻었다고 거기서 그치지말고

  이제 로직과 코드를 보다 효율적으로 개선할 방법이 없는지 고민해보자. 글을 써놓고 좋은 글로

  만들기 위해 읽고 또 읽고 다듬듯이 코드를 다듬어보자. 여러분들의 코드를 구사하는 능력이 보다

  향상되어가는 것을 느낄 수 있을 것이다.

 .여러분들을 위한 제안은 작은 프로그램을 만들어서 오랜기간동안 점차 발전시켜 나가는 것이다.

  새로운 기능들을 하나씩 추가해가고, 기능을 발전시켜나가보자. 이과정을 통해서 여러분들의 실력

  은 몰라보게 향상될 것이다.

9. 생각하라.

 .항상 머릿속에 한 가지 문제를 준비하라. 지하철을 기다리거나, 화장실에서 볼일 볼때 문제를 풀어

  보자. 유레카를 외치고 뛰어나올지도...^^;

10. 좋은 책을 선택한다.

 .공부를 시작할때 제일 먼저 하는 일은 아마도 책을 고르는 일일 것이다. 보통 책하나에 수십시간을

  학습하게 되는데, 책을 잘못선택한 경우 수십시간과 노력을 허비하는 셈이다.

  바른 책을 고르는 일은 쉬운일이 아니지만, 최소한 몇시간을 투자해서 최선의 선택을 하도록 노력

  해야 수십시간을 허비하는 일이 없을 것이다.

 .책을 고르는 법은 여러가지가 있겠으나, 가장 중요한 것은 본인이다. 서점에서 같은 종류의 몇가지

  책을 놓고 서로 비교해보면, 시간을 들인 만큼 보다 나은 선택을 할 가능성이 높아진다.

 .많은 컴퓨터 서적이 독자들의 선택을 어렵게 하고, 컴퓨터 업계 특성상 좋은책을 만들기 보다

  빨리찍어서 파는 것이 더 중요해진 요즘. 독자들의 바른 선택이 보다 나은 책이 출판되는 것을

  가능하게 한다는 것을 알았으면 한다.