5분 아키텍처 스케치: 프레임워크가 아닌 펜으로 복잡한 기능을 차분하게 다루는 법

복잡한 기능은 대부분 흐릿한 상태에서 시작합니다. 백로그에 적힌 한 줄짜리 스토리, 회의에서 튀어나온 버즈워드, 화이트보드 위의 화살표 뒤엉킨 낙서 같은 것들 말이죠. 그리고 우리는 너무 자주, 너무 빨리 이런 선택을 합니다.

• 새 프레임워크를 고르고,
• 새 레포를 만들고,
• 무거운 모델링 툴을 엽니다.

그보다 더 차분하고 빠르게 시작하는 방법이 있습니다. 바로 5분 아키텍처 스케치입니다.

펜 한 자루나 가벼운 브라우저 기반 도구만 있어도, 프로덕션 코드를 한 줄도 쓰기 전에, 혹은 어떤 프레임워크가 “최고”인지 논쟁하기 전에:

• 무엇을 만들고 있는지 더 선명하게 이해하고,
• 숨겨진 복잡도를 드러내고,
• 팀의 관점을 맞출 수 있습니다.

이 글에서는 5분 스케치 습관을 만드는 방법, 어떤 도구를 쓰면 좋은지, 그리고 작은 시각화 습관이 어떻게 큰 기능의 위험을 줄여주는지 살펴봅니다.

왜 먼저 스케치하고 나중에 코딩할까?

아키텍처라는 말을 들으면, 우리는 종종 이런 걸 떠올립니다. 기업용 다이어그램, 반듯한 박스와 완벽하게 정렬된 화살표, 수십 개의 컴포넌트. 새로운 기능을 이해해보려는 시점에는 이런 수준의 디테일이 오히려 독입니다.

5분 스케치의 목표는 전혀 다릅니다.

• 완전함이 아니라 명료함 – 사용자는 누구인지, 어떤 서비스와 데이터 저장소가 있고, 핵심 통합 지점이 어디 있는지, 큰 움직이는 부품만 보이면 충분합니다.
• 문서가 아니라 대화 – 이 스케치는 팀과 함께 생각을 정리하기 위한 도구이지, 영원히 보관할 산출물이 아닙니다.
• 낮은 비용, 높은 학습 효과 – 몇 분만 투자해도 빠진 부분을 찾고, 위험한 통합 지점을 짚어내고, 잘못된 가정을 드러낼 수 있습니다.

그 결과, 훨씬 차분한 방향성을 갖게 됩니다. 결국 복잡한 프레임워크를 선택할 수도 있습니다. 하지만 그때는 불안이 아니라 분명한 이유 때문에 선택하게 됩니다.

가벼운 브라우저 기반 도구(또는 종이)를 쓰자

빠르고 비공식적인 아키텍처 스케치에는 무거운 도구가 방해가 됩니다. 도형 팔레트랑 씨름하지 말고, 몇 초 안에 바로 그리기 시작할 수 있어야 합니다.

좋은 선택지는 예를 들면 이런 것들입니다.

• Excalidraw – 브라우저 기반, 설치 없이 사용 가능, 손그림 스타일. 협업하며 자유롭게 끄적이기에 최적입니다.
• tldraw, Miro, Figma 화이트보드 – 느슨한 도형과 자유로운 배치, 실시간 협업을 잘 지원합니다.
• 종이 & 펜 / 오프라인 화이트보드 – 여전히 속도와 즉흥성 면에서는 최강입니다.

핵심은 마찰 없는 드로잉입니다.

• 도구를 연다.
• 박스 몇 개와 화살표를 그린다.
• 쉬운 말로 라벨을 단다.

도구가 자꾸 완벽한 정렬, 픽셀 단위 정밀함, 엄격한 UML 기호를 강요한다면, 이 단계에서는 너무 무거운 도구일 가능성이 큽니다.

왜 손그림 스타일 다이어그램이 그렇게 잘 먹히는가

Excalidraw 같은 도구는 의도적으로 손으로 그린 것처럼 보입니다. 선은 덜렁거리고, 도형은 어설프고, 글자는 들쑥날쑥하죠. 이건 단순한 미적 선택이 아니라, 사람들이 그 다이어그램과 어떻게 상호작용하는지를 바꿉니다.

손그림 스타일 시각화는 이렇게 신호를 보냅니다.

• “이건 탐색 중이에요.” – 사람들은 눈앞에 보이는 걸 더 자유롭게 질문하고 수정하려 합니다.
• “이게 최종본은 아니에요.” – 지나치게 깔끔한 다이어그램이 주는, ‘이미 결정된 것 같은’ 권위에서 벗어납니다.
• “누구나 참여할 수 있어요.” – 동료가 “저 박스가 뭐죠?” “이 부분은 나누는 게 좋지 않을까요?”라고 말하는 데 부담이 적습니다.

반대로, 지나치게 정제된 공식 다이어그램은 대화를 막아버리기 쉽습니다. 이미 완성된 것처럼 보여서, 사람들이 비판하거나 제안하는 걸 주저하게 만들죠.

스케치는 이렇게 말합니다.

“같이 이걸 만들어 봅시다.”

(공식 다이어그램은 종종 이렇게 들립니다: “이게 공식 아키텍처입니다.”)

새로운 기능에 대해 생각하기 시작하는 첫 5분에는, 전자가 훨씬 더 유용합니다.

좋은 ‘빠른’ 아키텍처 다이어그램의 요건

스케치 수준이라 해도, 좋은 아키텍처 다이어그램에는 공통된 특징이 있습니다.

1. 핵심 컴포넌트를 드러낸다
   정말 중요한 것만 보여줍니다. 예를 들면:

   • 사용자
   • UI
   • 주요 서비스들
   • 핵심 데이터 저장소
   • 꼭 필요한 외부 API

2. 관계를 보여준다
   누가 누구와 통신하는지 화살표로 나타냅니다. 그리고 화살표에는 동사를 적습니다.

   • "calls"
   • "publishes event"
   • "writes to" 등

3. 데이터 흐름을 분명히 한다
   중요한 데이터가 어디서 생성되고, 어디서 변형되며, 어디에 저장·노출되는지 표시합니다.

4. 사소한 디테일은 과감히 버린다
   모든 마이크로서비스, 클래스, DB 테이블을 그릴 필요는 없습니다. 이 기능과 직접적으로 관련 있는 것에만 집중합니다.

5분 안에 하는 일은 시스템 전체 설계가 아닙니다. 대신 이런 질문에 답을 얻는 게 목표입니다.

• 이 새 기능은 기존 지형도에서 어디에 위치하는가?
• 무엇에 의존하는가?
• 무엇이 이 기능에 의존하는가?
• 데이터는 어디서 생성·검증·저장·노출되는가?

스케치가 이 질문들에 답할 수 있다면, 그걸로 충분히 잘한 것입니다.

5분 스케치 루틴 (단계별)

다음에 복잡한 기능을 맡게 되면, 이 루틴을 그대로 따라 해보세요.

1. 사용자부터 시작하기
막대인간 하나를 그리거나, User / Client라고 적힌 박스를 하나 그립니다. 그리고 스스로에게 묻습니다. “이 사람(또는 시스템)은 무엇을 하려는가?”
사용자 아래에 3–5 단어로 목적을 적습니다.

• 예: "대출 신청 제출", "장바구니 결제", "계정 정보 변경" 등

2. 주요 진입점 추가하기
사용자가 처음으로 마주치는 UI나 API를 그립니다.

• "웹 앱 UI"
• "모바일 앱"
• "Public REST API"

사용자에서 이 진입점으로 화살표를 하나 그립니다.

3. 핵심 컴포넌트 3–7개만 추가하기
이번에는 이렇게 묻습니다. “이 기능에 관여하는 시스템의 큰 조각들은 무엇인가?”
그리고 다음과 같은 덩어리들만 그립니다.

• 애플리케이션 서비스
• 백그라운드 워커
• 핵심 도메인 서비스
• 서드파티 API들
• 데이터베이스나 큐

4. 데이터 흐름을 화살표와 라벨로 그리기
컴포넌트들 사이를 화살표로 연결하고, 짧은 동사구로 라벨을 답니다.

• "POST /applications"
• "Publishes LoanSubmitted event"
• "Writes to loan_applications table"

5. 복잡한 부분을 동그라미 치거나 강조하기
특히 복잡해 보이거나 위험해 보이는 지점을 1–3개 찾아 표시합니다.

• 여러 서비스를 아우르는 트랜잭션
• 큰 규모의 데이터 변환
• 보안 경계(권한, 인증, 개인정보 등)

점선 테두리를 치거나 다른 색으로 강조하고, 간단한 메모를 적습니다. 예: "추가 설계 필요"

6. 5분에서 멈추기
이게 핵심입니다. 예쁘게 다듬고 싶은 욕구를 참고 멈춥니다. 지금의 목표는 구조를 드러내는 것이지, 아름다운 다이어그램을 만드는 게 아닙니다.

이제 팀이 함께 비판하고 다듬을 수 있는, 공유된 시각적 출발점이 생겼습니다.

UML에 빠지지 않고 ‘필요한 것만’ 다이어그램 고르기

유용한 스케치를 그리기 위해 UML 전체를 알 필요는 없습니다. UML에는 수많은 다이어그램 유형이 있지만, 기능 단위로 빠르게 작업할 때는 그 중 아주 일부, 혹은 그 정신만 빌려와도 충분합니다.

대표적으로 이런 것들이 있습니다.

1. 컨텍스트 / 시스템 다이어그램

• 목적: 내 시스템(또는 기능)이 주변 환경과 어떻게 연결되는지 보여준다.
• 언제 사용: 어떤 다른 시스템, 사용자, 외부 서비스가 얽혀 있는지 정리할 때.
• 형태: 가운데에 내 시스템(또는 기능)이 있고, 주변에 다른 박스(사용자, 외부 서비스)가 있고, 각각 화살표와 라벨로 연결된 형태.

2. 컴포넌트 다이어그램

• 목적: 시스템 내부의 주요 부분들이 서로 어떻게 관계를 맺는지 보여준다.
• 언제 사용: 기능을 서비스, 모듈, bounded context 등으로 쪼개고 싶을 때.
• 형태: "Order Service", "Payment Adapter"처럼 주요 컴포넌트를 박스로 표현하고, 이들 사이의 연결 관계를 표현.

3. (아주 느슨한) 시퀀스 다이어그램

• 목적: 시간 순서에 따라 상호작용이 어떻게 이어지는지 보여준다.
• 언제 사용: 순서가 중요한 플로우(결제, 승인 절차, 이벤트 기반 상호작용 등)를 다룰 때.
• 형태: 세로로 나열된 참여자들 사이를 가로 화살표가 오가며, 시간 순서에 따른 메시지를 나타내는 형태.

5분 스케치 모드에서는 완전한 UML 다이어그램을 그릴 필요가 없습니다. 대신 이렇게 합니다.

• 컨텍스트 다이어그램의 아이디어를 빌려 시스템 전체 윤곽을 본다.
• 컴포넌트 다이어그램의 아이디어를 빌려 내부 구조를 본다.
• 시퀀스 다이어그램의 아이디어를 빌려 절차와 순서를 생각해 본다.

이 패턴들을 대략 알고 있으면, 어느 수준에서 그릴지 빠르게 선택하기가 훨씬 쉬워집니다.

스케치에서 ‘제대로 된’ 문서까지

거친 스케치는 끝이 아니라, 더 나은 문서로 이어지는 시작점입니다.

짧은 스케치가 시간이 지나며 어떻게 진화할 수 있는지 살펴보겠습니다.

1. 초기 스케치 (5분)
   손그림 스타일, 최소한의 정보. 초기 논의에 사용합니다.

2. 정제된 다이어그램 (30–60분)
   같은 도구나 조금 더 정제된 도구에서 다시 그립니다.

   • 라벨을 다듬고,
   • 이미 버린 아이디어는 지우고,
   • 빠진 컴포넌트를 보완합니다.

3. 공식 문서화 (필요할 때)
   더 큰 프로젝트나 규제가 중요한 환경에서는 다음과 같은 작업을 할 수 있습니다.

   • C4 모델이나 일부 UML처럼 일관된 표기법 적용
   • 디자인 문서나 위키에 쓸 수 있도록 깔끔한 SVG/PNG로 내보내기
   • 다이어그램을 ADR(Architecture Decision Record)이나 RFC에 연결하기

중요한 건, 무거운 문서는 빠르게 그린 스케치를 통해 얻은 이해 위에 쌓인다는 것입니다. 정말 중요한 게 무엇인지 알게 된 뒤에야, 그 부분에만 시간을 진지하게 투자하면 됩니다.

짧고 집중된 습관으로 복잡도를 차분하게 다루기

진짜 핵심은 특정 도구나 표기법이 아닙니다. 습관 자체입니다.

• 코드로 바로 뛰어들거나 프레임워크 논쟁을 시작하기 전에, 먼저 5분을 스케치에 투자합니다.
• 새 기능, 리팩터링, 큰 장애를 다룰 때마다 이 습관을 반복합니다.
• 형식적이지 않아도 되고, 언제든 바꿀 수 있는 ‘대화용 스케치’로 남겨 둡니다.

이 습관을 이어가다 보면 이런 변화가 생깁니다.

• 뒤늦게 발견하는 숨은 의존성이 줄어듭니다.
• 기획, QA, 운영과의 대화가 훨씬 선명해집니다.
• 크고 낯선 영역을 마주할 때의 스트레스가 줄어듭니다.

당신 자신과 팀에게 이런 학습을 시키는 셈입니다. 복잡도를 마주했을 때 가장 먼저 할 일은, 반짝이는 새 프레임워크를 붙드는 것이 아니라 펜을 드는 것이라고요.

마무리

아키텍처 작업은 기업용 툴이나 거대한 다이어그램으로 시작할 필요가 없습니다. 손그림 스타일 도구나 종이 한 장으로 5분만 투자해도, 다음과 같은 효과를 얻을 수 있습니다.

• 핵심 컴포넌트, 관계, 데이터 흐름을 빠르게 드러낸다.
• 건설적인 논의와 공동 이해를 자연스럽게 이끌어낸다.
• 이후 더 공식적인 문서 작업의 단단한 기반을 제공한다.

Excalidraw 같은 가벼운 브라우저 기반 도구를 쓰면 시작 자체는 아주 간단합니다. UML과 흔한 다이어그램 유형에서 아이디어를 조금만 빌려오되, 지금 필요한 만큼만 사용하면 됩니다.

다음에 복잡한 기능이 책상 위에 떨어지면, 이렇게 해보세요.

• 프레임워크 얘기를 잠시 멈추고,
• 스케치 도구를 열고,
• 5분 동안만 그려봅니다.

코드를 건드리기도 전에, 얼마나 많은 복잡도를 미리 차분하게 정리할 수 있는지 직접 느끼게 될 것입니다.