N° 01 — 목록
'foundations' (8)
-
Architecture & Design/Software ArchitectureFoundations - 08. 아키텍처 특성의 측정
"건강하다"는 말로는 병을 못 고친다 — 아키텍처 특성의 측정건강검진을 받는다고 하자. 의사에게 "건강하세요?"라고 물으면 아무것도 진단할 수 없다. "네, 좀 피곤한데요"라는 대답으로는 혈압이 높은지, 콜레스테롤이 쌓였는지, 간 기능이 떨어졌는지 알 수 없다. 건강을 관리하려면 수치가 필요하다 — 혈압 120/80, 콜레스테롤 180, 간수치(GOT/GPT) 정상 범위. 수치가 있어야 추세를 보고, 개입 시점을 정하고, 치료가 효과가 있는지 판정한다.소프트웨어 아키텍처도 같다. "이 시스템은 확장성이 좋아요", "유지보수성이 떨어져요" — 이런 정성적 판단으로는 아무것도 관리할 수 없다. 확장성이 "좋다"가 아니라 "피크 트래픽 3배 시 p99 500ms 유지"로 측정되어야, 개선했는지 퇴보했는지 판정..
-
Architecture & Design/Software ArchitectureFoundations - 07. 빌드 vs 구매 vs 조달
직접 요리할까, 배달시킬까 — 빌드 vs 바이 vs 조달식당을 운영한다고 하자. 메뉴 하나를 추가할 때 세 가지 길이 있다. 첫째, 재료부터 직접 요리한다 — 시간과 솜씨가 필요하지만 내 입맛대로 완벽하게 만든다. 둘째, 완성된 음식을 배달시킨다 — 빠르고 전문가가 만들어 품질이 보장되지만, 내 입맛에 안 맞을 수 있고 가게가 문을 닫거나 가격을 올리면 선택지가 줄어든다. 셋째, 반조리 밀키트를 사서 마지막만 완성한다 — 핵심 소스는 남이 만들었지만 내가 손을 대고, 레시피를 고칠 수도 있다.소프트웨어 아키텍처에서도 같은 세 갈래가 있다. 직접 구현(build), 상용 소프트웨어·SaaS를 사서 쓰기(buy), 오픈소스를 가져와 맞춤(조달·adopt). 어느 쪽이든 무료가 아니다 — 각각 다른 종류의 비..
-
Architecture & Design/Software ArchitectureFoundations - 06. Conway's Law와 팀 토폴로지
도로가 도시를 만든다 — Conway's Law와 조직 구조도시 계획자가 도로를 어떻게 깔았느냐가 사람들의 이동 패턴을 정한다. 큰 길이 지나는 곳에 상점이 모이고, 골목길만 있는 동네는 주거로 남는다. 도로가 먼저고, 그 도로를 따라 도시 구조가 형성된다. 도로를 바꾸면 사람들의 이동이 바뀌고, 결국 도시 모양이 바뀐다.소프트웨어 조직도 비슷하다. 팀 간 소통 경로가 도로 역할을 하고, 그 소통 패턴을 따라 시스템 구조가 만들어진다. 모놀리스를 마이크로서비스로 쪼갠 팀이 1년 뒤 분산 모놀리스를 얻는 이유가 여기에 있다 — 서비스 경계를 도메인에 맞춰 나누고 각자 데이터베이스를 뒀지만, 팀 구조는 모놀리스 시절 그대로라 한 팀이 모든 서비스를 건드렸고 배포도 한꺼번에 일어났다. 도로(소통 구조)를 안 ..
-
Architecture & Design/Software ArchitectureFoundations - 05. 기술 부채와 의사결정
대출을 받아 출하한다 — 기술 부채의 본질사업자가 대출을 받아 지금 투자하면, 지금 가치를 얻는 대신 이자를 치른다. 상환 계획이 있으면 현명한 선택이고, 없으면 파산으로 이어진다. 소프트웨어에서도 비슷한 일이 벌어진다. 출시일을 맞추기 위해 결제 모듈의 카드 번호 길이 검증을 건너뛰고 코드 옆에 // TODO: 출시 후 추가를 달아둔다. "출시 후"는 오지 않는다. 6개월 뒤 한 사용자가 잘못된 카드 번호로 결제를 시도하고, 검증 없는 시스템은 그걸 승인 처리해 버린다. 환불 비용과 고객 신뢰 하락이 그 TODO 주석의 이자였다.이것이 기술 부채(technical debt)다. "나중에 고치지"로 미뤄둔 결정이 이자를 치는 현상. 이 은유는 널리 쓰이면서도 자주 오해된다 — 부채를 "나쁜 코드"와 동일..
-
Architecture & Design/Software ArchitectureFoundations - 04. 아키텍처 문서화
건축 도면이 거짓말이 되는 순간 — 아키텍처 문서화건축가가 집을 지을 때 도면을 그린다. 대지 평면도로 전체를 보고, 층별 평면도로 층을, 방 상세도로 디테일을 본다. 도면은 집을 이해하고 소통하는 도구다. 하지만 도면이 집 그 자체는 아니다. 현장에서 벽을 하나 허물고 도면을 안 고치면, 도면은 거짓말이 된다. 6개월 뒤 새 직원이 그 도면을 보고 집을 이해하려다 포기한다 — 도면 속 "거실"은 이미 침실로 바뀌어 있는데 도면엔 옛날대로 그려져 있으니까.소프트웨어 아키텍처 문서도 같다. 한때 정확했던 상자-화살표 그림이, 코드가 바뀌어도 안 고쳐지면 거짓말이 된다. 그렇다고 문서를 포기하면 결정의 이유가 사라지고 매번 같은 논쟁이 반복된다. 문제는 "문서를 쓸까 말까"가 아니라 "무엇을, 어떻게 기록하..
-
Architecture & Design/Software ArchitectureFoundations - 03. 결합과 응집
접착제로 붙인 모형은 뜯기 어렵다 — 결합과 응집아이가 접착제로 붙인 플라스틱 모형을 생각해 보자. 날개가 떨어져 다시 붙이려면 접착제를 뜯어내야 하고, 그러다 몸통이 부서진다. 한 부분을 교체하려면 전체를 해체하는 수고가 든다. 반면 레고 블록으로 만든 비행기는 날개 블록을 빼고 다른 걸 끼울 수 있다. 한 블록을 바꿔도 나머지는 그대로다.소프트웨어 모듈도 같다. 접착제로 붙인 것처럼 얽혀 있으면 한 부분을 바꿀 때 다른 부분이 부서진다. 레고처럼 분리돼 있으면 변경이 국소에 머문다. 전자를 결합도(coupling)가 높다고, 후자를 낮다고 부른다. 그리고 결합을 가늠하는 반대쪽 끝에 응집도(cohesion)가 있다 — 한 조립품 안의 블록들이 하나의 목적(예: 자동차 모형)으로 뭉쳐 있는 정도. 이 ..