N° 01 — 목록
'Software Architecture' (50)
-
Software Architecture/PrinciplesPrinciples - 06. 계약 설계와 API
메뉴판은 계약서다 — 계약 설계와 API식당에서 메뉴판을 본다. "된장찌개 8,000원"이라고 적혀 있다. 이 한 줄이 계약이다 — 8,000원을 내면(사전 조건) 된장찌개를 받는다(사후 조건). 주방에서 어떤 냄비를 쓰는지, 몇 분 끓이는지는 모른다. 메뉴판이 약속한 것만 지켜지면 된다. 메뉴판이 바뀌면(가격 인상, 메뉴 삭제) 손님이 혼란스럽다 — 계약이 변경된 것이다.소프트웨어의 API도 같다. 메서드 시그니처가 메뉴판이고, 호출 규칙이 계약이다. Bertrand Meyer는 에서 이를 계약에 의한 설계(Design by Contract)로 정식화했다 — 사전 조건(precondition), 사후 조건(postcondition), 불변 조건(invariant) 세 가지로 계약을 명시한다.사전 조건과..
-
Software Architecture/PrinciplesPrinciples - 05. 캡슐화와 정보 은닉
계기판 뒤에 엔진이 있다 — 캡슐화와 정보 은닉운전자가 자동차를 몰 때 보는 건 계기판이다 — 속도계, 연료 게이지, 엔진 경고등. 엔진 내부의 실린더 배열이나 점화 타이밍은 보이지 않는다. 엔진이 터보에서 하이브리드로 바뀌어도, 계기판이 같으면 운전자는 모른다. 이것이 캡슐화(encapsulation)다 — 내부 구현을 숨기고 외부에 필요한 것만 노출한다.David Parnas는 1972년 논문에서 모듈을 나누는 기준으로 "무엇이 변할 수 있는가"를 제시했다. 변할 가능성이 있는 것을 모듈 안으로 숨기고, 변하지 않는 것만 인터페이스로 노출한다. 그러면 내부가 바뀌어도 외부(다른 모듈)가 영향을 받지 않는다.캡슐화의 두 층 — 데이터 은닉과 구현 은닉데이터 은닉은 객체의 내부 상태(필드)를 외부에서 직..
-
Software Architecture/PrinciplesPrinciples - 04. 의존성 규칙
부장이 말단 사원에게 의존하면 조직이 뒤집힌다 — 의존성 규칙조직도를 그린다고 하자. 사장이 부장에게 지시하고, 부장이 대리에게, 대리가 사원에게. 화살표는 위에서 아래로 향한다. 만약 사원이 "제가 이 방식으로 하겠습니다"라고 바꾸면 사장의 업무가 영향을 받는다면, 조직이 뒤집힌 것이다 — 말단이 최상위를 좌지우지하면 안 된다.소프트웨어도 같다. 도메인(최상위)이 데이터베이스(최하위)에 의존하면, DB를 바꿀 때 도메인이 흔들린다. 의존성 규칙은 "의존성은 항상 안쪽(고수준)으로만 향해야 한다"고 말한다 — 인프라가 도메인에 맞추지, 도메인이 인프라에 맞추지 않는다.의존성 역전 — 화살표를 돌려세운다도메인이 DB를 직접 쓰면, 의존성이 도메인 → DB로 향한다. DB를 바꾸면 도메인이 깨진다. 의존성 ..
-
Software Architecture/PrinciplesPrinciples - 03. 패러다임의 함의
걷기, 운전, 기차 — 세 패러다임이 사고를 제약하는 법목적지에 가는 방법은 세 가지가 있다. 걸어간다(절차형) — 순서대로 한 발씩, 경로를 직접 결정한다. 운전한다(객체지향) — 자동차라는 상태(속도·연료)와 행동(가속·제동)이 함께하는 도구를 조종한다. 기차를 탄다(함수형) — 정해진 선로 위를 달리며, 내가 조종하지 않고 정해진 역에서 내린다.세 방법은 이동이라는 같은 목표를 이루지만, 사고 방식이 다르다. 걷기는 절차(순서)에 집중하고, 운전은 객체(상태+행동)에 집중하며, 기차는 함수(입력→출력, 상태 없음)에 집중한다. 프로그래밍 패러다임도 같다 — 절차형·객체지향·함수형은 같은 문제를 다른 사고로 푼다.절차형 — 순서가 곧 프로그램절차형(procedural)은 데이터와 함수가 분리되어 있다..
-
Software Architecture/PrinciplesPrinciples - 02. 추상화와 깊은 모듈
변속기는 "기어 1~6"만 보여준다 — 깊은 모듈과 얕은 모듈자동차 변속기를 생각해 보자. 운전자에게 보이는 인터페이스는 기어 레버 — "1단에서 6단으로 옮긴다"가 전부다. 하지만 그 레버 뒤에는 수백 개의 톱니바퀴와 유압 시스템과 센서가 얽혀 있다. 운전자는 내부를 몰라도 운전할 수 있고, 변속기 제조사가 내부를 개선해도 운전자는 기어 레버만 보면 된다.이것이 깊은 모듈(deep module)이다 — 인터페이스는 단순하지만 구현은 풍부하다. John Ousterhout은 에서 모듈의 깊이를 "인터페이스의 복잡성 대 구현의 복잡성" 비율로 정의했다. 깊은 모듈은 적은 인터페이스(노출)로 많은 구현(숨김)을 감싼다. 얕은 모듈은 그 반대다 — 인터페이스가 복잡한데 구현이 얄팩하다.깊은 모듈 vs 얕은 모..
-
Software Architecture/PrinciplesPrinciples - 01. SOLID 원칙
주방에 요리사가 한 명일 때 문제가 생긴다 — SOLID 다섯 원칙레스토랑 주방을 상상해 보자. 한 요리사가 그릴·샐러드·디저트를 전부 담당한다. 그릴이 늦어지면 디저트도 밀리고, 샐러드 레시피를 바꾸면 그릴 타이밍도 흐트러진다. 이 요리사에게 "한 가지 역할만 하라"고 하는 것이 SRP다. 반대로, 새 메뉴를 추가할 때 기존 레시피를 다시 써야 한다면 주방 구조가 문제인 것이다 — 이게 OCP가 다루는 영역이다.Robert C. Martin이 에서 정리한 SOLID는 다섯 개의 설계 원칙이다. 각 원칙은 독립된 "건강 지표"처럼, 어느 것이 빨간불인지를 보면 설계의 어디가 아픈지 진단할 수 있다. 다섯을 동시에 완벽히 지킬 필요는 없지만, 어느 것을 어기고 있는지 아는 것이 설계 개선의 출발점이다.이 ..