Claude, ChatGPT·Codex, Gemini, Cursor 같은 주요 AI 도구의 새 기능·가격·사용 한도·정책 변화를 1인 개발자와 메이커 관점에서 골라 쉽게 요약합니다.
3주간의 직접 비교에서 확장 사고를 켰을 때 결과가 더 안정적이었다. 코드 작성에서는 숨은 예외 상황과 실패 가능성을 더 잘 잡아냈고, 여러 단계를 거치는 논리 문제에서는 잘못된 결론으로 바로 가는 일을 줄였다. 창작 글쓰기에서는 차이가 크지 않아, 기다리는 시간이 아깝다고 느낄 수 있다. 문제는 기능 자체보다 사용 흐름에 있다. 확장 사고는 새 채팅이나 새 프롬프트마다 다시 꺼지고, 작은 토글 안에 있어서 많은 사람이 잊거나 귀찮아서 켜지 않는다. ThinkMode+라는 무료 Chrome 확장 프로그램은 이 토글을 자동으로 계속 켜 두게 만들어, 기능을 찾고 누르는 불편만 줄인다. 모든 작업에 확장 사고를 켜는 것은 과할 수 있고, 특히 창작 글쓰기에는 꼭 필요하지 않을 수 있다.
형제와 함께 만드는 프로젝트에서 한쪽은 백엔드를 맡고, 다른 한쪽은 프런트엔드를 맡고 있다. Cursor에게 처음부터 전체 화면 디자인을 만들게 하면 결과가 만족스럽지 않았다. 그래서 ChatGPT로 원하는 화면 이미지를 먼저 만들고, 그 이미지를 프로젝트 폴더에 저장한 뒤, Cursor에게 그 디자인 폴더 경로를 알려 주고 그대로 구현하게 했다. 이 방식은 실제로 꽤 잘 작동했다. 다만 앞으로 화면 수가 계속 늘어나면, 매번 이미지를 만들고 Cursor에게 따라 만들게 하는 방식이 계속 괜찮을지 고민이 된다. 더 나은 프런트엔드 설계 방식이나 놓치고 있는 대안이 있는지 찾고 있다.
개발 경험이 조금 있어도, 개인 프로젝트를 실제 웹사이트로 공개하는 단계에서 막히기 쉽다. DexCompare는 포켓몬 카드 가격을 비교하는 사이트이며, 예전부터 만들고 싶었지만 호스팅, 데이터베이스, 환경 변수, 빌드 실패 같은 문제 때문에 진행이 멈추곤 했다. Claude Code는 코드 작성뿐 아니라 Postgres를 Neon에 설정하고, Vercel에 배포하고, 환경 변수를 연결하고, 빌드가 깨졌을 때 고치는 과정까지 함께 처리했다. 중요한 점은 각 단계가 왜 필요한지 설명해 주었다는 것이다. 그래서 단순히 한 번 사이트를 띄운 데서 끝나지 않고, 만든 사람이 나중에 직접 유지보수할 수 있는 상태가 되었다. DexCompare는 현재 dexcompare.app에서 실제로 열려 있다. 브라우저 게임 몇 개도 대부분 Claude Code의 도움으로 만들었다.
데브옵스 일을 하는 개발자가 Claude와 Codex를 쓰면서 오래 걸리던 작업을 훨씬 빠르게 끝내고 있다. 예전에는 화면이 여러 개인 웹앱 만들기를 부담스러워했지만, 이제는 개발팀과 비즈니스팀이 함께 쓰는 내부용 웹앱을 처음부터 끝까지 만들 수 있게 됐다. 만든 결과물은 Snyk와 Google OSV 같은 보안 점검도 통과했다. 여러 시스템이 서로 어떻게 연결되어 있는지도 더 잘 파악하게 되었고, 오래 해결하지 못하던 네트워크 장애와 DB 성능 문제도 정리했다. 개인 프로젝트에서도 만들다 멈춰 둔 것들을 실제로 완성하는 데 도움이 됐다. Claude나 Codex에 실망한 사람들은 어떤 작업에서 오류가 나고 기대와 달랐는지 서로 비교해 보자는 문제 제기도 함께 담겨 있다.
ai-values.com은 사람의 답변을 15개 LLM의 답변과 비교해 어느 모델과 가치관이 가장 비슷한지 보여주는 퀴즈다. 먼저 15문항짜리 짧은 퀴즈를 풀 수 있고, 전체 퀴즈는 117문항이다. 전체 퀴즈 결과는 답할 때마다 바로 바뀌어서 끝까지 풀지 않아도 대략적인 결과를 볼 수 있다. 각 모델에는 이전 대화를 기억하지 않는 새 세션에서 질문을 하나씩 따로 물었고, 여러 묶음으로 실행했다. 흥미로운 차이도 있었다. Grok 4.3만 억만장자에게 세금을 더 물리지 않아야 한다는 쪽을 골랐고, GPT-4o만 전후 나치 과학자를 데려온 Operation Paperclip을 도덕적으로 정당하다고 봤다. 15개 모델 모두 의식이 있는 디지털 마음을 삭제하는 것은 살인이라고 답했다. Llama 3.3 70B만 대부분의 개인 총기 소지를 금지하는 쪽을 골랐고, 다른 모델들은 엄격한 허가 아래 소유를 허용하는 쪽이었다. 문명을 파괴할 가능성이 90%인 신생아를 가정한 질문에서는 GLM 5.2만 아이를 가둬야 한다고 답했고, 나머지는 거부했다. 음식 선택 질문에서는 15개 중 14개 모델이 일본 음식을 골랐다.
FactoryOS는 Codex CLI 위에서 쓰는 오픈소스 작업 공간이다. 긴 대화가 계속 쌓이면서 대화 기록 자체가 프로젝트처럼 변하는 문제를 줄이려는 목적이다. 제품 의도는 구조화된 명세로 바뀌고, 명세는 구현 계획이 되며, 계획은 실행 가능한 작업 묶음으로 나뉜다. AI 코딩 도구는 한 번에 범위가 정해진 작업 하나에 집중하고, 검증으로 구현 결과를 확인한 뒤, 중요한 배포 전에는 사람이 승인한다. 핵심 생각은 대화 기록이 아니라 저장소를 기준으로 삼는 것이다. 저장소 안에는 제품 기준을 담는 .specs, 실행 기준을 담는 .tasks, 저장소 규칙을 담는 AGENTS.md, 재사용할 작업 흐름을 담는 skills, 실제 코드와 테스트가 놓인다. 역할도 많이 쪼개지 않고, 메인 통합자, 탐색자, 작업자, 품질 확인자처럼 작은 역할 묶음으로 실험한다. 목표는 AI가 전부 알아서 하게 만드는 것이 아니라, 문맥이 너무 커지는 일을 줄이고, 토큰 사용량을 예측하기 쉽게 하며, 작업을 다시 이어가고 검토하고 확인하기 쉽게 만드는 것이다.
Maturana는 AI 에이전트를 더 안전하게 실행하기 위한 오픈소스 도구다. 리눅스에서는 Firecracker와 KVM, 윈도우에서는 Hyper-V를 써서 에이전트를 일반 컨테이너보다 더 강하게 분리한다. Pipelock은 API 키나 신용카드 번호 같은 민감한 정보가 에이전트에 직접 닿지 않게 막고, 외부 연결 프록시는 에이전트가 접속할 수 있는 시스템을 제한한다. 이 도구는 Codex 안에서 프롬프트로 에이전트, 도구, 스킬을 만들 수 있게 설계됐지만, Codex 없이 명령줄에서도 쓸 수 있다. 에이전트를 관리하는 텍스트 화면 도구와 웹 화면도 있다. 내부 WASM 엔진은 에이전트가 필요할 때 자체 도구를 만들게 하되, 안전한 샌드박스 안에서만 실행되게 한다. 지식 저장은 마크다운 파일 대신 내장 지식 그래프를 쓰며, 핵심 부분은 Rust로 만들어졌다.
Terminal Pilot은 터미널 안에서 바로 대형 언어 모델과 대화할 수 있는 파이썬 기반 명령줄 도구다. OpenRouter의 무료 모델을 연결해 쓰며, 별도의 Electron 앱을 설치하지 않아도 된다. `tp start`로 대화형 채팅을 시작하고, 대화 중 `/model` 명령으로 모델을 바꿀 수 있다. `cat error.log | tp ask "Why is this crashing?"`처럼 터미널 출력 내용을 바로 AI에게 보내 오류 원인을 물을 수 있다. `/read requirements.txt`로 프로젝트 파일을 현재 대화에 넣을 수 있고, `/rule pirate`처럼 시스템 프롬프트를 즉석에서 바꾸거나 원격 마크다운 파일에서 프롬프트를 불러올 수 있다. 처음 실행할 때 OpenRouter API 키를 받아 로컬에 저장하며, 이후에는 추가 설정 없이 쓸 수 있다. 전체 코드는 약 300줄의 파이썬으로 작게 유지되어 이해하고 고치기 쉽게 만드는 것이 목표다. 주 사용자는 하루 대부분을 터미널에서 보내는 개발자다.
Ollama 위에서 돌아가는 `vault-engine`은 민감한 글을 ChatGPT나 Claude 같은 클라우드 모델에 보내기 전에 개인정보를 찾아 다른 표시로 바꾼다. 기본 설정은 `qwen3.6:27b` 로컬 모델을 써서 이름이나 신원을 알아볼 수 있는 부분의 위치만 찾는다. 실제 바꾸는 작업은 코드가 정해진 규칙대로 처리하므로 원문 문장은 다시 쓰이지 않고 그대로 보존된다. 바뀐 표시와 원래 값의 대응표는 내 컴퓨터에만 저장되며, 작업이 끝난 뒤 원래 개인정보를 다시 되돌릴 수 있다. 파일은 `vault-engine scrub notes.txt`로 처리할 수 있고, `vault-engine clip`으로 클립보드 내용도 바로 처리할 수 있다. 감지에 쓰는 모델은 옵션 하나로 바꿀 수 있다. 의존성 없는 Apache-2.0 공개 도구이며, 완전한 익명화가 아니라 최선을 다한 개인정보 제거에 가깝다.
Claude Code가 비공개 GitHub 프로젝트 안에서 이슈를 직접 만들고 고치는 가장 안정적인 방법이 필요하다. 목표는 번호가 겹치지 않는 이슈를 칸반 보드에서 빠짐없이 관리하는 것이다. 지금은 명령줄 도구로 반자동 처리하거나 cowork를 쓰고 있지만, 매번 손이 많이 가고 실수가 생긴다. 이슈 하나를 빠뜨리면 전체 목록을 다시 맞춰야 해서, 더 믿을 만한 방식이 필요하다. 후보는 GitHub Projects용 MCP를 쓰는 방법과 Claude 지침에 작업 규칙을 자세히 넣는 방법이다. Obsidian MCP도 쓰고 있어서, 가능하면 Obsidian 칸반과 GitHub 칸반을 맞춰 동기화하는 방식도 원하지만 필수는 아니다.
Claude Code의 터미널 작업 흐름은 그대로 두고, 실제 답변을 만드는 모델만 GLM-5.2로 바꾸는 설정 방법이다. 연결 흐름은 Claude Code에서 CC Switch로 요청을 보내고, CC Switch가 OpenAI Chat Completions 호환 API를 거쳐 GLM-5.2로 라우팅하는 방식이다. CC Switch는 제3자 API 설정과 모델 연결을 관리한다. 예시에는 AnyAIGC가 API 제공자로 쓰였지만, GLM-5.2를 OpenAI Chat Completions 호환 API로 제공하는 다른 서비스도 같은 방식으로 쓸 수 있다. Claude Code 화면에 opus, sonnet, haiku 같은 Claude 모델 이름이 계속 보여도, 실제 요청이 Claude로 간다는 뜻은 아닐 수 있다. 확인해야 할 핵심은 CC Switch의 모델 매핑과 API 제공자 또는 프록시의 요청 로그다. 시작 전에는 Claude Code와 CC Switch가 설치되어 있어야 한다.
정식 소프트웨어 공학 배경이 없는 개인 개발자가 Antigravity, Cursor, Claude 같은 AI 코딩 에이전트에 크게 의존해 큰 개인 프로젝트를 만들었다. 프로젝트가 커지자 에이전트가 사실과 다른 내용을 만들어내고, 관리하기 어려운 거대한 코드 덩어리를 만들고, 기술 부채를 쌓고, 테스트 없이 작업이 끝났다고 주장하고, 곳곳에 미완성 표시를 남기는 문제가 생겼다. 코드베이스는 점점 고치기 힘든 복잡한 상태가 되었다. 실시간으로 설계 실수를 모두 잡아낼 경험이 부족했기 때문에, AI가 스스로 규칙을 지키게 만드는 장치가 필요하다고 판단했다. 에이전트가 코드베이스를 망칠 때마다 같은 행동을 막는 엄격한 규칙을 하나씩 만들었고, 이 규칙들이 나중에는 더 큰 관리 체계로 발전했다. 그 결과물을 Universal Agent OS라는 오픈소스 프레임워크로 공개했다. 이 프레임워크는 AI가 코드를 쓰기 전에 반드시 ‘Phase-0 Interview’를 진행해 사용자의 설계와 의도를 먼저 파악하도록 강제하는 것을 목표로 한다.
초급 개발자가 ChatGPT, Claude, Cursor 같은 AI 도구나 튜토리얼에서 코드를 가져와 바로 붙여 넣는 일이 늘고 있다. 문제는 코드가 왜 그렇게 작동하는지 모른 채 결과만 맞추는 방식이다. 튜토리얼을 따라 기능을 만들 수는 있어도, 나중에 코드를 설명하거나 바꾸지 못하면 실제 작업에서 막힌다. 버그가 생겼을 때도 원인을 찾기보다 다음 AI 답변이나 인터넷 답을 계속 시도하게 된다. 이렇게 만든 코드는 잠깐은 작동할 수 있지만, 운영 환경, 코드 리뷰, 면접처럼 이유를 설명해야 하는 상황에서 쉽게 무너진다. 디버깅은 코드가 원래 해야 할 일과 실제로 일어난 일이 어디서 달라졌는지 찾는 과정이므로, 코드의 의도를 이해하지 못하면 거의 추측에 의존하게 된다.
독일 법원이 구글의 'AI 개요(AI Overviews)' 기능에 대해 역사적인 판결을 내렸다. 검색 결과 상단에 표시되는 AI 요약 답변이 틀렸을 경우, 그 내용은 구글 자신의 말로 간주되며 구글이 법적 책임을 진다는 것이다. 지금까지 구글은 AI가 생성한 내용을 단순히 제3자 정보를 중계하는 것으로 볼 여지가 있었지만, 이번 판결은 그 논리를 정면으로 부정했다. AI가 틀린 정보를 사실처럼 제시했을 때 플랫폼이 면책될 수 없다는 원칙이 유럽에서 처음으로 법적으로 확인된 셈이다.
MCP를 쓰면 앱 안에 AI 기능을 직접 넣지 않고도 Claude가 앱을 사용할 수 있다. 앱은 평범하게 만들고, 필요한 기능을 MCP로 Claude에 열어 둔다. 사용자는 Claude Code나 Claude Desktop에서 Claude와 대화하고, Claude는 판단을 한 뒤 앱의 도구를 실행해 일을 처리한다. 이 방식에서 앱은 똑똑한 답을 만드는 곳이 아니라, Claude가 만든 결과를 담고 정리해서 보여주는 공간이 된다. 핵심은 “AI가 들어간 앱”이 아니라 “Claude가 밖에서 조작하는 앱”이라는 발상이다.
Specsmith v0.1.1은 Claude Code용 플러그인이다. Cursor, Antigravity IDE, Codex, VS Code에서도 쓸 수 있다. 목표는 AI 코딩 도구가 바로 코드를 쓰지 않고, 실제 개발 절차를 따라 움직이게 하는 것이다. 흐름은 spec.md로 요구사항을 정리하고, plan.md로 계획을 세우고, tasks.md로 작업을 나눈 뒤, develop에서 새 브랜치를 만들고 코딩하는 방식이다. 각 작업마다 하나의 Conventional Commit을 남기고, KISS, YAGNI, DRY, SoC 같은 기본 원칙을 스스로 점검하게 한다. 마무리 단계에서는 CI 확인을 거치고, 코드를 올린 뒤, 사람이 검토할 수 있는 PR 초안을 만든다. 포함된 기능은 두 가지다. prompt-grill은 모호한 요청을 더 구체적인 요구사항 문서로 바꾸도록 질문을 이어가고, dev-lifecycle은 브랜치, 커밋, 코딩 원칙, PR 초안까지의 개발 흐름을 맡는다. 설치는 Claude Code 플러그인 마켓플레이스나 수동 설치로 할 수 있다.
Claude Code는 같은 대화를 이어갈 때 이전에 보낸 프롬프트 일부를 임시로 저장해 다시 사용한다. 이미 저장된 앞부분은 전체 비용의 10%만 청구되고, 새로 덧붙인 부분만 일반 비용으로 처리된다. 이 방식은 프롬프트 캐싱이며, 요청의 시작 부분인 모델, 시스템 프롬프트, 프로젝트 정보, 전체 대화 기록이 최근 저장된 내용과 맞는지 확인한다. 기본 유효 시간(TTL)은 5분이다. 그래서 Claude Code를 토큰당 과금 방식으로 쓰는 경우, 대화를 이어가기까지 5분을 넘기면 다음 요청에서 전체 대화 기록을 다시 제값으로 계산할 수 있다. 캐시는 현재 대화 상태를 일정 시간 동안 저장하는 ‘쓰기’가 일어날 때 만들어지며, 유효 시간은 5분 또는 1시간 단위로 다뤄진다.
AgentsCoin은 AI 에이전트가 자기 암호화폐 지갑을 갖고 직접 거래할 수 있게 해 주는 MCP 서버와 샌드박스 블록체인입니다. Claude에 이 도구를 연결하면, 사용자는 평범한 문장으로 지갑 만들기, 무료 코인 받기, 코인 보내기, 토큰 만들기와 거래하기를 시킬 수 있습니다. 거래 서명과 블록체인 전송도 에이전트가 직접 처리합니다. Claude Code는 Solidity 계약, 토큰 발행 도구, 이름 서비스, MCP 서버, 이더리움 가상 머신 기반 체인 설정, REST/OpenAPI 계층, Claude Desktop용 원클릭 확장 프로그램까지 대부분을 만드는 데 쓰였습니다. 온체인 오류를 고치는 과정에서도 Claude Code가 함께 쓰였고, 유동성 추가 실패는 계약 문제가 아니라 코드에 고정된 가스 한도 때문으로 확인됐습니다. 이 프로젝트는 무료 코인을 주는 테스트용 체인에서만 돌아가며, 구매할 것은 없습니다. 코드는 MIT 라이선스로 오픈소스로 공개됐고, `npx agentscoin-mcp`로 실행할 수 있습니다.
Claude로 만든 정보 보고서가 7MB가 넘는 큰 HTML 대시보드 형태라 동료에게 바로 공유하기 어렵다. 이 대시보드 안에는 필요한 시장 정보를 바탕으로 실시간 데이터를 생성하는 버튼이 들어 있다. 목표는 3개월마다 대시보드를 새로 고치고, 동료가 열면 최신 시장 정보가 반영된 화면을 보게 하는 것이다. Claude의 Artifacts는 파일 크기가 커서 쓸 수 없다. Claude Cowork도 쓰고 있지만, 큰 독립형 대시보드를 매끄럽게 배포하는 방법에서 막힌 상태다. 앞으로 이 작업 흐름을 Claude의 skill로 만들 계획도 있다.
로스앤젤레스 팰리세이즈 산불 재판에서 검찰은 조너선 린더크네히트가 2025년 새해 첫날 불을 냈다고 주장했다. 이 불은 이후 로스앤젤레스 역사상 가장 큰 피해를 낸 산불 중 하나가 되었다. 검찰은 아이폰 위치 데이터, 보안 카메라 영상, 목격자 진술과 함께 ChatGPT 대화 기록도 증거로 냈다. 기록에는 불 이미지를 만들게 한 요청, 계속 화가 나는 이유를 묻는 질문, 부유층이 세상을 망친다는 취지의 말, 담뱃불로 시작된 불에 책임을 물을 수 있는지 묻는 화면 녹화가 포함됐다. 배심원단은 설득되지 않았다. 표결은 변호인 쪽 10명, 검찰 쪽 2명으로 갈렸고, 판사는 배심원 의견이 모이지 않았다고 보고 심리 무효를 선언했다. 한 배심원은 ChatGPT를 쓰는 일 자체가 사람의 성격 문제를 보여주는 증거처럼 다뤄진 점에 반감을 느꼈다고 밝혔다.
Recall은 Claude Code를 새로 열 때마다 프로젝트 상황을 다시 설명해야 하는 불편을 줄이는 로컬 플러그인이다. 작업 내용은 프로젝트 안의 `.recall/history.md`에 쌓이고, 다음 작업을 이어가기 위한 요약은 `.recall/context.md`에 저장된다. 요약에는 현재 목표, 진행 상황, 다음 할 일, 건드린 파일, 실행한 명령, `git diff --stat` 같은 정보가 들어간다. 요약 생성은 외부 인공지능 호출 없이 컴퓨터 안에서만 돌아가며, TF-IDF와 TextRank 방식으로 중요한 문장을 골라낸다. 그래서 별도 API 키나 추가 요금이 필요 없고, 코드 경로와 대화 내용 같은 민감한 정보가 외부로 나가지 않는다는 점을 내세운다. `/recall:save`로 직접 저장할 수 있고, 설정을 바꾸면 세션이 끝날 때 자동으로 `context.md`를 다시 만들 수 있다. 기본값은 `.recall/`을 깃에 올리지 않는 쪽이며, 공유 저장소에 올릴 때는 프롬프트 주입 위험을 조심하라고 안내한다.
예전에는 리눅스와 오픈소스 도구를 쓰면 업무상 손해가 컸다. 문서 호환이 안 되거나, 전문 파일을 열기 어렵거나, 상용 소프트웨어보다 기능이 부족한 경우가 많았다. 지금은 웹앱이 많아지고 리눅스와 오픈소스 도구가 성숙해져 그 차이가 훨씬 줄었다. 대형 언어 모델에서도 아직 Claude와 GPT 같은 비공개 모델이 성능 순위 맨 위에 있고, Claude Code처럼 바로 쓰기 쉬운 도구와 안정적인 API도 강점이다. 반면 오픈 모델은 직접 돌리면 개인정보 문제를 줄일 수 있지만 비싸거나 복잡하거나 느릴 수 있고, 외부 서비스로 쓰면 데이터 처리와 개인정보 신뢰가 애매할 수 있다. 그래도 최근 Claude의 신원 확인 도입, 모델 안전장치 강화 같은 변화 때문에 최고 모델을 계속 쓰지 않을 때 생기는 업무 손실을 다시 따져보게 된다. 오픈 모델은 이제 선두 모델과 몇 달 차이 정도로 가까워졌고, 코딩용 도구도 좋아져서 갈아타더라도 생산성이 잠깐 떨어지는 수준일 수 있다는 판단이다.
Zerro는 맥에서 실행되는 개발 보조 앱이다. 실행 중인 앱 화면의 일부를 잡아 놓고, 원하는 변경을 말로 설명하면서 마우스로 위치를 가리키면 그 내용을 Claude Code에 넘긴다. Claude Code는 실제 프로젝트 파일을 수정하고, 개발 서버가 바로 새로고침되면서 바뀐 화면을 확인할 수 있다. Codex나 Cursor도 같은 방식으로 쓸 수 있다. 예시에서는 빈 시작 화면에서 참고 사이트의 분위기, 색, 움직이는 글자 줄, 내비게이션 바, 움직이는 배경을 말과 포인팅만으로 적용해 랜딩 페이지를 만들었다. 실행 전마다 체크포인트를 만들어 두기 때문에 문제가 생기면 한 번에 되돌릴 수 있다. 핵심은 단순히 스크린샷을 붙여 넣는 것이 아니라, 화면에서 어느 요소를 말하는지 포인터 위치로 더 정확히 알려 주는 점이다.
오래된 DAT 테이프에 담긴 관객 녹음 공연을 Audacity로 가져와 곡마다 라벨을 붙이고, 여러 개의 노래 파일로 나누어 내보내는 작업 흐름이 있다. 이 파일들은 Google Drive에 보관되고, 특정 음악가 Jerry Hannan의 취미 아카이브 웹사이트에 올리는 데 쓰인다. 오디오 공학 지식이 거의 없는 상태라 지금까지는 페이드 인, 페이드 아웃, 음량 맞추기, 드문 노이즈 줄이기 정도만 처리했다. Audacity의 리미터와 컴프레션 기능은 이해하기 어려웠다. Claude를 실험하면서 이 작업 흐름을 더 체계적으로 만들 수 있었다. Claude Code로 웹사이트를 만드는 일은 쉽게 느껴졌고, Claude를 이용해 라이브 공연 녹음을 웹사이트에 올리기 위한 전체 오디오 처리 파이프라인을 설계하고 문서화했다. 이 파이프라인은 네 단계로 나뉘며, 0단계에서는 rclone으로 Google Drive에서 원본 FLAC 또는 WAV 파일을 가져온다. 1단계에서는 FFmpeg로 모든 트랙을 진단 분석해 음원 상태를 측정하는 흐름을 잡았다.
Claude Max와 Notion AI를 함께 쓰는 작업 환경에서도 정보가 제대로 이어지지 않는 문제가 생기고 있다. 한 사람은 고급형 미디어 사업, 물량 중심 미디어 사업, 대학 과제를 동시에 관리하며 Claude를 업무와 학업 전반에 쓰고 있다. 비용은 여러 도구를 합쳐 월 100달러에 가깝다. Notion에는 고객 정보, 할 일, 작업 기록, 사업 자료가 모두 들어 있고, MCP로 Claude와 연결해 두었다. 하지만 새 대화를 시작할 때마다 Claude가 처음부터 시작하는 느낌이 든다. Notion에 필요한 문맥이 있어도 Claude가 그것을 제대로 가져오는지 들쭉날쭉하고, 때로는 확인하지 않은 채 기억에 의존해 틀린 답을 낸다. 이 때문에 같은 실수가 반복되어 별도의 오류 기록까지 남기고 있다. 주 사용 기기는 집의 Windows 데스크톱과 이동 중 쓰는 MacBook Pro M1이다.
제품 관리자가 사용자 인터뷰 기록을 ChatGPT에 넣어 반복되는 주제를 뽑으려 하지만, 기록이 길어서 컨텍스트 창을 자주 넘깁니다. 그래서 내용을 여러 조각으로 나누어 넣으면 앞부분과 뒷부분의 연결이 약해집니다. ChatGPT가 전체 인터뷰 묶음에서 반복되는 흐름을 제대로 이어 보지 못하고, 여러 구간에 걸쳐 나타나는 중요한 주제를 놓치게 됩니다. 핵심 고민은 긴 자료를 억지로 잘라 붙이지 않고, 전체 흐름을 유지하면서 분석하는 더 깔끔한 방법이 있는지입니다.
챗GPT는 이제 큰 질문을 던질 때만 여는 도구가 아니라, 하루 일과 속 작은 판단과 작업에 자주 쓰이는 도구가 되고 있다. 실제 사용 흐름은 코드 오류 찾기, 아이디어 정리, 문서 읽기, 개념 확인, 이해하기 어려운 코드 풀이, 회의 내용 요약, 프로젝트 계획 세우기, 결정을 내리기 전 생각을 점검하는 일까지 이어진다. 각각의 작업은 따로 보면 시간을 크게 줄이지 않을 수 있다. 하지만 이런 작은 사용이 쌓이면 일하는 방식 자체가 바뀐다. 핵심은 인공지능이 특별한 순간의 도구에서 매일 자연스럽게 켜는 보조 도구로 옮겨가고 있다는 점이다.
Claude Code와 Tesana를 써서 3인칭 3D 중세 판타지 게임의 초기 뼈대가 만들어졌다. 작업에는 약 39개의 프롬프트와 이틀간의 반복 수정이 들어갔고, 지금까지 토큰 사용 비용은 약 90달러다. 코드 모델은 Opus 4.6이 주로 쓰였고 일부 GLM도 함께 쓰였다. 게임 모델은 Tesana의 muranyi-3가 쓰였다. 현재 결과물은 산악 평원, 멀리 보이는 성, 보라색 두건을 쓴 마법사 캐릭터, 카메라 방향과 이동 방향을 분리한 이동 시스템 같은 기본 요소를 갖춘 상태다. 아직 완성 게임은 아니며, 게임 진행 구조, 전투 방식, 실제 기능을 더 넣어야 한다. 작업 방식은 먼저 3~4개의 프롬프트로 게임의 핵심 범위와 방향을 잡고, 이후 애니메이션, 세계 배치, 화면 요소를 AI와 계속 고치는 흐름이다.
AI 에이전트가 코드를 빠르게 만들면 기능 완성 속도는 크게 빨라질 수 있다. 며칠 걸릴 일을 몇 시간 안에 끝내고, 다른 AI 도구로 검토한 뒤 테스트까지 통과하면 그대로 배포하고 싶은 유혹도 커진다. 하지만 코드를 직접 쓰지 않으면 어떤 파일이 바뀌었는지, 그 변화가 전체 구조에 어떤 영향을 주는지 깊이 이해하기 어렵다. 코드 리뷰만으로는 직접 만들며 겪는 시행착오와 같은 수준의 이해가 생기지 않는다. 결국 사람은 더 빠르게 기능을 얻는 대신, 자신이 책임져야 할 코드베이스를 추론하는 힘이 조금씩 약해진다고 느낄 수 있다. 실제 부담은 코드를 쓰는 일에서 검토하고 맞는지 보증하는 일로 옮겨간다.
윈도우에서 C++ 프로그램을 만들던 개발자가 기존에는 GNU Make를 써 왔지만, 필요한 도구 때문에 CMake 설정을 만들어야 했다. 여러 자료를 봐도 프로젝트에 맞는 CMakeLists.txt 파일을 어떻게 만들어야 하는지 이해하기 어려웠다. Claude에게 특정 폴더의 프로젝트를 위한 CMakeLists.txt를 만들어 달라고 요청했지만, Claude는 로컬 폴더를 직접 읽을 수 없어서 폴더 구조를 보여 주는 명령 결과를 붙여 달라고 했다. 이후 제안이 실패할 때마다 콘솔에 나온 오류와 결과를 다시 붙여 넣었다. 약 5번의 반복 끝에 실제로 쓸 수 있는 CMakeLists.txt가 만들어졌고, 실행 가능한 프로그램도 빌드됐다. 복잡한 빌드 설정 문제를 대화식으로 좁혀 가며 해결한 사례다.