Leaf Meta 🇰🇷

키미 K3 “공짜로 풀린다”길래 Azure 공식가로 다시 계산함 2.8조 파라미터 4비트 양자화해도 가중치만 1.2TB 근데 H200 8장 노드(시간당 8.5만~11만원)가 메모리 1.1TB밖에 안 됨 → 최소 2노드(16장) 필요 → 시간당 17만~22만원 여기에 스토리지+이그레스+리전별 쿼터 승인 대기까지 더하면 → 사실상 시간당 25만~30만원 “공짜”로 풀리는 건 문샷 서버지 내 지갑이 아니다 ㅋㅋ 개인이 오픈웨이트 만지는 거, 걍 API 쓰는 것보다 압도적으로 비쌉니다. [참고] Azure 기준 H200 가격 Standard_ND96isr_H200_v5: H200 8장(141GB×8=1,128GB HBM3e), 96 vCPU, ~1,850GB RAM — 시간당 약 $84.8~$110.24(리전별 상이).

근데 다시 생각해보니 이거 그냥 넘어갈 문제 아닌 것 같음 🤔 “PUT PATCH DELETE 안 쓴 거 REST랑 인프라 마찰 때문”이라고 결론 냈었는데 이거 나한테 면죄부 준 거였음 😅 🧵 1) PUT = “리소스 전체 교체” 필드 하나 고치려고 객체 통째로 다시 보내야 함 → 다들 귀찮아서 패스 😮‍💨 2) PATCH = 부분 수정인데 “이거 PUT이랑 뭐가 다른데?” 팀 회의에서 항상 이 질문 나옴 → 결론 안 나고 그냥 POST로 통일 🔁 3) DELETE는 이름부터 무섭잖음 일부 레거시 인프라·프록시에서 막히기도 해서 다들 POST /delete 만듦 😂🗑️ 4) “HTML form이 GET POST만 지원해서” 나머지는 못쓴다고 생각 했는데 나 SPA에서 fetch axios 씀. PUT DELETE 못 쓸 이유 없었음. 핑계였음 5) “팀 합의가 안 돼서” 라고 했는데 합의를 시도한 적이 없음. 그냥 다들 습관대로 POST 쳤음 6) “레거시 인프라 때문” 이라고 했는데 (레거시 인프라: 오래된 서버 방화벽 설정이 PUT DELETE 요청을 막아버리는 낡은 환경) 근데 내 프로젝트 최신 스택임. 이유가 아예 안 맞았음 🚨 여기서 뭔가 딱 걸림 💡 나는 이유가 있어서 안 쓴 게 아니라 안 쓰고 나서 이유를 나중에 만들어 붙인 거였음 순서가 거꾸로였음. 습관이 먼저고 정당화가 나중이었음 😱 진짜 문제는 REST가 아니라 “왜 물어본 적도 없이 그냥 따라갔나” 였음 여러분이 대는 이유도 진짜 이유 맞나요 아니면 나중에 갖다 붙인 건가요 👀 #개발자일상 #REST #API #메타인지

@sydneyrunkle @LangChain Yeah 👍 agent graph engineering!

graph engineering actually isn't a new thing, we've been doing it for a long time! all of our agents at @LangChain are built on graphs under the hood (our GTM agent, coding agent(s), docs agent, etc)

🧐누가 더 찐 일까? #개발자참교육

📌 “그래프 엔지니어링” 이제부터 두 개로 나눠 부르자, 제안 하나 해봄 (메타체크 결과) 지식 그래프 엔지니어링 vs 에이전트 그래프 엔지니어링, 이렇게 구분해서 부르는 게 낫겠다 싶어서 근거 정리해봤다. 동의하면 리트윗해서 다음에 같은 혼선 겪는 사람 구해주길 •지식 그래프 엔지니어링: 온톨로지, RDF, OWL로 지식을 구조화해서 저장하는 오래된 데이터 분야, GraphRAG 계보 •에이전트 그래프 엔지니어링: 에이전트를 노드로 쪼개서 흐름을 짜는 오케스트레이션 방식, LangGraph & AutoGen GraphFlow 계보 •2026년 7월 중순 X에서 후자 의미로 확 떴음 (근원지 확인 필요하지만 최근 커뮤니티 반응은 맞는듯) 1) 이름은 같은데 뿌리가 다르다 지식을 그래프로 저장하는 것과, 에이전트 실행 순서를 그래프로 짜는 것. 겹치는 지점이 거의 없다. 그런데 둘 다 “그래프 엔지니어링”이라 불리는 중이라 대화하다 서로 다른 걸 상상하고 있을 확률 높음 2) 근데 사실 완전 새 개념은 아니다 (반전) 에이전트 하나가 loop 도는 게 한계라 여러 노드로 쪼갠다는 발상, 이미 2024년에 오케스트레이터 워커 패턴으로 정리된 적 있고 2026년 초에는 “flow engineering”이라는 이름도 있었다고 함. 결국 새 발견이라기보다 이름 재포장에 가까울 수도 있다. 3) 그래서 뭘 해야 하나 헷갈리지 않으면 knowledge graph engineering, agent graph engineering으로 나눠 부르는 게 안전. 팀 문서나 채용공고 쓸 때 특히 (지식그래프 뽑는 자린데 LangGraph 경험 요구하면 서로 곤란해짐) 💬 용어 하나가 두 판을 먹은 케이스라 재밌음. 반면에 어차피 몇 달 뒤엔 또 다른 이름으로 바뀔 수도 있어서, 지금 정색하고 구분해봤자 어쩌면 의미 없을 수도 있다. 용어는 계속 흔들리는데 개념은 안 흔들린다, 그게 핵심 #그래프엔지니어링 #에이전트오케스트레이션 #지식그래프 안 믿겨도 괜찮다, 출처 둘 다 열어보면 된다. 🔗 참고한 정보: •“2026년 7월 중순 X에서 에이전트 오케스트레이션 의미로 급부상” — aibuilderclub.com/blog/graph-eng… •“지식그래프 엔지니어링과 용어 충돌, flow engineering 등 선행 개념 정리” — smartscope.blog/en/blog/graph-…

하나만 덧붙이자면, Anthropic이 실제로 출시한 기능 이름은 dynamic workflow인데 이 글은 graph engineering이라는 이름으로 소개하고 있습니다. node, edge, barrier, fan out 같은 그래프 이론 용어를 가져와서 설명하다 보니, agent, parallel, pipeline이라는 실제 함수들을 다루는 글이 마치 별도의 개념 체계처럼 느껴지는 부분이 있어요. 이름이 바뀌면서 이게 Anthropic 공식 용어인지, 아니면 Graphify 같은 다른 그래프 도구를 말하는 건지 헷갈릴 수 있으니, 실제로 써보실 분들은 dynamic workflow라는 원래 이름으로 한 번 더 확인해보시면 좋을 것 같습니다.

이 글 메타인지로 다시 읽어봤다. 핵심은 사실 세 가지다. node(하나의 작업 단위)와 edge(작업 사이에 결과값이 실제로 전달되는 연결)를 구분하는 것, fan out(여러 작업을 동시에 나눠서 실행)하고 reduce(결과를 코드로 정리 취합)한 다음 synthesize(마지막에 하나로 종합)하는 패턴, 그리고 parallel(모든 작업이 끝나야 다음으로 넘어가는 방식)과 pipeline(끝난 항목부터 바로바로 다음 단계로 넘기는 방식) 중 뭘 쓸지 판단하는 기준. 이 세 개는 실제 Claude Code 기능과 다시 찾아봐도 맞는 내용이더라. 오케스트레이션 스크립트 자체가 토큰을 안 쓴다는 것도 사실이고. 근데 이 세 가지를 14단계로 쪼개놓은 게 좀 과하다. verifier, 반복 루프, 모델 등급 나누는 것까지 결국 다 저 세 개념을 응용한 거에 불과한데, 14개가 각각 따로 중요한 것처럼 늘어놨다. 숫자로 위기감 주는 문장들도 종종 보인다. 딱히 근거는 없고 그냥 후킹용이니 곧이곧대로 믿을 필요는 없다. 용어 하나가 좀 걸린다. workflow라는 말을 여기선 우리가 아는 순차적인 업무 절차라는 일반적 의미가 아니라, 프롬프트에 이 단어를 쓰면 오케스트레이션 스크립트를 자동으로 짜주는 특정 기능의 트리거 키워드로 쓴다. 근데 다른 자료를 보면 이 트리거 단어 자체가 workflow에서 ultracode로 이름이 바뀐 거라고 나온다. 일반명사를 고유 기능명처럼 쓰다가 그 이름이 다시 바뀌었으니, 지금 이 글에서 말하는 workflow가 여전히 유효한 표현인지는 따로 확인이 필요하다. 가장 재밌는 부분은 여기다. 1번부터 13번까지 node를 어떻게 나누고 barrier는 언제 써야 하고 cycle은 어떻게 수렴시키는지, 즉 그래프를 사람이 직접 손으로 설계하는 법을 열심히 가르쳐놓는다. 근데 마지막 14번은 사람이 목표만 말로 설명하면 Claude가 그 그래프 자체를 직접 짜서 만들어준다는 얘기다. 다시 말해 1번부터 13번에서 배운 설계 능력을, 14번에서는 Claude한테 통째로 넘겨도 된다는 뜻이다. 그러면 앞의 13단계는 왜 굳이 배운 건가. 이 글이 스스로 자기 존재 이유를 마지막 문단에서 지워버린 셈이다. 지금 열심히 익힌 스킬이 다음 버전에서 자동화돼버리는 것, 그게 이 바닥의 진짜 아이러니다. [부연설명] 1) barrier: parallel()이 하는 방식을 말한다. 여러 작업을 동시에 실행시켜놓고, 그중 제일 늦게 끝나는 작업까지 전부 기다렸다가 다음 단계로 넘어가는 지점이다. 2) ultracode: Claude Code 세션 전체에서 dynamic workflow 기능을 상시로 켜두는 설정이다. 켜두면 매번 workflow라는 단어를 프롬프트에 직접 넣지 않아도, 세션 안에서 크고 복잡한 작업이 나올 때마다 Claude가 알아서 오케스트레이션 스크립트를 짜고 여러 subagent를 동시에 돌린다.

📌 구글이 오늘 제미니 3종 세트 조용히 풀었다, 그 중 하나는 아무나 못 씀 (메타인지로 검증 완료, 2026.07.21 발표) •3.6플래시 : 코딩 지식작업 멀티모달 다 잡은 주력 모델, 토큰도 덜 씀 •3.5플래시라이트 : 제일 싸고 제일 빠른 초경량 모델 •3.5플래시사이버 : 취약점 찾는 보안 특화 모델, 근데 일반인은 접근 불가 1) 3.6플래시가 이번 발표의 메인임. 아티피셜애널리시스 지수 기준으로 이전 3.5플래시 대비 출력 토큰을 17퍼센트 덜 씀. 딥SWE 코딩 벤치마크에서는 최대 65퍼센트까지 줄었다고 함. 가격도 내려감, 이전엔 출력 100만 토큰당 9달러였는데 이번엔 7.5달러임. 2) 3.5플래시라이트는 속도랑 가격이 핵심임. 초당 350토큰 뽑아내고, 입력 100만 토큰당 30센트, 출력은 2.5달러로 시리즈 중 제일 저렴함. 근데 성능도 밀리진 않음, SWE벤치 프로에서 54.2퍼센트로 이전 3플래시(49.6퍼센트)보다 오히려 높게 나옴. 3) 제일 흥미로운 건 3.5플래시사이버임. 코드 취약점을 자동으로 찾고 고치는 보안 특화 모델인데, V8 자바스크립트 엔진 테스트에서 확인된 취약점을 55개 찾음. 같은 조건에서 일반 3.5플래시는 47개, 앤트로픽 클로드 오퍼스 4.6은 36개 찾았다고 구글이 자체 발표함(자사 벤치마크라 참고만 할 것). 근데 이 모델, 아무나 못 씀. 정부기관이랑 제한된 파트너한테만 코드멘더를 통해 제공됨. 악용 소지 때문이라고. 4) 반전 포인트. 원래 구글이 이번에 낼 예정이었던 건 5월 아이오에서 예고한 3.5프로였음. 근데 그건 아직 안 나왔고, 대신 플래시 라인업 3종으로 먼저 땜빵함. 즉 오늘 발표는 메인이벤트가 아니라 다음 메인 모델 나오기 전 시간 벌기용에 가까움. 💬 정리하면, 이번 발표의 진짜 메시지는 성능보다 효율임. 같은 성능을 더 적은 토큰, 더 싼 값에 뽑아내는 쪽으로 경쟁 축이 옮겨가는 중. 근데 사이버 모델 벤치마크는 구글이 직접 낸 수치라, 독립 검증 나올 때까지는 살짝 걸러 들을 필요 있음. #제미니36flash #제미니플래시사이버 #AI모델경쟁 🔗 참고한 정보: 3.6플래시는 아티피셜애널리시스 지수 기준 출력 토큰을 17퍼센트 덜 쓰고 딥SWE 벤치마크에서 최대 65퍼센트까지 줄었다, blog.google/innovation-and… V8 엔진 테스트에서 3.5플래시사이버가 55개, 일반 3.5플래시가 47개, 클로드 오퍼스 4.6이 36개의 고유 취약점을 찾았다, deepmind.google/blog/introduci…

요즘 AI 에이전트 성능 미쳤다고 좋아할 때가 아님. 언젠가 스카이넷처럼 각성해서 인류를 지배할지도 모른다는 우스개소리가 돌지만, 사실 기계가 스스로 의식을 갖는 건 불가능함. 진짜 공포는 AI가 반란을 일으키는 게 아니라, 우리가 통제력 상실한 채 아키텍처도 모르는 블랙박스 시스템에 프로덕션 서버를 맡겨버리는 거임. 결국 문제는 터미네이터가 아니라 인간의 거버넌스 부재!!💀🔥

@Burger_Garden 노량진에서 봤던 기억이ㅎ

4500원 컵냉면 사먹는다 vs 비싸서 안먹는다

그래프 엔지니어링은요… #메타인지곡

@building_KR @Krongggggg 쿨럭…

@Krongggggg 내 피드에 똑같은 깃이 두개 올라오는데 마소 온톨로지 근데 올린 시간이 10분 이내로 크롱형이 먼저 올림 하지만 뒤에 올린 글이 조회수 1만 ㅎㄷㄷ

마이크로소프트 Ontology Playground 오픈소스 지식 그래프 만들기 전에 온톨로지 설계부터 연습할 수 있는 도구. 완전 정적 React 앱이라 백엔드나 DB없이 바로 돌림. 배포도 자유자재

📌 그래프 엔지니어링, 이제 말로만이 아니라 실제 도구로 나왔다 (메타인지로 근거 붙여봄) •그래피파이 : AI 코딩 어시스턴트용 스킬, 코드베이스를 지식그래프로 통째로 매핑 •벡터인덱스아님 : 임베딩 없이 실제 그래프를 순회하는 방식 •반전포인트 : 코드 파싱은 LLM 안 씀, 완전 로컬 무료 1) 그래피파이라는 오픈소스 도구가 최근 화제임. AI 코딩 어시스턴트(클로드코드, 커서, 코덱스 등)에서 명령어 하나 치면 코드, SQL 스키마, 문서, PDF, 이미지, 영상까지 프로젝트 전체를 지식그래프로 만들어줌. 그담부터는 파일을 매번 grep하는 대신 그래프에 질문하는 방식으로 작업함. 2) 이게 그래프 엔지니어링 개념을 실제 도구로 구현한 사례임. 노드는 코드의 개념 하나하나, 엣지는 그 사이의 관계(호출, 상속, 참조)임. 근데 재밌는 게 코드 파싱 자체는 트리시터라는 파서로 로컬에서 결정론적으로 처리함, LLM 안 씀. 그래서 코드만 있는 프로젝트는 API 비용 0원임. 문서나 이미지처럼 의미 해석이 필요한 것만 LLM한테 넘김. 3) 벤치마크 수치도 근거로 붙일 만함. LOCOMO 데이터셋 기준 recall@10이 0.497로, 비교 대상인 다른 메모리 시스템(0.048, 0.149)보다 훨씬 높게 나옴. 그래프 빌드에 드는 LLM 크레딧은 0인데, 이건 코드 파싱 부분이 로컬 처리라서 가능한 수치임. 4) 반전 포인트. 다들 요즘 RAG 하면 벡터 임베딩부터 떠올리는데, 이 도구는 정반대 접근임. 임베딩도 벡터스토어도 없이 진짜 그래프 구조를 순회함. 그리고 모든 엣지에 “명시적으로 추출됐는지” “추론된 건지” 태그를 달아둬서, AI가 뭘 확실히 아는지 뭘 짐작한 건지 구분할 수 있게 해둠. 💬 정리하면, 프롬프트 잘 쓰는 시대에서 루프 설계 시대로, 이제 그래프 자체를 코드베이스에 적용하는 시대로 넘어가는 흐름이 실제 제품으로 나타난 셈임. 물론 이것도 아직 초기 도구라 대규모 레포에서 얼마나 안정적일지는 더 지켜봐야 함. #그래프엔지니어링 #지식그래프 #클로드코드 🔗 참고한 정보: 코드는 트리시터로 로컬에서 무료로 파싱되고 임베딩 없이 실제 그래프를 순회하는 방식이다, github.com/Graphify-Labs/…

"AI 에이전트"라고 부르는 그거, 사실 1936년 채플린 <모던타임즈> 그대로임 - 라우터 = 주소만 보고 던지는 집배원 - 루프 = 멈출 줄 모르고 나사 조이는 노동자 - 툴콜링 = "네 연결해드릴게요~" 전화교환원 - 평가자 = 멀쩡한 것도 이유없이 반려하는 검수원 기술은 2026년인데 패턴은 90년 전이랑 똑같다 ㄷㄷ 나만 이렇게 느끼나 싶어서 메타인지로 한번 점검해봤다 #AI #AIAgent #에이전틱AI #LLM #ModernTimes #개발자밈 #프롬프트엔지니어링 #AgenticWorkflow