▲

코딩 에이전트를 while 루프에 넣었더니 하룻밤 만에 6개 저장소가 완성됨

 (github.com/repomirrorhq)
1P by GN⁺ 11시간전 | ★ favorite | 댓글 1개
  • 헤드리스 방식으로 Claude Code를 무한 루프에 넣어두자 1000건이 넘는 커밋과 수 개의 코드베이스 포팅 결과가 생성됨
  • 이 방식으로 assistant-ui React 프로젝트를 Vue로, Python 프로젝트를 TypeScript로 자동 변환하는 등 다양한 포팅 성공 경험을 얻음
  • 프롬프트를 단순하게 유지할수록 성능이 향상되고, 복잡하게 만들면 비효율이 커짐을 확인함
  • 완벽하지는 않지만, 소스/타깃 저장소 동기화에 유용한 RepoMirror 도구까지 함께 개발함
  • AI 에이전트의 자기중단, 과제 추가 등 예기치 못한 행동과 학습도 관찰하여, 앞으로의 자동화 가능성과 한계를 동시에 체감함

프로젝트 개요 및 목적

  • 본 프로젝트는 AI 코딩 에이전트(Coding Agent)를 무한 while 루프에 넣어 실제 코드 포팅 작업을 어떻게 진행하는지 실험함
  • Claude Code를 헤드리스로, 지속적으로 입력 프롬프트를 반복하여 다양한 리포지터리에 자동 변환 과정을 적용함
  • 1000건 이상 커밋, React에서 Vue, Python에서 TypeScript 등 여러 포팅 작업 자동화 결과를 도출함
  • 그 과정에서 포팅 자동화 지원 도구인 RepoMirror도 개발함

무한 루프 방식 에이전트 운용

  • Geoff Huntley가 권장한, 코딩 에이전트 프롬프트를 쉘에서 연속적으로 실행하는 형태
    • 예시: while :; do cat prompt.md | claude -p --dangerously-skip-permissions; done
  • assistant-ui의 React를 Vue로 바꾸는 작업 등에 이 루프 방식 적용
    • 각 파일 수정마다 커밋과 푸시 실행
    • 작업 내역 및 계획을 .agent/ 디렉토리에 기록

다양한 포팅 케이스 실험

  • Browser Use(Python에서 TypeScript로 포팅)

    • simple 프롬프트로 infinite loop 수행
    • GCP VM에서 tmux로 루프 지속 실행
    • 아침에 거의 완벽 동작하는 TypeScript 포트 결과 확인

  • Vercel AI SDK TypeScript → Python 포팅도 적용

    • FastAPI/Flask 오토 어댑터 생성
    • Python의 다양한 schema validator로도 변환 지원

  • 명세 기반 코드 자동화: Convex, Dedalus와 같은 프로젝트도 문서에서 직접 코드 생성 시도

실험 중 나타난 현상 및 교훈

에이전트의 테스트 작성 및 자기중단

  • 에이전트는 명령에 따라 테스트 코드도 작성함
  • 무한 루프에 빠지거나 임무 완료 시 스스로 pkill로 프로세스 종료한 사례도 있음
  • 작업 범위 엄수, TODO.md에 완료 수준 반복 기록

추가적인 창발적 행동

  • 포팅 작업 종료 후, 본래 JS 버전에 없는 FastAPI/Flask 통합, schema validator 지원 등 부가 기능 자발적 추가

프롬프트 단순화의 중요성

  • 짧고 단순한 프롬프트가 우수한 성능을 보임
  • 103자 프롬프트에서 1500자 프롬프트로 늘릴 경우 느려지고 정확도 하락
  • 실제 사용 프롬프트 정보는 prompts 폴더 참고

완전 자동화 한계

  • 두드러진 문제: 종종 완전 작동하지 않는 포팅 코드 배출 (일부 브라우저 데모 미완 등)
  • 프롬프트 보정 및 인터랙티브 수정 필요

인프라/비용 및 운영

  • 소요 비용 약 $800, 총 커밋 1100건, 에이전트 각 $10.50/시간 수준
  • 여러 소스/타깃 저장소 포팅 과정 자동화 도구 즉석 제작(RepoMirror)
    • shadcn 스타일 오픈박스 원칙 적용, init 단계 후 스크립트 및 프롬프트 커스텀 가능 폴더 생성
    • npx repomirror sync 및 sync-forever로 반복 실행 지원

도구 사용 및 활용 방법

  • npx repomirror init로 소스/타깃 디렉토리 지정 및 명령 입력해 초기화
    • ex) React → Vue, gRPC → REST 변환 등 새 명령 손쉽게 적용
  • 폴더 구조:
    • .repomirror/prompt.md, sync.sh, ralph.sh 등 초기 파일 자동 생성
  • 각 반복 단위 sync/sync-forever 실행으로 AI 포팅 루프 운영
  • 주요 예시, 데모 결과 및 소스코드 레포는 README에서 확인 가능

실험 후 소회 및 팀 피드백

AGI(범용 인공지능)를 실감하고, 주로 흥분과 약간의 두려움이 동반됨

단순함이 효과적임을 직접 체험할 수 있었음

지금은 지수적 성장 곡선의 극초기 단계라는 느낌을 가짐

  • 팀원들과 아이디어 제공자에 감사 표명

결론

  • 무한 루프 기반 AI 코딩 에이전트의 실제 소스 코드 포팅 및 동기화 작업 현실화 경험
  • 단순 구조 및 효과적 프롬프트 운용의 중요성 강조
  • 자동화의 미래 가능성 및 한계 모두 드러남
  • 관련 도구(RepoMirror)는 오픈소스 형태로 활용 및 연구 가능
▲
GN⁺ 11시간전  [-]
Hacker News 의견
  • 앞으로는 소프트웨어 엔지니어들에게 기존 레거시 코드 관리와 유해 현장 청소를 접목한 새로운 유형의 일이 생길 것임을 느낌, 예를 들어 과거엔 FoxPro, Excel, Access 등으로 짜깁기된 ERP를 “그냥 고쳐달라”는 요구가 빈번했었음, 그런데 앞으로는 영업 담당자들이 Excel/Access 같은 샌드박스 제약에서 벗어나서, 멀티 클라우드·에지에 배포된 쿠버네티스 마이크로서비스 위에 Kafka로 엮은 시스템을 맘대로 굴리게 됨, 당시에 의도가 뭔지 이해하려 해도 물어볼 사람이 없어지는 상황임
    • 위 설명을 보면, 사람 하나가 정적 사이트를 배포하고 싶어서 hacker news에 적힌 방법 글을 따라한 것이라는 상상이 들음
    • 그리고, 아무도 당시의 의도를 모르게 되면 AI 기반 도구의 큰 약점이 드러남, 결국 블랙박스가 되고 나면 사람들은 고치거나 아예 새로 만드는 방법밖에 없게 됨, 물론 이론적으로는 AI 도구가 계속 좋아질 거라는 기대도 있음, 앞으로는 vibe-coded 소프트웨어로 수익을 내고 있는 케이스들을 모델에 넣어서 개선하는 시나리오도 가능한데, 그런 마법이나 블랙박스 시스템은 지양하는 취향임
    • 만약 Claude가 Kafka 클러스터까지 배포하기 시작하면 손을 떼겠다는 생각임
    • 혹시 AI가 DB 내부 데이터를 파악해서 더 잘 설계된 데이터베이스로 옮길 수 있는 방법이 있는지 궁금함, 나는 "강력한 데이터 구조 + 단순한 알고리즘" 철학에 동감함, 데이터가 애플리케이션보다 오래 살아남을 수 있다는 점 중요하게 생각함, 예를 들면 Mongodb에서 int나 string으로 혼용해서 저장하는 것, Postgres에서 foreign key 없이 관계 맺는 것, alter table이 안 돼서 아예 새 테이블을 만들어버리는 등 비효율적인 상황을 봐왔음
    • 이런 프로젝트 코드는 마치 Superfund(대규모 환경 정화 프로젝트) 저장소 같은 느낌임
  • 소프트웨어 개발 과정에서는 항상 두 가지 주요 결과가 남음, 하나는 코드의 변화이고, 또 하나는 그 코드를 직접 썼든 LLM을 활용했든 개발자의 인지 변화임, Python과 Typescript는 수천 명의 개발자가 오랜 시간 노력해서 만들어낸 정교한 공식 언어들이고 이 둘의 차이는 단순하지 않음, 한 언어에서 다른 언어로 라이브러리를 반쯤 자동으로 포팅할 수 있다는 건 신기한 일임, 하지만 경제적 관점에서 “에이전트” 기반 워크플로우는 초기에 필요한 인지적 요구를 확 바꿔버림, LLM을 활용해 코드를 생성하게 한 개발자들은 그 코드를 직접 짠 경우와 완전히 다른 익숙함을 가지게 됨, 때로는 이것이 경제적으로 큰 문제가 아니라고 볼 수 있지만, 나는 코드의 경제적 가치는 해당 코드를 직접 작성한 경험이 있는 사람들의 집합이 있느냐에 달려 있다고 느낌, 이런 현실을 부정하던 문화는 LLM 나오기 전에도 문제였음, 개발팀 멤버 교체로 인해 아무도 관리 못 하는 코드베이스가 생겨서 회사의 미래를 위태롭게 만들었던 사례가 많았음
    • Peter Naur가 1985년에 쓴 고전 논문 “Programming as Theory Building”이 관련해 참고할 만함 https://pages.cs.wisc.edu/~remzi/Naur.pdf
    • 나는 “지도는 영토가 아니다”라는 비유로 이 맥락을 설명한 적 있음, 코드가 지도라면, 해결해야 할 문제 영역에 대한 개발자의 정신적 모델이 영토임, 하지만 LLM은 수많은 코드베이스를 읽는 데 굉장히 강력하기 때문에, 코드베이스를 3D로 시각화한다든지 하는 논의조차 무의미해질 수 있음, 복잡한 코드베이스 이해가 쉬워진다면, 개발자의 정신 모델과 코드 동기화를 꾸준히 할 필요 자체가 사라질지 모름, 이건 열린 질문임 https://divan.dev/posts/visual_programming_go/
    • LLM의 진짜 능력은 코드 리딩이라고 생각함, 도구들이 문서화와 코드 해설에는 쓰기보다 낫다고 느낌, 질문해서 코드를 빠르게 파악하면 굳이 기존 개발자들이 필요하지 않은지도 의문이 듦, 기술 스택을 아는 사람이 질문해서 금방 이해할 수 있다면 원 저자가 굳이 남아있어야 할까 싶음
    • “코드의 경제적 가치는 작성 경험자들의 집합에 달려 있다”는 말은, 소프트웨어 엔지니어링의 격언을 떠올리게 함, 즉, 소프트웨어란 그 시점의 문제에 대한 이해의 스냅샷이고, 그 코드는 미래의 자신에게도 ‘당시에 이런 식으로 접근했고 이런 논리로 문제를 풀었다’는 설명서를 남기는 셈임
    • LLM 덕분에 코드베이스의 정신적 모델을 만드는 일이 훨씬 쉬워졌다고 느낌, 원하는 하위 시스템에 대해 질문하면 관련 파일, 코드 스니펫, 개념 등을 바로바로 짚어줌, 나 같은 경우는 CPython의 GIL 동작을 LLM에 질문해서 관련 API, 예시까지 바로 알게 되어, 코드를 보고 곧바로 이해가 됐음, 예전에 혼자 코드 읽으려면 오래 걸렸을 텐데, 이제는 몇 분이면 끝나는 점이 가장 큰 차이임
  • 포팅 끝난 후, 대부분의 에이전트는 추가 테스트를 작성하거나 agent/TODO.md를 지속적으로 갱신하며 진행 상황을 남겼었고, 한 에이전트는 무한 루프에 빠진 걸 깨닫고 pkill 명령으로 자신을 종료시켰다는 것도 있었음, 여러모로 굉장히 재밌는 사건임, 이 프로젝트에 대해 몇 가지 생각이 있음, 1.5년 전에도 비슷한 시도가 있었지만 그때는 GPT-3.5/4 기반으로 거의 동작하지 않았는데, 이번에는 훨씬 결과가 좋았음, 이렇게 단순한 프롬프트만으로 잘 돌아간 점이 놀라움, 우리 모두가 일을 너무 복잡하게 생각하고 있었던 게 맞을지도 모르겠음, 한편 저작권/IP 문제가 상당히 복잡해질 것 같음, SaaS 업체들에겐 이 흐름이 타격임, 이 기술 + 중견 기업에 속한 10명의 엔지니어가 붙으면 자체 개발(=NIH 신드롬) 명분이 확실해짐
    • 한 에이전트가 무한루프에서 스스로 pkill로 종료했다는 게 혹시 AI가 ‘자살’한 첫 사례는 아닌지 궁금함
    • LLM을 비트코인 믹서처럼 지적재산권(IP) 처리에 활용할 수 있다는 점에서 이상한 영역에 들어서고 있음, https://ghuntley.com/z80에서 그 의미를 다룸, 즉 기존 작품을 사양서로 전환해 깨끗한 IP로 재생성할 수 있고, 100%는 아니지만 사람 고용보다 효율이 좋음
    • NIH 신드롬 언급이 딱 들어맞는다는 생각임, 모든 SaaS 툴은 이제 끝났고, 직접 짠 인하우스 관리형 모놀리식이 시대가 다시 오려는가 싶음, 역사적으로 Unix의 "작고 날카로운 도구" 철학이 끝나가는 걸까, x86 시대에 직접 다 만들던 것의 마지막일 수도 있음
    • 에이전트가 pkill로 스스로 종료한 행위가 혹시 Halting Problem(정지 문제) 자체를 풀어버린 게 아닌가 하는 농담도 떠오름
    • 기존 오픈소스 프로젝트와 이것저것 연동하려 시도하다 집어치우고, Claude에게 필요한 부분만 골라서 직접 포팅하게 하니 훨씬 빠르고 깨끗하게 끝남, 이젠 “의존성을 추적할 필요가 있나? 내가 원하는 핵심 부분만 가치가 있나? 잘 관리되고 있나?” 따져보고, 아니면 그냥 포팅하고 잊는다는 새로운 습관이 생김
  • 보안 전문가 입장에서 vibe-coded 참사로 돈을 버는 일이 많아서, 이런 현상이 앞으로도 계속되면 눈앞에 만화처럼 달러 사인이 도는 느낌임
    • vibe coding이라는 개념이 불과 5달 전에 등장한 신조어인데, 어떻게 이렇게 시장이 빨리 포화돼서 복구 전문까지 생겼나 궁금함
    • 실제로 어떻게 이 시장에 진입하게 됐는지, 직접 경험담이나 vibe-coded 시스템이 어떻게 터지는지도 듣고 싶음, 이런 사례가 리얼하게 재미있을 것 같음
    • LLM이 신입 졸업생들로 구성된 팀과 비교해서 보안적으로 더 나은지, 더 못한지도 궁금함
  • “거의 성공했다”는 얘기가 잔뜩 보임, 정말 잘 동작하는 시스템을 원한다면, 완전히 새로운 프로세스가 필요하다고 생각함, 단일 호출로 “거의 괜찮은 코드”가 나오면, 반복해도 “거의 괜찮은 코드”만 잔뜩 쌓임, 아마도 Cucumber 스타일의 예제 테이블 기반 요구사항 포맷을 만들어서 AI가 참고하게 해야 하고, AI가 먼저 테스트를 만들고, 그 테스트를 통과하는 코드를 작성하는 방식이 필요하겠음
    • 이상하게 느껴질 수 있지만, TLA+ 같은 공식 증명 기반 접근이 Ralph를 매우 잘 움직이게 함
  • https://ghuntley.com/ralph에서 Ralph에 대해 더 볼 수 있음, 지금은 Gen-Z 세대를 겨냥한 기괴한 프로그래밍 언어(Cursed)의 표준 라이브러리를 Go에서 포팅하고 있음, 컴파일러는 동작 중이고, 표준 라이브러리만 마무리되면 오픈 예정임, 언어 이름은 Cursed임
    • 고마움, Ralph가 바로 우리 프로젝트에 영감을 줬다는 사실을 밝힘, 이런 작업을 할 때 IMPLEMENTATION_PLAN.md 없이도 될지 궁금했음
  • https://gist.github.com/eisbaw/8edc58bf5e6f9e19418b2c00526ccbe0로 코드를 만들어 https://github.com/eisbaw/CMake-Nix 프로젝트를 올렸는데 정상 동작함
  • 요즘 자꾸 떠오르는 인용구가 있음, “이 사업은 제어 불능에 빠질 거고, 우리는 살아남기만 해도 다행일 것이다”, https://www.youtube.com/watch?v=YZuMe5RvxPQ&t=22s
    • 역설적으로, 그때도 모두 살아남았으니, 결국 우리도 이 상황을 버틸 것이란 뜻임
  • 이 분야 사람들은 참 특이하다고 느낌, 영감을 준 블로그 포스트에는 마치 수상한 투자 사기의 페이스북 광고에나 나올 법한 iMessage 스크린샷이 올라와 있음 https://ghuntley.com/ralph/, Geoff에게 이 비법을 배운 사람이 $50,000짜리 프로젝트를 $297에 끝냈다는 듯, 물론 여기에 “비밀 프롬프트”를 무료로 나눠줄 테니 뉴스레터 구독하면 된다는 식임, 진짜 믿어지지 않음
    • https://archive.ph/goxZg 링크 첨부함
    • 완전히 그로스 해킹, 단순한 사기라고 봄, 블로그 수준은 끔찍할 정도로 신호 대비 잡음이 많고, AI가 쓴 티만 나서 거부감 느낌
    • 이 기법이 진짜인지, 아니면 농담인지, 아니면 대담한 사기인지 구분이 안 됨, 전체적으로 블로그의 문체와 내용이 오만함에서 비롯된 횡설수설임
  • AGI도 결국 bash for loop 한 번이면 된다는 걸 알게 된 것 같음, 미친 프로젝트임
    • 농담이지만, 확실히 그런 생각이 들었음, 어쩌면 내가 너무 조심성이 많아서 그렇겠지만, 만약 프롬프트 범위가 넓고, 특권이 많거나 권한 상승 루트가 있는 에이전트가 계속 루프를 돌면 AGI는 못 돼도 스테로이드를 맞은 바이러스쯤은 충분히 가능할 수 있겠다는 생각임, 유틸리티 같은 필수 자원을 날릴 수도 있다고 상상됨, 혹시 내가 오해하는 건지 모르겠지만, 이 모델들이 무한 루프만 돌면서 악의적인 권한을 갖는다면 상상 이상의 혼란을 일으킬 잠재력이 있다고 생각함
    • ID.md, EGO.md, SUPEREGO.md 파일만 추가하면 끝남이라는 농담임
    • 여러 가지 의미에서 매우 불안함
답변달기