한참 웹이 quirk html로 난장판이었을 때 웹 표준 검사기로 사이트 채점해주던 시절이 생각나네요. 웹 표준 지킨다고 사이트 내실이 보장되는 건 아니었지만 적어도 사이트들이 표준 준수에 대한 경각심을 갖게 해 주는 효과는 있었죠. 그리고 구글처럼 웹을 크롤링하고 머신 리딩해야 하는 기업들은 누워서 검색 품질을 공짜로 올리는 정도의 이점을 가져가지 않았을까 싶네요.
저렇게 가이드라인을 제시하면 인간만이 아니라 AI 에이전트도 인터넷의 사용 주체로 변화하는 시점에서 조금이나마 덜커덩을 줄이면서 빠르게 인프라 안정화를 이룰 수 있겠죠. 시간이 지나면 몇 가지는 지나치고 과한 군더더기로 여겨지더라도 기강(?)을 빠르게 잡는 자체에서 관련 산업에서 이점이 있지 않겠느냐는 얘기였습니다.
DiskLayer는 그런 패턴이 아니라 그냥 일반 캐시 레이어로 동작합니다 — 읽기도 하고 쓰기도 하고, 위 레이어 미스나면 순서대로 접근하는 구조예요. 혼선을 드렸네요.
말씀하신 "원격 호출 결과를 디스크에 저장했다가 실패 시 읽는" 패턴은 사실 stale-if-error 옵션이 더 가깝긴 한데, 그건 메모리에 들고 있는 거라 프로세스 재시작하면 날아가요.
그리고 DiskLayer가 꼭 필요하냐는 지적은 음. 실제로 대부분의 다중 인스턴스 환경에서는 Memory → Redis만으로 충분하고, Disk가 레이어로 들어오는 순간 직렬화 비용이나 파일 관리 복잡도가 따라오거든요.
Redis가 들어간 건 서버가 여러 대일 때를 가정해서예요. 각 서버의 메모리는 서로 다른 값을 갖고 있을 수 있으니까, Redis가 "공유 진실" 역할을 합니다.
Disk가 Redis보다 뒤에 오는 건 Redis가 같은 로컬 네트워크에 있다는 가정 하에 더 빠르기 때문이에요. 벤치마크 기준으로 Disk는 ~2ms, Redis는 ~0.02ms거든요. 하지만 Redis가 멀리 있거나 네트워크가 나쁘면 로컬 Disk가 더 빠를 수 있고, 그럴 땐 순서를 바꾸는 게 맞아요. 라이브러리도 순서를 강제하지 않고 사용자가 직접 정하는 구조입니다.
Disk는 어디에 있든 간에 속도 경쟁보다는, Memory와 Redis가 다 죽었을 때 살아남는 마지막 보험 역할이 주목적이에요.
“토큰 사용량이 곧 실력이다”, “잘 만든 PRD 하나면 AI가 전부 해결된다” 같은 표현은 굉장히 강한 주장인데, 정작 누가 어디서 어떤 맥락으로 그렇게 말했는지는 잘 보이지 않습니다. 그래서 읽는 입장에서는 실제 흐름을 비판한다기보다, 대표성이 불분명한 극단적 주장 몇 개를 묶어 반박하는 허수아비 논법처럼 보입니다.
특히 om 계열을 포함해서 실제로 툴을 만들고 워크플로를 다듬는 분들이, “PRD 하나면 다 해결된다”는 식으로 말하는 경우는 저는 거의 보지 못했습니다. 오히려 계속 릴리즈와 수정, 검증을 반복하고 있죠. 그 자체가 아직은 사람의 판단과 개입이 필수라는 걸 전제로 한다고 봅니다.
그래서 더 조심해야 하는 건, 이런 식의 서술이 잘못 읽히면 특정 빌더나 개발자들이 실제로 하지도 않은 말을 한 것처럼 보이게 만들 수 있다는 점입니다. 그런 방식은 건강한 비판이라기보다, 과장된 프레임을 세워두고 공격하는 쪽에 더 가깝다고 생각합니다.
토큰 사용량도 마찬가지입니다. 실력의 절대 지표는 아니지만, 그렇다고 완전히 무의미한 숫자라고 하기도 어렵습니다. 사용량 차이가 매우 크게 벌어진다면 그건 단순 낭비가 아니라 탐색량, 실험량, 검증량의 차이일 수 있고, 실제 업무 밀도 차이로 이어질 수도 있습니다. 실제로 젠슨황께서도 연봉의 반 이상의 토큰을 사용해야한다고 말씀하셨죠 https://www.youtube.com/shorts/XBnFPuru4xA
좋은 PRD 역시 만능이 아니라 레버리지입니다. 그래서 결국 중요한 건 “토큰이 실력이냐 아니냐” 같은 단순 구도가 아니라, AI를 활용한 문제 해결 능력을 앞으로 어떤 기준으로 볼 것인가라고 생각합니다.
긱뉴스에 들어오는 IPv6 트래픽의 약 80%는 국내 이동통신 3사 계열 IPv6 대역에서 발생한 것으로 추정됩니다.
RIPEstat의 announced-prefixes와 APNIC RDAP 기준으로 SKT AS9644, KT/KORNET AS3559 및 AS4766, LGU+ Mobile AS17853, LGU+ / DACOM AS3786 등이 광고 중인 IPv6 prefix를 가져와서 서비스 로그랑 매칭해 산출한건데요.
다만 공개 BGP/WHOIS 정보만으로는 각 prefix가 모바일 가입자망 전용인지, 유선/기업망까지 포함하는지 완전히 구분하기 어렵기 때문에 “국내 이동통신 3사 계열 대역” 정도로 보는 게 안전합니다.
감사합니다!
“If you're nothing without the suit, then you shouldn't have it.” - Tony Stark
최소한 AI에게 지시할 때 짧게 몇마디 던지지 말고 구체적으로 최대한 나의 생각과 논리 전개를 풀어서 얘기하고, 그 후에 작업을 진행하기 전에 더 확인해 볼것이 있다면 반드시 물어보고 진행하도록 하는 게 도움이 되는 것 같습니다.
적어주신 글에 완전히 동의하는 게
사실 “토큰 사용량이 곧 실력이다”는 건 명백히 잘못됐고, 왜곡된 프레임입니다.
오히려 연산자원의 한계(사람을 포함한)가 유일한 병목이라는 걸 깨닫는 시점에서
토큰 사용량의 중요성을 깨닫게 된다는 관점으로 봐야합니다.
한참 웹이 quirk html로 난장판이었을 때 웹 표준 검사기로 사이트 채점해주던 시절이 생각나네요. 웹 표준 지킨다고 사이트 내실이 보장되는 건 아니었지만 적어도 사이트들이 표준 준수에 대한 경각심을 갖게 해 주는 효과는 있었죠. 그리고 구글처럼 웹을 크롤링하고 머신 리딩해야 하는 기업들은 누워서 검색 품질을 공짜로 올리는 정도의 이점을 가져가지 않았을까 싶네요.
저렇게 가이드라인을 제시하면 인간만이 아니라 AI 에이전트도 인터넷의 사용 주체로 변화하는 시점에서 조금이나마 덜커덩을 줄이면서 빠르게 인프라 안정화를 이룰 수 있겠죠. 시간이 지나면 몇 가지는 지나치고 과한 군더더기로 여겨지더라도 기강(?)을 빠르게 잡는 자체에서 관련 산업에서 이점이 있지 않겠느냐는 얘기였습니다.
DiskLayer는 그런 패턴이 아니라 그냥 일반 캐시 레이어로 동작합니다 — 읽기도 하고 쓰기도 하고, 위 레이어 미스나면 순서대로 접근하는 구조예요. 혼선을 드렸네요.
말씀하신 "원격 호출 결과를 디스크에 저장했다가 실패 시 읽는" 패턴은 사실 stale-if-error 옵션이 더 가깝긴 한데, 그건 메모리에 들고 있는 거라 프로세스 재시작하면 날아가요.
그리고 DiskLayer가 꼭 필요하냐는 지적은 음. 실제로 대부분의 다중 인스턴스 환경에서는 Memory → Redis만으로 충분하고, Disk가 레이어로 들어오는 순간 직렬화 비용이나 파일 관리 복잡도가 따라오거든요.
클로드 4.7이 아니라 opus 4.7
재미나다는거지 비웃는거는 아닙니다. 표현이 좀 그랬나 보네요.
클라우드플레어도 요 몇일 뭔가를 쏟아내고 있어서, 에이전트 시대에 뭔가 발빠르게 대응하는건 이해합니다.
근데 저 사이트의 체크리스트는 좀 이상해요. 저거로 사이트를 점수로 평가한다는거 자체가 갸우뚱하게 만듭니다.
자신들도 다 따라하지 못할 것들을 나열해 놓고, 굉장히 중요한 것처럼 말하는게 이상하다고 얘기하는 거에요.
클라우드플레어가 사이트들 못 만들었다고 도덕적으로 훈계하려고 저런 걸 만드는 게 아닐 텐데, 비웃을 이유가 있을까요?
인터넷 생태계에서 큰 영향력을 발휘하는 업체로서, 저렇게 아젠다를 선점하면 de facto로 여겨지면서 앞으로의 인터넷 발전 방향을 자사 이익에 유리한 방향으로 유도하기도 좋죠.
네 설계 의도 감사합니다. ㅎ
모든 원격 호출을 로컬 디스크 쓰기로 저장하다가, 원격 호출이 실패할때는 디스크 읽기를 한다는 말씀이시죠? 캐시레이어에 Disk가 꼭 필요한지도 고민해보시면 좋을 것 같습니다.
Redis가 들어간 건 서버가 여러 대일 때를 가정해서예요. 각 서버의 메모리는 서로 다른 값을 갖고 있을 수 있으니까, Redis가 "공유 진실" 역할을 합니다.
Disk가 Redis보다 뒤에 오는 건 Redis가 같은 로컬 네트워크에 있다는 가정 하에 더 빠르기 때문이에요. 벤치마크 기준으로 Disk는 ~2ms, Redis는 ~0.02ms거든요. 하지만 Redis가 멀리 있거나 네트워크가 나쁘면 로컬 Disk가 더 빠를 수 있고, 그럴 땐 순서를 바꾸는 게 맞아요. 라이브러리도 순서를 강제하지 않고 사용자가 직접 정하는 구조입니다.
Disk는 어디에 있든 간에 속도 경쟁보다는, Memory와 Redis가 다 죽었을 때 살아남는 마지막 보험 역할이 주목적이에요.
솔직히 이 글은 문제 제기 자체보다도 논지 전개가 더 아쉽게 느껴졌습니다.
“토큰 사용량이 곧 실력이다”, “잘 만든 PRD 하나면 AI가 전부 해결된다” 같은 표현은 굉장히 강한 주장인데, 정작 누가 어디서 어떤 맥락으로 그렇게 말했는지는 잘 보이지 않습니다. 그래서 읽는 입장에서는 실제 흐름을 비판한다기보다, 대표성이 불분명한 극단적 주장 몇 개를 묶어 반박하는 허수아비 논법처럼 보입니다.
특히 om 계열을 포함해서 실제로 툴을 만들고 워크플로를 다듬는 분들이, “PRD 하나면 다 해결된다”는 식으로 말하는 경우는 저는 거의 보지 못했습니다. 오히려 계속 릴리즈와 수정, 검증을 반복하고 있죠. 그 자체가 아직은 사람의 판단과 개입이 필수라는 걸 전제로 한다고 봅니다.
그래서 더 조심해야 하는 건, 이런 식의 서술이 잘못 읽히면 특정 빌더나 개발자들이 실제로 하지도 않은 말을 한 것처럼 보이게 만들 수 있다는 점입니다. 그런 방식은 건강한 비판이라기보다, 과장된 프레임을 세워두고 공격하는 쪽에 더 가깝다고 생각합니다.
토큰 사용량도 마찬가지입니다. 실력의 절대 지표는 아니지만, 그렇다고 완전히 무의미한 숫자라고 하기도 어렵습니다. 사용량 차이가 매우 크게 벌어진다면 그건 단순 낭비가 아니라 탐색량, 실험량, 검증량의 차이일 수 있고, 실제 업무 밀도 차이로 이어질 수도 있습니다. 실제로 젠슨황께서도 연봉의 반 이상의 토큰을 사용해야한다고 말씀하셨죠
https://www.youtube.com/shorts/XBnFPuru4xA
좋은 PRD 역시 만능이 아니라 레버리지입니다. 그래서 결국 중요한 건 “토큰이 실력이냐 아니냐” 같은 단순 구도가 아니라, AI를 활용한 문제 해결 능력을 앞으로 어떤 기준으로 볼 것인가라고 생각합니다.
의도적으로라도 귀찮음을 겪는 과정을 가져야겠군요
디지털 치매라는 단어가 떠오르는 글이네요
긱뉴스에 들어오는 IPv6 트래픽의 약 80%는 국내 이동통신 3사 계열 IPv6 대역에서 발생한 것으로 추정됩니다.
RIPEstat의 announced-prefixes와 APNIC RDAP 기준으로 SKT AS9644, KT/KORNET AS3559 및 AS4766, LGU+ Mobile AS17853, LGU+ / DACOM AS3786 등이 광고 중인 IPv6 prefix를 가져와서 서비스 로그랑 매칭해 산출한건데요.
다만 공개 BGP/WHOIS 정보만으로는 각 prefix가 모바일 가입자망 전용인지, 유선/기업망까지 포함하는지 완전히 구분하기 어렵기 때문에 “국내 이동통신 3사 계열 대역” 정도로 보는 게 안전합니다.
좋은 라이브러리네요!
Redis가 설계에 포함된 이유가 있나요? 읽기용 인스턴스 여러개가 동시에 뜨는걸 가정하는 상황인가요? 그렇다면 (로컬)Disk가 Redis보다 앞 레이어에 배치되어야 하지 않을까요?
사실 캡스락은 쓰이는 빈도에 비해 너무 좋은 자리를 차지하고 있지요. vial로 한영키로 바꿔 사용중입니다
혹시 이통망 IP여부도 확인 가능한가요?
한국은 이동통신망, 일부 기업, 자체 회선에서 사용하는거 같네요
개인 할당을 안하다보니 퍼센티지에 변화도 거의 없고
1.1.1 쓰던때가 어제같은데