배포가 느려진 진짜 이유는, 코드 때문이 아니었다
요즘 들어 가장 많이 드는 고민은 이것이었다.
“왜 이렇게 배포가 오래 걸릴까?”
매일같이 기능은 쌓여가고, 팀원들도 쉼 없이 개발하고 있는데
막상 실제 서비스에 반영되는 속도는 점점 느려지고 있었다.
순수 개발보다 더 오래 걸리는 건 QA였다
우리가 이 문제를 뜯어보며 놀란 건,
실제로 순수하게 ‘코드 짜는 시간’은 그렇게 오래 걸리지 않는다는 사실이었다.
정말 시간을 잡아먹는 건, 그 이후의 과정이었다.
- 개발 완료 → develop 배포
- 기본 QA → 디자인 QA
- 디자인 QA 반영 후 다시 QA
- 버그 수정 후 QA
- 마지막으로 프로덕션 배포
이 과정 속에서 “지금 어떤 QA가 어디까지 되었는지” 파악도 어렵고,
한 단계를 넘기면 꼭 예기치 못한 에러가 다시 터지기 마련이었다.
결국 일정을 예측할 수 없고, 예상보다 리소스가 훨씬 많이 들어가기 시작했다.
해결의 실마리는 QA 시간을 줄이는 것
그래서 우리는 “어떻게 하면 QA 시간을 줄이고, 더 빠르게 배포할 수 있을까?”를 본격적으로 고민하기 시작했습니다.
단순히 QA를 ‘빨리’ 한다는 의미가 아니라,
QA가 필요한 상황 자체를 줄일 수 있는 구조를 만들자는 방향이었습니다.
결국 우리가 발견한 가장 큰 병목은,
개발자가 실수하고, 그걸 나중에 발견해 수정하는 반복적인 사이클이었습니다.
시간도 많이 들고, 컨텍스트도 자주 끊기고, 그만큼 리소스 낭비도 컸습니다.
기존 코드 리뷰 봇은 잘 안 썼다
사실 예전부터 GitHub Actions 기반의 Code Review Bot을 이용하고 있었습니다.
하지만 기대만큼 실용적이진 않았습니다
- 예외 처리를 제대로 못 잡고,
- 컨벤션도 정확히 지적하지 못했고,
- 가장 중요한 건 리뷰가 ‘도움이 안 된다’는 느낌이었다.
그래서 결국 사람만 리뷰하고, 봇은 참고용에 그치는 경우가 대부분이었다.
CodeRabbit 도입
그러던 중 어떤 개발자의 블로그에서
CodeRabbit이라는 AI 리뷰 봇이 진짜 잘 잡아준다는 글을 보게 됐다.
- 단순히 코드 포맷이 아니라
- 비효율적인 로직이나 API 설계 방식,
- 변수명 통일, 반복되는 실수까지 지적해준다는 리뷰 예시를 보고
도입 검토를 하게 되었다.
작은 팀일수록
사람이 리뷰를 하지 않아도 되는 영역은 최대한 줄여야 하고,
그 에너지를 정말 중요한 리뷰와 논의에 써야 하니까.
AI Code Reviews | CodeRabbit | Try for Free
Most advanced AI code reviews that catches 95%+ bugs. Free your devs to ship code faster.
www.coderabbit.ai
장점 1 : 빠르고 단순한 연동
연동 과정은 놀랄 만큼 간단했습니다.
CodeRabbit 웹사이트에 접속해 로그인하고, 안내에 따라 GitHub에 앱을 설치하면 끝.
추가 설정이나 복잡한 권한 조정 없이, 몇 번의 클릭만으로 모든 리포지토리에 연결할 수 있었습니다.
장점 2: 꼼꼼한 리뷰
무엇보다 인상 깊었던 건 리뷰의 깊이와 구조였습니다.
기존 리뷰 챗봇이 주던 단순한 피드백이 아니라 코드 베이스를 기준으로 리뷰해주니까
정말 디테일하면서도 전체 흐름에 대한 피드백까지 받을 수 있었습니다.
1. 변경된 기능에 대한 설명 / 요약
PR 전체를 훑고 어떤 기능이 어떻게 변경되었는지 요약해주기 때문에,
코드를 하나하나 따라가지 않아도 변경 목적과 흐름을 먼저 이해할 수 있었습니다.
2. 각 파일별 디테일한 변경 사항
단순히 코드 몇 줄이 바뀌었다는 게 아니라,
“이 변경이 왜 필요한지”, “이렇게 바꾸는 게 더 나은 이유는 뭔지”까지 디테일하게 리뷰합니다.
3. Sequence Diagram
특정 상황에 따라 API 호출 흐름이나 내부 로직이 복잡할 때,
직접 시퀀스 다이어그램을 그려주기도 합니다.
이건 단순 리뷰를 넘어선 수준이었고, 협업자 간의 맥락 공유에도 큰 도움이 됐습니다.
4. 코드 에러 처리, 로직 등 부족한 부분 검토
예외 처리가 빠진 부분, 더 깔끔하게 쓸 수 있는 조건문,
중복된 코드 구조 등 우리가 놓치기 쉬운 지점들을 정확히 짚어줍니다.
도입 효과
이를 통해 PR 단계에서 에러나 부족한 부분을 미리 잡아낼 수 있었고,
변경사항의 맥락을 코드 중심으로 명확히 파악할 수 있어 소통도 훨씬 수월해졌습니다.
그 결과, 불필요한 QA 작업이 50% 이상 줄어들었습니다.
처음에는 테스트 코드, 개발 컨벤션, 꼼꼼한 코드 리뷰 등
개발자의 ‘역량’으로 해결하려 했지만,
곧 깨달았습니다.
개인의 역량에만 의존하는 건 한계가 있다는 것.
지속 가능하고 확장 가능한 구조를 만들기 위해선
회사가 시스템으로 뒷받침해야 한다는 것.
그래서 우리는 구조를 바꿨고, 도구를 도입했고,
QA가 필요한 상황을 줄이기 위해 개발 흐름 자체를 개선했습니다.
결국 우리가 하고 싶었던 건,
“QA를 줄이고 성공 확률을 높이는 것”이었습니다.
그리고 이 방식이 장기적으로는 더 빠르고, 더 단단한 팀으로 가는 길이라고 믿습니다.
'개발' 카테고리의 다른 글
| 온리유를 개발하며 ‘왜’를 남기고 싶어 시작한 블로그 :: 온리유 CTO, 개발자로서 의사결정의 맥락을 기록합니다 (0) | 2025.06.13 |
|---|