← 전체 채용 포지션
품질 엔지니어링

QA 엔지니어

결과물이 생성되는 플랫폼을 위한 품질 엔지니어링.

부서
품질 엔지니어링
보고 대상
엔지니어링 리더십
경력
소프트웨어 품질 직무 약 2–5년
근무지
Las Vegas, NV (8400 W Sunset #300) — 전일 사무실 근무. 원격 또는 하이브리드 근무가 아닙니다.
고용 형태
정규직(풀타임)
취업 자격
미국 내 취업 자격 필수
지원하기 →

포지션 개요

Regara는 생명과학 산업을 위한 임상 및 규제 인텔리전스 플랫폼입니다. 의료기기, 제약, 바이오테크 기업들은 제품을 시장에 출시하는 데 필요한 것들 — 규제 전략, 임상 프로토콜, 연구 보고서, 허가 신청 자료 — 을 여러 시장에 걸쳐 계획하고 준비하기 위해 Regara를 사용합니다.

AI가 곧 제품입니다. Regara는 실시간 데이터를 조사하고, 이를 바탕으로 추론하며, 완성된 기술 문서를 처음부터 끝까지 작성하는 자율 에이전트 플랫폼을 운영합니다. 그래서 품질은 정말 어려운 문제입니다. 결과물은 고정된 것이 아니라 생성되며, 같은 입력으로도 두 번 다른 텍스트가 나올 수 있고, 최종 결과물은 고객이 규제 기관에 제출하는 문서입니다.

일반적인 QA 업무와 다른 점. 여기서 결함은 어긋난 버튼이 아닙니다. 잘못된 숫자, 근거 없는 주장, 또는 출처가 인용된 내용을 말하지 않는 인용입니다. 생성된 문서는 유창하고 형식이 잘 갖춰져 있으면서도 틀릴 수 있으며 — 화면 어디에도 그런 신호는 나타나지 않습니다. 고객보다 먼저 이를 잡아내는 것이 이 일입니다.

이 포지션은 품질에만 전념하는 역할입니다. 테스트 주기 사이에 제품 기능을 개발하기 위해 채용하는 것이 아니라, 회사에서 가장 어려운 품질 문제에 온전히 집중할 사람이 필요하기 때문에 채용합니다. 탐색적 테스트와 직접 작성한 테스트 케이스부터 결함 추적, 프로덕션에서의 수정 확인까지 하나의 테스트 영역을 처음부터 끝까지 책임지게 됩니다.

실제로 하게 될 일

01 · 탐색적 테스트와 기능 테스트

고객처럼 제품을 사용한 다음, 무너지는 지점을 찾아 나섭니다.

  • 디스패치 플로우, 결과 화면, 관리자 도구 전반에 걸쳐 기능 및 UI/UX 테스트를 수행합니다.
  • 경계를 탐색합니다 — 빈 상태, 과도하게 큰 입력, 중단된 실행, 권한, 브라우저 및 뷰포트 차이.
  • 개별 화면만이 아니라 고객이 실제로 사용하는 워크플로를 테스트합니다.
  • 매 릴리스를 다시 테스트하고 회귀를 잡아냅니다.

02 · 테스트 설계와 회귀 커버리지

배운 것을 어느 한 릴리스보다 오래 남는 반복 가능한 형태로 만듭니다.

  • 핵심 사용자 워크플로를 다루는 테스트 케이스와 체크리스트를 작성하고 유지합니다.
  • 팀이 릴리스 전에 실행하는 회귀 테스트 스위트를 책임지고, 제품 변화에 맞춰 최신 상태로 유지합니다.
  • 제품 전반에 대한 커버리지를 매핑하고 어디에 공백이 있는지 분명하게 말합니다.
  • 테스트하기 쉬운 것이 아니라 리스크를 기준으로 우선순위를 정합니다. 중요도가 낮은 영역은 철저히 다루면서 중요한 영역은 전혀 다루지 않는 스위트는 커버리지처럼 보이기 때문에 스위트가 없는 것보다 더 나쁩니다.

03 · 생성된 결과물 검증

이 일에서 가장 흥미로운 절반이자, 정해진 방법론이 없는 부분입니다.

  • 생성된 결과물의 내부 일관성을 확인합니다 — 숫자, 상호 참조, 섹션 완결성, 서식.
  • 에이전트가 생성한 식별자와 참조를 공식 출처와 대조합니다.
  • 근거 없는 주장, 잘못된 출처 표기, 그리고 내용이 해당 주장을 뒷받침하지 않는 인용을 찾아냅니다. 인용의 무결성은 이 제품에서 가장 중요한 품질 속성입니다.
  • 골든 예시를 기준으로 결과물을 평가하고 그 결과를 평가 스위트에 반영합니다.
  • 결과물이 비결정적일 때도 작동하는 테스트 방식을 설계합니다 — “기대한 문자열이 나왔는가”가 잘못된 질문인 상황에서.

04 · 결함 보고와 분류

버그 리포트는 하나의 결과물입니다. 읽는 사람이 추가 질문 없이 바로 조치할 수 있도록 작성하세요.

  • 최소한의 신뢰할 수 있는 재현 절차를 분리합니다 — “가끔 깨진다”가 아니라.
  • 재현 단계, 기대 결과와 실제 결과, 환경, 그리고 근거를 댈 수 있는 심각도를 포함해 보고합니다.
  • 결함을 그것이 깨뜨리는 요구사항이나 워크플로까지 추적합니다.
  • 코드 버그와 모델 품질 문제를 구분합니다. 담당자도 수정 방식도 다르며, 잘못 전달하면 모두의 일주일이 낭비됩니다.
  • 각 결함을 수정이 검증될 때까지 끝까지 추적합니다.

05 · 릴리스 검증과 품질 신호

누군가는 릴리스가 안전한지 말할 수 있어야 하고, 그 판단이 맞아야 합니다.

  • 릴리스 검증을 수행하고 빌드가 준비되었는지에 대해 명확하고 근거 있는 판단을 제시합니다.
  • 시간에 따른 품질 신호를 추적합니다 — 결함 추세, 유출률, 그리고 제품의 어느 부분에서 문제가 반복적으로 발생하는지.
  • 아무도 듣고 싶어 하지 않는 내용까지 포함해 품질 현황을 엔지니어링 팀에 서면으로 보고합니다.
  • 릴리스 상황이 나빠지고 있을 때 일찍 경고합니다. 늦은 경고는 없는 것보다 크게 나을 것이 없습니다.

06 · 테스트 자동화

손으로 하던 점검을 스스로 실행되는 점검으로 옮깁니다 — 효과가 확실한 곳에서.

  • 백엔드 커버리지는 pytest로, 프런트엔드 커버리지는 Vitest와 React Testing Library로 확장합니다.
  • 트래픽이 가장 많은 워크플로에 대해 브라우저 수준의 엔드투엔드 테스트를 작성합니다.
  • 테스트 스위트를 GitHub Actions에 연결해 실패가 머지 이후가 아니라 풀 리퀘스트 단계에서 드러나도록 유지합니다.
  • 신중하게 자동화합니다. 아무도 신뢰하지 않는 불안정한 스위트는 그것이 대체한 수동 점검보다 비용이 더 큽니다.

기술 스택

  • 백엔드 — Python 3.12, FastAPI, SQLAlchemy 2.0, Pydantic v2, Postgres / SQLite, pytest
  • 프런트엔드 — React 19, TypeScript (strict), Vite, TanStack Router + Query, Tailwind, shadcn/ui, Vitest + RTL
  • AI — 최신 LLM API(Claude), MCP 도구 서버, RAG, 평가 하네스 및 골든 출력 채점기
  • 인프라 — AWS (ECS/EC2, ECR, SQS, S3), Docker, GitHub Actions

이 모든 것을 알고 있을 필요는 없습니다. 대부분의 테스트는 코드베이스가 아니라 애플리케이션을 대상으로 진행됩니다 — 다만 버그의 원인을 추적할 때 읽게 되고, 자동화 스위트를 확장할 때 작성하게 되는 것이 바로 이것들입니다.

자격 요건

필수 요건

  • QA, 소프트웨어 품질 또는 테스트 엔지니어링 직무에서 실제 사용자가 있는 실제 제품을 테스트한 약 2–5년의 경력.
  • 컴퓨터 과학, 컴퓨터 공학 또는 관련 분야 학위 — 또는 이에 준하는 실무 경험.
  • 최소 한 가지 언어로 코드를 읽고 쓸 수 있는 역량. Python이나 TypeScript가 저희 스택에 가장 가깝지만 Java, C++ 등 다른 언어도 괜찮습니다.
  • 로드되지 않는 페이지뿐 아니라 미묘하게 틀린 값까지 잡아내는 세심함.
  • 명확한 기술 문서 작성 능력. 저희는 당신의 코드보다 버그 리포트를 더 많이 읽게 됩니다.
  • 1차 자료 — 사양서, 표준, API 계약 — 를 읽고 구현이 그 내용과 정확히 일치하는지 확인하는 능력.
  • 모호한 상황에서도 체계적으로 접근하는 태도. 막연한 불만을 그대로 에스컬레이션하지 않고 최소한의 재현 절차로 좁혀냅니다.
  • 최소 한 가지 테스트 프레임워크(pytest, Vitest, Playwright, Selenium 등)를 직접 사용한 경험.
  • Git과 풀 리퀘스트 워크플로에 익숙함.
  • 릴리스를 멈출 수 있는 의지. 이 역할은 때로 모두가 기다리는 상황에서도 빌드가 준비되지 않았다고 말해야 합니다. 그렇게 말하는 것이 이 일입니다.
  • 라스베이거스에서 풀타임 사무실 근무가 가능하고 미국 내 취업 자격을 보유한 분.

우대 사항

  • AI 또는 LLM이 생성한 결과물을 테스트하거나 평가 하네스를 구축·운영한 경험.
  • 규제 산업(의료기기, 제약, 임상 연구) 경험 또는 21 CFR Part 11, GxP, 컴퓨터 시스템 밸리데이션 경험.
  • 화면을 거치지 않고 데이터를 직접 검증할 수 있을 정도의 API 테스트 및 SQL 역량.
  • CI/CD 경험, 특히 GitHub Actions.
  • 접근성 테스트 또는 성능·부하 테스트 경험.
  • 테스트 프로세스가 없던 곳에 프로세스를 정립한 경험.
  • 스타트업 경험, 그리고 프로세스가 갖춰지기 전에도 일할 수 있는 유연함.

일하는 방식

  • 보기 좋은 예시 하나만으로 출시하지 않습니다. 모든 프롬프트, 검색, 도구 변경은 고객에게 전달되기 전에 회귀 스위트와 채점된 결과물 세트를 기준으로 평가됩니다. 저희는 숫자로 개선합니다.
  • 프로덕션까지의 빠른 루프. 첫 주부터 스테이징 환경에서 테스트하게 되며, 보고한 버그는 직접 수정 여부를 확인할 수 있을 만큼 빠르게 고쳐집니다.
  • 하나의 테스트 영역을 처음부터 끝까지 책임집니다. 탐색적 테스트와 직접 작성한 케이스부터 자동화와 결함 추적, 프로덕션에서의 수정 확인까지. 누군가 실행할 스크립트만 건네고 생각하는 일은 가져가 버리는 일은 없습니다.
  • 작은 팀, 직접적인 협업. 창업 엔지니어링 팀과 함께 일하며, 작성하는 모든 풀 리퀘스트에 코드 리뷰가 이뤄집니다.
  • 최전선에서 만듭니다. 새로운 모델 출시, 컨텍스트 및 캐싱 기능, 에이전트 도구를 나오는 즉시 따라가고, 더 낫다면 그에 맞춰 다시 만듭니다. 이곳에서 배우는 것은 늘 최신입니다.

기대 성과

  • 결함은 고객이 아니라 스테이징에서 발견되고, 유출률은 감소 추세에 있습니다.
  • 조작되었거나 잘못 표기되었거나 근거 없는 인용이 고객의 눈에 띄기 전에 내부에서 걸러집니다.
  • 스위트가 중요한 부분을 다루고 불안정하지 않기 때문에, 회귀 테스트의 통과가 실제로 의미를 가집니다.
  • 버그 리포트가 추가 질문 없이 처리됩니다.
  • 커버리지 공백은 사고로 발견되는 것이 아니라 사전에 파악되고 공유됩니다.
  • 모델 품질 문제와 코드 결함이 처음부터 올바른 담당자에게 전달됩니다.
  • 릴리스 결정에는 근거가 있고, 엔지니어링 팀은 당신의 판단을 신뢰합니다.

이 포지션이 존재하는 이유

전통적인 QA는 검증할 수 있는 정답이 있다고 가정합니다. 이곳에서는 시스템이 매번 새로운 것을 작성하며, 실패의 모습은 완벽하게 읽히지만 자신의 인용이 뒷받침하지 않는 주장을 담은 문서입니다. 이는 assertion을 추가한다고 해결되는 문제가 아닙니다 — 규제 기관처럼 결과물을 읽을 사람이 필요합니다. 그것이 이 포지션입니다.

지원

이 포지션에 지원하기.

QA 엔지니어

별표(*)로 표시된 항목은 필수 입력 항목입니다. 모든 지원서를 빠짐없이 검토합니다.

PDF, DOC 또는 DOCX · 최대 4MB
PDF, DOC 또는 DOCX · 최대 4MB