AI와의 성공적인 첫 Co Work — 바이브 코딩으로 탄생된 맞춤형 Testcase Management System (29TMS)

* 이 글은 2025년 11월에 Medium에 작성된 내용입니다.
제 블로그에도 기제하기 위해서 동일한 내용을 가져온것 입니다. 앞으로도 이런 글들은 계속됩니다.

안녕하세요 29CM QE팀 Lead 박현준입니다.

29CM QE팀은 상용화된 Testcase Management System(이하 TMS)을 사용하고 있습니다. 그러나 지불하는 비용 만큼의 만족도를 가지고 있는것은 아니었는데, 이를 해결하기 위해 AI와의 협업을 본격적으로 시작하였고

결과적으로 자체 TMS 개발을 완료하여 실무에서 사용하고 있습니다.

이번 글에서는 어떤 과정을 거쳐 자체 시스템을 구축하게 되었는지 공유해보고자 합니다.

상용화 TMS는 저도 거의 10년 동안 사용했었는데 몇 년 전부터 사용 중에 몇 가지 불만 사항이 생기게 되었습니다. 그중에 가장 큰 불만은 지원이 너무 느리다는 것이었습니다.

1년 동안 수정되지 않았던 버그와 Section 계층구조 기능의 버그 등으로 Testcase Import가 원활하게 되지 않는 문제는 계속 저희의 발목을 붙잡았습니다.

이에따라 신규 테스트케이스를 Import 하는 상황은 점점 감소하였고, 기존에 Import 되어 있던 테스트케이스를 수행하는 역할로만 주로 사용하게 되었습니다. 결과적으로 등록된 케이스만 사용하고 신규 테스트케이스는 구글 스프레드시트로 사용하는 반쪽짜리 사용을 하고 있었습니다.

비용 대비 충분한 사용성을 보장받지 못해 고민하던 차에 Cursor AI가 눈에 들어왔습니다. 바이브 코딩에 대한 다양한 실사례들이 나오고 있고 회사에서도 AI 관련 도구들을 적극적으로 권장하고 있었기 때문에 ‘이제는 내가 직접 만들어서 사용해 볼 수 있겠다.’ 라는 결심을 할 수 있었습니다.

그렇게 저는 Cursor와의 여정을 시작했습니다.

정한 것은 단 하나, React로 만들겠다는 점이었습니다. 하지만 저는 React 개발 경험이 없었습니다.

즉, 100% 바이브 코딩에 도전하는 프로젝트였으며, React 사용을 제외한 나머지 기술 스택은 전혀 정하지 않은 상태로 시작했습니다.

처음에는 그럴듯한 기능과 화면들이 척척 만들어지는 것을 보고 감탄을 금치 못했습니다. 왜 이렇게 사람들이 AI에 열광하는지 저도 체감할 수 있었죠.

하지만 기능이 많이 구현될수록 저 스스로 AI를 사용하는 것에 대한 한계를 느끼게 되었습니다.

AI는 모든 것을 기억하지 못합니다.
그렇기 때문에 방금 작업했던 내용을 이후에 작업할 때는 불필요하다고 판단하고 삭제하거나 수정하는 상황이 자주 있었습니다.
힘들게 구현한 기능이 갑자기 한순간 사용 불가가 될 때는 정말 집에 가고 싶었는데 (…) 많은 우여곡절 끝에 AI를 사용하는 보완점을 많이 알게 되면서 저만의 노하우도 어느 정도 쌓이게 된 것 같습니다.
AI는 개떡같이 말하면 찰떡같이 알아듣지 못합니다.
척척 만들어주니 문제가 없는 것 같지만, 나중에 다시 보면 매우 비효율적으로 코드를 작성해 준 것을 알게 됩니다. 사실 이런 문제 대부분은 제가 그렇게 프롬프트를 작성했기 때문입니다. 개떡으로 input 하면 개떡으로 output이 나올 수밖에 없습니다.

후반부에서는 초반보다 Cursor를 훨씬 수월하게 활용하게 되었는데, 이 내용은 길어질 것 같으니 다른 글에서 풀어 보도록 하겠습니다 :)

결과적으로 제작에 든 시간은 3개월 정도 걸린 것 같습니다. 아무래도 업무와 병행하면서 하다 보니 빠른 트러블 슈팅이 어려웠고 이에 따라 진행에 병목이 생기는 일이 자주 발생하게 되었습니다.
또한 내가 원하는 기능에 살짝 미치지 못하면 그 디테일을 잡기 위해서도 시간을 많이 사용하게 된 것 같습니다.

이때는 디테일한 프롬프트를 작성해서 해결하는 상황이 많았는데, 확실히 QA라는 직무가 많은 도움이 되었습니다. 현상이나 기능을 자세히 설명하는 것은 이미 QA 업무를 많이 하면서 숙달된 기능이기 때문에 프롬프트 작성에 그만큼 이점이 많았습니다.

개인적으로 경험한 개발 프롬프트 3 Level 단계가 있었는데,

1 Level: 요청한 사항이 프롬프트만으로 구현된다.

많은 코드 소스가 있어서 학습이 잘 되어있을 거 같은 기능 ( ex.로그인)은 프롬프트만으로 구현에 문제가 없었습니다.

2 Level: 추상적 단어 없이 상세한 Flow와 화면구성이 포함된 프롬프트로 구현한다.

이건 단순한 프롬프트만으로는 구현에 문제가 생겨서 그 다음 단계로 넘어간 상황입니다.
이 기능은 어떤 동작을 하고 어떤 화면으로 구성이 되어야 하는지 최대한 상세히 설명해야 구현이 원하는 방향으로 완료됩니다. 기능 간의 연관성을 작성해서 요청하는 방식이었습니다.

3 Level: 시스템 구조를 직접 설명하는 프롬프트로 구현한다.

DB Table 구조, API 응답 프로퍼티 등 필요한 기능들을 제가 미리 설계하고 그 데이터와 구조로 기능이 동작할 수 있도록 세부적인 프롬프트를 작성합니다.
이 경우 높은 확률로 원하는 기능이 구현될 가능성이 있으나 이것도 항상 100% 제가 원하는대로 기능이 구현되는 것은 아닙니다.

대부분 1~2 Level로 진행했고 정말 구현이 너무 안 되는 경우에만 3 Level로 진행했던 것 같습니다.

이 방식은 Debug에서도 동일합니다.

간단한 요청으로 수정 되는 것이 있는만, 아무리 수정해도 원인을 찾지 못하는 경우도 있었습니다. 이럴 때는 Log 추가를 요청해서 스스로 정확한 원인을 파악할 수 있도록 한 뒤 문제를 해결할 수 있도록 도와주는 경우도 있었습니다. 또한 논리적으로 문제가 될 만한 상황을 계속 질문하면서 Debug를 해야 하는 경우도 있습니다. 이 경우 의외의 위치에서 문제가 되는 부분을 찾기도 합니다.

Cursor가 계속 수정하지 않았던 코드 영역인데 개인적으로 의심되는 부분이라면 끝까지 추적해서 그 코드가 문제였던 것을 알아낸 경우도 있었습니다.

그리고 2025년 10월 21일.
29CM QE 팀은 이렇게 만들어진 TMS (가칭 29TMS) 를 본격적으로 실무에 사용하기 시작하였습니다.

8월 초기 기획 당시 정말 조직 내에서 필요로 하는 MVP 위주로 사용하기 위한 구현 목록을 정했는데 하나씩 구현을 완료하고 버전을 올리면서 꾸준히 계속하다 보니 어느덧 1.6.1 버전까지 릴리즈 되었고, 해당 버전 기준으로 모든 초기 구현이 완료되었습니다.

정렬이나 필터 등의 세부 기능 설명은 제외하고 중요 기능 위주로만 설명해 보겠습니다.

회원가입 후 관리자의 승인이 있을때만 로그인이 가능하며,
관리자의 경우 별도 관리자 메뉴가 존재합니다. 해당 메뉴에서 회원가입 승인, 비밀번호 초기화의 기능을 사용할 수 있습니다.
로그인시 Access Token을 발급 받으며, 모든 기능 사용 시 Token 인증이 필수입니다.