AI로 풀어보는 AI-DLC: Service를 이해하는 방법

본 기사의 위치— 본 기사는 awslabs/aidlc-workflows 리포지토리의 규칙군을 소재로 하여, 필자가 AI를 활용해 읽어내고 정리한 해석입니다. AWS가 공식적으로 발표한 방법론이 아니며, 1차 자료의 번역이나 요약도 아닙니다.

시리즈— 본 기사는 AI로 풀어보는 AI-DLC 시리즈의 일부입니다.

참조한 버전— 2026년 5월 시점에서 공개되어 있는 v0.1.8 (2026년 4월 20일 릴리스)의 aidlc-rules/를 참조하고 있습니다. OSS 구현은 업데이트가 계속되고 있으므로, 최신 상태는 공식 리포지토리를 확인해 주시기 바랍니다.

1. 서론

AI-DLC의 워크플로우를 실행하다 보면, Service라는 단어를 몇 번이고 마주하게 됩니다. Application Design, Units Generation, Infrastructure Design, Code Generation, Build and Test ── 어느 장면에서든 사용되지만, 같은 단어가 장면마다 서로 다른 것을 가리키는 것처럼 보여 처음에는 당혹스러울지도 모릅니다.

하지만 이는 용어 정리가 허술해서가 아니라, 각 스테이지의 규칙이 다루는 관심 영역이 다르기 때문에 Service라는 단어가 각각의 문맥에 맞춰 구분되어 사용되고 있는 것입니다. 본 기사에서는 각 스테이지의 규칙 기술로부터 Service의 의미를 읽어내어, 독자가 문맥에 따라 적절한 의미를 선택할 수 있도록 정리합니다.

또한 본 기사에서는 규칙 본문의 영어 표기를 그대로 인용하기 때문에, 「Service」, 「service layer」, 「services」가 혼재합니다. 본문에서는 처음 등장하거나 의미가 바뀌는 부분에서 「Service(협조 역할)」, 「Service(독립 배포 단위)」와 같이 괄호로 의미를 보충하여, 문맥과 의미의 대응을 읽기 쉽게 하겠습니다.

구체적으로는 Application Design · Units Generation에서의 취급을 차례로 확인하고 (§2 · §3), 그 후에 구현 단계 이후에서의 나타남을 살펴봅니다 (§4). 이어서 각 스테이지에서 Service의 구체적인 내용이 어떻게 확정되는지 정리하고 (§5), 마지막으로 문맥으로 구분하여 읽는 관점을 정리합니다 (§6).

2. Application Design에서의 Service: service layer / orchestration

Application Design 스테이지에서 로드되는 inception/application-design.md에는 Service에 대해 다음과 같은 기술이 있습니다.

High-level component identification and service layer design
개요 수준에서의 Component 식별과 service layer 설계

Designing service layer for orchestration
오케스트레이션 (orchestration)을 담당하는 service layer 설계

Service Layer Design- Ask about service orchestration, boundaries, and coordination patterns
Service Layer Design— Service의 오케스트레이션 (orchestration), 경계, 협조 패턴에 대해 질문하기

Create aidlc-docs/inception/application-design/services.md with:

Service definitions
Service responsibilities
Service interactions and orchestration

다음 내용을 포함하여 aidlc-docs/inception/application-design/services.md를 생성한다:

Service의 정의
Service의 책임
Service의 상호작용과 오케스트레이션 (orchestration)

여기서의 Service(협조 역할)는, 복수의 Component를 협조시키는 오케스트레이션 (orchestration) 계층으로 위치 지어져 있습니다. 「service layer」, 「orchestration」, 「coordination patterns」와 같은 단어가 일관되게 사용되고 있으며, Service 자체가 비즈니스 로직의 주체가 되는 것이 아니라, 로직의 본체를 Component에 위임하면서 호출 순서나 조합을 조율하는 계층으로서 정의되어 있습니다.

또한, 여기서의 Service는 Component를 호출하고, 그 결과를 조합하여 반환하는 위치에 있습니다. Component 자체의 취급은 본 기사의 대상이 아니지만, 「Service가 호출하는 상대」가 별도의 단위로서 존재한다는 점만 짚고 넘어가겠습니다.

이 단계에서 정의되는 Service는 코드 내부에 있는 논리적인 계층입니다. 설계 산출물로서는 services.md라는 하나의 문서로 집약되며, 다음 단계로 넘어가는 입력 소재가 됩니다.

3. Units Generation에서의 Service: independently deployable

Units Generation은 Application Design의 후속 단계에 위치하는 스테이지입니다. Application Design에서 식별된 Component나 service layer의 설계를 받아, 이를 개발·배포의 단위(Unit of Work)로 다시 할당하는 역할을 담당합니다. 이 단계에서 로드되는 inception/units-generation.md에서는 Service의 의미가 전환됩니다.

A unit of work is a logical grouping of stories for development purposes. For microservices, each unit becomes an independently deployable service. For monoliths, the single unit represents the entire application with logical modules.

Unit of Work는 개발 편의를 위해 스토리를 하나로 묶은 논리적인 단위입니다. 마이크로서비스(Microservices)를 채택한 경우, 각 Unit이 그대로 독립적으로 배포 가능한 Service가 됩니다. 모놀리스(Monoliths)를 채택한 경우, 단일 Unit이 애플리케이션 전체에 대응하며 그 내부에 논리 모듈이 포함됩니다.

Use "Service" for independently deployable components, "Module" for logical groupings within a service, "Unit of Work" for planning context.

독립적으로 배포 가능한 구성 요소에는 "Service", Service 내의 논리적인 묶음에는 "Module", 계획 컨텍스트에서는 "Unit of Work"를 사용합니다.

Application Design stage REQUIRED (determines components, methods, and services)

Application Design 스테이지는 필수입니다 (Component, Method, Service를 결정함)

여기서의 Service(독립 배포 단위)는 독립적으로 배포 가능한 시스템 구성 단위를 가리킵니다. 마이크로서비스를 채택한 경우, Units Generation에서 식별된 각 Unit of Work가 그대로 하나의 Service와 대응하게 됩니다. Service, Module, Unit of Work라는 세 가지 용어가 독립 배포 단위 / 그 내부의 논리 그룹 / 계획 문맥에서의 명칭으로 명시적으로 구분되어 사용되고 있습니다.

§2에서 본 Service(조율 역할)가 「코드 내부에 있는 협조 계층」이었던 것에 반해, 여기서의 Service(독립 배포 단위)는 「배포 가능한 시스템 단위」입니다. 성질도 입도(Granularity)도 크게 다릅니다. 전자는 1개의 애플리케이션 내부에 복수 존재할 수 있는 논리적인 레이어(Layer)이며, 후자는 그 자체가 애플리케이션으로서 외부에 공개되는 시스템 단위입니다.

두 가지가 무관하게 나열되어 있는 것이 아니라, 의존 관계를 가집니다. Units Generation의 전제 조건으로 「Application Design stage REQUIRED」라고 명시되어 있는 것처럼, Application Design에서 정의된 service layer의 정보가 Units Generation의 입력 소재가 됩니다. 두 가지는 별개의 것이지만, Application Design의 services.md가 Units Generation에서 각 Unit의 경계를 나눌 때의 소재로 참조되는 관계입니다.

워크플로(Workflow) 계획 측면에서도 이러한 대비를 읽어낼 수 있습니다.

Application Design - Execute IF:

새로운 Component 또는 Service가 필요함
Component의 Method 및 비즈니스 규칙 정의가 필요함
Service layer 설계가 필요함

여기서의 「services」, 「Service layer」는 service layer 측을 가리키는 것으로 읽힙니다. Application Design 실행의 판단 재료로 사용되고 있으며, 동일한 용어가 계획 단계의 판단 조건으로서도, 독립 배포 단위(Independent deployment unit)로서도 등장합니다. 이를 해석할 때는 문맥을 의식할 필요가 있습니다.

4. 구현 단계 이후에서의 Service

Construction 페이즈에 들어가면, Service라는 용어는 더욱 다른 의미로 사용됩니다. Infrastructure Design에서는 클라우드 측의 매니지드 서비스(Managed Service)를 가리키고, Code Generation에서는 디렉토리명으로 사용되며, Build and Test에서는 운영 시의 엔드포인트(Endpoint)를 가리킵니다. 여기서는 세 가지 상황을 차례로 확인합니다.

Infrastructure Design: 매니지드 서비스로서의 Service

Infrastructure Design 스테이지에서 로드되는 construction/infrastructure-design.md에는 논리적인 Component를 실제 인프라에 대응시킨다는 목적이 기재되어 있습니다.

Map logical software components to actual infrastructure choices for deployment environments.

논리적인 Component를 배포 환경을 위한 실제 인프라 선택지로 매핑한다.

Focus on mapping to actual services (AWS, Azure, GCP, on-premise)

실제 서비스(AWS, Azure, GCP, on-premise)로의 매핑에 초점을 맞춘다.

여기서 언급되는 「actual services」는 클라우드 프로바이더가 제공하는 매니지드 서비스(Managed Service, 이하 「매니지드 서비스」)를 가리킵니다. AWS라면 Lambda, ECS, Fargate, EC2 등이 선택지가 됩니다 (이러한 구체적인 명칭은 규칙 본문에 나열된 것이 아니라 문맥에서 도출된 대표적인 예시입니다). Units Generation에서 분리된 각 Service(독립 배포 단위)를 어떤 매니지드 서비스에 올릴 것인가 하는 대응 작업이 이 단계에서 이루어집니다.

「Service」라는 용어는 여기에서 클라우드 측에서 제공되는 매니지드 서비스를 가리키기 위해 사용됩니다. 설계 시의 논리적 단위가 아니라, 배포 대상이 되는 실체적인 그릇을 의미합니다.

src/services/라는 디렉토리

Code Generation: Code Generation 스테이지에서 로드되는 construction/code-generation.md에는 생성되는 코드의 구조에 관한 기술이 있습니다.

For this unit, include:

이 Unit에 대해 다음을 포함한다:

이 Unit이 구현하는 Stories
다른 Unit/Service에 대한 의존성 (Dependencies)
기대되는 인터페이스 (Interfaces) 및 계약 (Contracts)
이 Unit이 소유한 데이터베이스 엔티티 (Database entities)
Service의 경계 (Boundaries) 및 책임 (Responsibilities)

Brownfield: 수정된 파일과 생성된 파일을 구분 (예: "• Modified: src/services/user-service.ts"

", "• Created: src/services/auth-service.ts

)

Greenfield: 생성된 파일을 경로와 함께 나열 (예: "• Created: src/services/user-service.ts

Brownfield: 수정된 파일과 신규 생성된 파일을 구분 (예: "• 수정: src/services/user-service.ts

", "• 신규 생성: src/services/auth-service.ts

Greenfield: 생성된 파일을 경로와 함께 기재 (예: "• 신규 생성: src/services/user-service.ts

Greenfield, 다중 유닛 (Microservices): {unit-name}/src/, {unit-name}/tests/

Greenfield, 다중 유닛 (Monolith): src/{unit-name}/, tests/{unit-name}/

여기서 Service는 두 가지 형태로 디렉터리 이름으로 사용됩니다.

외부 디렉터리 이름
{unit-name}: Microservices 채택 시 Unit과 일치하는 독립 배포 단위 (Independent Deployment Unit)를 나타냅니다. §3의 Service (독립 배포 단위)에 대응합니다.
내부 디렉터리 이름
src/services/: 코드 내의 오케스트레이션 (Orchestration) 계층을 담는 장소를 나타냅니다. §2의 Service (협조자)에 대응합니다.

src/services/user-service.ts와 같은 명명은 Application Design의 services.md에서 정의된 service layer가 구현 시 이 디렉터리에 대응함을 나타냅니다. 설계 단계의 용어가 디렉터리 구조로서 구현 단계까지 그대로 이어지고 있습니다.

Build and Test: 운영 시의 Service Endpoints

Build and Test 단계에서 로드되는 construction/build-and-test.md에서는 테스트 실행 및 운영 맥락에서 Service (독립 배포 단위)가 사용됩니다. 먼저, Service (독립 배포 단위)가 유닛 간의 상호작용을 검증하는 대상으로 다뤄지고 있음이 Integration Test의 목적에 명시되어 있습니다.

Test interactions between units/services to ensure they work together correctly.

Unit / Service 간의 상호작용을 테스트하여 이들이 올바르게 연동되는지 확인한다.

다음으로, 그 상호작용이 엔드포인트 (Endpoint)를 통해 이루어진다는 전제를 테스트 환경의 설정 절차에서 읽을 수 있습니다.

2. Configure Service Endpoints

2. Service의 엔드포인트를 설정한다

나아가, Microservices를 위한 추가 테스트로서 Service 간 API의 컨트랙트 (Contract) 검증이 언급되어 있습니다.

API contract validation between services

Service 간의 API 컨트랙트 검증

여기서 Service는 배포되어 가동 중인 독립 배포 단위를 가리킵니다. 엔드포인트를 가지며, 네트워크를 통해 호출되고, API 컨트랙트를 통해 연동되는 실체입니다. "services"라고 복수형으로 표기된 부분은 §3의 Service (독립 배포 단위)가 운영 시에 어떻게 동작하는지를 보여줍니다.

구현 단계 이후부터는 이와 같이 Service가 "클라우드의 매니지드 서비스 (Managed Service)", "코드 내의 디렉터리 이름", "가동 중인 독립 배포 단위"라는 세 가지 의미로 사용됩니다. 모두 이전 단계의 정의를 계승한 것이지만, 문맥에 따라 대상이 되는 측면이 다릅니다.

5. 규칙은 성질을 정하고, 요구사항은 단위를 확정한다

지금까지 각 스테이지에서의 Service 처리에 대해 살펴보았습니다. 다시 한번 깨닫게 되는 점은, 규칙이 정하고 있는 것은 Service의 성질이나 역할이지, **구체적인 단위의 수나 입도(Granularity)**가 아니라는 사실입니다. Service의 윤곽을 최종적으로 결정하는 것은 사용자가 가져오는 요구사항이나 선언입니다. 각 스테이지에서 무엇이 정해지고, 무엇이 위임되는지를 정리하겠습니다.

Application Design: 협조자라는 성질을 정한다

Application Design의 규칙은 Service(협조자)의 성질(비즈니스 로직의 주체가 아닌 협조 계층·오케스트레이션 지향)과 생성되는 문서(services.md)의 구조를 정합니다. 반면, 무엇을 하나의 Service로 묶을 것인가에는 관여하지 않습니다.

동일한 성질을 만족하는 단위 설정 방식으로서, 예를 들어 다음과 같은 형태들이 모두 성립할 수 있습니다.

유스케이스(Use Case) 1건을 1 Service로 하는 방식: PlaceOrderService와 같이 특정 조작 시나리오를 단위로 합니다. Service의 수는 유스케이스의 수에 비례하며, 하나의 Service는 단일 목적의 협조 절차를 담당합니다.
도메인의 애그리거트(Aggregate) 1개를 1 Service로 하는 방식: OrderService와 같이 주문 도메인 전체를 단위로 합니다. Service의 수는 도메인 애그리거트의 수에 대응하며, 하나의 Service가 동일 도메인 내의 여러 조작을 다룹니다.
여러 유스케이스를 묶은 파사드(Facade)를 1 Service로 하는 방식: OrderingService와 같이 Place/Cancel/Refund와 같은 관련 조작군을 모은 창구로 만듭니다. Service의 수는 기능군(업무 영역)의 수에 대응하며, 하나의 Service가 외부에서 보기에 일관된 API 면을 제공합니다.

어떤 방식을 채택할지는 유스케이스의 수나 복잡성, 채택하는 설계 방법론, 도메인의 범위와 같은 사용자 요구사항에 따라 결정됩니다.

Units Generation: 아키텍처 선언이 단위를 확정한다

Units Generation의 규칙은 "마이크로서비스(Microservices)라면 Unit = Service", "모놀리스(Monolith)라면 Unit 전체 = 애플리케이션"이라는 대응 관계를 정합니다. 다만, 어느 쪽을 채택할지는 규칙이 결정하는 것이 아니라 사용자가 선언하는 아키텍처에 의존합니다.

units-generation.md:8이 "For microservices, each unit becomes an independently deployable service", "For monoliths, the single unit represents the entire application"라고 조건부로 기술하고 있는 점에서도 이 부분을 읽어낼 수 있습니다.

마이크로서비스를 선언한 경우, 사용자 요구사항에 따라 Unit이 몇 개로 분리될지, 그리고 각각이 독립 배포 단위인 Service와 대응할지가 결정됩니다. 모놀리스를 선언한 경우, 독립 배포 단위로서의 Service는 생기지 않으며, Unit은 애플리케이션 전체를 나타내는 덩어리가 됩니다.

Infrastructure Design: 매핑 방침을 정하고, 선택을 위임한다

Infrastructure Design의 규칙은 "논리적 Component를 실제 인프라에 매핑한다"는 방침까지를 정하며, 어떤 매니지드 서비스(Managed Service)를 선택할지는 사용자에게 위임합니다.

선택을 좌우하는 것은 클라우드 프로바이더(Cloud Provider)의 선정, 가용성이나 비용 요구사항, 기존 자산과의 정합성, 스케일링(Scaling) 특성 등 프로젝트 고유의 사정입니다. 동일한 Service(독립 배포 단위)라도 Lambda에 올릴지, ECS / Fargate에 올릴지, EC2에 올릴지에 따라 운용의 모습이 달라집니다.

Code Generation · Build and Test: 언어·운용 환경이 형태를 확정한다

Code Generation에서는 Service(협조자)가 src/services/user-service.ts와 같은 파일로서 구현과 대응됩니다. 클래스로 만들지 혹은 함수군으로 만들지, 어떤 프레임워크 스타일을 따를지와 같은 점은 규칙이 지정하는 것이 아니라, 채택하는 언어·프레임워크·코딩 규약에 따라 구체적인 형태가 결정됩니다.

Build and Test 단계에서는 Service(독립 배포 단위)가 엔드포인트(Endpoint)를 가진 가동 실체로서 취급됩니다. 어떤 포트(Port)로 공개할지, 어떤 프로토콜(Protocol)로 연계할지, 어떤 테스트를 통과할지 등의 사항은 프로젝트의 운영 요건에 따라 확정됩니다.

요약

각 스테이지(Stage)에서 규칙이 정하는 것은 Service의 성질이나 역할까지이며, 구체적인 단위의 수나 입도(Granularity), 형태는 사용자 요건(채택하는 아키텍처, 설계 방법론, 클라우드 선택, 언어·프레임워크)이 확정합니다.

스테이지	규칙이 정하는 것	단위를 확정시키는 요건
Application Design	협조층이라는 성질 (로직 본체는 가지지 않음)	채택하는 설계 방법론
...
규칙이 Service가 취할 수 있는 공간을 제시하고, 사용자 요건이 그 안의 한 점을 선택하는 구조로 되어 있습니다.

6. 마치며

본 기사를 통해 전달하고 싶었던 것은, "Service"라는 단어를 만났을 때 그 자리에서 문맥(Context)을 확인하는 관점을 갖는 것의 중요성이었습니다. AI-DLC의 문서군에서는 스테이지마다 서로 다른 관심 영역이 있으며, 그 관심 영역에 맞춰 Service가 서로 다른 것을 가리킵니다. 문맥에 따라 구분해서 읽을 수만 있다면, 용어의 다중성은 혼란이 아니라 자신의 상황에 대응하는 의미를 선택하기 위한 여지로 작용합니다.

실무에서 이 관점을 사용할 때의 지표가 되는 것은 자신이 지금 어떤 문서를 읽고 있는가입니다. 다음의 요약표를 참고하여 문서와 스테이지로부터 문맥을 읽어내시기 바랍니다.

읽고 있는 문서	Service가 가리키는 것
`services.md` / `application-design.md`	협조 역할 (service layer)
`unit-of-work.md`	독립 배포 단위
`infrastructure-design.md`	매니지드 서비스 (Managed Service)
`{unit-name}-code-generation-plan.md` 하위의 코드 (`src/services/` 포함)	구현상의 협조층
`integration-test-instructions.md` / `contract-test-instructions.md`	동작하는 엔드포인트

그리고 또 하나, §5에서 보았듯이 규칙이 정하는 것은 Service의 성질이나 역할까지입니다. 얼마나 나눌 것인지, 어떤 입도로 나눌 것인지와 같은 구체적인 사항은 사용자의 요건과 환경이 결정합니다. 규칙은 성질을 정하고, 구체적인 사항은 요건으로 결정한다는 구조를 이해한다면, 용어의 다중성은 혼란이 아니라 자신의 상황에 맞춰 의미를 선택하기 위한 여지로 해석할 수 있습니다.