Show Cover Slide

TDD를 중요하게 바라보지 않습니다

저는 더 이상 “TDD 합시다”라고 말하지 않습니다.
대신 이렇게 말합니다:

“TDD 하면 좋죠. 초기엔 최소한만 해두세요.”
“그보다 먼저, 흐름과 관측 지점부터 설계 해둡시다.”

제품을 만들 때,
모든 사용성과 흐름을 처음부터 예측할 수는 없습니다.
예상하지 못한 상황이 반복되고,
그때마다 우리는 구조에 의지합니다.

그래서 저는 테스트보다 흐름의 구조,
예측보다 관측 가능한 시스템을 먼저 고민합니다.

이 글은 제가 왜 TDD보다 관측 가능성과 추적 가능한 구조를 더 중요하게 생각하게 되었는지를, 제가 겪은 기술 흐름을 따라 설명해보려는 시도입니다.

그 흐름은 이렇게 요약됩니다:

EDA → MSA → Metrics → O11y(Observability)

그리고 그 안에서 저는
분산 컴퓨팅,
데이터 중심 설계,
메시징 구조,
Gateway와 Bridge에
집중하며 흐름을 설계해왔습니다.

내가 걸어온 사고의 흐름: EDA → MSA → Metrics → O11y

돌이켜보면 저는 테스트를 먼저 설계하는 것보다,
흐름을 어떻게 만들고 그것을 어떻게 관측할 수 있을지를 먼저 고민해왔습니다.

이 과정에서 자연스럽게 다음과 같은 사고 흐름을 밟아왔습니다:

EDA (Event-Driven Architecture)

계산은 꼭 필요할 때만 일어나야 한다고 생각했습니다.
자원을 아끼기 위해서이기도 했지만,
무엇보다 시스템이 반응해야 할 ‘조건’을 명확히 정의하는 것이 중요했습니다.

그 조건은 바로 ‘이벤트’였습니다.
어떤 변화가 감지되었을 때,
그에 반응해 동작하도록 설계된 시스템은
불필요한 연산을 줄이고, 흐름의 단위를 명확하게 나눌 수 있습니다.

이벤트 기반의 구조는
시스템을 관측 가능한 단위로 나누는 첫 출발이 되어주었습니다.

MSA (Microservices Architecture)

처음에는 하나의 시스템 안에서
책임과 흐름을 추상화하고 모듈화하는 데 집중했습니다.
기능을 잘게 나누고, 경계를 명확히 구분하다 보니
각 기능은 독립적으로 존재할 수 있는 구조를 갖추기 시작했습니다.

그러다 보니 자연스럽게
의존성과 흐름이 분산되었고,
각 모듈은 서로 다른 서비스로 분리될 수 있는 준비가 된 상태가 되었습니다.

추상화 → 모듈화 → 분산 구조화
이 흐름을 따라가다 보니,
저는 어느새 MSA라는 구조를 활용하고 있었던 것입니다.

MSA는 목표가 아니라,
구조를 잘 나누기 위한 노력의 자연스러운 결과였습니다.

Metrics (Data-Driven Development)

흐름을 나누고 분산 구조로 설계하게 되면,
그 흐름이 실제로 어떻게 흘렀는지 확인할 수 있어야 합니다.
“무슨 일이 벌어졌는가?“라는 질문은,
더 이상 로그나 콘솔 출력을 넘어서 지표(Metrics)라는 형태로 다뤄져야 했습니다.

그래서 저는 각 흐름마다 이벤트를 정의하고,
그 이벤트가 발생한 시점과 결과를 기록하기 시작했습니다.
그렇게 쌓인 데이터가 지표가 되었고,
지표는 곧 시스템을 해석하고 판단하는 기준이 되었습니다.

점점 더,
코드가 아니라 데이터로 시스템을 이해하는 방식이 자연스러워졌습니다.

O11y (Observability)

흐름을 분리하고, 이벤트와 지표를 정의하면서
저는 결국 한 가지 질문에 도달하게 되었습니다:

“지금 이 시스템 안에서 무슨 일이 벌어지고 있는가?”

이 질문은 단순히 로그를 남기거나,
나중에 에러를 분석하기 위한 것이 아니었습니다.
시스템의 흐름을 설계하는 순간부터,
그 흐름을 관측할 수 있는 지점을 함께 설계해야 한다는 뜻이었습니다.

이벤트와 지표는 수집하는 것만으로 충분하지 않았습니다.
그 수집이 해석 가능한 형태로 구조화되어야,
우리는 시스템의 상태를 ‘내부가 아닌 외부에서’ 이해할 수 있게 됩니다.

그래서 저는 구조를 설계할 때,
관측 지점 자체를 설계 요소로 포함시키는 방식으로 접근했습니다.
이는 자연스럽게 TDD보다 먼저,
흐름을 설계하고 그 흐름을 관측 가능한 형태로 정의하는 개발 방식으로 이어졌습니다.

ODD는 내가 해오던 개발과 닮아 있었습니다

ODD(Observability-Driven Development)라는 개념을 처음 접했을 때,
저는 그것이 낯설거나 새롭다고 느끼지 않았습니다.
오히려 자연스럽게 이런 생각이 들었습니다:

“내가 해오던 개발 방식이 이와 비슷했다.”

저는 SRE 관점에서 출발하지 않았습니다.
운영 효율이나 장애 대응보다는,
시스템의 흐름을 어떻게 설계하고 해석 가능한 단위로 만들 것인가에 집중해왔습니다.

제가 품어온 질문들은 늘 비슷했습니다:

• 분산 컴퓨팅 환경에서 자원을 어떻게 효율적으로 쓸 것인가?
• 이벤트 기반 비동기 구조를 어떻게 추적 가능한 단위로 만들 것인가?
• 시스템의 동작을 어떻게 데이터로 해석할 수 있을까?

이러한 질문들 속에서
자연스럽게 흐름을 나누고, 경계를 정의하고,
그 위에 데이터를 쌓아왔습니다.

그렇게 도달한 구조는 결국
관측 가능성(Observability)을 중심에 둔 시스템이었습니다.

ODD는 제가 쌓아온 사고의 흐름을
더 정제된 언어로 설명해주는 이름이었고,
그 철학은 제가 오랫동안 고민해온 방향성과
자연스럽게 맞닿아 있었습니다.

메시징은 흐름의 언어입니다

흐름을 추적 가능한 구조로 만들기 위해
제가 가장 집중해온 기술적 수단은 메시징(Messaging)입니다.

처음에는 단순히 비동기 처리를 위한 통신 기법 정도로 접근했습니다.
하지만 시스템을 메시지 중심으로 바라보는 순간,
저는 흐름이 곧 메시지이고, 메시지가 곧 시스템의 구조라는 생각을 갖게 되었습니다.

메시징의 힘은 단순함에 있습니다.
단지 데이터를 전달하는 것을 넘어,
시스템이 어떤 단위로 반응하고 변화하는지를 정의하는 수단이기 때문입니다.

• 메시지는 흐름의 단위를 명확히 규정합니다.
• 시간과 공간을 분리하며,
• 서비스 간 결합도를 낮추고,
• 언제, 무슨 일이 일어났는지를 기록할 수 있게 해줍니다.

메시지는 단순한 통신 수단이 아닙니다.
그것은 설계의 단위이자, 추적과 해석의 단서입니다.

그래서 저는 코드보다 메시지를 먼저 설계합니다.
“흐름을 어떻게 설계할 것인가?“라는 질문에
가장 먼저 답해야 하는 것이 바로 메시지이기 때문입니다.

Gateway와 Bridge는 흐름의 출입구입니다

흐름을 관측하려면,
그 흐름이 반드시 어디를 지나가는지를 식별할 수 있어야 합니다.
저는 그 지점을 Gateway와 Bridge라는 구조로 설계해왔습니다.

이 둘은 단순한 통신 경로가 아니라,
흐름을 기록하고 해석할 수 있게 만들어주는 출입구입니다.

Gateway: 흐름의 진입점과 종착지

Gateway는 시스템 외부와 내부가 만나는 접점입니다.
요청이 들어오고, 응답이 나가며, 오류와 지연이 발생하는 모든 순간이
Gateway를 통과하면서 기록됩니다.

저는 이 구조를 단순한 API 라우팅 계층이 아닌,
관측과 계측의 출발점으로 설계합니다.

• 요청 단위로 Metrics를 쌓고
• 트랜잭션 단위로 흐름을 추적하며
• 외부와 내부의 경계를 구조적으로 정의합니다

Bridge: 흐름을 재해석하는 전환점

Bridge는 서로 다른 해석 체계를 가진 흐름을 연결하는 지점입니다.
단순히 메시지를 전달하는 것이 아니라,
책임과 의미를 다시 정의하는 구조적 전환이 일어나는 곳입니다.

Bridge는 다음과 같은 역할을 수행합니다:

• 메시지 포맷을 변환하고
• 도메인 간 책임을 넘기며
• 시스템 간 연결을 느슨하게 유지합니다

저는 Gateway와 Bridge를
흐름의 관측을 가능하게 만드는 명확한 구조적 인터페이스이자,
시스템이 해석 가능한 경계 위에서 동작할 수 있게 만드는 핵심 장치로 설계합니다.

Design-First로 시작하고, 필요할 때 나눕니다

저는 처음부터 MSA를 목표로 삼지 않습니다.
기술 스택이 중요한 것이 아니라,
흐름과 경계를 어떻게 설계하느냐가 핵심이라고 생각합니다.

그래서 언제나 Design-First,
즉 흐름의 구조부터 설계하는 방식으로 시작합니다.

“흐름을 먼저 설계하고,
관측 가능한 구조를 갖춘 다음,
필요할 때 나눕니다.”

초기에는 하나의 모놀리식 구조로 빠르게 실행합니다.
하지만 그 안에서도 반드시 다음을 준비해둡니다:

• 흐름마다 메시징 구조를 설계하고
• 도메인 간 책임을 분리하고
• Metrics를 수집할 지점을 명확히 정해둡니다

이렇게 준비된 구조는
비록 초기엔 하나의 덩어리처럼 보일 수 있지만,
언제든 분해 가능하고 추적 가능한 시스템으로 발전할 수 있습니다.

저에게 MSA는 어떤 선언이 아닙니다.
경계가 명확해지면 자연스럽게 도달하게 되는 하나의 구조적 결과일 뿐입니다.

효율과 흐름과 추적이 생각의 중심점입니다

제가 시스템을 설계할 때 가장 중요하게 여기는 기준은 세 가지입니다:

효율, 흐름, 그리고 추적 가능성

효율: 지금 이 연산은 필요한가?

컴퓨팅 자원은 언제나 유한합니다.
그래서 저는 설계 단계에서부터 늘 이렇게 묻습니다:

“이 연산은 꼭 지금 필요할까?”
“이 구조는 자원을 낭비하지 않고 흘러갈 수 있을까?”

이 질문은 자연스럽게 이벤트 기반, 비동기적 흐름을 설계하게 만들었습니다.

흐름: 설계되지 않은 흐름은 불안정하다

효율적인 시스템은 설계된 흐름을 따르는 시스템입니다.
요청과 응답, 트리거와 처리, 전송과 저장이
의도된 순서로, 예측 가능한 방식으로 흘러야 시스템은 안정성을 가질 수 있습니다.

추적: 흐름을 관측할 수 있어야 한다

아무리 잘 설계된 흐름이라도,
그 흐름이 실제로 그렇게 작동했는지를 알 수 없다면
그 시스템은 해석될 수 없고, 유지될 수도 없습니다.

그래서 저는 메시지를 중심으로 흐름을 정의하고,
Gateway와 Bridge를 통해 흐름의 관문을 설계하며,
관측 가능한 구조를 설계의 일부로 간주합니다.

제가 강조해온 추적 가능성은
운영에서의 모니터링이 아니라,
설계 단계에서부터 시스템의 해석 가능성을 준비하는 방식이었습니다.

그런 관점에서 저는 ODD가 제 철학과 매우 닮아 있다고 느꼈습니다.

결론: 중요한 것은 흐름과 구조입니다.

TDD는 훌륭한 개발 기법입니다.
하지만 저에게 있어 더 먼저 떠오르는 질문은 항상 이것이었습니다:

“지금 이 시스템 안에서는 무슨 일이 벌어지고 있는가?”

이 질문에 답할 수 있어야,
우리는 시스템을 설계했다고 말할 수 있습니다.

그 답을 찾기 위해
저는 테스트보다 먼저 흐름을 나누고,
메시지를 중심으로 구조를 설계하며,
Gateway와 Bridge를 통해 관측 지점을 정의해왔습니다.

그 중심에는 항상
분산 컴퓨팅 환경에 대한 이해,
데이터 중심의 해석 방식,
그리고 관측 가능성 중심의 구조 설계가 있었습니다.

ODD는 나중에 알게 된 이름이지만,
제가 설계자로서 고민해온 많은 것들을
가장 명확한 언어로 설명해주는 개념이었습니다.

이러한 철학이 단순한 이론이 아니라는 점은
제가 경험한 ROS(Robot Operating System)를 통해 분명히 확인할 수 있었습니다.

ROS는 메시지 기반의 분산 컴퓨팅 구조를
TCP 위에서 안정적으로 구현한 시스템이었습니다.
센서, 액추에이터, 제어 노드들이
서로 메시지로 느슨하게 연결된 구조였음에도,
흐름이 명확하였고 시스템은 유기적으로 동작했습니다.

그 안에서 저는 구조가 실제로 “작동한다”는 것을 처음으로 체감했습니다.

이 경험을 통해 확인하게 되었습니다:

• 메시지가 흐름을 정의할 수 있다는 것
• 구성 요소들이 독립적으로, 추적 가능한 단위로 분리될 수 있다는 것
• 관측 가능성과 분산 효율성이 함께 구현될 수 있다는 것

그리고 무엇보다도,
메시지를 먼저 설계하고,
그 위에 흐름과 구조를 차곡차곡 세워나가는 방식은
철학이 아니라 충분히 실현 가능한 설계 방법이라는 것을 경험했습니다.