Signal Desk는 관련 대화를 찾아내고, 이를 리드(leads)로 순위를 매기며, 검토 가능한 인박스 카드(inbox cards)를 작성하고, 아웃리치(outreach) 답장 초안 작성을 돕습니다. 저는 Aura의 단계별 워크플로(phased workflow), 가시적인 차이점(visible diffs), 검증(validation), 그리고 저렴한 모델들을 사용하여 약 10센트의 비용으로 이를 구축했습니다.

Aura를 개발하면서, 저는 가능한 한 자주 Aura를 사용하여 실제 프로젝트를 그린필드(greenfield, 신규 개발) 방식으로 시도해 보려고 노력합니다.

단순한 장난감 프롬프트나 "할 일 목록 앱 만들기" 같은 것이 아닙니다. 실제로 유용하고, 약간은 복잡하며, 제가 실생활에서 하는 업무와 유사한 프로젝트를 의미합니다.

대부분의 경우, 저는 동일한 프로젝트를 두 번 실행합니다. 한 번은 Aura의 주요 변경 사항이 적용되기 전이고, 다른 한 번은 적용된 후입니다. 이는 실질적인 A/B 테스트가 됩니다:

• Aura가 더 빨라졌는가?
• 출력 결과가 더 깔끔해졌는가?
• 프로젝트의 형태(shape)가 개선되었는가?
• 도구와 씨름하는 일이 줄어들었는가?

이것이 제가 관심을 두는 테스트입니다. 왜냐하면 실제 코드베이스는 다듬어진 데모처럼 동작하지 않기 때문입니다. 코드베이스는 단계적으로 진화합니다. 요구사항은 변합니다. 어떤 부분은 명확하지만 어떤 부분은 모호하며, 도구는 이 모든 과정 속에서 유용함을 유지해야 합니다.

이번 릴리스를 위한 도그푸딩(dogfood, 자사 제품 직접 사용) 프로젝트는 로컬 리드 발굴 및 아웃리치 도구인 Signal Desk였습니다.

Signal Desk의 기능

Signal Desk는 RSS 및 Hacker News와 같은 소스를 스캔하여 관련 게시물을 후보(candidates)로 변환하고, 이를 잠재적 리드로 점수화하며, 검토 가능한 인박스 카드를 작성하고, 답장 초안 작성을 돕습니다.

제품 루프(product loop)는 다음과 같습니다:

소스(sources) → 후보(candidates) → 중복 제거(dedupe) → 점수화(scoring) → 발견 사항(findings) → 인박스 카드(inbox cards) → 표시 / 무시 / 답장(show / ignore / reply)

이것이 제가 Aura를 테스트하기 위해 선호하는 워크플로 유형입니다. 빠르게 구축할 수 있을 만큼 작으면서도, 생성된 코드가 실제 제품의 형태를 갖추었는지 드러낼 수 있을 만큼 실질적입니다.

설정

이번 실행을 위해, 저는 계획(planning)과 구현(implementation) 모두에 저렴한 모델을 사용했습니다.

DeepSeek V4 Flash에서 Planner와 Worker를 실행 중인 Aura. 전체 도그푸딩 빌드에 소요된 모델 사용 비용은 약 10센트였습니다.

그 비용도 중요하지만, 핵심은 단순히 "저렴한 토큰"만이 아닙니다.

핵심은 저렴한 모델들이 충분히 성능이 좋아지고 있으며, 그 모델들을 둘러싼 하네스 (Harness)가 점점 더 중요해지고 있다는 점입니다. Aura가 작업을 집중시키고, 가시화하며, 검증할 수 있다면, 저비용 모델들은 사람들이 예상하는 것보다 훨씬 더 멀리 나아갈 수 있습니다.

모델은 연료입니다.

Aura는 그 연료를 통제된 작업으로 전환하는 하네스 (Harness)입니다.

대규모 프로젝트를 위한 나의 Aura 워크플로우

대규모 프로젝트의 경우, 저는 보통 Aura에게 하나의 거대한 프롬프트로 전체를 구축해 달라고 요청하지 않습니다.

저의 워크플로우는 다음과 같습니다:

1. 실제 사양 (Spec)을 작성합니다.
2. Aura에게 이를 단계 (Phases)별로 나누도록 요청합니다.
3. 한 번에 하나의 단계씩 할당 (Dispatch)합니다.
4. Aura가 해당 슬라이스 (Slice)를 실행하도록 합니다.
5. 출력물, 검증 (Validation), 파일 및 커밋 (Commits)을 검사합니다.
6. 다음 단계로 넘어갑니다.

이렇게 하면 모델이 집중력을 유지할 수 있고, 제가 통제권을 유지할 수 있습니다.

마지막에 거대하고 정체 모를 덩어리를 검토하는 대신, 각 슬라이스가 생성될 때마다 즉시 검사할 수 있습니다.

단계별 계획

Signal Desk는 다음과 같이 단계별로 나뉘었습니다:

• 1단계: 프로젝트 스켈레톤 (Skeleton) 및 초기화 명령

• 2단계: 데이터 모델 (Data models) 및 저장소

• 3단계: 소스 어댑터 (Source adapters)

• 4단계: 스코어링 (Scoring) 및 랭킹 (Ranking)

• 5단계: 답장 초안 작성 (Reply drafting)

• 6단계: 받은 편지함 (Inbox) 및 나머지 CLI 명령

• 7단계: 테스트 및 다듬기 (Polish)

Aura는 실제 사양 (Spec)에서 시작하여, 이를 구체적인 파일과 검증 대상이 포함된 집중된 단계로 전환합니다.

이러한 단계적 구조가 중요합니다. Aura에게 단순히 "앱을 만들어줘"라고 요청하는 것이 아닙니다. 각 할당 (Dispatch)에는 집중된 작업이 부여됩니다.

흐름(Flow)이 곧 기능이다

Aura를 사용할 때 제가 가장 좋아하는 부분은 흐름 (Flow)입니다.

Aura가 잘 작동할 때는 매끄럽고 빠르게 느껴집니다. Planner가 슬라이스 (Slice)의 형태를 잡고, Worker가 파일들을 처리하며, 검증 (Validation)이 실행되고, 프로젝트 트리가 변하며, 출력물이 실제 결과물로 변하기 시작합니다.

그것이 바로 제가 추구하는 느낌입니다. 마치 레슬링을 하는 것처럼 힘들지 않은 AI 코딩 말이죠. 작업이 딱딱 들어맞는 것을 지켜보는 듯한 느낌입니다.

성공적인 실행은 다음과 같은 모습을 띱니다:

spec → phase → files → validation → next phase

혼돈도 아니고, 맹목적인 신뢰도 아니며, "에이전트(Agent)가 제대로 했기를 바라는" 상태도 아닙니다.

그저 통제된 빌드 루프 (Build loop)일 뿐입니다.

캡션: 수락 기준 (Acceptance criteria) 확인, 검증 (Validation) 실행, 그리고 다음 단계로의 깔끔한 인계와 함께 페이즈 1 (Phase 1)이 완료되었습니다.

Aura가 구축한 것

마지막에 Signal Desk는 다음과 같은 것들을 갖추게 되었습니다:

• 설치 가능한 Python 패키지
• signal-desk init 명령
• 로컬 설정 (Local config) 및 워크스페이스 (Workspace) 설정
• SQLite 저장소
• RSS 및 Hacker News 소스
• 후보 중복 제거 (Candidate deduplication)
• 결정론적 점수 산정 (Deterministic scoring)
• 마크다운 (Markdown) 인박스 카드
• 답장 초안 작성 (Reply drafting)
• scan, watch, inbox, show, ignore, reply 명령어
• 109개의 테스트 통과

캡션: 마지막에 Signal Desk는 완전한 프로젝트 구조를 갖추었으며 109개의 테스트를 통과했습니다.

최종 사용자 루프 (User loop)는 다음과 같았습니다:

scan sources → rank leads → review inbox → inspect details → ignore or draft a reply

이것이 생성된 파일들과 실제로 사용 가능한 제품 조각 (Product slice) 사이의 차이점입니다.

예시: 주요 제품 루프 (Main Product Loop)

이것이 바로 제가 Aura로부터 기대하는 종류의 결과물입니다.

scan 명령어는 단순한 자리 채우기용이 아닙니다. 실제 제품 흐름을 따릅니다.

def _run_scan(config_dict: dict) -> dict:
    started_at = datetime.utcnow()

...

여기서 제가 마음에 드는 점은 그 형태입니다:

config → sources → candidates → dedupe → scoring → inbox → scan record

이것이 진정한 제품 루프 (product loop)입니다. 코드는 인상적으로 보이려고 애쓰지 않습니다. 대신 유용해지려고 노력합니다.

예시: 도메인 중심의 상태 (Domain-Shaped State)

Signal Desk는 단순한 도메인 (domain)을 가지고 있습니다:

• sources가 candidates를 생성합니다.
• candidates가 findings가 됩니다.
• findings가 inbox로 들어갑니다.
• scan이 발생한 일을 기록합니다.

@dataclass
class Candidate:
    id: str
...

이것은 올바른 의미에서 지루한 코드입니다.

이름이 제품과 일치합니다. 상태 (state)가 명시적입니다. 프로젝트의 나머지 부분은 이 구조를 중심으로 깔끔하게 구축할 수 있습니다.

이것이 바로 제가 AI에게 원하는 종류의 코드입니다. 일반적인 DataManager 식의 모호한 코드 (soup)가 아니라, 구축 중인 대상에 속하는 단순한 개념들 말입니다.

예시: 스스로 설명하는 스코어링 (Scoring That Explains Itself)

리드 발굴 (lead discovery) 도구의 경우, 스코어링 (scoring)은 검사 가능해야 합니다. 저는 단순히 숫자만 원하는 것이 아닙니다. 어떤 것이 왜 inbox에 들어왔는지 알고 싶습니다.

def score_candidate(candidate: Candidate, config: dict) -> dict:
    aura_cfg = config.get("aura", {})

...

이것이 바로 이런 종류의 도구에 제가 원하는 방식입니다.

스코어링은 결정론적 (deterministic)입니다. 이유는 가시적입니다. 사용자는 응답 여부를 결정하기 전에 왜 무언가가 매칭되었는지 검사할 수 있습니다.

예시: 검토 가능한 인박스 카드 (Reviewable Inbox Cards)

Signal Desk는 단순히 데이터베이스에 행 (rows)을 쏟아붓지 않습니다. 직접 검토할 수 있는 마크다운 (markdown) 카드를 작성합니다.

def format_finding_card(finding: Finding, include_draft: bool = True) -> str:
    priority_emoji = {
        "high": "🟢",
...

이것이 바로 제품 중심의 사고 (product thinking)입니다.

사용자의 업무는 "데이터베이스를 소유하는 것"이 아닙니다. 사용자의 업무는 유용한 대화를 검토하고 응답할지 결정하는 것입니다.

출력 결과는 그 업무를 지원합니다.

캡션: Signal Desk가 스캔된 대화로부터 순위가 매겨진 리드 카드들을 생성했습니다.

예시: 답장 초안 작성 (Reply Drafting)

Signal Desk는 또한 finding으로부터 답장 초안을 작성하는 것을 도와줍니다.

이 기능은 프로젝트를 직접적으로 언급하지 않고 응답하고 싶은 경우를 위해 다양한 스타일과 Aura 미사용 모드 (no-Aura mode)를 지원합니다.

def generate_reply(
    finding: Finding,
    style: str = "helpful",
...

다시 말하지만, 이는 워크플로 (workflow)로 다시 연결됩니다.

Signal Desk는 단순히 리드 (leads)를 찾는 것에 그치지 않습니다. 발견 (discovery)에서 아웃리치 (outreach)로 넘어가는 과정을 도와줍니다.

이것이 중요한 이유

이번 실행에서 제가 좋았던 점은 Aura가 많은 코드를 생성했다는 것이 아닙니다.

코드가 제가 계속해서 작업할 수 있는 형태 (shape)를 갖추고 있었다는 점입니다.

CLI는 사용자 흐름 (user flow)을 따랐습니다. 모델 (models)은 도메인 (domain)에 부합했습니다. 저장 계층 (storage layer)은 제품에 유용했습니다. 스코어링 (scoring)은 그 자체로 설명력을 가졌습니다. 인박스 (inbox) 출력물은 검토 가능했습니다. 답장 초안 작성 (reply drafting)은 발견 사항 (findings)과 다시 연결되었습니다.

이것이 제가 AI 코딩에서 원하는 것입니다:

• 파일 더미가 아닌 것
• 맹목적인 신뢰가 아닌 것
• 값비싼 블랙박스 (black box)가 아닌 것
• 영원히 돌봐줘야 하는 코드가 아닌 것

저는 제가 여전히 제어할 수 있는 유용한 조각 (useful slice)을 원합니다.

그것이 바로 Aura가 구축된 핵심입니다.

Aura가 나아가는 방향

Aura는 오픈 소스 (open-source) 데스크톱 AI 코딩 하네스 (harness)입니다.

목표는 간단합니다:

실제적인 것을 요청하라.
단계별로 나누어라.
제어권을 유지하라.
...

그것이 제가 매일 구축하고 싶은 워크플로 (workflow)입니다.

Aura는 GitHub에서 오픈 소스로 제공됩니다:

https://github.com/CarpseDeam/Aura-IDE