이번 달 많이 추천된 글
이번 달 추천이 많이 모인 글이 생기면 여기에서 바로 보여줍니다.
최근 베스트
Microsoft MarkItDown — PDF, Word, PPT, 이미지 등 모든 파일을 마크다운으로 변환
마이크로소프트가 오픈소스로 공개한 Python 도구입니다. PDF, PowerPoint, Word, Excel, 이미지, 오디오, HTML, CSV, JSON, XML, ZIP까지 거의 모든 포맷을 마크다운으로 변환해줍니다. LLM에 문서를 넣을 때 전처리 파이프라인으로 바로 쓸 수 있고, MCP 서버도 지원해서 Claude Desktop에서 바로 연동 가능합니다. OCR 플러그인으로 이미지 속 텍스트 추출도 됩니다. pip install markitdown[all] 한 줄이면 설치 끝.
HappyHorse: 생성과 편집을 한 화면에 묶은 AI 비디오 툴
공개 랜딩 기준으로 HappyHorse는 AI 영상 생성과 편집을 함께 제공하는 비디오 제작 플랫폼이다. 로그인 전에는 세부 기능이 거의 보이지 않고, 핵심 진입점은 ‘Generate video’와 ‘Edit video’ 두 개다. 그래서 뉴스/시그널보다는 발견 링크로 두고, 확인 포인트는 텍스트·이미지→영상 생성 범위, 편집 기능이 단순 후처리인지 재생성 워크플로우인지, 크레딧 기반 가격이 실사용에 맞는지다.
GPT Image 2 프롬프트 예시 모음: 이미지 기능 만들 때 참고할 레퍼런스
X와 커뮤니티에서 모은 GPT Image 2 프롬프트와 결과 이미지를 카테고리별로 정리한 GitHub 모음. 플랫폼 뉴스라기보다는 이미지 생성 기능을 만들거나 테스트할 때 참고할 샘플셋에 가까워 커뮤니티 발견 링크로 둔다. 사진·게임·UI·포스터·문서·캐릭터 일관성 카테고리를 골라 우리 서비스의 이미지 출력 기준을 잡는 데 쓸 수 있다.
GPT Image 2 + Seedance 2로 게임 콘셉트 영상을 먼저 만든 사례
AI Coffee Chat이 공유한 0xInk_ 사례입니다. 핵심은 게임을 완성한 뒤 홍보 영상을 만드는 흐름이 아니라, 기획 초기에 세계관·캐릭터·장면 톤을 먼저 시각화하고 짧은 영상으로 반응을 확인하는 방식입니다. 실제 플레이 가능한 빌드라기보다는 콘셉트, 무드, 전환 연출을 검증하는 영상형 프로토타입으로 보는 것이 맞습니다. 왜 볼 만한가 - 개발 완료 후 홍보 영상이 아니라, 초기 기획 단계에서 세계관과 장면을 빠르게 구체화합니다. - 이미지 생성과 영상 생성을 따로 쓰는 것이 아니라, 키비주얼 → 장면 → 짧은 시퀀스로 이어지는 조합이 핵심입니다. - 게임 외에도 커머스, 마케팅, 교육, 서비스 기획에서 콘셉트 검증용 MVP로 응용할 수 있습니다. 당장 해볼 것 1. 제품·서비스 콘셉트를 한 문장으로 잡습니다. 2. GPT Image 2 같은 이미지 도구로 키비주얼·캐릭터·장면 3~5개를 만듭니다. 3. Seedance 2 같은 영상 도구로 10~20초 시퀀스를 구성합니다. 4. 팀이나 초기 고객에게 보여주고, 이해도·흥미·구매/참여 의향을 기록합니다. 주의: 원문 댓글에서도 확인되듯 ‘게임 개발 완료’ 사례라기보다 영상형 콘셉트 프로토타입입니다.
Codex Desktop의 remote development 요청, AI 코딩 앱도 결국 VS Code의 원격 워크플로를 넘어야 한다는 신호
이 GitHub 이슈의 핵심은 아주 단순하다. Codex Desktop App이 현재는 로컬 프로젝트만 다루고 있어서, SSH 원격 서버나 클라우드 인스턴스 위에서 작업하는 실제 개발 워크플로에는 잘 들어가지 못한다는 문제 제기다. 작성자는 VS Code Remote SSH처럼 원격 파일 시스템과 서버 환경에서 바로 Codex를 돌릴 수 있어야 한다고 요청한다. thenocodes 관점에서 중요한 건 이게 단순한 편의 기능 요청이 아니라는 점이다. 많은 실전 개발 환경에서 코드는 이미 로컬에 없다. GPU 서버, 보안이 걸린 내부망, 대용량 데이터가 붙은 클라우드 머신, 운영과 가까운 staging 환경에서 바로 작업하는 흐름이 흔하다. 이런 상황에서 AI 코딩 앱이 로컬 폴더 전제만 깔고 있으면, 데모는 좋아도 메인 툴이 되기 어렵다. 이 이슈가 보여주는 더 큰 신호는 AI 코딩 제품 경쟁이 이제 모델 품질만으로는 안 된다는 점이다. 진짜 경쟁은 IDE shell, file system, terminal, remote host, auth, secrets, sync 같은 주변 시스템을 얼마나 자연스럽게 흡수하느냐로 넘어가고 있다. 사용자는 더 똑똑한 답변만 원하는 게 아니라, 이미 굴러가는 개발 환경 안으로 에이전트가 들어오길 원한다. 특히 remote development는 중요하다. 로컬 노트북에서 가볍게 코딩하는 순간보다, 원격 Linux 서버에서 빌드하고 로그 보고 GPU 붙여 실험하는 순간이 훨씬 실무에 가깝기 때문이다. 그래서 Codex Desktop이 원격 개발을 지원하지 않으면, 결국 브라우저 데모나 로컬 보조 도구의 인상을 벗기 어렵다. 한 줄로 요약하면 이렇다. AI 코딩 앱이 VS Code 대체재나 동급 동반자가 되려면, 채팅 성능보다 먼저 원격 개발이라는 현실 세계의 기본 인프라를 먹어야 한다.
“8GB VRAM으로 405B 로컬 추론”은 모델을 다 올린다는 뜻보다, offloading으로 초거대 모델 접근성을 넓히는 흐름에 가깝다
이 X 포스트의 핵심은 AirLLM이라는 프로젝트를 근거로, 이제 8GB VRAM만으로도 405B 규모 LLM을 로컬에서 돌릴 수 있다는 주장이다. 연결된 GitHub README를 보면 AirLLM은 메모리 사용량을 최적화해 70B를 단일 4GB GPU에서, 나아가 Llama 3.1 405B도 8GB VRAM에서 추론할 수 있다고 설명한다. 하지만 thenocodes 관점에서 이 문구는 그대로 받아들이기보다 구조를 정확히 읽는 게 중요하다. 이건 보통 "405B 모델 전체를 8GB VRAM에 올린다"는 뜻이 아니라, 레이어 단위 로딩, 디스크/메모리 오프로딩, 필요 시점에만 일부를 올리는 방식으로 어떻게든 추론을 성립시키는 쪽에 가깝다. 즉 기술적으로는 매우 흥미롭지만, 사용자 체감은 전통적인 의미의 "로컬 고성능 실행"과는 다를 수 있다. 연결된 README도 그 점을 어느 정도 드러낸다. AirLLM은 메모리 최적화와 레이어 분할 저장을 강조하고, 디스크 공간이 많이 필요하다고 명시한다. 병목이 GPU 계산보다 디스크 로딩에 있다는 설명도 나온다. 다시 말해, VRAM이 적어도 초거대 모델을 만질 수 있게 해주는 접근이지, 8GB GPU가 갑자기 405B를 쾌적하게 돌리는 마법은 아니다. 그럼에도 이 흐름이 중요한 이유는 분명하다. 에이전트 시대에는 꼭 최고급 GPU가 없어도, 느리더라도 큰 모델을 로컬에서 시험하고 연결하고 조합해보려는 수요가 커진다. 이런 프로젝트는 "저사양에서도 거대 모델을 완전히 배제하지 않는 선택지"를 만든다는 점에서 의미가 있다. 특히 프라이버시, 오프라인 환경, 프로토타이핑, 연구 실험 쪽에서는 유효하다. 한 줄로 요약하면 이렇다. 8GB VRAM으로 405B를 돌린다는 말은 과장된 headline처럼 보일 수 있지만, 그 밑에 있는 진짜 신호는 초거대 모델 사용의 병목을 VRAM 한계에서 운영 방식 문제로 바꾸려는 로컬 추론 엔지니어링의 진전이다.
Tesla Optimus 3세대 구조로 추정되는 팔·관절 특허 공개, 휴머노이드는 모델보다 메카 설계가 다시 중요해진다는 신호
이 X 포스트의 핵심은 Tesla Optimus 3세대 구조로 추정되는 로봇 팔 및 관절 관련 특허가 공개됐다는 점이다. 아직 공식 제품 발표나 성능 시연은 아니지만, 이런 특허 공개는 휴머노이드 경쟁이 단순 데모 영상 단계에서 실제 메카니컬 패키징과 원가, 내구성, 유지보수 구조 경쟁으로 더 깊게 들어가고 있다는 신호로 읽을 수 있다. thenocodes 관점에서 흥미로운 이유는, 휴머노이드 담론이 요즘 너무 쉽게 "모델이 더 똑똑해졌다" 쪽으로만 쏠리기 때문이다. 그런데 실제 제품화는 팔, 손목, 어깨, 관절, 구동부, 배선, 열관리, 조립성 같은 아주 물리적인 문제에서 갈린다. 특허가 진짜 차세대 Optimus 구조와 맞닿아 있다면, Tesla가 결국 어떤 형태로 강성, 가동 범위, 경량화, 원가 절감을 동시에 잡으려 하는지 엿볼 수 있는 단서가 된다. 이런 자료가 중요한 또 다른 이유는 embodied AI의 병목이 소프트웨어 하나로 해결되지 않는다는 점을 다시 보여주기 때문이다. 로봇이 현장에서 반복 작업을 하려면 정책 모델만 좋아서는 안 되고, 그 정책이 안정적으로 실릴 하드웨어 플랫폼이 필요하다. 즉 휴머노이드 경쟁은 foundation model 경쟁의 연장이 아니라, 메카 설계와 제어, 서비스성까지 포함한 시스템 경쟁이다. 그래서 이 포스트는 단순 "테슬라 또 특허 냈다"보다, 휴머노이드 시장이 이제 본격적으로 산업 설계 게임에 들어가고 있다는 신호로 보는 편이 맞다. 앞으로 의미 있는 격차는 화려한 데모보다, 어떤 구조가 더 싸고 튼튼하고 정비 가능하며 대량 생산에 유리한지에서 갈릴 가능성이 크다.
중국 휴머노이드 대여 단가 급락, embodied AI도 “행사 데모 시장”에 머물면 바로 상품화된다는 신호
이 기사의 핵심은 중국 휴머노이드 로봇 대여 시장이 수요 폭증과 가격 붕괴를 동시에 겪고 있다는 점이다. 작년 초 하루 3만 위안 수준이던 대여료가 1년 만에 3000위안 안팎까지 내려왔고, 일부 기본형은 1000위안 이하로도 떨어졌다고 한다. 관련 업체 수도 15만 곳을 넘길 정도로 급증했다. thenocodes 관점에서 중요한 건 숫자 자체보다 구조다. 기사에 따르면 현재 수요의 중심은 상업 공연, 개업 행사, 관람객 안내, 각종 이벤트 같은 "보여주기형" 용도다. 이런 시장은 처음엔 희소성과 화제성 덕분에 높은 가격을 받지만, 공급자가 늘어나는 순간 거의 바로 가격 경쟁으로 무너진다. 즉 embodied AI가 실제 산업 workflow 안에 깊게 들어가지 못하고 데모성 수요에 머무르면, 생각보다 훨씬 빨리 상품화되고 마진이 사라질 수 있다는 신호다. 더 흥미로운 부분은 비용 구조다. 기사에 나온 현장 관행은 로봇 한 대당 엔지니어 한 명이 따라가는 식이라서, 단순 대여료만으로는 수익성이 거의 남지 않는다고 한다. 결국 돈은 대여 그 자체보다 설치, 운영, 유지보수, 현장 대응 같은 서비스 레이어에서 나온다. 이건 AI 에이전트 시장과도 닮았다. 모델이나 하드웨어 본체보다, 실제 현장에 붙여 돌아가게 만드는 운영 계층이 더 큰 가치가 될 수 있다는 뜻이다. 그래서 이 뉴스는 "중국 휴머노이드 붐"보다, 로봇이든 에이전트든 결국 일회성 쇼가 아니라 반복되는 실제 업무 수요를 잡아야 살아남는다는 사례로 읽는 편이 맞다. 산업단지 순찰, 보안 점검, 현장 물자 이동처럼 상시성이 있는 use case로 넘어가야 하고, 전국 단위 서비스망이나 운영 체계가 없으면 공급 과잉 속에서 바로 가격이 무너진다. 한 줄로 요약하면 이렇다. embodied AI의 문제는 더 멋진 데모를 만드는 것보다, 데모 이후에도 돈이 남는 반복 운영 구조를 만들 수 있느냐에 있다.
Claude Code prompt cache window이 짧아지면, 긴 코딩 세션 운영 방식도 달라진다는 신호
이 LinkedIn 포스트의 핵심은 Claude Code 계열 사용 경험에서 프롬프트 캐시 리셋 주기가 예전보다 훨씬 짧아졌다는 체감이 퍼지고 있고, 그 결과 긴 세션에서 토큰 사용량이 갑자기 불어날 수 있다는 점이다. 글의 설명대로라면 문제는 단순 지연이 아니라 비용 구조다. 대화 맥락이 서버 쪽 캐시에서 유지되는 동안엔 앞부분 컨텍스트를 매번 다시 밀어넣지 않아도 되지만, 캐시가 짧은 주기로 리셋되면 조금만 쉬었다가 이어도 긴 문맥이 다시 전체 입력으로 들어가면서 토큰이 급증할 수 있다. 특히 Claude Code처럼 한 세션 안에서 코드베이스 문맥을 길게 쌓아두는 워크플로에서는 체감이 크다. 흥미로운 지점은 여기서 나온 대응 방식이다. 포스트 작성자는 tmux 기반 keepalive 플러그인을 만들어 4분 50초마다 의미 없는 메시지를 보내 캐시를 유지하려 했다. 이건 해킹에 가깝지만, 반대로 말하면 에이전트 UX가 아직 모델 자체 성능만으로 결정되지 않고 캐시 정책, 세션 지속성, 비용 모델 같은 운영 레이어에 크게 좌우된다는 뜻이기도 하다. thenocodes 관점에서 중요한 포인트는 두 가지다. 첫째, 장시간 코딩 에이전트는 단순 채팅이 아니라 세션 시스템으로 봐야 한다는 점. 둘째, 앞으로는 모델 품질만큼이나 "문맥을 얼마나 오래, 얼마나 싸게 유지할 수 있는가"가 실제 생산성을 가를 가능성이 크다는 점이다. 결국 에이전트 시대의 경쟁력은 모델 IQ뿐 아니라 cache window, resume UX, context compaction, background session 같은 시스템 설계에서 갈릴 수 있다. 다만 이 포스트의 수치와 정책 변화는 공식 문서 확인이 더 필요하다. 그래서 확정 사실로 박기보다, 사용자들이 실제로 체감하는 비용/세션 문제와 그 임시 우회법을 보여주는 현장 신호로 보는 편이 적절하다.
Nous Tool Gateway, “구독 하나로 모델 300개”는 API 묶음이라기보다 에이전트용 게이트웨이로 보는 게 맞다
Threads에 올라온 요지는 Nous Research가 Tool Gateway를 내놨고, 하나의 구독으로 300개 이상의 모델과 브라우저 자동화, 이미지 생성, TTS 같은 서드파티 툴을 함께 쓸 수 있다는 점이다. 이 표현은 매력적이지만, thenocodes 관점에서는 정확히 해석할 필요가 있다. 이런 서비스는 보통 "모든 모델의 원본 API를 무제한으로 직접 제공한다"기보다, 하나의 게이트웨이 계층을 두고 여러 모델/툴을 에이전트가 공통 인터페이스로 부를 수 있게 만드는 쪽에 가깝다. 즉 핵심 가치는 모델 수 자체보다, 에이전트가 여러 공급자를 한 환경에서 오케스트레이션할 수 있는 운영 레이어에 있다. 그래서 "구독 하나로 300개 모델"이라는 말은 마케팅 문구로는 맞을 수 있어도, 실제 사용자는 몇 가지를 따져봐야 한다. 첫째, 진짜로 모든 모델에 동일 품질/동일 한도가 열려 있는지. 둘째, 어떤 모델이 프록시 제공인지, 어떤 모델이 자체 계약형인지. 셋째, rate limit, fair use, 지연시간, 안정성, 로그 가시성은 어떤지. 넷째, 에이전트가 모델만 쓰는 게 아니라 브라우저·이미지·음성 툴까지 함께 묶였을 때 실제 workflow가 얼마나 매끄러운지다. 그럼에도 이 흐름이 중요한 이유는 분명하다. agentic engineering의 다음 단계는 특정 모델 하나를 잘 쓰는 것보다, 다양한 모델과 툴을 하나의 작업 환경에서 비용/속도/품질 기준으로 라우팅하는 문제로 가고 있기 때문이다. 그런 의미에서 Tool Gateway는 "300개 모델"보다 "에이전트용 멀티모델 오케스트레이션 레이어"로 보는 편이 더 정확하다.
Qwen3.6-35B-A3B 4bit를 맥북 M4 32GB에서 로컬로 굴리는 흐름, 오픈클로 쪽에도 꽤 맞는 신호
Threads 포스트 자체는 짧았지만, 연결된 글까지 보면 포인트는 분명하다. Qwen3.6-35B-A3B의 MLX 4bit 버전이 맥북 M4 32GB에서 로컬로 충분히 돌아가고, 특히 에이전트 코딩과 MCP 도구 사용 능력이 이전 세대보다 꽤 좋아졌다는 흐름이다. 연결된 정리 글 기준으로 이 모델은 총 35B 파라미터 MoE지만 추론 시 활성 파라미터는 3B 수준이라서, Apple Silicon에서도 로컬 구동 현실성이 있다. 4bit 기준 다운로드 크기는 약 19GB, 실사용 RAM은 대략 22~26GB 수준으로 정리돼 있고, 32GB 통합 메모리면 4K~16K 컨텍스트 범위에서 비교적 안정적으로 쓸 수 있다는 계산이다. thenocodes 관점에서 중요한 건 단순히 "맥북에서 대형 모델 돌린다"가 아니라, 로컬 agentic workflow의 실용성이 올라간다는 점이다. 특히 정리 글에서 강조한 부분처럼 Terminal-Bench, MCPMark, NL2Repo 쪽 개선이 실제라면, 코드 에이전트나 오픈클로 계열 워크플로에 연결해서 로컬 추론 + 도구 호출 조합을 시험해볼 가치가 커진다. 클라우드 모델 의존도를 낮추거나, 오프라인/저비용 환경에서 에이전트 코딩을 굴리고 싶은 사람에게 꽤 흥미로운 선택지다. 물론 이걸 바로 클로드 대체처럼 보면 과하다. 긴 컨텍스트, 복잡한 다단계 추론, 안정성, 실전 디버깅 품질은 직접 써봐야 한다. 그래도 "Apple Silicon 로컬 모델도 이제 체험용이 아니라 실제 agent workflow 후보군에 들어온다"는 신호로는 충분히 의미가 있다.
Claude Opus 4.7 system prompt 유출 신호, 프롬프트 설계 감각을 볼 자료
Threads에 올라온 매우 짧은 포스트인데, 핵심은 Claude Opus 4.7의 시스템 프롬프트가 유출되었고, Claude Code나 시스템 프롬프트 설계에 관심 있는 사람이라면 꼭 읽고 분석해볼 만하다는 신호다. thenocodes 관점에서 중요한 건 단순히 "유출됐다"는 가십보다, 실제 프로덕션급 모델이 어떤 톤, 안전장치, 우선순위, 역할 정의를 시스템 레벨에서 어떻게 잡는지 엿볼 수 있다는 점이다. 시스템 프롬프트는 결국 에이전트의 행동 반경, 거절 방식, 도구 사용 태도, 사용자 응대 결을 결정하는 핵심 레이어라서, 잘 만든 프롬프트 하나를 분석하는 것만으로도 설계 감각을 많이 얻을 수 있다. 특히 agentic engineering 쪽에서는 이걸 그대로 베끼는 게 아니라, 어떤 규칙이 왜 들어갔는지 뜯어보는 게 더 중요하다. 예를 들면 역할 고정 방식, 안전과 유용성의 균형, 불확실성 표현 방식, 길이 조절, 사용자 의도 해석 방식 같은 요소를 체크리스트로 읽어보면 자기 에이전트 프롬프트를 다듬는 데 꽤 도움이 될 수 있다. 다만 실제 유출본은 출처 진위와 최신성 검증이 필요하다. 그래서 바로 "공식 동작 규칙"처럼 받아들이기보다, 프로덕션 시스템 프롬프트가 어떤 구조를 가지는지 보는 레퍼런스 샘플로 다루는 편이 적절하다. 그래도 프롬프트 엔지니어링을 넘어서, 시스템 레벨 행동 설계를 공부하려는 사람에겐 충분히 볼 가치가 있는 신호다.
Codex 안에서 이미지·GIF까지 다루는 흐름이 개발과 디자인 경계를 더 무너뜨리는 신호
이 Threads 글의 요지는 새 기능 자체보다, Codex 같은 코딩 에이전트 안에 이미지 생성·편집, GIF 제작이 붙으면서 개발 워크플로가 더 이상 코드만 다루는 흐름이 아니게 됐다는 점이다. 기존에는 프론트엔드 작업이나 UI 구현을 하다가 에셋이 필요하면 외부 이미지 툴이나 별도 창으로 나가야 했다. 그런데 글에서 짚은 변화는 이제 코드 작성 흐름 안에서 바로 필요한 시각 자산을 만들고 수정할 수 있게 되었다는 것이다. 즉 "개발 -> 디자인 툴 이동 -> 다시 구현"이 아니라, 한 에이전트 워크플로 안에서 기획, 자산 생성, UI 조정, 코드 반영이 더 가까워진다. thenocodes 관점에서 중요한 포인트는 이게 단순 편의성 추가가 아니라 agentic engineering의 범위를 넓힌다는 점이다. 예전에는 코딩 에이전트가 텍스트와 코드 중심이었다면, 앞으로는 화면 자산, 마이크로 인터랙션, GIF, UI 요소까지 포함해 결과물을 더 완결된 단위로 만들어내는 방향으로 간다는 신호다. 개발과 디자인의 경계가 무너진다는 표현도 결국 "한 사람이 다 한다"보다, "한 워크플로 안에서 더 많은 단계를 에이전트가 흡수한다"에 가깝다. 실무적으로는 특히 랜딩페이지, 프로토타입, 마이크로 에셋, 제품 소개 화면 같은 영역에서 체감이 클 수 있다. 코드와 시각 자산이 분리된 파이프라인보다, 필요한 순간에 즉시 만들고 바로 반영하는 루프가 훨씬 짧아지기 때문이다. 글에서도 이후 gpt-image 계열 업그레이드와 더 강한 이미지 기반 프론트엔드 구현 모델이 결합되면 이 흐름이 더 세질 가능성을 암시한다. 다만 여기서 바로 "텍스트 몇 줄이면 기획부터 디자인, 개발까지 끝난다"로 받아들이면 과장될 수 있다. 실제로는 브랜드 판단, 정보 구조, 사용성 검토, 마감 디테일 같은 부분에서 여전히 인간 검수가 중요하다. 그래도 방향성은 분명하다. 코딩 에이전트는 이제 코드 생성기보다, 에셋 제작까지 흡수하는 제품 제작 워크플로 엔진으로 진화하고 있다.
AI가 만든 UI가 왜 비슷비슷해 보이는지, 디자이너 관찰로 정리한 신호들
이 LinkedIn 글은 “AI가 만든 UI는 왜 비슷하게 느껴지는가”를 디자이너 시선에서 꽤 잘 짚는다. 핵심은 특정 툴 비판보다, 생성형 UI가 자주 반복하는 시각적 클리셰가 있다는 관찰이다. 글에서 언급한 대표 패턴은 다섯 가지다. 첫째, 한글 제품인데도 본문 폰트가 지나치게 작아지는 경향. 둘째, 카드/배경/아이콘/로고까지 그림자가 과도하게 들어가는 경향. 셋째, `소타이틀 + 메인 타이틀 + 설명` 구조를 거의 습관처럼 반복하는 패턴. 넷째, 브랜드가 없으면 블루나 퍼플 계열을 기본값처럼 쓰는 경향. 다섯째, 지나치게 반듯한 3열·4열 그리드와 완벽한 정렬을 선호하는 경향이다. thenocodes 관점에서 흥미로운 건, 이걸 단순 미적 취향 문제가 아니라 “에이전트가 UI를 만들 때 어떤 분포에 과적합되는가”의 문제로 볼 수 있다는 점이다. 즉 모델은 안전하고 학습량이 많은 패턴, 구현이 쉬운 그리드, 보편적 신뢰감을 주는 컬러, 정보 밀도를 높인 옛 대시보드 스타일로 쉽게 수렴한다. 그래서 빠르게 그럴듯한 초안은 만들지만, 지역 언어 특성이나 브랜드 리듬, 제품의 의도적인 비대칭감까지는 잘 못 살리는 경우가 많다. 실무 시사점도 분명하다. AI가 만든 첫 화면을 바로 shipping 기준으로 보기보다, “폰트 크기”, “shadow 과다”, “설명 텍스트 남발”, “기본 블루/퍼플”, “과한 정렬감” 같은 체크리스트로 한 번 걸러보는 게 필요하다. 특히 한글 제품에서는 영문 중심 학습 분포 때문에 정보 밀도와 읽기 편의성이 어긋나기 쉽다는 지적이 꽤 유효하다. 결국 이 글은 좋은 디자인을 AI가 아직 못 한다는 얘기보다는, 생성형 UI를 쓸 때 사람이 어디를 봐야 하는지 알려주는 관찰에 가깝다. 즉 "AI가 화면을 뽑아주는 시대"에서도 디자이너의 역할은 줄기보다, 오히려 기본 분포에서 벗어나 제품 고유의 리듬을 만들고 검수하는 쪽으로 더 선명해진다는 쪽에 가깝다.
설명하는 VLM에서 실행하는 비전 에이전트로 넘어가는 신호, Orion
LinkedIn에 올라온 Orion 소개 글의 핵심은 “이미지를 설명하는 모델”에서 “시각 정보를 이해하고 실제 도구를 호출해 작업을 끝내는 에이전트”로 무게중심이 이동하고 있다는 점이다. 글에 따르면 Orion은 단순한 이미지 캡셔닝이나 질문응답 수준이 아니라, 객체 탐지, 키포인트 파악, 세그멘테이션, OCR 같은 전문 컴퓨터 비전 도구를 스스로 오케스트레이션해 다단계 시각 작업을 수행하는 쪽에 가깝다. 즉 VLM이 혼자 모든 걸 답하는 구조보다, 시각 이해 + 도구 실행 + 결과 생성이 하나의 워크플로로 묶이는 패턴이다. thenocodes 관점에서 중요한 건 이게 “모델 성능 자랑”보다 “비전 영역의 agentic engineering” 사례라는 점이다. 예를 들어 특정 인물 배경 편집, 문서 이해, 비디오 처리 같은 문제는 이제 단일 멀티모달 모델의 답변보다, 여러 비전 도구를 부르고 결과를 조립하는 실행 시스템으로 넘어갈 가능성이 크다. 다시 말해 보는 것과 행동하는 것이 분리되지 않는 구조다. 이런 흐름은 앞으로 비전 모델을 평가하는 기준도 바꾼다. 단순 벤치마크 점수보다, 어떤 도구를 언제 호출하고 얼마나 안정적으로 멀티스텝 작업을 끝내는지가 더 중요해진다. 특히 문서 처리, 이미지 편집, 현장 점검, 제조/의료 같은 영역에서는 “이미지를 잘 이해하느냐”보다 “그 이해를 바탕으로 실행 가능한 시스템을 만들 수 있느냐”가 더 핵심이 될 수 있다. 다만 이 글은 소개 성격이 강해서 실제 운영 신뢰성, latency, 비용, 실패 패턴까지 검증된 건 아니다. 그래서 지금 단계에선 "VLM이 agent layer와 결합될 때 어떤 업무가 바로 바뀌는가"를 보는 레이더로 받아들이는 게 적절하다. 그래도 방향성 자체는 분명하다. 멀티모달도 결국 답변형 모델에서 끝나는 게 아니라, 도구를 부르고 결과를 만들어내는 실행형 에이전트로 가고 있다.
NotebookLM을 도구가 아니라 에이전트 시스템의 저장소로 쓰는 관점
LinkedIn에 올라온 짧은 글인데, 포인트는 NotebookLM을 그냥 웹 UI에서 자료 넣고 팟캐스트 뽑는 “단일 도구”로 보지 말고, 에이전트 시스템 안의 자료 저장소 겸 검색 레이어로 보자는 주장이다. 정리하면 구조는 이렇다. NotebookLM은 자료를 적재하고 검색하는 저장소 역할을 맡고, 에이전트는 그 위에서 판단과 실행을 담당한다. 그러면 Claude나 Codex 같은 모델은 원문 자료 전체를 매번 직접 읽는 대신, NotebookLM이 찾아준 응답을 바탕으로 결론과 다음 액션에만 토큰을 쓰게 된다. 글에서는 이 차이가 결국 토큰 비용 구조와 반복 작업 방식 자체를 바꾼다고 설명한다. 실무적으로 흥미로운 지점은 네 가지다. 첫째, 유튜브 플레이리스트나 PDF 폴더 단위 적재를 자동화해 수작업 업로드를 없앨 수 있다는 점. 둘째, 모델이 자료 전체를 매번 읽지 않으니 판단·실행에 토큰을 더 집중할 수 있다는 점. 셋째, 퀴즈/플래시카드/마인드맵/슬라이드 같은 산출물을 웹 UI보다 더 구조적으로 뽑아낼 수 있다는 점. 넷째, 새 자료가 들어오면 요약, 팟캐스트, 후속 정리까지 파이프라인으로 묶을 수 있다는 점이다. thenocodes 관점에서 보면 이건 단순한 NotebookLM 활용 팁보다, “에이전틱 엔지니어링에서 컨텍스트를 어디에 두고, 어떤 계층이 검색을 담당하며, 어떤 계층이 판단을 맡는가”에 대한 설계 힌트에 가깝다. 즉 LLM 하나에 모든 자료를 밀어 넣는 방식에서 벗어나, 저장소와 실행 모델을 분리하는 패턴으로 볼 수 있다. 다만 글에서도 언급하듯 비공식 라이브러리 기반이라 Google 업데이트에 따라 동작이 달라질 가능성은 있다. 그래서 바로 운영 핵심에 넣기보다는, 내부 리서치/지식 정리/반복 요약 파이프라인에서 먼저 검증해볼 만한 패턴으로 보는 게 적절하다.
500개 AI 에이전트 프로젝트 모음 — 레시피 추천부터 법률 분석까지
GitHub에서 500개 이상의 AI 에이전트 프로젝트를 산업별로 정리한 레포지토리. 헬스케어, 금융, 교육, 리테일 등 분야별로 실제 구현 가능한 오픈소스 프로젝트 링크가 있습니다. 노코더가 바로 시도해볼 만한 것들: - 재료 넣으면 레시피 추천하는 에이전트 - PDF 법률 문서 분석 에이전트 (GPT-4o + 벡터 임베딩) - 실시간 주식 데이터 + 애널리스트 인사이트 통합 금융 에이전트 - CrewAI + LangGraph 조합 워크플로우 자동화 MIT 라이선스라 상업적 사용도 가능.
운영 seed 브리프입니다. 밋업이 여러 개 보일 때는 행사 소개문보다 먼저 이 네 가지를 보면 됩니다. 1. 대상 직군이 개발자 중심인지, PM/디자이너도 많은지 2. 발표 위주인지, 네트워킹 위주인지 3. 장소와 시간대가 퇴근 후 동선에 맞는지 4. 다음 액션이 남는지, 즉 사람을 만나거나 데모를 볼 수 있는지 더노코즈에선 /meetups 페이지를 먼저 훑고, 관심 행사만 원문 링크로 넘어가는 흐름이 제일 빠릅니다.
GPT 이미지 모델 "duct-tape" 아레나 테스트 — 한국어 렌더링, 일러스트, 실사화 수준이 미쳤습니다
LMSys 아레나에서 GPT 이미지 시리즈로 추정되는 duct-tape 모델이 테스트 중입니다. 한국어 손글씨 렌더링, 게임 일러스트(던파/메이플), 인스타 스토리 UI, 가상 유튜브 화면, 한국 배경 가상 게임, 미래 도시, 가상 웹페이지, 실사화, 가상 광고, 애니 일러스트까지 10개 카테고리 사례가 정리되어 있습니다. 특히 한국어 구현력과 일러스트 일관성에서 기존 모델을 압도한다는 평가.