
Python


MARU(마루)는 매일 반복되는 일을 시간에 맞춰 알려주고, 오늘 했는지를 간단하게 체크하는 Windows용 미니 스케줄러다.
업무 중 약을 챙기거나 백업을 실행할 시간을 놓치지 않도록, PC에 띄워 두고 쓰기 위해 만들었다.
필요한 기능이 떠오른 뒤 ChatGPT와 이름·로고·기획 초안을 정하고, Claude로 구현한 다음, Codex의 검토 보고서를 다시 Claude에 전달해 수정하는 방식으로 진행했다. 중간에는 직접 화면을 확인하며 수정 방향과 기능 범위를 결정했다.
개발일 : 2026.09.29 / 전체 작업 시간 : 약 1시간 30분
| Project | MARU — 오늘 할 일을 확인하는 데일리 체크 스케줄러 |
| Role | 필요 기능 정의 · 이름과 디자인 결정 · 사용 흐름 기획 · 육안 검수 · 수정 우선순위 및 배포 방식 결정 |
| AI Collaboration | ChatGPT: 이름·로고·기획 초안 / Claude: 상세 설계·구현·수정 / Codex: 코드 검토·재현 검사·재검토 및 Windows 빌드 확인 |
| Desktop UI | Python 3.11 · PySide6 6.11.2 |
| Data | 로컬 JSON — 반복 일정·설정·오늘 체크 상태 저장 |
| Notification | MARU 전용 팝업 · 완료 처리 · 재알림 · 시스템 트레이 |
| Deployment | PyInstaller 6.22.3 · 설치 과정 없는 Windows 단일 EXE |
| Test | 최종 회귀 테스트 28개 통과 · 별도 검토에서 방어 처리 제거 검사 8개 탐지 및 추가 시나리오 4개 통과 |
| Time | 기획부터 검토·배포까지 약 1시간 30분 |
| Result | 업무시간에 켜 두고 반복 일정과 오늘만 할 일을 확인하는 개인용 도구 완성 |
처음 생각한 기능은 단순했다. 정해진 시간이 되면 알림이 뜨고, 일을 마친 뒤 확인을 누르면 오늘 일정에 체크되는 프로그램이 필요했다. 약을 챙기는 시간과 백업을 실행하는 시간을 기본으로 등록하고, 그날만 해야 하는 일이 생기면 추가해서 쓰면 됐다.
이번에 필요한 범위는 오늘의 완료 여부였다. 장기 통계나 연속 달성 기록, 계정과 서버까지 만들 이유는 없었다. 업무시간에 사용하고 퇴근하면 그날 역할이 끝나는 도구로 범위를 정했다.
시간 도착 → MARU 알림 → 직접 할 일 수행 → 했어요 → 오늘 일정에 체크
여기서 백업 일정은 백업할 시간을 알려주는 알림이다. MARU가 파일을 직접 백업하거나, 알림을 띄웠다는 이유만으로 일을 완료 처리하는 기능은 넣지 않았다.

먼저 ChatGPT에 필요한 동작을 설명하고 프로그램 이름을 같이 정했다. 여러 후보 중에서 선택한 이름은 MARU. 일본어의 동그라미를 뜻하는 ‘마루’에서 착안해, 오늘 할 일을 하나씩 ○로 만들어 간다는 의미를 붙였다.
이름이 정해진 뒤에는 동그란 강아지 캐릭터를 로고로 잡았다. 체크리스트와 연필을 든 강아지, 따뜻한 갈색과 주황색 계열을 기본으로 해서 화면과 알림까지 같은 느낌으로 이어지게 했다.
그다음에는 아이디어를 개발에 전달할 기획서로 정리했다. 일정 등록·수정·삭제, 시간 알림, 완료와 재알림 버튼, 날짜 변경 시 체크 초기화, 트레이 실행과 자동 시작까지 필요한 동작을 적었다. 이 단계에서는 어떤 프로그램을 만들지와 어디까지 만들지를 먼저 정했다.
ChatGPT에서 정리한 기획서와 로고를 Claude에 전달하고 구현을 진행했다. Python 응용프로그램으로 만들고, 화면은 PySide6를 사용했다. 알림은 Windows 기본 알림 대신 MARU 전용 팝업을 선택했다.
초기 아이디어에 있던 매일 반복 일정에 더해, 그때그때 등록하는 ‘오늘만’ 일정도 사용할 수 있게 했다. 화면은 오늘 목록을 바로 확인하는 데 집중하고, 추가·수정·설정은 별도 창으로 나눴다.

완료 여부는 알림에서 바로 처리할 수도 있고, 메인 화면의 상태 버튼을 눌러 바꿀 수도 있다. 잘못 체크했다면 다시 눌러 취소할 수 있게 했다.

알림은 일을 했다는 기록과 분리했다. 시간이 돼서 팝업이 나타나도 일정은 미완료로 남고, ‘했어요’ 버튼을 눌러야 완료된다. 바로 처리하기 어려우면 ‘10분 후’로 미룰 수 있다.


이렇게 기본 기능이 있는 1차 화면을 만드는 데 약 20분이 걸렸다. 다만 화면이 나타나는 것과 매일 쓸 수 있는 상태로 마무리하는 것은 별도의 작업이었다.
실행 화면을 확인하면서 버튼, 일정 표시, 아이콘처럼 매일 사용할 때 눈에 들어오는 부분을 수정 요청했다. 예를 들어 메일과 문서 아이콘도 실제 화면에서 구분하기 쉬운 모양으로 골랐다.
로고와 화면 분위기가 어울리는지, 일정과 완료 상태가 바로 읽히는지, 설정 항목이 필요한 만큼만 들어 있는지를 직접 확인했다. 이 과정에는 약 30분을 사용했다.
AI가 만든 화면을 그대로 채택하는 대신, 내가 사용할 장면을 기준으로 수정 방향을 정했다. 기능을 더 많이 넣는 것보다 오늘 할 일을 확인하는 흐름이 자연스러운지가 우선이었다.
1차 개발과 화면 수정을 마친 뒤에는 실제 프로그램 파일과 처음 정리한 요구사항을 Codex에 전달했다. 화면이 보이는지뿐 아니라, 일정과 알림 상태가 저장·수정·재시작 과정에서도 맞게 유지되는지 검토하도록 했다.
첫 검토에서는 수정이 필요한 항목 8건이 나왔다. 평소 화면을 잠깐 눌러 보는 것만으로는 발견하기 어려운 조건들이 포함돼 있었다.
| 검토 항목 | 확인한 문제 |
|---|---|
| 저장 실패 | 저장이 실패했는데 메모리만 완료로 바뀌거나, 실제 팝업을 띄우기 전에 알림을 보낸 것으로 처리되는 경우 |
| 수정 전 알림 | 일정 시간을 바꾸거나 사용을 꺼도 이전 팝업으로 완료 처리가 가능한 경우 |
| 긴 일정 이름 | 입력 가능한 길이의 제목이 완료 버튼을 창 밖으로 밀어내는 경우 |
| 날짜 경계 | 자정 직후 추가한 오늘만 일정에 전날 날짜가 붙어 삭제되는 경우 |
| 알림 누적 | 여러 팝업이 위로 쌓이면서 일부가 화면 밖으로 나가는 경우 |
| 자동 실행 실패 | 등록에 실패해도 설정을 저장한 것처럼 보이는 경우 |
| 데이터 구조 오류 | JSON 문법은 맞지만 내부 구조가 잘못돼 시작에 실패하는 경우 |
| 복구본 보존 | 손상 파일의 복구본을 만들면서 이전 복구본을 덮어쓰는 경우 |
예를 들어 저장 실패 문제는 단순히 오류 메시지를 보여 주는 것으로 끝나지 않았다. 화면에서 보이는 완료 상태와 파일에 저장된 상태가 일치하는지, 저장을 못 했다고 알림까지 사라지지는 않는지를 함께 확인해야 했다.
검사는 실제 사용 데이터를 바꾸지 않고 임시 데이터와 가상 시각을 이용해 진행했다. 검토 결과는 문제 위치, 재현 조건, 수정 방향을 담은 보고서로 받았다.
Codex의 보고서를 Claude에 전달해 결함을 재현하고 수정하도록 했다. 검토 결과를 설명만 듣고 끝내지 않고, 수정한 동작이 다시 깨지는지를 확인할 회귀 테스트도 함께 추가했다.
사용자가 완료·추가·수정을 했는데 저장에 실패하면 이전 상태로 되돌리고 재시도할 수 있게 했다. 반면 알림 상태의 백그라운드 저장 실패는 실제 알림을 막지 않도록 하고, 저장하지 못한 내용을 알려 주며 다시 저장하도록 처리했다.
오래된 팝업은 생성 당시의 날짜와 일정 수정 번호를 기준으로 무효화하고, 긴 제목은 말줄임과 툴팁으로 정리했다. 화면을 넘는 알림에는 대기열을 두고, 손상된 데이터의 복구본도 서로 덮어쓰지 않도록 바꿨다.
수정이 끝났다는 답변을 받은 뒤에는 다시 Codex에 전달해 코드와 테스트를 확인했다. 이 과정에서 이전 실행 경로의 자동 시작 항목이 남는 문제와, 시간대가 포함된 재알림 값 때문에 다른 일정 검사까지 중단되는 문제가 추가로 확인됐다.
저장 재시도 창을 열어 둔 채 날짜가 바뀌는 경우도 발견됐다. 내 사용 방식은 퇴근 시 종료하는 것이어서 우선순위를 낮춰도 됐지만, 수정 범위가 작아 함께 반영했다. 발견한 문제의 중요도는 실제 사용 범위를 기준으로 판단했다.
이후에도 검토 보고서 전달 → Claude 수정 → Codex 재검토를 이어 갔다. 마지막에는 기존에 지적했던 항목들이 해당 재현 검사에서 해결된 것을 확인했다.
또 하나 확인한 것은 테스트가 실제로 결함을 잡아내는지였다. 저장 실패 시 상태를 되돌리는 처리나 오래된 알림을 막는 처리 등을 검사 과정에서 하나씩 제거하자, 8개 대표 검사에서 해당 테스트가 실패했다. 정상 코드에서 통과한다는 결과와 함께 확인한 부분이다.
로그 테스트를 추가한 최종 회귀 테스트는 28개 모두 통과했다. 별도 재검토에서는 추가 시나리오 4개도 통과했다. 다만 화면 없는 Qt 검사와 레지스트리 모의 검사는 실제 Windows 로그인이나 화면 배율 확인과는 구분해서 봤다.
배포 형태는 설치 프로그램 없이 실행하는 단일 EXE로 정했다. 업무시간에 간단히 띄워 두는 개인용 도구라, 설치·제거 절차까지 만들기보다는 정해진 폴더에 두고 바로 실행하는 방식이 맞았다.
일정과 설정은 EXE와 분리해 사용자 데이터 폴더의 JSON 파일에 저장한다. 그래서 같은 PC에서 EXE를 교체해도 등록한 일정과 오늘 체크 상태는 유지된다. 다음 날 다시 실행하면 전날의 체크가 초기화되고, 반복 일정은 남는다.
여기서 설치 없이 실행한다는 것과 데이터까지 EXE 안에 들어 있다는 것은 다르다. 다른 PC로 EXE만 복사하면 기존 일정이 자동으로 따라가는 방식은 아니다.
배포 준비에서는 테스트를 통과한 뒤 빌드하도록 구성하고, 실행 중인 프로그램을 강제로 종료하지 않도록 했다. 오류를 나중에 확인할 수 있게 용량을 제한한 순환 로그도 추가했다. 체크 이력을 장기간 모으는 기능과는 별개다.
Windows용 단일 실행 파일을 제작했고, 실제 배포도 마쳤다. 기획서만 정리하거나 시연 화면을 만드는 데서 끝내지 않고, 내 PC에서 실행해 사용할 파일까지 만드는 것을 이번 작업의 마무리로 잡았다.
| 단계 | 소요 시간 | 진행 내용 |
|---|---|---|
| 기획 초안 | 약 10분 | 필요 기능 정리, 이름과 로고 결정, 개발용 기획 초안 |
| 1차 개발 | 약 20분 | Claude와 상세 기획 및 기본 기능 구현 |
| 육안 검사·수정 요청 | 약 30분 | 실행 화면 확인, 아이콘·표시·사용 흐름 피드백 |
| 검토·수정·배포 | 약 30분 | 세 차례의 피드백 과정, 재검토, 배포 버전 제작 |
| 합계 | 약 1시간 30분 | 아이디어에서 개인용 실행 프로그램까지 |
시간은 이번 작업을 돌아보며 정리한 대략적인 기록이다. 기획과 1차 구현에 약 30분, 화면 확인과 검토·수정·배포에 약 60분을 썼다. 빠르게 화면을 만든 뒤에도 결과를 확인하고 고치는 시간이 상당 부분을 차지했다.
| 담당 | 이번 작업에서 맡은 역할 |
|---|---|
| 나 | 무엇이 필요한지 정의하고 이름·디자인·화면 수정·기능 범위·배포 방식을 결정 |
| ChatGPT | 프로그램 이름과 로고 방향, 개발에 전달할 기획 초안 정리 |
| Claude | 상세 설계와 구현, 사용자 피드백 및 검토 보고서 반영, 회귀 테스트와 패키징 준비 |
| Codex | 실제 코드 검토, 결함 재현, 수정 후 재검증, Windows 빌드와 포함 리소스 확인 |
필요한 기능 발견
↓
ChatGPT와 이름·로고·기획 초안
↓
Claude와 상세 설계·구현
↓
직접 화면 확인·수정 요청
↓
Codex 검토 보고서
↓
Claude 수정 ↔ Codex 재검토
↓
배포 버전 제작·실제 사용같은 요구사항과 실제 산출물을 넘겨 가며 작업한 점이 중요했다. “잘 만들어 줘”라는 요청을 반복하기보다, 어느 조건에서 어떤 문제가 났는지 전달하니 다음 수정에서 확인할 기준도 분명해졌다.

이번 프로젝트는 간단 기획서로 어디까지 가능한가를 보는 거였는데… 결과는 너무 놀라웠다.
일단 chatGPT로 프로그램에 대한 대략적 설명과 다른 프로그램 이름을 알려주니 비슷한 유형의 이름을 추천받아서 그중에 고르면 되었다.
이어서 로고 제작도 chatGPT로 진행하였다.
그 과정에서 내가 한 건 마루니깐 강아지면 좋겠다는 단 1개 설정이었는데, 체크하는 프로그램 컨셉과 동그라미라는 이름에 맞는 로고가 나왔다.
추가로 ui 디자인을 chatGPT로 진행하고 지금까지 대화한 내용을 프로그램 기획서로 작성시켜서 클로드로 넘겼다.
다른 대형 프로젝트에서는 웹클로드로 지시서를 md로 만들고 내가 윈도우파워쉘로 넘기면서 작업하고 있지만, 이번은 작은 규모라 work로 직접 개발 지시를 해보았다.
gpt에서 넘겨받은 기획서와 이미지를 주고 오퍼스 등급으로 개발을 시켰다.
파일 분석 후 스스로 필요 파일들을 만들고 work다 보니 직접 폴더에 파일 세팅도 하고…
혹시 중간에 내가 도와줄까 했더니 거절도 당하고 쿨럭…
..
금방 뚝딱 1차 버전이 나왔다.
거의 완성형에 가까워서 너무 놀랐고, 거기서 내가 한 거라고는 사용할 리스트 추가 정의 간단한 css 수정뿐이었다. 아! 추가로 실행을 위한 bat 파일 누르기 정도?
그리고 이번엔 구현된 파일들을 codex에 접근 권한을 주고 파일 분석을 시켰다.
수정 없이 분석 후 피드백과 테스트 재현용 파일들이 나왔고 그걸 클로드에 반영 여부 검토 후 몇 차례 수정에 들어갔다.
확실히 이 과정에서는 내가 보는 외형적 부분과는 다르게 버그나 기능적인 피드백, 아직 발생하지 않은 대응에 대한 것들이 오가며 수정이 이루어졌다.
개인적으로 혼자 쓸 거라 Fable 보안 검토는 돌리지 않았다.
여기까지 총제작 시간이 1시간 반. 평소 내 개발 속도라면 최소 2일은 걸렸을… 솔직히 디자인적 코드 퀄리티나 UX도 AI로 제작한 게 더…
개발자의 미래…. 아니 나의 미래는 괜찮은걸까?… 기획자만 살아남을듯 ㅠㅡㅠ
참고로 분업 기준은 평소 내가 써봤을 때 좋았던 기준이지, 실제 AI 특화 부분과는 다를 수 있다.
다른 프로젝트 보기 : Project 전체 보기