Make It Work, Make It Right, Make It Fast
미소 짓는 제품, 미소 짓는 팀, 미소 짓는 코드

저장소 소개 오디오 .wav 파일 by 노트북LM

지속 가능한 코드
코드는 팀이 함께 완성해 가는 한 편의 글입니다. 우리는 그 글을 차곡차곡 쌓아 제품을 만들어 갑니다.

• 소스 코드의 구조는 책의 목차처럼 명확하고 직관적이어야 하며, 이를 통해 도메인과 제품의 이해를 자연스럽게 이끌어야 합니다.
• 테스트 코드는 단순한 검증 도구를 넘어, 비즈니스 규칙을 학습하는 핵심가이드가 되어야 합니다.

지속 가능한 코드는 마치 한 편의 아름다운 시와 같습니다. 시간이 흘러도 그 의미와 가치가 바래지 않고, 읽는 이에게 꾸준한 감동을 주는 코드입니다. 이런 코드를 작성하는 일은 단순히 기능을 구현하는 것을 넘어, 코드의 아름다움과 명료함을 추구하는 개발자의 철학이자 자세입니다.

코드는 마치 한 그루의 나무처럼 자랍니다.

나무는 처음 심을 때는 작고 연약하지만, 시간이 흐르면서 뿌리를 내리고 가지를 뻗어 결국 울창한 숲을 이루게 됩니다. 지속 가능한 코드도 마찬가지입니다. 처음 작성할 땐 작은 부분에 불과할지 몰라도, 시간이 지나면서 점차 더 많은 기능을 담고, 더 많은 이들의 손을 거치며 제품과 함께 성장하게 됩니다.

이처럼 지속 가능한 코드를 작성하는 일은 단순한 기술 구현을 넘어, 미래를 내다보는 안목과 책임감이 필요한 일입니다. 코드는 결국 작성자의 철학과 가치관이 고스란히 드러나는 작품이기 때문입니다.

우리는 스스로에게 끊임없이 질문해야 합니다

• 이 코드가 시간이 지나도 쉽게 이해되고 유지보수될 수 있을까?
• 이 코드가 다른 사람들과의 협업에 걸림돌이 되지는 않을까?
• 이 코드가 변화하는 요구사항에 유연하게 대응할 수 있을까?

이 질문들은 우리가 나아가야 할 방향을 알려주는 나침반이 됩니다. 가독성이 높은 코드, 명확하게 정의된 인터페이스, 그리고 신뢰할 수 있는 테스트는 지속 가능한 코드의 핵심 요소이자, 제품의 지속적인 진화를 뒷받침하는 기반입니다.

그러나 지속 가능한 코드를 작성하는 길은 결코 쉽지 않습니다. 때로는 당장의 마감에 쫓겨, 임시방편에 기대고 싶은 유혹에 빠지기도 합니다. 하지만 우리는 언제나 긴 호흡으로 바라봐야 합니다. 일시적인 해결책보다는 장기적인 관점에서의 품질을 더 중요하게 여겨야 합니다. 그것이 진정한 개발자의 시선이며, 팀과 제품을 위한 진정한 기여라고 믿습니다.

제가 꿈꾸는 코드는, ‘제품과 함께 성장하는 코드’, ‘다시 읽고 싶은 코드’, ‘누군가에게 배움이 되는 코드’입니다. 그것이 제가 코드를 쓰는 이유이며, 지속 가능한 코드를 향해 끊임없이 나아가는 이유입니다. 그리고 이 여정은 혼자가 아닌, 같은 꿈을 꾸는 개발자들과 함께 만들어가는 길입니다.

결국, 지속 가능한 코드를 작성하는 일은 단순한 기술적 문제를 넘어서 인간적인 문제이기도 합니다. 서로를 배려하고 존중하며, 함께 성장하는 것이야말로 지속 가능한 코드를 위한 가장 중요한 요소라고 믿습니다.

이것이 바로 지속 가능한 코드를 향한, Beyond Code 저장소의 이야기입니다.

도메인 주도 설계의 '무엇을 표현할지'와 함수형 프로그래밍의 '어떻게 표현할지'가 만나서, 변경에 강하고, 테스트 가능하고, 명확한 의도를 가진 코드를 만듭니다.

• 무엇을 표현할지: 복잡성 분리
  • 복잡한 비즈니스 로직을 도메인 모델 중심으로 풀어나가는 설계 방법입니다.
  • 도메인 전문가의 언어(Ubiquitous Language)로 제품을 설계하는 것이 핵심입니다.
• 어떻게 표현할지: 부작용 최소화
  • 함수(수학적인 함수)에 기반한 프로그래밍 방식입니다.
  • 상태 변경 없이, 입력에 따라 일관된 출력을 보장합니다.

• 변경에 강한 모델
  • 도메인 주도 설계: 복잡성 분리 (관심사의 분리: 도메인과 기술)
  • 함수형 프로그래밍: 부작용 최소화 (합성 함수: 부작용 없는 순수 함수 연결)
• 예측 가능한 동작
  • 도메인 주도 설계: 명확한 경계 (Bounded Context)
  • 함수형 프로그래밍: 순수 함수 지향
• 풍부한 도메인 표현
  • 도메인 주도 설계: 명확한 의미 부여 (Ubiquitous Language)
  • 함수형 프로그래밍: 타입 기반 설계

• 출처: 마틴 파울러, 소프트웨어 아키텍처의 중요성

아키텍처는 마치 식물처럼 '토양' 위에서 자란다

• 애플리케이션 아키텍처는 식물에 비유할 수 있습니다.
• 아키텍처는 ‘종자’에 불과하고, 그 종자가 자라기 위해서는 적절한 토양(개발 문화), 물(자동화된 배포), 빛(인프라), 온도(가치 전달 속도)가 필요합니다.
• 좋은 종자라도 척박한 땅에선 자랄 수 없고, 잘 자라는 구조라도 계속 방치하면 금방 말라 죽습니다.

• 아키텍처 원칙 (Separation of Concerns)
  • 1992년, 제품을 구성할 때 관심사(역할과 책임 그리고 협력)를 구분하는 개념이 소개되었습니다.
  • 대표적으로 Three-layered Architecture(프리젠테이션, 비즈니스, 데이터 계층)와 ECB(Entity-Control-Boundary) 모델이 등장하여, 레이어와 엔티티를 나눠 설계하는 방식이 제시되었습니다.
  • 이로써 코드의 구조와 책임이 명확해지고, 유지보수와 확장이 쉬워졌습니다.
• 개발 방법론 (Development Methodology)
  • 1999년부터, 개발 방식에도 변화가 생깁니다.
  • 익스트림 프로그래밍(XP)과 애자일(Agile) 방법론이 등장하며, 고객의 요구에 빠르게 대응하고 가치를 빠르게 전달하는 것이 중요해졌습니다.
  • 2001년 발표된 애자일 선언(Agile Manifesto)는 지금까지도 소프트웨어 개발 철학에 큰 영향을 미치고 있습니다.
• 설계 기술 (Design Techniques)
  • 2002년, 켄트 벡이 테스트 주도 개발(TDD)을 소개하면서, 코드를 작성하기 전에 테스트를 먼저 만들고 설계하는 새로운 접근이 확산됩니다.
  • 2003년, 에릭 에반스가 발표한 도메인 주도 설계(DDD)는 복잡한 비즈니스 로직을 중심으로 코드를 구조화하는 강력한 설계 전략으로 자리잡았습니다.
  • 두 기술은 지금까지도 많은 개발자들이 사용하는 핵심 설계 기법입니다.
• 아키텍처 패턴 (Architecture Patterns)
  • 2005년부터, 실제 제품 설계에 활용할 수 있는 다양한 아키텍처 패턴이 등장합니다.
    • 헥사고날 아키텍처(Ports & Adapters) – 외부 시스템과의 의존성을 줄이고, 핵심 도메인을 보호하는 구조.
    • 어니언 아키텍처 – 도메인 중심으로 레이어를 감싸는 방식.
    • 클린 아키텍처 – 핵심 비즈니스 로직을 중심으로 의존성을 바깥 방향으로만 향하게 설계.
  • 이들 패턴은 모두 관심사의 분리와 의존성 제어라는 원칙을 기반으로 발전해 왔습니다.
• 설계 테스트 (Design Test)
  • 2009년, 테스트 피라미드 개념이 소개되며, 유닛 → 통합 → E2E(엔드투엔드) 테스트를 계층적으로 설계하는 전략이 강조됩니다.
  • 테스트 또한 설계의 일부분으로 간주되며, 안정성과 품질을 보장하는 중요한 수단이 됩니다.

• 아키텍처는 도메인 주도 설계와 함수형 프로그래밍을 기반으로 레이어를 명확히 구분하고, 각 레이어의 역할과 요청·응답 방식을 통일하는 것에서 시작됩니다.
• 이러한 관심사의 분리(레이어)는 테스트 피라미드 구조를 적용한 자동화 테스트를 가능하게 하고, 각 레이어에서 생성되는 로그, 지표, 추적 데이터를 일관성 있게 수집·관리할 수 있는 기반을 제공합니다.
• 특히 로그는 운영 환경에서 필수적인 요구사항으로, 예측 가능한 실패(Validation Error 등)와 예측 불가능한 실패(Exception 등)를 구분하고, 이들을 단일화된 에러 타입으로 통합해 다양한 환경에서도 일관된 오류 분석과 운영 품질 개선이 가능하게 합니다.
• 수집된 로그·지표·추적 데이터는 제품 병목 구간을 파악하고, 처리 속도 개선과 장애 원인 분석의 핵심 자료가 됩니다.
• 이를 통해 테스트 → CI/CD → 관찰 가능성(Observability) → 아키텍처 피드백으로 이어지는 지속적 품질 개선 사이클이 형성됩니다.

• Fin<T> 오류를 포함한 결과 표현
  • Fin<T>는 성공(Succ) 또는 실패(Fail) 상태를 나타내는 값입니다. 이는 Either<Error, T>와 유사하지만, 오류 처리를 보다 간결하게 표현할 수 있도록 설계되었습니다.
    • 성공: Succ(value) 형태로 값을 포함합니다.
    • 실패: Fail(error) 형태로 오류 정보를 포함합니다.
  • 이러한 구조는 예외를 사용하지 않고도 오류를 명시적으로 처리할 수 있게 해줍니다.
• FinT<M, T>: 모나드 변환기(Monad Transformer)
  • FinT<M, T>는 Fin<T>를 다른 모나드 M과 결합하여 복합적인 효과를 처리할 수 있도록 하는 모나드 변환기입니다.
  • 예를 들어, FinT<IO, T>는 동기 및 비동기 IO 작업 중 발생할 수 있는 오류를 Fin을 통해 명시적으로 처리할 수 있게 합니다.
  • 이러한 구조는 여러 모나드를 결합하여 복잡한 효과를 처리할 때 유용하며, 오류 처리를 명확하게 표현할 수 있게 해줍니다.

TODO

• 001 | 솔루션 | 관심사의 분리 원칙 (Separation of Concerns Principle)
• 002 | 테스트 | 테스트 자동화
• 003 | 솔루션 | 프로젝트 구성
• 004 | 솔루션 | .NET SDK 버전 (global.json)
• 005 | 솔루션 | NuGet 저장소 소스 (nuget.config)
• 006 | 솔루션 | NuGet 패키지 버전 중앙 관리 (Directory.Packages.props)
• 007 | 솔루션 | 프로젝트 속성 중앙 관리 (Directory.Build.props)
• 008 | 솔루션 | 코드 스타일 중앙 관리 (.editorconfig)
• 009 | 솔루션 | 버전 중앙 관리
• 010 | 테스트 | 테스트 범주화
• 011 | 테스트 | 테스트 보고서 (ReportGenerator, Allure)
• 012 | 테스트 | 아키텍처 테스트 (ArchUnitNET)
• 013 | 테스트 | 도메인 규칙 테스트 (BDD: Reqnroll)
• 014 | 테스트 | 스냅샷 테스트 (Verify)
• 015 | 테스트 | 구조적 로그 테스트 (Microsoft.Extensions.Logging -> Serilog)
• 016 | 프로젝트 | 레이어별 어셈블리 정의 (AssemblyReference.cs)
• 017 | 프로젝트 | 레이어별 의존성 등록
• 018 | 프로젝트 | 클래스 기본 접근 제어자 (internal sealed)
• 019 | 프로젝트 | 에러 처리
• 020 | 프로젝트 | 소스 생성기 (IIncrementalGenerator)
• 021 | 레이어 | 도메인 레이어 | 값 객체
• 022 | 레이어 | 도메인 레이어 | 엔티티
• 023 | 레이어 | 애플리케이션 레이어 | 파이프라인
• 024 | 레이어 | 애플리케이션 레이어 | CQRS 메시지
• 025 | 레이어 | 애플리케이션 레이어 | 유스케이스
• 026 | 레이어 | 어댑터 레이어 | 옵션 유효성 검사 (appsettings.json)

단순한 Divide 구현을 출발점으로 삼아, 부작용 없이 예측 가능한 순수 함수(Pure Function)로 개선하고, 이를 통해 유효한 값만 표현할 수 있는 도메인 타입(Value Object)을 점진적으로 설계해 나가는 과정을 통해 도메인 주도 설계와 함수형 프로그래밍의 핵심 가치를 함께 익힙니다.

// 개선 전
int Divide(int x, int y)
{
  return x / y;
}

// 개선 후
int Divide(int x, NonZeroInt y)
{
  return x / y;
}

이 과정은 의미 있는 타입 설계, 입력 유효성 보장, 오류 처리의 명확화, 도메인 언어 강화 등을 아우르며, 유지보수성과 안정성이 높은 코드를 구성하는 기반을 마련합니다.

• 1. 시작은 단순한 나눗셈에서
• 2. 예외를 예방하려는 우리의 첫 시도
• 3. 실패도 값이다
• 4. 그 값이 문제라면, 애초에 들어오지 못하게 하자 (Always Valid)
• 5. 코드의 표현력을 더 풍부하게 (연산자 오버로딩)
• 6. 값이 같다면 객체도 같아야 한다 (값의 동등성)
• 7. 객체의 책임을 분리하자 (단일 책임 원칙: SRP)
• 8. 설계 규칙을 자동으로 검증하기
• 9. 타입으로 말하는 도메인

Scott Wlaschin "Designing with types" F# 코드를 C# 기반으로 재구성하는 글입니다.

• TODO

Amichai Mantinband "Clean Architecture" 템플릿을 함수형 기반의 도메인 주도 설계와 아키텍처로 재구성하는 글입니다.

• TODO

"Getting Started: Domain-Driven Design" 강의 예제를 함수형 기반의 도메인 주도 설계와 아키텍처로 재구성하는 글입니다.

• Part 1. Hexagonal 아키텍처 (도메인 레이어: 도메인 타입)
  • Chapter 01. 도메인 탐험
  • Chapter 02. 도메인 구조화
  • Chapter 03. 도메인 함수형화
  • Chapter 04. 도메인 Entity Id 소스 생성기
  • Chapter 05. 도메인 시나리오 테스트 (BDD: Cucumber)
• Part 2. Hexagonal 아키텍처 (애플리케이션 레이어: 유스케이스)
  • Chapter 06. 유스케이스 CQRS & Event
  • Chapter 07. 유스케이스 미들웨어
  • Chapter 08. 유스케이스 시나리오 테스트 (BDD: Cucumber)
• Part 3. Hexagonal 아키텍처 (어댑터 레이어)
  • Chapter 09. Web API
  • Chapter 10. IAdapter 인터페이스 소스 생성기
  • Chapter 11. 저장소 CQRS (Command: EF Core, Query: Dapper)
  • Chapter 12. 컨테이너화
  • Chapter 13. 통합 테스트
  • Chapter 14. 부하 테스트

• Part 1. Microservices 아키텍처
  • Chapter 01. Aspire
  • Chapter 02. RabbitMQ
  • Chapter 03. Resilience
  • Chapter 04. Reverse Proxy
  • Chapter 05. Chaos Engineering
• Part 2. 운영
  • Chapter 06. OpenFeature (Feature Flag 관리)
  • Chapter 07. OpenSearch (Observability)
  • Chapter 08. Ansible (Infrastructure as Code)
  • Chapter 09. Backstage (Building Developer Portals)

• TODO: "eShop"을 Functional 도메인 주도 설계와 아키텍처로 재구성하는 글입니다.
• TODO: "DevBetterWeb"을 Functional 도메인 주도 설계와 아키텍처로 재구성하는 글입니다.

• xUnit: 테스트
• TngTech.ArchUnitNET: 아키텍처 테스트
• coverlet: 코드 커버리지
• Shouldly: Fluent 테스트 검증
• NSubstitute: 인터페이스 Mocking
• Bogus: Fake 데이터 생성기
• Verify: 스냅샷 테스트
• Testcontainers: 컨테이너 테스트
• NBomber: 부하 테스트

• LanguageExt.Core: 함수형
• Dapr: 액터 모델
• MediatR: 기술 관심사와 도메인 관심사 간의 느슨한 결합 (Mediator 패턴)
• FluentValidation: 유효성 검사
• Ardalis.SmartEnum: 열거형 도메인 타입
• Ulid: Entity Id

• OpenTelemetry: 관찰 가능성 (Observability)
• Aspire: 분산 클라우드 네이티브
• FastEndpoints: Web API
• ZiggyCreatures.FusionCache: 메모리 캐시
• Wolverine: RabbitMQ
• Entity Framework Core: Command ORM
• Dapper: Query ORM
• Polly: Resilience
• Docker: 컨테이너
• RabbitMQ: 메시지 큐
• OpenSearch: 관찰 가능성 시스템