직접 써본 AI 도구40 코덱스 사용량 70%가 사라진 밤과 세 번의 오진 기록 2026년 8월 1일 밤 9시, 나는 사용량이 다 닳았다는 사실을 알았다. 손을 쓰지 못해 입술로 커서를 움직이는 내게 사용량은 곧 작업 시간이다. 바닥나면 그날 일도 멈춘다. 그런데 그날은 코덱스를 거의 쓰지 않았는데도 70%가 사라져 있었다. 닷새를 뒤졌고, 세 번 틀린 뒤 네 번째에야 원인을 찾았다.거의 쓰지 않았는데 왜 70%가 사라졌을까?내가 처음 확인한 사실은 단순했다. 코덱스를 거의 쓰지 않은 날에 사용량의 70%가 사라졌고, 그 변화는 밤 9시에야 눈에 들어왔다. 문제의 크기와 원인은 처음부터 같지 않았다. 숫자는 분명했지만 그 숫자가 왜 줄었는지는 바로 말할 수 없었다.“사용량이 곧 내 작업 시간이라 바닥나면 그날 일이 멈춘다.”이 기록을 적을 때 중요한 것은 불편함을 크게 보이게 만드는.. 2026. 9. 20. paseo에서 Orca로 바꾸며 확인한 세 가지 2026년 8월 17일, 나는 paseo에서 Orca로 넘어가며 바로 확인한 변화 세 가지를 적었다. 파일을 CLI 창으로 끌어다 놓으면 그대로 들어가는 점, 설정 없이 상태줄이 뜨는 점, 그리고 여러 에이전트를 굴리는 오케스트레이션 가능성이다. 셋째는 아직 켜 보지 못했다. 램이 부족해 우선 한두 개만 붙여 볼 생각이라고 남겼다.도구를 바꾸면 무엇부터 달라질까?내 경우에는 파일을 넣는 방식, 상태를 보는 방식, 여러 에이전트를 다루는 가능성이라는 세 지점이 먼저 눈에 들어왔다.“paseo에서 Orca로 넘어왔더니 달라진 게 3개다.”도구를 비교할 때 기능 이름을 길게 나열하는 것보다, 실제로 손이 닿는 순간의 차이를 적는 편이 내게는 더 분명했다. 이번에는 파일 하나를 넣는 동작, 화면에서 상태를 읽는.. 2026. 9. 19. 앱 기획 스킬을 20섹션 PRD로 고쳐 쓴 이유 2026년 4월 10일, 새 앱을 만들 때마다 기획 단계에서 가장 오래 멈추던 나는 vibewithaisy/app-plan-skill을 보고 출발점을 찾았다. 인터뷰로 앱 기획을 구체화하고 문서 구조를 잡아 주는 Claude Code 스킬이었다. 하지만 기획만으로는 손이 움직이지 않는다는 내 기준이 남아 있었다. 그래서 원본을 fork해 경쟁사 조사부터 KPI와 리스크까지 담은 20섹션 PRD 방향으로 바꿨다.원본 스킬과 내가 바꾼 스킬은 무엇이 달랐나?원본은 기획을 구체화하는 출발점이었고, 나는 필요성·차별화까지 답해야 다음 단계로 움직일 수 있었다.“기획만으로는 안 움직였다. 나는 ‘왜 이 앱이 필요한가’, ‘남들과 뭐가 다른가’까지 답이 나와야 손이 움직이는 사람이었다.”항목출발점내가 덧붙인 방향기.. 2026. 9. 18. AI가 오후 4시를 23분 뒤라 계산한 이유와 도구 전환 2026년 8월 19일, 나는 Claude에게 현재 시각을 매 턴마다 넣도록 해둔 뒤에도 오후 4시 예약을 23분 남았다고 받았다. 당시 시각은 오후 1시 37분이었다. 4시까지는 2시간 23분인데 시간 자리 하나가 사라졌다. 이 작은 계산 오류를 계기로, 시각을 아는 일과 시각을 계산하는 일을 분리해서 보게 됐다.시간을 알려줬는데 왜 계산은 틀렸을까?현재 시각을 문장으로 넣는 일과, 그 시각으로 차이를 정확히 계산하는 일은 같은 작업이 아니었다.“그때가 1시 37분. 4시까지 2시간 23분인데, 시간 자리만 통째로 날렸다.”내가 본 답은 분 단위의 23은 남기고 시간 단위의 2를 잃어버린 형태였다. 오후 1시 37분, 오후 4시, 2시간 23분이라는 세 숫자는 모두 대화 안에 있었지만, 답으로 나온 값.. 2026. 9. 18. 코덱스 한도가 11시간 만에 사라진 날 점검한 5가지 2026년 8월 2일, 지난 글에서 원인을 막았다고 적은 뒤 닷새가 지났을 때였다. 한도가 11시간 만에 0이 됐다. 그날 나는 코덱스를 한 번도 열지 않았고 세션 기록 폴더도 만들어지지 않았다. 사용량이 곧 내 작업 시간인 상황에서, 엿새를 통째로 잃을 수 있다는 감각이 먼저 왔다.한도가 줄었는데 작업 기록이 없다면 무엇부터 봐야 할까?내가 남긴 답은 단순했다. 기록이 없는 날에는 내가 코덱스를 열지 않았다는 점부터 분명히 적는 것이다. 11시간, 0, 닷새라는 숫자는 추측보다 먼저 확인한 관찰값이다. 무엇이 사용량을 가져갔는지 바로 단정하지 않고, 이미 꺼 둔 항목과 남아 있는 조건을 차례로 분리했다.“그날 나는 코덱스를 한 번도 열지 않았다. 세션 기록 폴더가 아예 안 만들어졌다.”사용량 숫자만 보.. 2026. 9. 16. 버그 제보 하루 뒤 비용이 절반으로 돌아온 과정 2026년 8월 19일, 나는 같은 플랜인데 비용이 2배로 계산되던 캐시 버그를 로그째로 제보했다. 다음 날 수정판이 배포된 뒤 같은 5턴을 다시 돌렸더니 3.28달러가 1.72달러가 됐고, 캐시 쓰기는 44k에서 14k로 줄었다. 제보부터 검증까지의 시간을 숫자와 함께 정리한다.처음 발견한 문제는 무엇이었나?같은 플랜에서 비용이 2배로 보이는 캐시 버그였고, 나는 그 현상을 말이 아니라 로그로 제보했다.문제를 처음 적을 때 내가 붙잡은 것은 “비싸다”는 감상이 아니었다. 같은 플랜인데 비용이 2배라는 현상과 그때의 로그였다. 캐시가 대화 전체를 다시 쓰는 것처럼 보이는 상황을 확인했고, 그 기록을 그대로 제보했다. 원문에서 “제보는 욕이 아니라 로그로 하는 거였다”라고 쓴 이유가 여기에 있다.로그가 있.. 2026. 9. 14. 이전 1 2 3 4 5 6 7 다음