오랫동안 이 사이트에 정말 블로그가 필요한지조차 확신하지 못했다.
나는 이미 업무 시간 대부분을 문제 해결에 사용한다. 어떤 것은 평범한 frontend나 backend 작업이다. 어떤 것은 이미지 인코딩, 브라우저 동작, SEO 실험, 인프라 장애, AI-assisted development, 미디어 처리처럼 훨씬 좁은 주제로 들어간다. 단순한 질문에서 시작한 production 문제가 며칠짜리 조사로 바뀌기도 한다.
그 뒤에 다시 수천 단어를 쓰는 일은 불필요하게 느껴질 수 있다.
누가 읽을까?
나는 여기서 무엇을 얻을까?
문제만 해결하고 다음으로 넘어가면 되지 않을까?
결국 나에게는 충분한 답을 찾았다. 이런 작업 중 일부는 그냥 버리기에는 너무 많은 비용이 들어간다.
어려운 문제 안에는 내가 깨닫기 전부터 하나의 글 전체가 들어 있을 수 있다
내 글은 보통 “이번 주에 블로그 글을 하나 써야겠다”는 생각으로 시작하지 않는다.
문제로 시작한다.
업무에서 나오기도 하고, 개인 프로젝트에서 나오기도 한다. 이해하지 못하는 무언가가 궁금해져서 훨씬 잘 이해할 때까지 파고들기도 한다.
이미지 처리는 나를 그런 깊은 조사로 여러 번 끌고 갔다.
처음에는 일이 거의 우스울 정도로 단순해 보일 수 있다.
이 이미지들의 용량을 줄여 줘.
AI 모델에게 script를 요청하면 거의 바로 하나를 받을 수 있다.
그렇다고 좋은 image-processing pipeline이 생긴 것은 아니다.
첫 버전은 JPEG, PNG, WebP, animated content의 차이를 무시할 수 있다. 모든 파일에 같은 quality 값을 적용하거나, 불필요하게 이미지를 upscale하거나, transparency를 잘못 처리할 수 있다. 지우고 싶은 metadata를 남기거나 보존해야 할 metadata를 파괴할 수도 있다. 시각적 손상을 측정하지 않은 채 파일 크기만 최적화할 수도 있다. 테스트 파일 10개에서는 완벽하게 동작하지만 훨씬 큰 규모에서는 매우 비싼 실수가 될 수도 있다.
script가 성공적으로 실행되는 것과 내가 신뢰하는 system인 것은 다르다.
내 글의 상당수는 바로 이 차이에서 시작된다.
내 AI workflow는 “ChatGPT에게 답을 물어보는 것”보다 훨씬 느리다
이런 문제를 다룰 때 나는 유료 ChatGPT 계정을 많이 사용한다.
하나의 대화가 며칠이나 몇 주 동안 계속될 수 있다. 질문하고, 제안을 테스트하고, 결과를 다시 넣고, 가정을 의심하고, 코드를 살펴보고, 또 다른 edge case를 찾고, 구현을 바꾸고, 다시 실행하고, 결과를 비교한 뒤 반복한다.
특히 깊은 조사에서는 같은 큰 문제를 중심으로 100시간이 넘는 작업이 쌓인 적도 있다.
그렇다고 내가 100시간 동안 AI 모델이 마법처럼 답을 발견하기를 기다린다는 뜻은 아니다.
과정은 반복적이다.
보통은 이런 흐름에 가깝다.
- 문제를 설명한다.
- 모델이 초기 해결책을 제안한다.
- 실제 데이터에서 실행한다.
- 약하거나 비효율적이거나 그냥 틀린 부분이 나온다.
- 그 증거를 다시 대화에 넣는다.
- 접근 방식을 바꾼다.
- 다시 테스트한다.
- 다른 edge case가 나온다.
- 반복한다.
이 사이클은 여러 번 이어질 수 있다.
유용한 결과는 첫 script가 아니라 그 주변에 쌓인 실패, 측정, 수정, 판단의 집합인 경우가 많다.
AI는 시작점을 만드는 비용을 낮췄지만 검증 비용까지 낮추지는 않았다
AI가 쓴 기술 콘텐츠에 대한 흔한 논의가 지나치게 단순하다고 느끼는 이유 중 하나다.
물론 AI 모델은 그럴듯한 tutorial을 매우 빠르게 만들 수 있다.
동시에 완전히 합리적으로 보이지만 바로 중요한 상황에서 틀리는 코드를 만들 수도 있다.
좁은 기술 문제에서는 첫 번째 그럴듯한 답이 필요한 경우가 거의 없다. 실제로 실행했을 때 무슨 일이 일어나는지가 궁금하다.
이미지 pipeline을 만든다면 output 크기와 시각적 품질을 확인하고 싶다. 서로 다른 source format에서 어떤 일이 생기는지도 보고 싶다. 특이한 dimensions, alpha, animation, 손상된 input을 테스트하고 싶다. 구현이 어떤 가정을 하고 있는지도 이해하고 싶다.
script가 결국 거대한 컬렉션을 처리해야 한다면 이런 작업은 더 중요해진다.
이미지 1,000만 장은 의도적으로 극단적인 예시이며 내 특정 dataset의 크기를 주장하는 것이 아니다. 하지만 문제를 잘 보여 준다. 아주 작은 systematic mistake도 1,000만 번 반복되면 더 이상 작은 실수가 아니다.
코드 생성 비용은 크게 떨어졌다.
그 코드를 대규모로 실행할 가치가 있는지 판단하는 비용은 그렇지 않다.
채팅은 연구 자료이지 완성된 글이 아니다
이런 긴 조사가 끝나면 채팅 기록에는 엄청난 양의 정보가 남을 수 있다.
예를 들면 다음과 같다.
- 실패한 접근 방식;
- 나중에 교체된 코드;
- 유용한 benchmark 결과;
- log;
- 오해;
- 수정;
- 모호한 동작에 대한 설명;
- 대안 비교;
- 처음에는 생각하지 못했던 edge case;
- 그리고 마지막에 신뢰하게 된 규칙.
이 모든 것을 하나의 비공개 대화 안에만 두는 것은 아깝게 느껴진다.
그래서 유용한 부분을 뽑아 글로 만든다.
글은 대화 transcript가 아니다. 대화 대부분은 애초에 글이 되어서는 안 된다.
유용한 기술 글에는 한 단계가 더 필요하다. 아무것도 가르쳐 주지 않는 막다른 길은 버리고, 중요한 것을 설명해 주는 실패는 남기고, 주장을 확인하고, 시간 순서를 재구성하고, 관찰과 설명을 분리하고, 최종 결과를 다른 개발자가 실제로 사용할 수 있는 형태로 바꿔야 한다.
이 편집 단계가 중요하다.
AI가 여기에 참여할 수는 있지만, 증거는 여전히 실제 작업에서 나온다.
이미지 처리는 “단순한” 문제가 얼마나 깊어질 수 있는지 보여 줬다
내 작업에서 가장 분명한 예는 아마 이미지 최적화다.
처음에는 encoder 설정 모음처럼 보였지만 충분히 오래 다루다 보니 점점 훨씬 큰 system problem으로 변했다.
질문은 빠르게 늘어난다.
어떤 source format을 다루는가?
animated인가?
dimensions를 바꿔야 하는가?
quality는 어떻게 고를 것인가?
quality loss가 허용 가능한지 어떤 metric으로 판단할 것인가?
서로 완전히 다른 이미지에 하나의 quality threshold가 통하는가?
upscaling을 어떻게 막을 것인가?
어떤 metadata를 남길 것인가?
transparency는 어떻게 할 것인가?
output은 어떻게 validate할 것인가?
작아진 파일 크기가 추가 encoding cost를 정말 정당화하는가?
input population이 바뀌면 어떻게 되는가?
그래서 나는 다섯 줄짜리 “궁극의 이미지 최적화” script를 경계한다.
그런 script도 이미지를 처리할 수는 있다.
하지만 trade-off를 이해하고 있는 pipeline을 만드는 것과는 다르다.
현재 내가 다루는 image-heavy workload에서는 AVIF를 보통 가장 먼저 검토한다. 이것은 내가 작업하는 프로젝트 유형에서 나온 규칙이지, 세상의 모든 웹사이트가 내일 모든 오래된 format을 없애야 한다는 주장이 아니다. 호환성 요구사항, source material, latency, encoder cost, delivery architecture에 따라 답은 달라질 수 있다.
중요한 것은 한 format을 승자로 선언하는 일이 아니다.
의식적으로 결정할 수 있을 만큼 workload를 이해하는 일이다.
video processing도 같은 깊이까지 파고들고 싶다. 아직 거기까지 가지는 못했다. 이런 주제가 재미있는 이유도 그것이다. 한 문제의 바닥까지 왔다고 생각할 때마다 또 다른 층이 나타난다.
그러다 일본 사이트가 블로그를 발견했다
이 글들을 공개하면서 특별한 대가를 기대하지는 않았다.
이 블로그에서 의미 있는 금전적 수익이 나오는 것도 아니다. 과정 자체가 재미있고, 유용한 작업을 오래된 채팅과 터미널 기록 속에 사라지게 하기보다 남겨 두고 싶어서 계속한다.
그러다 정말 예상하지 못한 일이 생겼다.
2026년 9월 17일, 일본 사이트 Levtech Freelance가 대략 “성장 의욕이 높은 엔지니어에게 추천하는 스킬 향상 블로그”에 해당하는 글을 공개했다.
Levtech Freelance의 해당 글에는 여러 엔지니어링 블로그와 함께 JSVar도 포함되어 있었다.
Levtech는 일본의 큰 IT 커리어 생태계의 일부이며, Levtech Freelance는 프리랜서 IT 엔지니어를 지원하고 프로젝트와 연결하는 데 초점을 둔다. 나에게 흥미로웠던 것은 단순히 backlink 하나를 얻었다는 사실이 아니었다. 외부 편집팀이 내 작업의 어떤 부분을 소개할 가치가 있다고 판단했는지 보는 것이 더 흥미로웠다.
JSVar 소개에서는 특히 세 개의 글을 언급했다.
하나는 production development에서 Codex와 TypeScript가 잘 맞는다고 느낀 이유에 관한 글이었다. TypeScript의 type과 compiler feedback이 generated code의 문제를 일찍 드러내는 데 도움이 된다는 내용이었다.
또 하나는 ChatGPT로 블로그를 20개 언어로 번역하고, 여러 나라의 검색 방문자가 각 localized page로 직접 들어오는 변화를 본 경험을 다뤘다.
세 번째는 AI-generated SEO page 10,000개를 공개한 실험으로, 결국 쉬운 성장보다 실패에 관한 이야기가 되었다.
서로 매우 다른 세 글이지만 모두 같은 패턴을 가지고 있다는 점이 재미있었다.
모두 내가 실제로 해 본 일을 바탕으로 썼다.
Levtech가 정확히 어떻게 나를 찾았는지는 모른다
여기에는 아주 그럴듯한 이야기를 만들 수 있다.
나는 일본어를 하지 못한다.
내 사이트에는 일본어 버전이 있다.
일본의 엔지니어링 매체가 사이트를 찾았다.
그러므로 블로그를 일본어로 번역했기 때문에 Levtech가 발견했다.
하지만 그건 증명할 수 없다.
일본어 페이지가 도움을 줬을 수도 있다.
검색을 통해 영어 글을 찾았을 수도 있다.
누군가 링크를 공유했을 수도 있다.
완전히 다른 경로로 사이트에 왔을 수도 있다.
그 attribution data는 가지고 있지 않다. 그래서 이를 근거로 깔끔한 SEO case study를 만들어 내고 싶지는 않다.
확인할 수 있는 사실은 훨씬 단순하다. 나는 블로그를 여러 언어로 공개했고, 이후 일본 매체가 편집 기사에 포함할 만큼 흥미롭다고 판단했다.
그 자체로 이미 좋은 결과다.
특히 localization도 처음에는 많은 노력에 비해 결과가 불확실해 보였던 실험이었기 때문에 더 만족스럽다.
이 소개는 독립적인 검증이라는 점에서 의미가 있었다
여기서 “검증”이라는 말은 Levtech가 내가 쓴 모든 내용을 정확하다고 증명했다는 뜻이 아니다.
그들이 내 codebase를 audit하거나 모든 실험을 재현한 것도 아니다.
중요했던 것은 더 소박한 부분이다.
세계 반대편에서, 내가 직접 그 언어로 다가갈 수 없는 독자를 위해 글을 쓰는 사람이 내 작업에서 독자에게 소개할 만큼의 가치를 발견했다.
내가 먼저 제안한 것도 아니다.
원래 글을 Levtech를 위해 쓴 것도 아니다.
일본 기사에 등장할 것이라고 기대하지도 않았다.
그래서 이 결과가 나에게 의미가 있다.
매우 좁은 주제의 기술 글도 공개할 가치가 있으려면 반드시 거대한 독자가 필요한 것은 아니라는 생각이 든다.
올바른 독자에게 유용하면 된다.
2026년에 개발자가 블로그를 시작해야 할까?
내 답은 그렇다. 다만 중요한 조건이 하나 있다.
실제로 무언가를 기록하고 싶어야 한다.
누군가 “모든 개발자에게 personal brand가 필요하다”고 말했다는 이유만으로 기술 블로그를 시작하라고 권하고 싶지는 않다.
passive income을 기대하며 시작하지도 않을 것이다.
이미 더 좋은 공식 문서가 있는 기술에 대한 일반론으로 채우기 위해 블로그를 만들지도 않을 것이다.
하지만 업무를 하면서 “처음 시작했을 때 내가 이런 걸 찾을 수 있었으면 좋았을 텐데” 싶은 것이 계속 생긴다면 이야기는 달라진다.
그걸 쓰면 된다.
이상한 production failure를 쓴다.
예상보다 3일 더 걸린 최적화를 쓴다.
내 가정을 뒤집은 benchmark를 쓴다.
우아해 보였지만 실패한 접근 방식을 쓴다.
최종 구현을 쓰되, 왜 당연해 보이는 구현으로는 충분하지 않았는지도 설명한다.
그런 내용은 일반적인 지식만으로 만들기 어렵다.
AI는 쓸 거리를 줄이지 않고 오히려 늘려 준다
AI 때문에 기술 블로그가 쓸모없어졌다고 생각하게 된 것은 아니다.
내 경우에는 거의 반대다.
초기 구현이나 설명을 얻는 속도가 빨라져 더 많은 아이디어를 조사할 수 있게 됐다.
하지만 iteration이 빨라지면 evidence도 더 많이 생긴다. 더 많은 variant, log, benchmark, 실패한 시도, 확인해야 할 것들이 생긴다.
그 raw material은 무엇이 사실이고 무엇이 중요한지 누군가 판단하는 작업을 해야 비로소 가치가 생긴다.
500개의 메시지가 있는 AI 대화가 자동으로 지식이 되는 것은 아니다.
실제 테스트를 끝내 통과한 script와, 통과하지 못한 20개 버전에 대한 설명은 지식이 될 수 있다.
내가 블로그에 남기고 싶은 것은 그 차이다.
공개하는 것은 유용한 작업이 사라지지 않게 만드는 방법이다
대부분의 기술 작업은 놀랄 만큼 일시적이다.
어려운 bug를 고친다.
터미널을 닫는다.
deployment가 성공한다.
채팅은 기록 아래쪽으로 밀려난다.
6개월 뒤에는 최종 구현이 왜 그런 모양인지 나조차 기억하지 못할 수 있다.
글을 쓰면 달라진다.
증거가 아직 남아 있을 때 reasoning을 다시 구성하게 된다.
검색할 수 있는 형태가 된다.
미래의 내 작업에서도 다시 참고할 수 있다.
그리고 가끔은 전혀 예상하지 못한 사람에게 닿는다. 이번처럼 내가 말하지 못하는 언어의 엔지니어링 매체에 닿을 수도 있다.
지금도 이 블로그를 유지하는 데 거창한 이유는 없다.
배우는 것이 좋다.
무언가 만드는 것이 좋다.
처음에는 간단해 보였던 문제를 지나치게 깊게 파고드는 것이 좋다.
그리고 쓸 만한 답 하나를 얻기 위해 수십 시간, 때로는 100시간 넘게 썼다면 그 답이 채팅창 안에서 사라지게 두고 싶지 않다.
나에게는 그것만으로 공개할 충분한 이유가 된다.
당신의 일에서도 같은 종류의 어렵게 얻은 지식이 만들어진다면, 그것은 당신에게도 충분한 이유가 될 수 있다고 생각한다.