지난 포스트에서 global을 적용했다. 이번엔 envs/dev를 적용하고 서비스를 실제로 띄운다. 이 단계에서 validate와 plan을 통과한 코드가 apply에서 깨지는 경험을 여러 번 했다. 하나씩 정리한다. 순서 flowchart LR A[envs/dev plan] --> B[이미지 빌드·ECR push] B --...

지난 포스트에서 코드 구조를 잡았다. 이번엔 실제로 AWS에 연결하고 global 스택을 적용한다. 코드가 이미 있어도 실행 환경을 맞추는 단계에서 의외로 시간이 많이 걸렸다. 전체 순서 검증: fmt, validate (AWS 불필요) AWS CLI 로그인 state를 저장할 S3 버킷 만들기 terraform init, pl...

지난 포스트에서 앱을 만들었다. 이번엔 이걸 올릴 인프라를 Terraform 코드로 어떻게 나눠 짤지 정리한다. 코드를 쓰기 전에 구조부터 잡는 게 중요한 이유는, 나중에 바꾸기 가장 어려운 게 디렉터리 경계와 state 경계이기 때문이다. 세 덩어리로 나눈다 infra/terraform/ ├── global/ # 계정 공통: EC...

지난 포스트에서 전체 그림을 봤다. 이번엔 Terraform이 올릴 대상 앱을 만든다. 목적이 인프라 테스트라서 앱은 최대한 단순하게 만든다. 프로젝트 구조 실제로 운영 중인 MSA 프로젝트와 같은 모양으로, Gradle 멀티모듈로 서비스를 나눴다. terraform-study/ ├── settings.gradle.kts ├── build.g...

Terraform을 제대로 써본 적이 없어서, 실제 MSA 구조를 흉내 낸 테스트 프로젝트를 만들고 AWS ECS(Fargate)에 올려보기로 했다. 코드로 인프라를 만들고, 서비스를 띄우고, 브라우저에서 응답을 확인하고, 다시 전부 지우는 것까지가 목표다. 이 포스트는 그 과정 전체를 요약하고, 시리즈 전체의 인덱스 역할을 한다. 무엇을 만들었...

앞의 두 편(개념·동기, 아키텍처)이 글로 설명한 내용이라면, 이번엔 실제 화면이다. 블로그용으로 데모 팀 하나를 새로 만들고, 직원을 추가하고, 실제로 티켓 하나를 끝까지 돌려봤다. (평소 쓰는 팀에는 실제 회사 프로젝트 데이터가 들어있어서, 노출되면 안 되는 정보라 이번 데모는 별도 팀으로 진행했다.) 1. 빈 조직도 — 팀 하나 새로 만들기...

지난 포스트에서 ai-crew가 왜 필요했는지 다뤘다. 이번엔 실제로 어떻게 짜여 있는지 — 모노레포 구성, 배포 토폴로지, 티켓 하나가 큐에 들어가서 완료될 때까지 거치는 경로를 정리한다. 모노레포 구성 pnpm workspace 하나에 서버·프론트·러너·공유 타입이 다 들어있다. 혼자 개발하고, 서버·UI·러너가 티켓/이벤트 타입을 공유해야...

Claude Code 하나로 사이드 프로젝트를 여러 개 굴리다 보니 매번 같은 패턴을 반복하고 있었다. 터미널을 열고, 어느 프로젝트인지 확인하고, 컨텍스트를 설명하고, 작업을 시키고, 결과를 확인한다. 프로젝트가 7개면 이 사이클을 7번 반복한다. 그래서 “회사”를 하나 만들기로 했다. 팀장 1명이 요청을 받아 작업을 쪼개고, 적합한 직원에게 티켓...

personal-assistant를 배포하는 Jenkins 파이프라인이 갑자기 실패했다. 원인을 하나씩 쫓아가다 보니 겉으로 보인 에러들은 전부 곁가지였고, 진짜 문제는 몇 주 전에 실수로 설치된 snap docker가 도커 소켓을 조용히 가로채고 있었다는 것이었다. 삽질한 순서 그대로 정리한다. 문제 상황 personal-assistant 배포가...

이전 글에서 gateway → Azure Event Hubs(Kafka) → gateway-consumer-mongo 파이프라인을 구성한 이야기를 정리했다. 이번 글은 그 뒤에 이어지는 이야기로, MongoDB에 데이터를 저장하는 방식을 일별(YYYYMMDD) 컬렉션 구조에서 Time Series Collection 하나로 전환하면서 겪은 시행착오를 ...