수십 년 경력의 전문 소프트웨어 엔지니어가 전하는 조언 - 공식적인 소프트웨어 QA 수행 방법을 배우세요.

나 28년 차 소프트웨어 엔지니어인데, 나 같은 사람들은 '바이브 코더(vibe coders)'들 엄청 까거든. 자기가 뭘 하는지 정확히 아는 걸 대체할 수 있는 건 없고, 솔직히 말해서 바이브 코더들 대부분은 그걸 모르니까.

근데 솔직히 말하면, 중간 정도 복잡도 이상의 프로젝트를 혼자서 개발하는 거 자체가 경력을 떠나서 '잘못된 방식'이야. 전문 팀에서 코드 리뷰랑 QA를 개발자가 직접 안 하게 하는 데에는 다 그만한 이유가 있는 거거든. 결과물에 대한 책임은 본인한테 있는데, 개발이랑 코드 리뷰, QA를 서로 다른 사람이 안 하면 리스크가 엄청나게 커져.

미리 말해두는데, 내 가장 강력한 추천은 위에 말한 대로 팀을 꾸리는 거고, 그다음 추천은 코딩이랑 정식 QA를 둘 다 배워서 코드 리뷰랑 QA를 스스로 하는 거야. 지금 내가 "혼자 QA 하는 것만으로 충분하다"고 말하는 게 아니야. "정식 코드 리뷰랑 QA 프로세스를 죽어도 안 하겠다면, 최소한 QA라도 직접 해라"라는 뜻이지.

어쨌든 여긴 바이브 코딩 서브레딧이니까, 코드를 직접 파고드는 건 제쳐두고라도 내가 추천하는 차선책은 정식 소프트웨어 QA를 배워서 직접 해보라는 거야. 배경 설명부터 좀 하고 왜 이걸 추천하는지 알려줄게.

배경:

TLDR: 대부분의 사람들이 생각하는 테스트는 정식 QA의 아주 작은 일부분일 뿐임.

1. QA는 너랑 네 친구들이 앱 가지고 노는 게 아님.

전부는 아니지만, 시작하기 위한 가이드는 다음과 같음:

• 정식 QA에 대해 공부해. 코드에 유닛 테스트를 넣고 통과하는지 확인하고, 기능 테스트, 보안 테스트, 해피 패스 테스트, 네거티브 테스트, 부하 및 스트레스 테스트(이 둘은 다름), 회귀 테스트, 스모크 테스트(그 외 다수)를 포함한 테스트 계획을 세워.

• 버그 리포트 쓰는 법을 배워. 요약, 환경 정보, 재현 단계, 실제 결과와 기대 결과 등을 적고 스크린샷, 영상, 로그 스니펫도 첨부해.

• 제대로 된 이슈 트래킹 시스템을 써. 진행 상황을 추적하고, 수정 사항을 기록하고, 발견한 세부 정보를 추가해. 나중에 같은 문제가 또 터졌을 때 이게 진짜 보물 같은 자료가 됨.

• 계속 업데이트해. QA는 한 번 하고 끝나는 게 아님. 새로운 기능이 생기면 새 테스트가 필요하고, 버그나 취약점이 발견돼도 마찬가지임.

2. 네가 쓰는 최신 AI 모델한테만 QA를 맡기는 건 절대 충분하지 않음.

자동화는 내가 중세 시대에 일을 시작했을 때부터 QA 프로세스의 일부였어. 내가 일했던 모든 곳은 자동화된 테스트 스위트를 돌리면서 동시에 수동 QA도 병행했음. AI한테 테스트 돌리는 거 당연히 좋지. 근데 수동 QA도 무조건 같이 해.

내가 이걸 추천하는 이유(전부는 아님):

TLDR: 이걸 하면 너는 훨씬 더 나은 바이브 코더가 될 거고, 네 소프트웨어 퀄리티도 올라감. 한번 해봐!

1. 바이브 코딩이랑 비슷하게, 진입 장벽은 낮은데 제대로 파고들면 엄청난 결함들을 찾아낼 수 있음.

시작하는 데 기술적인 지식이 많이 필요하지 않아. 나를 포함해서 많은 사람들이 테크 업계에서 처음 시작한 일이 QA였던 이유가 이거지. 근데 프로세스를 배우고 정식 QA 관점에서 소프트웨어를 생각하기 시작하면 바로 큰 효과를 볼 수 있어. 물론 처음부터 완벽한 QA 프로세스를 갖추긴 힘들겠지. 다른 거랑 똑같이 하다 보면 느는 거고, 끝이 없는 분야야.

2. 버그 리포트는 끝내주는 프롬프트가 됨.

"그냥 믿어봐" 하지 말고, 버그 리포트 양식 검색해서 딱 한 번만 써봐. 직접 해보면 알 거야.

3. 다음에 바이브 코딩할 때 큰 도움이 됨.

소프트웨어를 만들 때 프롬프트부터가 QA 프로세스를 고려하게 될 거야. 훨씬 더 좋은 프롬프트를 쓰게 될 거고, 결과물에서 바로 티가 날 거다.