코드 수정 없이 시간 추적기 만들기: Claude를 활용한 선언형 아키텍처 프로그래밍

저는 실험을 했습니다. 코드를 직접 작성하거나 편집하는 과정 없이 완벽한 제품을 만들어 보는 것이었습니다. 스크립트도, 프로토타입도 아닙니다. 백엔드, 데이터베이스, 휴대폰 레이아웃, 설치 가능한 PWA(Progressive Web App), Chrome 확장 프로그램, 랜딩 페이지를 갖춘 웹 앱입니다. 평소 직장 생활 후 며칠에 걸쳐 진행했습니다.

'시간 추적기조차도 감성적인 코딩이 필요하다'는 댓글이 올라오기 전에 먼저 말씀드리자면, 네, 알고 있습니다. 시간 추적기가 우주선은 아니죠. 저는 백엔드 개발자이며, 그 밑단(API, 데이터베이스, 모듈)의 모든 것은 어떤 모델의 도움 없이도 제가 직접 작성할 수 있었습니다. 기획하고 설계한 것은 저이고, 모델은 구현만 채워 넣었습니다. 핵심은 앱이 어렵다는 것이 아닙니다. 핵심은 코드를 한 번도 들여다보지 않고도 완벽하게 작동하는 제품을 만들 수 있다는 것입니다.

프론트엔드는 이야기가 다릅니다. 저는 프론트엔드 개발자가 아니기 때문에, 그 부분에서는 직관과 엔지니어링 이해 수준에서 작업했습니다. 즉, 어떻게 느껴져야 하는지, 어떻게 동작해야 하는지, 무엇이 어디에 배치되어야 하는지 말입니다. 이것은 코드보다 한 단계 높은 영역입니다. 그래서 제가 여러분께 던지고 싶은 질문은 이겁니다: 만약 앱이 이런 방식으로 만들어진다면, 여전히 '당신의 것'일까요? 빠르고 모델을 통해 잘 만들어진 좋은 앱과 느리고 작지만 손으로 직접 작성된 좋은 앱 중 어느 것을 선택하시겠습니까? 저에게는 답이 있지만, 여러분의 의견도 듣고 싶습니다.

결과는 Overdraft라는 개인 시간 추적기입니다. 아직 사용자는 없습니다. 방금 출시했고, 광고할 계획은 전혀 없었습니다. 저 자신과 아들을 위해 만들었습니다. 이 글은 그것이 어떻게 만들어졌는지, 그리고 제가 생각하기에 이것이 프로그래밍의 미래가 어디로 향하고 있는지에 대해 이야기합니다.

아이디어

저는 단순한 것을 원했습니다. 작업 시작 버튼을 누르고 나중에 실제로 시간이 어디에 쓰였는지 확인하는 것입니다. 타임시트도, 팀 도구도 아닙니다. 개인 시간을 비추는 거울이자, 어쩌면 '낭비'를 조절할 수 있는 방법이었습니다.

여기서 몇 가지 규칙이 나왔고, 이들은 모두 저의 것이었습니다:

• 한 번에 하나의 작업만 실행 가능합니다. 다른 작업을 시작하면 현재 작업은 자동으로 중지됩니다.
• 작업별 일일 한도 설정. 게임을 2시간 하는 것은 괜찮지만, 카운터가 초과되면 빨간색으로 변합니다.
• 네 가지 고정 목록: 백로그(Backlog), 진행 상황(Progress), 오늘(Today), 내일(Tomorrow). 사용자 지정 목록이나 장기 프로젝트는 없습니다. 백로그에는 실제로 다가오는 것만 담겨 있으며, 오늘과 내일은 작은 일일 플래너입니다.
• 추적된 시간은 수정할 수 없으므로, 숫자는 정직하게 유지됩니다.
• 수면 시간도 계산에 포함됩니다. 하루는 24시간이며, 수면 역시 예산의 일부입니다.

The board on a phone: swipe between lists, tap play

실제로 구축한 방법

아이디어, 제품 결정 및 아키텍처는 모두 저의 것이었습니다. 코드는 Claude Code를 통해 Claude가 전적으로 작성했습니다. 저는

현재 레포지토리는 Java, TypeScript, CSS 및 SQL로 약 25,000줄, 데이터베이스 마이그레이션 23개, 그리고 184개의 커밋으로 구성되어 있습니다. 이 모든 라인은 제가 작성한 것이 아닙니다.

결과물

The board on desktop

• 네 개의 리스트, 드래그 앤 드롭 기능, 시간 차트가 있는 작업 페이지, 색상별 그룹화, 선택적 일일 제한(daily caps) 기능을 갖춘 웹 앱.
• 통계: 주간, 월간, 연간 및 전체 기간 통계를 막대 그래프, 선 그래프 또는 활동 달력 형태로 제공하며, 그룹 필터링, CSV 내보내기, 그리고 임의의 두 날짜를 나란히 비교하는 기능이 있습니다.

Stats with a trend over a year

• 보드 하단 일일 스트립: 시간별 세션 타임라인 또는 하루 전체를 하나의 막대(놓친 시간, 수면, 그룹 활동, 남은 시간)로 '분해'하여 보여줍니다.
• 휴대폰 버전: 화면당 리스트가 하나씩 존재하며, 목록 사이를 스와이프하고, 모든 페이지에 현재 진행 중인 작업을 표시하는 막대가 있고, 이 막대를 스와이프하여 정지시킬 수 있습니다.
• PWA (Progressive Web App): 설치 가능하며, 읽기 전용으로 오프라인에서 작동하고, 제한(cap)에 도달하거나 타이머가 계속 실행 중일 때 푸시 알림을 보냅니다.
• Chrome 확장 프로그램: 툴바에서 작업을 시작하고 중지할 수 있으며, 아이콘에 진행 시간을 표시합니다.

The Chrome extension popup

• 세 가지 인터페이스 언어 (영어, 러시아어, 우크라이나어), 데이터베이스에 암호화된 작업 텍스트, Google 로그인 기능, 소형 VPS로 원클릭 배포가 가능합니다.
• 랜딩 페이지: 데모 데이터를 이용해 스크립트로 촬영한 스크린샷과 비디오를 포함하며, 이 역시 모델을 통해 제작되었습니다.

선언적 프로그래밍은 오래된 이야기입니다. 이것은 다르게 느껴집니다

우리는 오랫동안 선언적으로 코드를 작성해 왔습니다. 원하는 것(SQL, HTML, 설정 파일 등)을 말하면 엔진이 어떻게 구현할지 결정하는 방식입니다. 제가 여기서 한 것은 그보다 한 단계 높은 것입니다. 저는 코드를 설명한 것이 아니라 아키텍처를 설명했습니다. 즉, 어떤 부분이 있는지, 각 부분이 무엇을 소유하는지, 경계가 어디인지, 무엇이 금지되어 있는지, 그리고 제품이 어떤 느낌이어야 하는지를 설명한 것입니다. 구현은 모델에게 맡겼습니다.

어쩌면 '선언적 아키텍처 프로그래밍(declarative architectural programming)' 같은 이름이 어울릴지도 모릅니다. 이 용어가 정확한지는 모르겠지만, 분리는 명확합니다. 인간이 아이디어, 제약 조건, 그리고 취향을 소유하고; 모델이 타이핑(typing)을 소유하는 것입니다.

제가 배운 것들

• 명시된 경계가 기발한 프롬프트보다 중요하다. 모듈별로 무엇을 할 수 있고 할 수 없는지에 대한 짧은 메모는 수십 번의 세션에 걸쳐 코드베이스를 일관되게 유지하는 데 도움이 되었습니다.
• 파일에 표준화된 규칙을 만드는 것이 반복하기보다 낫다. 제가 두 번씩 수정했던 모든 오류들은 파일 내의 규칙이 되었습니다.
• 여전히 원하는 것을 알아야 한다. 모델은 잘못된 것을 구축하는 것도 빠릅니다. 제품의 엄격함(하나의 작업, 네 개의 목록, 편집 금지)은 저에게서 나왔으며, 이것이 앱을 완성할 만큼 작게 만듭니다.
• 검증이 새로운 병목 지점이다. 저는 버그를 찾기 위해 코드를 훑어볼 수 없었으므로, 사용자가 제품을 사용하는 것처럼 활용했습니다. 다른 작업을 하는 동안 발견한 버그들은 사라지는 대신 KNOWN_ISSUES.md 파일에 기록되었습니다.
• 노력이 필요하다는 것이 아니다. 시간과 주의력은 여전히 투입되어야 하지만, 타이핑으로 투입되는 것은 아닙니다. 결과물이 상상하는 대로 보이고 작동하기를 원한다면, 노력해야 합니다. 아이디어를 명확하게, 작고 원자적인 조각들로, 그리고 합리적인 순서로 구성해야 합니다. 모호한 입력은 모호한 출력을 낳습니다.

이것이 나의 것일까?

이 부분은 제가 아직 정리하지 못한 부분입니다. 이 앱은 제 아이디어와 규칙, 그리고 아키텍처에서 나왔지만, 코드는 직접 작성하지 않았습니다. 백엔드는 제가 직접 타이핑할 수 있었고; 프론트엔드와 확장 기능은 코드 자체를 읽지 않고 직관과 엔지니어링 감각으로 구현했습니다. '내가 만들었다'와 '내가 만들지 않았다'는 말을 같은 대상에 대해 하는 것이 이상하게 느껴집니다.

현재 저의 생각은 이렇습니다. 저는 제품과 결정의 작가이며, 모델이 타이핑을 담당합니다. 영화감독이 카메라를 직접 조작하는 것은 아닙니다. 하지만 그 경계선이 흐릿하고, 몇 달마다 움직인다는 것을 깨닫습니다.

솔직한 현황

사용자도 없고, 마케팅도 없고, 수익도 없습니다. 현재는 초기 접근 단계이며 무료로 제공되고 있으며, 저와 제 아들을 위한 도구로 시작되었습니다. 한번 사용해 보시고, 어떤 점이 잘못되었는지 알려주시면 좋겠습니다.

• 웹 앱: https://app.overdraft.nomad4.tech
• 랜딩 페이지: https://overdraft.nomad4.tech
• Chrome 확장 기능: https://chromewebstore.google.com/detail/mgciphgekdeipgbablncehlmjmlciadb

여러분의 차례입니다

• 모든 것을 설계하고 모델이 모든 코드를 작성했다면, 그것을 '당신의 것'이라고 할 수 있나요?
• 모델이 만든 빠르고 세련된 앱과, 손으로 직접 작성한 느리고 작은 앱 중 어떤 것을 출시하시겠어요?
• 만약 비슷한 실험을 해보셨다면, 무엇이 가장 먼저 무너졌나요? 아이디어였나요, 아키텍처였나요, 아니면 리뷰 과정이었나요?

댓글로 알려주세요. 그리고 만약 시간 추적(time track)을 하신다면, 없어서는 안 될 기능 하나가 무엇인지 알려주세요.

고지: 이 글 역시 모델(Sonnet 5.5)에 의해 제가 작성한 메모와 프로젝트 파일을 바탕으로 같은 실험의 일환으로 완전히 작성되었습니다.