inflearn-tech

문제GB 단위 대용량 컨테이너 이미지를 사용하는 ML/데이터 파이프라인에서 노드가 새로 뜰 때마다 이미지 pull 과 압축 해제에 수 분이 걸려 Spot 인스턴스 비용이 낭비됐다.

접근Bottlerocket 의 OS 와 컨테이너 데이터 볼륨이 분리된 구조를 활용해 이미지가 미리 들어 있는 EBS 스냅샷을 만들고, Karpenter EC2NodeClass 로 새 노드 데이터 볼륨에 마운트했다. gp3 의 IOPS/Throughput 도 함께 상향했다.

결과이미지 pull 시간이 최대 15분에서 10초 이내로 줄었고, 컨테이너 준비 단계의 EC2 및 네트워크 비용이 70% 이상 절감됐다.

문제팀 규모가 커지면서 코드 리뷰가 꼼꼼하게 이뤄지지 못하고, 타이핑 오류나 컨벤션 위반이 프로덕션까지 새어 나가는 경우가 늘었다.

접근AI 기반 리뷰 도구 CodeRabbit 을 PR 파이프라인에 붙이고, `.coderabbit.yaml` 의 Review Instructions 로 DDL 규칙·성능 기준·라이브러리별 컨벤션을 학습시켜 맞춤형 피드백을 받게 했다.

결과약 7개월간 사용한 결과 팀 코드 리뷰 문화가 더 활성화됐다. 정적 분석 도구와 달리 맥락 기반 리뷰가 가능해 동료 리뷰를 보완하는 역할을 한다.

문제기존 한국어 서비스에 다국어 지원을 붙이려면 수천 개의 한글 문자열을 일일이 `t()` 함수로 감싸야 했고, 개발자 며칠치 반복 작업과 키 컨벤션 합의가 필요했다.

접근Babel parser·traverse·generator 로 AST 를 분석해 한글 문자열을 자동으로 `t()` 로 래핑하는 T Wrapper 와, 추출된 텍스트로 JSON 언어 자원 파일을 만드는 Extractor 두 스크립트를 구현했다.

결과스크립트 두 번 실행으로 i18n 작업이 끝났다. 한 동료는 도메인 전체 번역을 5시간 만에 마쳐, 수작업 대비 작업 시간을 획기적으로 줄였다.

문제플랫폼 성장으로 스팸 게시글이 늘면서 운영팀의 수작업 부담이 커졌고, GPT 단독 필터링은 새로운 패턴·다국어 대응이 느렸다.

접근TfidfVectorizer 와 SGDClassifier 로 학습한 머신러닝 모델을 AWS Lambda 에 배포하고, ChatGPT API 를 결합해 새 유형·다국어 스팸을 보조 탐지하게 했다. 특징 추출은 Zero Shot With Auto Generate Prompt 기법으로 자동화했다.

결과스팸 계정 생성 요청이 76% 감소했고, 게시글당 판정 비용은 0.05원, 모델 추론 시간은 0.2~0.6ms 수준으로 떨어졌다.

문제팀이 커지며 VPN 요구가 진화했지만 AWS Client VPN 은 모바일 SAML 미지원, Firezone 은 오픈소스 지원 중단과 세부 권한·Split Tunnel 한계로 운영이 어려워졌다.

접근AWS Client VPN(OpenVPN) → Firezone(WireGuard) → Tailscale 로 단계적으로 이전했다. Tailscale 의 도메인 기반 Split Tunnel, 태그 기반 권한, 세션 자동 갱신, 멀티 플랫폼 안정성을 활용한다.

결과Tailscale 의 SaaS 모델로 유지보수 공수가 크게 줄었다. VPN 선택 기준을 사용자 경험·운영 효율성·기술 요구사항 세 축으로 정리해 다른 팀의 의사결정에 참고가 된다.

문제AWS Advanced JDBC Wrapper를 쓰는 Spring Boot 환경에서 트랜잭션 종료 시점에 "Cannot change transaction read-only property in the middle of a transaction" 에러가 간헐적으로 났다.

접근래퍼의 Failover 플러그인이 토폴로지 캐시 만료 시 쿼리를 실행해 트랜잭션 상태가 OPEN으로 바뀌는 것을 디버깅으로 찾아냈다. Spring 6.1.2의 LazyConnectionDataSourceProxy.setReadOnlyDataSource로 읽기 전용 DataSource를 분리해 setReadOnly 호출 자체를 없앴다.

결과읽기 전용 트랜잭션에서 setReadOnly가 호출되지 않아 에러가 사라졌고, Failover 동작과 트랜잭션 경계의 충돌을 구조적으로 해결했다.

문제인프런 서비스에 3개 버전의 디자인 시스템이 혼재해 UI 일관성이 깨졌고, 컴포넌트 식별과 문서화 비용이 누적됐다. 플랫폼 팀 없는 소규모 조직(개발 10명·디자이너 5명)에서 0부터 만들 여력은 없었다.

접근Mantine 오픈소스를 베이스로 모노레포에서 컴포넌트를 패키징한다. Anima로 피그마 에셋 변환을 자동화하고, Turborepo·Changesets·Storybook으로 개발과 배포 파이프라인을 구축했다.

결과프로젝트 개발 속도와 QA 효율이 올라갔고 디자이너-개발자 협업 비용이 줄었다. Code Owner 기반 리뷰와 Jira·Confluence 히스토리로 안정적인 운영 체계를 갖췄다.

문제인프런 사용자 콘텐츠(수강평·Q&A)를 SNS에 공유하면 미리보기 이미지가 일반 슬로건만 보여 내용 파악이 어려웠다.

접근Vercel `@vercel/og`로 HTML/CSS를 SVG로 그린 뒤 satori와 sharp로 PNG로 변환한다. CloudFront로 캐싱해 동일 요청을 빠르게 응답하도록 한다.

결과캐시 미적중 1.27초에서 적중 0.1초로 약 13배 빨라졌고, 서버 처리량은 1 RPS에서 35 RPS까지 끌어올렸다.

문제스타트업 인프랩이 매달 수천 달러 규모의 AWS 청구서를 받으며 비용 압박을 겪었다.

접근팀 차원의 비용 모니터링 문화를 만들고 상위 10개 서비스부터 분석했다. 매니지드 서비스를 self-hosted로 전환하고, EC2 스팟 인스턴스와 MSP 할인 계약을 활용했다. CDN 동적 캐싱과 VPC Endpoint로 트래픽 비용도 줄였다.

결과월 약 25,000달러(연 300,000달러)를 절감했다. MediaConvert 대체로 15~20배, CircleCI 대체로 4.5배, Fargate에서 EC2 전환으로 월 1,500달러를 줄였다.

문제개발팀이 배포 빈도, 장애 복구 시간 같은 개발-운영 생산성을 측정할 도구가 필요했다. 상용 솔루션은 비용 부담이 크고 커스터마이징이 제한적이었다.

접근DORA 4 메트릭(배포 빈도, 리드 타임, 변경 실패율, MTTR)을 기준으로 Apache Devlake를 데이터 수집 엔진, Grafana를 시각화 도구로 사용한다. GitHub·Jira·Jenkins를 연동해 메트릭을 자동 계산했다.

결과PR 사이클, 배포 성공률, 개발자별 기여도까지 대시보드 한 곳에서 보는 환경을 만들었다. 정량 지표를 기반으로 개선 목표를 잡을 수 있게 됐다.

문제인프라 구성 업무가 늘면서 수동 작업의 부담이 커졌다. AWS CDK는 CloudFormation 계층의 Drift 탐지가 어려웠고, Terraform/Terragrunt는 HCL 문법과 테스트 자동화의 한계가 있었다.

접근AWS CDK → Terraform → Terragrunt를 거쳐 최종적으로 Pulumi를 택한다. TypeScript 기반이라 IDE 자동 완성과 타입 체크가 잘 동작하고, Jest로 단위·통합 테스트를 짠다. Pulumi Automation API와 Generic으로 타입 안정성을 확보했다.

결과IaC 코드 전 영역에서 자동완성과 타입 힌트가 동작하고, 테스트로 변경 안전성을 보장하는 구조를 갖췄다. 인프라 변경에 드는 리뷰·검증 비용이 줄었다.