GeekNews Weekly

이제 Codex는 더 이상 단순한 코딩 보조 도구가 아닙니다. PR 리뷰, 대형 코드베이스 이해, Figma 디자인 구현 같은 개발 작업은 물론 Gmail 정리, Slack 업무 처리, 데이터 분석, 재무 모델링, QA, 슬라이드 작성까지 아우릅니다. Codex의 포지션이 "개발자용 AI"에서 전사 업무를 위임받는 실행 에이전트로 옮겨가고 있습니다.

Lobsters의 개발자 도구 추천 스레드인데요. 단순한 도구 목록이라기보다, 요즘 개발자들이 어떤 작업 환경 철학을 선호하는지 보여줍니다. Helix, Fish, ripgrep, mise처럼 “기본값이 좋은 도구”가 반복적으로 언급되는 한편, jujutsu, lazygit, fzf, jq, tmux 같은 CLI 도구들은 여전히 강력한 생산성 도구로 자리 잡고 있습니다.

왠지 이 말이 와닿네요 "나이 들수록 도구를 내게 맞추기보다 좋은 기본값을 가진 도구에 내 선호를 맞춤"

"AI로 더 빨리"라는 통념을 뒤집어, 같은 도구로 더 느리게, 대신 더 좋은 코드를 만드는 법을 제안하는 글입니다. 핵심은 Claude 서브에이전트·Codex·Cursor Bugbot 등 여러 모델에게 PR을 교차 검토시켜 오탐을 걸러낸 뒤, critical/high 문제만 사람이 방향을 잡아 고치고 나머지는 과감히 건너뛰는 워크플로입니다. 결국 핵심은 생성 속도가 아니라, 실패 모드와 경계 조건을 더 집요하게 확인하면서 코드베이스의 건강을 높이는 데 있습니다.

정적 분석과 LLM 추론을 결합해 코드베이스의 아키텍처 다이어그램과 컴포넌트 문서를 자동 생성하는 오픈소스 도구입니다. 결과물이 Markdown + Mermaid로 만들어져 IDE·PR·문서에 그대로 임베드된다는 점이 실용적이고, 사람뿐 아니라 AI 에이전트가 함께 보는 코드 지도를 표방한다는 점이 흥미롭습니다. 앞선 글들의 “AI에게 맥락과 검증을 쥐여주자”는 흐름과도 맞닿아 있어, 에이전트 시대에 코드 이해와 아키텍처 가시성을 도구로 보강하려는 분께 권해 드립니다.

일상에 녹아드는 오픈소스 개인 비서로, 데스크톱 마스코트가 말하고 Google Meet에 참여자로 합류하며 118개 이상 서드파티를 원클릭 OAuth로 연동해 새 데이터를 알아서 끌어옵니다. 기술적으로는 데이터를 Markdown 청크로 정규화해 로컬 SQLite와 Obsidian 호환 vault에 저장하는 로컬 우선 Memory Tree, 도구 호출·이메일을 LLM 전에 압축해 비용을 최대 80% 줄이는 TokenJuice 레이어가 눈에 띕니다.

AI 코딩 에이전트가 매번 grep/glob로 파일을 훑으며 토큰을 태우는 대신, 심볼 관계·호출 그래프·코드 구조를 미리 인덱싱한 지식 그래프에 바로 질의하게 해주는 도구로, 평균 토큰 59%·도구 호출 70% 절감에 49% 빠름을 내세웁니다. 100% 로컬(SQLite) 로 외부 유출이 없고 MCP 서버로 Claude Code·Cursor·Codex에 그대로 붙는다는 점이 실용적이고요. 앞서 본 CodeBoarding이 사람이 보는 아키텍처 지도를 만든다면, CodeGraph는 에이전트가 실제 작업 중 참고할 로컬 코드 맥락 계층을 만드는 시도라서 함께 보면 좋습니다.

위클리 메인 주제로 다룬 글인데요. AI 에이전트에게 코드 맥락과 구조 정보를 쥐여주는 것은 중요하지만, 그것이 곧 아키텍처 판단까지 위임해도 된다는 뜻은 아닙니다. “아니오”와 “왜?”를 말하고, 팀의 역량·레거시·운영 제약을 반영해 무엇을 만들지 결정하는 책임은 여전히 사람에게 남아 있다는 점을 잘 짚어줍니다. 근데 HN 댓글의 다수는 "Claude가 '아니오'를 못 한다"는 전제에 동의하지 않는데요. 비판을 먼저 하라는 프롬프트나 회의적 페르소나를 주면 충분히 반박하더라는 경험담도 많습니다.

이 글의 또 다른 실무적인 교훈은 진짜 병목이 예약 쿼리가 아니라 커넥션 점유 시간이었다는 점인데요. 모든 SQL에 conn_tag 주석을 달아 "누가 커넥션을 오래 쥐는지"를 계측하자 비로소 드러나게 되어, 결국 DB 읽기 50%·트랜잭션 33%를 줄였습니다. 전환도 한 번에 갈아엎지 않고 Shadow Mode로 Redis·MySQL을 병행 기록하며 검증한 뒤 킬 스위치를 남겨두는 신중함이 돋보이고요. "CPU는 낮은데 큐가 쌓인다면 원인을 끝까지 파라", "5년 전 내린 결정을 다시 검토하라"는 마무리는 기술 선택을 고민하는 누구에게나 권할 만합니다.

AI 자동화에 대한 CEO들의 기대와 현장 업무의 실제 복잡도 사이에 생기는 간극을 날카롭게 짚은 글입니다. 프로토타입이나 계약서 초안을 만들어본 경험만으로 “이제 업무 대부분을 에이전트가 대체하겠구나”라고 판단하기 쉽지만, 실제 가치는 마지막 검토·수정·예외 처리·운영 책임에서 만들어지는 경우가 많습니다. 이번 주 메인 글의 기술 선택 이야기와도 이어지는데, "AI에게 판단을 통째로 맡기지 말라"는 흐름을 조직/경영 레이어로 확장해서 읽을 수 있을듯 합니다. AI가 더 많은 일을 할수록 리더에게 필요한 것은 더 큰 낙관론이 아니라 업무의 디테일을 이해하고 자동화의 경계를 정하는 판단력입니다.

"AI가 쓴 React 코드를 누가 검토하는가"라는 물음에서 출발한 도구로, npx react-doctor 한 줄이면 상태 관리·성능·보안·접근성·아키텍처를 0~100점으로 진단합니다. 흥미로운 건 AI 에이전트 연동을 전면에 내세운다는 점인데, install 시 Claude Code·Cursor·Codex에 스킬을 등록하고 git 훅까지 깔아 "한 에이전트가 만든 문제를 다른 에이전트가 잡는" 구조를 지향합니다. 앞서 본 코드 리뷰·지식 그래프 도구들과 함께, AI 코드 생성이 일상화되며 그 뒤를 받치는 게이트키퍼 도구가 빠르게 늘고 있음을 보여주는 사례입니다.

AI 자체보다 더 피곤한 것은, 사람이 해야 할 이해와 판단까지 AI 답변으로 우회하는 순간이라는 점을 잘 짚은 글입니다. GitHub 이슈, 회사 업무 질문, Reddit 대화에서 반복되는 사례들은 모두 “AI를 썼다”가 문제가 아니라, 상대가 답을 읽고 책임지는 과정을 생략했다는 데 문제가 있습니다. 이번 주의 “AI에게 어디까지 맡길 것인가”라는 흐름과도 맞닿아 있어, 자동화가 늘어날수록 오히려 사람이 직접 생각하고 응답하는 신뢰의 비용이 더 중요해진다는 점을 보여줍니다.

단순히 nmap을 돌리고 보고서를 뽑는 수준을 넘어, 정찰→익스플로잇→권한 상승→측면 이동→C2까지 실제 레드팀 공격 체인에 맞춰 구성된 자율 해킹 에이전트입니다. 16개 전문 에이전트가 킬체인 단계별로 나뉘고, 모든 명령은 작전망·관리망을 분리한 Kali 샌드박스에서만 돌도록 격리 설계를 갖춘 점이 눈에 띕니다. 앞서 본 코드 에이전트들이 개발 워크플로를 자동화한다면, 이쪽은 보안 테스트 영역에서도 에이전트 오케스트레이션과 샌드박스 격리가 핵심 설계 요소가 되고 있음을 보여줍니다.

Go에서 Rust로의 전환을 "더 빠른 언어로 갈아타기”"가 아니라 무엇을 컴파일 타임에 보장받을 것인가의 문제로 풀어낸 마이그레이션 가이드입니다. nil·데이터 레이스·오류 누락 같은 런타임 함정을 타입 시스템으로 옮기는 대신 가파른 학습 곡선과 느린 컴파일을 감수하는 트레이드오프를 솔직하게 짚고, 전면 재작성 대신 핫패스나 워커부터 떼어내는 Strangler 전략을 권합니다. 결론이 이번 주 주제와도 잘 맞는데, 결국 중요한 것은 유행하는 언어가 아니라 우리 시스템의 문제에 가장 맞는 언어를 배치하라는 것이죠.

현대적인 픽셀 폰트를 모은 글이지만, 단순한 레트로 취향 소개가 아니라 제약이 만든 디자인 언어를 다시 보는 글에 가깝습니다. 1990년대 VCR 자막 폰트의 기준선 문제를 바로잡은 Analog Mono, 서브픽셀 번짐을 향수로 담아낸 컬러 폰트 Coral Pixels, 높이가 단 2픽셀인 Two Slice 등을 소개합니다. 이번 주의 기술 선택 이야기와도 묘하게 닿아 있는데, 좋은 도구는 멋진 겉모습보다 제약을 이해하고 실제 사용 환경에 맞게 다듬는 일에서 완성된다는 점을 보여줍니다.

Claude Code·Codex를 강력하게 만드는 하네스 아키텍처를 일반화해, 누구나 자율 에이전트를 짤 수 있게 한 헤드리스 TypeScript 프레임워크입니다. Agent = Model + Harness라는 정의 아래 Model·Harness·Sandbox·Filesystem의 4계층으로 나누어 “에이전트를 쓰는 것”에서 에이전트를 제품 안에 직접 구성하는 것으로 넘어가는 흐름을 보여줍니다. "다른 사람의 에이전트를 임대하지 말고 전체 스택을 직접 소유하라"는 메시지가 핵심입니다.

React 비판 글들을 모은 큐레이션이지만, 단순한 안티 React 모음이라기보다 기술이 기본값이 되는 과정의 위험을 보여주는 자료에 가깝습니다. 성능, 하이드레이션, API 복잡도, Server Components, Next.js 거버넌스까지 다양한 불만이 쌓여 있지만, 핵심을 찌르는 건 "React가 기본값으로 승리하며 프론트엔드 혁신을 늦췄다" 는 지적입니다. "제약이 무엇이고 어떤 도구가 맞는가"가 아니라 "다들 아니까 React 쓰자" 로 시작되는, 이번 주 주제인 기술 선택의 가장 흔한 함정을 정면으로 보여줍니다. 다만 댓글에선 "수많은 대안을 다 겪고 살아남은 게 React"라는 반론도 팽팽하니 균형 잡아 읽으면 좋습니다.

Google 검색이 AI Overview와 AI Mode 중심으로 바뀌면서, 검색엔진 선택도 다시 기술 선택의 문제가 되고 있습니다. Kagi, DuckDuckGo, Startpage, Brave, Ecosia, &udm=14 같은 대안들은 각각 광고 없는 유료 검색, 추적 최소화, Google 결과 프록시, AI 없는 검색 경험처럼 서로 다른 제약 조건을 내세웁니다. 지난주 AI 검색 변화와도 이어지는 글인데, 이제 사용자 입장에서는 “어디서 검색할 것인가”를, 사이트 운영자 입장에서는 AI가 답을 가져가는 검색 환경에서 어떻게 발견될 것인가를 함께 고민해야 할 시점입니다.

AI 코딩 도구가 코드 작성 속도를 높여도, 조직의 병목이 그대로라면 가치 전달 속도는 크게 달라지지 않는다는 점을 짚은 글입니다. 자동화 테스트, CI/CD, 관측 가능성, ADR, 골든 패스 같은 엔지니어링 인에이블먼트는 사람 개발자뿐 아니라 AI 에이전트를 안전하게 움직이게 하는 가드레일이 됩니다. DORA 보고서를 빌려 "AI는 증폭기일 뿐, 잘하는 조직의 강점도 못하는 조직의 역기능도 똑같이 키운다" 고 이야기 하는데요. 도구를 들이기 전에 기반부터 갖췄는지를 되묻게 하는 글입니다.

"AI가 생산성을 10배 높인다면, 왜 노동시간은 그대로인가?"라고 가볍게 묻는 글입니다. 일주일 걸리던 일을 월요일 정오에 끝낸다면 주 4일 근무도 가능하지 않냐며, 목요일에 프롬프트를 남기면 금요일엔 에이전트가 일하게 하자는 반쯤 농담 섞인 제안이죠. 진짜 핵심은 댓글에서 드러나는데, 생산성 향상의 이익이 노동자가 아니라 주주에게 간다는 점, 그리고 주 5일이 생산성이 아니라 경쟁(죄수의 딜레마)과 사회적 규범으로 유지된다는 분석이 인상적입니다. AI 도입을 재촉당하면서도 "그래서 우리에게 무엇이 돌아오는가"는 묻지 않는 분위기를 꼬집는, 가볍지만 곱씹게 되는 글입니다.

프론티어 모델의 API 가격이 2~3배씩 오르는 추세를 짚으며, 저비용 국가 엔지니어와 DeepSeek 같은 오픈소스 모델 조합이 곧 더 경제적이 될 거라 전망하는 글입니다. 숫자 비교 자체는 가정이 많지만, "비싼 모델을 항상 쓰는 것이 최선인가"와 "사람의 감독 비용까지 포함하면 무엇이 더 싼가"를 함께 보게 만든다는 점이 흥미롭습니다. AI 모델 선택 역시 성능 순위표가 아니라 비용·보안·품질·감독 가능성을 함께 따지는 아키텍처 결정이 되고 있습니다.

위클리 메인에서는 반응이 예전만큼 뜨겁지 않다고 언급했지만, 내용 자체는 꽤 중요한 업데이트입니다. 코딩·에이전트 작업·추론 성능 개선보다 눈에 띄는 부분은 정직성(Honesty) 강화로, 불확실할 때 더 잘 멈추고 코드 결함도 이전보다 훨씬 덜 놓친다는 점입니다. 노력 수준을 조절하는 Effort Control, 수백 개 서브에이전트를 돌리는 Dynamic Workflows도 함께 나왔고요. 앞서 본 “AI에게 검증과 맥락을 쥐여주자”는 흐름과 연결해 보면, 이제 모델 경쟁도 단순 성능보다 스스로 의심하고 반박할 수 있는 협업 능력으로 옮겨가고 있습니다.

AWS에서 4년을 보내고 해고된 한 직원의 회고로, 회사가 고객 문제를 푸는 인프라(S3·EC2·RDS)에서 GenAI 과열로 급격히 기울며 길을 잃었다는 비판이 핵심입니다. 직원을 대체 가능한 부품(fungible) 으로 보는 관점이 물류센터엔 맞아도 시간이 쌓여야 하는 IT 조직 지식엔 안 맞는다는 지적, 그리고 "이메일을 요약하기보다 더 나은 이메일을 쓰는 게 낫다", "충분히 괜찮음은 고객 집착이 아니다" 라는 문장이 인상적입니다. 댓글의 AI 지원봇 성토까지 더하면, AI를 향한 조직의 조급함이 정작 사람과 품질을 밀어내는 풍경을 생생하게 보여주는 글입니다.

위클리 메인 주제로 다룬 글이지만, 이 글은 “Postgres로 어디까지 할 수 있나”보다 워크플로의 상태를 어디에 저장할 것인가라는 관점에서 읽으면 더 흥미롭습니다.

AI 도구 비용 논의에서 중요한 것은 “AI가 사람보다 비싼가”보다 토큰 사용량을 생산성 지표처럼 다루는 위험입니다. Microsoft·Uber 사례처럼 도입이 늘수록 비용도 빠르게 커질 수 있고, 특히 “많이 쓰는 것”과 “가치를 만든 것”은 전혀 다른 지표입니다. 이제 필요한 것은 도입 독려가 아니라 업무별 ROI와 사용 경계를 측정하는 운영 감각입니다.

AI가 온라인 콘텐츠를 넘어 노동시장과 소비 수요 자체를 흔들 수 있다는 꽤 비관적인 경제론입니다. 자동화로 비용을 줄인 기업은 단기적으로 이익을 얻지만, 대체된 노동자가 소비자이기도 하다는 점에서 전체 시장 수요를 갉아먹는 AI Layoff Trap이 생길 수 있다는 주장입니다. AI 도입을 비용 절감 전략으로만 볼 때 생길 수 있는 더 큰 경제적 부작용을 생각하게 합니다.

푸시 알림을 단순한 전달 채널이 아니라 Apple과 Google이 파싱·순위화·요약·재작성하는 플랫폼 편집면으로 보고 있다는 점이 흥미로운 글입니다. Android 채널, iOS Focus·Scheduled Summary, 온디바이스 요약 기능이 쌓이면서 앱 개발자가 보낸 알림이 사용자에게 그대로 도달한다는 가정은 점점 약해지고 있습니다. 이제 제품은 검색 결과뿐 아니라 알림·피드·요약 화면 같은 플랫폼 중개면에서 어떻게 보일지까지 고민해야 합니다.

소비자 구독보다 엔터프라이즈 사용량 과금에서 AI 회사들의 제품-시장 적합성(PMF)이 드러나고 있다는 Simon Willison의 분석입니다. Claude Code와 Codex 같은 에이전트가 개인 구독에서는 매우 저렴하게 느껴지지만, 기업 단위에서는 API 가격에 가까운 사용량 과금으로 전환되며 전혀 다른 비용 구조가 됩니다. 코딩 에이전트는 “무료에 가까운 생산성 보너스”가 아니라 기업 예산과 구매 프로세스 안으로 들어온 고가 인프라 제품이 되고 있습니다.

네이버가 AI 브리핑 인용수를 창작자 보상 기준에 넣은 것은 국내 검색 생태계에서 꽤 중요한 신호입니다. SEO가 검색 순위와 유입을 겨냥했다면, 이제는 AI 답변에 인용될 수 있는 콘텐츠가 보상과 노출의 기준이 되기 시작한 셈입니다. 창작자와 커뮤니티 운영자는 “좋은 글을 쓰는 것”에 더해 AI가 신뢰할 만한 출처로 인식하는 구조까지 고민해야 할 단계에 들어섰습니다.

LLM 에이전트가 기능 요구사항은 그럴듯하게 맞추지만, 백엔드의 API 계약·아키텍처 패턴·DB·ORM 제약이 누적될수록 성능이 무너지는 현상을 실험으로 보여준 논문입니다. 특히 실패 원인의 상당 부분이 데이터 계층과 ORM 런타임 위반에서 나온다는 점이 실무적으로 중요합니다. 코딩 에이전트를 실무에 쓰려면 프롬프트를 잘 쓰는 것만으로는 부족하고, 구조적 제약을 테스트와 정적 검증으로 고정하는 장치가 필요합니다.

호주 15개 기업의 100:80:100 실험은 4일 근무제가 단순한 복지 정책이 아니라 업무 흐름 재설계 실험이라는 점을 보여줍니다. 임금은 유지하고 근무시간은 줄이되 산출량을 유지하려면, 불필요한 회의와 낮은 가치의 업무를 줄이고 자동화·위임을 다시 설계해야 합니다. 생산성 향상의 목적은 더 많은 일을 밀어 넣는 것이 아니라 일의 구조를 바꿔 지속 가능한 속도를 찾는 것일 수 있습니다.

OpenAI의 구조 전환과 리더십 위기, GPT-4 이후의 기술 감각, 컴퓨트 제약까지 폭넓게 다룹니다. 특히 흥미로운 부분은 "AI가 이미 AI 개발을 가속하고 있다"는 대목과, 코드 작성은 빠르게 자동화되지만 코드 구조 설계는 여전히 인간 전문가가 강하다는 구분입니다. 이번 주 기술 선택 이야기와도 맞닿아 있어, AI 시대에도 사람이 맡아야 할 판단의 경계가 어디인지 생각해보게 합니다.

LLM이 만든 글과 웹사이트에서 반복적으로 보이는 문체와 시각적 패턴을 "AI 냄새"로 관찰한 글입니다. 짧은 명언식 문장, 반복되는 문장 구조, 비슷한 카드 UI와 버튼 스타일처럼 처음에는 세련돼 보이던 패턴도 인터넷 전체에 퍼지면 금방 식별 가능한 흔적이 됩니다. AI를 쓰지 말자는 이야기가 아니라, AI가 만든 기본값을 그대로 받아들이면 개인의 문체와 제품의 질감이 쉽게 평평해진다는 경고로 읽을 만합니다.

구독을 단순히 "가격 대비 혜택"으로만 보면 놓치는 지점을 잘 짚은 글입니다. Costco, Uber One, Amazon Prime 같은 구독은 비용을 낮춰주는 동시에 사용자의 구매처와 소비 습관을 조금씩 바꾸는 행동 설계 장치가 됩니다. SaaS를 만들거나 가격 모델을 고민하는 분이라면, 구독이 고객에게 주는 가치는 물론 고객의 미래 행동을 어떻게 바꾸는지도 함께 봐야 한다는 점에서 읽어보시기 바랍니다.

AI 도입 비용을 두고 "토큰을 많이 쓰면 생산성도 늘어난다"는 가정이 실제 조직 안에서 흔들리고 있음을 보여주는 사례입니다. Uber 내부에서 Claude Code 예산과 채용 속도까지 함께 논의된다는 점은, 코딩 에이전트가 더 이상 실험용 도구가 아니라 기업 비용 구조에 영향을 주는 인프라가 되었다는 뜻입니다. AI 도구 도입을 고민하는 팀이라면 사용량보다 성과와 연결되는 지표를 먼저 정해야 한다는 점을 생각하게 합니다.

위클리 메인 주제에 다뤘는데, 이 글은 "SQLite로도 된다"는 주장보다 워크플로 상태를 어디까지 단순하게 유지할 수 있는가를 보여주는 사례로 읽는 편이 좋습니다. SQLite와 Litestream을 조합해 각 에이전트나 워크플로가 독립적인 상태 단위를 갖게 하면, 초기 단계에서는 대형 공유 데이터베이스보다 운영과 장애 격리가 쉬울 수 있습니다. 고가용성 시스템이 필요해지기 전까지는, 복잡한 인프라를 미리 끌어들이지 않는 것도 중요한 기술 선택입니다.

Sentry의 오픈소스 책임자였던 개발자가 테크 업계를 떠나 인터넷 없는 삶으로 전환하겠다고 선언한 글입니다. 다소 극단적인 선택처럼 보이지만, AI 이후 오픈소스와 온라인 커뮤니티에 느끼는 피로감이 어디까지 커질 수 있는지를 보여줍니다. 기술을 좋아하는 사람일수록, 자신이 쓰는 도구와 연결 방식이 삶을 얼마나 지배하고 있는지 한 번쯤 돌아보게 만드는 글입니다.

대학 기숙사 방에서 시작한 무선 키보드 보드가 5만 개 이상 팔리고 100만 달러 매출을 넘긴 이야기입니다. Nordic 칩, Pro Micro 폼팩터, ZMK 생태계처럼 이미 존재하던 조각들을 잘 엮어 DIY 키보드 커뮤니티의 정확한 빈틈을 찌른 점이 인상적입니다. 거대한 시장이 아니어도, 깊이 아는 작은 커뮤니티의 불편을 해결하면 충분히 의미 있는 제품이 될 수 있다는 좋은 사례입니다.

Stack Overflow의 공개 Q&A 트래픽은 AI 도우미 확산 이후 크게 줄었지만, 회사는 과거 콘텐츠와 기업용 제품으로 버티고 있다는 점이 흥미롭습니다. 개발자의 질문이 비공개 AI 채팅으로 이동하면서 새 공개 지식은 줄어드는데, 정작 LLM은 여전히 Stack Overflow 같은 공개 지식에 의존하는 순환 구조가 만들어지고 있습니다. 지식 커뮤니티를 운영하는 입장에서는, AI 시대에 "새 지식이 어디서 만들어지는가"라는 질문을 피하기 어려워 보입니다.

위클리 메인 마지막에 소개드린 고전입니다. 혁신 토큰이라는 비유는 여전히 강력한데, 새로운 기술을 고를 때마다 팀의 학습·운영·장애 대응 비용을 함께 쓰고 있다는 사실을 직관적으로 보여줍니다. 기술 선택을 "무엇이 더 멋진가"가 아니라 실패 양상을 얼마나 알고 있는가로 바꿔 보게 만드는 글입니다.

2015년의 조언을 AI 코딩 도구 시대에 다시 읽어낸 글입니다. AI는 모르는 기술 스택에서도 그럴듯한 코드를 만들어주지만, 사용자가 검증할 수 없는 영역이 늘어날수록 위험은 더 커집니다. 이미 잘 아는 기술에서는 AI가 역량 증폭기가 되지만, 모르는 기술에서는 의존성을 키우는 장치가 될 수 있다는 점에서 이번 주 주제와 가장 잘 맞습니다.