N° 01 — 목록

'Principles' (8)

  1. Architecture & Design/Software Architecture

    Principles - 08. 복잡성의 원천

    흙은 없앨 수 없지만 잡초는 뽑을 수 있다 — 복잡성의 원천정원을 가꾼다고 하자. 흙이 있다 — 식물이 자라려면 흙이 필요하고, 흙의 종류·배수성·영양분이 복잡하다. 이건 정원의 본질이다, 없앨 수 없다. 하지만 잡초도 있다 — 우리가 심지 않았는데 자라난 것, 영양분을 빼앗고 정원을 어지럽힌다. 이건 뽑을 수 있다. "정원이 복잡하다"고만 말하면 흙과 잡초를 구분 못 한다 — 무엇이 본질이고 무엇이 우리가 만든 것인가를 가려야 한다.소프트웨어 복잡성도 두 종류다. Fred Brooks는 (1986)에서 본질적 복잡성(essential complexity)과 우발적 복잡성(accidental complexity)을 나눴다. 본질적 복잡성은 문제 자체에서 온다 — 결제 도메인의 복잡한 규칙, 동시성 요구,..

    · 댓글
  2. Architecture & Design/Software Architecture

    Principles - 07. 오류 처리 전략

    배송 실패와 화물 사고는 다르다 — 오류 처리 전략택배를 보낸다고 하자. 수취인이 부재중이라 배송이 실패했다 — 이건 정상 흐름의 일부다. 내일 다시 배달하면 된다(복구 가능). 하지만 트럭이 사고를 내어 화물이 전소했다 — 이건 정상 흐름이 아니다. 운송 자체가 중단되고, 보상 청구라는 전혀 다른 경로로 넘어간다(복원 불가능).소프트웨어 오류도 이 두 종류로 나뉜다. 복구 가능한 오류(입력 검증 실패, 리소스 부족)는 정상 흐름의 일부로 다뤄야 하고, 복원 불가능한 오류(디스크 고장, 메모리 부족)는 흐름을 중단시키고 상위로 알려야 한다. 이 둘을 구분하지 않고 모두 예외로 던지면, 호출자가 매번 try-catch를 쳐야 하고 정상 흐름이 예외 처리에 묻힌다.예외 vs 결과 값 — 두 접근예외(exce..

    · 댓글
  3. Architecture & Design/Software Architecture

    Principles - 06. 계약 설계와 API

    메뉴판은 계약서다 — 계약 설계와 API식당에서 메뉴판을 본다. "된장찌개 8,000원"이라고 적혀 있다. 이 한 줄이 계약이다 — 8,000원을 내면(사전 조건) 된장찌개를 받는다(사후 조건). 주방에서 어떤 냄비를 쓰는지, 몇 분 끓이는지는 모른다. 메뉴판이 약속한 것만 지켜지면 된다. 메뉴판이 바뀌면(가격 인상, 메뉴 삭제) 손님이 혼란스럽다 — 계약이 변경된 것이다.소프트웨어의 API도 같다. 메서드 시그니처가 메뉴판이고, 호출 규칙이 계약이다. Bertrand Meyer는 에서 이를 계약에 의한 설계(Design by Contract)로 정식화했다 — 사전 조건(precondition), 사후 조건(postcondition), 불변 조건(invariant) 세 가지로 계약을 명시한다.사전 조건과..

    · 댓글
  4. Architecture & Design/Software Architecture

    Principles - 05. 캡슐화와 정보 은닉

    계기판 뒤에 엔진이 있다 — 캡슐화와 정보 은닉운전자가 자동차를 몰 때 보는 건 계기판이다 — 속도계, 연료 게이지, 엔진 경고등. 엔진 내부의 실린더 배열이나 점화 타이밍은 보이지 않는다. 엔진이 터보에서 하이브리드로 바뀌어도, 계기판이 같으면 운전자는 모른다. 이것이 캡슐화(encapsulation)다 — 내부 구현을 숨기고 외부에 필요한 것만 노출한다.David Parnas는 1972년 논문에서 모듈을 나누는 기준으로 "무엇이 변할 수 있는가"를 제시했다. 변할 가능성이 있는 것을 모듈 안으로 숨기고, 변하지 않는 것만 인터페이스로 노출한다. 그러면 내부가 바뀌어도 외부(다른 모듈)가 영향을 받지 않는다.캡슐화의 두 층 — 데이터 은닉과 구현 은닉데이터 은닉은 객체의 내부 상태(필드)를 외부에서 직..

    · 댓글
  5. Architecture & Design/Software Architecture

    Principles - 04. 의존성 규칙

    부장이 말단 사원에게 의존하면 조직이 뒤집힌다 — 의존성 규칙조직도를 그린다고 하자. 사장이 부장에게 지시하고, 부장이 대리에게, 대리가 사원에게. 화살표는 위에서 아래로 향한다. 만약 사원이 "제가 이 방식으로 하겠습니다"라고 바꾸면 사장의 업무가 영향을 받는다면, 조직이 뒤집힌 것이다 — 말단이 최상위를 좌지우지하면 안 된다.소프트웨어도 같다. 도메인(최상위)이 데이터베이스(최하위)에 의존하면, DB를 바꿀 때 도메인이 흔들린다. 의존성 규칙은 "의존성은 항상 안쪽(고수준)으로만 향해야 한다"고 말한다 — 인프라가 도메인에 맞추지, 도메인이 인프라에 맞추지 않는다.의존성 역전 — 화살표를 돌려세운다도메인이 DB를 직접 쓰면, 의존성이 도메인 → DB로 향한다. DB를 바꾸면 도메인이 깨진다. 의존성 ..

    · 댓글
  6. Architecture & Design/Software Architecture

    Principles - 03. 패러다임의 함의

    걷기, 운전, 기차 — 세 패러다임이 사고를 제약하는 법목적지에 가는 방법은 세 가지가 있다. 걸어간다(절차형) — 순서대로 한 발씩, 경로를 직접 결정한다. 운전한다(객체지향) — 자동차라는 상태(속도·연료)와 행동(가속·제동)이 함께하는 도구를 조종한다. 기차를 탄다(함수형) — 정해진 선로 위를 달리며, 내가 조종하지 않고 정해진 역에서 내린다.세 방법은 이동이라는 같은 목표를 이루지만, 사고 방식이 다르다. 걷기는 절차(순서)에 집중하고, 운전은 객체(상태+행동)에 집중하며, 기차는 함수(입력→출력, 상태 없음)에 집중한다. 프로그래밍 패러다임도 같다 — 절차형·객체지향·함수형은 같은 문제를 다른 사고로 푼다.절차형 — 순서가 곧 프로그램절차형(procedural)은 데이터와 함수가 분리되어 있다..

    · 댓글

티스토리툴바