너무 좋습니다...

그렇네요 함수 호출이 “~ㄴ다“ 여야 할 것 같습니다 ㅋㅋ

근본적인 문제는 잘못된 쿼리죠.
근데 전 unwrap으로 문제 검증을 생략한 것도 문제라고 생각해요
내부적으로 문제가 생길지언정 에러처리했으면 트래픽 다운되진 않았을테니까요

현재 구글에서 출시한 VSCode OSS 포크인 Antigravity ( https://antigravity.google/pricing ) 에서 무료로 사용할 수 있습니다
이외 gemini-cli에서는 현재 AI Ultra(월 36만)만 사용 가능하다는 것 같네요.

unwrap이 문제는 아닌거같은

아 제가 아직 대학교 3학년이라 컴파일러 수업을 듣지 않고 독학하며 만든 거기도 하고 빠르게 만드려고 야매로 학습하고 개발해서 그렇습니다.

그나저나 이 글 작성자가 CEO 였네요

오잉 lexer, parser 파일 명칭을 보면 컴파일러 공부를 하신 것 같은데 아닌가요?

대박이네요..

Cloudflare가 안되어서 온갖 서비스가 중단되니 지옥이더군요..

몇몇 예시를 보면 공백제거했을 때 JSON 규격이 훨씬 더 토큰 수를 줄여준다고 합니다.. 아직 잘 모르겠네요. 제대로 써볼만한 규격인지.

CF정도되는 회사에서도 .unwrap()을 쓰네요 ㄷㄷ
저 코드가 어떻게 프로덕션에 적용된거지

원인분석 문서가 꽤 빠르게 공개됐네요ㄷㄷ

모델별 정확도 비교
​- Gemini 2.5 Flash: TOON 87.6% vs JSON 77.0%
​- GPT-5 Nano: TOON 90.9% vs JSON 89.0%
​- Claude Haiku 4.5: TOON 59.8% vs JSON 57.4%

벤치마크 결과만 믿는다면, 정확도 감소 없이 token 사용량이 줄어서 안 쓸 이유가 없어 보이긴 하네요

Flamehaven FileSearch v1.2.0을 어제 릴리스했습니다. 이번 버전은 서비스 전체를 “공개 API”에서 보안·확장성 중심의 엔터프라이즈급 플랫폼으로 전환하는 데 초점을 맞췄습니다.

주요 변경 사항은 다음과 같습니다:

API 인증·권한 시스템 추가
모든 보호된 엔드포인트는 Bearer Token 인증을 필요로 합니다.
API Key는 업로드/검색/스토어/삭제 등 세분화된 권한을 지원하며, 키별 rate limit, 감사 로그, SHA256 해시 저장(원본 키 저장 없음)을 포함합니다.

Admin Dashboard 추가
API Key 생성·조회·폐기, 요청 통계, 엔드포인트 사용량 분포 등을 볼 수 있는 웹 UI입니다.
HTML/CSS/JS로 완전 자체 포함되어 외부 의존성이 없습니다.

Batch Search API
한 요청에 1–100개의 쿼리를 처리합니다.
병렬/순차 실행 모드, 우선순위 기반 정렬, 쿼리별 에러 격리, 상세 타이밍 메트릭을 제공합니다.

Redis 캐시 백엔드
멀티 워커 환경을 위한 분산 캐시 옵션입니다.
<10ms 조회 지연, 자동 LRU fallback, LLM 호출량 40–60% 절감 효과가 있습니다.

배포 템플릿 제공(Docker/Kubernetes)
Docker, Docker Compose, Kubernetes(ConfigMap/Secret/Deployment) 예제가 포함되어 바로 배포할 수 있습니다.

성능 요약:

캐시 히트: <10ms

캐시 미스(LLM 호출): ~0.5–3s

Batch Search(10개): ~2–5s

GitHub: https://github.com/flamehaven01/Flamehaven-Filesearch

보안 설계, API 사용성, 배포 구조 등 개선 의견이 있으면 환영합니다.
v1.2.1(어드민 인증 개선, Redis 설정 UI), v1.3.0(키 로테이션 + OAuth2/OIDC)도 준비 중입니다.

좋은 사이트인데 일부 링크가 동작안하는 부분이 있어 수정되면 좋을 것 같아요~!
https://careers.linecorp.com/ko/jobs/2838/

원래 초기에는 변수 할당은 가는 ~이다. 였습니다. 근데 개발할때 "이다/다"를 함수 호출에도 써서 표현식 파싱 하는게 애매해져서 "된다"로 바꿨습니다. 나중에 "이다"로 파싱할 수 있게 해보려 시도 해볼 거 같습니다.

Hardening ingestion of Cloudflare-generated configuration files in the same way we would for user-generated input

좋은 교훈인것 같습니다.

유저의 입력값은 오만가지 검증을 다 적용하면서

내부에서 만들어낸 크리티컬 데이터는 사실 이렇게까지 검증하지는 않지요.

조직이 방대해질수록 해당내용이 문서화되어 있더라도 발견되지 않을수도 있고
넉넉하게 설정한 사이즈여서 한동안 문제가 없어 잊혀버린후에 제한 사이즈를 넘어가거나 하면
맨붕이죠.. 정말..