아프니까 개발자다 아프니까 개발자다

코드 위키 도구들이 다이어그램을 많이 쓴다는 얘기는 이전 글에서 했다. "얼마나 많이?"에 답해 본 적은 없었다. 그래서 직접 세 보았다.2026-05 기준 deepwiki.com/facebook/react 위키는 sub-page 34개로 구성되어 있고 그 안에 mermaid 다이어그램 115개가 들어가 있다(페이지당 평균 약 3.4개). expressjs/express 위키는 32 페이지에 221개(페이지당 평균 약 6.9개). DeepWiki는 SPA 방식이라 한 URL에 위키 전체 페이로드가 같이 실려 오는데, 그 페이로드를 그대로 grep해서 ```mermaid 블록을 센 결과다.한 위키 전체에 다이어그램 100~200개라는 게 처음엔 비현실적으로 들리지만, 큰 코드 베이스를 설명할 때 흔한 분량..

코드 위키 AI 도구들이 GitHub repo를 받아서 위키를 자동 생성할 때, 거의 공통으로 다음 8개 섹션을 만든다.Overview · Structure · Architecture · API · Subsystems · Operations · Testing · Glossary.처음 보면 그냥 목차처럼 보이지만, 사실 이 8섹션은 "코드를 처음 보는 사람이 어디서부터 봐야 하는가"라는 질문에 대한 누적된 답이다. 위키나 docs 폴더가 흔히 자유 형식인데, 이 셋업은 읽는 사람의 경로를 미리 설계해 둔 것이다. 그리고 이 구조는 사람뿐 아니라 AI 에이전트가 코드를 이해하는 데도 결정적인 도움이 된다. 이 글은 8섹션을 하나씩 풀어 — 무엇이고 왜 거기 있고 어떤 효과가 있는지 — 설명한다.왜 굳이 8개..

2024년 4월에 Cognition Labs(같은 회사의 AI 소프트웨어 엔지니어 Devin으로 유명한)가 deepwiki.com을 공개했다. GitHub repo URL 앞에 prefix만 붙이면 LLM이 자동 생성한 위키가 떠오르는 서비스이다. 곧 커뮤니티에서 deepwiki-open이 self-host 버전을 들고 등장했고, 2025년 11월에는 Google이 codewiki.google로 비슷한 영역에 들어왔다.세 도구는 첫인상이 거의 똑같다. "GitHub repo 던지면 LLM이 8섹션짜리 위키 만들어 줌"이라는 한 줄 컨셉. 그런데 막상 깊이 보면 누가 만들었고, 어디서 돌고, 어떤 LLM을 어떻게 쓰는지가 완전히 다르다. 이 글은 그 세 가지를 정직하게 비교하는 글이다 — 어느 게 "더 좋..

영상 한 편을 만들면서 의외로 어려웠던 게 자막이었다. BytePlus Seedance 2.0 Fast로 클립을 19개 만들고 ffmpeg로 합본하는 데까지는 비교적 정리된 길이 있었는데, 어린이가 직접 녹음한 한국어 음성 위에 자막을 ffmpeg burn-in하는 단계에서 문제가 생겼다. 첫 시도는 자막을 클립 길이로 단순히 등분해 보여주는 거였다. "한 호흡 한 줄" 원칙이면 N등분이 어느 정도는 맞을 거라고 가정한 거다. 결과는 듣는 단어와 보이는 자막이 1초씩 어긋나는 영상이었다.다음 시도는 Whisper로 음성을 word-level로 받아 자막 줄과 직접 매칭하는 거였다. 이것도 안 됐다. 한국어 ASR이 발화를 항상 똑같이 적어주지 않는다. 사용자가 "복도에서"라고 말해도 Whisper는 "복..

🔧 이 글은 BytePlus Seedance 2.0 fast로 만든 영상을 ffmpeg로 후처리하는 사용자를 위한 글입니다. "재생성 vs 후처리" 비용 비교는 API paid 호출을 직접 다루는 환경에서 가장 명확하게 의미가 있습니다. ModelArk 콘솔로 한 편씩 만드는 분이라면 재생성 비용이 다르게 다가오지만, adelay 후처리 자체는 어떤 환경에서 만든 mp4에도 동일하게 적용 가능합니다."시작!"을 외치는데 손동작이 늦다탐정 컨셉으로 노는 아이가 "시작!"을 외치며 한 손을 sharp하게 뻗는 클립을 Seedance로 만들었습니다. 결과를 받아 들어 보니 묘하게 어긋나 있었습니다.음성 "시작!"이 먼저 나오고, 1.3초쯤 뒤에야 손이 뻗습니다. 마치 누군가 외친 다음 한 박자 늦게 동작하는..

🔧 이 글은 BytePlus Seedance 2.0 fast로 만든 영상 클립들을 ffmpeg로 자동 합본하는 사용자를 위한 글입니다. Seedance가 클립마다 다른 audio spec(mono/stereo)을 출력해서 발생하는 시나리오라 AI 영상 자동화 환경에서 특히 자주 만나지만, 함정 자체와 해결책은 heterogeneous mp4를 다루는 모든 영상 파이프라인에 적용됩니다.멀티 stream을 다루다 보면 만나는 두 함정영상 후처리 파이프라인을 만들다 보면 ffmpeg의 멀티 stream 다루기에서 거의 모든 사람이 한 번씩은 빠지는 두 함정이 있습니다.mux 함정: 영상과 음성을 합치려고 -shortest 플래그를 썼더니 영상까지 잘려나간다.concat 함정: 여러 클립을 합치려고 -c co..

🔧 이 글은 BytePlus Seedance 2.0 fast로 만든 영상을 ffmpeg로 후처리하다 만난 함정이지만, 일반 ffmpeg 사용자에게도 그대로 적용됩니다. AI 영상 자동화든, 일반 영상 편집이든 비슷한 sub-second 정확도 문제를 겪고 있다면 해결책이 같습니다."stream copy 빠르고 무손실이니까 무조건 -c copy" 라는 습관ffmpeg에서 영상의 앞부분만 자르고 싶을 때 가장 흔히 보이는 패턴은 이겁니다.ffmpeg -ss 0.5 -i input.mp4 -c copy output.mp4직역하면 "0.5초부터 시작해서 끝까지를, 스트림은 복사만 해서 새 파일로 저장". -c copy는 디코딩·인코딩 과정을 건너뛰는 stream copy 모드라 빠르고 무손실입니다. 깔끔하죠...

🔧 이 글은 BytePlus Seedance 2.0 fast로 만든 영상을 자동 파이프라인에서 후처리하는 사용자를 위한 글입니다. photo prefix 현상은 ModelArk 콘솔에서 만든 결과물에도 그대로 나타나지만, 후처리 자동 trim 코드는 여러 클립을 일괄 처리하는 API 자동화 환경에서 가장 가치가 있습니다. 단발 영상이라면 콘솔의 트림 UI를 쓰는 게 편할 수 있어요."왜 첫 0.5초는 멈춰 있는 것 같지?"BytePlus Seedance 2.0 fast로 만든 클립을 한 편 한 편 다듬다가, 시청자 입장에서 자꾸 같은 위화감이 느껴졌습니다. 영상이 시작하자마자 인물이 자연스럽게 움직이는 게 아니라, 첫 반 초쯤은 사진처럼 정지되어 있다가 그 뒤에 motion이 시작됩니다. 한 클립만 그..