| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
- 애자일기법
- Java
- database
- JPA
- 코딩테스트
- framework
- 애자일프로그래밍
- 백준
- 코딩
- 자바
- 프레임워크
- 코드
- 읽기쉬운코드
- 그리디
- Elasticsearch
- 스프링
- cleancode
- spring boot
- Baekjoon
- 개발자
- 클린코드
- API
- ES
- 알고리즘
- 개발
- kotlin
- 그리디알고리즘
- 데이터베이스
- 엘라스틱서치
- Spring
- Today
- Total
튼튼발자 개발 성장기🏋️
AI와 함께하는 테스트 자동화: 플러그인 개발기를 읽고 나서 본문
우아한형제들 기술블로그에서 "AI와 함께하는 테스트 자동화: 플러그인 개발기"를 보았다. 평소에 테스트 코드 자동화, 그리고 AI가 개발 실무에서 어떤 역할을 할 수 있을지에 대해서 많이 궁금했던 탓인지 재밌게 보았다.
AI 자동화의 장점과 마주친 한계
AI, 특히 Amazon Q, Copilot 같은 도구들을 이용해 테스트 코드를 자동 생성하는 건 업무 효율 측면에서 정말 매력적으로 보인다. 단순히 코드 몇 줄을 대신 써주는 게 아니라, 팀 컨벤션까지 반영해서 실제로 돌아가는 테스트 코드를 빠르게 만들어준다는 점이 참 고무적이다.
하지만 역시 현실은 만만치 않다는 게 느껴졌다. 100% 자동화의 환상은 생각보다 쉽게 깨진다고 느꼈다. 클래스 의존성, 멀티모듈 구조, 비슷한 클래스명, 누락되는 엣지케이스 등 AI가 잘 실수하는 부분에서 충분히 공감이 갔다. 약 2년 전, 전직장에서 나도 Copilot이 코드 자동완성은 잘해줘도, 실제 우리 프로젝트 복잡한 상황에서 정확히 동작하게 하려면 꼭 직접 손봐야 했던 경험이 있어서 더 와닿았다.
플러그인 + AI 콤비 전략이 인상적
템플릿을 미리 만들어주는 자체 플러그인과 Amazon Q의 조합 전략이 꽤 영리해보인다. AI가 놓치는 일관성과 커버리지는 플러그인이 보장해주고, 구체 구현은 AI가 맡는 식으로 역할을 분리한 게 실용적인 접근이라고 생각한다. 실사용 결과 데이터(클래스당 70% 시간 단축, 빌드 오류 감소)를 구체적으로 제시한 것도 신뢰감을 준다.
사실 단순히 플랫폼이나 프롬프트만 신경 쓰다가 "자동화 툴을 직접 만드는 쪽"으로 진입하는 건 쉽지 않은데, 실제 팀 문제에서 출발해 반복작업 자동화를 위해 IDE 플러그인을 개발했다는 점이 개발 문화적으로도 인상적이다.
그래도 남는 궁금증
읽다보니 궁금한 점도 많았다.
우선, 플러그인에서 커버리지를 높이기 위해 분기 로직을 다 추출한다고 했는데, 보통 if-else나 복잡한 비즈니스 로직이 도메인 객체나 외부 서비스 호출로 분리돼있으면 어떤 식으로 TC를 산출하는지가 궁금하다. 실제로 "정책이 복잡한 곳"은 테스트 케이스 만들기도 쉽지 않은데, 이걸 플러그인이 어디까지 자동화할 수 있을지, 혹시 오케스트레이션 이상의 테스트 설계(예: API 레벨, 통합 테스트 케이스 분리)까지도 커버하는지 알고 싶다.
또 하나는 팀 전체에서 새 플러그인 도입 시 개발 문화 충돌은 없었는지도 궁금하다. 나도 예전에 사내 툴을 도입하려고 했을 때 "왜 또 새로운 도구야?", "기존 코드 깨질까봐 불안하다" 이런 피드백이 있었어서, 실제 전파가 어떻게 이뤄졌는지도 더 듣고 싶다.
적용 아이디어와 현 시점에서의 업계 트렌드
이런 플러그인+AI 조합은 앞으로 점점 더 확장될 거라고 생각한다. 특히 반복성이 많지만 컨벤션, 팀 문화, 도메인 지식이 강하게 필요한 영역(테스트 자동화, 코드 리뷰 보조 등)은 '완전한 AI의 자율성'보다 'AI와 사람이 역할을 분담하는 하이브리드 구조'가 더 현실적으로 보인다.
최근 내 주변에도 ChatGPT 기반의 코드 생성 보조툴을 팀 환경에 통합하려는 시도가 종종 보이는데, 아직은 항상 '인간의 검증'이 필수라고 생각한다. 하지만 지금 같은 플러그인-자동 템플릿 방식이 충분히 다듬어지면, 진짜로 시니어 개발자 한 사람이 수많은 반복 작업에서 해방될 수 있을 것 같다.
더 나아가 이 방식이 문서 작성, 린트/포맷팅, 코드베이스 분석 등의 '지루한 반복작업' 전반에 적용될 수 있지 않을까 생각도 해봤다.
그래서 뭘 얻었지?
- AI로 테스트 자동화는 "기대한 만큼 쉬운 일은 아니다"라는 점. 복잡한 현실에서 동작하는 건 항상 사람의 보완이 필요함.
- 플러그인/자동화 도구는 한 번에 완전 자동화보다는, 반복 작업을 줄이고 팀 컨벤션을 맞추는데 초점을 맞춰야 오래 살아남는다는 점.
- 문제의 본질이 'AI의 한계'에 있다는 걸 빨리 인정하고, 역할을 잘 분배해 사람-도구-플랫폼이 각자 잘하는 걸 하게 만들어야 효과가 난다는 것.
다음번에는 우리 팀에도 이런 플러그인 식 접근을 제안해보고 싶다. 머릿속으로만 생각하던 "반복작업 자동화"를 실제로 실현한 사례여서 꽤 동기부여가 됐다.
참고 문헌: AI와 함께하는 테스트 자동화: 플러그인 개발기
