tag · 25 posts

#architecture

부록: 조직 경계와 콘웨이의 법칙 - 디자인 패턴, 시스템 수준 편 ep.14
  • series
  • develop
  • design
  • architecture
  • system-design
  • organization
  • conway-law
  • design-system
  • governance

부록: 조직 경계와 콘웨이의 법칙 - 디자인 패턴, 시스템 수준 편 ep.14

콘웨이의 법칙과 역콘웨이 기동, 팀 토폴로지의 네 유형을 정리하고 디자인 시스템 거버넌스 세 모델을 비교합니다. 기술 부채의 소유권, 문서가 코드가 되는 지점, 그리고 제품 경계와 시스템 경계가 어긋날 때 벌어지는 일을 함께 봅니다.

read →
배포 경계와 마이크로 프론트엔드 - 디자인 패턴, 시스템 수준 편 ep.11
  • series
  • develop
  • frontend
  • devops
  • architecture
  • system-design
  • typescript
  • micro-frontend
  • feature-flag
  • deployment

배포 경계와 마이크로 프론트엔드 - 디자인 패턴, 시스템 수준 편 ep.11

모놀리스에서 마이크로서비스까지의 스펙트럼을 비용 관점으로 정리하고, Module Federation과 코드 스플리팅, feature flag의 수명 주기를 다룹니다. 한 화면에 두 버전의 디자인 시스템이 섞이는 순간과 점진 롤아웃의 UX를 함께 봅니다.

read →
변경 경계와 Strangler Fig - 디자인 패턴, 시스템 수준 편 ep.12
  • series
  • develop
  • backend
  • frontend
  • architecture
  • system-design
  • typescript
  • migration
  • versioning
  • design-system

변경 경계와 Strangler Fig - 디자인 패턴, 시스템 수준 편 ep.12

Strangler Fig로 오래된 시스템을 점진적으로 교체하는 방법과 Expand-Contract로 스키마를 무중단 변경하는 순서를 정리합니다. API 버저닝의 비용과 디자인 시스템 v1에서 v2로 넘어가는 deprecation 정책, 릴리스 노트가 곧 계약서인 이유를 함께 봅니다.

read →
관측 경계와 분산 추적 - 디자인 패턴, 시스템 수준 편 ep.13
  • series
  • develop
  • backend
  • frontend
  • devops
  • architecture
  • system-design
  • typescript
  • observability
  • opentelemetry

관측 경계와 분산 추적 - 디자인 패턴, 시스템 수준 편 ep.13

로그·메트릭·트레이스의 역할을 나누고 correlation ID가 경계를 넘는 방법과 OpenTelemetry, SLI·SLO를 정리합니다. Error Boundary가 놓치는 것과 RUM, 그리고 사용자에게 보여줄 에러 ID의 설계를 함께 봅니다.

read →
상태의 경계와 서버 상태 분리 - 디자인 패턴, 시스템 수준 편 ep.07
  • series
  • develop
  • frontend
  • backend
  • architecture
  • system-design
  • typescript
  • state-management
  • cqrs
  • url-state

상태의 경계와 서버 상태 분리 - 디자인 패턴, 시스템 수준 편 ep.07

상태를 둘 수 있는 여섯 위치를 비교하고 서버 상태와 클라이언트 상태를 가르는 기준을 세웁니다. CQRS와 Repository를 TypeScript로 정리하고, URL이 상태를 가질 때 얻는 공유·뒤로가기·새로고침을 함께 봅니다.

read →
캐시 경계와 무효화 전략 - 디자인 패턴, 시스템 수준 편 ep.08
  • series
  • develop
  • frontend
  • backend
  • infra
  • architecture
  • system-design
  • typescript
  • caching
  • http

캐시 경계와 무효화 전략 - 디자인 패턴, 시스템 수준 편 ep.08

CDN부터 메모리까지 다섯 계층의 캐시를 짚고 TTL·태그·이벤트 기반 무효화를 비교합니다. stale-while-revalidate와 캐시 스탬피드를 TypeScript로 정리하고, 낡은 데이터를 숨기지 않고 드러내는 UI 패턴을 함께 봅니다.

read →
일관성 경계와 Saga 패턴 - 디자인 패턴, 시스템 수준 편 ep.09
  • series
  • develop
  • backend
  • frontend
  • architecture
  • system-design
  • typescript
  • saga
  • transaction
  • eventual-consistency

일관성 경계와 Saga 패턴 - 디자인 패턴, 시스템 수준 편 ep.09

트랜잭션이 닿는 범위와 닿지 않는 범위를 나누고, Saga의 보상 트랜잭션과 Event Sourcing, 최종 일관성을 TypeScript로 정리합니다. 부분 실패 상태를 사용자에게 어떤 문장으로 알릴 것인가, 되돌릴 지점을 어디에 둘 것인가를 함께 봅니다.

read →
신뢰 경계와 검증의 위치 - 디자인 패턴, 시스템 수준 편 ep.10
  • series
  • develop
  • backend
  • frontend
  • security
  • architecture
  • system-design
  • typescript
  • authorization
  • authentication

신뢰 경계와 검증의 위치 - 디자인 패턴, 시스템 수준 편 ep.10

인증과 인가를 분리하고 서버 권위 원칙과 최소 권한을 정리합니다. 토큰 저장 위치의 트레이드오프를 비교하고, 숨김과 비활성화의 차이, 에러 메시지가 흘리면 안 되는 정보, 위험한 행동 앞의 마찰 설계를 함께 봅니다.

read →
실행 경계와 렌더링 전략 - 디자인 패턴, 시스템 수준 편 ep.04
  • series
  • develop
  • frontend
  • architecture
  • system-design
  • typescript
  • rendering
  • ssr
  • rsc
  • bff

실행 경계와 렌더링 전략 - 디자인 패턴, 시스템 수준 편 ep.04

빌드 타임과 런타임, 서버와 클라이언트라는 두 축으로 실행 지점의 사분면을 그리고 SSG·ISR·SSR·CSR·RSC·Islands의 좌표를 정리합니다. hydration 비용과 BFF를 짚고, 스켈레톤 UI와 레이아웃 시프트가 이 경계의 산물임을 함께 봅니다.

read →
네트워크 경계와 회복 탄력성 - 디자인 패턴, 시스템 수준 편 ep.05
  • series
  • develop
  • frontend
  • backend
  • architecture
  • system-design
  • typescript
  • resilience
  • circuit-breaker
  • error-handling

네트워크 경계와 회복 탄력성 - 디자인 패턴, 시스템 수준 편 ep.05

Timeout, Retry, Circuit Breaker, Bulkhead, Fallback을 TypeScript로 정리하고 워터폴과 병렬 페칭의 차이를 짚습니다. 로딩·에러·빈 상태 3종 세트와 재시도 버튼의 정직함, 낙관적 업데이트의 롤백을 사용자에게 어떻게 알릴 것인가를 함께 봅니다.

read →
시간의 경계와 이벤트 기반 처리 - 디자인 패턴, 시스템 수준 편 ep.06
  • series
  • develop
  • backend
  • frontend
  • architecture
  • system-design
  • typescript
  • event-driven
  • message-queue
  • idempotency

시간의 경계와 이벤트 기반 처리 - 디자인 패턴, 시스템 수준 편 ep.06

동기와 비동기의 경계를 시간축에서 정리하고 메시지 큐, Pub/Sub, Outbox 패턴, at-least-once와 멱등성을 TypeScript로 다룹니다. 디바운스와 오프라인 큐를 짚고, "완료했습니다"라고 말했지만 큐에 넣은 것뿐인 상황을 정직하게 쓰는 방법을 함께 봅니다.

read →
시스템의 형태는 경계가 결정한다 - 디자인 패턴, 시스템 수준 편 ep.00
  • series
  • cover
  • develop
  • frontend
  • backend
  • architecture
  • system-design
  • typescript
  • boundaries

시스템의 형태는 경계가 결정한다 - 디자인 패턴, 시스템 수준 편 ep.00

객체 하나의 책임 위 층위에서 우리가 실제로 결정하는 것은 경계입니다. 이 시리즈는 코드·실행·데이터·수명이라는 네 층위에서 열세 개의 경계를 다루고, 각 경계에 이미 붙어 있는 패턴의 이름과 그 경계가 화면에 드러나는 자리를 함께 봅니다.

read →
모듈 경계와 폴더 구조 전략 - 디자인 패턴, 시스템 수준 편 ep.01
  • series
  • develop
  • frontend
  • backend
  • architecture
  • system-design
  • typescript
  • modularity
  • design-system

모듈 경계와 폴더 구조 전략 - 디자인 패턴, 시스템 수준 편 ep.01

응집도와 결합도를 기준으로 Package by Layer와 Package by Feature를 비교하고, 배럴 파일과 순환 참조, 모듈 경계와 번들 청크 경계의 불일치를 짚습니다. 같은 결정이 디자인 시스템과 프로덕트 사이의 선을 긋는 일에서 어떻게 다시 나타나는지를 함께 봅니다.

read →
의존 방향과 헥사고날 아키텍처(Hexagonal Architecture) - 디자인 패턴, 시스템 수준 편 ep.02
  • series
  • develop
  • frontend
  • backend
  • architecture
  • system-design
  • typescript
  • hexagonal-architecture
  • dependency-inversion
  • design-tokens

의존 방향과 헥사고날 아키텍처(Hexagonal Architecture) - 디자인 패턴, 시스템 수준 편 ep.02

의존성 역전 원칙과 Ports and Adapters 구조를 TypeScript로 정리하고, 프론트엔드에서 컴포넌트가 API 스키마를 직접 아는 문제를 짚습니다. 같은 결정이 디자인 토큰의 단방향 흐름(토큰에서 컴포넌트로, 컴포넌트에서 화면으로)에서 어떻게 다시 나타나는지를 함께 봅니다.

read →
계약 경계와 런타임 타입 검증 - 디자인 패턴, 시스템 수준 편 ep.03
  • series
  • develop
  • frontend
  • backend
  • architecture
  • system-design
  • typescript
  • zod
  • schema
  • design-system

계약 경계와 런타임 타입 검증 - 디자인 패턴, 시스템 수준 편 ep.03

타입 소거와 as 단언의 위험을 짚고, Parse don't validate 원칙과 zod 기반 파싱을 TypeScript로 정리합니다. 스키마 우선과 코드 우선, codegen과 tRPC가 실제로 보장하는 것을 구분하고, 컴포넌트 계약과 headless·slot 확장점 설계, 디자인 토큰 계약까지 함께 봅니다.

read →
아키텍처 정의서는 왜 화석이 되거나 거짓말이 되는가 - 두 개의 아키텍처 정의서 ep.00
  • series
  • cover
  • develop
  • backend
  • frontend
  • infra
  • architecture
  • documentation
  • c4
  • adr

아키텍처 정의서는 왜 화석이 되거나 거짓말이 되는가 - 두 개의 아키텍처 정의서 ep.00

같은 시스템을 내부 공유용과 SI 납품용, 두 개의 정의서로 나란히 작성하며 비교하는 시리즈입니다. 첫 편에서는 아키텍처 문서가 실패하는 두 가지 방식을 정의하고, 시리즈 전체가 사용할 샘플 시스템을 소개합니다. 이 시리즈가 끝나면 자신만의 정의서를 설계할 기준틀을 갖게 됩니다.

read →
아키텍처 문서의 표준 지형도 - 두 개의 아키텍처 정의서 ep.01
  • series
  • develop
  • backend
  • frontend
  • infra
  • architecture
  • documentation
  • c4
  • adr
  • arc42

아키텍처 문서의 표준 지형도 - 두 개의 아키텍처 정의서 ep.01

아키텍처 문서를 다루는 네 가지 표준 도구를 정리합니다. ISO/IEC/IEEE 42010은 문서가 답해야 할 질문의 틀을, arc42는 문서의 골격을, C4는 다이어그램을 그리는 법을, ADR은 결정의 기록 형식을 정합니다. 같은 도구를 내부용과 납품용이 어떻게 다르게 쓰는지도 함께 봅니다.

read →
요구사항에서 시작하기: 품질 속성과 드라이버 - 두 개의 아키텍처 정의서 ep.02
  • series
  • develop
  • backend
  • frontend
  • infra
  • architecture
  • documentation
  • quality-attributes

요구사항에서 시작하기: 품질 속성과 드라이버 - 두 개의 아키텍처 정의서 ep.02

기능 요구사항은 거의 어떤 구조로도 만족됩니다. 구조를 가르는 것은 가용성·성능·보안 같은 품질 속성과 제약입니다. 이 편에서는 품질 속성을 시나리오로 표현하는 법을 익히고, 스폿의 드라이버 여섯 가지를 도출한 뒤, 그것이 어떻게 설계 결정으로 이어지는지 추적합니다.

read →
뷰를 그리다: C4와 4+1 - 두 개의 아키텍처 정의서 ep.03
  • series
  • develop
  • backend
  • frontend
  • infra
  • architecture
  • documentation
  • c4
  • diagram

뷰를 그리다: C4와 4+1 - 두 개의 아키텍처 정의서 ep.03

하나의 시스템을 여러 관점으로 나눠 그리는 법을 다룹니다. 4+1 뷰 모델로 누가 무엇을 보는지 가르고, C4의 컨테이너 뷰로 스폿의 구조를, 런타임 뷰로 동기와 비동기 두 경로가 갈라지는 순간을, 배포 뷰로 코드가 어디서 도는지를 그립니다. 같은 그림을 두 문서가 어떻게 다르게 싣는지도 비교합니다.

read →
결정을 남기다: ADR - 두 개의 아키텍처 정의서 ep.04
  • series
  • develop
  • backend
  • frontend
  • infra
  • architecture
  • documentation
  • adr
  • decision-record

결정을 남기다: ADR - 두 개의 아키텍처 정의서 ep.04

ADR은 하나의 설계 결정을 맥락·결정·대안·결과로 남기는 형식입니다. 스폿의 여섯 가지 결정을 ADR로 적고, 결정에도 상태와 수명이 있다는 점을 상태 머신으로 봅니다. 같은 ADR이 내부용에서는 살아있는 로그로, 납품용에서는 요구사항에 매핑되는 목록으로 갈라지는 지점도 다룹니다.

read →
흩어진 정책을 모으다: 횡단 관심사 - 두 개의 아키텍처 정의서 ep.05
  • series
  • develop
  • backend
  • frontend
  • infra
  • architecture
  • documentation
  • security
  • observability

흩어진 정책을 모으다: 횡단 관심사 - 두 개의 아키텍처 정의서 ep.05

횡단 관심사는 여러 컴포넌트에 걸치는 정책입니다. 한 곳에 모아 두지 않으면 컴포넌트마다 다르게 구현되고 어딘가에서는 빠집니다. 이 편에서는 스폿의 여섯 가지 횡단 관심사를 관심사와 컴포넌트의 매트릭스로 정리하고, 같은 외부 의존이라도 동기와 비동기 경로에서 에러 전략이 어떻게 갈라지는지 봅니다.

read →
내부 공유용 정의서: 거짓말하지 않는 문서 만들기 - 두 개의 아키텍처 정의서 ep.06
  • series
  • develop
  • backend
  • frontend
  • infra
  • devops
  • architecture
  • documentation
  • adr

내부 공유용 정의서: 거짓말하지 않는 문서 만들기 - 두 개의 아키텍처 정의서 ep.06

지금까지 모은 재료로 내부 공유용 정의서를 완성합니다. 핵심 과제는 두 번째 죽음, 거짓말을 막는 것입니다. 거짓말이 자라는 메커니즘을 짚고, 천천히 변하는 것만 직접 쓰기·다이어그램을 코드로 그리기·결정을 쌓기·검증을 자동화하기라는 네 원칙으로 거짓말할 수 없는 구조를 만듭니다.

read →
SI 납품용으로 변환하기: 화석을 인정하는 문서 만들기 - 두 개의 아키텍처 정의서 ep.07
  • series
  • develop
  • backend
  • infra
  • devops
  • architecture
  • documentation
  • adr

SI 납품용으로 변환하기: 화석을 인정하는 문서 만들기 - 두 개의 아키텍처 정의서 ep.07

살아 있던 내부용 정의서를 SI 납품용으로 변환합니다. 납품용은 살릴 수 없는 문서, 곧 화석입니다. 요구사항 추적표를 채우고, 버전과 승인 이력을 붙이고, 특정 시점에 박제합니다. 공공 SI의 감리·검수 맥락을 짚고, 인수인계를 통해 화석이 유지보수팀의 살아있는 문서로 다시 태어나는 흐름까지 그리며 시리즈를 닫습니다.

read →
왜 이렇게 만들었는가: 아키텍처와 개념 설명 - 개발자를 위한 기술문서 입문 ep.05
  • series
  • develop
  • frontend
  • backend
  • infra
  • devops
  • ai
  • explanation
  • architecture
  • c4-model
  • diagram

왜 이렇게 만들었는가: 아키텍처와 개념 설명 - 개발자를 위한 기술문서 입문 ep.05

익스플레네이션은 왜의 글입니다. 결정의 배경, 다른 길과의 비교, 트레이드오프를 다룹니다. 이번 편은 C4 모델로 줌 레벨을 잡고, 여섯 가지 대표 다이어그램의 쓰임을 정리한 뒤, 설명문이 자주 빠지는 두 함정(묘사와 변호)을 짚습니다.

read →
의사결정의 기록: ADR과 RFC - 개발자를 위한 기술문서 입문 ep.06
  • series
  • develop
  • frontend
  • backend
  • infra
  • devops
  • ai
  • adr
  • rfc
  • decision-record
  • architecture

의사결정의 기록: ADR과 RFC - 개발자를 위한 기술문서 입문 ep.06

팀의 큰 결정은 어딘가에 적혀야 합니다. 결정 *전*의 글은 RFC, 결정 *후*의 글은 ADR입니다. 둘은 같은 주제를 다루지만 톤·구조·수명이 다릅니다. 이번 편은 ADR과 RFC의 위치 차이, 각자의 템플릿, 그리고 ADR의 상태 머신을 다룹니다.

read →