에필로그
더 나은 QA 엔지니어가 되는 길
2개월 동안 제임스컴퍼니를 혼자서 개발하면서, QA 엔지니어에서 풀스택 개발자 따라하기로, 그리고 다시 더 나은 QA 엔지니어로 성장했습니다. 이 여정에서 얻은 가장 큰 깨달음은 "개발자 입장에서 이슈를 만들고, QA 관점에서 분석하는" 능력이었습니다.
이슈 분석 능력의 질적 향상
이전의 나: 표면적 관찰자
개발을 시작하기 전, 저는 이런 식으로 버그를 리포트했습니다.
제목: 로그인 버튼 클릭 시 500 에러 발생
내용:
- 재현 경로: 로그인 페이지 > 이메일/패스워드 입력 > 로그인 버튼 클릭
- 예상 결과: 로그인 성공
- 실제 결과: 500 Internal Server Error
- 환경: Chrome 120, Production
나름 체계적이라고 생각했지만, 이제 보니 개발자에게는 별로 도움이 안 되는 리포트였다고 생각합니다.
지금의 나: 근본 원인 추적자
이제는 같은 이슈를 이렇게 분석합니다.
제목: [Auth] JWT 토큰 생성 시 환경 변수 참조 실패로 인한 500 에러
문제 상황
- Production 환경에서만 로그인 시 500 에러 발생
- Development 환경에서는 정상 동작
근본 원인 분석
1. 에러 로그 확인
KeyError: 'JWT_SECRET_KEY' at auth/utils.py:45
2. 환경별 차이점
- Local/Dev: .env 파일에서 JWT_SECRET_KEY 로드 성공
- Production: Vercel 환경 변수에 JWT_SECRET_KEY 미등록
3. 코드 분석
해결 방안
즉시 조치: Vercel Dashboard에서 JWT_SECRET_KEY 환경 변수 추가
장기 개선: 환경 변수 검증 로직 추가
# config.py
class Settings:
def __init__(self):
self.jwt_secret_key = os.getenv("JWT_SECRET_KEY")
if not self.jwt_secret_key:
raise ValueError("JWT_SECRET_KEY must be set")
영향 범위
영향 받는 기능: 로그인, 회원가입, 토큰 갱신
영향 받는 사용자: Production 환경의 모든 사용자
데이터 손실: 없음 (인증 실패만 발생)
테스트 계획
환경 변수 설정 검증 자동화 스크립트 추가
CI/CD 파이프라인에 환경 변수 체크 단계 추가
환경별 smoke test 강화
이런 변화가 가능했던 건, 직접 환경 변수 설정의 복잡성을 경험하고, 환경별 차이로 인한 고통을 겪어봤기 때문입니다.
개발팀과의 진정한 협업
이전의 협업: 일방적 전달
예전에는 개발팀과의 소통이 단방향이었습니다.
QA 엔지니어: "여기 버그 있어요. 고쳐주세요."
개발자: "재현이 안 되는데요?"
QA 엔지니어: "제 환경에서는 되는데... 다시 해보세요."
개발자: (한숨)
앞으로의 협업: 문제 해결 파트너
이제는 이런 대화가 가능해질 것 같습니다.
QA 엔지니어: "Production에서 결제 실패하는 이슈 발견했습니다. 네트워크 탭 확인해보니 Toss API 호출 시 401 에러가 발생하네요. 혹시 TOSS_SECRET_KEY가 test_sk_로 시작하는 테스트 키로 설정되어 있는 건 아닐까요?"
개발자: "어? 정말이네요. 환경 변수 확인해볼게요."
QA 엔지니어: "제가 로컬에서 테스트해본 결과, live_sk_로 시작하는 라이브 키로 변경하면 정상 동작합니다. 그런데 웹훅 URL도 함께 변경해야 할 것 같아요."
개발자: "맞아요. 덕분에 빨리 찾았네요. 혹시 웹훅 검증 로직도 테스트해주실 수 있나요?"
QA 엔지니어: "네, 이미 Postman으로 웹훅 시뮬레이션 준비해뒀습니다. TOSS_WEBHOOK_SECRET 검증 로직도 함께 테스트하겠습니다."
이런 대화가 가능한 이유는, 이제 저도 토스페이먼츠 연동의 복잡성, 환경별 키 관리의 어려움, 웹훅 검증의 중요성을 직접 경험했기 때문입니다.
코드 리뷰 참여
앞으로는 PR 리뷰에도 더 적극적으로 참여할 수 있을 것 같습니다.
# PR Comment by QA Engineer
백엔드 PR #234 리뷰
1. 보안 관련 제안.
- Line 45: JWT 토큰 만료 시간이 하드코딩되어 있는데, 환경별로 다르게 설정할 수 있도록 환경 변수로 빼는 게 어떨까요? (Dev: 1h, Prod: 30m)
2. 에러 처리 개선
- Line 78: 여기서 Exception을 그대로 raise하면 프론트엔드에서 사용자 친화적인 메시지를 보여주기 어려울 것 같아요. HTTPException으로 감싸서 적절한 status_code와 detail을 제공하면 어떨까요?
3. 테스트 관련
- 이 API는 외부 의존성(Toss API)이 있는데, mock 처리가 필요할 것 같습니다. 제가 Postman으로 만든 목 서버를 활용하실 수 있어요.
아키텍처 논의 참여
이제는 기술적 의사결정에도 QA 관점을 제시할 수 있습니다.
팀 미팅: "Monorepo vs Multi-repo 결정"
QA 엔지니어: "제 경험상 Monorepo는 초기엔 편하지만, CI/CD 파이프라인이 복잡해집니다.
특히 프론트엔드만 수정했는데 백엔드 테스트까지 돌아가면서 배포 시간이 길어지더라고요.
테스트 전략 관점에서는 Multi-repo가 유리할 것 같아요.
1. 각 레포별 독립적인 테스트 스위트 관리
2. 병렬 배포로 빠른 피드백 사이클
3. 환경별 배포 전략 세분화 가능"
개발자: "오, 실제로 겪어본 경험이 있으시군요. 그럼 레포 간 의존성은 어떻게 관리하셨어요?"
QA 엔지니어: "Git Submodule로 공통 타입 정의를 관리했고, API 스펙은 OpenAPI로 자동 생성했습니다.
이렇게 하니 API 계약 테스트도 자동화할 수 있었어요."
환경을 고려한 체계적 테스트 설계
환경별 테스트 전략 수립
이제는 각 환경의 특성을 이해하고 맞춤형 테스트를 설계할 수 있습니다.
환경 전환 테스트
환경 간 전환 시 발생할 수 있는 이슈들을 미리 파악하고 테스트합니다.
"개발자 입장에서 이슈를 만들고, QA 관점에서 분석하는" 능력
이슈 생성의 진화
이제는 버그를 발견했을 때, 즉시 가능한 원인들을 떠올릴 수 있습니다.
문제 해결 능력의 향상
개발 경험을 통해, 이제는 단순히 문제를 찾는 것을 넘어 해결책까지 제시할 수 있습니다.
앞으로의 다짐
1. 지속적인 학습
개발을 경험하니, QA로서 더 배워야 할 것들이 명확해졌습니다.
성능 테스팅: 이제 데이터베이스 쿼리 최적화의 중요성을 알았으니, 성능 테스트도 더 깊이 있게 접근하고 싶습니다.
보안 테스팅: JWT, OAuth를 직접 구현해보니, 보안 취약점이 얼마나 쉽게 발생할 수 있는지 깨달았습니다.
자동화 전략: CI/CD 파이프라인을 구축하면서, 테스트 자동화의 새로운 가능성을 보았습니다.
2. 개발팀과의 시너지
앞으로는 이런 협업을 만들어가고 싶습니다.
개발팀: "새로운 기능 스펙이 나왔는데, 같이 리뷰해주실래요?"
QA 엔지니어: "네, 제가 개발하면서 겪었던 엣지 케이스들을 공유드릴게요."
개발팀: "이 아키텍처로 가면 어떤 테스트 전략이 좋을까요?"
QA 엔지니어: "제가 비슷한 구조로 개발해본 경험상..."
개발팀: "배포 자동화를 개선하고 싶은데요."
QA 엔지니어: "제가 Vercel로 환경별 배포 구성해본 노하우가 있어요."
3. QA 커뮤니티에 기여
제가 겪은 이 여정을 다른 QA 엔지니어들과 나누고 싶습니다. 제임스컴퍼니 플랫폼을 통해,
QA Code Challenge: 실제 개발 상황을 시뮬레이션한 QA 챌린지
Coffee Chat: 개발 경험이 있는 QA와 없는 QA의 만남
Insights: "QA가 알아야 할 개발 지식" 시리즈
2개월 전, "개발자 입장이 되어 이슈를 만들어보고, QA 관점에서 분석하는 힘을 기르자"는 목표로 시작한 이 여정이 이제 하나의 전환점에 도달했습니다.
예전에는 "이거 버그예요"라고 말하는 QA였다면, 이제는 "이 버그의 근본 원인은 이것이고, 이렇게 해결하면 좋을 것 같아요"라고 제안하는 QA가 되었습니다.
무엇보다 개발팀을 "버그를 만드는 사람들"이 아닌 "함께 더 나은 제품을 만드는 동료"로 바라보게 되었습니다. 환경 변수 하나 빼먹는 것이 얼마나 쉬운 일인지, CORS 설정이 얼마나 복잡한지, 마이그레이션이 얼마나 조심스러운 작업인지 이제는 압니다.
"더 나은 QA 엔지니어가 되는 길"은 결국 개발자의 고충을 이해하고, 함께 문제를 해결하는 파트너가 되는 것이었습니다.
이 시리즈를 읽는 QA 엔지니어분들께 전하고 싶은 메시지는 하나입니다.
"개발을 완벽하게 할 필요는 없습니다. 하지만 한 번쯤은 직접 만들어보세요. 그 경험이 여러분을 더 나은 QA로 만들어줄 것입니다."
긴 여정을 함께해주셔서 감사합니다.
ps. 제임스컴퍼니는 계속 발전하고 있습니다. 이제는 제가 만든 플랫폼을 제가 QA하면서, 기획자이자, 개발자이자, QA 엔지니어로서의 독특한 관점을 계속 키워가고 있습니다. 여러분도 각자의 방식으로 성장하시길 응원합니다!
