Molayo

© 2026 Molayo

Dev.to헤드라인2026. 06. 05. 21:58

AI에게 무엇을 위임할지 고민하는 것을 멈추세요

요약

AI 에이전트와 인간 사이의 작업 위임 문제를 해결하기 위한 오픈 소스 작업 큐 시스템인 'Personal Task Assistant'를 소개합니다. 이 도구는 작업의 상태와 소유자를 명확히 구분하여 AI가 즉시 실행 가능한 작업을 식별하고 관리할 수 있도록 돕습니다.

핵심 포인트

  • AI 위임 결정 과정의 병목 현상 해결
  • 인간과 AI 에이전트 간의 협업을 위한 운영 큐 구축
  • 작업 상태(Status)와 소유자(Owner)를 분리하여 관리
  • 기존 협업 도구와 연동 가능한 JSON API 및 어댑터 구조

저는 인간의 작업, AI 준비 완료 작업, 차단된 작업, 그리고 검토 준비 완료된 결과물을 분리하는 오픈 소스 작업 큐(task queue)를 구축했습니다.

문제점

대부분의 AI 도구들은 여전히 인간이 무엇을 요청해야 할지 정확히 알고 있다고 가정합니다.

코딩 에이전트(coding agents), 편지함 자동화(inbox automation), Slack 요약, 회의록, 그리고 개인 작업 캡처(personal task capture)를 매일 사용하기 전까지는 이 말이 합리적으로 들릴 것입니다. 병목 현상(bottleneck)이 항상 실행 단계에서 발생하는 것은 아닙니다. 종종 병목 현상은 애초에 무엇을 AI에게 위임해야 할지 결정하는 과정에서 발생합니다.

저는 계속해서 동일한 운영상의 질문에 부딪혔습니다:

이 작업들 중 어떤 것을 내가 해야 하고, 어떤 것을 AI 에이전트가 여기서부터 이어받을 수 있을까?

그 질문은 놀라울 정도로 비용이 많이 듭니다.

맥락(context)을 읽고, 다음 행동을 식별하며, 자격 증명(credential)이나 결정 사항이 누락되었는지 확인하고, 결과물이 검토가 필요한지 결정한 후에야 비로소 작업을 사람이나 에이전트에게 할당할 수 있기 때문입니다.

그래서 저는 Personal Task Assistant를 만들었습니다.

핵심 아이디어는 간단합니다:

AI에게 무엇을 위임할지 고민하는 것을 멈추세요. 작업 시스템이 AI 준비 완료된 작업을 드러내도록 하세요.

그것은 무엇인가

Personal Task Assistant는 사람과 AI 에이전트 간의 협업을 위한 오픈 소스 인터페이스입니다.

이 도구는 작업을 명확한 소유권이 있는 운영 큐(operational queue)로 변환합니다:

  • 인간을 위한 작업;
  • AI 에이전트가 실행할 수 있는 작업;
  • 인간의 검토를 기다리는 작업;
  • 차단된 작업(blocked tasks);
  • 여전히 분류(triage)가 필요한 미할당 작업.

이것은 Jira, Linear, Asana, YouTrack, Trello, Slack, Telegram 또는 이메일을 대체하려는 것이 아닙니다.

대신, 작은 작업 모델과 JSON API를 노출하여 사용자가 소유한 어댑터(adapters)가 해당 시스템으로부터 작업을 가져올 수 있도록 합니다.

왜 다른 모델이 필요한가

일반적인 작업 추적기(task tracker)는 다음과 같이 답합니다:

무엇을 해야 하는가?

AI 지원 워크플로(AI-assisted workflow)에는 또 다른 질문이 필요합니다:

다음 단계는 누가 수행해야 하는가?

이 두 번째 질문이 제품의 형태를 바꿉니다.

어떤 작업은 기술적으로는 간단하지만 결정(decision)이 내려지지 않아 차단(blocked)되어 있을 수 있습니다. 또 다른 작업은 복잡하지만 에이전트(agent)가 수행할 준비가 완전히 되어 있을 수 있습니다. 세 번째 작업은 에이전트에 의해 이미 완료되었을 수도 있지만, 사람이 결과물을 검토하기 전까지는 완료(done)로 표시되어서는 안 됩니다.

이것이 바로 Personal Task Assistant가 상태(status)와 다음 작업 소유자(next-action owner)를 모두 추적하는 이유입니다.

상태 (Statuses):

  • backlog (백로그)
  • in_progress (진행 중)
  • waiting_review (검토 대기 중)
  • blocked (차단됨)
  • done (완료됨)
  • cancelled (취소됨)

소유자 (Owners):

  • me (나)
  • codex (codex)
  • unassigned (미할당)

가치는 라벨 그 자체에 있는 것이 아닙니다. 가치는 필터링된 큐(queue)에 있습니다:

  • 내가 무엇을 해야 하는가?
  • 에이전트가 무엇을 할 수 있는가?
  • 검토할 준비가 된 것은 무엇인가?
  • 차단된 것은 무엇인가?
  • 기한이 지난 것은 무엇인가?

에이전트 큐 (The Agent Queue)

중요한 엔드포인트(endpoint)는 다음과 같습니다:

curl "$TASK_TRACKER_URL/api/agent/queue?assignee=codex&sort=smart&limit=25" \
  -H "Authorization: Bearer $TASK_TRACKER_API_KEY"

응답 예시:

{
  "summary": {
    "active": 42,
...

이는 에이전트가 UI를 스크래핑(scrape)하거나 모든 작업을 읽을 필요가 없음을 의미합니다. 에이전트는 실행 큐(execution queue)를 요청할 수 있습니다.

컨텍스트로부터 작업 수집 (Ingesting Work From Context)

에이전트나 어댑터(adapter)는 컨텍스트 수집(context-ingest) 엔드포인트를 통해 추출된 작업을 보낼 수 있습니다:

curl -X POST "$TASK_TRACKER_URL/api/agent/ingest/context" \
  -H "Authorization: Bearer $TASK_TRACKER_API_KEY" \
  -H "Content-Type: application/json" \
...

동일한 패턴이 Slack, Telegram, Linear, Jira, Asana, YouTrack, Trello, 회의록 또는 기타 모든 소스에 적용됩니다.

이 프로젝트는 의도적으로 내장된 자격 증명(credentials)이나 범용 소스 클라이언트(universal source clients)를 포함하지 않습니다. 더 안전한 패턴은 어댑터를 작게 유지하고 사용자가 직접 소유하도록 하는 것입니다.

로컬 설정 (Local Setup)

가장 빠른 설정 경로는 다음과 같습니다:

git clone https://github.com/J3d1-fm/Personal-Task-Assistant
cd Personal-Task-Assistant
python3 scripts/setup_wizard.py

수동 설정:

python3 -m venv .venv
. .venv/bin/activate
pip install -r requirements.txt
...

그 다음 다음을 엽니다:

로컬 설정은 SQLite를 사용합니다. 의도된 호스팅 형태는 Cloud Run과 Firestore를 결합한 형태이며, 비밀 정보(secrets)는 저장소 외부에 저장됩니다.

아키텍처 (Architecture)

현재 MVP(Minimum Viable Product)는 의도적으로 작게 설계되었습니다:

  • FastAPI가 웹 UI와 JSON API를 제공합니다.
  • SQLite가 작업을 로컬에 저장합니다.
  • Google Cloud 배포를 위해 Firestore를 지원합니다.
  • Google OAuth로 브라우저 UI를 보호할 수 있습니다.
  • Bearer-token 인증이 API 클라이언트를 보호합니다.
  • 리마인더 폴링(Reminder polling)이 /api/reminders/due를 쿼리할 수 있습니다.
  • 에이전트 클라이언트가 /api/agent/queue를 읽을 수 있습니다.

데이터 모델은 간결하게 유지됩니다:

  • 제목(title) 및 설명(description);
  • 상태(status);
  • 담당자(assignee);
  • 출처(origin);
  • 우선순위(priority);
  • 마감일(due date);
  • 리마인더 날짜(reminder date);
  • 소스 이름(source name), 소스 URL(source URL), 소스 컨텍스트(source context).

작업에 마감일이 포함되지 않은 경우, 서버는 우선순위에 따라 마감일을 추정합니다:

  • P1: 약 1일;
  • P2: 약 3일;
  • P3: 약 7일;
  • P4: 약 14일;
  • P5: 약 30일.

이는 실제 마감일을 대체하기 위한 것이 아닙니다. 날짜 없이 중요하게 캡처된 작업들이 조용히 방치되는 것을 방지하기 위한 목적입니다.

피드백을 받고 싶은 부분

현재 가장 유용한 피드백은 다음과 같습니다:

  • 인간/에이전트 소유권(ownership) 모델이 명확한가요?
  • 에이전트가 완료한 작업의 기본 상태로 waiting_review가 적절한가요?
  • 첫 번째 실제 어댑터(adapters)는 무엇이 되어야 할까요: Slack, Telegram, Gmail, Linear, Jira, Asana, YouTrack, 또는 Trello?
  • 에이전트 큐(agent queue)가 더 많은 순위(ranking) 정보를 노출해야 할까요?
  • 로컬 설정을 더 쉽게 만들려면 무엇이 필요할까요?

이 계층이 중요하다고 생각하는 이유

AI 에이전트들은 실행(execution) 능력이 점점 좋아지고 있습니다.

하지만 실행은 워크플로(workflow)의 한 부분일 뿐입니다. 매일 마주하는 더 어려운 문제는 작업을 올바르게 라우팅(routing)하는 것입니다:

  • 이것을 위임하기(delegate this);
  • 이것을 직접 하기(do this yourself);
  • 이것을 검토하기(review this);
  • 이것을 해결하기(unblock this);
  • 이것을 무시하기(ignore this).

그렇기 때문에 에이전트 주변의 다음 유용한 계층은 또 다른 채팅창이 아니라, 위임 계층(delegation layer)이라고 생각합니다.

Personal Task Assistant는 그 계층을 구현하기 위한 저의 첫 번째 오픈 소스 시도입니다.

저장소(Repository):
[https://github.com/J3d1-fm/Personal-Task-Assistant]

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0