10월 8일에는 학술대회 패키지를 세 단계로 나누고, 첫 메일에서 제안할 상품과 데모 방식, 일정을 정했습니다. 데모 사이트 brave-conf를 위한 환경을 세팅했고, 매일 한 일을 기록하는 흐름도 점검했습니다.
오늘 한 일
- /정리 명령어 첫 확인 (10분): 새 세션에서 /정리를 처음 입력했습니다. 행동쟁이-한일 폴더에 오늘 날짜 노트가 생기고, 한 일과 설명이 적혔습니다.
- 옵시디언 기록 확인 (5분): 밤 10:30 뒤 옵시디언 오늘 화면에 한 일이 들어왔는지 확인했습니다. 안 들어왔을 때는 scripts/sync-obsidian.log를 보기로 했습니다. 어제 한 일은 확인할 수 있었지만, 오늘 중간중간 정리한 일은 오늘 날짜로 저장되지 않는 빈틈을 찾았습니다.
- 세팅 마감 점검표 확인 (20분): 빠진 것이 있는지 점검했습니다. 어제 한 일 14개를 확인하고 오늘 할 일과 이어 붙일 수 있었습니다.
- 학술대회 패키지 나누기 (60분): 기본(초록+), 표준(편성+), 확장(학술대회+)으로 나누고, 포함·선택·제외 표를 만들었습니다. 사전 결제, 문자, 메일 발송은 선택 항목으로 두었습니다.
- 이번 주 기획 확정 (30분): 첫 메일에서 팔 상품 하나, 데모 방식, 일정, 영업 후보 기준을 정했습니다.
- 데모 에디션 방식 결정: 기존 서비스를 복제해 필요한 부분만 남기는 방식으로 정했습니다. 이름은 brave-conf, 공개는 단계 공개로 정하고 기획서를 고쳤습니다.
- 데모 기획서 교차 검토 반영: Codex가 조건부 진행 의견과 지적 13건을 남겼습니다. 14장의 13개 결정과 반영 결과가 담긴 15.5를 읽고 틀린 것만 고쳤습니다. 다른 AI에게 한 번 더 검토를 맡기려면 15.1 프롬프트를 쓰면 됩니다.
- brave-conf 개발 환경 세팅: 프로젝트 폴더, GitHub 비공개 저장소 brave_conf, 서버와 DB, 도메인을 세팅했습니다.
예상 대 실제
- /정리 명령어: 예상대로 오늘 날짜 노트가 생기고 한 일과 설명이 적혔습니다.
- 옵시디언 기록: 명령어 하나로 저장하고, 웹서버를 거쳐 할 일을 DB에 쌓는 흐름을 예상했습니다. 실제로는 어제 한 일만 오늘 볼 수 있었고, 오늘 중간에 정리한 일은 오늘 날짜로 저장되지 않았습니다.
- 세팅 마감 점검표: 어제 한 일과 못 한 일을 파악할 수 있을 것으로 예상했습니다. 실제로 어제 한 일 14개를 확인했고, 오늘 할 일과 자연스럽게 이을 수 있었습니다.
- 학술대회 패키지: 고객이 필요에 따라 고를 수 있게 기본, 표준, 확장으로 나누려 했습니다. 이미 만든 기능을 모듈로 나누면(필요한 부분만 떼었다 붙일 수 있게 나누면) 세 단계에 맞춰 쓸 수 있다는 것을 확인했습니다. 다만 의도치 않은 영향(사이드 이펙트)과 디자인이 어긋나는 부분은 아직 정리해야 합니다.
- 이번 주 기획: 상품 규모와 가짓수, 데모 방식, 일정을 정하는 것이 목표였습니다. 실제로 정한 내용은 다음과 같습니다.
- 첫 상품은 학술대회 패키지 '기본(초록·심사)'입니다.
- 데모는 비밀번호 없는 공개 체험과 14일 비공개 링크로 합니다. 이메일로 ID와 비밀번호는 보내지 않습니다.
- 10/11까지 전체 설계를 만들고 10/12부터 메일을 보냅니다.
- 다음 초록 접수 마감이 2~4개월 안인 학회부터 연락합니다. 오늘 고른 후보는 5곳입니다.
- 데모 에디션: 기존 제품에서 필요한 부분만 복제하고 줄이는 방식을 제안했고, 그대로 확정해 기획서에 반영했습니다.
- 교차 검토: Claude와 Codex가 서로 비판적으로 보게 해서 혼자 못 찾는 빈틈을 찾으려 했습니다. 실제로 Codex가 Claude의 기획안을 객관적으로 비판했고, Claude가 이를 받아들여 대안을 냈습니다.
- 개발 환경 세팅: 처음에는 폴더를 만들고 개발한 뒤 Git, 서버, DB, 도메인을 세팅하려 했습니다. 그런데 개발 중간에 세팅할 일이 자꾸 생겨 개발이 끊겼습니다. 그래서 도메인을 뺀 Git, 서버, DB를 먼저 세팅하고 개발을 이어 갔습니다.
배운 점
- AI에게 일을 맡기는 방법: AI에게 겉핥기로 일을 시키면 쌓이는 것이 없습니다. 신입사원에게 일을 가르치듯 할 일을 매뉴얼로 만들어 쌓아야 합니다. AI가 제 생각을 읽고 원하는 바를 조금씩 구체화하게 하려면, AI와 약속을 정하고 데이터를 쌓아 매뉴얼로 만들어야 합니다.
- 당일 기록 저장: 오늘 한 일을 오늘 날짜로 저장할 방법이 필요합니다. 스킬을 쓸 때 데이터가 웹 DB로 바로 가게 하거나, Cron(정해진 시간마다 자동으로 실행하는 기능)으로 1시간마다 보내도록 고칠 생각입니다.
- 매일 기록의 효과: 하루를 기록하면 돌아보기에도 좋지만, 다음 일을 시작하는 준비 시간이 줄어 집중하는 시간이 늘어납니다. 이것을 업무 관리 웹앱에 적용하면 직원들이 어제, 오늘, 내일 할 일을 이어서 볼 수 있는 화면을 만들 수 있겠다고 생각했습니다.
- 모듈화와 상품 나누기: 이미 만든 기능을 모듈로 나눈 것은 좋은 선택이었습니다. 다만 나누면서 생기는 충돌과 사이드 이펙트를 미리 생각하지 못해 시간이 더 걸렸습니다. 그래도 상품을 단계별로 나눠 두면 고객마다 다른 여건에 맞춰 대응하기 쉬워집니다.
- 상품과 데모를 먼저 정하기: 상품을 정하고 모듈로 나눠 두면 영업 후보가 바뀌어도 대응하기 쉽다고 보고 상품과 데모를 먼저 정했습니다. 영업 후보 기준과 받은 의견에 따라 나중에 고쳐 나갈 계획입니다.
- 고객이 낼 수 있는 만큼의 상품: 고객마다 필요한 규모가 다르므로 품질이 높기만 하다고 좋은 것은 아니었습니다. 고객이 낼 수 있는 금액 안에서 줄 수 있는 상품을 만드는 것이 고객의 요구를 채우는 길이라고 생각했습니다.
- AI끼리 교차 검토: AI는 사용자의 의도를 따라가기 쉽습니다. 그래서 반대 의견이나 비판을 하도록 지시한 다른 AI에게 결과를 평가하게 하면 결과물의 품질을 높일 수 있습니다.
- 실행과 준비의 균형: 실행을 먼저 하는 태도는 도움이 되었습니다. 하지만 개발 전에 어느 정도 환경을 세팅해 두는 것이, 나중에 설정을 바꾸다 오류가 나는 것을 막는 방법이라고 생각합니다.