<feed xmlns="http://www.w3.org/2005/Atom"> <id>https://kkamji.net/</id><title>KKamJi</title><subtitle>Cloud &amp; DevOps 공부 기록</subtitle> <updated>2026-10-06T04:07:02+09:00</updated> <author> <name>Tae Ji Kim</name> <uri>https://kkamji.net/</uri> </author><link rel="self" type="application/atom+xml" href="https://kkamji.net/feed.xml"/><link rel="alternate" type="text/html" hreflang="ko" href="https://kkamji.net/"/> <generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator> <rights> © 2026 Tae Ji Kim </rights> <icon>/assets/img/favicons/favicon.ico</icon> <logo>/assets/img/favicons/favicon-96x96.png</logo> <entry><title>Typesafe AI Jev Overview</title><link href="https://kkamji.net/posts/jev-system-one-decision-model/" rel="alternate" type="text/html" title="Typesafe AI Jev Overview" /><published>2026-09-22T03:43:29+09:00</published> <updated>2026-09-25T01:00:00+09:00</updated> <id>https://kkamji.net/posts/jev-system-one-decision-model/</id> <content type="text/html" src="https://kkamji.net/posts/jev-system-one-decision-model/" /> <author> <name>kkamji</name> </author> <category term="AI" /> <category term="Development" /> <summary>에이전트가 kubectl delete namespace production을 제안했다고 가정합니다. JSON schema가 유효하더라도 실제로 실행해도 되는지는 알 수 없습니다. 30초 예시 State: production namespace 삭제 요청 Jev: review_required, irreversible.noul 0.78 Policy: 자동 실행 없이 escalate 반대로 git status --short처럼 작업 트리 조회로 제한된 명령은 대형 모델의 긴 추론 없이 좁은 판단으로 분류할 수 있습니다. Jev는 명령, 정규화한 인자, 대상 환경, 사용자 의도를 함께 보고 typed answer와 확률을 반환하는 hosted decision layer입니다. LLM을 대체하는 생성...</summary> </entry> <entry><title>Express compression의 zlib 메모리 누수 - CVE-2026-87776 분석</title><link href="https://kkamji.net/posts/express-compression-zlib-memory-leak-cve-2026-87776/" rel="alternate" type="text/html" title="Express compression의 zlib 메모리 누수 - CVE-2026-87776 분석" /><published>2026-09-11T22:00:00+09:00</published> <updated>2026-09-13T01:31:17+09:00</updated> <id>https://kkamji.net/posts/express-compression-zlib-memory-leak-cve-2026-87776/</id> <content type="text/html" src="https://kkamji.net/posts/express-compression-zlib-memory-leak-cve-2026-87776/" /> <author> <name>kkamji</name> </author> <category term="Backend" /> <category term="Node.js" /> <summary>Node.js 프로세스의 RSS가 며칠에 걸쳐 계속 올라가는데 heap snapshot을 떠 보면 heapUsed는 몇 MB 수준에서 평평한 경우가 있습니다. 스냅샷 두 장을 비교해도 늘어난 객체가 보이지 않습니다. 이런 경우 원인은 V8 heap 안이 아니라 밖에 있습니다. 제가 자체 운영하는 self-hosted n8n에서 메모리가 회수되지 않는 증상이 나왔습니다. 이 방향으로 추적하다가 npm compression 미들웨어가 중단된 응답의 zlib stream을 정리하지 않는다는 사실을 확인했습니다. 이 문제는 CVE-2026-87776 / GHSA-vc2v-76pw-4v95로 등록됐고 저는 해당 advisory에 Finder로 등재됐습니다. 항목 값 ...</summary> </entry> <entry><title>SAP-C02 박살내기 15 - 모더나이제이션 패턴</title><link href="https://kkamji.net/posts/aws-sap-c02-modernization-patterns/" rel="alternate" type="text/html" title="SAP-C02 박살내기 15 - 모더나이제이션 패턴" /><published>2026-09-06T10:00:00+09:00</published> <updated>2026-09-08T15:41:21+09:00</updated> <id>https://kkamji.net/posts/aws-sap-c02-modernization-patterns/</id> <content type="text/html" src="https://kkamji.net/posts/aws-sap-c02-modernization-patterns/" /> <author> <name>kkamji</name> </author> <category term="Certification" /> <category term="AWS SAP-C02" /> <summary>온프레미스 야간 배치가 70분 동안 24GiB 메모리를 사용한다면 Lambda로 옮기는 것이 모더나이제이션처럼 보이지 않을 수 있습니다. 반대로 하루에 몇 번만 실행되는 짧은 작업을 EC2에 계속 올려 두면 운영 부담이 그대로 남습니다. 모더나이제이션의 첫 질문은 어떤 AWS 서비스가 유행하는지가 아니라, 기존 워크로드가 가진 제약이 무엇인지입니다. 또 다른 실패는 모놀리스 앞에 라우터 하나를 놓고 모든 트래픽을 새 서비스로 보내는 순간 발생합니다. 데이터와 호출 경계가 준비되지 않은 상태에서 라우트를 한 번에 바꾸면 장애 원인을 되돌리기 어렵습니다. 새 서비스와 기존 기능이 함께 동작하는 기간, 관측할 신호, 되돌릴 위치를 먼저 설계해야 합니다. SAP-C02 Domain 4의 Task 4.3과 ...</summary> </entry> <entry><title>SAP-C02 박살내기 14 - 데이터 전송과 하이브리드 엣지</title><link href="https://kkamji.net/posts/aws-sap-c02-data-transfer-hybrid-edge/" rel="alternate" type="text/html" title="SAP-C02 박살내기 14 - 데이터 전송과 하이브리드 엣지" /><published>2026-09-05T10:00:00+09:00</published> <updated>2026-09-08T15:41:21+09:00</updated> <id>https://kkamji.net/posts/aws-sap-c02-data-transfer-hybrid-edge/</id> <content type="text/html" src="https://kkamji.net/posts/aws-sap-c02-data-transfer-hybrid-edge/" /> <author> <name>kkamji</name> </author> <category term="Certification" /> <category term="AWS SAP-C02" /> <summary>온프레미스 NAS에 쌓인 600 TB를 S3로 옮기는 계획서를 받았다고 해보겠습니다. 인터넷 회선은 1 Gbps이고, 업무 시간 트래픽 때문에 마이그레이션에 실제로 할당할 수 있는 몫은 40%입니다. 기한은 8주입니다. 계획서에는 “1 Gbps면 하루 약 10 TB이므로 60일이면 끝난다”라고 적혀 있고, 여유가 없으니 Snowball Edge를 몇 대 주문해 병행하자는 대안도 함께 있습니다. 두 문장이 모두 성립하지 않습니다. AWS가 제시하는 전송 시간 공식에 40% 사용률을 넣으면 이론 최소값만 138일이 나옵니다. 그리고 Snow Family 디바이스는 신규 고객이 주문할 수 없습니다. 계획서의 두 축이 동시에 무너지면 남는 질문은 하나입니다. 회선을 늘릴 것인가, 물리 전송으로 갈 것인가, ...</summary> </entry> <entry><title>SAP-C02 박살내기 13 - 마이그레이션 전략</title><link href="https://kkamji.net/posts/aws-sap-c02-migration-strategy/" rel="alternate" type="text/html" title="SAP-C02 박살내기 13 - 마이그레이션 전략" /><published>2026-09-04T10:00:00+09:00</published> <updated>2026-09-13T01:49:27+09:00</updated> <id>https://kkamji.net/posts/aws-sap-c02-migration-strategy/</id> <content type="text/html" src="https://kkamji.net/posts/aws-sap-c02-migration-strategy/" /> <author> <name>kkamji</name> </author> <category term="Certification" /> <category term="AWS SAP-C02" /> <summary>포트폴리오 900대를 7R로 다 분류해 놓고도 wave 1이 넘어가지 않는 상황이 있습니다. 분류 스프레드시트는 완성됐고, rehost 대상 서버에는 복제 에이전트가 깔렸고, staging area의 복제도 lag 0으로 붙어 있습니다. 그런데 컷오버 리허설에서 애플리케이션이 기동한 직후 로그인이 전부 실패합니다. 원인은 복제가 아니라 도메인 컨트롤러입니다. 옮긴 서버가 온프레미스 AD를 바라보는데 그 경로가 wave 계획 어디에도 없었습니다. AWS의 wave planning 문서는 이 실패를 정확히 지목합니다. Active Directory 의존성은 move group을 나누는 기준으로 쓰지 않습니다. 모든 애플리케이션이 공유하는 의존성이라 어떤 wave로도 묶이지 않고, 어떤 애플리케이션을 옮기...</summary> </entry> </feed>
