프로젝트로 돌아가기
폼 작성 → 의뢰 → AI 추가 질문 → 납품 → 승인

AI HACK 2026 · 공개 중

Relay

디자인 제작 의뢰를 접수부터 추가 확인, 납품, 승인까지 한곳에서 관리하는 AI 에이전트입니다.

도쿄 AI 해커톤 ‘AI HACK 2026’(주제: 업무를 자립화하는 AI 에이전트)에서 디자이너와 둘이 만든 제작 의뢰 관리 서비스입니다. 저는 개발 전체를 맡아, AI 출력을 원문 인용과 대조한 뒤에만 저장하는 Go 워커와 AI가 멈춰도 업무가 멈추지 않는 의뢰 흐름을 구현했습니다.

결과공개 서비스 · 공개 리포지토리 · 97커밋 · AI 출력 근거 검증

기간
2026.09
담당 범위
개발 전체 · Go API · River 워커 · AI 연동 · React
팀
2인 팀 (개발 1·기획/디자인 1)
저장소
공개 리포지토리

링크

Live siteGitHubZenn articleAI HACK 2026

제작 전후의 관리 업무를 AI에 맡기기

팀원인 디자이너는 여러 마케터에게 의뢰를 받을 때마다 목적·게재처·소재 확인, 우선순위, 진행 공유, 납품 연락을 혼자 떠안고 있었습니다. AI HACK 2026의 주제 ‘업무를 자립화하는 AI 에이전트’에 맞춰 이 관리 업무를 맡길 수 있는 서비스를 만들었습니다.

2025년 한일 미래세대 포럼에서 저는 ‘한일 협력을 구호로 끝내지 말고 청년이 해커톤과 공동 프로젝트에서 직접 경험해야 한다’고 발표했습니다. Relay는 그 제안을 제가 직접 실행한 프로젝트입니다. 일본 해커톤에 출전해 일본 제작 현장의 과제를 일본어 제품으로 만들었습니다. 수상하지는 못했지만 공개 가능한 형태까지 완성했습니다.

의뢰가 처리되는 흐름

검증을 통과한 AI 결과만 업무에 반영

  1. 01

    의뢰 폼

    React · 의뢰자·담당자 화면

  2. 02

    Go API

    인증·권한·의뢰 상태

  3. 03

    잡 저장

    PostgreSQL + River

  4. 04

    AI 호출

    OrcaRouter · 상한 설정

  5. 05

    근거 검증

    인용 대조·세대 비교

AI 요약은 원문에 인용이 있는 문장만 저장했습니다

의뢰 요약은 담당자가 원문을 다시 읽지 않고 판단하는 재료가 됩니다. AI가 원문에 없는 기한이나 조건을 쓰면, 요약이 오히려 잘못된 작업을 시작하게 만듭니다.

요약을 바꿔 쓰기가 아닌 추출로 만들었습니다. 각 항목에 근거 종류·ID·인용문을 붙이고, Go에서 인용이 실제 의뢰 본문·답변·댓글에 들어 있고 본문과 일치할 때만 저장합니다.

요약 검증 함수와 주간 리포트 검증 함수를 단위 테스트로 확인했습니다. 근거 없는 출력은 저장되지 않고, 기록으로 집계한 리포트로 돌아갑니다.

제약·구현·배운 점 보기

프롬프트로 ‘사실만 쓰라’고 지시해도 출력이 지킨다는 보장은 없습니다. 검증은 모델 밖, 서버 코드에서 해야 했습니다.

  • JSON 출력을 지정하고 질문은 최대 8개, 요약은 1~6개로 제한.
  • 인용 출처가 존재하고 공백을 정규화한 본문과 일치하는지 검증했습니다.
  • 미완료 의뢰에서는 납품 정보를 근거로 쓰지 못하게 제한.
  • 예상하지 못한 필드와 여분의 JSON 거부.

LLM 출력도 외부 API 입력처럼 믿기 전에 검증해야 하는 대상이라는 점을 배웠습니다.

의뢰자가 쓴 본문이 AI 요약의 근거가 됩니다

AI 처리 상태와 업무 상태를 분리했습니다

AI 분석이 끝나도 제작이 끝난 것은 아닙니다. 또 AI가 처리하는 동안 의뢰자가 내용을 바꾸거나 담당자가 작업을 진행할 수도 있습니다.

AI 처리를 PostgreSQL에 저장되는 River 잡으로 만들고 실행 시점의 세대를 기록했습니다. 결과를 반영하기 전에 세대를 비교해, 의뢰가 바뀌었으면 결과를 버리고 현재 상태를 유지합니다. 완료는 AI가 아닌 사람의 승인으로만 기록합니다.

PostgreSQL 통합 테스트로 제공자 호출 중 완료된 의뢰, 중복·오래된 잡, 수동으로 추가한 태스크 보존을 확인했습니다.

제약·구현·배운 점 보기

AI 응답은 수십 초가 걸릴 수 있고 브라우저를 닫아도 처리가 이어져야 했습니다. 반면 늦게 도착한 결과가 사람의 조작을 덮어써서는 안 됩니다.

  • 의뢰는 제출 시점에 접수하고 AI 분석은 백그라운드에서 실행했습니다.
  • 세대 비교로 오래된 결과를 버리고 analysis_stale 이벤트 기록했습니다.
  • AI가 완료로 바꾸는 것을 코드에서 거부.
  • 시도 횟수·출력 토큰·실행 시간에 상한 설정.

비동기 처리에서는 ‘언제 끝나는가’보다 ‘끝났을 때 그 결과가 아직 유효한가’를 먼저 생각해야 한다는 점을 배웠습니다.

완료는 사람의 승인으로 결정됩니다

AI를 쓸 수 없어도 의뢰와 납품은 멈추지 않게 했습니다

해커톤 주제는 업무 자립화였지만, API 키 미설정·이용 한도·모델 응답 오류는 실제 업무에서 반드시 일어납니다.

AI 출력은 모두 ‘제안’으로 다루고 실패 시 대안을 준비했습니다. 추가 질문은 일부만 답해도 진행되고, 납품 문안은 편집 가능한 기본 문안으로, 주간 요약은 기록 집계로 돌아갑니다.

키 암호화·마스킹, CSRF, 워크스페이스 분리를 테스트로 확인하고, 모킹한 OrcaRouter 응답을 포함한 통합 테스트와 Docker 빌드를 통과했습니다.

제약·구현·배운 점 보기

AI 실패를 그대로 화면 오류로 내보내면 의뢰자는 의뢰할 수 없고 담당자는 납품할 수 없습니다. AI가 돕는 경로와 사람이 끝까지 진행할 수 있는 경로를 둘 다 남겨야 했습니다.

  • 키 미설정 시 관리자에게 설정 링크, 의뢰자에게 확인 안내 표시.
  • API 키를 암호화 저장하고 조회 API와 AI 입력에서 제외.
  • AI 접속처를 고정해 입력 URL로 키를 보내지 않는 구성했습니다.
  • 워크스페이스와 역할 기반 권한을 서버에서 검증했습니다.

AI 에이전트의 신뢰성은 AI가 성공할 확률보다, 실패했을 때 사람이 다음 행동을 할 수 있는지로 결정된다는 점을 배웠습니다.

API 키는 암호화해 저장하고 조회 API에서 반환하지 않음

서비스와 GitHub 리포지토리를 공개하고 있습니다. 97개 커밋은 모두 제가 작성했고, Go 단위 테스트·PostgreSQL 통합 테스트·프론트엔드 빌드·Docker 빌드를 통과했습니다.

AI 기능을 만들 때는 먼저 ‘AI가 틀리면 무슨 일이 생기는가’, ‘AI가 멈추면 누가 무엇을 하는가’를 정한 뒤 프롬프트와 모델을 고르게 됐습니다.

아직 검증하지 않은 범위

수상하지는 못했습니다. 실제 OrcaRouter 모델에서의 질문 품질·비용·응답 시간, 메일 도달, 실무 시간 단축은 모킹한 테스트 외에는 아직 검증하지 않았습니다.

다음에 확인할 것

  • 실제 의뢰 예시로 누락된 정보와 불필요한 질문 수 측정
  • OrcaRouter로 모델별 일본어 자연스러움·JSON 안정성·응답 시간 비교
  • 실환경에서 메일 도달과 중복 방지 확인