Javascript/Typescript 생태계에는 소스코드 간 의존관계를 유향그래프(Direct Graph)로 시각화하는 CLI 도구가 있다는 사실... 알고 계신가요? madge, 적극적으로 추천합니다.

그냥 JS/TS 프로젝트 뿐만이 아니라, jsx 파일이 들어간 경우도 의존관계를 아름답게 시각화해줍니다. fedify 소스코드 통독하면서 이걸 적극적으로 써볼까 합니다. 마치.... 탐정이 사건 추적하면서 지도에 X 표시하는 감성으로...

분명 회사일로 EC2에 도커 컨테이너 하나 띄우려 했는데 어느샌가 NixOS를 살펴 보고 있었다

hackers.pub 이라면 계실 것 같아서... 혹시 이 문제를 해결할 만한 천재데이터엔지니어 분이 계시다면 고견을 여쭙고 싶습니다... 블스 한국어 클러스터에 지금 러브휴먼들이 너무 많아서 일반 사용자들이 고생하고 있습니다 그나마 다행인 건 블스에는 사용자 리스트라는 기능이 있어서 저런 러브휴먼 계정들을 넣은 리스트를 블락 리스트로 공유하는데 아무래도 양이 양인지라... 프로그램을 짜서 긁어넣고 있어요 문제는 저런 중간자(?) 계정들이 자꾸 빨려 들어가곤 합니다 그렇다고 제가 직접 일일히 확인하기엔 제 시간과 정신력에도 한계가 있으니... 데이터를 기반으로 걸러내야하는데 어떤 알고리즘? 이 러브휴먼과 그냥 휴먼을 걸러내기 가장 좋을까요? 단순 키워드 정도만 던져주셔도 감사하겠습니다!

And just finished writing a comprehensive contributor guide for the #OSSCA mentees!

You can check it out here—it's Korean though: https://hackers.pub/@hongminhee/2025/ossca-fedify-contributors-guide.

It covers everything from setting up the #fediverse accounts and development environment to finding good first issues. While it's primarily for the OSSCA participants, anyone interested in contributing to @fedifyFedify: an ActivityPub server framework is welcome to use it as a reference.

Ready to onboard the next wave of #ActivityPub developers!

#Fedify #fedidev #opensource #mentoring

Fedify에도 지원했었는데 다른 프로젝트에 참여하게 되었습니다. Hackers' Pub에 Fedify에 넉 달 동안 깊게 빠져들 멘티분들이 많이 계신데, 언젠가 연이 닿았으면 좋겠습니다. 모두 화이팅입니다 🥰

@bglbgl gwyng Chants of Sennaar와 7 Days to End with You가 있습니다. 오픈월드는 아니고 언어를 이용한 퍼즐이 주가 되는 게임이긴 합니다. 언어를 좋아하신다면 추천합니다.

가자가자가자가자가자가자

ossca 결과 보니까 fedify 합격한듯?

@hongminhee洪 民憙 (Hong Minhee) @bglbgl gwyng 네넹 Nushell 내장 커맨드 및 플러그인들은 지정된 프로토콜에 따라 구조화된 데이터를 주고받고, 외부 커맨드(유저 바이너리들) 실행할 땐 stdin/out에 텍스트 형태로 주고받게 되는 건 맞는데 from 커맨드 써서 다시 Nushell 데이터타입으로 파싱할 수도 있습니다

@bglbgl gwyng 키보드에서 스페이스를 꾹 누르고 있으면 커서 이동 모드로 진입합니다.

2025년 7월 현 시점에,

• Node.js, Bun, Deno에서 모두 돌아가면서
• 서브테스트(테스트 단계)을 지원하거나
• before/after를 지원하는

JavaScript 단위 테스트 프레임워크가 없다는 게 사실이냐…

최근 한 달 동안 분석한 이슈의 결론이 물리 세계 때문이라는 결론이 나기 직전입니다. 측정값이 예상보다 오차가 훨씬 크게 날 수 있다 + 랜덤 생성기가 사실 충분히 랜덤이 아니었다의 환장의 콜라보... 모든 것이 예상 가능하게 돌아가는 컴퓨터 세상에서 살고 싶어요... 🤬🤬

상시 #블친소 #개발자_블친소 (개발자/프로그래머 버전) 대학교 탈출을 꿈꾸고 있는 학부생입니다. 아직은 취미(🥲)로 게임/웹 개발을 하고 있고 간단한 SVG를 다룰 수 있습니다(갑자기??). 🌐 eatch.dev 🐱 github.com/EatChangmyeong 📝 @blog.eatch.dev (이전 중) 🎈 solved.ac/profile/dlau... (💙₅ 2294, CLASS 6)

이제 2025년인데 에반게리온 CLI 프레임워크도 나올때 되지 않았음?

와하하 이거 ​​ 다!!!!

어제 튜링의 사과를 처음 구경했습니다. 귀인들 만나느라 이용은 안하고 구경만. 조금 과장해서 얘기하면, 다른 공유 오피스와는 다르게 PC방에 개발자 모인 것 같은 느낌이었습니다. 다른 오피스들처럼 조용하고, 조금은 생기 없는 풍경이 아니라, 상대적으로 소음도 좀 있고, 활기가 있어 보여 의외였습니다. 장소 오너분들도 개발자로 알고 있는데, 개발자 이해도가 높은 게, 영향이 있는 것 아닐까요?

(삶에 찌든 사람들 모인 PC방 말고, 젊은이들이 즐겁게 노는 모습의 PC방입니다.)

안녕하세요, SNS 프로젝트로 Jeju.social을 만들었습니다. 제주도의 친구, 가족, 기업들이 안전하게 사진과 정보를 공유할 수 있는 온라인 커뮤니티입니다. 외국인들과도 함께요. 즐거운 시간 보내세요.

Hello, I created Jeju.social as a social media project. It is an online community where friends, family, and businesses on Jeju Island can share photos and information safely. Even for foreigners. Please enjoy.

#introduction #제주 #제주도 #Jeju

내일(7월 1일) 개인 용무로 잠시 제주를 벗어나 서울에 이틀간 머물 예정인데요, 이날 5시 이후부터 여유 시간이 많아 만나서 이야기 나눌 분을 찾습니다.

자기소개 - 블로그 소개 및 Gravatar 프로필 참고

• 10여 년 전부터 웹 프로그래밍을 생산성과 취미로 즐겨하고 있는 컴퓨터 전공 4학년 학부생입니다.
• 이번 1학기에 졸업 요건을 대부분 만족하여 프런트엔드 개발 직군으로 구직 활동을 시작했습니다.

I'm currently experimenting with a poll creation feature for @botkitBotKit by Fedify . If this experiment pans out, the feature will likely be included in the next release, BotKit 0.3.0. So far, so good. Each vote will trigger a Bot.onVote event in real-time. This could open up a lot of interesting possibilities, like a bot that uses emoji selection for one-time authentication.

I think the @fedifyFedify: an ActivityPub server framework project has now reached full maturity. What this means is that all the low-hanging fruit has been addressed, and only the difficult problems remain. 😂

[[선언적 디자인과 디자인 런타임]] (@ak 著)

Javascript Weekly 뉴스레터에 @hongminhee洪 民憙 (Hong Minhee) 님의 Logtape가 소개되었습니다

드디어 스레드에서 연합우주 계정 팔로우가 된다... @alternative00__alternative 님 덕분에 알게된 사실...

요즘 함수 적용Apply에 꽂혀서, 처음 보는 프레임워크 코드들을 Apply 위주로 읽으니 그럴싸합니다. 그래서, Apply 생각 일부를 정리했습니다. 함수형 프로그래밍 언어도 익숙하지 않은 외국어와 비슷한 느낌이라, 코드들을 정확히는 몰라도 일단 통밥으로 읽는 방법을 계속 훈련 중입니다.

Apply - 이펙트가 있는 함수들을 연이어 적용하고 싶어
Apply - Price와 (exRate -> Price)를 다루는 프로그램의 골격을 똑같이 하고 싶어

해커스펍에 바로 올릴까 했는데, 읽어보니 조금 더 정돈하고 올리고 싶다는 생각이 들어, 개인 블로그에 먼저 올립니다.

@hongminhee洪 民憙 (Hong Minhee) @bglbgl gwyng 지나가다 관심 있는 주제가 보여 의견을 드려보아요. 사실 전문가가 전문성을 발휘하는 데에는 암묵지가 많아도 문제가 없는데, 전문성을 남에게 설명하거나 교육해야 할 때에는 어려움을 크게 높이는 요소가 됩니다. 그래서 홍님이 말씀하신 암묵지를 이끌어내는 전문가들은 인지 작업 분석(CTA) 같은 기법을 사용하기도 하는데요. bgl 님이 멘토링을 하고 계신다는 걸 보면 이미 어떤 식으로든 교육을 위해 암묵지를 많은 부분 명시지화 하셨을 것 같기도 해요. 물론 홍님 말대로 암묵지는 암묵지인 것일 수도 있겠지만요. 😅

gemini-cli 이것저것 만져보는 중인데, gemini-2.5-pro 의 코드 수정능력이 생각보다 괜찮아서 좀 더 써볼 것 같다. VSCode 의 Gemini Code Assist 보다는 만족감이 더 높다. 다만 이미지 분석 용도는 아닌 것 같고. 코딩 용도로 쓰면 괜찮을 것 같다.

새롭게 다시 태어난, 또 만들어버린 boilerplate. 이제는 진짜 monolithic 하고 Pocket Galaxy라는 이름에 걸맞는 boilerplate입니다.

Django + Vue(Vuetify) 조합이구요, nginx가 이것저것을 다 처리합니다.

백엔드는 /api에서 서빙하고, 기타 기본적인 static 캐싱이나 로깅 등 전부 기초적인건 제공합니다.

간단한 웹사이트 하나 만들겠다는게 어쩌다 여기까지 왔는지.... 암튼 이제는 진짜 최소한의 웹사이트 만들때 뚝딱 하면 만들수 있을것 같습니다 제발...

내부용 툴 만들때 애용해보세요.

https://github.com/theeluwin/pocket-galaxy

오픈소스 프로젝트에 여러분의 gemini cli(등등)의 무료 사용량을 기여하세요

오픈소스 소프트웨어라는 소프트웨어 개발 방법은 그동안 대성공을 거두어 오고 있습니다. 여기에는 여러 요인이 있지만, 중요한 요인 중 하나는 이것입니다. 상업 소프트웨어든 오픈소스 소프트웨어든 공평하게 프로그래머의 시간을 들인 만큼 개발된다는 것이지요. 능력 있는 소프트웨어 개발자가 시간을 기여하면 오픈소스 소프트웨어는 상업 소프트웨어만큼이나 빠르게 성장할 수 있었습니다.

하지만 AI 프로그래밍의 시대가 빠르게 다가오고 있습니다. 앞으로 소프트웨어 개발은 프로그래머의 시간만으로 개발되지 않습니다. 상업소프트웨어는 AI 프로그래밍을 적극적으로 사용하여 이전과 다른 생산성으로 개발되기 시작할 것입니다. 상업 소프트웨어와 달리 오픈소스 소프트웨어는 언제나 그럴 수는 없습니다. 프로젝트의 성장과 유지를 위해 훌륭한 프로그래머들의 시간을 들이는 것을 넘어서, 훌륭한 프로그래머들이 시간에 더해 비용까지 들여야 한다면요.

상업 소프트웨어와 오픈소스 소프트웨어 사이의 불균등한 생산성의 시대가 코앞까지 다가오고 있습니다.

새로운 기여자 확보의 문제

문제는 여기서 그치지 않습니다. 오픈소스 프로젝트는 새 기여자를 얻기 더 힘들어져가고 있습니다. 왜냐하면 이제 'good first issue'라는 것은 의미가 없기 때문입니다. 그 정도로 쉬운 일은 새로운 기여자 대신 로봇이 해결할 가능성이 높고, 그 로봇은 새로운 기여자의 로봇일 수도 있습니다. 결국 AI 프로그래밍으로 기여하는 새 기여자는 이 프로젝트에 대해 거의 배우지 못하게 됩니다.

전통적인 오픈소스 생태계에서 'good first issue'는 단순히 쉬운 문제를 해결하는 것이 아니었습니다. 새로운 기여자가 프로젝트의 코드베이스를 이해하고, 개발 프로세스를 익히며, 커뮤니티와 소통하는 법을 배우는 학습 과정이었습니다. 하지만 AI가 이런 단순한 작업들을 대신 처리하게 되면, 새로운 기여자들은 진입 기회를 잃게 됩니다.

AI 프로그래밍의 현재 위치

AI 프로그래밍은 완벽하지 않습니다. 숙련된 전문가가 숙련된 도메인에서 작업하는 것만큼 잘하지는 못합니다. 하지만 비숙련된 프로그래머가 처음 보는 프로젝트에서 작업하는 것보다는 잘할 때가 많습니다.

그러나 많은 오픈소스 소프트웨어는 바로 이런 비숙련 기여가 성장의 한 축을 차지합니다. 처음 프로젝트에 참여하는 개발자들의 작은 기여들이 모여 거대한 프로젝트가 됩니다. 그리고 이런 비숙련 기여의 일부는 손쉽게 AI가 대체할 수 있는 기여입니다.

다행히도 지금은 AI 프로그래밍의 초창기입니다. Gemini CLI가 무료 사용량을 제공하듯이, 앞으로 여러 회사들이 비슷한 기회를 제공할 것입니다. Claude, ChatGPT, Copilot 등 다양한 AI 도구들이 개인 사용자에게 무료 크레딧을 제공하고 있습니다.

이것은 오픈소스 프로젝트에 기여할 새로운 기회로 삼을 수 있을까요?

주의: 이 글은 아무 프로젝트에나 방문해서 AI로 적당한 코드를 생성한 다음 패치를 보내라는 뜻이 아닙니다.

AI 프로그래밍은 (아직은) 마법이 아닙니다. "이 프로젝트를 겁나 멋지게 만들 기능을 추가해주세요"라고 한다고 해서 그런 패치가 나오는 식으로는 동작하지 않습니다.

이상적인 경우: AI 친화적 프로젝트

가장 좋은 방법은 프로젝트가 AI 친화적으로 준비되는 것입니다. 바로 작업할 수 있을 만큼 잘 정의된 이슈들이 있는 프로젝트라면, "nnn 번 이슈에 대해 작업해 주세요"라는 요청만으로도 누구나 기여할 수 있을 것입니다.

하지만 (적어도 아직은) 그런 프로젝트가 많지는 않을 것입니다.

현실적인 접근: AI가 잘하는 일들에 집중

대신 AI는 인간과 비대칭적으로 잘하는 기능이 있습니다.

이를테면 이슈에 minimal reproducible case가 보고되어 있지만 아직 구체적으로 발생하는 원인이 밝혀져 있지 않은 경우를 생각해봅시다. 버그를 고치는 사람이 해야하는 지루한 작업 가운데 하나는, 이 문제를 어떻게 수정할지를 생각하기에 앞서 이 문제가 어디서 발생하는지 찾는 것입니다. 디버거를 써야 할 수도 있고, 코드에 많은 trace log를 남겨야 할 수도 있습니다.

하지만 AI 코딩 에이전트는 테스트가 재현 가능하기만 하다면, 문제를 발생시키는 정확한 줄을 찾아내는 데 탁월합니다. 지치지 않고 정석적인 지루한 방법으로 꾸준히 로그를 추가하고 테스트를 다시 실행하면서 문제를 찾아내거든요.

어쩌면 문제의 원인이 아주 단순해서, 문제를 바로 수정할 수 있을지도 모릅니다! 그렇다면 패치를 제출해도 좋겠지요. 하지만 바로 수정하기까지는 어렵더라도 괜찮습니다. 버그 리포트와 실제 코드의 문제를 매핑하는 것은 그 자체로 지루하고 시간이 걸리는 일입니다. 이것을 대신하는 것으로도 큰 작업을 대신하는 것입니다.

주의: 모든 프로젝트가 AI 기여를 환영할 리는 없습니다. 충분히 유용하게 다듬어지지 못한 유형의 AI 기여는 스팸처럼 느껴질 가능성이 있음을 유의해야 합니다.

미래

사실 누구나 자기 라이브러리를 뚝딱 만들어낼 수 있게 되었다는 점에서 오픈소스 프로젝트에 참여하는 사람들의 동기와 기여 방식 자체가 크게 뒤바뀔 가능성이 높습니다.

AI 프로그래밍을 누구나 거의 무료로 사용할 수 있는 시대가 올까요? 아마 어느 정도의 사용량까지는 그럴 것입니다. 그것이 얼마나 많은 양일지에 따라서 오픈소스 프로젝트의 미래는 크게 바뀌겠지요.

만일 정말로 AI 프로그래밍을 누구나 무제한적으로 사용할 수 있다면, 대규모가 아닌 대부분의 오픈소스 프로젝트에는 더이상 협력이 필요하지 않을 것입니다. 진정으로 '어떻게'보다 '무엇을'이 더 중요한 시대가 온다면, 프로젝트의 목표를 확고하게 가진 사람이 극한의 완성도까지 프로젝트를 밀어붙이는 편이 훨씬 좋은 결과를 만들겠지요.

그런 시대가 올지 오지 않을지 모르겠습니다. 하지만 그 전까지는, AI 프로그래밍이 누구에게나 주어지는 기회이지만 프로젝트를 단숨에 완성할만큼 주어지지는 않는 시대가 유지되는 동안에는, 다음 세대의 오픈소스 기여의 방법은 AI 프로그래밍 사용량을 기여하는 것이 하나의 큰 축이 될 것입니다.

클플 뭐 서비스 낼때마다 리전 맨날 Earth 요따구로 해두니까 우주진출 뒤의 클플을 상상하게 됨

Gemini CLI 공개 됐네. 어떠려나…

부트캠프의 함정, 오버엔지니어링 https://subokim.wordpress.com/2025/06/20/overengineering/

리액트 작업하면 vs code 탭 두 개 한 화면에 브라우저 한 화면에 디자인 전달받아서 하면 figma나 시안 확인용 화면 하나에 모니터 세 개쯤은 있어야 하던데 노트북만 들고 카페에서 코딩하는 건 어떤 종류의 작업일까….

해커스 펍은 아무래도 어텐션이 낮다 보니 채용 시장 이야기를 조금 해 보자면 (트위터는 왠지 채용 과정에서 아쉬운 경험을 하신 분들도 있을 것 같고, 해서) 새로운 프론트엔드 개발자분이 곧 합류하시는데 채용까지 이르는 데 까지 정말 많은 이력서 스크리닝을 해야 했다. 솔직히 말해 '옛날에 비하면' 뛰어난 개발자분들이 시장에 많은데 (공개적으로 이야기하기는 뭐한) 특정한 스타일의 비슷한 개발자분들이 아주 많다. 괜찮은 사람을 아무나 빨리 뽑는 채용 기조는 아니다 보니 정말 특출나게 뭔가 뛰어난 부분이 있는 분을 찾아야 한다는 압박감이 있었고, 이것때문에 좀 힘들었다.

블로그 글로도 적어봤습니다. 재현 환경 구성 하는거 너무 노가다인데 어떻게 잘 할까..

https://moreal.hashnode.dev/vitepress-localsearch-debugging

오늘의 코딩은 합정역 근처에 위치한 카페 콤파일에서 했습니다!
해커스펍의 개발자 분들이 좋아하실 것 같은 노트북하기 좋은 카페에요

#콤파일 #코딩하기좋은카페

@oilpaintingkim 고민되시겠어요. 음… 결국 본인 성향과 어떤 걸 하고 싶으시냐에 따라 다를 것 같은데, 자기 주도적이신 편이라면 첫번째 회사가 좋을 것 같고요. 누군가 가르쳐 주는 사람한테 배우는 걸 좋아하시면 두번째 회사가 좋을 것 같아요.

안녕하세요 이번에 신입 개발자 취업에 성공하게 되었는데 두 회사중에서 고민중입니다.

두 곳 모두 프론트엔드 직무고, 최종 합격은 했는데 방향이 너무 달라서 글 올려봅니다!

1. 웹페이지 제작 전문 회사 (정규직)

• 고용 형태: 정규직 (풀타임)
• 기술 스택: PHP 기반의 오픈소스 콘텐츠 관리 시스템(CMS) + JS/TS
• 업무 내용: 홈페이지 리뉴얼 및 내부 시스템 개발 등
• 장점
  • 제가 기술 도입을 주도할 수 있는 환경인듯 합니다
  • 프론트엔드 개발의 모든 범위를 직접 경험 가능
• 단점
  • 레거시 기반 스택 중심
  • 최신 기술 도입은 가능하나, 대부분 혼자 해결해야 할 수도 있음 (사수 없습니다!)

2. 어느 정도 규모 있는 보안쪽 IT 자회사 (인턴)

• 고용 형태: 인턴 (하루 5시간, 약 4개월)
• 기술 스택: React
• 업무 내용: 보안 관련 웹 페이지 개발 일부 참여
• 장점
  • React 기반의 실무 경험
  • 체계적이고 안정적인 조직 문화 기대
• 단점
  • 실무 범위가 제한적일 수 있음
  • 인턴 기간 이후엔 다시 취업 준비를 해야 함 (정규직 전환 없습니다!)

많은 의견 주시면 감사드리겠습니다!

Arstechnica 에서 이런 글을 보았습니다.

A history of the Internet, part 2: The high-tech gold rush begins

제가 이것저것의 역사에 대하여 흥미가 많다는 말을 여기에 쓴 적이 있던가요? 게임이라거나 컴퓨팅이라거나 ...

사실 대강의 사연을 알고있던 저 2편보다는, 제가 모르던 사연이 더 많은 1편 An Ars Technica history of the Internet, part 1이 더욱 흥미로웠습니다.

그 와중에 글을 쓰는 방식과 디테일들이 마음에 들어서 글쓴사람을 클릭해보니 와우' -' 보물창고가 쨘 하고 나타나는 것이었습니다.

일단 처음에 눈에 띄여서 이 시리즈를 읽었습니다. 재미있었어요.

• A history of ARM, part 1: Building the first chip
• A history of ARM, part 2: Everything starts to come together
• A history of ARM, part 3: Coming full circle

그래서 ARM의 원래 이름은 Acorn RISC Machine. 도토리 RISC 머신이었던 것입니다 ' -' ...

다음에는 Amiga 의 역사를 읽어볼 생각이에요. 두근두근.

Just learned of a self-hostable ticketing software called Pretix: https://pretix.eu/

It looks extremely full-featured.

미국의 이란 폭격 작전 Midnight Hammer를 "자정의 망치"로 번역했지만 정황을 고려했을 때 "아닌 밤중의 홍두깨"가 더 어울린다.

It's pretty unfortunate that NodeJS still doesn't have Fetch API based servers included while still being the most used JS runtime. This justifies server side libraries keep promoting Express usage by default on docs, which is not good considering that it's a NodeJS specific one.

Windows NT라는 이름은 David Cutler의 말장난에서 비롯되었다고 한다. 그가 DEC에서 일할 적에 만든 운영체제가 VMS인데, Microsoft로 옮긴 뒤에 VMS를 계승한다는 의미에서 VMS의 각 알파벳을 한 글자씩 뒤로 미룬^[1] WNT를 코드네임으로 썼던 것.

소프트웨어 엔지니어링 가이드북 저자 게르겔리 오로스, 켄트백 둘다 페디버스 계정 있는걸 사이먼 윌라이슨 계정을 통해 알았다..... 페디버스에서 네임드 개발자 찾으라면 있긴 있는데, 사혼의 구슬 찾는듯한 이 묘한 기분

기분 좋은 일. 작업실에 밥 주는 성격 좋고 조심성 있는 고양이가 있는데 이 친구가 동네 최약체라 다른 큰언니한테 맨날 맞고 밥도 뺏기며 마주치면 도망가고 숨어다녔단 말임. 사실 양쪽 다 밥 주고 싶은데 큰언니는 자기가 우리를 다 차지하고 싶어서인지 최약체를 쫓아내려고 해서 맘에 안들었음. 그래서 최약체 전용 밥을 실내에서 따로 주기 시작했는데 최약체도 좀 컸고 또 건강상태가 좋아져서인지는 몰라도 이제 이전처럼 큰언니와 대면할 때 그냥 도망치지 않고 거리를 둔 채 위협하며 대면하는 단계까지 갔다. 오늘은 그 위협에 무서운 큰언니가 아주 천천히 시야 밖으로 사라졌고 그걸 보는데 너무 대견하게 느껴짐. 잘했어 최약체야.

번아웃으로 아직 고생하는 가운데, 갑자기 삘이 와서 지난 1주간 170쪽짜리 소설을 Gemini로 써 버렸다. 소재가 너무 잔혹해서 (R-18G 수준) 그대로 공개하기에는 꺼려진다는 문제가 있을 뿐; 줄거리 자체는 내가 예상한 것 이상으로 잘 나왔는데 퇴고를 열심히 해서 그런 것 같다. 구체적으로 어떻게 된 거냐 하면,

1. Gemini 2.5 Flash로 짧은 초안 작성 (1판)
2. 이 초안의 중간 즈음에서 두 개의 새 줄거리를 만들어서 전체 줄거리 수가 3개가 됨
3. 이대로는 안되겠다 싶어서 Flash의 제안을 일부 받아 들여 줄거리를 하나로 재조정 (2판)
4. 이 시점에서 Gemini 2.5 Pro한테 평가를 부탁하고, 평가 내용을 다시 Flash에게 되먹여서 액션 아이템을 만들어 퇴고를 반복 (3~7판)
5. 이 참에 번역도 맡겨야지 싶어서 Flash한테 먼저 초벌 번역을 시킴 (번역 1판)
6. 초벌 번역을 Pro한테 주고 고쳐야 하는 부분을 그 이유와 함께 나열하게 함
7. Flash한테 수정된 번역과 수정한 이유들을 주고 판단하게 시킨 다음 최종 번역본을 완성 (번역 2판)
8. 마지막으로 Pro한테 전체 번역문을 주고 전체 번역 안에서의 일관성이 깨진 게 있는지 확인

이랬는데, 가장 곤란했던 건 역시 4였다. 왜냐하면 내용이 너무 길어서 텍스트 창에는 한 번에 안 들어가고(...), 잘라서 넣으면 이제 뭔 짓을 해도 앞부분을 까먹어 버렸기 때문이다. 최종적으로 동작한 방법은 소설을 최대 32KB 크기가 되도록 쪼갠 뒤 파일로 나눠어 업로드하고, 업로드가 끝난 뒤에 몇장까지 있는지 확인하고 뒤가 잘린 문장이 있는지 확인해서 뭔가 문제가 있으면 평가를 하지 않고 멈추라고 지시한 것. 혹시 이런 일 해야 하는 분은 참고하시길.

...뭐 이렇게 말하긴 했는데 사실 Flash한테 글 쓰기는 다 맡겼지만 세부적으로는 상당히 손을 많이 거쳤다. 한국어나 영어 번역이나 둘 다 그랬음. 나름 노력한 것도 있고 이 전체 내용을 다시 Flash한테 되먹였더니 찬사 일색(!!!!!)이라 진짠가 싶어서 어디 올려야 할 것 같긴 한데 소재가 소재다 보니 공개도 간단하지 않다는 게 곤란하다. 호옥시 관심 있으신 분께서는 메일로 pdf 파일을 보내 드리겠습니다.