Tusk

Tusk

Tusk AI, Inc. · 코딩 · 생산성

Tusk는 풀 리퀘스트마다 단위 테스트와 API 테스트를 작성해 직접 실행하고, 발견한 버그를 알려주는 AI 테스트 에이전트다. Tusk AI, Inc.는 2026년 6월 10일 서비스를 종료했다.

Tusk 미리보기

Tusk 소개

What Is Tusk

Tusk는 2024년 Y Combinator W24 기수로 좁은 약속 하나를 들고 나왔다. 고객이 올린 버그를 에이전트에 넘기면 풀 리퀘스트가 돌아온다. 작은 개발팀은 열 줄짜리 수정에 오후를 통째로 쓰기 마련이고, Tusk는 그런 티켓을 책상에서 치우는 역할을 맡았다.

2026년의 Tusk는 AI 테스트 에이전트로 자리잡았다. 풀 리퀘스트마다 단위 테스트와 API 테스트를 만들고, 스스로 돌려 보고, 통과할 때까지 다시 손봤다. 테스트는 릴리스에서 누구도 시간을 내기 싫어하는 구간이고, Tusk는 시키지 않아도 처리하는 동료라는 문구로 팔렸다.

남은 것을 평가하려면 한계부터 봐야 한다. GitHub 저장소, 이미 갖춰진 테스트 스위트, 실패한 테스트를 여러 번 다시 돌려도 견디는 여유가 필요했다. 경계 조건을 잡아냈다는 수치는 자체 벤치마크에서 나온 값이고 외부 검증을 거치지 않았다.

결정적인 한계는 날짜다. Tusk AI, Inc.는 2026년 6월 11일 전날 서비스를 종료했다고 공지했다. GitHub App은 고객 조직에서 빠졌고, Tusk Drift 사용자는 SDK를 지우고 CI 워크플로를 삭제해야 했다. 지원은 종료 후 한 달 더 이어졌다. 회사는 테스트 자동화와 코드 리뷰 대안으로 Cognition의 Devin을 안내했다.

Getting Started

  1. Tusk 계정을 만들고 에이전트가 읽고 고칠 저장소에 GitHub App을 설치한다.
  2. 각 서비스 루트에 CLI를 설치한다. 명령 한 줄이면 되고, 초기 설정을 돌리면 Tusk가 기존 테스트 방식을 색인했다.
  3. 평소처럼 풀 리퀘스트를 연다. Tusk는 생성한 테스트를 댓글로 붙이고 CI에서 실행한 뒤 실패한 항목을 계속 고쳤다.
  4. 그 테스트를 다른 코드처럼 읽는다. 회사 설명으로는 생성한 테스트의 약 69%가 실제로 풀 리퀘스트에 병합됐다.

제품 정보

Tusk의 요금, 지원 플랫폼, 성능을 한눈에 확인해 보세요.

무료 플랜예
유료 플랜$0 - $50 per active dev/mo
플랫폼Web, CLI, GitHub App, CI/CD pipelines
개발사Tusk AI, Inc.
카테고리코딩 · 생산성
출시일Feb 2024
최근 업데이트Jun 2026
웹사이트 방문 수5.3K
웹사이트 글로벌 순위3.6M
API 제공 여부예

추천 대상

이 도구가 가장 잘 맞는 사용자, 작업, 상황입니다.

사용자

  • QA 전담 인력이 없는 작은 개발팀
  • 아직 코드를 직접 읽는 창업자
  • 백엔드와 플랫폼 엔지니어

작업

  • 릴리스 전 코드 커버리지 올리기
  • 풀 리퀘스트 회귀 잡기
  • 외부 API 계약 감시

활용 상황

  • 커버리지가 낮고 다시 쓸 예산도 없는 오래된 코드베이스
  • 하루에도 여러 번 배포하며 저장소가 서너 개인 팀
  • 이미 사라진 도구를 비교하는 경우

주요 기능

풀 리퀘스트마다 단위 테스트 작성

Tusk는 변경분을 읽고 기존 테스트에서 맥락을 가져와 단위 테스트를 풀 리퀘스트 댓글로 제안했다. 자기가 쓴 테스트를 실행하고 실패한 것은 다시 고쳤다. 돌려주는 결과가 제안이 아니라 실행되는 코드라는 뜻이다. 테스트를 귀찮은 일로 보던 팀에게는 편집기를 열지 않고도 작동하는 테스트를 얻는 것이 전부였다.

실제 트래픽으로 만드는 API 테스트

Tusk Drift는 엔드포인트로 들어온 실제 트래픽을 기록해 API 테스트로 바꿨다. 목을 직접 쓰는 대신 서비스가 실제로 받은 요청에서 테스트가 나왔다. 응답이 조용히 바뀌면 호출하는 쪽이 깨지고, 항의가 들어올 때까지 모르는 상황에서 특히 쓸모가 있었다.

CoverBot이 정해진 주기로 커버리지 채우기

CoverBot은 Dependabot과 비슷하게 움직였다. 다른 점은 열어 주는 풀 리퀘스트에 의존성 업데이트가 아니라 단위 테스트가 들어 있다는 것이다. 저장소를 지정하고 매일이나 매주를 고른 뒤 맡겨 두면 됐다. Tusk는 한 달에 커버리지가 30% 올랐다고 했지만 자체 수치이므로 보장이 아니라 방향으로 읽어야 한다.

스스로 따라가는 테스트 스위트

비즈니스 로직이 움직이면 테스트는 낡는다. Tusk는 커밋마다 실패한 스위트를 갱신해 현재 동작에 맞췄다. 편리함과 위험이 동시에 있는데, 통과하려고 스스로를 고쳐 쓰는 테스트는 진짜 버그까지 덮어쓸 수 있다.

Jira와 Linear, 기존 테스트의 맥락 활용

Tusk는 Jira와 Linear 티켓에서 업무 맥락을, 팀이 이미 쓴 테스트에서 코드 패턴을 가져왔다. 생성된 테스트는 새 스타일을 발명하지 않고 팀의 이름 규칙과 fixture 관습을 따랐다. 범용 생성 도구를 써 본 사람들이 가장 먼저 꼽는 차이가 이 지점이다.

코드 리뷰와 버그 수정

처음의 에이전트는 완전히 사라지지 않았다. Tusk는 풀 리퀘스트를 계속 읽었고 신고된 버그에서 수정까지 추적할 수 있었다. 리뷰에도 테스트와 같은 단서가 붙는다. 생성된 것은 병합 전에 사람이 읽어야 한다.

장단점

장점

  • 테스트가 이미 실행된 상태로 도착해 AI 코파일럿에서 흔한 주고받기가 줄었다.
  • 단위 테스트 생성이 CI에 붙어 있어 별도 스프린트 없이 커버리지가 올라갔다.
  • GitHub, Jira, Linear 연동 덕분에 맥락이 팀이 이미 쓰는 도구 안에 남았다.
  • 활성 개발자 단위 요금에 최소 좌석 조건이 없어 저장소 하나로 시험하기가 쌌다.

단점

  • 제품이 없어졌다. 저장소에서는 GitHub App이 빠졌고, Drift 사용자는 서비스에서 SDK 코드를 걷어내야 했다.
  • 벤치마크가 자체 발표라, 다른 에이전트가 놓친 경계 조건을 잡았다는 주장은 외부에서 확인된 적이 없다.
  • 최상의 결과는 기존 스위트와 단일 플랫폼을 전제로 했다. GitHub 밖이거나 테스트가 아예 없는 팀이 얻는 효과는 훨씬 작았다.
  • AI 리뷰에는 사람의 확인이 필요하고, 테스트 통과가 코드가 옳다는 증거는 아니다.

자주 묻는 질문

풀 리퀘스트용 단위 테스트와 API 테스트를 생성하고, 코드를 리뷰하고, 고객이 신고한 버그를 고쳤다. 팀들은 코드 커버리지를 올리고 배포 전 회귀를 잡는 용도로 썼다.