최근 보안 사고가 잇달아 터지면서, API 키 등을 재발급하고 관리해야하는 일이 빈번해졌는데요. 키들이 .env, Vercel, Supabase, GCP, GitHub Actions 등등 다양한 서비스에 흩어져 있어서 관리하기가 까다로웠습니다.
그래서 rekey 명령 하나로 키를 재발급하고, 쓰이는 모든 곳에 반영하고, 재배포 확인 뒤 옛 키까지 폐기하는 과정을 도와주는 도구를 하나 만들었습니다.
🔑 키 값은 @1Password 에만. 사용처는 1Password 템플릿 파일로 git에서 관리
🤖 API로 되는 건 자동, 안 되는 서비스는 발급 페이지를 열어 주고 "복붙"만 하면 되도록
🚀 @vercel @Railway @supabase @Cloudflare @googlecloud @github @flydotio 지원 (다른 플랫폼 기여 환영)
🌏 한국어·English·中文·日本語·Español
레포: github.com/golbin/rekey
예시: github.com/golbin/rekey-exam…
With security incidents piling up lately, I've had to reissue and manage API keys more and more often. Our keys were scattered across .env files, Vercel, Supabase, GCP, GitHub Actions and more, which made them a pain to manage.
So I built rekey, a tool that does the whole job with one command: reissue a key, update every place it's used, confirm the redeploys, then revoke the old one.
🔑 Key values live only in @1Password. Where each key is used is tracked in git as 1Password template files
🤖 Automatic where an API exists. For services without one, it opens the key page so you just copy and paste
🚀 Supports @vercel @Railway @supabase @Cloudflare @googlecloud @github @flydotio (contributions for other platforms welcome)
🌏 한국어 · English · 中文 · 日本語 · Español
Repo: github.com/golbin/rekey
Example: github.com/golbin/rekey-exam…
📝 Claude가 25년 동안 미스터리였던 문제를 풀어낸 이야기
미국 NSA가 제공하고 NIST가 표준화한 타원곡선 암호 기술에 사용되는 시드(seed)가 대체 어떻게 만들어진 건지, 암호학계에서 25년 넘게 추측해 왔는데요.
Claude가 이 문제를 30분도 안 돼서 풀어냈다고 합니다.
(이 시드는 공개된 값으로, 암호 기술이 뚫렸다는 이야기는 아닙니다.)
결론은 충격적으로(?) 단순했는데요. 1997~1998년 당시의 유닉스 타임스탬프를 난수 생성기의 초기값으로 넣고, 그 결과 중 특정 값을 선택했던 것이었습니다.
Claude는 공개된 시드의 숫자에서 특이한 비트 패턴을 발견했고, 이것이 당시 사용하던 lrand48() 난수 생성기의 출력 구조와 일치한다는 사실을 알아냈습니다.
이후 수학적 기법으로 난수 생성기의 내부 상태를 역산하고, 생성 시점까지 거슬러 올라가 실제 표준값과 일치하는지 검증하는 과정을 거쳤다고 합니다.
결과와 과정만 언뜻 보면 별거 아닌 것 같지만, 이번 사례는 AI가 단순히 추론과 실험을 반복해서 문제를 푸는 것을 넘어, 기존에 정답이 알려지지 않은 미지의 문제에서 인간의 가설을 그대로 따르지 않고 새로운 접근을 시도했다는 것에 큰 의의가 있는 것 같습니다.
그런데 더 재미있는, 어떻게 보면 음모론자들에게는 ㅎㅎ 조금 으스스할 수도 있는 장면이 있었습니다.
Claude가 값을 계산해낸 직후의 내부 추론 과정이 일부 공개됐는데요.
처음에는 엄청나게 놀라면서,
“이건 놀라운데? 25년 된 미스터리를 해결했잖아!”
라고 하다가, 갑자기 멈춰서 스스로 의심하기 시작합니다.
“잠깐, 혹시 내가 시뮬레이션이나 테스트 환경에 있는 건 아닐까?”
자신이 정말로 25년 동안 풀리지 않은 문제를 해결했다는 게 믿기지 않았던지, Claude는 계산된 값이 실제 표준값과 일치하는지, 단순한 우연일 가능성은 없는지 검증하고, 자신의 기존 지식상 이 문제가 아직 미해결 상태였다는 사실까지 대조합니다.
그리고 나서야,
“와, 이건 진짜 발견이야.”
라고 결론 내립니다.
그런데 여기서 끝이 아닙니다.
다시 한번 의심합니다.
“그런데 이렇게 명백한 걸 25년 동안 아무도 발견하지 못했다는 게 좀 이상한데?”
그리고 스스로 추가 검증을 진행합니다. 160비트 시드의 정확한 일치가 여러 차례 확인됐다는 점을 근거로 우연일 가능성을 배제합니다.
개인적으로는 도출한 결과 자체도 충격적이지만, 그보다 AI가 스스로 가설을 세우고, 발견한 결과를 의심하고, 자신이 처한 상황까지 의심하면서 연구를 진행했다는 것이 훨씬 인상적입니다.
물론 이런 내부 추론 기록을 사람의 의식이나 자각과 동일하게 해석할 수는 없겠지만, 적어도 연구 과정에서 보여준 행동만큼은 상당히 놀랍습니다.
특이점이라는 게 생각보다 훨씬 가까이 와 있는 건 아닐까 하는 생각이 드는 사례였습니다.
실시간 음성대화를 자연스럽게 만들기 위한, 작지만 아주 중요한 구성요소 중 하나는 “발화권”이다.
사용자가 말을 끝냈는지를 판단하거나 AI가 말을 하는 도중 사용자가 말을 시작했는지를 매우 빠르게 판단해서 누구의 턴인지를 판단하는 기술.
하지만 이게 단순하지만은 않은데, 사용자가 추임새를 할 때는 말을 멈추지 않아야하며 혹은 적절한 시점에 추임새를 주기도 해야하고, 말을 늘어뜨리거나 멈칫하는 순간에 치고 들어오지 않아야 하는 등 실세계에서는 상당히 복잡한 상황을 다룰 수 있어야한다.
그리고 그 판단 속도가 수십ms 이내여야한다.
시중의 턴 디텍션 모델들은 매우 단순해서 이런 복합적인 상황을 다룰 수 있는 모델이 없기도 하지만, 다른 유명한(OpenAI가 사용하는 LiveKit 등) 모델들의 성능이 잘 나오지 않아 직접 모델과 엔진을 개발중이다.
발화권 모델을 직접 개발해야겠다고 마음먹은건 각 모델들의 벤치마크 숫자는 거의 완벽할 정도로 잘 나오지만, 실제 상황에서는 대체로 잘 작동하지 않는 경우가 많았기 때문인데,
모델들을 들여다보니 테스트 데이터에 학습 데이터가 섞여 들어가 있거나, 합성 데이터를 잘못 사용해서 학습 데이터와 테스트 데이터간 유사도가 너무 높아서 과적합처럼 성능이 비정상적으로 높은 경우가 있었다.
또한 측정한 모델 추론 속도는 고사양 컴퓨터에서 잰 속도여서, 클라우드 서버의 열악한 CPU에서 돌리면 몇 배나 느려지는 문제도 있었다.
무엇보다 모델 자체의 성능은 좋아도, 실제 서비스에 붙였을 때 인간의 예측 불가능한 사용 방식, 전화망 환경 등 실세계 환경에 맞지 않는 경우도 많았다.
이것이 바로 모델의 벤치마크 성능을 숫자 그대로 믿지 말아야하는 이유다.
아무튼, 그래서 모델과 하네스에서 모두 성능을 담보할 수 있도록 교차 실험을하며 연구 개발하고 있고, 비교 평가하고 있는 주요 벤치마크에서 모든 모델을 이기는 모델을 확보했다.
물론 아직 서비스 반영 전이라 서비스에 올려봐야 알 수 있겠지만, 기존보다는 확실히 더 좋은 경험을 줄 수 있을 것으로 생각된다.
📝 간밤의 OpenAI DevDay 소감
Dots. 모든 회사가 이리로 가고 있구나. 우리 Loom도 그런 방향의 실험을 하고 있었는데.. 🫠 역시 큰 회사가 할만한 분야는 손대지 않는 것이 좋을 듯? 음..
GPT 6.1 Sol. Sonnet 5.5도 그렇고, 높은 지능 대비 가성비는 계속 낮아지고 있다. 프론티어 랩이 아닌 모델 회사들은 진짜 피가 마를 듯. 매우 긴 장기전으로 생각해야할텐데 과연 어떨지..
ChatGPT 로그인으로 다른 앱에 로그인해서 토큰을 ChatGPT 구독 토큰을 쉐어해서 쓸 수 있게 되었다. 사실 이게 가장 큰 것 같은데, OpenAI가 플랫폼 플레이를 놓지 않고 끈질기게 해 오더니 이제 방향을 제대로 잡은 듯?
$500 플랜. Ultrafast 8배속 모드.. 아.. 쓰고싶다..(…) 하지만 사용 비율이 줄어서 500이 기존 200과 비슷한 25배여서 Astra로는 버틸 수 없을 것이라 매력이 떨어지지만, Sol 도 사용 가능해지면 아마 내가 못버틸 듯? 🙈
Fable, Astra와 Opus, Sol과의 차이, 그리고 그 아래 레벨 모델들과의 차이는 약간 이런 느낌이다.
일을 주면 하루종일 만화책 보면서 코 후비다가 한숨 자고 일어나서 한 열 줄 코딩하고 일 끝내는 삼십년묵은 덕후 개발자와, 삼일 내내 잠도 안자고 리서치 해 가면서 레포를 갈아 엎으며 코딩해서 뿌듯하게 일 마치고 기절하는 이제 막 대학교를 졸업한 신입/주니어의 차이?
겉보기에는 결과가 비슷하지만 자세히 보면 코 후비던 덕후 개발자의 코드의 품질과 성능이 더 좋은 것 같은 느낌이랄까? 😏
모델 및 Effort 선택 기준 알려드립니다. Fable, Astra, Opus 5.5, GPT-6 Sol 모델 기준.
수치적으로 재 본 것은 아니지만, 일반 웹 서비스, 앱, 데스크탑 앱, 디자인, 머신러닝 프로젝트, 프롬프트 엔지니어링, 데이터 분석 그리고 신규 프로젝트와 유지보수 프로젝트 등 다양한 실제 실무에 사용한 경험적 의견입니다.
결론부터 말하자면, 보통은 그냥 Opus 5.5 + GPT 6 Sol Medium 으로 기분에 따라 번갈아가면서 쓰면 됨.
다만 Opus, GPT High 까지는 그 대신 Fable, Astra를 Low로 사용하는게 더 빠르고 좋을 수 있고, 어떤 경우는 비용이 덜 들기도 함.
복합적이고 넓은 사고를 요하는 경우 Fable이 아직 확실히 독보적이긴 하고, Astra는 세부사항을 파고드는 능력이 좋음.
여러 프로젝트에 써 본 경험상 가장 좋은 기본 조합은 Fable High 계획 + Astra Low 구현 + Astra Medium 리뷰인데 토큰이 순삭될 수 있어서 권장은 어려움.
근데 보통의 문제에는 이정도까지 쓸 필요가 없기 때문에, 어떻게 해도 해결이 안되는 문제가 아니면 그냥 Opus 5.5, GPT 6 Sol Medium 무지성으로 쓰시면 됩니당. ☺️
Fable, Astra가 본격적으로 필요한 일은 스펙이 명확히 정해지지 않은 초기 단계의 복합적인 작업 혹은 밀레니엄 문제같은 초고차원 문제 정도.









