글을 좀 더 자세하게 읽고 왔는데 뭔가 이곳저곳이 억지스러워서 광고처럼 느껴지는 글이네요.
특히 마지막 녹음기 부분이 여러 매체에서 보이던데 단순한 녹음기임에도 엄청난 가격으로 명품 마케팅을 하고 있네요..
"스마트폰 녹음기를 사용하는 방식은 생각에서 녹음까지 너무 많은 단계를 거쳐야 함. 원하는 동작은 버튼을 누르는 동안 음성을 녹음하고, 놓으면 저장하는 정도로 단순함. 일부 스마트폰에 이런 기능이 있지만 AI 기능으로 포장되고 있으며, 데이터가 다른 곳으로 전송될 가능성이 있다고 봄."
이것이 문제라고 생각하시는 분들은 이미 배포되는 수많은 오픈 소스 녹음기 앱을 사용하시거나 간단하게 구현하실 수 있고 전원 버튼 두 번 클릭 등의 제스처에 할당하셔서 사용하시면 됩니다. 상당히 억지스러운 부분이네요.
그냥 비싸지만 이쁩니다. 이쁜거 좋아하면 사세요. 라고 사실대로 말해도 되는 것을 굳이 가짜 문제를 만들고 해결하고 있네요.
사실 중국이 승리하는 것보다는 나을 뿐 미국이 승리한다고 해서 한국 포함 전세계적으로 정말 좋은 일인가는 굳이 최근 정치적인 상황 등을 따지지 않더라도 의문스러운 일이지만
샘 알트먼 자신은 미국이 승리하는 게 좋겠죠. 본인도 미국인이고 여러 미국 기업의 주식을 보유했으니까요.
이메일 열람용 도구를 분리해서 이메일만 확인하고 절대 손도 뻗지 않겠다 라는 목표를 세우고 달성할 수 있는 사람이라면 스마트폰에서 이메일만 확인하고 끄겠다는 목표도 달성할 수 있을 것입니다.
집중의 분산은 거의 습관의 문제입니다. 지쳤을 때 하던 것을 놓지도 않고 다른 것을 보고자 하는 충동을 제어하지 못하고 왔다갔다 하는거죠.
뭔가에 확실하고 길게 몰입하여 집중하고 지칠 때 확실히 끊고 쉬어버리는 습관을 만들어야 합니다.
물론 알림 등 현대 여러 매체들이 집중을 빼앗으려고 고의적으로 설계되었다는 점을 무시하지는 않겠습니다만 설정으로 어느 정도 해결할 수 있는 문제입니다. 덜 중요한 알림은 무음으로 하고 잠금화면에서도 숨기세요.
기본적으로 사용자에게 적대적인 아이폰에서도 되는지는 잘 모르겠지만요.
3번(에이전트 간 책임 분리)이 제일 어려운 부분 같습니다. 공개 벤치마크 트레이스를 좀 들여다본 적이 있는데, 거기서 본 패턴 하나 공유드립니다.
가장 흔했던 건 "잘못된 결정"보다 같은 작업이 두 번 실행되는 것이었습니다. 같은 인자로 이메일 발송이 반복되거나, 같은 파일이 다시 쓰이거나. 특히 타임아웃 후 재시도 구간에서 자주 나왔습니다 첫 호출이 느렸을 뿐인데 실패로 판단해서 다시 부르는 식이죠.
이게 추적하기 까다로운 이유가, 에러가 안 난다는 겁니다. 두 번 다 200이고 로그도 깨끗해서 사후에 로그만 봐서는 안 보입니다.
저희가 쓰는 방법은 (도구, 정규화된 인자, 출력 해시)로 묶어서 같은 조합이 반복되는지 기계적으로 세는 겁니다. LLM 판단 없이 계산만으로 되니까 재현 가능하고요. 다만 한계가 명확한데 "두 번 호출됐다"까지만 알지 "실제로 두 번 실행됐는지"는 트레이스만으론 확인이 안 됩니다. 응답에 엔티티 ID를 주는 도구(문서 생성 API 같은)는 ID를 비교해서 확인 가능한데, 이메일처럼 "발송 성공"만 돌려주는 도구는 방법이 없더군요.
2번 말씀하신 "빠른 속도를 위해 그냥 통과시키는" 부분도 공감합니다. 저희도 실시간으로 막는 걸 검토했는데, 실행 전에는 결과를 볼 수 없어서 인자만으로 판단해야 하고 그 정확도가 낮았습니다. 정상적인 재시도까지 막아버리는 경우가 생겨서 접었습니다.
써보시다가 점프백이 헛도는 대화나 "이건 좀 불편한데" 싶은 부분 있으면 편하게 댓글 남겨주세요. 사이트마다 대화 구조가 달라서 실사용 사례가 제일 큰 도움이 됩니다. 다음으로는 Perplexity 지원이랑 Notion/Obsidian 내보내기를 보고 있는데, 더 급한 게 있다면 그것부터 하려고요 ㅎㅎ
[보기 불편하실까봐 READ ME 한국어 번역본을 적어드렸습니다!]
Clew
에이전트 트레이스에서 낭비된 작업을 찾는 결정론적 탐지기.
Clew는 완료된 AI 에이전트 실행 트레이스를 읽어서, 이미 수행된 작업을 반복한 스텝 — 같은 도구를 같은 인자로 재호출, 실패한 호출을 동일 인자로 재시도, 이미 컨텍스트에 있는 정보를 다시 조회 — 을 찾아냅니다. LLM 판정 없이 동작하므로, 같은 트레이스를 넣으면 언제나 같은 결과가 나옵니다.
estimated cost impact: $0.026340 ~ $0.263400 (cache-hit to cache-miss)
이게 왜 중요한가
AI 코딩 에이전트 세션은 청구서로만 낭비가 드러납니다. 모든 도구 호출이 200을 반환하고, 아무것도 에러를 내지 않기 때문에 낭비가 눈에 보이지 않습니다. 하지만 트레이스 안에서는 에이전트가 같은 파일을 두 번 읽고, 실패한 호출을 동일 인자로 재시도하고, 같은 도구를 같은 페이로드로 다시 부릅니다.
코딩 에이전트 세션에서 읽기(read) 작업이 토큰의 65~90%를 차지하기 때문에, 이런 낭비는 눈에 띄지 않게 쌓입니다. 관측성 도구들은 트레이스를 보여주지만, 어느 스텝이 중복이었는지는 알려주지 않습니다.
무엇을 탐지하나
Clew는 세 가지 중복 패턴을 찾습니다:
repeat — 같은 도구/노드가 반복 호출됨
requery — 같은 도구가 같은 입력으로 재호출됨 (출력 동일)
pingpong — 두 에이전트가 실질적으로 같은 내용을 주고받음 (멀티에이전트)
각 발견은 네 가지로 분류됩니다:
error_repeat — 출력이 에러인데 같은 호출을 반복
side_effect — 상태를 변경하는 도구(전송/쓰기/생성 등)를 재실행
idempotent — 읽기 전용/선언적 도구를 반복 (부작용 없음, 토큰은 소모)
unclassified — 매핑에 없는 도구. 효과가 페이로드에 달려 있어 도구 이름만으로 추론하지 않음 (Bash/PowerShell 등)
[어떻게 동작하나]
2단계 캐스케이드입니다:
구조 게이트 — 같은 도구를 같은 (정규화된) 인자로 호출한 것끼리 묶음
동일성 게이트 — 출력의 sha256이 완전히 일치하는지 확인. 다르면 상태가 변한 것이므로 플래그하지 않음
값싼 구조 검사가 먼저 후보를 추리고, 비싼 의미 검사(임베딩+코사인)는 필요할 때만 실행됩니다. LLM 판정이 없으므로 결과가 결정론적입니다 — CI에 넣고 싶다면 이 점이 중요합니다.
[입력 형식]
Claude Code — 세션 JSONL을 직접 분석
LangGraph — 트레이스에서 체인 중복 탐지
LangChain·CrewAI·AutoGen·LlamaIndex 등 — OpenTelemetry/OpenInference 표준 형식으로 계측된 트레이스를 파싱 (형식 지원이며, 프레임워크별 실측 검증은 진행 중)
공개 벤치마크 트레이스 (Toolathlon, RedundancyBench)
Cursor와 Codex 세션은 아직 지원하지 않습니다 — 로컬 포맷을 검토 중입니다.
[검증 결과]
공개 벤치마크 (Toolathlon, 6,780 트레이스, tool span 176,270개):
중복 호출 8,042건 탐지. 그중 47%는 회색지대(멱등 연산, 완료 선언)이며, 이를 제외하면 4,251건(tool span 대비 2.41%). Claude Code 세션(0.80%) 대비 약 3배.
상태 변경 도구의 중복 실행 1,343건, 여기에 같은 인자로 반복된 이메일 발송 459건 포함. 단, 이는 같은 도구가 같은 인자로 중복 호출됐다는 탐지이며, 실제로 부작용이 발생했는지는 확인되지 않았습니다.
라벨링 벤치마크 (RedundancyBench):
precision 0.826 (파일 내 중복에 대한 하한 추정치). RB 라벨의 상당수는 파일 간(cross-file) 중복으로, 세션 단위 분석 설계의 범위 밖입니다. recall은 0.157로 낮습니다.
[정직 경계]
측정된 절감 사례는 아직 없습니다. 탐지하고 추정할 수는 있지만, 실사용자가 무언가를 고쳐서 청구서가 실제로 줄어든 before/after 데이터는 0건입니다.
벤치마크에서 플래그된 것의 47%는 회색지대(멱등 재실행)입니다. 걸러내지 않고 분류만 합니다 — 읽기 전용 재실행이 낭비였는지는 볼 수 없는 맥락에 달려 있기 때문입니다.
sha256 완전일치를 요구하므로 출력이 조금만 달라도 플래그하지 않습니다. recall이 낮은 이유이며, 정밀도 쪽에 서 있는 설계입니다.
Claude Code는 유난히 잘 최적화돼 있습니다. 실제 CC 세션에서 후보 낭비 패턴 여섯 개를 측정했는데 다섯 개는 거기 존재하지 않았습니다. 흥미로운 낭비는 CC 자체가 아니라 다중 도구 MCP 환경에서 나타났습니다.
비용 추정(amplification)은 측정이 아니라 추정이며, Claude Code 포맷에서만 가능합니다.
검증되지 않은 것은 폐기합니다
파일 재읽기 탐지기를 만들었다가, 30건 표본 사람 주석에서 정밀도가 사전등록 임계(70%)를 크게 밑돌아(관대하게 봐도 3.3%, 엄격하면 0%) 폐기했습니다. 예측과 결과는 사전등록 문서에 함께 남겨뒀습니다.
작성자 업데이트입니다. 본문에서 한 줄로만 언급한 MCP 서버 부분을 따로 정리한 글을 올렸습니다 — 에이전트가 마이그레이션을 짤 때 컬럼명을 제멋대로 짓는 문제를, 물리명을 "입력"이 아니라 단어사전 기반 "계산"으로 바꿔서 푸는 구조입니다: https://sqemo.com/blog/erd-mcp-server
글을 좀 더 자세하게 읽고 왔는데 뭔가 이곳저곳이 억지스러워서 광고처럼 느껴지는 글이네요.
특히 마지막 녹음기 부분이 여러 매체에서 보이던데 단순한 녹음기임에도 엄청난 가격으로 명품 마케팅을 하고 있네요..
"스마트폰 녹음기를 사용하는 방식은 생각에서 녹음까지 너무 많은 단계를 거쳐야 함. 원하는 동작은 버튼을 누르는 동안 음성을 녹음하고, 놓으면 저장하는 정도로 단순함. 일부 스마트폰에 이런 기능이 있지만 AI 기능으로 포장되고 있으며, 데이터가 다른 곳으로 전송될 가능성이 있다고 봄."
이것이 문제라고 생각하시는 분들은 이미 배포되는 수많은 오픈 소스 녹음기 앱을 사용하시거나 간단하게 구현하실 수 있고 전원 버튼 두 번 클릭 등의 제스처에 할당하셔서 사용하시면 됩니다. 상당히 억지스러운 부분이네요.
그냥 비싸지만 이쁩니다. 이쁜거 좋아하면 사세요. 라고 사실대로 말해도 되는 것을 굳이 가짜 문제를 만들고 해결하고 있네요.
여기 성명에 동조하는건 정치적 행동일 뿐이라 봅니다. 샘알트먼도 애매하게 썼듯이…
오픈소스는 오픈소스일뿐 누가 만들던 승리자가 없는 세상이길 바래요.
사실 중국이 승리하는 것보다는 나을 뿐 미국이 승리한다고 해서 한국 포함 전세계적으로 정말 좋은 일인가는 굳이 최근 정치적인 상황 등을 따지지 않더라도 의문스러운 일이지만
샘 알트먼 자신은 미국이 승리하는 게 좋겠죠. 본인도 미국인이고 여러 미국 기업의 주식을 보유했으니까요.
글쎄요. 도구를 분리한다고 딱히 집중도나 생산성에 큰 도움이 될까 싶습니다.
이메일 열람용 도구를 분리해서 이메일만 확인하고 절대 손도 뻗지 않겠다 라는 목표를 세우고 달성할 수 있는 사람이라면 스마트폰에서 이메일만 확인하고 끄겠다는 목표도 달성할 수 있을 것입니다.
집중의 분산은 거의 습관의 문제입니다. 지쳤을 때 하던 것을 놓지도 않고 다른 것을 보고자 하는 충동을 제어하지 못하고 왔다갔다 하는거죠.
뭔가에 확실하고 길게 몰입하여 집중하고 지칠 때 확실히 끊고 쉬어버리는 습관을 만들어야 합니다.
물론 알림 등 현대 여러 매체들이 집중을 빼앗으려고 고의적으로 설계되었다는 점을 무시하지는 않겠습니다만 설정으로 어느 정도 해결할 수 있는 문제입니다. 덜 중요한 알림은 무음으로 하고 잠금화면에서도 숨기세요.
기본적으로 사용자에게 적대적인 아이폰에서도 되는지는 잘 모르겠지만요.
https://x.com/sama/status/2080683363174945065?s=46
샘알트먼이 어제 X에 이렇게 얘기했죠
i want the US to win in AI both in open source and proprietary models, and i am glad to see this
근데 당연히 중국 오픈웨이트에 대한 찬성은 아니고 미국이 독점모델과 오픈모델 둘다에서 승리하길 바란다는…
바로 어제 올라온 OpenAI와 Anthropic, 자사 수익을 위협하는 오픈 웨이트 AI에 공동 대응 과 대비되는 소식이네요.
사주는 곳이 많으면 좋은 NVIDIA와 큰 힘을 못쓰는 회사들은 오픈웨이트를 붙잡고
이미 꽉 잡고 있는 OpenAI와 Anthropic은 닫아걸려고 난리네요
이럴 때만 마음이 맞네요.
Open을 사명에 박아놓고도 뻔뻔하게 행동하는 OpenAI나
OpenAI가 변했다면서 뛰쳐나간 Anthropic이나
돈 때문에 이러는건지 AI를 패권 다툼으로 보고 정부가 개입하여 경영진을 쥐락펴락하는건지
eww...
교육을 팔아먹는 것이 가장 가성비가 좋음. 책임은 없고 비용청구만 있음. AI는 이런 장사의 큰 파이를 차지할 것임
몇년 전에 본거 같은데
일단 원본사이트가니, 이미지로 설명이 되어 있어 직관적으로 이해하기 쉽네요.
산책이나 독서 같은 오프라인 활동을 늘리면 좋아집니다. ㅎㅎ
3번(에이전트 간 책임 분리)이 제일 어려운 부분 같습니다. 공개 벤치마크 트레이스를 좀 들여다본 적이 있는데, 거기서 본 패턴 하나 공유드립니다.
가장 흔했던 건 "잘못된 결정"보다 같은 작업이 두 번 실행되는 것이었습니다. 같은 인자로 이메일 발송이 반복되거나, 같은 파일이 다시 쓰이거나. 특히 타임아웃 후 재시도 구간에서 자주 나왔습니다 첫 호출이 느렸을 뿐인데 실패로 판단해서 다시 부르는 식이죠.
이게 추적하기 까다로운 이유가, 에러가 안 난다는 겁니다. 두 번 다 200이고 로그도 깨끗해서 사후에 로그만 봐서는 안 보입니다.
저희가 쓰는 방법은 (도구, 정규화된 인자, 출력 해시)로 묶어서 같은 조합이 반복되는지 기계적으로 세는 겁니다. LLM 판단 없이 계산만으로 되니까 재현 가능하고요. 다만 한계가 명확한데 "두 번 호출됐다"까지만 알지 "실제로 두 번 실행됐는지"는 트레이스만으론 확인이 안 됩니다. 응답에 엔티티 ID를 주는 도구(문서 생성 API 같은)는 ID를 비교해서 확인 가능한데, 이메일처럼 "발송 성공"만 돌려주는 도구는 방법이 없더군요.
2번 말씀하신 "빠른 속도를 위해 그냥 통과시키는" 부분도 공감합니다. 저희도 실시간으로 막는 걸 검토했는데, 실행 전에는 결과를 볼 수 없어서 인자만으로 판단해야 하고 그 정확도가 낮았습니다. 정상적인 재시도까지 막아버리는 경우가 생겨서 접었습니다.
버그수정 또한 매우 저렴해졌고 소프트웨어 업데이트 비용도 0에 수렴하는데다 금융권급 아니면 버그는 고치면 그만인 경우가 많긴해서...
근데 이런 인식이 쌓이면 결국 대형사고가 일어나는거겠죠
써보시다가 점프백이 헛도는 대화나 "이건 좀 불편한데" 싶은 부분 있으면 편하게 댓글 남겨주세요. 사이트마다 대화 구조가 달라서 실사용 사례가 제일 큰 도움이 됩니다. 다음으로는 Perplexity 지원이랑 Notion/Obsidian 내보내기를 보고 있는데, 더 급한 게 있다면 그것부터 하려고요 ㅎㅎ
감사합니다. 써보시고 점프백이 안 잡히는 대화가 있으면 편히 알려주셔요~
저도 써보고는 있는데, 실제 다른 유저분들의 불편 사항도 함께 들을 수 있으면 좋을 것 같네요 ㅎㅎ
에이전트가 수정할 때마다 diff 로그를 관찰해서 산탄총 수술이나 대량의 변경을 일으킨다면 SE적 악취로 보고 강화학습이 가능할 것 같기도 하네요...
[보기 불편하실까봐 READ ME 한국어 번역본을 적어드렸습니다!]
Clew
에이전트 트레이스에서 낭비된 작업을 찾는 결정론적 탐지기.
Clew는 완료된 AI 에이전트 실행 트레이스를 읽어서, 이미 수행된 작업을 반복한 스텝 — 같은 도구를 같은 인자로 재호출, 실패한 호출을 동일 인자로 재시도, 이미 컨텍스트에 있는 정보를 다시 조회 — 을 찾아냅니다. LLM 판정 없이 동작하므로, 같은 트레이스를 넣으면 언제나 같은 결과가 나옵니다.
pip install "clew-custos[detect]"
python -m clew analyze ~/.claude/projects/<slug>/<uuid>.jsonl --out report.md
공개 Claude Code 세션에 돌린 실제 출력 예시:
Result: WASTE DETECTED
1. requery — Read on
.../boot.ts이게 왜 중요한가
AI 코딩 에이전트 세션은 청구서로만 낭비가 드러납니다. 모든 도구 호출이 200을 반환하고, 아무것도 에러를 내지 않기 때문에 낭비가 눈에 보이지 않습니다. 하지만 트레이스 안에서는 에이전트가 같은 파일을 두 번 읽고, 실패한 호출을 동일 인자로 재시도하고, 같은 도구를 같은 페이로드로 다시 부릅니다.
코딩 에이전트 세션에서 읽기(read) 작업이 토큰의 65~90%를 차지하기 때문에, 이런 낭비는 눈에 띄지 않게 쌓입니다. 관측성 도구들은 트레이스를 보여주지만, 어느 스텝이 중복이었는지는 알려주지 않습니다.
무엇을 탐지하나
Clew는 세 가지 중복 패턴을 찾습니다:
repeat — 같은 도구/노드가 반복 호출됨
requery — 같은 도구가 같은 입력으로 재호출됨 (출력 동일)
pingpong — 두 에이전트가 실질적으로 같은 내용을 주고받음 (멀티에이전트)
각 발견은 네 가지로 분류됩니다:
error_repeat — 출력이 에러인데 같은 호출을 반복
side_effect — 상태를 변경하는 도구(전송/쓰기/생성 등)를 재실행
idempotent — 읽기 전용/선언적 도구를 반복 (부작용 없음, 토큰은 소모)
unclassified — 매핑에 없는 도구. 효과가 페이로드에 달려 있어 도구 이름만으로 추론하지 않음 (Bash/PowerShell 등)
[어떻게 동작하나]
2단계 캐스케이드입니다:
구조 게이트 — 같은 도구를 같은 (정규화된) 인자로 호출한 것끼리 묶음
동일성 게이트 — 출력의 sha256이 완전히 일치하는지 확인. 다르면 상태가 변한 것이므로 플래그하지 않음
값싼 구조 검사가 먼저 후보를 추리고, 비싼 의미 검사(임베딩+코사인)는 필요할 때만 실행됩니다. LLM 판정이 없으므로 결과가 결정론적입니다 — CI에 넣고 싶다면 이 점이 중요합니다.
[입력 형식]
Claude Code — 세션 JSONL을 직접 분석
LangGraph — 트레이스에서 체인 중복 탐지
LangChain·CrewAI·AutoGen·LlamaIndex 등 — OpenTelemetry/OpenInference 표준 형식으로 계측된 트레이스를 파싱 (형식 지원이며, 프레임워크별 실측 검증은 진행 중)
공개 벤치마크 트레이스 (Toolathlon, RedundancyBench)
Cursor와 Codex 세션은 아직 지원하지 않습니다 — 로컬 포맷을 검토 중입니다.
[검증 결과]
공개 벤치마크 (Toolathlon, 6,780 트레이스, tool span 176,270개):
중복 호출 8,042건 탐지. 그중 47%는 회색지대(멱등 연산, 완료 선언)이며, 이를 제외하면 4,251건(tool span 대비 2.41%). Claude Code 세션(0.80%) 대비 약 3배.
상태 변경 도구의 중복 실행 1,343건, 여기에 같은 인자로 반복된 이메일 발송 459건 포함. 단, 이는 같은 도구가 같은 인자로 중복 호출됐다는 탐지이며, 실제로 부작용이 발생했는지는 확인되지 않았습니다.
라벨링 벤치마크 (RedundancyBench):
precision 0.826 (파일 내 중복에 대한 하한 추정치). RB 라벨의 상당수는 파일 간(cross-file) 중복으로, 세션 단위 분석 설계의 범위 밖입니다. recall은 0.157로 낮습니다.
[정직 경계]
측정된 절감 사례는 아직 없습니다. 탐지하고 추정할 수는 있지만, 실사용자가 무언가를 고쳐서 청구서가 실제로 줄어든 before/after 데이터는 0건입니다.
벤치마크에서 플래그된 것의 47%는 회색지대(멱등 재실행)입니다. 걸러내지 않고 분류만 합니다 — 읽기 전용 재실행이 낭비였는지는 볼 수 없는 맥락에 달려 있기 때문입니다.
sha256 완전일치를 요구하므로 출력이 조금만 달라도 플래그하지 않습니다. recall이 낮은 이유이며, 정밀도 쪽에 서 있는 설계입니다.
Claude Code는 유난히 잘 최적화돼 있습니다. 실제 CC 세션에서 후보 낭비 패턴 여섯 개를 측정했는데 다섯 개는 거기 존재하지 않았습니다. 흥미로운 낭비는 CC 자체가 아니라 다중 도구 MCP 환경에서 나타났습니다.
비용 추정(amplification)은 측정이 아니라 추정이며, Claude Code 포맷에서만 가능합니다.
검증되지 않은 것은 폐기합니다
파일 재읽기 탐지기를 만들었다가, 30건 표본 사람 주석에서 정밀도가 사전등록 임계(70%)를 크게 밑돌아(관대하게 봐도 3.3%, 엄격하면 0%) 폐기했습니다. 예측과 결과는 사전등록 문서에 함께 남겨뒀습니다.
작성자 업데이트입니다. 본문에서 한 줄로만 언급한 MCP 서버 부분을 따로 정리한 글을 올렸습니다 — 에이전트가 마이그레이션을 짤 때 컬럼명을 제멋대로 짓는 문제를, 물리명을 "입력"이 아니라 단어사전 기반 "계산"으로 바꿔서 푸는 구조입니다:
https://sqemo.com/blog/erd-mcp-server
(아직 stdio 로컬 전용이라 원격 MCP는 미지원, 앱 본체는 비공개이고 MCP 서버만 오픈).
무가입으로 바로 써볼 수 있으니(app.sqemo.com) 걸리는 부분 있으면 댓글 주세요 — 초기라 피드백이 바로 반영됩니다.
업데이트 기록 (2026-07-25)
첫 글 이후 Repolis를 단순한 3D repo 브라우저보다, 다시 방문할 이유가 있는 작은 마을 쪽으로 계속 확장했습니다.
새 글을 만들기보다 이후 변경사항도 이 원글 댓글에 이어서 기록하겠습니다.
Live: https://hyeonsangjeon.github.io/Repolis/
Source: https://github.com/hyeonsangjeon/Repolis