서론
원코 프로젝트는 TAVE 16기 후반기 연합 팀 프로젝트입니다.
듀오링고, 말해보카와 같은 학습 플랫폼에서 "경제"라는 주제로
"AI가 알려주는 하루 10분 매일 경제 공부 플랫폼", "One Day Economy" 원코 서비스를 기획했습니다.
그러나,
"그래서 사람들이 왜 우리 서비스를 사용해야 하지?"라는 질문에 답을 하지 못했었습니다.
그래서 새롭게 기획하게 된 "부모-자녀 페어링 기반 경제·금융 키워드 교육 서비스"
원코는 부모와 자녀가 함께 학습을 계획하고, 자녀에게 보상이라는 학습 동기를 부여하는 경제 금융 서비스입니다.
본론
새로운 기술과 근사한 아키텍처를 프로젝트에 도입하고 싶은 마음은 개발자라면 모두 공감하실 것 같습니다.
저도 이때 당시 새로운 Tech Stack, Architecture 등 공부한 내용들을 적용해보고 싶었습니다.
전반기 스터디에서 학습한 멀티 스레드를 활용해보고 싶었고,
"대기업은 MSA를 사용한대, 그럼 우리도 MSA 도입해 볼까?"와 같은 고민을 했었습니다.
그러나 우리의 서비스는 수십만의 트래픽이 몰리는 서비스가 아니라는 점
개발 기한이 길지 않으며 클라우드 호스팅 비용 지원을 받지 않는다는 점에서 과감하게 지워버렸습니다.
그래서 우리는 최소한의 인프라로 최대의 효율을 뽑을 수 있는 "가성비 아키텍처"를 설계했습니다.
우리에게 주어진 인스턴스는 프리디어 EC2 micro.t2 단 한대로 개발했습니다.
우리에게 가장 익숙한 Spring Boot, Spring Data JPA, MySQL 그리고 필요하다면 Redis 도입을 설계했습니다.
Docker로 "프로세스 단위 컨테이너" 구성
독립성과 단순화
EC2 인스턴스 안에서 Spring 서버 / MySQL / Redis를 각각 독립 컨테이너로 띄워 운영했습니다.
프로세스를 컨테이너로 분리해두면 각 컴포넌트가 서로의 실행 환경에 영향을 덜 주고,
장애 / 재시작/ 로그 확인 / 버전 관리 같은 운영 행위가 훨씬 단순해집니다.
즉, "한 서버 안에 여러 프로세스가 섞여 있는 상태"가 아니라 역할별로 경계가 명확한 실행 단위로 설계했습니다.
또한 이 구성을 Docker Compose로 관리했습니다. Compose 파일 하나로 컨테이너 간 네트워크 의존성, 환경 변수, 볼륨, 포트, 헬스체크까지 묶어서 관리할 수 있어 배포/ 서버 재구성 시 재현성이 높아지는 장점이 있어 선택했습니다. 결과적으로 "운영 서버에서 수작업으로 설치하고 맞추는 과정"을 단순화 하고, 동일한 구성을 어디서든 재현할 수 있도록 했습니다.
다만, 실제 운영 전략으로 EC2에는 Spring 애플리케이션만 운영하도록,
DB / 캐시는 추후 관리형 서비스(RDS, ElastiCache)로 분리하는 방향으로 계획중입니다.
그럼에도 불구하고, 현재 단계에서는 Compose 기반 컨테이너화 전략이 지금 필요한 수준의 운영 관리 + 미래 운영 구조로의 마이그레이션 용이성을 고려했을 때 적합하다고 판단했습니다.
AWS SSM 도입
이번 프로젝트에서 처음으로 AWS Systems Manager(SSM)을 도입했습니다.
기존 SSH 방식의 한계
기존에는 EC2에 접속하기 위해 SSH(22번 포트)를 열어두고, 팀원들이 pem 키를 공유해 인스턴스에 접속하는 방식을 사용했습니다.
이 방식은 설정이 단순하고 널리 알려져 있어 시작은 쉽지만, 운영 관점에서는 다음과 같은 부담이 있었습니다.
- 인바운드 22 포트 개방 필요
서버에 "외부에서 들어올 수 있는 접속 경로"가 상시 열려있어야 했습니다. - pem 키 관리 부담
팀 단위 운영에서는 키를 공유/보관/회수하는 과정이 필요해지고, "접속 권한 관리"가 키 파일에 의존하게 됩니다.
정리하자면, SSH 방식은 편리하지만 보안그룹에서 반드시 열어야하는 진입점(22)과 키 기반의 접근 관리가 부담이었습니다.
SSM 방식으로 전환
SSM은 SSH처럼 외부에서 EC2의 22번 포트로 들어가는 방식이 아니라, EC2 인스턴스 내부의 SSM Agent가 AWS SSM 서비스와 먼저 통신 채널을 만들어두는 구조입니다.
- 개발자는 콘솔/CLI에서 SSM 세션을 시작할 때 IAM 인증을 거칩니다.
- EC2 내부의 SSM Agent는 AWS SSM 서비스와 Outbound 443(TLS) 연결을 통해 통신합니다.
- 그 결과, 터미널 명령/응답은 SSM 서비스를 경유해 전달됩니다.
즉,
접속 흐름은 "외부(개발자)에서 서버로 직접 진입"이 아니라, "AWS 서비스와의 통신을 통해 서버에 명령을 전달"하는 형태로 바뀝니다.
SSM 도입 이후 가장 큰 변화는 보안그룹 설계가 단순해지고, 서버의 외부 노출이 줄었다는 점입니다.
- SSM 접속을 전제로 하지 않기 때문에 인바운드 22 포트를 열 필요가 없어졌고
- 결과적으로 EC2 인스턴스가 외부로부터 직접 "접속받는" 형태가 줄어들어 외부 노출 면적을 축소할 수 있었습니다.
결론
원코는 "AI로 매일 10분 경제 공부"라는 초기 아이디어에서 출발했지만, 사용자가 왜 써야 하는지에 대한 답을 찾지 못해 방향을 다시 잡았습니다. 그리고 부모-자녀 페어링이라는 구조로 "함께 계획하고, 보상으로 동기를 만드는" 방식으로 문제를 다시 정의했습니다.
기술 선택도 같은 기준으로 판단했습니다.
"새로운 기술을 써보고 싶다"는 욕심보다, 우리가 가진 제약(짧은 기간, 제한된 비용, 단일 EC2 환경) 안에서 최소한의 인프라로 최대 효율을 내는 구조를 우선했습니다. 그래서 프로세스 컨테이너 단위로 분리해 Docker Compose로 재현 가능하게 만들고, 젒속 방식은 SSH 대신 SSM으로 전환해 인바운드 22포트 개방 없이 운영할 수 있는 형태로 정리했습니다.
제가 이번 글에서 강조하고 싶은 내용은 "기술을 멋있어 보이기 위해 쓰는 게 아니라, 문제를 해결하기 위해 선택하는 것"이라는 점입니다.
원코는 지금의 프로토타입 아키텍쳐를 기반으로, 점진적으로 확장 가능한 구조로 발전시켜 나갈 계획입니다.
다음 포스팅은 [ONECO] 개발 일기 2편 - DDD/헥사고날로 설계한 '부모-자녀 미션' 도메인] 으로 이어가겠습니다.
'Tech Note > Architecture' 카테고리의 다른 글
| [ONECO] 부모-자녀 페어링 기반 경제·금융 키워드 교육 서비스 개발 일기 1편 (0) | 2026.01.14 |
|---|