비동기 이터레이션이 필요한 상황 네트워크로 데이터가 여러 번에 걸쳐 들어오는 경우가 흔합니다. 이런 데이터를 필요할 때마다 처리하려면 async 이터레이션을 사용합니다. 이를 위해 async 이터레이터와 async 제너레이터를 활용하고, 반복은 for await..of로 수행합니다 먼저 async 이터레이터가 일반 이터레이터와 어떻게 다른지 확인하고, 다음으로 async 제너레이터가 어떤 형태로 확장되는지 정리한 뒤, 실무에서 자주 나오는 페이지네이션 패턴을 예시로 살펴봅니다 async 이터레이터 문법 비동기 이터레이터는 일반 이터레이터와 구조가 비슷합니다. 차이는 반복 가능한 객체를 만들 때 쓰는 심볼과 next 반환 타입입니다 ...

JSON-RPC가 transport agnostic이라고 불리는 이유는 명세가 데이터의 모양을 정의하고 전송 방식은 강하게 제한하지 않기 때문입니다 프로토콜의 메시지 포맷을 고정해두면, 그 포맷을 어떤 통로로 보내는지는 구현 쪽 선택으로 분리할 수 있습니다 HTTP의 기능에 강하게 기대지 않는 설계 REST는 HTTP의 기능을 비교적 직접적으로 활용합니다 HTTP method로 행위를 구분 HTTP status code로 성공과 에러를 표현 반면 JSON-RPC는 HTTP를 사용하더라도 보통 단일 엔드포인트와 단일 HTTP method 중심으로 동작하는 경우가 많습니다 성공 여부와 에러는 대체로 JSON 본문 안의 result 또는 error로 표현합니다 ...

레디스가 싱글스레드라서 BullMQ에서 job data가 커지면 Redis가 터진다고 단순화해서 말하는 경우가 많음 하지만 실제로는 Redis가 큰 payload 처리 때문에 막히고, 그 지연이 메모리와 네트워크 문제로 이어지며 타임아웃이나 OOM 같은 연쇄 문제로 번지는 쪽이 더 큼 job data가 커질 때 Redis에서 바로 벌어지는 일 1) 이벤트루프가 큰 값 때문에 오래 점유 BullMQ는 job을 만들 때 job data를 보통 Redis에 문자열이나 JSON 형태로 저장함 job data가 커지면 쓰기와 조회 모두에서 처리해야 하는 바이트가 늘어남 SET이나 HSET 같은 쓰기, HGET 같은 조회가 한 명령당 처리해야 하는 바이트를 키움 ...

개요 oh-my-codex, oh-my-claudecode, claw-code를 묶어 보면 에이전트형 코딩 도구는 모델 자체보다 “운영체제 같은 orchestration layer”로 확장된다는 결론으로 수렴한다. 여기서는 Codex CLI와 Claude Code가 skill, agent, sub-agent, tmux worker, PR review, verification loop 같은 자동화를 붙일 수 있는 이유와 바닥 런타임 구조를 층으로 정리한다 핵심은 모델 튜닝이 아니라 다음 조합으로 행동을 바꾸는 접근이다 상위 지시문 skill, prompt, agent 카탈로그 상태 파일과 산출물 디렉터리 hook 또는 세션 부트스트랩 서브에이전트와 tmux worker 검증, 리뷰, 커밋, PR 프로토콜 에이전트형 코딩 도구의 6개 층 Codex CLI, Claude Code, claw-code 같은 도구는 보통 아래 6개 층으로 이해할 수 있다 ...

개념을 먼저 레이어로 분리 HTTP에서 인증을 얘기할 때는 보통 아래 4축으로 보면 정리가 빠름 자격 증명을 매 요청에 직접 보내는 방식 서버가 저장한 상태를 식별자로 조회하는 방식 토큰 자체를 검증하는 방식 외부 인증 또는 권한 위임 프레임워크를 이용하는 방식 조금 더 구조적으로 나누면 다음처럼 분류 가능함 Credential-based Basic Auth Digest Auth API Key Client Certificate mTLS Stateful Identifier-based Session ID Opaque Token Stateless Token-based JWT PASETO 기타 signed token Authentication / Authorization Framework OAuth 2.0 OpenID Connect SAML HTTP 기반 웹 SSO 맥락 여기서 중요한 건 인증과 인가, 전달 메커니즘이 섞여서 헷갈리는 경우가 많다는 점임 ...

컨테이너에 CPU와 메모리를 얼마나 줄지 정하는 설정은 크게 두 가지입니다. request는 최소 보장을 위한 값이고 limit은 최대 상한선입니다. 이 둘을 어떻게 설정하느냐에 따라 스케줄링과 런타임 동작이 달라집니다 Request는 최소 이만큼은 보장해줘 스케줄러는 pod를 노드에 배치할 때 request를 기준으로 자원을 예약합니다. 즉 이 컨테이너는 최소 이만큼 필요하다는 의미이며, 노드에 request만큼의 여유가 없으면 해당 노드에는 올라가지 못합니다. 또한 request만큼의 자원은 다른 pod가 아무리 바빠도 최소한으로는 확보된다고 이해하면 됩니다 Limit은 최대 이만큼까지만 써라 limit은 컨테이너가 넘을 수 없는 상한입니다. limit을 초과하려고 하면 ...

배경 ES6 이후 이터러블(iterable)이나 유사 배열 객체(array-like object)를 실제 배열로 변환하는 상황은 매우 흔합니다. 대표적으로 [...iterable](전개 구문, Spread Syntax)과 Array.from() 메서드를 사용합니다. 두 방식은 대부분의 경우 동일하게 동작하는 것처럼 보이지만, 동작 원리와 지원 범위에 명확한 차이가 있어 상황에 맞게 선택해야 합니다. 핵심 차이점 두 방식의 가장 큰 차이는 변환할 수 있는 소스 객체의 타입입니다. 전개 구문 ([...iterable]) 오직 이터러블 프로토콜을 따르는, 즉 Symbol.iterator 속성을 가진 객체에만 사용할 수 있습니다. NodeList가 이터러블인 최신 브라우저 환경에서는 문제없이 동작하지만, 그렇지 않은 환경에서는 TypeError가 발생합니다. ...

Cron, Crontab, Cronjob 유닉스 계열 운영체제에서 특정 작업을 정해진 시간에 자동으로 실행하려면 Cron을 사용합니다. Cron은 백그라운드에서 동작하는 데몬(daemon)이며, 스케줄링 설정을 바탕으로 명령어나 스크립트를 실행합니다 Cron: 시간 기반 잡 스케줄러(Job Scheduler)로, 특정 시간에 작업을 실행하는 시스템 데몬 Crontab: ‘Cron Table’의 약자로, Cron 작업의 목록과 실행 시간을 정의하는 설정 파일 또는 해당 파일을 다루는 명령어 Cronjob: Crontab에 등록되어 주기적으로 실행되는 개별 작업 이 글에서는 Cronjob을 정의하는 Cron 표현식(Cron Expression)의 구조와 문법을 정리합니다 ...

퍼사드 패턴이란 퍼사드(Façade)는 프랑스어로 ‘건물의 정면’을 의미함. 소프트웨어 공학에서 퍼사드 패턴은 이 개념을 차용해 복잡한 서브시스템의 내부 구현을 숨기고, 클라이언트가 사용하기 쉬운 단일 인터페이스를 제공하는 역할을 함. GoF(Gang of Four)의 디자인 패턴 중 구조 패턴(Structural Pattern)으로 분류됨. 클라이언트는 복잡하게 얽힌 서브시스템에 직접 접근할 필요 없이, 퍼사드 객체가 제공하는 간결한 API를 통해 필요한 기능을 호출할 수 있음. 이를 통해 서브시스템과 클라이언트 간의 결합도(coupling)를 효과적으로 낮출 수 있음. 사용 목적과 장점 퍼사드 패턴의 주요 목적과 장점은 다음과 같음. ...

개념 구분: 요소는 태그가 아니다 HTML을 다룰 때 ‘요소(Element)‘와 ‘태그(Tag)‘를 혼용하는 경우가 많다 흔히 “p 태그"처럼 부르지만 두 개념은 엄연히 다르다 이 차이는 HTML 4.01 명세부터 명확히 강조되었다 요소는 태그가 아니다. 어떤 이들은 요소를 태그라 부르기도 한다(예: “the P tag”). 하지만 요소와 태그(시작 태그든 종료 태그든)는 별개임을 기억해야 한다. 예를 들어, HEAD 요소는 마크업에 시작 태그와 종료 태그가 모두 생략되더라도 항상 존재한다. 즉, 요소는 문서의 구조적 구성원을 의미하며, 태그는 이 요소의 시작과 끝을 마크업에 표기하는 구문일 뿐이다 ...