신규하 블로그

개발 기록 보관소

Markdown이 나빠서가 아니다. AI가 너무 강해져서 Markdown이 더 이상 안 맞는다는 이야기다. Threads의 @alex_ai_mcp 가 공유한 짧은 포스트에서 단단한 한 줄을 뽑아낼 수 있다. “문서를 생성하는 것” → “인터페이스를 생성하는 것” 예전엔 AI가 10줄 요약, 20줄 메모를 써 줬다. 지금은 한 번에 1000줄짜리 기획서, 전체 코드 리뷰, 복잡한 플로우차트, 실행 가능한 툴 UI까지 만든다. 이걸 전부 Markdown으로 받으면 결국 끝없는 텍스트 벽 이 된다 — 심지어 Claude 엔지니어조차 100줄 넘는 AI 생성 MD 파일은 끝까지 안 읽는다고 한다. 그래서 작업 방식이 바뀌고 있다. AI가 만들고 사람은 조작한다. 더보기

생성형 미디어 도구는 보통 각각 따로 쓴다. 이미지는 이미지 생성 툴 영상은 영상 생성 툴 립싱크는 또 다른 서비스 워크플로 자동화는 별도 노드 에디터 로컬 모델은 또 다른 실행기 Open Generative AI가 흥미로운 이유는 이 조각들을 하나의 스튜디오로 묶으려 하기 때문이다. 단순히 “AI 이미지 생성 웹앱”이 아니라, 이미지·영상·립싱크·시네마·워크플로·로컬 추론을 한 화면에서 다루려는 오픈소스 미디어 생성 작업대에 가깝다. 더보기

코딩 에이전트의 결과물 차이는 모델 성능이 아니라 요구사항을 얼마나 명확하게 넘겼는가 에서 갈린다. 영상은 여기서 한 발 더 들어간다. “명확한 프롬프트가 중요하다"는 이미 다 알고 있는 이야기이고, 진짜 문제는 나도 내가 뭘 원하는지 모른다는 것 이다. 그래서 발상을 뒤집는다. 내가 명확한 프롬프트를 만들려 애쓰는 대신, AI가 나에게 역으로 질문하게 만든다. 이게 “딥 인터뷰” 스킬의 출발점이다. 그리고 발화자는 이렇게 단언한다. Plan Mode 전에 먼저 이 스킬부터 써야 한다. 더보기

AI 코딩 에이전트는 늘 같은 약점을 드러낸다. 어제 실패한 실수를 오늘 다시 반복하고 지난 실행에서 확인한 레포 규칙을 또 잊고 이미 겪은 verifier 실패를 매번 새로 추론한다 그래서 문제는 “컨텍스트를 더 많이 넣을까?”가 아니다. 진짜 문제는 긴 문맥에서 다음 실행에 재사용할 규칙을 어떻게 뽑아낼까다. Moonshot Notes의 이번 글이 흥미로운 이유는 바로 이 지점을 Ctx2Skill 논문과 연결하기 때문이다. 핵심은 문맥을 더 길게 주는 것이 아니라, 문맥에서 규칙과 절차를 추출해 Repo Skill Memory로 바꾸는 것이다. 더보기

Pi는 요즘 코딩 에이전트들 가운데서 조금 이상한 위치에 있다. 더 많은 기능으로 주목받는 게 아니라, 오히려 기능을 덜 넣어서 주목받고 있기 때문이다. 이 영상이 흥미로운 이유도 여기에 있다. 핵심 메시지는 “Pi가 Claude Code나 OpenCode보다 기능이 많다”가 아니다. 오히려 반대다. 작은 하네스에 필요한 것만 붙여 쓰는 방식이 실제로 더 조용하고 오래 가는 작업 흐름을 만든다는 주장이다. 더보기

AI 에이전트에서 memory는 가장 쉽게 과장되는 기능 중 하나다. 모든 대화와 실패를 다 기억시키면 더 똑똑해질 것 같지만, 실제로는 반대일 때가 많다. 오래된 가정과 일회성 실패가 다음 작업을 오염시키기 때문이다. 그래서 중요한 건 “많은 기억”이 아니라 실패는 먼저 Run Ledger에 남기고, 반복 가능하고 검증된 사실만 Memory로 승격하는 절차다. 더보기