Theory/Unclassified

민주주의 서비스 아키텍쳐

민주주의는 그냥 표를 많이 얻는 이가 권력을 가지는 제도이다.
표를 많이 얻은 사람이 훌륭하다는 보장이 없다.
따라서, 민주주의는 훌륭한 사람 능력있는 사람을 뽑는데 적합한 제도가 아니다.
다만, 이상한 사람이 권력을 잡아도 나쁜 짓을 아주 많이 못하게 한다.[각주:1]
민주주의의 핵심은 평화적이고 합법적으로 권력을 교체할 수 있다는 것에 있다.

- 차이나는 클래스에서 유시민


비슷한 원리를 서비스 아키텍쳐에 도입하면 어떨까?
이를 "민주주의 서비스 아키텍쳐"라고 이름을 붙이자.

이 아키텍쳐는 최고의 시스템을 만드는 것을 목표로 하고 있지 않다.
문제가 있더라도 극복할 수 있는 탄력적인 시스템을 만드는 것이 핵심이다.[각주:2]

  1. 박근혜 전대통령의 탄핵이 대표적인 예. [본문으로]
  2. 세부 기술과 방법은 생각나면 진행할 예정이다. 어쩌면 여기까지가 끝일 수도 있다. [본문으로]
저작자 표시 변경 금지
신고
Practice/Debugging

문제가 발생하면 근본 원인 찾아라.

문제가 발생하면 근본 원인 찾아라.[각주:1]
근본 원인을 찾지 않고 성급하게 해결하는 것은 나쁘다.

대표적인 사례가 핵(hack)이다.
핵은 원인을 고치지 않고 드러나는 문제만을 처리한다.
근본 원인 파악 없이 방어 코드로 해결한다.

자동차의 시동을 두세번 시도해야 비로서 작동하는 문제가 있다고 가정해보자.
핵를 쓰는 엔지니어는 시동 걸릴 때까지 자동으로 반복해주는 기능을 추가한다.
여러 가능성이 있는 원인을 조사하지 않고 표면적인 문제만을 처리하였다.[각주:2]

그러나, 이러한 방식은 문제를 감추었을 뿐 근본이 해결되었는지 알 수 없다.
숨겨진 문제가 언제 드러날지 누구도 알 수 없다.
게다가, 이렇게 원인이 해결 안 된 문제들이 숨겨지면서 누적된다는 것이 더 심각하다.

시동이 잘 안걸렸던 이유가 배터리가 망가지고 있었기 때문일 수도 있다.
만약 그렇다면, 핵으로 진짜 문제를 숨겨준 셈이다.
외딴 곳에 있을 때 배터리가 완전히 망가진다면
또는 고속도로 주행 중에 시동이 꺼진다면
아주 큰 문제에 직면하게 된다.
실력있는 엔지니어는 진짜 원인을 찾아내어 이런 사태를 사전에 예방했을 것이다.

더불어, 핵을 자주 사용하면 개인의 실력 향상에도 좋지 않다.
문제를 정의하고 원인을 파악하는 능력은 문제 해결에서 매우 중요하다.
핵은 이 능력을 길러주지 않는다.

핵을 쓸 수 밖에 없는 피치 못할 상황도 있긴 하다.
예를 들면, 긴급하게 처리해야 하는 상황,
우리가 수정할 수 없는 외부 라이브러리 등의 이유가 있겠다.
이러한 경우, 코드에 반드시 핵을 썼다는 사실과 이유 등을 주석을 남겨야한다.[각주:3]
나중에 이런 부분을 찾아서 반드시 제대로 고쳐야 한다.


  1. 가능성 있는 진짜 원인을 찾아가는 도구 중에 <a href="http://unipro.tistory.com/112" target="_blank">5 Whys</a>라는 것이 꽤 유용하다. [본문으로]
  2. 문제를 빨리 해결하여 마치 실력자처럼 보일 수도 있다. 이런 착시 때문에, 일부 프로그래머는 자신의 무능함을 감추고자 핵을 자주 이용한다. [본문으로]
  3. 관례적으로 주석의 시작에 "HACK" 또는 "XXX"라고 붙이다. [본문으로]
저작자 표시 변경 금지
신고
Life/Software Engineer

기술 허세

자신의 지식이나 기술을 보여줄 목적으로
불필요하게 과도한 기술을 언급하거나 도입하여 것을
나는 '기술 허세'라고 부른다.
최신 유행하는 기술을 마구 늘어놓는 것이 전형적인 형태이다.

기술과는 관련이 없지만, 주변에서 '허세'라는 것을 종종 접한다.
뒷동산에 올라가도 너나 할 것 없이 전문 등산 장비를 몸에 두른다.
최소한 수십만원 때때로 그 이상의 가격이 붙은 등반의 명품을 차려입는다.
장비에 비해서 산이 초라하게 느껴질 정도이다.
자전거 동호외에 참여해도 다르지 않다.
가벼운 라이딩을 즐기는 사람이 장비는 프로들의 그것에 견주어 볼 만 하다.

그들은 비록 닭을 잡지만 소잡는 칼이 있음을 자랑하고 싶다.
수단은 목적에 이르게 하는 도구이다.
목적에 맞게 과하지도 부족하지도 않은 것을 택하는 것이 합리적이다.
합리적이지 않은 이유를 설명하는데 '허세'만큼 적절한 용어가 없다.

이와 같은 현상이 IT에도 있다.
해결할 문제에 대한 분석없이 첨단 기술이나 최신 유행을 떠든다.
예를 들면, 사내 데이터를 분석하는 문제에 대해서
데이터의 형태나 크기 등을 살펴볼 생각을 하지 않고
최근에 좀 주워들은 하둡, 스플렁크, 스파크 등의 지식을 나열한다.

이런 태도는 해결 방법의 선택을 매우 제한하기 때문에 문제가 된다.
쉽고 간단하게 해결할 수 있는 문제를 필요 이상으로 어렵게 만들 수 있다.
이전 단락의 '사내 데이터 분석'의 예를 다시 꺼내보자.

  • 간단한 것은 grep 등을 이용한 간단한 쉘스크립팅으로 분석 가능하다.
  • 엑셀과 VB스트립트로 웬만한 규모의 데이터는 손쉽게 처리하는 분을 본적도 있다.
  • 좀 더 복잡하다면, 자신이 익숙한 스크립트 언어(perl이나 python 등)으로 처리하는 것도 한 방법이다.
  • RDBMS 쿼리에 익숙하다면, RDBMS와 아름다운 쿼리로 멋지게 끝내는 것을 어떨까?
    쿼리 마스터의 능력은 위대하다.
  • 기존 방법으로는 해결하기 힘들어서 새로운 기술 중에서 골라야 하는 경우도 더러 있다.

즉, 자신(팀)이 가진 기술, 데이터의 형태나 크기, 원하는 정보에 따라서 다양한 해결 방법이 있다.
'닥치고 스파크'를 외치는 것은 전문가답지 않다.
단지, 최신의 기술인 스파크를 알고 있다고 알리고 싶은 허세스러운 행동일 뿐이다.
아니면 스파크 밖에 모르는 햇병아리임을 스스로 자인하는 꼴이다.

최신 기술을 안다는 것은 새로운 무기를 "더하는" 것이다.
기존의 좋은 무기를 쉽게 버리는 우를 범하지 않아야 한다.
상대성 이론과 양자 역학으로 패러다임은 이동했지만, 뉴턴의 고전 역학은 아직도 유용하다.
최신이 최선이 아니다.


데이터 싸이언스 계의 ‘싸이’ 김진영님의 이야기를 많이 참고하였다.

저작자 표시 변경 금지
신고
  1. Favicon of http://www.boannews.com/media/view.asp?idx=56216 보안뉴스 옮김 M/D Reply

    무조건 최신 기술이 최고가 아니라는 좋은 사례.

    전 세계 선박들이 사이버 위협 때문에 최신식 인공위성 기술을 버리고 2차 세계대전 때나 쓰던 라디오 기술을 다시 채택하고 있는 것으로 나타났다.

    출처: http://www.boannews.com/media/view.asp?idx=56216

Theory/Programming Language

getter/setter를 올바로 사용하기

외부에서 내부의 상태를 변경할 때는 getter/setter를 사용하도록 한다.[각주:1]
변수를 직접 접근하도록 노출하지 않는다.
이름이 변경되지 않을 getter/setter를 공개한다.


변경될 가능성이 적은 getter/setter만 외부에 노출한다.

public 속성을 지닌 모든 것(클래스, 함수, 변수 등)의 의도는
"마음대로 접근하라."는 의미만 있는 것이 아니다.
"이름이 바뀌지 않는다."까지 포함한다.
바뀔 수도 있다면(예를 들면, 구현에 의존적이라면) public 속성을 주지 않는다.
이 클래스를 변경할 때, 이것을 사용하는 다른 어떠한 코드에도 영향을 줄 수 있기 때문이다.


getter/setter를 사용하면 일관된 접근 방법을 유지하면서 구현의 유연성까지 제공한다.

변수의 이름이나 규칙이 바뀔 수 있다면
setter/getter 같은 것을 한번 감싸는 것이 좋다.
예를 들면, "Null을 설정할 수 없다."라는 규칙이나,
불변성[각주:2]이 추가될 수 있다.

접근의 제약이 없고 변수명이 절대로 바뀔 일이 없으면
변수를 public으로 직접 공개해도 괜찮을 듯 싶다.

그러나, getter/setter와 변수 직접 접근을 섞어서 쓰면 코드가 더러워진다.
어떤 변수는 'h = now.getHours()'
다른 변수는 'm = now.minutes'를 사용하면 지저분하다.


getter/setter에 대한 오해

setter/getter 쓴다고 정보은닉이 되는 게 아니고 사실은 정보은닉을 망치게 됩니다.
저는 getter/setter 많이 쓴 것은 나쁜 냄새(bad smell)로 봅니다.
getter setter는 객체지향과 거리가 멀며 써야 할 곳은 한정되어 있다


문맥과 떨어져서 해석하면,
"getter/setter 보다는, 변수를 직접 노출하고 사용하는 것이 좋다"
라고 오해할 수 있다.


꼭 필요한 getter/setter만 공개한다.

내가 해석한 의도는
클래스 내부의 변수를 필요 이상으로 노출하는 설계는 나쁘다는 것이다.
그래야만 한다면 설계에 문제[각주:3]가 있다고 볼 수 있다.
공개된 getter/setter 뿐만 아니라 이와 마찮가지인 public 변수도 해당된다.
따라서, getter/setter 보다는 변수에 public을 주는 것이 좋다고 해석하면 안된다.

  1. 언어에서 제공하는 getter/setter 포함. 예를 들면, C#의 property [본문으로]
  2. getter/setter에서 사본을 생성하고 이를 반환하는 식으로 구현 [본문으로]
  3. 인용한 구절에서는 이를 나쁜 냄새라고 표현했다. [본문으로]
저작자 표시 변경 금지
신고

'Theory > Programming Language' 카테고리의 다른 글

getter/setter를 올바로 사용하기  (1) 2017.02.13
public, private 키워드가 필요한 이유  (0) 2017.02.08
  1. Favicon of https://justhackem.wordpress.com/2017/02/28/encapsulation-and-information-hidi.. 옮긴이 M/D Reply

    나는 응집 관점의 캡슐화 해석을 지지한다. Vector 클래스 설계법은 정보를 숨기지 않지만 이름을 가지기에 충분한 가치가 있기때문이다.
    https://justhackem.wordpress.com/2017/02/28/encapsulation-and-information-hiding/

Theory/Programming Language

public, private 키워드가 필요한 이유

public/private 키워드는 정보 은닉, 캡슐화 등에 도움을 주는 도구이다.

정보 은닉은 복잡하거나 변경 가능한 설계 결정을 안정적인 인터페이스 뒤로 숨기는 기본 설계 원리이다.
정보 은닉은 모듈을 분할하기 위한 기본 원리다.
모듈은 변경될 가능성이 있는 비밀을 내부로 감추고 잘 정의되고 쉽게 변경되지 않을 공용 인터페이스를 외부에 제공하여 내부의 비밀에 함부로 접근하지 못하도록 한다.
캡슐화는 ‘온갖 방법의 숨기기’라고 생각하면 쉽다. 캡슐화를 통해 데이터를 숨길 수 있다. 그리고 구현 코드, 파생 클래스 또는 여러 가지의 것들을 숨길 수 있다.
- 알란 섈로웨이, 제임스 트로트, “알기 쉬운 디자인 패턴
캡슐화는 가해지는 변경에 대한 파급 효과를 일정한 영역 내부로 제한시킬 수 있다.
대부분의 컨텍스트에서 캡슐화와 정보 은닉은 동일한 의미를 지니다.

Information Hiding by 이터너티


private 키워드의 불편함을 호소하며 무용론을 펼치는 이들이 있다.

public/private 키워드는 필요없다.
구현하면서 접근자에 대해서 신경쓰느니 그냥 public으로 모두 공개하겠다.
필요하다면 주석이나 문서로 설명하면 충분하다.

라고 주장한다.

흔히 접하는 전형적인 부채의 한 유형이다.[각주:1]
당장은 편하고 빠를 수 있겠으나,
프로젝트가 커지고 복잡해지면 결국 이것이 발목을 잡는다.

프로그램의 곳곳에서 백여 번에 걸쳐서 주의력을 소진하는 것보다는 당연히 단 한 번만 주의를 기울이는 편이 훨씬 행복한 경우일 것입니다.

- Modern C++ Design

언어적으로 제약 조건을 기술하는 기능을 활용하면 여러모로 편하다.
컴파일러, 또는 자동 오류 검사 도구를 사용하여 제약 조건 위반을 바로 찾아낼 수 있다.
심지어, 요즘 개발 툴은 제약 조건을 반영하여, 자동 완성, 오류 검사 등으로 코딩을 도와준다.
개발자는 제약 조건에 신경쓸 필요없이 코딩에만 집중하면 된다.

  1. 또 한가지 흔한 유형은 테스트 코드를 전혀 만들지 않기 [본문으로]
저작자 표시 변경 금지
신고

'Theory > Programming Language' 카테고리의 다른 글

getter/setter를 올바로 사용하기  (1) 2017.02.13
public, private 키워드가 필요한 이유  (0) 2017.02.08

알림

이 블로그는 구글에서 제공한 크롬에 최적화 되어있고, 네이버에서 제공한 나눔글꼴이 적용되어 있습니다.

카운터

Today : 98
Yesterday : 147
Total : 171,340