DevFest Incheon 2025 후기

안녕하세요! 이번에 인천 송도에서 열린 DevFest Incheon 2025 행사에 다녀왔습니다.

규모가 큰 행사인 만큼 기대가 있었는데요.

2년전 쯤에도 이 행사에 참가했던 경험이 있어서, 이번 행사는 또 어떻게 다를지 기대됐어요.

체크인하면서 GDG 인천 키링, 스텐머그, 마나부 포인트 쿠폰 등 간단한 굿즈를 수령했구요.

저는 시간 상 2개의 세션에 참가해 들어보았습니다.

안전하게 AI를 활용하는 개발 문화, CI/CD로 시작하기

제가 첫번째로 들은 세션은 임성호님의 '안전하게 AI를 활용하는 개발 문화, CI/CD로 시작하기' 라는 세션이었습니다.

성호님은 무신사에서 프론트엔드 엔지니어로 근무하시는 분으로, 실제 프로덕션 환경에서의 경험을 바탕으로 CI/CD 파이프라인 구성에 대한 이야기를 들려주셨어요.

 

• 버전 관리의 중요성
  • 버전 관리는 크게 소스 버전 관리(Git 등)과 실행 환경 버전 관리로 나뉩니다. Git은 협업의 기반이자 CI/CD의 시작점이라고 할 수 있습니다.
  • Git 브랜치 전략으로는 GitFlow, GitHub Flow, TBD(Trunk-Based Development) 등이 있는데, 발표자는 TBD를 강조했습니다. TBD는 main 브랜치에 바로 머지하는 방식으로, 머지 충돌을 최소화하고 빠른 통합이 가능합니다. Feature flag를 활용하면 안전한 배포도 가능합니다.
  • 실행 환경 버전 관리도 중요합니다. Node.js 버전을 관리하는 방법으로 .nvmrc 파일이나 package.json의 engines 필드를 사용할 수 있습니다. NVM, FNM, Volta 같은 도구들을 활용하고, Corepack으로 패키지 매니저 버전도 관리할 수 있습니다.
  • GitHub Workflow에서도 동일한 버전을 사용하는 것이 중요하며, Docker 이미지의 Node 버전도 CI 단계에서 확인하도록 해야 합니다. SSOT(Single Source of Truth) 원칙을 지키는 것이죠.
• CI/CD의 핵심
  • CI의 핵심 원칙은 단일 소스 저장소 유지, 하루에 여러 번 코드 통합, 그리고 빌드/테스트 피드백을 빠르게 받는 것입니다. 발표자 팀은 10분 안에 피드백을 받는 것을 목표로 하고 있다고 합니다. 7명이 하루에 20개의 PR을 올리는 환경이라니, 확실히 빠른 CI/CD 프로세스가 필요할 것 같았어요.
  • CI에서 해야 할 것들은 환경 일치 검증, 빌드 자동화, 테스트 자동화, 코드 품질 검사, 그리고 빠른 피드백입니다.
  • 회사에서는 App Layer, Feature Layer, API Layer로 나뉘는 레이어 아키텍처를 사용하고 있으며, Turborepo를 도입했다고 합니다. Turborepo의 두 가지 주요 특징은 Internal Package와 Remote Caching입니다.
    
  • 하루에 PR이 20개이고 매일 1개 이상의 앱이 배포될 수 있는 환경에서 CI/CD가 10분 이상 걸린다면 개발 흐름이 끊길 수밖에 없습니다. 그래서 Remote Cache를 사용하는데, 덕분에 원래 오래 걸렸을 작업이 3초 만에 완료된다고 합니다. --dry-run 옵션으로 Remote Cache 존재 여부를 확인해 빌드를 스킵할 수도 있습니다.
    
  • 테스트 자동화에는 Vitest와 Synthetic Monitoring을 사용합니다. 원래 Jest를 사용했지만, Vite 기반이고 더 빠르다는 이유로 Vitest로 전환했다고 합니다.
    
  • CD는 Continuous Delivery와 Continuous Deployment로 나뉩니다. 배포 전략으로는 Blue-Green, Canary, Rolling Update 등이 있는데, 무신사에서는 Kubernetes 상에서 Rolling Update(서버를 한 대씩 순차적으로 업데이트)를 사용하고 있습니다. 안전장치로는 Feature Flag, Datadog Monitor, Incident Manager를 활용합니다.
    
• 측정하고 개선하기
  • DORA Metrics로 배포 성숙도를 측정할 수 있습니다. 주요 지표는 다음과 같습니다.
    Deployment Frequency(배포 빈도): 긴 수명의 Feature Branch를 없애는 것이 핵심입니다.
    Lead Time for Changes(변경 리드 타임): 커밋부터 프로덕션 배포까지 걸리는 시간입니다. 배포가 잘못됐을 때 슬랙 알림으로 즉각 반응할 수 있게 해야 합니다.
    Change Failure Rate(변경 실패율): 배포 후 프로덕션에서 문제가 발생하여 핫픽스, 롤백, 패치가 필요한 비율입니다. E2E 테스트를 강화하는 것이 중요합니다.
    Time to Restore Service(서비스 복구 시간): 서비스 정상화까지 걸리는 시간입니다. 런치 리뷰 시 Rollback Plan을 미리 설정해두는 것이 좋습니다.
    
• AI 시대, 안전장치가 더욱 중요하다
  • 발표자님이 강조한 부분은 바로 이것이었습니다. AI가 코드를 빨리 만들어줄 수 있지만, 버그도 빠르게 만들 수 있습니다.
    
  • 발표자님이 "AI를 쓰는 것에는 자신이 없지만, 그런 코드들이 안정적으로 배포될 수 있는 환경을 만드는 데에는 자신이 있다"고 말씀하셨는데요. 정말 인상적인 말이었습니다. AI 시대에 우리한테 필요한 것은 단순히 코드를 빨리 만드는 능력이 뿐만 아니라, 그 코드가 안전하게 배포되고 운영될 수 있는 시스템을 만드는 능력이라는 생각이 들었습니다.
    

열심히 만들었는데, 왜 아무도 안 쓸까? - 기술의 시대, 우리가 놓치고 있던 '사람'에 대한 이야기

두번째로 들은 세션은 이재백님의 '열심히 만들었는데, 왜 아무도 안 쓸까?' 입니다.

서비스에 사람들이 모이지 않는 이유를 분석하고 개선하는 방법을 다룬, 서비스 성장 전략에 관한 내용이었습니다!

개인적으로 발표자님의 입담과 스피치실력이 좋으셔서, 무척 재미있고 몰입감있게 들었던 세션이었어요 😀

 

• 왜 사람들이 안 올까
  • 사람들이 서비스를 사용하지 않는 이유는 정말 다양하다고합니다. 기존에 쓰고 있던 서비스에서 전환되기 어려울 수도 있고, 그 외에도 안 쓸 이유는 무척 많습니다. 이런 원인 분석을 구조적으로 단순화하여 쉽게 만든 도구가 AARRR 퍼널이라고 합니다.
• AARRR 퍼널
  • AARRR은 Acquisition(획득), Activation(활성화), Retention(유지), Revenue(수익), Referral(추천)의 약자입니다. 각 단계를 순차적으로 개선해나가는 것이 중요하며, Referral 단계까지 가면 마케팅에 돈을 들이지 않아도 자연스럽게 유입이 된다는 점이 인상 깊었습니다.
  • 각 단계에서 발생하는 문제는 결국 사람에 대한 이해가 부족해서 생기는 것입니다.
• Acquisition 의 함정
  • 사람들은 일반적이고 추상적인 이야기보다 개인적이고 구체적인 이야기에 더 민감합니다. 구체적인 고통일수록 더 관심을 가지게 됩니다.
  • 그리고 급발진(?)하면 안 됩니다. 너무 긴 구글 신청 폼, 복잡한 랜딩 페이지 등 첫 진입점에서 사용자를 놓치는 경우가 많습니다. 사용자가 서비스에 처음 접근할 때의 경험을 최대한 간결하고 명확하게 만들어야 합니다.

• 데이터 모니터링의 중요성
  • 활성화와 재방문에 대한 통찰을 얻기 위해서는 직관적으로 이해 가능한 수준의 데이터 모니터링 환경이 구축되어 있어야 합니다. Amplitude 같은 서비스를 사용하거나, 직접 쿼리를 작성해서 스프레드시트에서 확인하는 방법도 있습니다.
  • 중요한 것은 데이터를 수집하는 것만이 아니라, 그 데이터를 통해 실제로 인사이트를 얻고 개선할 수 있어야 한다는 점입니다.

마치며

항상 기대감을 가지고 방문하는 DevFest 인데요. 

인천 뿐만 아니라 판교, 서울 등 다양한 챕터에서 열리니 관심있는 분들은 방문해보시면 좋을 것 같아요.

꼭 구글 관련 기술 내용이 아니더라도 서비스 기획, 웹 프론트엔드 등 다양한 분야와 관련된 세션들이 준비되어있어서 그런지 저와 지인 모두 만족할 수 있었어요.

굿즈로 받은 예쁜 스텐머그를 보여드리며, 포스팅 마칩니다.

감사합니다 ☕️