TedDev

[리뷰] 일 잘하는 팀장 :IT 회사에서 살아남은 팀장의 41가지 리더십 기술 - 이재호

TedDev — Wed, 18 Feb 2026 20:00:43 +0900

매니저 역할에 대한 고민은 계속 하게 되는 것 같다.

자연히 팀장, 관리자 역할과 관련된 책에 관심이 쏠릴 수 밖에 없는데

이 책은 관리자로서 생길 수 있는 상황, 고민 등을 개별 케이스와 주제로 나열해서 솔루션이나 접근하는 방향 등을 이해하기 쉽게 정리해 놓은 책이다.

특정 상황에서 취할 수 있는 구체적인 행동이나 방법을 고민할 때 방향성을 먼저 정하고 꼭 염두에 두어야 하는 포인트 등을 확인할 수 있는 좋은 의견들이 많은 책이다.

"공감", "구성원과의 잦은 소통을 통한 탐색" 등이 언급되는데 리더로서의 본인만의 가치관이나 신념을 정립하는데도 도움이 될 것 같다.

아래는 리더의 역할에 대한 내용 위주로 정리해보았다.

리더의 역할

감독(director) : 방향(프로젝트, 구성원의 성장)을 제시하고 길을 잃지 않게 만드는 사람
관리자(manager) : 팀의 동력을 유지하고 프로젝트를 위기로부터 보호하는 사람
- 업무관리, 사람관리, 외부환경 관리
팀이 목적을 이루도록 하는 것을 우선시 해야한다
리더가 자리를 비워도 좋은 성과를 낼 수 있는 팀을 만드는 것

구성원으로부터 신뢰를 얻는 방법

구성원들과 팀과 프로젝트에 관해 많은 이야기를 나누는 것이 필요
거짓말을 하지 말아야 한다.
자신이 한 말을 행동으로 뒷받침해야 한다
가능한 숨기는 것이 없도록 노력해야 한다
평가에 대해 공정해야 한다. 그러기 위해서는 자신이 경험하지 못한 부분에 대해 이해의 폭을 넓혀야 한다.

팀의 목표를 세우는 방법

모두가 동일하게 해석할 수 있도록 구체적이고 명확하게 설정해야 한다.
팀의 목표와 조직의 목표를 연결시키고 팀의 목표가 어떻게 조직의 성과에 공헌하는지 분명하게 선언
SMART기법
- Specific(구체적), Measurable(측정가능), Achievable(달성 가능), Relevant(장기적 비전과 연결), Time-bound(기한이 정해짐)

팀워크 형성할 때 중요한 점

프로젝트가 갖는 의미와 그 안에서 각자가 수행하는 역할의 중요성을 마음속에 심어줄 필요가 있다
조직을 구성하는 구성원들이 동일한 수준의 정보를 보유할 수 있도록 신경써야 한다.
팀이 위기에 빠졌을 때도 긍정적인 분위기를 유지하기 위해 노력 필요
성공적인 결과에 관한 메시지가 팀 안에서 계속 교환되도록 하는 것이 도움된다

구성원 사이에 불화가 생겼다면

불화가 발견되었을 때는 가장 먼저 당사자의 감정에 공감해 주는 것 (마음을 진정시키는 것)
- 특히 감정적인 문제의 해결은 언제나 공감에서부터 시작한다.
사실에 기반하여 문제를 확인한다. (추론과 평가는 가급적 배제한다.)
커뮤니케이션에 각별한 주의가 필요하다

팀의 갈등을 관리하는 방법

갈등을 예방한다 - 서로 다를 수 있다는 것을 받아들이기 위해서 서로를 이해할 필요가 있다.
사람들과 대화를 많이 나누고 행동을 관찰하면서 갈등을 탐색한다
갈등을 해소할 때는 이슈와 사람을 분리하는 것이 중요 - 절대 사람이 문제가 있다는 식으로 발전하면 안된다.

팀의 생산성을 관리하는 법

가장 치명적으로 악영향을 끼치는 요소를 탐색 - 이를 위해서 구성원들과 커뮤니케이션 필요
물리적인 환경, 잦은 업무 전환, 필요하지 않은 회의 등 몰입을 방해하는 요소 제거
명확하고 구체적인 소통

구성원에게 동기부여하는 방법

각 구성원이 가진 동기를 이해한다. - 각자 중요하게 생각하는 요소 파악 필요
자신감과 심어주고 실패에 따른 두려움이 생기지 않도록 격려
적절한 보상 - 경제적인 보상 뿐만 아니라 구성원의 노력을 인정하는 상징적인 행위 (칭찬, 박수, 선물 등)

팀이 성장하려면

현재 상태를 알아야 한다 - 조직의 강점, 약점, 시장의 상황과 경쟁조건 등의 이해
성장을 위한 학습을 습관으로 만들도록 노력
새로운 것을 학습했다면 그것을 조직의 업무에 어떻게 적용할지 고민

실패를 대하는 자세

실패로부터 배우려는 행동에 보상한다
실패를 다루는 프로세스를 정비한다. - 실패 분석 담당자 지정, 히스토리 정리, 관련 사람들과 대화 등
실패에 대한 회고 내용을 모든 팀이 활용할 수 있도록 자료로 모아둔다
실패는 묻어버리면 그냥 경험이 되지만 잘 활용하면 역량이 된다.

코칭 방법

코칭에 필요한 것 : 정확한 목표, 구성원의 성장에 시간을 투자할 의지, 상호작용
코칭이 이루어졌으면 그것을 실무에서 활용할 수 있게 해준다. 그에 따른 책임과 권한을 부여한다
코칭은 성장이 목적임을 잊지 않는다 - 구성원이 얼마나 빠르게 성장하고 있는지 확인 필요

간과하지 말아야할 팀원 평가 기준

팀 분위기에 영향을 미치는 긍정적인 에너지
조율과 화합
불편한 얘기라도 솔직하게 의견을 주는 팀원 - 실수를 미연에 방지하는 기회를 얻게 됨
코드 재정리, 문서작업, 간식 주문이나 물품수령 등 누군가는 해야하는 잡일을 도맡아 해서 나머지 사람이 자기 작업에 집중할 수 있게 하는 팀원
엉뚱한 의견을 자주 제시해서 생각의 폭을 넓혀주는 팀원

성과로 이어지는 평가 방법

평가 기준이 명확하고 이해하기 쉬워야 하며 변하면 안된다.
현재 상태를 자주 확인시켜 주어야 한다
눈에 보이지 않는 성과가 확실하지 않은 작업을 정당하게 평가하려는 노력이 필요하다
부당하게 좋은 평가를 받으려는 시도를 감지해야 한다
회사가 중요하게 생각하는 가치와 연결되어 있어야 한다.

아웃박스 패턴 (Outbox Pattern)

TedDev — Sun, 14 Dec 2025 18:08:12 +0900

분산 시스템을 구축할 때 가장 어려운 문제 중 하나는 데이터베이스 상태 변경과 이벤트 메시지 발행 사이의 일관성을 유지하는 것이다. 이를 도와줄 수 있는 것이 아웃박스 패턴(Outbox Pattern)이다.

1. 아웃박스 패턴이 왜 필요할까

마이크로서비스 아키텍처에서 서비스들은 메시지 브로커(Kafka, RabbitMQ 등)를 통해 비동기적으로 통신하며 서로의 상태 변화를 전달한다.

일반적인 문제 시나리오

주문 서비스가 새 주문을 생성하는 상황을 가정해본다.

데이터베이스 업데이트 : 주문 서비스는 트랜잭션을 열고 주문 테이블에 새로운 주문 정보를 저장한다.
메시지 발행 : 주문 서비스는 메시지 브로커로 주문 생성 이벤트를 발행하려 한다.

만약 1번이 성공한 직후 네트워크 문제나 브로커 다운 등으로 메시지 발행에 실패한다면 데이터베이스에는 주문이 있지만 다른 서비스들은 이 주문 발생 사실은 알 수가 없게 된다.

아웃박스 패턴은 이 두 작업을 하나의 데이터베이스 트랜잭션 안에 묶어 이 문제를 원자적으로 해결한다.

2. 아웃박스 패턴이 구조와 동작 원리

아웃박스 테이블 (Outbox Table)

비즈니스 상태 변화와 함께 발행되어야 할 이벤트를 임시로 저장하는 테이블
비즈니스 데이터 테이블(예: Order)과 아웃박스 테이블(Outbox)에 대한 쓰기 작업은 반드시 동일한 트랜잭션 내에서 이루어져야 한다.
아웃박스 테이블 예시

필드명	타입	설명
id	UUID	고유 ID
aggregate_id	VARCHAR	이벤트가 발생한 엔티티의 ID
aggregate_type	VARCHAR	엔티티의 타입 (예: Order)
type	VARCHAR	이벤트의 타입 (예: 주문 생성)
payload	JSON	이벤트 내용
created_at	TIMESTAMP	발생일시
processed	BOOLEAN	메시지 브로커로 전송되었는지 여부

애플리케이션 서비스 (Application Service)

비즈니스 로직을 처리하고 이벤트를 생성한다
트랜잭션이 커밋되는 순간 데이터 변경과 이벤트 레코드 저장 성공이 보장된다. 만약 중간에 문제가 발생하면 둘 다 롤백된다.

BEGIN TRANSACTION;

-- 1. 비즈니스 데이터 업데이트
INSERT INTO Orders (id, user_id, status) VALUES ('123', 'userA', 'PENDING');

-- 2. 아웃박스 레코드 저장 (동일 트랜잭션 내)
INSERT INTO Outbox (aggregate_id, type, payload) 
VALUES ('123', 'OrderCreated', '{"orderId": "123", "amount": 1000}');

COMMIT;

릴레이 서비스 (Relay/Publisher Service)

아웃박스 테이블을 모니터링하고 저장된 이벤트를 메시지 브로커로 전송하는 독립적인 프로세스

구현 방식

Polling (폴링)
- 릴레이 서비스가 주기적으로 Outbox 테이블을 쿼리하여 처리되지 않은 레코드를 찾아 메시지를 발행한 뒤 해당 레코드의 상태를 True로 업데이트 한다
- 구현이 간단하지만 빈번한 쿼리로 인한 DB 부하가 발생할 수 있고 메시지 발행 지연 시간이 발생한다
Transaction Log Tailing (CDC - Change Data Capture)
- Debezium과 같은 CDC 도구를 사용하여 DB의 트랜잭션 로그(Binlog, WAL)를 실시간으로 모니터링한다. Outbox 테이블에 INSERT 작업이 감지되면 해당 레코드를 즉시 메시지 브로커로 전송한다
- 실시간에 가까운 이벤트 발행이 가능하며 DB에 추가적인 폴링 부하를 주지 않는다. 다만 별도의 CDC 도구를 도입해야 하므로 설정이 복잡해진다

3. 아웃박스 패턴의 장점과 고려 사항

아웃박스 패턴의 주요 장점

원자성 보장 : 비즈니스 상태와 이벤트 발행이 로컬 트랜잭션으로 묶여 데이터 일관성을 완벽하게 보장한다.
재시도 매커니즘 : 메시지 브로커가 다운되더라도 이벤트는 DB에 안전하게 저장되어 있으므로 브로커가 복구되면 릴레이 서비스가 전송을 재시도할 수 있다
분산 트랜잭션 회피 : 복잡하고 느린 2PC(2-Phase Commit) 방식이나 사가(Saga) 패턴의 복잡성을 로컬 트랜재션으로 단순화할 수 있다

고려 사항

결국 분산 트랜잭션은 아님 : 이 패턴은 로컬 트랜잭션의 성공을 보장할 뿐 메시지를 수신한 다른 서비스의 트랜잭션 성공까지 보장하지는 않는다. 수신 측 서비스는 멱등성(Idempotency)을 갖춰야 한다.
메시지 순서 : 발행 시간을 기준으로 순서를 보장해야 한다. (CDC 방식에서는 DB로그의 순서가 보장되므로 유리하다)
관리 복잡성 : 릴레이 서비스라는 별도의 프로세스를 운영하고 관리해야 하는 오버헤드가 추가된다.

아웃박스 패턴은 마이크로서비스 환경에서 이벤트 기반 통신의 신뢰성을 확보하기 위한 가장 강력하고 검증된 패턴 중 하나이다.

CDC 도구와 함께 사용한다면 효율성과 안정성 모두를 잡는 세련된 아키텍처를 구축할 수 있다.

[리뷰] 개발 7년차, 매니저 1일차 - 카미유 푸르니에

TedDev — Sat, 13 Dec 2025 18:39:00 +0900

최근 이직을 했다.

이직을 하면서 역할이 변경되었는데

개발자에서 엔지니어링 매니저로서 새로운 도전을 하게 된 것이다.

그런데 막상 제대로 매니저 역할을 하려니 내가 당장 무엇을 해야할지 잘 모르겠다.

전혀 감도 안오고 그래서

우선 당장 내가 해볼 수 있는 구체적이고 명확한 액션 포인트가 무엇인지에 대한 도움이 필요했다.

그래서 이 책을 읽게 되었고 지금 당장 시도해 볼 수 있는 부분이 무엇인지 위주로 읽어보았다.

사람관리

새로운 보고 체계 만들기
정기적으로 원온원 미팅하기
경력 성장, 목표 달성, 개선된 영역 및 근거 있는 칭찬 등 정기적인 피드백 하기
팀원이 학습할 영역을 찾고 프로젝트 업무, 외부 교육이나 멘토링 등을 통해 성장 돕기

팀 관리

팀 성공을 위해 개발 프로세스의 병목지점과 장애물을 찾고 이를 제거하기
가치 있는 프로젝트를 선정하여 팀이 이에 집중할 수 있도록 한다.
제품 리드와 긴밀한 협력 관계를 유지하고 프로젝트 번위를 관리하고 기술 산출물이 요구사항을 충족하도록 한다.
팀의 필요 인원을 파악하고 이를 충원할 수 있는 계획을 세우고 채용을 할 수 있어야 한다.

개발 조직의 건강도 확인법

릴리즈 빈도 : 팀이 빠르게 움직일 수 있는 상태인지 배포 프로세스를 체크한다.
코드 체크인 빈도 : 진행 중인 작업을 작은 단위로 세분화 하고 정기적으로 확인할 수 있는 환경인지 체크한다.
문제 발생 빈도 : 안정적인 시스템을 위해 문제 발생 빈도를 파악하고 이를 해결하거나 예방해야 한다. 하지만 문제 에방을 너무 강조하는 것도 팀이 낼 수 있는 생산성을 저하시키는 요인이 되므로 적절한 조절이 필요하다.

거절 전략

단순히 "아니요" 라고 하는 것보다 "네, 그리고" 전략을 쓴다. (긍정적인 거절)
- ex) "네, 그 프로젝트 할 수 있어요. 현재 로드맵의 다른 프로젝트의 시작을 늦추면 돼요"
"네" 를 끌어내기 위해 필요한 요구사항과 결정을 고민할 때 참고할 몇 가지 가이드라인을 만든다. - 원칙을 만든다.
- ex) 새로운 언어나 기술을 반영하고 싶어 하는 팀원이 있는데 현재 상황에 대해 이해를 시키고 싶을 경우
"제가 '네' 라고 말할 수 있게 도와주세요"
시간과 예산을 요청한다. 현재의 업무 부담을 쉽게 설명하고 왜 조정하기 어려운지 이해시키는 방법
아군을 만든다. 거절이 필요할 때 다른 팀의 도움을 받을 수 있다.
얼버무리지 않는다. 틀리더라도 위험도 낮고 영향력이 크지 않은 결정은 신속하게 거절한다.

매니저는 경영층이 개발 팀에게 요구하는 사항과 개발팀의 현실을 조율하고
소프트웨어 사용자의 목소리를 경청하고 채용과 비용 절감을 고민하고
소프트웨어 제품의 출시 기간을 결정하고
인사 부서와 함께 직원의 복지 문제를 논의하고
평가를 통해 연봉과 보너스 수준을 결정하고
개발자의 불만과 의견을 접수하고
개발자 문화를 어떻게 개선할지 고민하는 일을 수행한다

개발자로 일하다 보면 언젠가는 매니저 역할을 맡게 되는 순간이 온다.

하지만 대부분 매니저가 되는 과정에 대해 제대로 알려주지는 않는다.

이 책은 "개발을 잘하던 사람"이 "사람과 일, 조직을 책임지는 매니저"로 역할이 바뀌며 반드시 마주하는 관점의 변화에 집중하고 있다.

그리고 개발자에서 테크리드, 팀장, 여러 팀을 관리하는 CTO 등 각 단계별로 좋은 매니저의 모습을 설명하고 있다.

생각해보면 당연한 얘기이긴 한데 "정답", "행동"을 제시히기 보다는 매니저로서 어떤 고민을 해야하는지를 안내하는 듯하다.

약간 아쉬운 점이 있다면 후반부 조직의 규모가 커질 때의 내용이 보다 더 추상적으로 느껴지는 것 같기도 했다.

지금은 초보 매니저로서 조금 더 구체적이고 실행할 수 있는 내용이 더 담겨있었으면 했던 생각도 있었지만 분명 시간이 지나면서 생길 수 있는 고민에 도움이 될만한 내용과 노하우가 많이 담겨있는 것 같다는 느낌이었다.

앞으로 자주 이 책을 참고하면서 엔지니어링 매니저로서의 성장에 많은 고민과 노력, 시도를 하지 않을까 생각한다.

Spring Cloud Data Flow (SCDF)

TedDev — Mon, 8 Dec 2025 19:48:42 +0900

Spring Cloud Data Flow 란?

실시간 데이터 파이프라인(stream)과 배치(job)을 손쉽게 정의, 배포, 운영할 수 있게 해주는 오케스트레이션 플랫폼

즉, SCDF 자체는 데이터를 처리하지 않고 "데이터를 처리하는 마이크로 서비스들을 조합, 배포, 관리하는 관리자" 역할을 한다

핵심 구성요소

Data Flow Server
- SCDF의 두뇌 (컨트롤 플레인)
- 사용자가 정의한 Stream/Task 정보를 저장하고 "어떻게 배포할지" Skipper에 명령을 내린다
- Web Dashboard, CLI, REST API 모두 여기로 요청이 들어옴
Skipper Server
- 배포 관리자 (Deployment Manager)
  - 롤링 업데이트, Blue-Green 방식, 롤백 등을 지원
- Kubernetes, CloudFoundry, Local 등 다양한 플랫폼에 실제로 앱을 배포함
Kubernetes Cluster
- Source/Processor/Sink 앱(스트림 구성요소)이 실제 배포되는 곳
- 배포된 앱들은 Kafka(or RabbitMQ) 기반으로 서로 이벤트 전달
Message Broker (Kafka or RabbitMQ)
- Stream 앱 간의 연결 통로
- Source -> Processor -> Sink 데이터를 실시간으로 흘려보냄
- Kafka를 쓰면 대규모 스트리밍 처리에 적합함
Dashboard (UI)
- 스트림 DAG 구성
- 배포/모니터링
- 메트릭 확인(Prometheus 연동)

https://dataflow.spring.io/docs/concepts/architecture/

Stream 구조 (Source -> Processor -> Sink)

스트림은 Source, Processor, Sink 의 파이프라인으로 구성된다

Source : 외부 데이터(HTTP, MQTT, Kafka, S3 등) 수집
Processor : 데이터 변환, 필터링, ML inference 등
Sink : DB, Kafka, Elastisearch, S3 저장

배치(Task) 구조

Task는 Stream 과 달리 한 번 실행되는 Job (Spring Batch 기반)

Skipper가 Kubernetes Job으로 실행 -> 완료되면 Pod 종료

SCDF의 장점

스트림을 코드 없이 GUI로 구성
- Kafka 기반 데이터 파이프라인을 개발자 없이 운영, 데이터팀이 직접 수정 가능
롤링 업데이트 + 롤백 기본 지원
- Pipeline을 수정해도 Skipper가 안전하게 배포
Spring 생태계와 완전 호환
- Spring Cloud Stream, Spring Batch 기반 -> 기존 스프링 앱과 쉽게 통합됨
Kubernetes 네이티브 실행
- HPA
- Prometheus/Grafana 메트릭
- ConfigMap + Secret 관리
- Blue/Green Deployment
운영 안정성
- Kafka 장애 감지, retry, DLQ 등 운영 기능 내장

모듈러 모놀리식 아키텍처 (Modular Monolithic Architecture)

TedDev — Sat, 6 Dec 2025 23:09:36 +0900

모듈러 모놀리식 아키텍처는 전통적인 모놀리식 아키텍처의 강점을 유지하면서 마이크로서비스의 모듈화 원칙을 적용한 아키텍처이다.

핵심 개념

단일 배포 단위 + 높은 모듈화

애플리케이션은 하나의 프로세스로 배포되지만 내부적으로는 명확히 분리된 모듈들로 구성된다.
각 모듈은 독립적인 도메인 책임을 가지며 명확한 인터페이스를 통해서만 통신한다.

주요 특정

강한 모듈 경계
- 각 모듈은 자체 데이터베이스 스키마나 테이블을 가질 수 있다
- 다른 모듈의 내부 구현에 직접 접근할 수 없다
- 공개 API/인터페이스를 통해서만 상호작용한다
독립적인 개발
- 각 모듈은 독립적인 팀이 담당할 수 있다
- 모듈 내부 변경이 다른 모듈에 영향을 주지 않는다
- 단, 공개 인터페이스 변경 시에는 조율이 필요하다
단순한 운영
- 단일 배포로 전체 시스템이 업데이트 된다
- 분산 시스템의 복잡성(네트워크 지연, 장애 처리 등)이 없다
- 트랜잭션 관리가 단순하다

예시

모듈 간 통신 패턴

각 모듈의 공개된 인터페이스 호출
이벤트 기반 통신

장점

개발 단순성 : 마이크로서비스보다 훨씬 단순하다
운영 용이성 : 배포, 모니터링, 디버깅이 쉽다
성능 : 네트워크 오버헤드가 없고 트랜잭션 처리가 단순하다
점진적 진화 : 필요시 특정 모듈을 마이크로서비스로 분리할 수 있다
낮은 인프라 비용 : 단일 서버로 시작 가능하다

단점

확장성 제약 : 전체를 함께 스케일링 해야 한다
배포 결합도 : 한 모듈의 변경이 전체 재배포를 요구한다
기술 스택 제약 : 모든 모듈이 같은 언어/프레임워크를 사용해야 한다

언제 사용하는 것이 좋을까

적합한 경우

중소규모의 팀과 서비스
명확한 도메인 경계가 있는 애플리케이션
마이크로서비스의 복잡성을 감당하기 어려운 경우
빠른 개발과 배포가 필요한 스타트업

부적합한 경우

매우 큰 규모의 독립적인 팀들
모듈별로 극단적으로 다른 확장 요구사항
다양한 기술 스택이 필수적인 경우

모듈러 모놀리식은 많은 기업들이 마이크로서비스 전환하기 전 또는 대안으로 채택하고 있는 실용적인 아키텍처 이다

[리뷰] 운명을 바꾸는 말하기 수업 - 이영선

TedDev — Sat, 15 Nov 2025 06:54:21 +0900

말하기, 커뮤니케이션, 프레젠테이션 등 AI시대가 도래함에 따라 이 스킬들은 굉장히 중요한 부분이 되어가는 것 같다.

따라서 말하는 방법에 대해 도움될 수 있는 어떤 중요한 포인트나 테크닉이 있을지 관심을 가지게 되는 것 같다

이 책은 말하기나 프레젠테이션에서 간단하게 적용해 볼 수 있는 기술들을 소개하면서

말하기를 할 때의 마음가짐이나 태도에 대해서도 많이 언급하고 있다.

"완벽하지 않아도 괜찮다"

말하기를 할 때 가장 어렵게 하는 부분이 완벽주의 때문이라는데 이 부분이 공감이 되었다.

남의 시선이나 평가 이런 것들을 두려워 하기 보다 스스로를 믿는 것이 가장 중요한 부분임이 맞는 것 같다. (사실 쉽지 않긴 하다)

아래는 책에서 소개한 말하기에서 간단하게 적용해볼 수 있는 팁에 대해 간략하게 정리해 보았다

자기소개 : 현재-과거-미래 순서로 간결하고 명확하게
면접 : 질문에 답변할 때에는 STAR(Situation - Task - Action - Result) 기술을 이용
스피치 : 스크립트를 통째로 외우기 보다는 '키워드' 로 생각과 흐름을 정리
피드백 : PIP(Positive-Improvement-Positive) 피드백을 사용. 잘한 부분을 언급하고 보완점을 제시, 이후 독려
협상 : 상대방의 이익도 함께 고려해야하는 것
프레젠테이션
- 오프닝 : 인용구, 간단한 일화, 질문으로 시작하면 청중의 관심, 이목, 상호작용을 높여주는 효과가 있다.
- 두괄식 말하기는 다소 복잡한 주제를 전할 때 효과적
- 주장을 논리적으로 만들기 위해서는 사실에 기반한 근거가 필요
- 어려운 용어는 이해하기 쉬운 표현으로
- MECE (Mutually Exclusive, Collectively Exhausted) 범주화된 내용이 겹치지 않으면서 큰 주제를 모두 포괄하고 있는지

스피치는 우월함을 뽐내는 도구가 아니라
자신의 이야기를 사람들과 공감하고 연결하기 위해
세상에 꺼내는 용기와 자기다움의 과정

말하기의 본질에 대해 다시 보게 해주는 책이다. 자기다운 말하기, 내 생각, 내 이야기를 전달하는 것 임을 잊지말라고 한다.

실생활에 간단하게 적용 가능한 내용도 많아서 한번 읽어보고 연습해보는 것도 좋을 것 같다.

[Architecture] 애플리케이션 기반 구현

TedDev — Sun, 26 Oct 2025 18:17:54 +0900

애플리케이션 기반 공통 기능

애플리케이션 기반에 공통적으로 필요한 기능

인증 : 사용자를 식별하고 시스템을 정상적으로 이용할 수 있는 사용자인지 확인
인가 : 사용자에게 시스템 리소스에 대한 접근 권한 부여
세션 관리 : 사용자별 상태 관리
오류 처리 : 시스템에서 발생한 오류를 적절히 제어하고 사용자에게 알림을 제공
로깅 : 사용자의 조작과 시스템 처리 상황을 등을 로그로 남김
보안 : 크로스 사이트 스크립틍(XSS), 크로스 사이트 요청 위조(CSRF) 등의 보안 조치
트랜잭션 제어 : 주로 데이터베이스와 같은 시스팀 자원의 무결성과 일관성을 유지
데이터베이스 접근 : 데이터베이스에 대한 접근 수단 제공
국제화 : 사용자의 Locale에 따라 언어와 데이터 형식 전환
문서 출력 : PDF 등의 형식으로 정형화된 문서 출력
캐시 관리 : 취득한 데이터를 메모리에 저장하여 관린
비동기 처리 : 시간이 많이 걸리는 처리를 백그라운드에서 실행하여 사용자가 기다리지 않도록 비동기적 수행

인증

접속한 사용자가 시스템을 정상적으로 이용할 수 있는 사용자인지 확인하는 과정

일반적으로 사용자ID와 비밀번호의 일치 여부를 확인하여 인증 수행. 과거에는 개별 시스템의 데이터베이스에서 사용자ID와 비밀번호를 관리하여 시스템 내에서 인증하는 방식이 주류였음

최근에는 IDP(Identity Provider)를 활용하여 인증 수행을 많이 함

IDP 활용 장점

사용자 인증 정보를 중앙에서 통합 관리 가능. 유지보수 부담 감소
사용자 비밀번호를 관리하지 않아 보안이 강화
MFA를 쉽게 구현하여 보안 강화 가능
SSO를 통해 한 번의 로그인으로 다중 서비스 이용이 가능해 사용자 편의성 향상

보안 관련 기능은 표준 방식이나 모범 사례를 따르는 것이 안전하다. 다양한 인증 수단을 지원하는 프레인워크나 라이브러리가 존재하므로 충분한 조사 및 검증 진행 필요. (Spring 에서는 Spring Security를 통해 SAML, OpenID Connect 등을 이용할 수 있음)

인증 관련 구현해야할 공통 기능들

로그인 화면 : 인증 정보를 인력하여 로그인하는 화면
인증 : 데이터베이스에 저장된 비밀번호 정보를 이용한 인증, IDP와 연계한 인증 등 사용자 인증 처리, 인증 성공 시 세션 정보에 인증 상태 저장/유지
인증 상태 확인 : 인증된 상태에서 특정 엔드포인트에 접근할 때, 세션의 인증 상태를 확인하는 처리. 미인증 상태일 경우 로그인화면으로 리다이렉트
로그아웃 : 사용자의 인증 상태와 세션 정보를 함께 삭제
인증 방식 전환 : 설정에 따라 여러 인증 방식을 유연하게 전환할 수 있도록 설계된 구조
기타 : 비밀번호 기반 인증 방식일 경우 비밀번호 잠금(로그인 실패 횟수 초과 시 계정 잠금), 비밀번호 재설정, 비밀번호 리마인더 등 추가 기능 필요

인가

사용자가 시스템 내 리소스에 접근할 수 있도록 권한을 부여하는 과정

역할 기반 접근 제어(RBAC)를 따르는 것이 기본 원칙. 사용자 개별적으로 권한을 부여하는 것이 아니라 역할에 권한을 부여하고 그 역할을 사용자에게 할당.

접근 권한 제어 리소스 예시

기능, 화면 : 특정 기능과 화면에 대한 접근 제어
기능 실행 수준 : 역할에 따라 기능에서 수행할 수 있는 작업을 조정 (ADMIN 역할은 데이터 등록/수정, 다른 역할은 조회만 가능)
화면 항목 : 특정 역할만 볼 수 있도록 화면의 일부 항목을 제어
데이터 : 역할에 따라 데이터 열람 가능 범위를 조정

접근 제어 구현 방식

URL 기반 접근 제어

// SecurityConfig.java
@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
	
    http.authorizeHttpRequests(it -> 
    	it.requestMatchers("/admin").hasRole("ADMIN").anyRequest().permitAll()
    )
    .formLogin(Customizer.withDefaults())
    .exceptionHandling(it -> it.accessDeniedPage("/access-denied"));
    
    return http.build();
}

엔드포인트 단위 접근 제어

//SampleController.java
@PreAuthorize("hasAnyRole('ADMIN', 'EMPLOYEE')")
@GetMapping("/hello")
public String hello(Model model) {
    model.addAttribute("greeting", "Hello");
    return "hello";
}

승인된 API 활용

<body>
    <h1 th:text="${greeting}">Hi</h1>
    <div sec:authorize="hasRole('ADMIN')">
    	<p>이 메시지는 관리자만 볼 수 있습니다.</p>
    </div>
</body>

독자적인 공통 기능 구현

세션 관리

세션은 사용자와 애플리케이션 간의 일련의 상호 작용을 의미

HTTP는 무상태 특성이 있기 때문에 데이터베이스에 영구 저장되기 전의 처리 중인 상태는 세션 정보에 일시적 저장된다.

일반적으로 사용자마다 고유한 세션ID는 클라이언트 측에서 유지하며 세션 정보는 서버 측에서 관리한다.

세션의 생성, 종료, 저장/조회는 프레임워크에서 표준적으로 제공하는 매커니즘을 활용

고려해야할 사항

1. 공통 정보에 대한 접근

인증이후 인증 상태 확인 및 인가 검사를 위해 사용자 ID, 역할 등의 정보가 세션 정보에 저장된다.

사용자 속성 정보(이름, 이메일 등)는 자주 참조되므로 인증 시점에 미리 가져와 세션에 보관해 두는 것이 일반적이다.

애플리케이션 기능에서 이런 정보들을 사용할 때는 세션 키로 직접 참조할 수도 있지만 공통 정보에 접근할 수 있는 API를 준비해서 제공하는 것이 편리하다

2. 세션 객체 분리

세션은 사용자 단위로 시작되지만 엄밀히 클라이언트 접속 단위이기 때문에 브라우저를 여러 개 실행하면 각각 별도의 세션이 생성됨. 따라서 아래와 같은 문제 발생 여지가 있음

여러 기능에서 세션 키가 중복되면 예상치 못한 동작 발생 가능성 있음
세션 객체는 로그아웃, 타임아웃이 발생할 때 삭제되므로 기능이 늘어날수록 세션 객체의 크기가 커져 메모리 부담이 커질 수 있음
브라우저에서 여러 탭을 열어 기능을 실행하면 세션 정보 충돌로 인해 예상치 못한 동작이 발생할 수 있음

따라서, 세션 객체의 논리적으로 구획하여 관리가 필요

오류 처리

애플리케이션 사용 중 오류가 발생하면 사용자 또는 관리자에게 해당 내용을 알리고 적절하게 복구할 수 있도록 해야한다.

아래는 오류 수준별 분류 및 수립할 수 있는 알림 정책을 나타낸다.

오류 수준	설명	예시	알림
보통	- 사용자의 정상적인 사용 중 발생할 수 있는 오류 - 사용자가 직접 복구 가능	- 주문 확정 시 재고 부족 - 신용카드 한도 초과	- 사용자 : 해당 기능 화면에 오류 메시지 표시
중요	- 자주 발생하지 않지만 시스템 이용에 있어 예상 가능한 오류 - 서비스 운영 담당자의 복구 조치 필요	- 특정 지점의 캘린더 등록 누락 - 워크플로우 경로 설정 오류로 승인자를 결정할 수 없음	- 사용자 : 해당 기능 화면에 오류메시지 표시 - 운영자 : 오류에 해당하는 담당자가 있는 경우 이메일로 알림 발송
심각	- 애플리케이션 버그, 미들웨어 또는 인프라 장애로 인해 발생 - 시스템 운영자의 복구 조치 필요	- 디스크 공간 부족으로 파일 쓰기 실패 - 연결된 시스템이 다운됨	- 사용자 : 시스템 오류 안내 화면을 표시 - 운영자 : 운영담당자에게 이메일 발송
치명적	- 시스템 전체가 중단되는 장애 - 시스템 운영자의 복구 조치 필요	- 메모리 부족으로 애플리케이션 서버가 정지됨	- 애플리케이션에서 대응할 수 없으므로 별도의 운영 모니터링 실시

오류 처리 방법

대부분 오류는 도메인 계층 또는 그 하위에서 발생하며 예외는 도메인계층에서 프레젠테이션 계층의 컨트롤러로 전달됨. 클라이언트에 오류 응답을 반환해야 하므로 컨트롤러를 중심으로 오류 처리하는 것이 합리적이다.

컨트롤러 내부에서 오류 처리 (catch 블록을 활용한 예외 처리 방식)
인터셉터를 이용한 오류 처리 (컨트롤러에 도달하기 전에 요청 흐름을 가로채 오류를 처리하는 방식) : 공통 로직(일괄 적용)으로 정리할 수 있으나 상황에 따른 대응은 어려울 수 있음

로깅

로깅을 효과적으로 활용하기 위해서는 요구사항을 정리하고 정책 수립이 필요하다

로그의 목적과 용도에 따라 아래와 같이 분류할 수 있다.

로그	목적 및 용도	개요
접속 로그	감사, 장애 조사	사용자의 시스템 접속을 기록
인증 로그	감사	사용자 인증의 성공, 실패 내역을 기록
작업 로그	감사, 장애 조사	사용자가 시스템의 기능을 이용하여 수행한 작업을 기록
오류 로그	모니터링, 장애 조사	시스템에서 오류가 발생했을 때 상세 정보를 기록
디버그 로그	개발 시 디버깅	디비겅을 위해 변수 값 및 처리 진행 상황 등의 상세 정보 기록
성능 로그	성능 로그	배치 처리 시간, SQL 쿼리 응답 시간 등을 기록

로그 유형별로 출력 대상과 형식을 수립할 필요가 있다. 예를 들어 감사 목적의 로그는 데이터베이스에 저장하는 것이 적절할 수 있다. 이후 애플리케이션 기반에서 자동으로 출력할 수 있는 로그가 있는지 검토해야 한다. 예를 들어 AOP 기능이 있는 프레임워크/라이브러리 등을 얘기할 수 있다. 그렇지 않다면 로그는 직접 구현해야 하므로 출력 정책을 문서화하고 유틸리티와 같은 공통 기능으로 만들어 제공하면 효율적이다.

보안

보안은 시스템이 관리하는 데이터와 시스템 자체를 악의적인 공격이나 사용자의 실수로부터 보호하는 것을 목적으로 한다.

아래는 대표적인 보안 위협과 주요 대응책이다.

위협	정의	주요 대책
크로스 사이트 스크립팅(XSS)	공격자가 입력값에 삽입한 악성 스크립트가 사용자 브라우저에서 실행되도록 하는 공격	- 사용자 입력값 검증 - 사용자 입력 데이터를 화면에 출력할 때 HTML 이스케이프 처리
크로슷 사이트 요청 위조(CSRF)	공격자가 사용자의 세션을 이용해 악의적인 요청을 서버에 전송하도록 유도하는 공격	- 서버가 임시 CSRF 토큰 발행하고 요청에 포함된 토큰의 유효성 확인
SQL 인젝션(SQLi)	공격자가 입력값에 악성SQL을 삽입해 데이터베이스에서 임의의 쿼리를 실행하는 공격	- 사용자 입력값 검증 - 데이터베이스 쿼리에 프리페어드 스테이트먼트(SQL 삽입 방지) 사용

트랜잭션 제어

트랜잭션 제어는 애플리케이션 기능의 일련의 처리에서 발생하는 데이터베이스 작업을 하나의 논리적 트랜잭션 단위로 묶어 데이터의 정합성을 보장하는 구조이다.

트랜잭션 제어 구현 방법

명시적 트랜잭션. 프로그램 처리 내에서 트랜잭션 제어를 직접 코드로 명시하는 방식
선언적 트랜잭션. 설정파일이나 어노테이션을 이용해 트랜잭션의 범위와 동작을 정의

트랜잭션 경계 설정

트랜잭션 경계(범위)란 애플리에키션 처리 중 트랜잭션이 시작되어 종료되기까지의 범위를 의미

HTTP는 무상태성 프로토콜이기 때문에 일반적으로 여러 요청에 걸쳐 트랜잭션이 발생하지 않음

따라서 프레젠테이션 계층과 도메인 계층의 경계를 트랜잭션 경계로 삼는 것이 정석적이다.

명시적 트랜잭션은 컨트롤러의 메서드 내부에 제어 코드를 작성.
선언적 트랜잭션은 컨트롤러가 호출하는 서비스에 어노테이션을 부여.
하나의 요청에서 여러 서비스 호출이 필요한 경우 도메인 게층에 Facade역할을 하는 서비스를 배치하고 거기에 트랜잭션 경계로 정의
하나의 요청에서 여러 트랜잭션을 사용해야 하는 상황. 로그 기록이나 오류알림 전송과 같은 경우. 트랜잭션 경계를 부분적으로 분리해 별도 처리가 필요

데이터베이스 접근

애플리케이션의 처리 특성과 개발 용이성 등 여러 관점에서 적합한 기술을 선택해야 한다.

ORM

객체 관계 매핑은 객체 지향 프로그래밍 언어에서 메모리에 구성된 객체 모델과 관계형 데이터베이스의 테이블 구조 간 매핑을 지원하는 기술.

Hibernate의 경우 개발자가 직접 SQL을 작성할 필요 없으며 ORM이 제공하는 자체 쿼리 언어를 사용할 수 있다. 다만, 복잡한 쿼리가 필요한 요구사항 구현이 쉽지 않고 성능 저하 우려도 있다. 이에 따라 이를 보완하는 기술도 등장하게 되었다.

CQRS 패턴

쓰기 중심 처리에서는 복잡한 비즈니스 규칙의 적용이 필요한 경우가 많아아 도메인 모델 패턴이 적합하다

반면 읽기 중심 처리에서는 데이터베이스 쿼리는 복잡하지만 조회 결과를 DTO로 정리해 반환하는 등 비교적 단순한 형태로 처리 된다.

읽기와 쓰기를 분리해 각각 최적화된 모델을 사용하는 것이 CQRS 패턴이다

CQRS

데이터베이스 접근 공통 기능

애플리케이션에서 데이터베이스 접근을 위해 갖추어야할 공통 기능은 사용하는 기술과 도구에 맞춰 준비가 필요하다.

참고서적

- 아키텍트 첫걸음 : 아키텍처 설계 기본 원칙부터 실무 적용까지, 한빛미디어

[Architecture] 개발 프로세스 표준화

TedDev — Sun, 19 Oct 2025 18:41:47 +0900

기능 명세서 표준화

기능 명세서는 요구사항 분식이 마무리될 무렵 작성된다. 아래는 표준화하는 방법, 주의사항 등을 나타낸다.

유스케이스 다이어그램

유스케이스 다이어그램은 사용자와 유스케이스 간 관계를 시각적으로 파악하기 위해 작성

UML이라는 표준화 기법이 있지만 작성자에 따라 다이어그램의 단위, 유스케이스 세분화 수준, 표현 방식이 달라질 수 있어 일정한 정책이 필요할 수 있다.

유스케이스 다이어그램은 요소 간 의존 관계를 나타내기 위해 아래 개념을 사용한다.

일반화 관계 : 공통된 동작을 가진 여러 유스케이스를 묶어 추상적인 부모 유스케이스와 구체적인 자식 유스케이스 간의 관계를 표현
포함 관계 : 여러 유스케이스에서 반복되는 공통 기능을 하나의 유스케이스로 분리, 상위 유스케이스가 이를 호출하는 관계
확장 관계 : 특정 유스케이스 내에서 인터럽트 조건을 확장점으로 정의하고 조건이 만족될 때 별도의 유스케이스가 실행되도록 정의되는 관계

다만, 위의 개념은 객체지향 개념에 익숙하지 않는 담당자의 경우 작성이 어려울 수 있다. 그 때는 유스케이스 설명 안에 조건, 처리과정 등 설명이 명확히 정리되어 있다면 관계 다이어그램을 간소화 해서 작성하는 것도 충분하다

유스케이스 기술서

유스케이스 모델에서는 각 유스케이스의 동작 요구사항을 구체적으로 정리한 유스케이스 기술서가 중요하다.

사용자는 시스템을 이용하여 특정 목적을 당성하기 위해 유스케이스를 실행한다.

유스케이스는 사용자가 요청을 보내고 시스템이 응답하는 일련의 흐름으로 구성되며 이런 상호작용이 핵심이다.

성공 시나리오, 예외 시나리오 등 다양한 시나리오를 일정한 형식에 따라 정리한다.

유스케이스 기술서 구성

유스케이스명
사용자 : 유스케이스를 실행하고 상호작용을 시작하는 주 사용자와 관련 부 사용자
요약/설명 : 업무적 목적, 처리 개요
사전조건 : 충족해야하는 조건
사후조건 : 정상적으로 종료된 후 충족해야하는 조건
성공 시나리오 : 정상적으로 실행되어 사용자가 목표를 달성하는 시나리오 (해피패스)
예외 시나리오 : 각 단계에서 어떤 문제가 발생하여 유스케이스가 중단/종료되는 상황과 동작
대체 시나리오 : 특정 상황에서 성공 시나리오와 다른 상호작용이 발생하는 경우
비즈니스 규칙 : 유스케이스의 처리 절차에서 참조되는 비즈니스 규칙

유스케이스 기술서 작성 시 고려 사항

적절한 추상화 레벨에서 기술하는 것이 중요하다
유스케이스의 요약, 사용자 목표, 하위 기능 세 가지 목표 레벨 중 사용자 목표가 가장 중요
사용자 목표의 적절한 크기 (작업 범위)는 '사용자가 이 작업을 수행한 뒤 만족하고 떠날 수 있는 적절한 분량인가?' 의 질문에 대응하는 것
기타 추가 고려 사항
- 사전 조건과 사후 조건은 시스템 외부에 있는 사용자가 인식할 수 있는 상태만 기술하고 시스템 내부 상태는 포함하지 않는다
- 사용자 인터페이스에 의존하는 표현은 피한다
- 화면의 개별 항목을 나열하지 않고 정보의 청크 형태로 기술
- 비즈니스 규칙이나 로직 세부 사항은 기술하지 않는다
- 사용자가 직접 처리할 수 없는 시스템적 예외(DB장애, 서버 오류)는 기술하지 않지만 사용자가 개입할 수 있는 예외는 포함한다

기능명세서

사용자 인터페이스로 구현될 화면 구성은 기능 명세서를 통해 정의

기능명세서 구성

화면 전환도
화면 레이아웃 정의
항목 정의
화면 이벤트 정의
로직 정의

로직 정의할 때는 개발자 관점의 내부 처리 절차가 아니라 외부 요구사항을 기술하는 문서라는 점을 염두에 두어야 한다. '어떻게 실현할지(How)'가 아니라 '무엇을 할지(What)'를 설명해야 한다.

설계서 표준화

클래스 다이어그램이나 협업 다이어그램등 설계서를 미리 작성하더라도 코드로 구현하는 과정에서 항상 일치하도록 관리하는 것은 쉽지 않은 일이다. 많은 경우 설계문서를 작성하고 구현이 끝나면 폐기하고 리버스 엔지니어링을 통해 역으로 설계 구조를 도출하여 다이어그램을 생성하여 관리하기도 한다.

한편, 데이터베이스 관련 설계서(ERD, 테이블 정의서 등)등은 프로젝트를 수행하는 동안 계속 관리하기도 한다.

이처럼 필요와 복잡성에 따라 기준을 정하여 적절한 합리적인 방법을 취하는 것이 좋다.

참고서적

- 아키텍트 첫걸음 : 아키텍처 설계 기본 원칙부터 실무 적용까지, 한빛미디어

[리뷰] 대화의 정석 - 정흥수

TedDev — Sun, 19 Oct 2025 00:31:28 +0900

최근 말을 잘하는 법에 대한 중요성을 굉장히 많이 생각하게 되었다.
많은 사람들 앞에서 발표를 해야한다던가 업무 관련 커뮤니케이션,
그리고 최근 필요에 의해 이직을 위한 면접 기회를 자주 접하다 보니
말을 잘 할 수 있는 방법에 대한 필요성을 느끼게 되었다.

그래서 우선 책을 통해 방법을 찾아보고자 했다.
제일 먼저 눈에 띄었던 책이 '대화의 정석' 이라는 책이었고
이 책을 읽어보기 시작했다.

사실 이 책은 대화, 말을 잘 할 수있도록 스킬이나 기술, 방법 등을 알려주는 책인 줄 알았다.

그런데 천천히 읽어 나가다보니 그런 방법적인 부분 보다는 대화를 할 때 가져야하는

마음가짐, 태도, 자세 등에 더 많은 설명을 하고 있었다.

그리고 더 나아가 누군가와 대화를 할 때는 마음가짐은 삶을 살아갈 때 가져야 하는

자세나 마음가짐과 크게 다르지 않다고 말하는 것 같았다.

에세이를 보는 것과 비슷한 느낌

생각했던 내용은 아니지만 그래도 나한테 필요로 하는 부분,

그리고 시도해보면 좋을 것 같은 내용들도 있고 마음을 울리는 부분이 있어 정리해본다.

대화할 때 어떤 질문을 할지, 적당한 주제가 있을지 고민할 필요가 없다.
그저 ' 사람'을 보면 된다.
'이 사람은 어떤 사람일까?', '평소에 어떻게 생활할까?',
'무엇에 관심을 둘까?', '왜 그럴까?', '언제부터 그랬을까?'
하고 호기심을 가지면 질문은 자연스럽게 나온다.

대화의 질을 높이고 싶다면 사람에게 관심을 갖자.
그 사람의 생각과 기분, 마음을 궁금해하는 것이다.

대화 뿐만아니라 관계에서도 해당되는 것 같다.

그 '사람'에게 집중하는 것이다.

나는 최근에 온갖 불필요한 고민과 생각으로 사람과 현재에 집중하지 못한 시간들을 보내온 것 같았다.

그래서 최근에는 편하고 의지할 만한 관계를 만들어 내지 못한 것 같다는 메시지를 주는 글이었다.

그래서 이제 대화를 할 때는 상대에게 집중하려고 노력하고 있다.

세상이 옳다는 삶을 살 게 아니라
내가 옳다고 믿는 가치관으로 살 때 진짜 내 인생을 살 수 있다

알지만 어렵다.
어떤 선택이든 후회는 있다. 모두가 옳다는 삶을 살면 그나마 후회를 덜하지 않을까 하는 생각,
내가 옳다고 믿는 삶은 분명 힘들고 고생을 사서하는 삶일 수도 있다는 생각
이런 생각들 때문에 선택을 어렵게 한다.
그런데 내가 옳다고 믿는 가치관으로 살아가지 않으면 행복할 순 없다는 것은 맞는 것 같다.

대화의 기술과 방법에 대한 내용도 잘 설명되어져 있다.

다만, 대화하는 상황을 통해 관계, 인생에 대한 생각도 하게되는 내용이었다.

단순히 당장 적용할 수 있는 대화의 스킬이나 기술이 필요한 상황이라면 이 책은 적절하지 않을 수 있다.

대화에 임하는 태도나 마음가짐을 살피고 이를 통해 관계에 대한 개선까지 고려한다면 이 책을 한번 읽어봐도 좋을 것 같다.

[Architecture] 아키텍처 문서화

TedDev — Sat, 20 Sep 2025 23:30:56 +0900

아키텍처 기술서

아키텍처 기술서에 포함되는 항목

목적 : 개요, 문서의 목적, 대상 독자, 아키텍처의 목표 및 지향점
아키텍처 드라이버 : 아키텍처 설계 시 고려해야할 요소 (제약, 품질속성, 영향을 미치는 기능 요구 등)
전체 시스템 구성
사용자와 이해관계자 : 사용자 및 아키텍처가 영향을 주거나 받는 이해관계자 (PO, 개발자, QA엔지니어 등)
아키텍처 모델 : 아키텍처를 다양한 관점에서 모델링하여 문서화

아키텍처 모델

이해관계자들은 관심사가 달라 아키텍처에서 알고 싶은 관점이 다르다

이러한 관심사와 관점에 따라 아키텍처를 파악하는 방법을 뷰포인트라 한다. 뷰포인트에 따라 실제로 아키텍처를 모델로 표현한 개별 도면을 뷰라 한다

대표적인 뷰포인트 세트(여러 개의 뷰포인트를 체계적으로 정리하여 하나의 프레임워크 형태로 구성한 것)로 4+1 뷰와 C4 모델이 있다.

1. 4+1 뷰

필립 크뤼슈텐이 1995년에 발표한 논문에서 제시한 내용

4+1 뷰를 활용한 아키텍처 모델링에서는 여러 뷰포인트를 통해 다양한 이해 관계자의 관심사를 개별적으로 다룬다

논리 뷰 : 소프트웨어의 논리적 구조를 나타내는 뷰포인트로 레이어 구조, 컴포넌트 구조, 클래스 구조 등 UML의 패키지 다이어그램이나 클래스 다이어그램 등으로 표현
개발 뷰 : 소프트웨어의 구현 관점에서 구조를 나타내는 뷰포인트. 네임스페이스나 패키지를 활용해 계층화된 모듈 구조를 표현. 디렉토리 구조도나 UML 패키지 다이어그램 등으로 표현
프로세스 뷰 : 시스템 실행 시의 프로세스 및 태스크의 병렬성과 동시성을 표현하는 뷰포인트. 예를 들어 마이크로서비스 아키텍처에서 여러 서비스가 협력하여 처리하는 흐름을 나타내는 것도 효과적. UML 시퀀스 다이어그램 등으로 표현
물리 뷰 : 시스템의 각 모듈이 배치되는 환경을 표현하는 뷰포인트. 아키텍처 다이어그램과 같은 시스템 구성 표현
시나리오 뷰 (유즈케이스 뷰) : 핵심 유즈케이스 시나리오. 아키텍처 설계의 타당성을 검토하고 구현 초기에 사용할 유스케이스 후보 도출 가능

2. C4 모델

사이먼 브라운이 고안한 모델.

시스템을 4가지 서로 다른 추상화 레벨로 나누어 각 수준에 적합한 다이어그램을 사용해 아키텍처를 모델링한다.

관심사를 효과적으로 분리하고 소프트웨어 개발 과정에서 원활한 커뮤니케이션을 돕는다.

C4 모델의 소프트웨어 시스템 구조

컨텍스트 : 가장 추상적인 레벨에서 소프트웨어 시스템과 외부 엔티티 간의 상호작용을 파악하여 구조화한 모델링 단위. 시스템 컨텍스트 다이어그램으로 표현
컨테이너 : 시스템을 구성하는 요소로 독립적으로 배포 가능한 실행 단위
컴포넌트 : 컨테이너 내부 요소. 명확하게 정의된 인터페이스를 가지고 일관된 동작 제공. UML 클래스 다이어그램, 시퀀스 다이어그램 사용
코드 : 실제 구현 단계의 구성 단위. 클래스와 인터페이스가 이에 해당. 주로 중요한 컴포넌트나 복잡한 컴포넌트에 한해 필요한 때만 작성됨

참고서적

- 아키텍트 첫걸음 : 아키텍처 설계 기본 원칙부터 실무 적용까지, 한빛미디어