BACK TO RESUME

Will Done

GITHUB

2026.02 - 2026.03

1인 개발 (기여도 100%)

권고 사직 후 "내가 무엇을 했는가"를 정리하지 못한 경험에서 출발한, AI 에이전트 오케스트레이션만으로 완성한 풀스택 데스크톱 타임 트래커

React 19Tauri v2RustSQLiteGemini APIVite 7

Technical Insights & Record

1. Why this project? (Motivation)

갑작스러운 권고 사직을 경험하면서 '내가 이 회사에서 뭘 했지?'를 제대로 정리하지 못한 채 퇴사했습니다. 이직이나 연봉 협상 시점에 자신의 성과를 복기하지 못하는 건 저만의 문제가 아닐 거라고 생각했습니다. 시중의 투두를 써봤지만 두 가지가 불편했습니다.
  • 긴급 업무가 생기면 타임라인을 손으로 다시 맞춰야 함
  • 기록은 쌓여도 무엇을 했는지 요약된 성과 문서로 연결되지 않음
둘 다 해결하는 도구가 없어서 직접 만들었습니다. 동시에 하나의 실험이기도 했습니다. 코드를 한 줄도 작성하지 않고 AI 에이전트만으로 풀스택 데스크톱 앱을 완성할 수 있는가, 그 가설을 직접 검증해보고 싶었습니다.

2. Architecture & Vibe Coding Strategy

Tauri v2 + Rust를 선택한 기준은 하나였습니다. AI 에이전트가 잘못된 코드를 작성했을 때 런타임이 아닌 컴파일 단계에서 차단할 수 있는가. Rust의 강타입 시스템이 그 역할을 해줬고, 덕분에 에이전트가 생성한 코드를 일일이 검증하는 부담이 줄었습니다.
이 프로젝트에서 제가 직접 작성한 코드는 없습니다. 대신 세 가지 제약으로 AI가 안정적으로 작동하는 환경을 만들었습니다.
  • SSOT(Single Soruce of Truth): STRUCTURE.md를 단일 진실 공급원으로 운영, 에이전트가 항상 동일한 프로젝트 상태를 인식하도록 강제
  • Atomic Loop: PLANNING.md 기반으로 한 번에 하나의 작업만 수행하도록 제약해 복잡도로 인한 실패를 차단
  • Verification Gate: 빌드 혹은 테스트가 실패한 상태에서는 다음 작업으로 절대 넘어가지 않도록 함
Application Preview & System ArchitectureClick to Enlarge
Will Done App Main Interface

3. Problems & Technical Solutions

Problem 01: Schedule Resilience

동적인 업무 환경에서의 스케줄링 붕괴

처음에는 긴급 업무가 추가되면 진행 중이던 태스크를 종료하고, 긴급 업무를 현재 시간에 배치한 뒤, 남은 시간만큼 새 태스크를 다시 자동으로 생성해주는 방식으로 구현했습니다. 하지만 직접 사용해보면서 기존에 진행하던 업무가 종료된 것과 진행할 업무로 분리되어 표시되다 보니, 자동으로 추가된 태스크가 잘못 추가한 건지 헷갈리기 시작했습니다.

Solution: Recursive Scheduling Engine

단순히 기존 태스크를 종료하고 추가하는게 아니라 태스크를 쪼개는 방식이 필요하다고 판단했습니다. 긴급 업무가 삽입되면 진행 중이던 태스크는 분리되고, 두 태스크는 time_block 테이블에서 task 테이블의 키를 참조하는 방식으로 연결 관계를 유지했습니다. 분리된 태스크는 모두 PENDING 상태로 표시해 긴급 태스크로 인해 멈춘 상태임을 명확하게 보여줬습니다.
Problem 02: The Harness Problem

AI 에이전트의 자율성에 따른 코드 오염

초기에 가장 많이 실패한 지점이었습니다. AI에게 연관된 수정 사항을 3개 정도 한 번에 전달하면, 그 중 하나를 빼먹거나 원하지 않는 결과를 만들거나, 완료했다고는 했지만 빌드가 깨지는 일이 반복됐습니다. GEMINI.md에 단계별 규칙을 작성했지만, 이마저도 여러 작업을 한꺼번에 처리하면서 중간에 길을 잃거나 제대로 동작하지 않는 기능을 커밋하는 문제가 또 생겼습니다.

Solution: Strict Harness Protocol

oh-my-opencode를 쓰다 Rate Limit이 자주 걸리면서 협업 기능을 Gemini CLI에 직접 붙일 수 없을까 생각했습니다. 당시 공식 지원이 없어서 oh-my-opencode의 결과물을 기반으로 /init, /plan, /work, /git 커스텀 커맨드를 직접 만들어 Gemini CLI에 붙였습니다. 이를 통해 한 번에 한 가지 작업만 처리하고, 계획 문서를 기반으로 AI가 먼저 검증한 뒤 진행하며, 세션이 끊겨도 이어서 작업할 수 있는 구조가 만들어졌습니다. 이 과정이 Harness Protocol의 기반이 됐습니다.

4. Project Highlights & Results

Development Metrics

개발 기간

1주일

(기획 → 설계 → 배포)

빌드 성공률

100%

Total Commits

259+

5. Lessons Learned

단순히 필요에 의해 만든 앱을 넘어, 처음 써보는 언어를 통해 AI 에이전트만으로 풀스택 데스크톱 앱을 완성할 수 있다는 가설을 증명할 수 있었습니다. 이 과정에서 가장 크게 느낀 것은, AI를 쓸수록 기획과 설계에 더 많은 시간을 써야 한다는 것입니다. 코드는 AI가 쓰더라도 무엇을 만들지, 어떤 구조로 만들지는 사람이 먼저 구체적으로 정해야합니다. 지시가 모호하면 결과도 모호했고, 계획이 구체적일수록 실패가 줄었습니다. 결국 '무엇을 AI에게 맡기고 무엇을 직접 판단할 것인가'를 설계하는 능력이 앞으로 더 중요해질 것 같다고 생각했습니다.