Home

소프트웨어 설계란 무엇인가?

What Is Software Design?" 우리가 소프트웨어 설계란 무엇인가에 대한 그 근원적인 힌트를 찾을 수 있는 좋은 아티클이 있어 번역해 봅니다.

이 글은 1992년 C++저널에 실린 Jack W. Reeves가 작성한 글인데(오래되었지만), 코딩, 테스트, 디버깅도 설계의 한 부분이며, 설계물을 엄격하게 적용해도 제품에 탈없이 적용할 수 없는게 소프트웨어 분야다보니, 그것도 설계, 빌드, 테스트 후 설계하는 과정을 거쳐서 완성품을 만들어야 하니 공학보다는 수공예에 가깝다고 합니다. 그리고 공학의 최종 산출물이 문서이고 이 문서는 코드도 포함되어 있으며, 소프트웨어 개발은 협업으로 진행되다보니 코드의 쓰기와 읽기의 중요성은 아무리 강조해서 지나치지 않는 법이죠. 그리고 소프트웨어 산업은 복잡성이 높은 분야이므로 쉬운 코드(산출물)는 협업의 커뮤니케이션 비용을 줄여주는 효과도 있겠습니다.

다음부터는 기사 전문을 번역한 내용입니다.

특히 C++ 분야의 객체 지향 기술은 소프트웨어 업계를 단번에 사로 잡았다. 그리고 이 새로운 기술의 적용 방법을 설명한 수 많은 기사와 책들이 나타났다. 이는 객체 지향 기술이 단순한 마케팅적으로 과대 광고였는지에 대한 의문은 통증을 최소화하고 이득을 얻는 방법에 대한 의문을 대체해 왔다. 객체 지향 기술이 아직 세상에 나온 지 얼마 되지 않았다는 것을 생각해볼 때 이런 폭발적인 인기는 극히 이례적이라고 말할 수 있다. 왜 객체 지향 기술이 갑자기 인기를 끌게 된 것일까요? 다양한 설명들이 난무했다. 사실, 이유는 단 하나뿐이 아니었을 것이다. 아마도 여러 요인이 합쳐지고 임계점에 도달해 인기를 얻게 된 것이다. 그럼에도 불구하고 최근 소프트웨어 혁명의 중심에는 C++ 그 자체가 있다고 생각된다. 그리고 그 이유도 단 하나가 아니겠지만, 나는 조금 다른 관점에서 답변을 제안하고 싶다: C++의 인기는 소프트웨어 설계와 프로그램을 동시에 쉽게 할 수 있기 때문이다.

이 의견이 이상하게 느껴졌다면 그것은 다분히 내 의도이기도 하지만, 이 아티클에서 제가 말하려고 하는 것은 프로그래밍과 소프트웨어 설계의 관계를 살펴보겠다는 것이다. 거의 10년동안, 소프트웨어 설계를 이루는 일련의 작업과 소프트웨어 설계의 참모습과의 미묘한 차이를 소프트웨어 업계 전체가 놓쳐왔다고 생각한다. 우리가 알 수만 있다면, C++ 인기도의 증가는 우리가 더 뛰어난 소프트웨어 엔지니어가 되기 위해 할 수 있는 중요한 교훈이 숨어 있다고 생각한다. 그 교훈은 프로그래밍은 소프트웨어를 제조하는 것이 아니라, 소프트웨어를 설계하는 것이다.

몇년 전, 내가 참석한 세미나에서 소프트웨어 개발은​​ 공학 분야에 속하는지 여부에 대한 논의가 이루어졌다. 그 당시 토론의 결론은 생각나지 않았지만, 소프트웨어 산업은 매우 유용한 몇가지 유사점을 간과하면서 하드웨어 공학에서의 잘못된 유사점을 창조했다고 내 스스로가 진단했다. 본질적으로, 우리는 소프트웨어 설계라는 것이 진정 무엇인지 모르고 있다는 점에서 소프트웨어 엔지니어가 아니라는 결론에 도달하게 된다. 그리고 그 생각은 오늘 더욱 확고해졌다.

공학 활동의 최종 목표는 몇몇 좋류의 문서이다. 설계 작업이 완료되면 설계 문서가 제조팀에 전달된다. 제조팀은 디자인팀과는 완전히 다른 스킬을 가진 전혀 다른 그룹이다. 그리고 설계 문서가 실제로 완벽하게 설계되어 있는 경우, 제조팀은 제품의 생산을 시작할 수 있다. 즉, 미래에 설계자의 개입없이 해당 제품을 대량 생산할 수 있게 되는 것이다. 나는 자신이 이해하고 있는 소프트웨어 개발 라이프 사이클을 리뷰해 보고, 공학적인 설계 기준을 정말 만족하는 소프트웨어 문서라는 것은 소스 코드 목록뿐이라는 결론에 도달했다.

이 가정에 대해서는 찬반 양론 다양한 의견이 존재할 수 있다. 따라서 본 아티클에서는 진정한 소프트웨어 설계가 최종 소스 코드라고 가정 할 경우, 이 가정에서 도출되는 추론의 일부를 조사하고자 한다. 이 견해(가정의 정당성)가 옳다는 것을 입증할 수 없을지도 모르지만, 이로 인해 C++ 인기에 대한 이유 등 포함해 소프트웨어 업계에서 볼 수 있는 몇가지 사실들을 설명할 기회를 가질수 있기를 바란다.

소스 코드가 소프트웨어 설계의 중요한 결과물로 귀결된다. 이 귀결은 너무 중요하고 자명하지만, 대부분의 소프트웨어 조직에서 맹점이 되고 있다. 그것은 소프트웨어를 제조(빌드)하는 것은 저렴하다는 사실이다. 너무 싸기 때문에 가치를 인정받지 못할수도 있고 저렴해서 무료라고 인식하기도 한다. 소스 코드가 소프트웨어 설계라고 생각하면, 소프트웨어의 실제 제조는 컴파일러와 링커에서 이루어지게 된다. 우리도 소프트웨어 시스템 전체 컴파일및 링크 프로세스를 종종 "빌드하기("doing a build")」라고 ​​부르고 있다. 또한, 소프트웨어 구축용 장비에 대한 자본 투자도 적게 든다. 실제로 필요한 것은 컴퓨터, 편집기, 컴파일러, 링커뿐이다. 한번, 일단 빌​​드 환경을 이용 가능하게 되면 소프트웨어의 제조에는 약간의 시간만 필요하게 된다. 50,000행의 C++ 프로그램을 컴파일하려면 상당한 시간이 필요할지도 모르지만, 50,000라인의 C++ 코드만큼 복잡한 설계의 하드웨어 시스템을 제조하는 것을 생각하면 덜 오래 걸릴 것이다.

소스 코드가 소프트웨어 설계하다고 생각하면 소프트웨어 설계는 적어도 기계적인 의미에서 비교적 쉽게 만들 수 있다는 추론도 가능하다. 50라인에서 100라인으로 코드로 구성된 일반적인 소프트웨어 모듈을 작성(즉 설계)하려면 대부분의 경우 며칠 걸리지 않는다(완벽하게 디버깅을 완료하는 것은 또 다른 이야기다. 그것은 나중에 살펴보겠다). 이 정도의 복잡성을 가지고 설계를 소프트웨어 수준의 기간내에서 해낼 수 있는 공학 분야가 있는지 물어보고 싶지만, 먼저해야 할 일은 복잡성을 어떻게 측정하는지를 알아내야 할 것이다. 그러나, 소프트웨어 설계는 오히려 급속도로 복잡성이 증가한다는 점이다.

소프트웨어 설계는 비교적 용이하다는 점, 그리고 제조(빌드)는 본질적으로 무료라는 점을 생각하면, 소프트웨어 설계가 엄청나게 거대하고 복잡한 경향이 있다는 것은 당연하다. 이것은 뻔한것처럼 보일지도 모르지만, 종종 문제의 규모가 무시되고 있다. 교육 현장의 프로젝트에서는 기껏해야 수천 줄의 코드 밖에 되지 않지만, 소프트웨어 제품에서 설계자로부터 인도된 시점에서 10,000라인의 설계 산출물이 되기도 한다. 간단한 소프트웨어에서 충분한 이익을 얻는다는 것은 이제 과거의 이야기이다. 이제 일반적인 상용 소프트웨어 제품은 수십만라인의 설계물로 구성되어 있다. 그리고 백만라인대에까지 가는 소프트웨어 설계물도 많다. 게다가, 소프트웨어 설계는 거의 항상 진화한다. 현재 설계에서는 수천 줄의 코드밖에 안될지 모르지만, 그 제품의 일생을 통해 볼 때 그 몇배 더 쓰여질지 모른다.

소프트웨어 설계만큼이나 복잡한 하드웨어 설계가 존재하는 것은 틀림없지만, 여기에서는 현대적인 하드웨어에 대한 두가지 사실에 주목해야 한다. 첫번째는 사실은 복잡한 하드웨어 공학을 적용한 경우 소프트웨어 비평가들이 우리에게 믿게 끔 해 온 만큼, 항상 버그가 없는 상태는 아니라는 것이다. 유명한 마이크로 프로세서가 논리 오류를 가진 상태로 출하된다. 교량과 댐은 붕괴되고, 항공기 추락되고, 수천대의 승용차 및 다른 소비자 제품이 리콜되는 것이다. 이들은 모두 최근 기억속의 것들이며, 모두 설계 오류의 결과물이다. 두번째는 복잡한 하드웨어 설계는 복잡하고 고가의 제조 공정이 필요하다. 결과적으로, 이러한 시스템을 만들어내는 능력이 필요하기 때문에 진정으로 복잡한 하드웨어 디자인을 만들어 낼 수 있는 기업의 수 자체가 한정되어 있다. 그러나, 소프트웨어는 이러한 제약이 적용되지 않는다. 수백개의 소프트웨어 회사가 존재하고 수천개의 매우 복잡한 소프트웨어 시스템이 존재하고 있다. 그리고 그 복잡도와 수는 나날이 증가하고 있다. 즉, 하드웨어 개발자가 배워서 흉내를 내도 소프트웨어 산업의 문제는 그렇게 쉽게 해결할 수 있는 것이 아니다. 하드웨어 설계자는 더 복잡한 설계를 할 수 있도록 도와주는 CAD/CAM 시스템이 있지만, 하드웨어 공학도 소프트웨어 개발처럼 점점 비슷해진다.

소프트웨어를 설계하는 것은 복잡성을 관리하는 작업이다. 이러한 복잡성은 소프트웨어 설계 자체와 기업의 소프트웨어 조직, 그리고 산업 전체에 내포하고 있다. 또한 소프트웨어 설계는 시스템 설계와 매우 비슷하다. 즉, 많은 기술들이 관련되어 있고 종종 하위 분야를 포함할 수도 있다. 따라서 소프트웨어 명세는 유동적이며, 빠르게 그것도 자주 변화하는 경향이 있다. 또, 설계 과정중에 변화하는 경우도 있다. 소프트웨어 개발 팀도 설계 과정 중간에 변경되는 경우가 종종 있기 때문에 유동적이다. 소프트웨어는 하드웨어보다는 여러면에서 복잡한 사회적, 조직적인 유기 시스템과 닮아있다. 이런 모두가 소프트웨어 설계를 어렵게 하고 오류를 쉽게 만들게 한다. 어디에도 그 근원적인 해결책은 없다. 그러나 소프트웨어 혁명이 일어나고 30년 가까이 지난 지금도 소프트웨어 개발은​​ 다른 공학 분야와 비교하면 규율이 없는(쳬계화되지 않은) 예술분야로 생각할 수 있다.

진정한 엔지니어가 설계를 완료하면 그것이 얼마나 복잡하던 간에 기대하는대로 작동한다는 것은 이론의 여지가 없다. 그리고 제조 기술을 이용하여 구축한 것도 잘 동작한다. 이런 일이 일어나기 위해서 하드웨어 엔지니어는 그에 상응하는 시간을 설계 검증과 개선하는데 투입한다. 예를 들어 교량 설계한다고 생각하자. 이러한 설계를 실제로 건설하기 전에 엔지니어는 구조 분석을 실시한다. 컴퓨터 모델을 구축하여 시뮬레이션을 한다. 또한 축소 모형을 만들고 바람의 움직임 등 다양한 방법으로 시험을 진행한다. 짧게 말하면, 설계자는 건설에 앞서 그 디자인이 뛰어난지 여부를 결정하는 데 필요한 모든 생각을 한다. 신형 항공기의 설계는 더욱 힘들다. 이 경우 설계시 예측을 검증하기 위해 실물 크기의 시제품​​을 제조하고 시험 비행을 실시해야 한다.

많은 사람들의 눈에는 소프트웨어 설계가 하드웨어 설계만큼 엄격하게 공학적으로 진행되지 않아도 된다고 생각한다. 그러나 소스 코드는 설계라고 생각하면 실제로는 소프트웨어 설계자도 자신의 설계에 상응하는 시간을 검증과 개선에 투자를 해야한다는 것을 알 수 있다. 단, 소프트웨어 설계자는 그것을 공학이라고 부르지 않고, 테스팅과 디버깅이라고 부르고 있을뿐이다. 그러나 많은 사람들은 테스팅과 디버깅을 진짜 공학이라고는 생각하지 않는다. 소프트웨어 업계에선 더 그렇게 부르지 않는다. 그 이유는 공학의 본질적 차이보다는 코드가 설계의 과정이라는 점을 소프트웨어 업계가 거부하고 있기 때문이다. 모형(목업), 프로토타입, 모의 실험은 다른 공학 분야에서도 실제로 받아 들여지고 있는 것들이다. 소프트웨어 설계자는 소프트웨어 빌드 사이클의 단순한 경제적 논리때문에 자신의 디자인을 검증하는 공식적인 방법론을 채택하거나 운영하지 않는다.

두 번째 계시: 단지 설계물을 작성하고 테스트할 뿐이라면 무엇보다 저렴하고 쉽게 할 수 있다. 여러번 빌드할 것인가는 고민할 필요도 없다. 이러한 것은 시간이라는 관점에서는 비용이 없으며, 사용한 자원은 빌드를 파기했을 때 완벽하게 회수할 수 있다. 테스트는 현재 디자인을 올바르게 하는 것뿐만 아니라, 설계 개선 프로세스의 일부이기도 하다라는 점에 주목하자. 복잡한 하드웨어 시스템 엔지니어는 종종 모델을 구축한다(또는 적어도 컴퓨터 그래픽을 이용하여 자신의 설계를 시각적으로 표현한다). 이를 통해 설계자는 설계 자체를 검토하는 것만으로는 알아낼 수 없었던 디자인의 "느낌"을 얻을 수 있게 된다. 그러나 소프트웨어 설계에서는 이러한 모델 구축은 불가능하며, 불필요하다. 우리는 단순히 제품 자체를 빌드하면 된다. 공식 소프트웨어 검사 툴이 컴파일러와 같이 자동화되었다해도 우리는 빌드/테스트 주기를 여전히 진행한다. 따라서 공식 검사는 소프트웨어 산업에 실질적인 이득을 주지 못한다.

이것이 오늘날의 소프트웨어 개발 프로세스에서 일어나는 현상이다. 또한 복잡한 소프트웨어 설계물들은 점점 증가하는 인력과 조직에 의해 만들어지고 있다. 그리고, 이러한 설계는 몇가지 프로그래밍 언어로 코딩될 것이고 빌드/테스트 주기를 거치면서 검증되고 개선되고 있다. 이러한 프로세스는 오류를 만들기 쉬우며 특별히 엄격하지도 않다. 많은 소프트웨어 개발자는 이것이 문제를 크게 악화시키는 방법이라고 믿고 싶지 않을 것이다.

현재 대다수의 소프트웨어 개발 프로세스는 소프트웨어 설계의 다양한 단계로 세분화하려고 한다. 코드를 작성하기 전에 최상위 설계를 완료하고 동결해 두어야 한다. 그리고 테스팅과 디버깅은 구축 과정의 실수를 제거하는 데에만 필요하다. 그 사이에 있는 것이 프로그래머, 즉 소프트웨어 산업에서 건설 노동자다. 그리고 많은 사람들은 프로그래머가 "해킹"이나 "재설계"를 멈추면 소프트웨어 개발은​​ 정말 공학 분야로 성숙한다고 믿고 있다. 프로세스가 공학이나 경제 현실을 무시하는 한, 공학 분야로의 성숙은 있을 수 없다.

예를 들어, 제조 과정에서 재작업율이 100%를 넘어 버리는 것을 용인하는 현대 산업계는 존재하지 않는다. 처음부터 제대로 구축할 수 없는 건설 노동자는 대부분의 경우 곧바로 일을 잃어 버릴것이다. 소프트웨어의 경우, 아무리 짧은 코드에도 테스팅과 디버깅 동안 수정되거나 완전히 재작성될 수 있다. 우리는 설계와 같은 창조적인 과정에서 일어나는 개선 작업은 수용하면서 제조 공정에서는 받아들이려 하지 않는다. 엔지니어가 처음부터 완벽한 설계를 만들수는 없다. 엔지니어가 그렇게 했을지라도, 그것이 완벽하다는 것을 증명하기 위해서 개선 프로세스를 지나야 한다.

일본의 경영 기법을 배웠다면, 과정에서 발생한 실수에 대해 작업자를 비난하는 것은 생산성을 저하시킨다고 배워왔다. 잘못된 프로세스 모델을 따르도록 소프트웨어 개발을 강요하는 것이 아니라, 프로세스를 수정하고 더 좋은 소프트웨어를 만드는데 도움이 되도록 해야한다. 이것이 "소프트웨어 공학"의 리트머스 테스트이다. 엔지니어링(공학)은 프로세스의 실행 방법에 대해 논의하는 것이지, 최종 설계 문서를 작성하기 위해 CAD 시스템이 필요한지 여부를 논하는 것은 아니다.

소프트웨어 개발의 큰 문제는 모든 것이 설계 과정의 일부라는 것이다. 코딩도 설계이고, 테스팅과 디버깅도 설계의 일부이며, 우리가 일반적으로 소프트웨어 설계라고 부르고 있는 것도 역시 설계의 일부이다. 따라서 소프트웨어 빌드는 저렴하지만, 설계는 놀라울 정도로 비싼 것이다. 소프트웨어는 너무 복잡하기 때문에 설계시 고려해야 할 부분과 설계 결과를 평가하는 부분에는 많이 다르다. 문제는 다양한 측면이 서로 관계되어 있다는 것이다(하드웨어 공학의 경우처럼). 상위의 설계자가 모듈의 알고리즘 설계에 관한 세부 사항을 몰라도 된다면, 아무 문제 없다. 마찬가지로, 프로그래머가 모듈의 내부 알고리즘을 설계할 때 상위 수준의 설계를 걱정하지 않아도 된다면, 이 또한 아무 문제 없다. 불행히도, 여러 디자인(설계) 계층이 서로 서로 간섭한다는 것이다. 주어진 모듈에 대한 알고리즘 선택은 상위 수준의 설계시 고려한 관점만큼이나 중요한 것이며, 소프트웨어 시스템의 전반적인 성공을 좌우하는데 중요하다. 소프트웨어 설계의 서로 다른 관점들 사이에는 중요도에 대한 서열은 존재하지 않는다. 최하위 모듈 레벨에서 설계를 실수가 최상위 수준에서 실수만큼이나 치명적인 것이 될 수 있다. 그래서 소프트웨어 설계는 모든 면에서 완벽하고 정확해야 하며 그렇게 되어 있지 않은 경우, 그 설계에 따라 소프트웨어 빌드 모두가 잘못된 것이 될 수 있다.

소프트웨어 설계 복잡도를 해결하기 위해 계층별로 설계할 수 있다. 프로그래머가 하나의 모듈 상세 설계를 할 때 수백 개의 모듈, 수천의 다른 세부 사항들을 동시에 고려할 순 없다. 예를 들어, 소프트웨어 설계자는 깔끔한 형태로 데이터 구조와 알고리즘을 설계하진 못한다는 것이 소프트웨어 설계의 중요한 관점이다. 그리고 프로그래머가 코드의 설계를 할 때 이상적인 것은 여러가지 다른 측면들을 신경 쓰지 않아야 한다.

그러나 이런 것은 실제로는 잘 되지 않는다. 그리고 그런 이유에는 합당한 핑계거리도 있다. 소프트웨어 설계는 코딩이 완료되고 테스트 될 때까지는 완벽하지 않다. 테스트는 설계 검증과 개선 프로세스의 기초가 될 것이다. 상위 레벨의 구조 설계는 완전한 소프트웨어 설계라고는 할 수 없다. 이것은 상세 설계를 위한 단순한 구조의 프레임 워크 밖에 안된다. 높은 수준의 설계를 엄격한 형태로 검증할 수 있을만큼 우리의 능력은 우수하지 않다. 상세 설계는 적어도 상세 설계 이외의 다른 요인들만큼 높은 수준의 설계에 영향을 미친다(영향을 미칠수 있게 해야 한다). 하나의 설계를 모든 관점에서 개선하는 것은 설계 주기를 통해 일어나야 한다. 설계의 일부 측면이 개선 프로세스에서 동결되는 경우라면, 최종 설계가 빈약하거나, 심지어 작동하지 않더라도 그것은 놀랄일이 아니다.

상위 수준의 소프트웨어 설계를 좀더 엄격한 공학 프로세스상에 있다라면 아무 문제 없다. 그러나, 실제 소프트웨어 시스템은 이렇게 엄격하지는 않다. 소프트웨어는 아주 복잡하며, 너무 많은 것들과 상호 연관이 되어 있다. 하드웨어에 따라 설계자의 생각대로 작동하지 않을지도 모른다. 또한 라이브러리 루틴에는 문서화할 수 없는 제약들을 가지고 있을 수 있다. 이런 종류의 문제는 모든 소프트웨어 프로젝트가 조만간 마주하게 될 것이다. 또한, 이런 문제는 초기에 발견될 방법이 없기 때문에(제대로 된 테스트를 실시했을 경우) 테스트중에 발견된다. 이러한 문제가 발견된 경우에는 설계의 변경을 강요하게 된다. 운이 좋으면 설계 변경은 지엽적인 것이 되지만, 많은 경우에 변경은 소프트웨어 설계 전체의 중요한 부분을 차지한다(머피의 법칙). 그리고 어떠한 이유로 영향을 받는 설계 부분을 변경할 수 없는 경우에는 다른 부분에서 이를 수용하게 되게 되고, 결과적으로 그 부분이 취약한 것이 된다. 관리자는 이를 '해킹'으로 인식한다. 그러나 이것은 소프트웨어 개발의 현 실정이다.

최근해 했던 프로젝트에서 내부 모듈 A와 내부 모듈 B사이에 타이밍 의존 문제가 발견되었다. 불행히도, 모듈 A의 내부는 추상화되어 은폐되어 있고 올바른 순서로 모듈 B의 호출할 수 있게 지원하는 것은 어떤것도 허용되지 않았다. 자연스레 문제가 발견된 시점에서는 A의 추상화를 변경하는 것은 너무 늦어 버렸다. 예상대로 A의 내부 설계에 맞추는 형태로 복잡한 일련의 "수정"과정이 일어났다. 초기 버전이 설치되기 전에 설계가 손상되었다는 것을 모두가 느낄수 있었다. 다음에 일어나는 새로운 수정거리들은 과거의 수정했던 것들과 상충하는 경우가 많아졌다. 이런 것들은 소프트웨어 개발 프로젝트의 일반적인 현상이다. 결국, 나는 동료와 함께 설계 변경에 대해 논쟁을 했지만, 관리의 동의를 얻기 위해 자발적으로 개발 잔업을 해야했다.

일반적인 규모의 소프트웨어 프로젝트라면 반드시 이러한 문제가 발생했을 것이다. 이러한 일을 막기 위해 다양한 시도를 했음에도 불구하고 중요한 세부 사항들은 간과하기 마련이다. 이것이 수공예와 공학의 차이다. 경험함으로써 올바른 방향으로 나아갈 수 있는 것이 수공예라는 것이다. 경험이 우리를 미지의 영역에 데려다 주게 되고 그런 다음, 시작하고, 개선된 관리 프로세스를 통해 더 나아지게 되는데 이것이 공학이라는 것이다.

소프트웨어 설계 문서는 코딩 전보다 코딩 후에 작성하는 것이 훨씬 더 정확하다는 것을 프로그래머라면 누구라도 알고 있다. 이 이유는 명백하다. 코드에 반영된 최후의 설계만이 빌드/테스트 주기를 통해 개선되는 유일한 길이다. 이 사이클을 통해 초기 설계가 변경되지 않을 가능성은 프로젝트의 모듈의 개수나 프로그래머의 수와 역 상관 관계가 있다. 즉, 이 수치는 급속히 제로에 가까워져 간다.

소프트웨어 공학은 모든 수준에서 뛰어난 설계가 필요하다. 상위 레벨에서는 특히 뛰어난 설계가 필요합니다. 초기 설계가 우수할수록 상세 설계도 뛰어나게 될 것이다. 설계자는 도움이 될만한 모든 것을 받아들여야 한다. 구조화 차트, Booch 다이어그램, 상태 전이 테이블, PDL(Program Design Language) 등 - 그것이 도움이 된다면 무엇이든 사용해아 한다. 그러나 이러한 도구와 기법이 소프트웨어 설계는 아니라는 것을 항상 염두에 두어야 한다. 결국, 우리는 진정한 소프트웨어 설계물을 만들어내야 하고, 그것은 여러 종류의 프로그래밍 언어로도 실현될 수도 있다. 따라서 우리가 만들어낸 설계물을 코드화하는 것을 주저할 필요는 없다. 우리는 필요에 따라 설계물을 기꺼이 개선할수 있어야 한다.

현재는 상위 수준의 설계와 상세 설계 모두에 적합한 설계 기법은 존재하지 않는다. 설계는 결국 어떤 프로그래밍 언어로 코딩되는 것이다. 이는 상세 설계를 시작하기 전에 상위 설계 기법에 의한 결과를 대상 프로그래밍 언어로 변환해야 한다는 것을 의미한다. 이 변환 과정에서 시간이 걸리고 오류가 만들어지기도 한다. 설계 기법이 선택한 프로그래밍 언어와 잘 맞지않아 프로그래머는 요구 수준에까지 거슬러 올라가며, 상위 레벨의 설계를 다시하고 그에 따라 코딩도 다시하는 경우가 있다. 이런 것도 소프트웨어 개발 현실에 한 부분이다.

원래 설계자가 처음부터 코드를 작성하는 것이 누군가 다른 사람에게 맡겨 버리는 것보다 결과는 더 좋다. 그래서 우리에게 필요한 것은 모든 설계 수준에 적절한 통일된 표기법이다. 다른말로 표현하면, 우리는 높은 수준의 디자인 컨셉을 알아차릴 수 있는 프로그래밍 언어를 필요로하고 있다. 여기에 C++의 여지가 있는 것이다. C++은 현실 세계에 존재하는 프로젝트에 적합한 프로그래밍 언어이며, 보다 표현력이 풍부한 소프트웨어 설계 언어이기도 하다. C++를 사용하면 설계 구성 요소에 대한 높은 수준의 정보를 직접 표현할 수 있다. 이를 통해 설계 작성을 용이하게 하고 후에 개선작업도 쉽게 할 수 있다. C++ 제공하는 강력한 형식 검사 도구에 의해, 설계 오류 탐지 프로세스도 지원된다. 따라서 디자인은 더 강력하게 되며, 본질적으로 더 나은 공학적 설계를 가능하게 한다.

소프트웨어 설계는 결국 어떤 프로그래밍 언어로 표현되어야 하며, 빌드/테스트 주기를 통해 검증되고 개선되어야 한다. 그렇지않게 되면 잘못될 것이다. 과거에 인기를 얻었던 소프트웨어 개발 도구와 기술들을 생각해 보자. 구조적 프로그래밍은 어떤 시기엔 그것이 돌파구였다. 그리고 구조적 프로그래밍은 Pascal에 의해 인기를 얻었고 이 Pascal 자신도 구조적 프로그래밍의 인기를 등에 업었기도 했다. 객체 지향 설계는 새로운 조류이며, C++이 그 중심에 있다. 그럼 인기가 없었던 것들을 생각해 보자. CASE 도구? 확실히 인기는 얻었지만, 보편적이지는 못했다. 구조화 차트? 이것도 같았다. 마찬가지로 Warner-Orr 다이어그램, Booch 다이어그램, 객체 다이어그램 등이 나을지도 모른다. 각각 장점이 있지만, 각각은 진짜 소프트웨어 설계가 아니라는 공통된 단점을 가지고 있다. 사실 광범위하게 보급되었다고 할 수 있는 소프트웨어 설계 기법은 PDL이고, 그것이 우리의 눈에 어떻게 비쳐지고 있는지 생각해 볼 필요가 있다.

이것은 프로그래밍 기술, 그리고 특히 현실 세계에서 프로그래밍 언어의 개선이 소프트웨어 업계에서 가장 중요하다는 점을 소프트웨어 업계 전체가 직관적으로 알고 있다는 것을 나타낸다. 또한 프로그래머가 설계에 관심을 가지고 있다는 것을 의미하고 있다. 더 표현력이 풍부한 프로그래밍 언어가 이용 가능하게되면 소프트웨어 개발자는 그것을 사용할 것이다.

또한 소프트웨어 개발 프로세스가 어떻게 변해왔는지 생각해보자. 한때는 워터폴 프로세스를 사용했었다. 그리고 지금은 나선형 개발이나 래피드 프로토타입에 대해 이야기하고 있다. 이러한 기법은 종종 "위험 감소"나 "제품 출시 가속화"등의 관점에서 정당화되었지만, 실제 결과는 라이프 사이클 동안의 코딩 작업을 좀 더 일찍 시작할 수 있었을 뿐이다. 그러나 이것은 옳은 방식이다. 빌드/테스트 주기를 통해 설계를 조기에 검증하고 개선할 수 있도록 하는 것이다. 또한 이것은 상위 수준의 설계를 담당하는 소프트웨어 설계자가 상세 설계 시점까지 있도록 해준다.

위에 기술한것 처럼, 공학은 최종 제품이 어떤 모습이 될 것인가가 아니라 당신이 어떻게 프로세스를 실천하는가에 해당하는 것이다. 소프트웨어 업계에 있는 우리는 엔지니어와 가까이에 있지만, 일부분은 인식을 바꾸어야 한다. 프로그래밍 및 빌드/테스트 주기가 소프트웨어 개발 공학 프로세스의 핵심이다. 우리는 이러한 작업을 제대로 실천해 나갈 수 있도록 관리해야 한다. 빌드/테스트 주기의 경제성이나 소프트웨어 시스템이 실질적으로 어떤한 것도 표현할 수 있다는 사실을 생각하면 소프트웨어 설계를 검증할 수 있는 범용적인 방법을 찾는 것은 쉽지 않다. 우리는 프로세스를 개선할 수만 있을뿐, 이 상황을 벗어날 수는 없다.

마지막 요점: 공학 설계 프로젝트의 목표는 어떤 문서를 작성하는 것이다. 분명, 실제 설계 문서가 엄청 중요하지만, 제조해야 한다는 것은 그것만으로는 안된다. 결국, 누군가가 그 소프트웨어를 사용하게 될 것이고 결국 대부분의 경우 해당 시스템은 나중에 보강되고 수정될 것이다. 이것은 하드웨어 프로젝트와 마찬가지로 소프트웨어 프로젝트들에서도 보조 문서는 중요하다는 의미이다. 설계 프로세스와 직접 관련이 없는 사용자 설명서, 설치 설명서나 기타 문서들은 당분간 무시하더라도 보조 설계 문서에 대해 해결해야 할 두가지 중요한 요구가 여전히 존재하고 있다.

보조 문서의 용법중에 하나는 설계에 직접 통합될 수 없는 문제 영역에서 중요한 정보를 포착하는 것이다. 소프트웨어 설계는 문제 영역에서 소프트웨어의 개념에서 모델의 개념을 만드는 작업이 포함되어 있다. 이 과정에서 문제 영역에 대한 개념의 이해를 확립해야 한다. 보통의 경우, 소프트웨어 영역중에 직접 모델링할 필요가 없는 정보까지 이해하고 있어야 하지만, 그럼에도 불구하고 설계자는 본질적인 개념이 무엇인지, 그리고 어떻게 모델링하는 것이 최적인지를 확정할 수 있도록 도움을 준다. 즉, 나중에 모델을 변경해야 하는 경우에 대비하여 이러한 정보를 어딘가에 포착해 두어야 한다.

보조 문서의 또 하나의 중요한 용도는 설계 자체에서 직접 추출하기 어려운 설계상의 여러 측면을 문서화해 둔다는 것이다. 이것은 상위 레벨 및 하위 레벨 두 방면 모두 포함된다. 이런 관점들의 많은 부분을 도표로 표현하는 것이 최고다. 따라서 이런 것들은 소스 코드의 주석에 표현하기 어려운 것들이다. 그러나 여기에서는 프로그래밍 언어 대신 그래픽 소프트웨어 설계 기법을 사용한다는 등의 논쟁은 하지 않는다. 이제 하드웨어 분야의 설계도에 글로 설명이 필요하다는 주장과 크게 다르지 않다. 그러나, 진정한 설계를 결정 짓는 것은 보조 문서가 아니라 소스 코드라는 것을 잊지 마라. 이상적으로는 소프트웨어 툴에 의해 설계에서 소스코드가, 보조 문서가 생성되게 될지도 모른다. 그러나 이것은 지나친 예측일수도 있다. 차선책으로는 프로그래머(또는 테크 라이터)가 소스 코드에서 특정 명세 정보를 추출하고 여러 다른 방법들로 문서화를 지원하는 도구가 있을수도 있다. 그러나 이러한 문서를 수동으로 최신 상태로 계속 유지하는 것은 매우 어렵다. 이것은 또한 표현력이 풍부한 프로그래밍 언어가 필요하다는 또 다른 논쟁이 될 수 있다. 또한 이러한 보조 문서를 최소한으로 억제하고 프로젝트 후반까지 가능한 한 그것을 비공식으로 유지하자는 논의도 있다. 다시 말하지만, 우리는 더 나은 도구를 사용할지도 모른다. 그렇지 않으면 우리는 언제까지나 연필, 종이, 화이트 보드를 계속 사용하게 될 것이다.

전체를 요약하면
  • 진정한 소프트웨어는 컴퓨터 내에서 실행되는 것이다. 이것은 어떤 자기 매체에 저장된 1과 0의 시퀀스이다. 즉, C++ (또는 다른 프로그래밍 언어)로 기술된 프로그램 목록에는 없다.
  • 프로그램 목록은 소프트웨어 설계를 표현한 문서이며, 소프트웨어 설계물은 컴파일러와 링커에 의해 실제로 제조(빌드) 된다.
  • 진정한 소프트웨어를 구축(빌드)하는 것은 놀라울 정도로 저렴하며, 컴퓨터의 고속화와 함께 더 저렴해지고 있다.
  • 진정한 소프트웨어를 설계하려면 놀라울 정도로 비용이 소요된다. 이것은 소프트웨어가 놀라울 정도로 복잡하고 사실상 소프트웨어 프로젝트의 모든 단계가 설계 프로세스의 일부가 되어 있기 때문이다.
  • 프로그래밍은 설계 활동이다. 우수한 소프트웨어 설계 프로세스는 이 점을 인식하고 코딩을 할 때는 주저하지 않는다.
  • 코딩은 우리가 믿고 있는것보다 더 의미있는 작업이다. 코드에 의해 설계물이 그려내는 과정은 종종 간과이나 추가 설계를 할 필요성에 대해 가르쳐준다. 이러한 일을 빨리 진행하면, 디자인은 더 나은 것이 될 것이다.
  • 소프트웨어 빌드는 거의 비용이 들지 않기 때문에 공식 공학적 검증 기법이 실제 소프트웨어 개발에 많이 사용되는 것은 아니다. 증명하려고 하는 것보다 단순히 설계를 빌드하고 테스트하는 것이 쉽고 저렴하다.
  • 테스팅과 디버깅은 설계 활동이다. 이것들은 다른 공학 분야의 설계 검증이나 개선 프로세스와 동일한 것들이다. 우수한 소프트웨어 설계 프로세스는 이 점을 인식하고 있기 때문에 이 단계들을 부실하게 하지는 않는다.
  • 그 밖에도 설계 활동이 존재하고 있다. 이들은 최상위 설계, 모듈 설계, 구조 설계, 아키텍처 설계 등의 이름으로 불리고 있다. 우수한 소프트웨어 설계 프로세스는 이 점을 인식하고 있기 때문에 의식적으로 이 단계들을 포함하고 있다.
  • 모든 설계 활동은 상호 작용을 한다. 우수한 소프트웨어 설계 프로세스는 이 점을 인식하고 있기 때문에 다양한 설계 단계에 변경의 필요한 경우 때때로 대담한 설계 변경을 허용하고 있다.
  • 많은 다양한 소프트웨어 설계 기법은 유익한 것들을 내포하고 있다. 설계 프로세스를 원할하게 도움을 주는 보조 문서나 도구도 있다. 그러나 이러한 것들이 소프트웨어 설계에는 없다.
  • 소프트웨어 개발은​​ 아직도 공학 분야라기보다는 수공예쪽에 가깝다. 이것은 주로 설계 검증 및 개선하는 중요한 프로세스에서 엄격성이 결여되어 있기 때문이다.
  • 궁극적으로 소프트웨어 개발 진정한 발전는 프로그래밍의 발전 즉, 프로그래밍 기술의 발전에 달려있다. C++이 이러한 발전속에 있다. 더 좋은 소프트웨어 설계를 직접 지원하는 주류 프로그래밍 언어이기 때문에 인기가 폭발적인 것이다.
  • C++ 올바른 방향으로의 한걸음 나아가고 있지만, 더욱 발전이 필요하다.
Tags : , , ,

조직의 생산성을 올리려면

사람이 많든, 적든 일을 진행하는데에는 수많은 난관들이 존재하고 그 난관들을 누군가는 조율하고 조화롭게 만들어야한다. 그렇다고 외적 프로세스를 강제하지 않고 자율성을 해치지 않는 범위내에서 협업하면서 조직의 생산성을 증대시키는 노력들에는 뭐가 있는지 고민하고 메모한 내용들을 정리해 본다.



사람이 많을수록 조직의 생산성은 하락한다. 링겔만 효과

독일의 심리학자 맥시밀리언 링겔만은 줄다리기 실험에서 아래와 같이 말한다.
"한번에 100의 힘을 내는 사람이 여럿이 잡아당긴다고 해서, 그 힘이 200이 되는게 아니라, 둘이서 할때는 180, 셋이서 할때는 250이 된다. 줄다리기에서 인원수가 많을수록 1인당 끌기의 힘은 감소하고 전체의 힘 합는 각 개인의 힘 합보다 작다"라는 실험 결과에서 보듯, "조직이 커질수록 조직을 구성하고 있는 개별 사람의 생산성은 저하한다"고 주장한다.
즉, 인원수가 많아 질수록 "자신은 편하게 하자. 이 일을 마치면 또 다른 일이 들어올 것이다."라는 생각이 의식적, 무의식적으로 일어나게 된다는 것이다. 이것이 링겔만 효과(Ringelmann Effect)며, 사회적 부실(Social Loafing) 연구의 시발점이 되었다고 한다.
  • 일이 들어오면 다른 누군가가 스스로 솔선수범해서 나눠 적극적으로 일해야만 나오는것이 생산성인데, 나 아닌 누군가가 하겠지하는 속내(본성)를 가지고 있고
  • 각자의 역할에 각인된(이 기능은 누구, 저 기능은 누구) 사람들이 자기의 책임감이 커지는 것을 꺼려하고 스스로에게 울타리를 쳐 전체를 보는 시야를 흐리게 한다.
이렇게 되어, 결국 사람이 많으면 비효율적 협업 메커니즘도 같이 올라가게 된다.

링겔만 효과를 최소화하려는 노력들

1. 자율성과 그룹의 소규모화
업무, 시간, 기술, 팀의 자율성을 부여하자. 프로세스, 관리 등은 업무의 성과를 저해하는 중요한 요인들이다. 자율성에서부터 문화란게 생기기 시작한다고 믿고 있다. 그리고 팀이나 그룹을 구성하는 인원을 한자리(10명 이내) 이내로 한다. "two-pizza rule"라고 하는데, 피자 2장으로 배를 채울 정도의 인원이 최적이라는 설이 설득력이 있어 보인다.

2. 외적 동기도 중요하지만, 내적 동기를 찾자
Daniel H. Pink가 쓴 Drive라는 책을 보면 인간의 동기는 세단계로 나뉜다고 한다.
  • 동기 1.0 : 인간을 음식, 안전, 섹스 등 기본적인 욕구를 얻기 위해서 발버둥치는 생물학적 존재라고 추정한다. 즉, 하고 싶은 것을 하고, 하고 싶지 않은 것은 하지 않는게 아니라 살아가야하면 할수밖에 없는 노력의 세계다. 생존 자체가 동기부여다.
  • 동기 2.0 : 인간은 당근과 채찍에 의해 대응한다고 추정한다. 당근을 줘서 의욕을 주고, 혹은 벌을 통해 그것을 피하고자 하는 욕구를 주게하는 방식의 동기다. 연봉 올려주기 등이 여기에 해당된다.
  • 동기 3.0 : 더 나은 세상을 만들기 위해, 새로운 것을 창조하기 위한, 배우기 위한 개인 내부에서 자발적으로 나오는 내재적 동기를 가르킨다.
창의성 발현이 훨씬 중요해진 오늘날에는 이 두가지 동기만(동기 1.0, 동기 2.0)으로는 인간을 움직일 수 없다고 한다. 그래서 세번째 동기인 동기 3.0을 이야기한다. 그 근거로 애드워드 디씨의 실험을 들었다.
두 그룹을 지정하고 양쪽 모두에게 세번씩의 소마 퍼즐을 풀게 했다. 첫번째 퍼즐을 두 그룹에 풀게하고, 한 그룹은 보상을 주고(A그룹) 다른 그룹은 포상을 주지 않았다(B그룹). 그 다음은 퍼즐을 한번 더 풀게하고 두 그룹 모두 보상을 하지 않았다. 그런 후 보상을 한번도 받지 못한 B그룹은 계속해서 퍼즐을 푸는 흥미를 보였고, 보상 경험이 있던 A그룹은 퍼즐에 흥미를 보이는 시간이나 즐거움을 느끼는 시간 자체가 줄어들었다고 한다.
이 실험을 통해 "돈이 외적 보상으로 사용될 경우 사람들은 그 행위에 대한 내재적 관심을 잃는다"고 주장한다.

그리고 동기 2.0의 한계가 우리 주변에서 일어나고 있다고 한다. 위키피디아, 리눅스, 파이어폭스 등을 예로 들면서 인간에게 육체적, 물질적인 부분 이상으로 자기의 만족과 일 자체가 갖는 즐거움을 축구하는 욕구가 존재한다. 결국 동기 3.0이 중요하다는 말이다.

그래서 자신 스스로가 일하는 의미와 왜 이 일을 해야하는지에 대한 대답을 찾아야 하고, 내가 더 잘하고 싶은 욕망을 가지고 숙련활동을 자발적으로 하는 노력이 필요하다.

3. 신뢰관계가 중요하다.
신뢰관계가 형성되면 상호 협력하는 정도도 증가하고 자발성도 증가하게 된다. 도움을 받으면 도와주게 되고 그렇게 되면 링겔만 효과는 줄어들고 오히려 시너지가 발생할 것이다.

4. 능력을 키우자.
능력은 서로간의 신뢰관계에 중요한 단초로 작용하는 경우가 많다. 실력이 있는 사람에게 배우고 싶고 친하게 지내고 싶은게 인지상정이다. 검색보다 신뢰할 수 있는 지식은 경험에서 나오는 사람들의 말이다. 그리고 조직에서 능력있는 자가 자신의 지식을 공유하는 자율적인 시스템을 만들어 놓는것도 중요한 것 같다. 전체 조직력이 증대되는 효과와 조직력의 이탈을 막을 수 있다.

5. 비전 공유하자
서로의 역할이 명확하고 도전적인 자세와, 서로 신뢰하고 친밀한 관계가 생겼다면, 비전이라는 하나의 목표를 달성하려는 의식의 일치는 협업에서 중요한 효율성을 갖게 한다. 그래서 결국엔, 비전에 적합한 조직력을 만들수 있게 된다.

[관련 포스트]
Tags :

기술과 관련된 뉴스레터

트위터나 페이스북의 큐레이션된 정보로는 Localization벽에 뭍혀버리는 기술 아티클이 많다. 그래서 괜찮은 뉴스레터를 정리해 본다.

1. 프로그래밍 언어
2. 프론트엔드
3. 데이터베이스
4. 데이터 과학
5. 인프라
6. 스타트업
7. 기타

더 나은 프로그래머가 되기 위해 알아야할 모든것은 이미 유치원에서 우리는 배웠다.

All I Need To Know To Be A Better Programmer I Learned In Kindergarten"라는 오래된 글이지만, 훌륭한 프로그래머가 되는 것은 먼 곳에, 어려운 곳에 있지만은 않다는 느낌을 받았습니다. 기본적인 내용들이지만, 그동안 바쁘다는 핑계로 잊었던 것들을 다시 생각해 보는 계기가 되었네요. 그리고 조금씩 먼저 실천해 가는 개발자만이 훌륭한 프로그래머로 되지 않을까요? 생각해 보면서 정리해 봅니다.

프로그래밍은 참으로 복잡한것이다. 그렇지만, 훌륭한 프로그래머가 되기 위해서 필요한 대부분의 것들은 우리가 어릴때 학교에서 배운 것과 크게 다르지 않다. 즉, 훌륭한 프로그래머는 어릴때 유치원에서 배운대로만 하면 된다는 이야기다.

아래의 리스트에 대한 영감은 Robert Fulghum의 All I Really Need to Know I Learned in Kindergarten"라는 에세이에서 많이 왔다.

1. 모든 것을 공유해라.
가능하면 오픈 소스를 사용하고 할 수 있다면 기여까지(contribute) 해보자. 커뮤니티의 집단 지성은 몇몇 대기업의 제한된 비전(생각들)보다는 훨씬 좋다.

2. 공평하게 해라.
다른 기술들이나 프레임워크, 방법론, 그리고 의견들에 기회를 주자. 자신의 선택만(내 방법만) 잘 동작한다고 생각하면 안된다. 다른 대안들도 잘 동작할 수 있고 열린 마음으로 다른 것들을 알아가는 것도 좋다.

3. 사람을 공격하자 마라.
2번에서와 같이 사람들이 .net이나 Java, PHP를 사용하고 있다는 이유만으로 그들을 공격하지 말자. 때로는 그들이 당신이 생각하는것보다 훨씬 사용성이 좋고 더 유용할 수 있다. 당신이 그들을 공격하지 않는다면 당신은 그들로부터 더 많은 것을 배울 수 있다.

4. 내가 어질른것은 내가 정리하자.
잘 동작하는 코드를 배포할 수 있도록 노력하자. QA가 너의 모든 버그를 찾아준다고 생각하면 안된다. 자주 테스트하고 때로는 치밀하게 때로는 광범위하게 테스트 하자.

5. 내것이 아니면 가지지 말자.
자신이 사용하는 것의 라이센스를 따르자. 절대로 훔치는 것은 안된다. 그리고 나중에 몰랐다고 잡아때도 안된다.

6. 사람을 다치게 했다면 꼭 미안하다는 말을 하자.
코드 리뷰는 매우 좋은 것이지만, 거의 행해지지는 않는다. 당신보다 경험이 없는 프로그래머에게 가르쳐주는 것은 팀 전체에는 큰 도움이 된다. 사람들을 공개적으로 비난하는 것을 그만하자. 학습은 사람을 경시하는 것이 아니다. 때때로 사람들은 내말을 들어줄때도 있고 그렇지 않을때도 있다. 나 자신보다 못하다고 생각되는 사람으로부터 많은 것을 배울수도 있다.

7. 먹기 전에 손을 씻자.
코드를 작성하기 전에 대상을 잘 이해하도록 노력하자. 프로토타입을 만들고, Web상에서 예를 체트해 보자. 같은 일하는 동료와 이야기하거나 심지어 같이 노는 것도 좋다. 경험을 하지 않았거나 사용한적이 없는 것을 구축하는 것은 매우 힘들다. 결국 단서를 가지고 일을 시작하면 결과는 잘 마무리 될 것이다.

8. 사용이 끝나면 물을 내리자.
사용할 수 없는 물건을 바꾸거나 다시 작성, 리팩토링, 그냥 포기하는 것을 두려워하면 안된다. 때로는 의심스럽다면 던져버리는 것이 최고의 철학이다. 그리고 결코 자신의 코드와 사랑에 빠지면 안된다.

9. 따뜻한 쿠키와 찬 우유는 건강에 좋다.
물론 프로그래머는 자신의 업무 환경이 좋아야 한다. 좋은 의자, 조용한 환경, 최신 PC에, 더 좋고 더 쉬운 코드를 만들수 있는 도구가 필수적이다. 관리자는 프로그래머에게 떨어지는 것을 지켜주는 우산 역할을 하는 것이다. 프로그래머라면 저급한 노예의 삶을 거부하자. 만약 고용주가 너를 하찮게 취급한다면, 다른 더 좋은 회사를 찾아라.

10. 균형된 삶을 살자 - 매일 조금씩 배우고, 생각하고, 그리고 칠하고, 노래하고, 춤추고, 놀고, 일하자.
나는 자신이 가치 있다고 생각하면 뭐든지 20%의 시간을 투자할 수 있는 Google의 20%룰을 좋아한다. 고용주들은 별도로 낮잠을 자는 룸이나 게임룸이나 긴장을 풀어주는 환경을 준비해야 한다. 프로그래밍은 정신적으로 매우 힘든일이다. 때때로 우리의 뇌를 쉽게해주는 것이 필요하다. 일상적인 주 80시간 노동은 당신이 만든 제품을 품질을 파괴하기 때문에 거부하자.(자신을 녹초로도 만들수 있다)

11. 오후에는 꼭 낮잠을 자자.
하루 24시간 일하는 것은 전혀 생산적이지 않다. 휴식을 취하고, 집으로 가서 제대로 수면을 취하라. 나는 종종 고약한 문제를 집에 가는동안에 해결될 때가 있었다. 퇴근길 운전중에, 혹은 다음날 아침에 해결 방법이 떠올랐다.

12. 밖에 나갔을때는 차를 조심하고 손을 잡고 함께 건너자.
커뮤니티활동은 아주 중요하다. 블로그를 읽고, 새로운 언어와 프레임워크에 대해 배우자. 토론에 참여하고 다른 사람이 하고 있는 것을 보라. 일을 하는 것만으로는, 훌륭한 프로그래머가 될 수 없다. 독불장군이 된다면 당신은 결국 쓸모없게 된다.

13. 궁금한것은 알아보라. 스티로폼컵 속의 씨는 뿌리가 자라고, 식물이 자란다. 아무도 그것이 어떻게, 왜 그런지는 모른다. 하지만, 우리 모두는 그것과 같다.
매일 새롭고 멋진 것들이 프로그래밍과 기술 세계에 일어나고 있다. 알아 보자. 매혹될 것이다. 매일 새로운 어떤 것을 배우자. 그래서 너의 마음은 신선해지고 너의 선택은 넓어지고, 기술력이 업데이트 된다. 만약 프로그램이 지루하거나 재미없다고 생각한다면 새로운 일을 찾는 것이 좋다.

14. 금붕어와 햄스터, 생쥐, 스티로폼 컵속에 씨앗조차 모두 죽는다. 우리들도 죽는다.
코드도 오래되면 나빠지고 죽는다. 때로는 그것을 아주 묻어주거나 혹은 다시 작성해야 한다. 돈을 아낄려고 더러운 코드를 유지보수하는 것은 전쟁이다.

15. Dick와 Jane의 동화책을 기억하고 먼저 배운 말을 생각해 보자 - 가장 중요한 단어는 "보는 것"이다.
만약 시도하지 않으면 아무것도 배울 수가 없다. 내가 프로그래밍에서 배운 모든것은 새로운 것들을 시도하거나 노는데서 왔다. 매일 아침 나는 프로그래밍 세계에서 무엇이 이어나고 있는지를 알기 위해서 여러 사이트들을 읽었다. 나는 이것을 80년대 초부터 계속 진행하고 있다.(당시는 카탈로그와 잡지들만 읽을지만.)

봐라, 5세의 눈을 통해서 보면 프로그래밍은 이렇게 간단하다.
Tags :

Vitess

YouTube의 거대한 동영상 시청 데이터 및 메타 데이터를 관리하고 있는 MySQL의 스케일 기능을 담당하는 Vitess를 오픈 소스로 공개했다.

1. 아키텍처


2. Vitess의 주요 특징
- SCALABILITY
  • MySQL의 커넥션에 걸리는 메모리 오버 헤드 제거.
  • 어플리케이션의 샤드 로직 추가없이 데이터 베이스 확장.
  • 샤딩 기능 내장.
  • 읽기 다운 타임 최소화가 가능하고 라이브 리샤딩 기능 지원.

- PERFORMANCE
  • 데이터베이스 성능에 문제를 야기하는 쿼리를 자동 재작성함.
  • 프록시 서버에서 캐싱 메커니즘을 활용하여 쿼리 조정이나 중복 쿼리 제거.

- MANAGEABILITY
  • etcd과 Zookeeper와 같은 락 서버를 통해 서버군들을 추적 및 관리 할 수 있음.
  • 마스터 장애조치, 백업 등의 기능을 자동화함으로써 다운 타임을 최소화 해 줌.

[참조 사이트]
Tags : ,

생산성과 창의성, 그리고 문화

급박한 일정에 놓여있고 빨리 개발하는 개발자를 편애하는 환경속에서 있다보니 생산성이 암묵적으로 중요하다는 생각이 우리의 머리에 자리잡고 있다.


그 부작용으로 창의력과 문제해결 능력을 갖고자 생각의 시간을 갖는 사람을 프로젝트에서 방해자로 간주되기 쉽게 되고 사람을 단지 목적을 달성하기 위한 종속자 역할만을 바라보게 된다.


그래서 단순 개발 효율화를, 빠른 피처 개발만이 생산성으로 치부해 버리고 생산성과 창의성의 반비례가 고착화된다.


구성원과 조직의 비전을 이해하고, 부족한 부분을 찾거나 메워주고, 상호 인식의 전환과 공유 노력을 하고, 목표에 기반한 조직력 증대 등 개발 문화 형성에 모든이들의 노력해야 생산성과 창의성은 정비례로 가게 될 것이다.


또한, 문화의 혜택을 자신의 편이로 활용하기보다는 더 나은 문화를 만드는데 일조하도록 지속적으로 노력해야 그 문화가 유지된다.


생산성, 창의성, 문화는 서로 결부되었을때 성숙될 것 같다.

삶의 태도

1. 가정을 하는것보다 질문을 하는것이 낫고 질문보다 그전에 한번 내가 온전히 할 수 있는지에 대해 조사하고 고민해보자. 증명을 하지 않는 가정은 실수를 낳게 하고 무조건 질문 먼저 하게되면 스스로 배울 기회를 앗아가고 기본기가 떨어지게 만든다.

2. 들을 땐, 검색할 땐 배우는 자세로, 그리고 듣고 검색한 후에는 맞는지 혹은, 내 것으로 만드는 후행학습을 하자. 그러면 경험 지식으로 만들어버려 오래갈 수 있다.

3. 코드나 문서 등은 내 얼굴이라고 생각하고 리팩토링이나 리뷰의 습관을 가지고, 문서는 필요한 경우에 한해 하며 항상 유용성과 현행화를 고민하자.

4. 인간에게 인식과 이해는 비동기적으로 일어나기 때문에 될 수 있으면 쉽게 말하는 버릇을 가지고, 중요한 건 캐싱이 안되고 별거아닌 기분 나쁜건 오래 캐싱되기에 완곡하게 표현하는(기분이 나빠도 한템포 참고 넘어가는) 습관을 가지자.

5. 목표 때문에 필요가 생겨나고 그 필요에 의해 의도가 생기니 굳이 친한 관계가 아니면 의도를 숨기는 편이 나은것 같다.

6. 인간은 형편보다 기회에 초점을 맞추다보니 자신의 유용성을 항상 강구하고 갖추기를 노력하고 어필한다.