Posts

한 줄 요약: ChatGPT Work 이슈에서 눈에 띄는 건 새 AI 에이전트 출시 자체보다, 회사 업무의 읽기 권한과 실행 권한이 같은 도구 안으로 들어오기 시작했다는 점이다. 사람들은 생산성보다 권한, 감사, 책임 소재를 먼저 떠올렸다. 무슨 일이 있었나 2026년 7월 9일, OpenAI는 ChatGPT Work를 공개했다. 공개 글은 이 기능을 “앱과 파일을 넘나들며 행동하고, 몇 시간 동안 프로젝트를 이어가며, 목표를 완성물로 바꾸는 에이전트”로 설명했다. 범위는 넓다. Slack, Microsoft Teams, Google Drive, SharePoint, 이메일, 캘린더, CRM, 프로젝트 관리 도구 같은 업무 앱 연결 문서, 슬라이드, 시트, 웹앱 생성 Scheduled Tasks를 통한 반복 작업 실행 데스크톱 앱에서 로컬 파일과 앱 접근 내장 브라우저와 Computer Use를 통한 클릭, 입력, 파일 이동 Codex 앱의 ChatGPT 데스크톱 앱 통합 Sites 공개 베타를 통한 대시보드, 포털, 인터랙티브 리포트 생성 출시 범위도 따로 봐야 한다. OpenAI 설명에 따르면 웹과 모바일의 ChatGPT Work는 2026년 7월 9일 기준 Pro, Enterprise, Edu 플랜에 먼저 제공된다. Plus와 Business에는 며칠에 걸쳐 배포된다. 데스크톱 앱에서는 Chat, Work, Codex가 Free를 포함한 모든 플랜에서 제공된다고 안내됐다. ...

한 줄 요약: 침입 탐지에 AI를 붙인다는 말은 센서를 똑똑하게 만든다는 뜻이 아니다. 어떤 판단을 로컬 모델에 맡기고, 어떤 판단을 에이전트와 사람의 검증 루프로 남길지 정하는 문제다. 왜 지금 이슈인가 침입 탐지 시스템(IDS), 보안 AI 에이전트, 온디바이스 머신러닝이 같은 논쟁 안으로 들어왔다. SnortML 같은 시도는 시그니처 기반 탐지의 빈틈을 줄이려 하고, 보안 운영 쪽에서는 에이전트가 알림 분류, 엔드포인트 조사, 탐지 규칙 생성까지 맡기 시작했다. 기존 Snort 룰은 강하다. 알려진 CVE, 알려진 페이로드, 알려진 와이어 레벨 패턴에는 낮은 오탐과 예측 가능한 비용으로 반응한다. 문제는 공격자가 같은 취약 경로를 살짝 다른 페이로드로 지나갈 때다. 룰이 작성되고 검증되고 배포되기 전까지 노출 시간이 생긴다. ...

한 줄 요약: AI 에이전트 보안 거버넌스의 중심은 더 똑똑한 보안 챗봇이 아니라, 에이전트가 볼 수 있는 데이터와 실행할 수 있는 행동, 실패했을 때 번질 피해를 아키텍처로 제한하는 데 있다. 왜 지금 이슈인가 멀티 에이전트(Multi-Agent) 구조가 운영, 비용 최적화, 보안 분석까지 들어오면서 질문이 바뀌고 있다. 예전 질문은 이랬다. 로그를 어디에 모을까? 권한 점검 쿼리를 어떻게 자동화할까? 보안 대시보드를 누가 매주 확인할까? 이제는 이렇게 묻는다. AI 에이전트가 실패 로그와 권한 정보를 보고 위험을 판단해도 될까? 비용 최적화 에이전트와 보안 에이전트가 같은 질문에 함께 답하면 무엇이 좋아질까? 사람 승인(Human-in-the-loop)이 있으면 정말 안전한가? 에이전트가 틀렸다는 사실을 나중에 어떻게 증명할 수 있을까? 선정 글감인 Snowflake 멀티 에이전트 예시는 이 변화를 잘 보여준다. Admin Agent는 사용량과 스토리지를 보고, Cost Optimizer Agent는 유휴 웨어하우스와 비용 낭비를 찾는다. Security and Governance Agent는 실패 로그인, 과도한 권한, 비인가 접근 시도를 다룬다. 사용자가 자연어로 물으면 Orchestrator Agent가 알맞은 전문 에이전트로 넘긴다. ...

한 줄 요약: Bun의 Rust 재작성은 언어 교체 자체보다, 큰 시스템 변경을 어떤 테스트와 검증 장치로 받아낼 수 있는지를 보여준다. 봐야 할 지점은 Zig와 Rust의 승패가 아니라, 테스트 하네스와 메모리 안전성으로 재작성 결과를 어디까지 믿을 수 있느냐다. 왜 지금 이슈인가 Bun의 Rust 재작성 이야기가 개발자 커뮤니티에서 회자되는 이유는 분명하다. 53만 줄이 넘는 Zig 코드베이스를 Rust로 옮기는 작업은 보통 제품 로드맵을 멈춰 세울 만한 일이다. Bun 팀은 이 작업을 AI 에이전트와 기존 테스트 하네스(Test Harness)를 함께 써서 진행했다고 설명한다. ...

한 줄 요약: OpenMed 1.8 논쟁의 초점은 의료 데이터 비식별화 도구가 로컬 AI로 돌아간다는 기술 성과보다, 환자 데이터가 어디까지 이동해도 되는지에 대한 신뢰 기준이 바뀌고 있다는 데 있다. 무슨 일이 있었나 Reddit LocalLLaMA에 OpenMed 1.8 출시 글이 올라왔다. 작성자는 OpenMed 관리자로 보이며, 이 프로젝트를 Apache-2.0 라이선스의 임상 자연어 처리(Clinical NLP) 툴킷이라고 소개했다. 규칙은 분명하다. 환자 데이터가 사용자의 하드웨어를 떠나지 않는다는 것. 이번 1.8에서 언급된 범위는 꽤 넓다. Android: Kotlin, ONNX Runtime Mobile, ML Kit OCR 기반 OpenMedKit iOS/Swift 및 React Native 브리지 브라우저 런타임: Transformers.js, ONNX Runtime Web, wasm, WebGPU 백엔드 PDF 검증 도구: 검은 박스만 덮은 가짜 삭제를 탐지 DICOM 비식별화: 픽셀에 박힌 텍스트까지 OCR로 처리 언어 식별 패키지 추가 다음 1.9를 위한 공개 이슈 400개 이상 확인된 사실은 여기까지다. OpenMed 1.8은 로컬 실행, 모바일, 브라우저, PDF 검증, DICOM 비식별화를 전면에 내세웠고, Reddit 커뮤니티에서 기여자를 공개 모집했다. ...

한 줄 요약: GPT-5.6 발표에서 실무자가 봐야 할 쟁점은 성능 수치보다 모델과 애플리케이션 사이의 계약이 바뀐다는 점이다. 짧은 프롬프트, Programmatic Tool Calling, 멀티 에이전트, 신뢰 기반 접근은 모두 덜 지시하고 더 많이 맡기는 방향을 가리킨다. 무슨 일이 있었나 OpenAI는 2026년 7월 9일 GPT-5.6 모델군을 일반 공개했다. 구성은 플래그십 모델 Sol, 일상 작업용 균형 모델 Terra, 비용 효율 모델 Luna다. 공개 범위는 ChatGPT, ChatGPT Work, Codex, OpenAI API다. API에서는 Responses API로 Programmatic Tool Calling과 멀티 에이전트 베타를 제공한다고 밝혔다. Codex와 ChatGPT Work에는 max, ultra 같은 고급 추론 설정도 들어간다. ...

한 줄 요약: 프런티어 모델 안전성 평가 논쟁은 OpenAI Sol이 얼마나 위험한지보다, 출시 허가를 누가 어떤 기준으로 판단했는지가 보이지 않는다는 문제에 가깝다. 이제 AI 모델 출시 리스크는 성능 수치보다 절차의 불투명성 쪽으로 옮겨가고 있다. 무슨 일이 있었나 2026년 7월 9일 TechCrunch는 OpenAI의 새 프런티어 모델 Sol이 넓은 공개 접근으로 풀리는 과정에서 미국 정부가 어떤 기준으로 안전성을 판단했는지 불분명하다고 짚었다. 기사의 문제 제기는 단순하다. OpenAI Sol은 Anthropic의 Fable과 비슷한 수준의 고성능 모델로 묘사된다. Fable은 사이버 보안 능력과 탈옥(Jailbreak) 우려 때문에 한때 더 넓은 접근이 제한됐고, 외국 국적자의 사용 금지까지 거론된 모델이다. 그런데 Sol은 정부와 사전 대화를 거친 뒤 공개 접근으로 나아갔다. ...

한 줄 요약: PostgreSQL 파티션 프루닝은 파티션 키만의 문제가 아니다. 데이터 생성 순서와 업무 규칙 사이에 강한 상관관계가 있다면, 체크 제약조건으로 옵티마이저에게 안전한 단서를 줄 수 있다. 왜 지금 이슈인가 파티션 테이블을 쓰기 시작하면 곧 PostgreSQL 파티션 프루닝 문제를 만난다. 시간 기준으로 나눈 이벤트 테이블은 날짜 범위 조회에는 빠르지만, session_id, tenant_id, customer_id 같은 업무 키로 조회하는 순간 모든 파티션을 건드릴 수 있다. 처음에는 인덱스를 만들면 해결될 것처럼 보인다. 하지만 PostgreSQL의 파티션 인덱스는 기본적으로 각 파티션에 붙는 로컬 인덱스(Local Index)다. 쿼리가 100개 파티션을 모두 확인해야 한다면, 각 파티션에서 인덱스를 잘 타더라도 실행 계획은 여전히 100개 테이블을 순회하는 모양이 된다. ...

한 줄 요약: AI 에이전트 시각화가 흔들리는 이유는 모델이 차트를 못 그려서만은 아니다. 에이전트가 다루는 언어가 너무 낮은 수준이면, 모델은 데이터의 의미보다 눈금, 색상, 레이아웃 같은 세부 결정을 떠안는다. Flint, 평가 플라이휠, 구조 린터 사례를 함께 보면 에이전트 품질은 프롬프트만이 아니라 중간 언어, 테스트 자동화, 코드베이스 어휘에서 갈린다. 왜 지금 이슈인가 AI 에이전트에게 데이터 시각화를 맡기면 처음에는 꽤 그럴듯해 보인다. 막대그래프, 선그래프, 산점도 정도는 자연어 요청만으로 만들어낸다. 문제는 실무 화면에 붙이는 순간 드러난다. ...

한 줄 요약: GitHub Copilot과 Testcontainers를 쓰면 통합 테스트 자동화를 빨리 시작할 수 있다. 다만 신뢰는 AI가 만든 코드에서 나오지 않는다. 격리된 실행 환경, 검증 가능한 의존성, CI 권한 설계가 받쳐줘야 한다. 왜 지금 이슈인가 GitHub Copilot, Testcontainers, 통합 테스트 자동화가 한꺼번에 묶이는 이유는 개발 속도만은 아니다. 이제 AI가 테스트 코드까지 제안하면서, 개발팀이 무엇을 믿고 병합할 수 있는지가 논점이 됐다. 선정 글감은 Copilot이 통합 테스트 골격을 만들고, Testcontainers가 SQL Server 같은 실제 의존성을 Docker 컨테이너로 띄워 CI에서 검증하는 흐름을 보여준다. 보일러플레이트를 줄이고, 공유 개발 DB나 과도한 목(Mock)에 기대던 테스트를 줄이자는 방향이다. ...