클라우드
성장해도 비용이 무너지지 않는 플랫폼
클라우드 아키텍처 설계, 마이그레이션, 플랫폼 엔지니어링. 저희가 중요하게 보는 것은 18개월 뒤에 드러나는 부분입니다. 청구액, 잘못된 배포의 영향 범위, 그리고 새 엔지니어가 첫 주에 시스템을 이해할 수 있는지입니다.
제공 내용
아키텍처와 마이그레이션
지금의 자리에서 설명할 수 있는 목표 구성으로. 각 단계가 그 자체로 성립하고, 각각에 되돌아갈 길이 있는 형태로 진행합니다.
- 의존 관계, 데이터 중력, 라이선스, 그리고 아무도 적어 두지 않은 사정까지 포함한 현황 진단
- 검토했다가 버린 선택지까지 포함해 판단 근거를 기록한 목표 아키텍처
- 단계마다 되돌릴 지점을 둔 점진적 전환. 특정 주말이 완벽하게 흘러가야 하는 계획은 세우지 않습니다
- 랜딩 존: 계정·구독 구조, 네트워크 구성, 인증 기준선, 가드레일 정책
플랫폼 엔지니어링
제품 팀이 그 위에 배포하는 “포장된 길”입니다. 저희에게 묻지 않고도 직접 바꿀 수 있다는 전제로 만듭니다.
- Infrastructure as Code. 변경은 다른 코드와 똑같이 계획되고, 리뷰되고, 되돌릴 수 있습니다
- 노트북에서 운영 환경까지 이어지는 환경 동일성. “스테이징에서는 됐다”가 의미를 갖게 합니다
- 점진적 배포, 헬스 게이트, 이상 신호 시 자동 롤백을 갖춘 CI/CD
- 골든 패스: 복사가 아니라 출발점으로 쓰는 서비스 템플릿, 베이스 이미지, 공용 라이브러리
신뢰성·비용·운영
18개월 뒤 그 플랫폼이 괜찮았는지를 가르는 질문은 둘입니다. 얼마가 드는가, 그리고 망가지면 무슨 일이 벌어지는가.
- CPU 그래프가 아니라 실제로 중요한 사용자 여정에 묶인 SLO와 에러 버짓
- 환경별·서비스별 비용 모델. 설계를 확정하기 전에 눈에 보이게 합니다
- 사이징, 오토스케일 정책, 약정 구매 계획을 사고 뒤가 아니라 정기적으로 재검토합니다
- 런북, 온콜 체계, 책임을 묻지 않는 장애 회고. 같은 장애가 두 번 나지 않게 하는 장치입니다
일하는 원칙
관리형이 먼저, 직접 구축은 마지막에
직접 운영하는 구성 요소는 그만큼 패치와 모니터링과 인력이 따라옵니다. 분명한 이유가 없으면 관리형 서비스를 택하고, 그 이유도 기록합니다.
값싸게 확보할 수 있는 만큼의 이식성
락인에 값하는 관리형 서비스는 씁니다. 다만 옮기는 비용이 큰 부분 ― 데이터, 인증, 빌드 파이프라인 ― 은 고객사가 통제하는 인터페이스 안쪽에 둡니다.
청구서는 설계의 산출물입니다
비용을 계산하지 않은 설계는 완성된 설계가 아닙니다. 예상 부하와 최악 부하 양쪽에서 비용을 산정한 뒤 설계를 승인받습니다. 첫 청구서를 보고 나서는 늦습니다.
중요한 곳일수록 지루하게
장애는 네트워크와 인증과 상태 관리에서 나옵니다. 이 셋은 정석대로 두고, 새로움은 잃어도 기능 하나로 끝나는 곳에 씁니다.
함께하는 방식
2 – 4주
아키텍처·비용 검토
현재 플랫폼을 신뢰성·보안·비용 관점에서 읽고, 공수 추정과 담당 제안을 붙인 우선순위 목록으로 제출합니다.
3 – 9개월
마이그레이션 또는 플랫폼 구축
이전을 설계하고 실행하거나, 각 팀이 배포할 플랫폼 계층을 만듭니다. 고객사 엔지니어와 나란히 일해 지식이 사내에 남게 합니다.
지속
플랫폼 운영
업그레이드, 비용 검토, 장애 대응, 그리고 다음에 무엇을 바꿔야 하는지에 대한 로드맵까지 함께 운영하고 키웁니다.
다루는 기술
프로젝트마다 선택합니다. 모든 과제에 밀어 넣는 자사 표준 스택은 두지 않으며, 고객사 팀이 이미 운영하고 있는 기술에 맞춥니다.
클라우드와 엣지
주요 클라우드를 두루 다룹니다. 무엇이 맞는지는 데이터와 팀과 기존 계약이 이미 어디에 있는지로 대체로 정해집니다.
- AWS
- Azure
- Google Cloud
- Cloudflare
- NGINX
프로비저닝과 배포
모든 것을 코드로, 검토 가능하고 되돌릴 수 있게. 아무도 재현할 수 없고 감사에서 설명도 못 하는 콘솔 조작은 남기지 않습니다.
- Terraform
- Ansible
- Docker
- Kubernetes
- Helm
- GitHub Actions
- Argo CD
상태와 신호
마이그레이션을 어렵게 만드는 것은 상태를 가진 부분이고, 장애를 짧게 만드는 것은 관측 가능성입니다. 둘 다 물려받지 않고 설계합니다.
- PostgreSQL
- Redis
- Kafka
- Elasticsearch
- OpenTelemetry
- Prometheus
- Grafana
프로젝트 진행 방식
1 – 3주 차
진단
자산 목록, 의존 관계 지도, 비용 기준선, 위험 목록. 어떠해야 하는지를 제안하기 전에 지금 무엇이 있는지를 측정합니다.
3 – 6주 차
설계
목표 아키텍처, 랜딩 존, 네트워크와 인증 모델, 그리고 각 웨이브 경계에 되돌릴 지점을 둔 이전 순서.
2 – 8개월 차
이전·구축
웨이브 단위로 진행합니다. 웨이브의 완료는 코드를 옮긴 시점이 아니라, 대상 워크로드가 새 환경에서 돌고 모니터링되고 비용까지 파악된 시점입니다.
지속
운영
SLO 보고, 비용 검토, 패치와 업그레이드 주기, 그리고 실제로 호출될 사람들과 함께하는 장애 훈련.
남게 되는 것
- 고객사 저장소에 놓인 Infrastructure as Code와 문서화된 plan / apply 운영 절차
- 환경별·서비스별 비용 모델. 전제 조건을 숫자 옆에 함께 적습니다
- 사람이 필요할 때만 사람을 호출하는 SLO와 대시보드와 알림
- 일반 템플릿이 아니라 설계 중에 발견된 장애 유형에 맞춘 런북
- 이전 기록. 무엇을 언제 옮겼고, 무엇이 문제였고, 그 결과 무엇을 바꿨는지
이 영역에서 상의할 일이 있으십니까
문제의 윤곽을 알려 주십시오. 저희가 적임인지 아닌지 솔직하게 말씀드리겠습니다.