iOS 개발자가 올리브영 QA 엔지니어가 되기까지, 5개월간의 리얼 온보딩
안녕하세요! 25년 1월에 CJ올리브영 QA팀 QA 엔지니어로 합류한 구망🐧 입니다.
"QA팀에 신입이 있다고?" 아마 많은 분들이 고개를 갸우뚱하거나, 한편으로는 놀라실지도 모르겠습니다. 사실 QA 직무는 서비스에 대한 깊은 이해와 다채로운 테스트 경험을 요구하기에, 대부분의 기업에서 경력직 채용이 일반적인 것으로 알고 있습니다. 신입 QA 엔지니어를 육성하는 데 따르는 시간과 비용 부담 탓에, 신입 채용 자체가 흔치 않은 것이 업계의 현실입니다. 🥲
하지만 올리브영은 단순히 버그를 찾아내는 '검사자'의 역할을 넘어, 개발의 시작부터 고객 경험의 마지막까지 품질을 '설계'하고 '책임지는' QA 엔지니어의 가치를 높이 평가합니다. 그리고 그 가치에 투자하며, 잠재력 있는 신입 인재를 육성하는 데도 적극적입니다!
코드 한 줄이 미치는 영향력을 고민하던 개발자였던 제가, 이제는 올리브영의 서비스 품질을 책임지는 '신입 QA 엔지니어'라는 새로운 도전을 시작하게 된 이유도 바로 여기에 있습니다.
올리브영에 합류한 지 벌써 5개월. 개발 백그라운드를 가진 제가 어떻게 올리브영 QA팀의 차별화된 온보딩과 실무 문화에 스며들며 성장하고 있는지, 그 생생한 여정을 여러분께 소개하려 합니다. 🙌 국내 대표 H&B 트렌드 리딩 플랫폼을 넘어 글로벌로 나아가는 올리브영에서, 품질 최전선을 지키는 QA 엔지니어의 역할과 매력은 무엇인지, 저의 솔직한 경험담을 통해 함께 알아가 보시죠!
목차
- 개발자였던 내가 왜, QA 엔지니어를 선택하게 되었을까?
- 왜 하필 CJ올리브영 QA팀이었을까?
- 입사 후 깨달은 QA의 진짜 세계: 이론과 실무의 간극을 넘어
- 꼼꼼함만으로는 부족했던 세계
- 온보딩을 통해 배운 것들 – 문서로 체계화된 학습 여정
- 책에서 본 QA vs 실제 QA – 일하는 방식의 진짜 차이
- 첫 2주 온보딩 리얼 후기
- 마무리
개발자였던 내가 왜, QA 엔지니어를 선택하게 되었을까?
면접에서나 일상에서나 제가 최근에 가장 많이 들은 질문인데요!
"개발자에서 QA 엔지니어로 전환하는 이유는 무엇인가요?"
가장 큰 이유는 2가지 입니다.
- 정적 테스팅: 리뷰의 중요성을 깨닫다
- 내가 가장 뿌듯한 순간: 남들이 발견하지 못한 것을 찾아낼 때 🦅👀
[ 정적 테스팅: 리뷰의 중요성을 깨닫다 ]
저는 약 1년 반 정도 iOS를 개발한 경험이 있습니다. 개발자로 일할 때는 단순히 '개발만 잘하면 되지'라는 생각이 강했습니다.
보통 신규 기능이나 기존 기능이 변경될 때, 개발 단계 전에 기획서를 리뷰하는 시간이 있는데요.
처음에는 마감 일정을 지키기 위해 내 개발 업무에만 집중하는 것이 최선이라 생각했고, 다 같이 모여 리뷰하는 시간이 오히려 개발 시간을 뺏는 것 같다고 생각했습니다. 기획서에 명시된 대로만 구현하면 된다는 생각으로, 기획에서 놓친 부분이나 잘못된 부분에 대해 언급은 했지만, 기획자의 생각이 있겠지 라며 넘겨짚기도 했습니다.
하지만 이러한 태도는 결국 기획 의도와 다른 개발로 이어졌고, 이는 더 많은 업무와 스트레스를 초래했습니다.
예를 들어, 특정 화면에서 어떤 버튼을 눌렀을 때 A처럼 동작해야 하는 상황이 있었는데, 기획 문서에는 명확히 정의되어 있지 않았습니다. 해당 화면은 이전에 작업했던 화면과 구조가 거의 동일했기 때문에, 당연히 그전과 같은 방식으로 동작하면 될 거라 판단하고 개발을 진행했습니다. 하지만 실제로는 이전과는 다르게 동작했어야 했고, iOS / Android / WEB 모두 다시 수정해야 했습니다.🥹 만약 기획 리뷰 단계에서 세부 동작에 대해 한 번만 더 질문하고 확인했다면, 이런 비효율은 발생하지 않았을 것입니다. 이 경험을 통해 아무리 익숙한 기능이라도 기획을 추정해서는 안 되며, 왜❓라는 생각을 가지고 작더라도 모호한 부분은 반드시 리뷰를 통해 해소해야 한다는 점을 깨달았습니다.
이때 비로소 일은 혼자 잘하면 되는 것이 아니라, 각각의 담당자(PO, 디자이너, 개발자, QA 등)는 단순한 구현자가 아닌, 자신의 전문성을 바탕으로 당면한 문제를 함께 검토하고 개선해 나가며 결과물을 완성해 나가는 역할임을 깨닫게 되었습니다. 이후에는 요구사항을 단순히 따르는 것에 그치지 않고, 해당 요구사항이 왜 생겨났는지, 최선의 방법인지를 함께 고민하게 되었습니다.
이 과정에서 리뷰의 중요성을 새롭게 인식하게 되었고, SW 테스팅 관련한 서적(개발자도 알아야할 소프트웨어 테스팅 실무)에서도 리뷰는 단순한 문서 검토가 아닌, 동적 테스팅 전에 결함을 조기에 발견하고, 잘못된 방향으로 프로젝트가 진행되는 것을 사전에 방지하는 중요한 단계임을 인식하게 되었습니다. 그 결과 점점 품질에 대한 관심이 높아지게 되었습니다.
[ 내가 가장 뿌듯한 순간 ]
다음으로 내가 뿌듯했던 때는 언제였을까 인데요.
- 기획 리뷰 때 놓친 것이나 잘못된 것을 언급하는 것
- QA도 발견하지 못한 결함을 찾아내는 것
- 문제의 원인을 정확하게 알아내는 것
- 비효율을 제거하고 개선안을 제안하는 것
이 중에 제가 가장 뿌듯한 순간은 남들이 발견하지 못한 것을 찾아낼 때 🦅👀 입니다. 개발자로 일할 당시, 문자 인증 기능에서 인증번호 자동완성이 특정 단말에서만 작동하지 않는 이슈를 겪은 적이 있습니다. 사용자 입장에서는 너무나 당연한 기능이었기에, 원인을 조속히 파악할 필요가 있었죠.
QA 담당자와 함께 분석해봤지만, 초기에는 뚜렷한 단서를 찾지 못했습니다. 그러던 중 최근에 리뉴얼한 TextField(입력창) 쪽에 문제가 있을지도 모른다는 생각이 들어, 관련 코드를 중심으로 점검을 시작했습니다.
하지만 소스 코드상 특별한 이상은 없었고, 이후에는 외부 요인을 의심해보게 됐습니다. 문제 발생 시점과 그 이전을 비교하던 중, 인증 문자 메시지의 형식이 일부 변경되었음을 확인했습니다. 혹시나 싶어 이전 형식으로 테스트를 진행해보니, 문제 단말에서도 자동완성이 정상 동작하는 것을 확인할 수 있었습니다.
사실 정확한 원인을 파악하기까지는 예상보다 시간이 많이 걸렸습니다. 그 과정에서 ‘만약 이슈의 본질을 좀 더 빨리 짚어냈더라면, 해결 시점도 앞당길 수 있지 않았을까?’ 하는 아쉬움이 남았어요.
이 경험을 통해 문제를 파악할 때 단순히 기능적인 요소만이 아니라, 비기능적인 관점(성능, 보안, 사용성 등)까지 함께 살펴보는 시야가 중요하다는 걸 배우게 되었습니다.
이런 과정을 겪다 보니, 개발자로서 기능을 구현하고 문제를 해결하는 것도 흥미로웠지만, 이전 경험을 바탕으로 더 넓은 시각에서 문제를 바라보고 싶다는 확신이 들었습니다. 그렇게 저는 QA 엔지니어라는 새로운 역할에 도전하게 되었습니다.
왜 하필 CJ올리브영 QA팀이었을까?
[ 국내 대표 옴니채널을 넘어, 글로벌로 나아가는 올리브영 ]
현재 올리브영은 국내를 넘어 글로벌로 도약하고 있습니다. 이 올리브영의 끊임없는 성장 여정에 QA팀의 일원으로 함께할 수 있다는 것은 저에게 매우 뜻깊은 기회라고 생각했습니다. 단순히 품질을 검증하는 것을 넘어, 글로벌 고객을 대상으로 한 서비스 품질 향상과 더 높은 기준의 테스트 환경을 경험하며 저 역시 한층 성장할 수 있을 것이라 기대했습니다. 급변하는 시장과 기술 환경 속에서 QA 엔지니어로서 기여할 수 있는 범위가 더욱 넓어지고 있는 지금, 올리브영에서 다양한 도전과 경험을 통해 역량을 키워 나가고 싶다고 생각했습니다.
[ 대규모 트래픽 경험 기회 ]
'올영세일, 페스타, 라이브 등'과 같은 대규모 트래픽이 발생하는 이벤트에 QA 엔지니어로 직접 참여한다는 것은, 단순한 테스트를 넘어 실제 서비스 운영 환경에서의 품질 안정성과 시스템 대응력을 경험할 수 있는 매우 특별한 경험이라고 생각했습니다.
수많은 사용자가 동시에 몰리는 상황에서 발생할 수 있는 다양한 이슈를 예측하고 선제적으로 대응하는 과정은, 어디서도 쉽게 얻을 수 없는 실전 경험이자 QA로서의 역량을 빠르게 성장할 수 있는 발판이 된다고 느꼈습니다.
이 좋은 경험을 1년에 4번이상 경험할 수 있다니! 어디에서도 경험하지 못할 큰 기회라고 생각했습니다. 🙌
[ 높은 품질 인식 (feat. 인시던트 관리 프로세스) ]
종종 플랫폼 서비스들의 기술 블로그를 구경하는데, 올리브영 테크 블로그에 기억에 남는 글이 있었습니다. 그것은 바로 인시던트 관리 프로세스입니다.
국내 대표 옴니채널 서비스를 제공하는 만큼 다양한 문제들이 동시 다발적으로 발생하게 되는데, 이런 다양한 문제들에 어떻게 대응하는지 궁금했습니다. 인시던트 관리 프로세스는 인시던트 발생뿐만 아니라 재발 방지 대책 관리를 통해 후속 프로세스까지도 체계적으로 관리하고 있는 점이 인상 깊었습니다. 또한, 이슈를 투명하게 공개하고 같이 해결해 나가는 과정에서 개발 조직의 품질에 대한 인식이 매우 높다고 판단 되어 저도 꼭 같이 일해보고 싶다고 생각하게 되었습니다.
저 또한 입사 후 인시던트 알림 전화를 받아보았는데요. 이 전화 알림을 통해 장애에 빠르게 대응할 수 있는 점이 매우 좋다고 느껴졌습니다.
입사 후 깨달은 QA의 진짜 세계: 이론과 실무의 간극을 넘어
[ 꼼꼼함만으로는 부족했던 세계 ]
입사 전, QA는 꼼꼼함이 생명인 일이라고만 생각했습니다. 기능이 제대로 작동하는지만 확인하면 되는, 비교적 명확한 일이라는 이미지였습니다.
그런데 막상 실무에 들어가 보니, 그건 QA라는 일의 아주 일부에 불과했습니다. 제품의 신뢰도를 높이는 설계를 하고, 사용자 흐름을 지키며, 정책과 서비스의 일관성을 관리하는 일이었습니다.
그 인식의 전환은 온보딩 과정에서부터 차근차근 시작되었습니다.
[ 온보딩을 통해 배운 것들 – 문서로 체계화된 학습 여정 ]
입사 첫 주는 QA팀에서 마련한 온보딩 체크리스트를 따라가며, 실무에 필요한 지식과 툴을 익히는 시간이었습니다. 단순히 시스템 계정을 세팅하거나 툴을 설치하는 걸 넘어, 아래와 같은 실무형 항목들이 포함되어 있었는데요.
- QA 표준 프로세스 및 정책
- Jira와 Confluence를 활용한 이슈 관리 및 문서 구조
- CSP와 인시던트 관리 프로세스
- 트라이브/스쿼드 체계
이를 통해 자연스럽게 팀의 일하는 방식을 익힐 수 있었습니다.
특히 인상 깊었던 점은, 문서는 혼자 보기 위한 게 아니라, 모두가 함께 이해하기 위한 수단이다라는 관점이었습니다. 테스트 케이스 하나를 작성할 때도 협력사, 개발자, 기획자가 함께 보고 행동할 수 있도록 의도를 명확히 표현하고, 불필요한 중복을 줄이는 구조를 고민하게 되었습니다.
[ 책에서 본 QA 🆚 실제 QA – 일하는 방식의 진짜 차이 ]
입사 전, QA 직무에 대해 공부하며 접한 대부분의 자료는 테스트 기법, 버그 리포팅 요령, 결함 추적 방식 같은 이론적인 내용이 많았습니다.
또 책을 통해 제가 생각한 QA는 테스트 케이스를 얼마나 꼼꼼하게 작성했는지, 이슈를 얼마나 잘 찾았는지에 초점이 맞춰져 있었습니다.
| 구분 | 책/이론에서 본 QA | 실제 실무 QA (올리브영 기준) |
|---|---|---|
| 업무 개입 시점 | 개발 완료 후 테스트에 참여 | 기획 단계부터 리뷰에 참여하여 요구사항과 정책 검토 |
| 주요 역할 인식 | 버그를 찾고 리포트하는 사람 | 리스크를 선제적으로 예방하고, 품질을 설계하는 사람 |
| 테스트 관점 | 기능이 정상 동작하는지 확인 | 정책 준수 여부, 예외 흐름, 사용자 경험까지 고려 |
| 테스트 케이스(TC) | 문서로만 정리, 개인 작업 중심 | 협업 문서로 작성, 내부 팀 + 협력업체와 함께 리뷰 진행 |
| 문서의 역할 | 테스트 결과 기록용 | 팀 간 커뮤니케이션 도구, 이해관계자 모두가 보는 기준점 |
| 커뮤니케이션 | QA 내부 공유 중심 | Slack을 통한 실시간 이슈 공유 및 대응 프로세스 확보 |
| 협력업체와의 관계 | 외주에 일방적으로 테스트 위임 | TC 리뷰를 포함한 실질적 파트너십 구조로 협업 |
| 문제 해결 방식 | 테스트 결과를 개발자에게 전달 | 테스트 설계 → 실행 → 이슈 식별 → 공유 → 조치까지의 사이클을 QA가 주도 |
올리브영 QA팀은 개발이 시작되기 전 단계인 기획 리뷰부터 적극적으로 참여합니다.
서비스 정책이나 예외 흐름을 QA의 시선으로 검토하며, 설계 단계에서부터 리스크를 줄이는 것이 일의 시작이었습니다. 단순히 기능 명세서를 보고 테스트하는 것이 아니라, '이 기능이 실제로 어떻게 사용될까?', '이 흐름은 정책에 부합할까?'와 같은 질문을 던지며 전체 맥락을 파악하려는 시도들이 당연한 문화로 자리 잡고 있었습니다.
또한, 외부 협력업체와도 함께 테스트 업무를 수행하고 있습니다. 단순히 테스트를 맡기는 구조가 아니라, 테스트 케이스를 함께 리뷰하고, 정책 기준을 명확히 맞추는 체계적인 협업 프로세스를 운영합니다. 덕분에 실제 테스트를 수행하는 외부 인력도 제품에 대한 이해도가 높고, 정책 변경이나 기능 업데이트가 있을 경우 빠르게 정리된 내용을 서로 공유해 일관된 품질 검증이 가능합니다.
이슈가 발생했을 때의 대응 속도도 인상적이었습니다. 올리브영은 Slack을 통해 실시간으로 이슈가 공유되고, QA뿐 아니라 개발자, 기획자까지 함께 참여하는 스레드가 금방 만들어집니다. 누구든 문제를 먼저 발견하면 빠르게 알리고, 문서화하거나 Jira 티켓으로 연결하여 놓치지 않도록 체계화합니다.
이런 구조 덕분에, 신입인 저도 “무언가 이상하다”고 느끼는 순간 바로 공유할 수 있고, 투명하게 공유하는 습관이 형성되는 것 같습니다.
첫 2주 온보딩 리얼 후기
입사하고 한 동안은 실감이 잘 안났습니다. 하지만 부서배치를 받고 나니 점점 '이제 정말 QA엔지니어가 됐구나' 라는 실감이 들었는데요. 부서배치 근 2주간 어떤 일이 있었는지 소소하고 가볍게 소개해보려 합니다.
📚 첫날, 신입사원을 환영해주는 책상
자리에 도착하니 웰컴 키트와 각종 필요 물품들, 온보딩 가이드 문서가 놓여 있었습니다. 누군가가 제 첫날을 준비해 줬다는 부분이 든든하면서도 감사하게 느껴졌습니다. 동기분들에게 자랑했더니 최고라고 들었는데요 😎 덕분에 저에게는 어깨가 으쓱해진 첫 날이 되었습니다!
그리고 CTO님께서 환영의 꽃 풍선과 업무 적응에 도움이 되는 책 2권을 선물해주셨는데요. 점점 실감이 나면서도 의욕을 다지게 된 하루가 되었습니다.🔥
📢 2일차, 신입사원의 이슈 제보!
올리브영 Slack에는 어떤 이슈든 자유롭고 투명하게 공유하는 채널이 있는데요.
사소한 오타 하나를 발견해서 제보했더니 생각보다 핫한(?) 반응을 해주셔서 매우 뿌듯했습니다. 비록 매우 작은 이슈이지만, 신입도 이런 방식으로 품질에 기여할 수 있다 라는 자신감을 얻게 되었습니다.
제 주변 동기분들도 이걸 발견했다고? 하며 감탄해주셨는데, 이런 부분은 제 직무 전환 계기인 남들이 발견하지 못한 것을 찾는 것 🦅👀 과도 자연스레 이어지는 모습이네요!
🍚 2주차, 점심 어떻게 먹지? - 팀내 밥봇 워크플로로 점심 공유하기
조금 익숙해지던 2주차, QA팀의 경우 점심 스타일이 자유로운 편인데요! 그래서 매 점심시간마다 서로 어떻게 먹을 건지 논의하는 경우가 많았습니다. 이때, 서로의 점심 유형을 미리 공유하고 필요할 때만 논의하는게 어떨까?🧐 하는 생각에서 간단한 밥봇 워크플로를 만들게 되었습니다.
이모지로 서로의 점심 유형을 공유하고, 만일 배달 시켜 먹고 싶은 경우엔 배달 논의 버튼을 누르면 해당 스레드에 댓글이 생겨 배달 논의를 편하게 할 수 있도록 해보았습니다. 매우 작은 기능이지만, 서로의 점심 타입을 말하지 않아도 알 수 있다는 점에서 보다 편리해진 것 같습니다.🤩
마무리
여기까지 저의 입사 여정을 남겨보았습니다. 직무 전환 계기부터 온보딩까지 꽤 긴 글이 되었는데요. 작은 것부터 천천히, 팀 안에 스며드는 중이다 하는 느낌이 드는 요즘입니다.
입사 전엔 QA가 뒤에서 ‘검사하는 사람 🔍’이라 생각했다면, 지금은 제품을 함께 만들어가는 동료👩🏻🔧 라는 감각에 더 가까워졌습니다.
문서 한 줄을 작성할 때에도 누군가의 행동 흐름을 바꾸게 될 수 있다는 책임감, 단순한 오류 발견이 아니라 고객의 경험을 지키는 중요한 역할이라는 사명감, 이 모든 걸 매일 조금씩 배우고 있습니다.
앞으로도 팀의 일하는 방식과 철학을 깊이 이해하며, 서비스에 가장 먼저 의심을 제기할 수 있는 QA, 기술과 정책 사이의 간극을 메울 수 있는 QA엔지니어로 성장해가고 싶습니다.
다음엔 더 성장한 모습으로 나타나 보겠습니다! 긴글 읽어주셔서 감사합니다. 🙇🏻♀️
