Product Hunt

Tiden — Intent verification for coding agents

Tiden, 코딩 에이전트의 의도 검증

Tiden은 코딩 에이전트가 만든 변경 사항을 코드 작성 세션의 테스트가 아니라 버전 관리되는 요구사항과 대조하는 도구입니다. 개발 환경에서 테스트를 실행하고 결과를 병합 게이트와 연결하며, 운영 오류를 릴리스와 변경 사항, 프롬프트까지 추적한다고 설명합니다.

에디터 노트

Tiden의 설득력은 테스트 통과를 곧 요구사항 충족으로 간주하지 않고, 변경 전 기록한 사양과 연결하려는 데 있습니다. 팀 엔지니어가 요구사항과 맞지 않는 변경을 검사 항목이 없다는 이유로 통과시킨 버그를 공개하고, 이를 거부하도록 바꿨다는 설명은 게이트 설계에서 실제로 생길 수 있는 빈틈을 짚습니다. 다만 사양을 기록하고 테스트를 요구사항에 연결하는 절차가 정확한 판정을 보장하는 것은 아닙니다. 제품 측도 요청이 올바른지는 사람이 판단해야 한다고 밝힙니다. 컨텍스트 그래프가 빠진 영향 범위를 보완한다는 댓글 답변은 회사 측 주장이고, 제공된 설명에는 그 판정 기준이나 검증 결과가 없습니다. 자동화 범위는 사양과 테스트가 갖춰진 정도에 좌우됩니다.

AI 요약

Tiden은 Claude Code, Cursor, Codex, Copilot과 함께 쓰는 코딩 에이전트 검증 도구입니다. 제품 설명에 따르면 에이전트가 코드를 작성하고 같은 세션에서 테스트와 문서까지 만드는 과정에서는 산출물이 서로 일치해도 실제 요구사항을 놓칠 수 있습니다. Tiden은 요구사항을 코드처럼 버전 관리하고 변경 사항마다 이를 기준으로 검사합니다. 판정은 diff를 평가하는 모델이 아니라 사용자의 환경에서 실행한 테스트 결과로 내립니다.

세션에서 병합까지

세션 훅(session hook)이 첫 수정 전에 사용자의 요청을 기록합니다. 변경 사항은 검토할 요구사항으로 정리되며, 요구사항은 코드처럼 브랜치와 병합을 거칩니다. Tiden은 변경 사항과 관련된 테스트를 골라 사용자 환경에서 실행하고, 실패하면 에이전트가 수정하도록 합니다. 게이트는 사양에 연결되며 실패 결과는 수정할 항목을 에이전트에 알립니다. 통과 결과에는 근거가 붙고, 병합 여부는 사용자가 결정합니다. 자동으로 해결하지 못하는 사안에는 사람이 승인하도록 임계값과 게이트를 설정할 수 있다고 설명합니다.

운영 단계에서는 오류를 릴리스와 변경 사항, 그 뒤에 있던 프롬프트로 추적하고 누락된 테스트와 수정 사항을 연결한다고 합니다. 여러 에이전트가 공통으로 읽는 사양을 하나의 버전 관리 기록으로 유지해 저장소에 Markdown 규칙 파일을 계속 쌓는 방식과 구분합니다. 다만 Tiden도 요청 자체가 올바른지 판단하지는 않습니다. 무엇을 만들지 정하는 일은 사람의 판단으로 남는다고 제품 측은 선을 긋습니다.

출시 배경과 적용

창업자는 팀에서 에이전트가 코드 대부분을 만들기 시작했지만 검토, 테스트, 릴리스, 요구사항 관리가 같은 속도로 빨라지지 않았다고 설명합니다. 대화한 게임 퍼블리셔에서는 개발자 1,000명 이상인 조직의 PR 수가 4~5배 늘었지만 출시 기능 수는 그대로였고, 한 결제 회사에서는 코딩 산출량이 10배가 됐는데 전달량은 10% 늘었다고 들었다고 밝혔습니다. 이 수치는 창업자가 전한 사례이며 제품 설명에 포함된 자체 조사 결과입니다.

Product Hunt 반응

  • @kshitij_mishra4 — AI 코딩의 진짜 과제는 코드를 더 빨리 쓰는 게 아니라 의도한 대로 작동하는지 확인하는 일입니다.
    • @nipisarev — 저도 이 문제를 여러 번 겪었습니다. 코드가 빨리 작성될수록 신뢰는 낮아졌습니다. 원래 요청을 모두 반영했는지, 다른 부분을 망가뜨리지 않았는지 확인하느라 몇 시간씩 썼습니다. Tiden은 처음부터 영향 범위를 파악해 영향을 받을 수 있는 부분의 기존 테스트를 실행하도록 에이전트에 알립니다. 새 테스트는 생성된 코드가 아니라 고객의 원래 요구사항을 바탕으로 작성하게 합니다.
  • @anastasia_nikonorova — 테스트 없이도 쓸 수 있나요? 여러 저장소에서 함께 쓸 사양만 보관하고 싶습니다.
    • @and_vaganov — 가능합니다. 온보딩 과정에서 Tiden에 사양을 만든 뒤 에이전트 세션을 시작하면 됩니다. 테스트가 없어도 시작을 막지 않으며 나중에 추가할 수 있습니다. 장기적으로는 요구사항에 테스트 커버리지를 갖추는 편이 좋습니다.
  • @nipisarev — Tiden 팀 엔지니어입니다. 제가 만든 게이트에서 가장 기억에 남는 버그는 쉽게 통과한다는 공통점이 있었습니다. 알려진 요구사항과 맞지 않는 변경은 검사할 것이 없다는 이유로 통과했고, 다른 사람의 성공 결과로 요구사항이 검증되기도 했습니다. 이제 전자는 거부하고 위험을 감수할지는 명시적으로 결정하게 했습니다. 후자는 해당 변경에서 직접 실행한 결과만 인정합니다. 검증기는 속이기 어려운 만큼만 가치가 있습니다.
  • @daniel_henry4 — 코드가 모든 테스트를 통과해도 사용자의 요청과 다르게 만들어진 경우를 잡을 수 있나요?
    • @nitidesh — Tiden의 차별점이라고 답했습니다. 에이전트가 한 줄도 작성하기 전에 기록한 원래 의도를 사양으로 삼아 검사합니다. 제품 기능 간 관계와 의존성을 유지하는 컨텍스트 그래프를 바탕으로 사용자가 정의하지 않은 영향도 보완한다고 설명했습니다.
  • @maklyen_may — 이미 Cursor나 Claude Code를 쓰는 프로젝트에 Tiden을 추가하기 쉽나요?
    • @nitidesh — 제품과 저장소를 등록하고 CLI를 설치해 설정하면 됩니다. 반나절 안에 설정을 마치고 코딩 에이전트와 백그라운드에서 함께 작동한다고 답했습니다.

원문: Product Hunt / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗