codex 와 함께 마이크로 서비스 시작하기

Codex와 함께 마이크로서비스 프로젝트 시작하기

로

Codex와 함께 마이크로서비스 프로젝트를 시작하지 않고 마이크로서비스 아키텍처(MSA)를 처음부터 직접 구축하는 건 꽤나 복잡한 작업이다.
각 서비스의 역할 분리, 통신 방식, 인증 처리, 테스트 환경 등 고려할 것이 많다.
하지만 AI 코딩 어시스턴트인 GitHub Copilot의 기반 모델 중 하나인 Codex를 활용하면, 이러한 과정을 좀 더 수월하게 진행할 수 있다.
이 글에서는 Codex를 이용해 마이크로서비스 프로젝트를 시작하는 첫 단계부터 함께 해본 경험을 기록해본다.

프로젝트를 시작하는 방법

GitHub 저장소 생성과 연결

Codex로 생성한 프로젝트 구조를 실제 개발 환경에 반영하려면, 코드 버전 관리와 협업을 위한 저장소가 필요하다.
가장 일반적인 방식은 GitHub에 저장소를 만들고, 로컬 프로젝트와 연결하는 것이다.
다음은 내가 진행한 절차다.

GitHub 저장소 생성

  1. GitHub에 로그인하고, 오른쪽 상단의 “+” 버튼을 눌러 New repository를 선택한다.
  2. 저장소 이름을 msa-project로 설정하고, Private 또는 Public 여부를 선택한 뒤 Create repository 버튼을 클릭한다.
  3. 저장소를 만든 후, GitHub에서 제공하는 초기화 명령어들을 확인할 수 있다.

로컬 프로젝트와 GitHub 저장소 연결

Codex가 생성한 프로젝트 구조를 로컬에 저장한 뒤, Git 초기화 및 원격 저장소 연결을 진행한다:

cd msa-project
git init
git add .
git commit -m "Initial commit with Codex-generated MSA structure"
git remote add origin https://github.com/사용자명/msa-project.git
git push -u origin master
codex로 작업하기 위해 github에 연결하는 화면

이 과정을 통해 Codex가 생성한 프로젝트 구조가 GitHub 저장소에 업로드된다.
이후에는 각 서비스별로 브랜치를 나눠 개발하거나, Pull Request 기반으로 협업을 이어갈 수 있다.

이렇게 초기 세팅을 마치고 나면, Codex에게 구체적인 기능을 단계별로 요청하면서 버전 관리를 병행할 수 있어 작업의 추적성과 협업 효율이 크게 향상된다.
GitHub와 Codex의 조합은 마이크로서비스 아키텍처를 빠르고 체계적으로 구축하는 데 있어 강력한 도구가 되어준다.

프로젝트를 시작할 때 가장 먼저 고민하는 것은 전체 구조와 서비스 분리 기준이다.
나는 Codex에게 다음과 같은 프롬프트로 접근을 시작했다:

현재 디렉토리는 읽기 전용이라 `/workspace/editable-msa-project` 경로에 복사해서 작업해줘.

develop 브랜치를 새로 만든 뒤 다음과 같이 프로젝트를 구성해줘:

- 프로젝트 루트의 `settings.gradle.kts`에는 다음 모듈을 포함해줘: config-server, discovery-server, gateway-service, auth-service, user-service, public-service, common-lib

- 루트의 `build.gradle.kts`에는 kotlin("jvm"), spring boot, dependency-management 플러그인을 설정하고, 모든 하위 프로젝트에 mavenCentral() 저장소를 사용하도록 해줘

- `common-lib` 모듈을 생성하고 내부에 JwtUtil.kt 파일을 만들어줘 (createToken, verifyToken 포함)

- 각 서비스 모듈(config-server, discovery-server, gateway-service, auth-service, user-service, public-service)은 모두 독립적인 Spring Boot 애플리케이션이야. 각각 다음 구조를 갖게 생성해줘:
  - `MainApplication.kt` (SpringBootApplication)
  - `HelloController.kt` ("/hello" API 반환)
  - `application.yml` (application name 설정)

- 각 서비스의 `build.gradle.kts`에는 공통으로 다음 의존성을 포함해줘:
  - spring-boot-starter-web
  - spring-boot-starter-actuator
  - jackson-module-kotlin
  - kotlin-reflect
  - project(":common-lib")
  - spring-boot-starter-test (testImplementation)

작업이 완료되면 develop 브랜치 상태를 보여줘.

Codex는 상당히 그럴듯한 폴더 구조와 초기 파일들을 제안해줬다.
다음은 Codex가 생성해준 기본 폴더 구조 예시다:

msa-project/
├── auth-service/
├── user-service/
├── order-service/
├── common/
└── README.md

각 서비스에는 src/main/kotlin, src/main/resources, 그리고 build.gradle.kts 가 포함되어 있었고, Spring Boot 애플리케이션의 기본 틀이 잘 갖춰져 있었다.

첫 코드 생성 요청

구조를 잡은 뒤에는 각 서비스에 초기 코드를 생성하는 작업이 필요하다.
나는 Codex에게 다음과 같은 요청을 해봤다:

각 서비스에 기본적인 Spring Boot Application 클래스를 생성해줘. 포트는 auth는 8081, user는 8082, order는 8083으로 설정해줘.

Codex는 @SpringBootApplication이 포함된 메인 클래스를 각각의 서비스에 생성해줬고, application.yml 파일에 포트 설정도 자동으로 반영했다.
물론 완벽하지는 않았다.
일부 설정은 누락되거나 다른 서비스와 겹치는 경우도 있었지만, 이러한 부분은 수동으로 조정하거나 Codex에게 다시 요청하여 수정할 수 있었다.

codex가 프롬프트를 기반으로 브랜치명을 자동으로 생성한 결과

또한 지시한 프롬프트를 기반으로 브랜치명을 자동으로 생성하므로 프롬프트에서 브랜치명을 지정하는 방식이 바람직하다.

spring-boot 프로젝트에 user-service 디렉토리를 만들고 userController 클래스를 생성해줘.  <br>그리고 브랜치 이름은 `feature/user-controller`로 만들어줘.

AI와 협업하며 얻은 인사이트

Codex와의 협업은 단순히 코드를 “자동 생성”하는 차원을 넘어선다.
무엇을 어떻게 지시하느냐에 따라 결과가 달라지고, 때로는 내가 미처 생각하지 못한 구조를 제안하기도 한다.
처음에는 한 문장으로 명령을 내렸지만, 점점 더 구체적으로 조건을 붙이게 되면서 나 스스로도 아키텍처 구성에 대해 더 깊이 고민하게 되었다.

Codex에게 효과적으로 지시하는 팁

  • 구체적인 기술 스택과 구조를 함께 명시하자 (예: Spring Boot + Maven + REST API)
  • 생성하려는 코드의 목적과 역할을 분명히 설명하자
  • 예시를 함께 제공하면 결과물이 개선된다

Codex와 함께 마이크로서비스 프로젝트를 시작하는 경험은 꽤 유익했다.
완벽하게 모든 코드를 만들어주지는 않지만, 초기 구조를 빠르게 잡고 반복적인 작업을 줄이는 데 큰 도움이 된다.
중요한 것은 Codex를 단순한 코드 생성기가 아닌, 개발 파트너로 인식하고 적극적으로 활용하는 자세다.
다음 포스트에서는 Codex에게 OAuth2 인증 서비스를 구현하도록 요청한 경험을 공유해볼 예정이다.

참고

자세한 코드는 아래 저장소에서 확인 가능하다.
Github – 저장소

댓글 남기기

© 2012 Yapsoft