- 05 Jan, 2026
엑셀은 내 친구 - QA와 스프레드시트의 떨어질 수 없는 관계
아침부터 엑셀 출근하면 가장 먼저 여는 건 엑셀이다. Jira보다 먼저다. 어제 테스트하다 말았던 시트를 연다. 초록색 셀은 Pass, 빨간색 셀은 Fail, 노란색은 Pending. 한눈에 들어온다. 리드가 물어본다. "어제까지 진행률이요?" 엑셀 하단에 자동 계산해둔 셀을 본다. "78.3%요." 3초 만에 답한다. Jira에서는 이 답을 3분 안에 못 구한다.TestRail은 좋은데 우리 회사도 TestRail 쓴다. 연간 라이선스 수백만 원짜리다. 근데 실제로는. TestRail에는 정식 테스트 케이스만 올린다. 문서화된 것. 검증된 것. 배포 전 최종 확인용. 진짜 테스트는 엑셀에서 한다. 탐색적 테스트하면서 발견한 것들. "이거 확인해봐야겠다" 싶은 것들. 임시로 추가한 체크리스트. 빌드별로 달라지는 테스트 범위. 이런 건 TestRail에 올리기 애매하다. 정식 케이스도 아니고. 매번 바뀌는데 거기 다 넣으면 관리가 안 된다. 결국 엑셀이다. 팀장님도 알고 계신다. "TestRail은 형식이고, 엑셀이 실전이지." 그렇게 말씀하신다.내가 엑셀로 관리하는 것들 1. 일일 테스트 체크리스트 매일 아침 만든다. 오늘 테스트할 기능 리스트. 우선순위 표시. 예상 소요시간. 실제 소요시간. 차이 기록. 이거 쌓이면 나중에 일정 산정할 때 근거가 된다. "로그인 기능 테스트는 보통 2시간 걸립니다." 데이터로 말한다. 2. 버그 트래킹 보조 시트 Jira에 버그는 다 올린다. 당연히. 근데 내 시트에는 더 많은 정보가 있다. 재현율. 특정 디바이스에서만 나오는지. 개발자 반응. 픽스 예상일. 내 체감 심각도. Jira는 공식 기록. 엑셀은 내 전투 일지다. 3. 디바이스별 테스트 현황 iPhone 12, 13, 14. Galaxy S21, S22, S23. 각 OS 버전별. 어떤 디바이스로 어떤 기능을 언제 테스트했는지. 이번 빌드에서 어떤 디바이스가 아직 안 됐는지. 시각적으로 표시한다. 색깔로. 조건부 서식으로. 개발자가 "그거 테스트했어요?" 물으면 바로 확인 가능하다. "iPhone 13에서 어제 했고, Galaxy는 오늘 오후 예정입니다." 4. 빌드 히스토리 빌드 번호. 날짜. 주요 변경사항. 발견한 버그 개수. 심각한 버그 여부. 배포 여부. 나중에 "이 버그 언제부터 있었죠?" 물으면 이거 보고 답한다. "빌드 234부터요. 9월 15일자." 5. 배포 체크리스트 배포 전날 밤. 이걸 보면서 최종 확인한다. 필수 시나리오 50개. 하나씩 체크. Pass 확인. 스크린샷 첨부 경로 기록. 이거 없으면 불안해서 못 잔다.왜 자동화 못 하냐고요 이번 주 회의에서 나왔다. "QA도 자동화 전환해야죠. 엑셀로 언제까지 하시게요?" 말은 맞다. 나도 안다. 근데 현실은. 시간이 없다. 당장 다음 주 배포인데 자동화 스크립트 짤 시간이 어딨나. 매뉴얼 테스트도 빠듯하다. "자동화 공부할 시간 드릴게요." 일주일에 2시간 준다. 2시간으로 뭘 하나. 변경이 너무 잦다. 이번 주 스펙 바뀐 게 세 번이다. UI도 계속 바뀐다. 자동화 스크립트 짜놓으면 다음 주에 못 쓴다. Selector가 바뀌어서. 플로우가 바뀌어서. 유지보수하는 시간이 처음 짜는 시간보다 더 든다. 모든 걸 자동화할 순 없다. UI 깨짐. 미묘한 애니메이션 버그. 특정 상황에서만 나오는 크래시. 이런 건 사람 눈으로 봐야 한다. 탐색적 테스트가 필요하다. 자동화는 정형화된 시나리오만 된다. 우리 앱에서 그런 게 30%밖에 안 된다. 인프라가 없다. 자동화 서버. CI/CD 파이프라인. 디바이스 팜. 이런 거 구축하려면 돈이 든다. 시간도 든다. 팀장님이 위에 보고하셨다. 거절당했다. "매출 늘어나면 검토하죠." 결국 엑셀로 돌아온다. 엑셀이 나쁜 건 아니다 개발자들은 엑셀 쓰는 걸 구식이라고 한다. "요즘 누가 엑셀로 테스트 관리해요?" 근데 나는 생각한다. 엑셀이 나쁜 게 아니라 상황이 그런 거다. 엑셀의 장점이 있다. 빠르다. 새 시트 만드는 데 10초. 템플릿 복사해서 쓰면 5초. Jira에서 새 대시보드 만들려면 설정에서 필드 추가하고 필터 설정하고 권한 확인하고. 20분 걸린다. 유연하다. 필요한 컬럼 바로 추가한다. 수식 넣는다. 차트 만든다. 내 맘대로. 전문 툴은 정해진 틀이 있다. 커스터마이징에 한계가 있다. 오프라인에서도 된다. 지하철에서도 본다. 회의실에서 인터넷 안 될 때도 쓴다. 클라우드 툴은 인터넷 끊기면 끝이다. 엑셀 다루는 건 모두가 안다. 신입이 와도 설명 안 해도 된다. 컬러 코딩 보여주면 바로 안다. 전문 툴은 온보딩에 일주일 걸린다. 물론 한계는 있다. 협업에 약하다. 버전 관리가 애매하다. 실시간 동기화 안 된다. 그래도 지금 우리 환경에서는 엑셀이 최선이다. 엑셀 장인의 길 4년 하다 보니 나만의 템플릿이 생겼다. 조건부 서식 활용 Pass는 초록, Fail은 빨강, Pending은 노랑. 자동으로 색 바뀌게. 마감일 지난 건 진한 빨강. 오늘이 마감인 건 주황. 숫자만 봐도 상황 파악된다. 피벗 테이블 디바이스별 버그 개수. 기능별 테스트 진행률. 주차별 테스트 커버리지. 데이터 쌓아놓고 피벗 테이블 돌리면 리포트 끝이다. 주간 회의 자료 만드는 데 10분이면 된다. 수식 자동화 VLOOKUP으로 버그 ID 넣으면 상태 자동으로 가져온다. COUNTIF로 Pass/Fail 개수 자동 집계. TODAY()로 오늘 날짜 기준 남은 날 자동 계산. 수동으로 하던 걸 수식으로 바꿨다. 실수도 줄고 시간도 줄었다. 매크로 반복 작업은 매크로로 만들었다. "새 테스트 시트 만들기" 버튼 하나로 템플릿 복사, 날짜 입력, 시트 이름 변경까지 자동. 3분 걸리던 게 3초 된다. VBA 공부한 건 아니다. 인터넷에서 찾아서 조금 수정했다. 그 정도면 충분하다. 엑셀과 툴의 공존 요즘 내 업무 플로우는 이렇다. 1단계: 엑셀로 계획 이번 주 테스트 범위. 우선순위. 일정. 다 엑셀에 정리. 빠르게 초안 만든다. 수정도 빠르다. 2단계: 툴로 공식화 정해진 것만 TestRail에 올린다. Jira에 티켓 만든다. 공식 기록용이다. 팀 전체가 보는 것. 3단계: 엑셀로 실행 실제 테스트할 때는 내 엑셀 시트 본다. 더 디테일하다. 더 빠르다. 내 손에 익었다. 4단계: 툴로 보고 결과는 다시 툴에 입력한다. Jira 버그 상태 업데이트. TestRail 테스트 결과 입력. 이건 해야 한다. 공식 프로세스니까. 5단계: 엑셀로 분석 주말에 데이터 정리한다. 트렌드 본다. 다음 주 계획 세운다. 엑셀이 가장 편하다. 이중 작업 같지만 각각 목적이 다르다. 툴은 협업과 기록용. 엑셀은 실무와 분석용. 둘 다 필요하다. 주변의 시선 다른 팀 사람들은 모른다. "아직도 엑셀 쓰세요? 우리는 다 Notion으로 옮겼는데." Notion도 써봤다. 예쁘다. 세련됐다. 근데 테이블 편집이 불편하다. 수식이 제한적이다. 로딩이 느리다. 결국 엑셀로 돌아왔다. 개발자들도 가끔 비웃는다. "QA는 엑셀만 보네요." 내가 답한다. "네, 엑셀로 당신 버그 트래킹하고 있어요." 농담처럼 말하지만 사실이다. 신입 때는 부끄러웠다. 남들 다 멋진 툴 쓰는데 나만 엑셀이라고. 지금은 신경 안 쓴다. 결과가 중요하지 수단이 중요한 게 아니다. 내가 제시간에 정확하게 테스트하고, 버그 잘 찾아내고, 리포트 빠르게 만들면 된다. 그게 엑셀로 되면 엑셀 쓰는 거다. 미래는 어떨까 솔직히 모르겠다. 5년 후에도 엑셀 쓰고 있을까. 자동화 비중이 늘어나면 엑셀 쓸 일이 줄긴 할 것이다. AI가 테스트하는 시대가 오면 내 엑셀도 쓸모없어질지 모른다. 근데 지금은 아니다. 지금은 엑셀이 내 무기다. 내 작업 속도를 2배로 만들어주는 도구다. 동료가 물어봤다. "엑셀 장인 되는 게 목표예요?" 아니다. 좋은 QA가 되는 게 목표다. 엑셀은 수단일 뿐이다. 근데 지금은 최고의 수단이다. 나중에 더 좋은 게 나오면 그걸 쓸 것이다. 도구에 집착하진 않는다. 다만 지금 이 순간, 엑셀만큼 내 일을 잘 이해해주는 툴은 없다. 오늘도 엑셀을 연다 퇴근 30분 전이다. 내일 테스트 시트를 만든다. 템플릿 복사. 날짜 입력. 테스트 항목 정리. 5분이면 끝난다. 팀장님이 지나가면서 본다. "또 엑셀이네요." "네, 제일 편해서요." "그래도 자동화는 공부해야죠." "네, 주말에 강의 들을 거예요." 진짜 들을 건지는 모르겠다. 아마 또 미룰 것이다. 당장 다음 주 배포가 급하다. 엑셀 파일을 저장한다. 백업도 한다. 4년 치 데이터가 여기 있다. 내 QA 커리어가 여기 있다. 누가 뭐래도 이건 내 자산이다. PC를 끈다. 가방을 챙긴다. 내일 아침, 가장 먼저 열 파일은 이미 정해져 있다. 역시 엑셀이다.엑셀 없으면 일 못 한다. 그게 현실이다.
- 28 Dec, 2025
버그 수정 확인 - 개발자와의 그 짧은 대화
버그 수정 확인 - 개발자와의 그 짧은 대화 그 한마디 "민수씨, 수정했어요." 슬랙 메시지다. 오전 10시 43분. 어제 등록한 버그. JIRA-4521. 로그인 후 프로필 사진 안 뜨는 거. Priority: High. 배포 2일 전이다. "확인하겠습니다." 답장 보내고 빌드 받는다. 20분 걸린다.설치 완료. 로그인한다. 프로필 사진 뜬다. "오, 됐네?" 근데 뭔가 이상하다. 로그아웃했다가 다시 들어간다. 안 뜬다. 다시 켜본다. 뜬다. 앱 강제 종료. 재실행. 안 뜬다. "아..." 두 번째 메시지 "재현 스텝이요." 슬랙에 쓴다. 스크린샷 3장 첨부.로그인 앱 강제 종료 재실행 프로필 사진 안 뜸개발자 답장. 5분 후. "아 그건 캐시 문제일 거예요. 다음 빌드에서 볼게요." Priority가 High에서 Critical로 바뀐다. 배포 2일 전인데. 점심 먹으러 간다. 김치찌개 맛이 없다. 오후의 반복 오후 2시. 새 빌드 온다. "이번엔 진짜 고쳤습니다." 설치한다. 같은 시나리오 돌린다. 된다. 10번 반복한다. 다 된다. "좋아." 근데 직감이 있다. 뭔가 더 해봐야 할 것 같다. 네트워크 끊어본다. 와이파이 껐다 켠다. 프로필 사진 깨진다. 엑스박스 아이콘. "하..."그 짧은 대화 개발자 자리로 간다. 3미터 거리. "저기요, 네트워크 상태 변경하면..." "아 맞다. 그것까지는 못 봤네요." "언제 가능할까요?" "음... 내일 오전?" 배포 하루 전이다. "네, 기다릴게요." 자리 돌아온다. TestRail에 체크한다. "Fixed (Partial)". 커피 마신다. 네 번째다. 신뢰의 문제가 아니다 '수정했어요'를 못 믿는 게 아니다. 개발자가 거짓말하는 것도 아니다. 그냥 '수정했다'의 정의가 다른 거다. 개발자: "코드 수정했다 = 수정 완료" QA: "모든 시나리오 통과 = 수정 완료" 이 간극. 매번 경험한다. 신입 때는 속상했다. "왜 대충 고쳐?" 3년 차쯤 깨달았다. 개발자는 자기가 고친 케이스만 본다. 당연하다. 시간도 없고, 엣지 케이스는 생각 안 난다. 그게 QA 역할이다. 근데 이걸 설명하기 힘들다. "의심해서 죄송합니다" 같은 느낌 들 때 있다. 체크리스트 버그 수정 확인할 때 내가 하는 것.리포트한 시나리오 그대로 (기본) 반대 순서로 빠르게 연속으로 느리게 하나씩 네트워크 끊고 백그라운드 갔다가 권한 꺼보고 다른 기기에서 이전 빌드랑 비교 관련 기능 리그레션10개 다 하면 30분 걸린다. 시간 없으면? 줄인다. 근데 줄이고 나서 배포하면 불안하다.내일 오전 다음 날. 9시 30분. 빌드 온다. "네트워크 이슈 수정" 설치. 테스트 시작. 로그인. 정상. 앱 종료. 재실행. 정상. 네트워크 끊기. 정상. (캐시된 이미지 표시) 와이파이 켜기. 정상. (이미지 갱신) 비행기 모드. 정상. LTE 전환. 정상. 10번 반복. 다 정상. "됐다." JIRA 상태 변경. "Verified". 개발자한테 슬랙. "확인 완료했습니다." 답장. "감사합니다 ㅎㅎ" 이 'ㅎㅎ'에 안도가 느껴진다. 그래도 나오는 버그 배포했다. 다음 날 아침. CS 문의 들어온다. "프로필 사진이 다른 사람 걸로 나와요." "...뭐?" 재현 안 된다. 우리 계정으로는. CS팀이랑 통화한다. 자세한 상황 듣는다. "아, 계정 두 개로 번갈아 로그인하셨구나." 테스트 안 한 시나리오다. 핫픽스 들어간다. 개발자: "QA에서 확인 안 하셨어요?" "..." 말 안 한다. '계정 두 개 케이스는 스펙 문서에 없었는데요' 같은 거. 버그 등록한다. JIRA-4527. "계정 전환 시 프로필 사진 캐시 이슈" Priority: Critical. 완벽한 검증은 없다 4년 했다. 깨달은 거. 모든 케이스 다 볼 수 없다. 시간도 부족하고, 상상력도 한계 있다. 그래도 최대한 본다. 개발자가 '수정했어요' 하면, 믿으면서도 의심한다. 이상한 관계다. 근데 이게 QA다. 신뢰는 '맹신'이 아니라 '검증 후 확신'이다. 대화가 쌓이면 6개월 함께 일한 개발자가 있다. 처음엔 서로 불편했다. 나: "여기 또 재현돼요." 개발자: "제 폰에선 안 그러는데요." 이게 한 달 반복됐다. 근데 어느 순간부터. 개발자: "민수씨, 이 케이스도 확인 부탁드려요." 자기가 놓칠 수 있는 거 미리 말한다. 나: "네트워크 전환이랑 권한 쪽 집중적으로 볼게요." 확인 범위 얘기한다. 대화가 짧아졌다. 근데 신뢰는 더 깊어졌다. '수정했어요'의 의미를 서로 안다. "코드는 고쳤고, 기본 케이스는 확인했다. 나머지는 QA가 봐줄 거다." 이걸 말 안 해도 안다. 금요일 저녁 배포 직전. 6시. 마지막 빌드 확인 중이다. 개발자가 지나가다 묻는다. "민수씨, 그거 됐어요?" "네, 확인 중이에요. 10분 후에 답 드릴게요." "네, 감사합니다." 10분 후. 슬랙. "최종 확인 완료. 배포 가능합니다." "고생하셨습니다!" 배포 버튼 누른다. PM이. 모니터링 시작한다. 나랑 개발자랑. 30분 후. 특이사항 없다. "오늘은 괜찮은가 봐요." 개발자가 웃는다. "민수씨가 확인해서 그런 거죠." "에이, 뭘요." 근데 기분 좋다. 그 짧은 대화의 무게 "수정했어요." 세 글자다. 네 음절. 근데 이 뒤에 30분 검증이 있다. 10가지 시나리오가 있다. 불안과 확신이 있다. 개발자는 코드를 고친다. QA는 수정을 검증한다. 둘 다 필요하다. '수정했어요'를 믿는 건 맹신이 아니다. 검증하겠다는 약속이다. 퇴근길 7시 반. 집에 간다. 지하철에서 앱 켠다. 우리 서비스 아닌 거. 로그인한다. 프로필 사진 확인한다. "잘 뜨네." 앱 종료했다가 다시 켠다. 프로필 사진 안 뜬다. "..." 다른 회사 QA 생각한다. '쟤도 지금 야근 중이겠네.''수정했어요' 뒤에는 '확인하겠습니다'가 따라온다. 이 짧은 대화가 품질을 만든다.
- 27 Dec, 2025
QA는 아무나 하는 거 아니야 - 세상 모르는 사람들에게
QA는 아무나 하는 거 아니야 - 세상 모르는 사람들에게 또 들었다 "QA요? 그냥 앱 좀 만져보는 거 아니에요?" 고등학교 동창 결혼식에서 들었다. 옆자리 누군가가 물어봤다. 뭐 하냐고. QA 엔지니어라고 했다. 반응이 시큰둥했다. "아, 그거 클릭하고 버그 찾는 거?" "개발은 못 하고?" "그거 아르바이트생도 하던데." 웃으면서 넘겼다. 설명할 기력이 없었다. 어차피 이해 못 한다. 집에 와서 생각했다. 언제까지 이럴 건가. 왜 매번 설명해야 하나. 왜 QA는 쉬운 일로 보이나.아무나 못 한다 4년 했다. 아직도 배운다. 매일 새로운 엣지 케이스가 나온다. 매일 예상 못 한 버그를 만난다. 입사 동기 중에 3명이 QA였다. 1년 안에 2명이 그만뒀다. "생각보다 힘들어서요." "단순 반복인 줄 알았는데." 남은 1명이 나다. 왜 버텼나. 버그를 찾는 게 재밌어서. 시스템을 이해하는 게 좋아서. QA는 앱을 가장 깊이 아는 사람이다. 개발자는 자기 파트만 안다. 기획자는 스펙만 안다. QA는 전체를 본다. 로그인부터 결제까지. 메인 플로우부터 서브 기능까지. 정상 케이스부터 비정상 케이스까지. 모든 경로를 다 안다. 그게 아무나 하는 거라고? 실제로 하는 일 오전 9시 30분. 어제 올라온 빌드 다운. 체인지로그 확인. 수정된 기능 3개, 신규 기능 1개. 테스트 케이스 작성. 정상 플로우 10개. 예외 상황 15개. 엣지 케이스 8개. 실행한다. 5번째 케이스에서 크래시. 재현한다. 3번 연속. Jira에 등록. 재현 스텝 작성:로그인 (테스트 계정) 마이페이지 진입 프로필 수정 탭 닉네임 입력창에 이모지 30개 연속 입력 저장 버튼 클릭 크래시 발생로그 첨부. 스크린샷 5장. 디바이스 정보. OS 버전. 앱 버전. 개발자가 답글 단다. "제 폰에선 안 그러는데요?" 다시 재현. 영상 녹화. 슬랙으로 전송. "이거 보세요." 오후 2시. 수정 빌드 올라왔다. 다시 테스트. 이번엔 통과. 근데 다른 게 깨졌다. 프로필 사진이 안 보인다. 또 등록. 이게 오전이다. 오후는 더 복잡하다.책임의 무게 배포일이다. 새벽 2시까지 테스트했다. 눈 감고도 테스트할 수 있다. 모든 케이스 통과했다. 배포한다. 오전 10시. 오후 3시. 슬랙에 메시지. "결제가 안 돼요." 심장이 멎는다. 어떻게 놓쳤지. 테스트했는데. 분명 했는데. 확인한다. 아이폰 13 이상에서만 발생. 내 테스트폰은 아이폰 12였다. 디바이스 커버리지 부족. 핫픽스 들어간다. CTO가 물어본다. "QA는 뭐 했어요?" 말이 안 나온다. 변명해봤자다. 내 책임이다. 그날 퇴근하면서 생각했다. QA가 놓치면 유저가 본다. 유저가 보면 회사 이미지 타격. 타격은 매출로 이어진다. 무거운 일이다. 아무나 못 한다. 보이지 않는 전문성 사람들은 모른다. 테스트 케이스 설계가 얼마나 어려운지. 어디를 찔러야 버그가 나올지 아는 감. 시스템 동작 원리 이해. HTTP 통신 안다. Charles Proxy로 패킷 잡는다. API 응답값 확인한다. 프론트 문제인지 백엔드 문제인지 구분한다. 로그 본다. 에러 코드 해석한다. 스택 트레이스 읽는다. 개발자한테 구체적으로 전달한다. SQL 쿼리 짠다. 테스트 데이터 직접 만든다. DB 상태 확인한다. 데이터 정합성 체크한다. Git 쓴다. 브랜치 전략 안다. 어느 커밋에서 버그 생겼는지 추적한다. 자동화 스크립트 짠다. Python, Selenium, Appium. Regression 테스트 자동화한다. CI/CD 파이프라인에 붙인다. 이게 클릭만 하는 일인가.개발자와의 관계 개발자랑 싸운다. 매일은 아니고 자주. "이거 버그예요." "스펙이에요." 기획서 다시 본다. 애매하다. 기획자한테 물어본다. "이건 버그 맞아요." 개발자한테 다시 간다. "기획자가 버그래요." "아, 네. 고칠게요." 이런 중재를 하루에 5번. 근데 좋은 개발자도 있다. 버그 리포트 보고 칭찬한다. "재현 스텝 완벽하네요." "덕분에 바로 찾았어요." 그럴 때 보람 있다. QA 잘했다는 생각. 애증이다. 서로 필요하다. 개발자 없으면 내가 테스트할 게 없다. QA 없으면 개발자는 유저한테 욕먹는다. 성장의 한계 고민이 있다. QA로 어디까지 갈 수 있나. 시니어 QA. QA 리드. QA 매니저. 그 다음은? 개발 전환? PM 전환? 아니면 계속 QA? 연봉도 고민이다. 같은 연차 개발자는 6000만원. 나는 4200만원. 능력 차이인가. 직무 차이인가. 회사에서 QA 가치를 모른다. "테스트 범위 줄여주세요." "일정이 빠듯해서요." 품질보다 속도. 버그보다 일정. 그럴 때마다 회의감. 내가 뭐 하는 건가. 그래도 계속한다 포기 안 한다. QA가 좋아서. 버그 찾았을 때 쾌감. 시스템 이해했을 때 만족감. 유저가 편하게 쓸 때 뿌듯함. 내가 막은 버그가 있다. 유저는 모른다. 개발자도 잊어버린다. 나만 안다. 그거면 된다. 자동화 공부한다. 더 효율적으로 일하려고. 더 많은 케이스 커버하려고. QA 커뮤니티 활동한다. 다른 QA들 만난다. 고민 공유한다. "나만 그런 거 아니구나." 블로그 쓴다. QA 노하우 정리한다. 나중에 후배 생기면 도움 될 것. 말하고 싶다 QA는 전문직이다. 아무나 못 한다. 클릭만 하는 게 아니다. 생각한다. 분석한다. 판단한다. 책임진다. 무겁다. 힘들다. 근데 필요하다. 누군가는 해야 한다. 다음에 또 들으면 말할 거다. "한번 해보시겠어요?" "테스트 케이스 100개 만들어보세요." "배포 전날 밤샘해보세요." 그럼 알 거다. QA가 뭔지.내일도 버그 찾으러 간다. 오늘보다 더 많이.
- 26 Dec, 2025
회귀 테스트(Regression Test) - 내 일의 대부분이 이거다
회귀 테스트, 내 업무의 70% 오늘도 회귀 테스트다. 새 기능 하나 추가됐다. "소셜 로그인 카카오 추가"래. 그래서 뭐? 기존 이메일 로그인도 테스트해야 한다. 네이버 로그인도. 애플 로그인도. 로그아웃도. 자동 로그인도. 개발자가 말한다. "로그인 쪽 코드는 안 건드렸는데요?" 믿을 수 없다. 지난주에도 똑같은 말 들었다. 결제 모듈 수정했는데 장바구니가 깨졌었다. "안 건드렸다"는 말은 "모르겠다"랑 같은 말이다.회귀 테스트. Regression Test. 새 기능 때문에 기존 기능이 깨지는 걸 찾는 작업. 내 업무 시간의 70%가 이거다. 테스트 케이스 850개. 한 번 다 돌리면 3일 걸린다. 매번 다 할 수는 없다. 그래서 우선순위를 정한다. Critical 케이스 200개는 무조건. 로그인, 결제, 회원가입. 이거 깨지면 서비스 마비다. High 케이스 350개는 선택적으로. 이번 수정이랑 관련 있는 것 위주로. Medium 이하는 대충 샘플링. 시간 있으면 한다. 없으면 못 한다. 오늘의 참사 오전 10시. 빌드 받았다. 테스트 시작했다. 카카오 로그인 잘 된다. 좋아. 그런데 기존 이메일 로그인이 이상하다. 비밀번호 찾기 버튼 눌렀는데 화면이 안 뜬다. 뒤로가기도 안 된다. 앱이 멈춘다. 버그 등록했다. [BUG-2847] 이메일 로그인 > 비밀번호 찾기 화면 응답 없음. 재현 스텝 적었다:앱 실행 이메일 로그인 선택 '비밀번호를 잊으셨나요?' 클릭 화면 멈춤스크린샷 3장 첨부. 로그 파일 첨부. 디바이스 정보 적었다. 개발자한테 슬랙 날렸다. "민우님, BUG-2847 확인 부탁드려요." 답장 왔다. "제 폰에선 잘 되는데요?"여기서부터가 지옥이다. 내 폰 버전: Android 13, 갤럭시 S22 개발자 폰: Android 14, 갤럭시 S23 버전 차이일 수 있다. 다른 폰으로 해봤다. Android 12. 똑같이 멈춘다. 개발자 자리로 갔다. 내 폰 보여줬다. 재현했다. 화면 멈췄다. "아..." 개발자 얼굴이 굳었다. "네비게이션 스택 문제네요. 카카오 로그인 추가하면서 라우팅 로직 바꿨는데..." 그러니까 안 건드렸다는 게 아니었다. 간접적으로 건드린 거다. 이게 회귀 테스트의 본질이다. A를 고쳤는데 B가 깨진다. 코드는 다 연결돼 있다. 효율성 문제 오후 3시. 팀장이 물었다. "민수야, 회귀 테스트 언제까지 걸려?" "850개 케이스 다 하면 3일이요." "배포가 내일 모레인데?" "그럼 Critical이랑 High만 하면 1.5일?" "내일 오전까지 안 돼?" 불가능하다. 물리적으로 불가능하다. 결국 타협했다. Critical 200개만 오늘 안에. High는 내일 오전까지. Medium 이하는 포기. 이게 현실이다. 완벽한 회귀 테스트는 없다. 시간과 리소스는 한정돼 있다.그래서 전략이 필요하다. Risk-Based Testing 위험도 높은 것부터 한다. 결제 관련은 무조건 1순위 회원 데이터 관련 2순위 UI 깨짐은 나중에이번 수정이 로그인이면 로그인 주변을 집중적으로. Impact Analysis 개발자한테 물어본다. "이번에 어느 파일 수정했어요?" 로그인 모듈이면 로그인 관련 케이스 집중. API 레이어면 모든 네트워크 요청 체크. UI 컴포넌트면 해당 화면들 위주로. 개발자가 정확히 말 안 해주면 답이 없다. "그냥 여기저기요"라고 하면 끝이다. 전부 다 해야 한다. Test Case 우선순위화 엑셀에 정리해뒀다.ID Feature Priority Last Failed Execution TimeTC-001 로그인 Critical 2주 전 2분TC-002 결제 Critical 1주 전 5분Last Failed가 최근인 것부터 한다. 자주 깨지는 케이스가 또 깨질 확률이 높다. 자동화의 필요성 저녁 8시. Critical 200개 끝났다. 손목이 아프다. 클릭만 3000번 한 것 같다. 자동화해야 한다. 알고 있다. 다들 안다. 회사에 Appium 있다. Selenium도 있다. 아무도 안 쓴다. 이유가 있다. 시간이 없다 자동화 스크립트 짜려면 시간이 필요하다. 한 케이스당 1시간씩 잡아도 850시간. 6개월 풀로 매달려야 한다. 그 시간에 수동 테스트를 해야 한다. 배포는 매주 있다. 유지보수 비용 UI가 바뀌면 스크립트도 바뀌어야 한다. ID 하나 바뀌면 테스트 10개가 깨진다. 그럼 고치는 데 또 시간 쓴다. 차라리 수동으로 하는 게 빠를 때가 있다. 전문성 부족 나는 코딩을 잘 못한다. Python 기초는 안다. Appium 예제 따라는 할 수 있다. 근데 복잡한 시나리오는 못 짠다. 동적 요소 처리, 타이밍 이슈, 예외 처리. 어렵다. 개발자한테 부탁하면 "바빠요"라고 한다. 당연하다. 본인 일도 바쁜데. 그래도 해야 한다. 지금 상태로는 확장이 안 된다. 케이스는 계속 늘어난다. 나는 하나다. 자동화 시작 이번 주부터 시작했다. 매일 1시간씩 자동화 스크립트 짠다. 퇴근 전에. 우선 Critical 케이스부터. 로그인, 로그아웃, 결제. 이 20개만 자동화해도 2시간이 절약된다. Appium 튜토리얼 봤다. 첫 스크립트 짰다. # 로그인 테스트 driver.find_element(By.ID, "email_input").send_keys("test@test.com") driver.find_element(By.ID, "password_input").send_keys("test1234") driver.find_element(By.ID, "login_button").click()실행했다. 실패했다. ID가 안 맞는다. 개발자가 바꿨나 보다. 개발자한테 슬랙 날렸다. "ID 좀 고정으로 해주세요. 테스트 자동화 때문에." 답 왔다. "넵, 다음 빌드부터 적용할게요." 작은 진전이다. 자동화는 하루아침에 안 된다. 조금씩 쌓아야 한다. 회귀 테스트의 딜레마 밤 11시. 집 도착. 오늘 회귀 테스트에서 버그 8개 찾았다. 새 기능 테스트에서 찾은 건 3개. 회귀에서 찾은 게 더 많다. 이게 현실이다. 새 기능보다 기존 기능이 더 자주 깨진다. 그런데 회귀 테스트는 눈에 안 띈다. "민수는 오늘 뭐 했어?" "회귀 테스트요." "결과는?" "이상 없었어요." 이상 없으면 한 일이 없는 것처럼 보인다. 버그 안 찾으면 "일 안 한 거 아냐?" 찾으면 "QA가 늦게 찾아서 일정 밀렸다." 억울하다. 버그 안 나온 건 내가 잘 테스트해서가 아니다. 운이 좋았거나, 버그가 원래 없었거나. 내 공은 아니다. 버그 나온 건 내가 놓친 게 아니다. 케이스가 850개인데 200개밖에 못 했다. 시간이 없었다. 그래도 한다. 해야 한다. 내일도 회귀 내일도 회귀 테스트다. High 케이스 350개. 아침 9시부터 시작해서 내일 오후까지. 개발자가 오늘 수정한 버그들도 다시 체크해야 한다. Regression on regression. 점심시간 30분. 커피 한 잔. 클릭 클릭 클릭. 손목 아프다. 눈 아프다. 같은 화면 100번 본다. 그래도 이게 내 일이다. 품질을 지키는 일. 회귀 테스트 없으면 서비스는 망한다. 새 기능 하나 추가하고 기존 기능 열 개 깨지는 앱. 쓸 사람 없다. 자동화 조금씩 한다. 우선순위 정리 계속한다. 개발자랑 협업 개선한다. 언젠가는 나아질 거다. 아마도.회귀 테스트, 끝이 없다. 그래도 해야 한다.
- 25 Dec, 2025
배포 1시간 전, 갑자기 '테스트 범위 줄여주세요'
배포 1시간 전, 갑자기 '테스트 범위 줄여주세요' 오후 4시, 슬랙 메시지 배포는 6시다. 2시간 남았다. 리그레션 테스트 중이다. 핵심 플로우 80% 완료. 슬랙 알림 떴다. 개발팀장: "민수님, 5시까지 테스트 마무리 가능하세요? 배포 1시간 앞당겨야 할 것 같아요." 손이 멈췄다. 화면을 쳐다봤다. 테스트 케이스 234개. 완료 187개. 남은 거 47개. 계산했다. 1시간. 불가능하다. "범위 줄여야 할까요?" 내가 먼저 물었다. 항상 이렇다. "핵심만 보고 넘어가죠." 대답은 빠르다. 준비된 답처럼. 키보드 앞에 앉아있다. 어떤 걸 빼야 하지.4년차의 판단 테스트 범위를 줄인다. 말은 쉽다. 실제론 어렵다. 체크리스트 열었다. 빨간색으로 핵심 플로우 표시되어 있다. 로그인, 결제, 주문. 이건 무조건이다. 노란색은 중요. 프로필 수정, 장바구니, 검색. 파란색은 부가 기능. 공유하기, 즐겨찾기, 알림 설정. 파란색부터 지운다. 47개가 32개로 줄었다. 아직도 많다. 노란색을 본다. 프로필 수정은 이번 배포에 안 건드렸다. 패스. 장바구니는... 결제랑 연결된다. 건드리면 위험하다. 남긴다. 검색은 UI만 바뀌었다. 로직은 그대로. 간단히만. 32개가 21개로. 1시간이면 가능하다. 빡빡하지만. 엑셀에 정리한다. "테스트 제외 항목" 시트 만들었다. 제외 사유 적었다. "이번 배포 미반영", "회귀 위험도 낮음", "시간 제약". 문서화한다. 항상. 나중에 버그 나면 내 방어막이다.머릿속 시뮬레이션 테스트 시작 전에 생각한다. 만약 이거 안 하고 배포하면? 검색 기능. UI만 바뀌었다. 근데 검색 결과 정렬 로직은? 혹시 건드렸나? 지라 티켓 다시 확인했다. "UI 개선"만 적혀있다. 코드 변경 범위는 안 적혀있다. 개발자한테 물었다. "지훈씨, 검색 UI 수정할 때 정렬 로직도 건드렸어요?" "아뇨, CSS만 바꿨어요." "확실해요?" "네." 믿는다. 근데 테스트는 한다. 검색 한 번, 정렬 한 번, 필터 한 번. 3분이면 된다. 즐겨찾기는 뺀다. 이번 배포랑 상관없다. 2주 전부터 안 건드렸다. 근데 찜찜하다. 항상 이렇다. 머릿속으로 시나리오 그린다. 유저가 즐겨찾기 눌렀다. 안 된다. 컴플레인 들어온다. "QA는 뭐 했어요?" "이번 배포랑 무관한 부분이라..." "그래도 테스트는 했어야죠." 변명처럼 들린다. 항상. 그래도 뺀다. 시간이 없다. 리스크 관리다. 완벽한 QA는 없다.4시 30분, 실전 타이머 켰다. 1시간 30분. 집중한다. 로그인. 일반 로그인, 소셜 로그인, 자동 로그인. 통과. 회원가입. 이메일 중복, 약관 동의, 인증번호. 통과. 결제. 카드, 간편결제, 쿠폰 적용. 여기서 5분 더 걸렸다. 쿠폰 할인율이 이상하다. 슬랙 보냈다. "지훈씨, 쿠폰 10% 할인인데 9%만 적용돼요." "아 그거 반올림 이슈요. 수정할게요." 기다린다. 10분. 빌드 다시 받았다. 재테스트. 통과. 시계 봤다. 5시 20분. 남은 테스트 6개. 가능하다. 주문 내역. 취소, 환불, 배송 조회. 빠르게. 푸시 알림. 받음, 안 받음, 클릭 시 이동. 확인. 장바구니. 추가, 삭제, 수량 변경. 마지막. 5시 48분. 끝났다. 슬랙에 보고했다. "핵심 플로우 테스트 완료했습니다. 이슈 1건 수정 완료 확인. 배포 가능합니다." 개발팀장: "고생하셨습니다." 짧다. 항상 짧다. 배포 후, 6시 30분 배포 완료 메시지 떴다. 모니터링 시작한다. 센트리 확인. 에러 없다. 앱 리뷰 확인. 아직 조용하다. 슬랙 공지방 확인. 이상 없다. 긴장 풀렸다. 조금. 근데 찝찝하다. 테스트 안 한 26개 기능. 머릿속에 남아있다. 즐겨찾기, 공유하기, 프로필 수정... 만약 여기서 버그 나면? 확률적으론 낮다. 이번 배포에 안 건드렸으니까. 근데 완벽하게 안전한 건 아니다. QA는 항상 이렇다. 100% 확신은 없다. 확률 게임이다. 저녁 먹으면서 생각했다. '테스트 범위를 줄인다'는 건 '리스크를 떠안는다'는 거다. 내가 판단한다. 내가 책임진다. 무섭다. 가끔. 품질 vs 속도 4년 동안 배웠다. 완벽한 테스트는 불가능하다. 시간은 한정되어 있다. 리소스도 한정되어 있다. 버그는 무한하다. 선택해야 한다. 무엇을 테스트할 것인가. 무엇을 포기할 것인가. 회사는 속도를 원한다. 빨리 배포하고, 빨리 피드백받고, 빨리 수정한다. 애자일이라고 한다. 그럴듯하다. 나는 품질을 원한다. 버그 없는 앱, 매끄러운 경험, 안정적인 서비스. 이상적이다. 현실은 아니다. 타협한다. 매번. 중요한 건 기준이다. 어떤 기준으로 범위를 줄일 것인가. 내 기준은 이렇다.이번 배포 변경 범위 유저 영향도 과거 버그 히스토리 회귀 위험도이 네 가지로 판단한다. 결제는 무조건이다. 유저 영향도 최상. UI 변경은 가볍게. 로직 변경은 무겁게. 과거에 버그 많았던 기능은 꼼꼼히. 연관 기능 많으면 회귀 테스트 필수. 문서화한다. 항상. 판단 근거를 남긴다. 나중에 내 방어막이다. 개발자와의 대화 테스트 범위 줄일 때 제일 중요한 건 커뮤니케이션이다. 개발자한테 물어본다. "이번에 정확히 뭘 고쳤어요?" "연관된 부분은 없어요?" "어디까지 테스트하면 될까요?" 대답은 다양하다. 어떤 개발자는 친절하다. "여기 로직 바꿨고, 여기는 안 건드렸어요. 이 부분만 보면 돼요." 고맙다. 같이 일하기 좋다. 어떤 개발자는 애매하다. "음... 대충 다 봐주세요." 도움 안 된다. 내가 알아서 해야 한다. 어떤 개발자는 방어적이다. "제 로컬에선 문제없는데요." 알아. 근데 QA 환경에선 문제야. 신뢰 관계가 중요하다. 개발자를 믿어야 범위를 줄일 수 있다. "로직 안 건드렸어요" 말을 믿고 테스트를 패스한다. 근데 가끔 배신당한다. "안 건드렸다"는데 버그가 난다. 의도치 않은 사이드 이펙트. 그럴 땐 어쩔 수 없다. 다음부턴 더 꼼꼼히 본다. 4년 동안 배웠다. 말보다 코드 커밋 로그를 본다. "UI만 바꿨다"는데 로직 파일도 수정됐으면 의심한다. QA는 믿음과 의심 사이다. 배포 후 3일째 버그 없다. 다행이다. 테스트 안 한 26개 기능도 문제없다. 판단이 맞았다. 근데 항상 운이 좋은 건 아니다. 지난달 생각난다. 비슷한 상황이었다. 시간 없어서 범위 줄였다. 공유하기 기능 테스트 패스했다. 이번 배포 무관이라고 판단. 배포 3시간 후. 앱 리뷰 터졌다. "공유가 안 돼요." 확인했다. 새로 추가된 권한 체크 로직이 공유 기능을 막았다. 개발자도 몰랐다. 의도치 않은 버그. 팀장한테 불려갔다. "이번 테스트 범위에 공유 기능 없었나요?" "네, 이번 배포 변경 사항이 아니라서..." "그래도 기본 기능은 봐야죠." 할 말이 없었다. 핫픽스 나갔다. 야근했다. 집에 가면서 생각했다. 내 판단이 틀렸나? 시간이 부족했던 건가? 회사가 무리한 건가? 답은 없었다. QA는 이렇다. 버그 안 나오면 당연한 거고, 버그 나오면 QA 책임이다. 억울하다. 가끔. 내가 만든 체크리스트 실수 반복하고 싶지 않았다. 체크리스트 만들었다. "긴급 테스트 범위 축소 가이드" 절대 빼면 안 되는 것로그인/회원가입 결제 플로우 핵심 비즈니스 로직 법적/보안 관련 기능 이번 배포 직접 수정 항목조건부로 축소 가능UI만 변경된 기능 (로직 미변경 확인 필수) 부가 기능 (공유, 알림 등) AB 테스트 대상 (일부 유저만 노출)축소 시 문서화 필수 항목제외한 테스트 케이스 목록 제외 사유 잠재 리스크 배포 후 모니터링 계획이걸 팀 위키에 올렸다. 팀장이 좋다고 했다. "다음엔 이거 기준으로 합시다." 동료 QA가 물었다. "근데 이것도 지켜지지 않으면?" 웃었다. "그럼 또 야근하지 뭐." 현실은 그렇다. 가이드가 있어도 압박은 온다. "그냥 빨리 해주세요." 근데 있는 것과 없는 것은 다르다. 최소한 근거는 있다. 여자친구와의 대화 주말에 여자친구 만났다. 간호사라 바쁘다. 나도 바쁘다. 한 달에 두세 번 본다. 저녁 먹으면서 말했다. "요즘 일이 힘들어." "왜? 야근?" "그것도 있는데... 테스트 시간을 자꾸 줄이래." 그녀가 물었다. "그럼 뭐가 문제야?" "버그 놓칠 수 있잖아. 내 책임이 되고." "근데 시간 없으면 어쩔 수 없는 거 아니야?" "그래도..." 그녀가 웃었다. "나도 비슷해. 환자 많으면 한 명당 시간 줄어들어. 다 못 봐. 그래도 최선은 다해." "그게 되게 와닿네." "중요한 거 먼저 보고, 나머지는 다음에 보는 거지. 완벽은 없어." 간호사도 비슷하구나. 한정된 시간, 무한한 일. 우선순위 정하고, 트리아지하고, 최선을 다한다. 좀 위로됐다. "그래도 내가 놓친 버그로 유저가 피해 보면..." "너 혼자 책임 아니잖아. 팀이 있는 거고." 맞는 말이다. 근데 막상 당하면 혼자 책임지는 느낌이다. "다음에 그런 일 있으면 나한테 푸념해. 들어줄게." "고마워." 집에 오면서 생각했다. 완벽한 QA는 없다. 완벽한 간호사도 없다. 한정된 시간 안에서 최선을 다하는 것. 위로가 됐다. 조금. 4년차의 생존 전략 테스트 범위를 줄이는 건 기술이다. 경험이 쌓여야 한다. 신입 때는 몰랐다. 모든 걸 다 봐야 한다고 생각했다. 안 보면 불안했다. 2년차 때는 혼났다. 테스트 너무 오래 걸린다고. "핵심만 보세요." 3년차 때는 배웠다. 어떻게 줄이는지. 무엇을 봐야 하는지. 4년차인 지금은 안다. 완벽한 테스트는 환상이다. 리스크 관리가 현실이다. 내 생존 전략: 1. 문서화 모든 판단을 기록한다. 왜 이걸 제외했는지. 회의록, 지라 코멘트, 슬랙 메시지. 증거를 남긴다. 2. 커뮤니케이션 개발자한테 계속 물어본다. 정확히 뭘 고쳤는지. 어디까지 봐야 하는지. 애매하면 다시 물어본다. 3. 우선순위 기준 내 기준을 명확히 한다. 팀원들과 공유한다. 판단 근거를 설명할 수 있어야 한다. 4. 배포 후 모니터링 테스트 못 한 부분은 배포 후 바로 확인한다. 센트리, 앱 리뷰, 유저 문의. 빠르게 감지하고 대응한다. 5. 회고 배포 끝나면 복기한다. 놓친 게 있나, 개선할 점은 뭔가. 혼자 또는 팀과 함께. 이렇게 해도 완벽하지 않다. 그래도 최선이다. 밤 11시, 혼잣말 배포 끝나고 집에 왔다. 샤워하고 침대에 누웠다. 오늘도 살아남았다. 테스트 범위 줄이라는 말 들을 때마다 떨린다. 품질을 포기하는 것 같아서. 내 존재 이유가 흔들리는 것 같아서. 근데 이게 현실이다. 모든 걸 다 볼 수는 없다. 시간은 한정되어 있다. QA의 가치는 모든 걸 테스트하는 게 아니다. 중요한 걸 골라내는 거다. 리스크를 관리하는 거다. 4년 동안 배웠다. 완벽한 앱은 없다. 완벽한 QA도 없다. 그래도 나는 최선을 다한다. 주어진 시간 안에서. 내 판단을 믿고. 때로는 틀릴 수도 있다. 버그가 나갈 수도 있다. 그럼 배우고 개선한다. QA는 그런 일이다. 불확실성 속에서 판단하고, 책임지고, 다시 일어서는 것. 내일도 출근한다. 또 비슷한 일이 있을 것이다. "테스트 범위 줄여주세요." 괜찮다. 준비됐다. 핸드폰 꺼두고 잔다. 내일 또 싸운다."배포 1시간 전"은 QA의 일상이다. 완벽보단 최선을 택한다.