[카테고리:] AI

  • 컨텍스트 인식 AI, 기업 에이전트 성패 가른다

    컨텍스트 인식 AI, 기업 에이전트 성패 가른다

    3줄 요약

    • 기업용 AI 에이전트의 성패는 모델 크기보다 ‘업무가 실제로 돌아가는 방식’, 즉 운영 맥락을 아느냐에 달려 있다.
    • 맥락이 빠진 에이전트는 제약 조건을 놓치고, 비싼 실수를 하고, 필요한 정보를 알아내느라 연산을 과하게 쓴다.
    • 도입은 결정 하나를 골라 가장 어려운 단계부터 AI를 시험하고, 속도와 가치를 측정한 뒤 확장 여부를 정하는 순서가 안전하다.

    세상의 거의 모든 지식을 학습한 AI 모델이라도 우리 회사의 발주 승인 기준 하나를 모르면 엉뚱한 답을 내놓는다. 정답에 닿는 경우도 있긴 하다. 질문을 거듭하며 막대한 연산을 태운 끝에.

    이 간극을 메우려는 개념이 ‘컨텍스트 인식 AI(context-aware AI)’다. 셀로니스(Celonis)에서 기업 AI 수석 과학자를 맡고 있는 데바브라트 샤(Devavrat Shah)는 MIT 테크놀로지 리뷰 팟캐스트 ‘Business Lab’에 나와, 이 맥락을 ‘의사결정 인텔리전스’의 핵심으로 꼽았다.

    그의 주장은 한 줄이면 된다. 기업 에이전트의 성패는 모델 크기가 아니라 회사가 실제로 어떻게 돌아가는지를 아느냐로 갈린다. 맥락이 빠지면 무슨 비용이 생기는지, 어디부터 손대야 하는지도 이 한 줄에서 나온다.

    컨텍스트는 프롬프트가 아니라 ‘회사가 일하는 방식’

    용어부터 짚고 가자. 여기서 컨텍스트는 대화 기록이나 프롬프트 길이가 아니다. 기업이 실제로 운영되는 방식 전체를 말한다.

    • 프로세스: 어떤 일을 어떤 순서로 처리하는가
    • 제약 조건: 예산 한도, 승인 규칙처럼 결정을 묶어 두는 조건
    • 관계: 한 과제의 결과가 다른 팀·다른 단계에 어떤 영향을 주는가
    • 데이터: 기업이 이미 쓰고 있는 시스템에 쌓인 업무 기록

    네 항목 모두 모델 성능과는 상관이 없다. 전부 회사 안에 이미 있는 정보다. 모델을 바꾼다고 생겨나지 않는다는 뜻이기도 하다.

    범용 모델은 일반 원칙에 강하다. 그런데 기업의 결정은 대부분 특수한 상황에서 나온다. 팟캐스트 진행자 메건 테이텀(Megan Tatum)도 이 지점을 짚었다. 맥락 없이 움직이는 기업 AI는 일반 원칙을 특수한 시나리오에 들이밀다가 기대에 못 미치는 결과를 낸다. 경영진이 확장을 망설이는 이유도 여기 있다는 설명이다.

    샤의 표현은 더 짧다. 어떤 역할과 어떤 과제를 AI에 맡길지 알려면 맥락을 알아야 하고, “진공 상태에서 그냥 할 수는 없다”는 것.

    의사결정 인텔리전스, 결정을 ‘과제’ 단위로 쪼갠다

    샤가 말하는 의사결정 인텔리전스(decision intelligence)는 AI를 결정 자체가 아니라 결정에 이르는 과정에 붙이는 접근이다.

    출발점은 분류다. 그는 기업의 결정을 크게 두 종류로 나눈다.

    • 전략적 결정: 사안이 생길 때마다 간헐적으로 내리는 결정
    • 운영적 결정: 높은 빈도로 반복해서 내리는 결정

    어느 쪽이든 정해진 프로세스가 있다. 이 일을 먼저 하고, 다음에 저 일을 하는 식이다. 사람들은 그 안에서 각자 역할을 맡는다. 샤는 이 역할 단위가 젠슨 황이 ‘태스크’라고 부른 것과 같다고 본다. 단계별 과제가 하나씩 끝나야 비로소 결정에 닿는다.

    AI 에이전트가 들어갈 자리도 이 과제 하나하나다. 결정을 통째로 넘기지 않는다. 과제마다 개입 수준을 따로 고른다.

    1. 보강(augment): 사람이 하던 과제를 더 잘하게 돕는다
    2. 지원(support): 과제 수행에 필요한 정보나 추천을 건넨다
    3. 자동화(automate): 반복적이고 고된 과제는 AI가 맡는다

    어떤 과제에 어느 수준을 적용할지는 결정의 종류와 과제의 성격에 따라 달라진다. 이 판단부터가 맥락 없이는 불가능하다.

    글 전체에서 실무에 가장 바로 쓸 만한 대목이 여기다. ‘AI를 쓸까 말까’라는 막연한 질문을 ‘어느 과제에, 어느 수준으로’라는 구체적인 질문으로 바꿔 주기 때문이다.

    맥락 없는 에이전트의 청구서: 제약 누락·실수·연산 낭비

    샤는 맥락 없이 에이전트를 돌릴 때의 위험을 두 갈래 시나리오로 설명했다.

    • 이상적인 경우: 프런티어 연구소들이 세상에서 일어난 일과 일어날 법한 일을 모두 담은 거대한 모델을 만들었다고 치자. 이 ‘아주 똑똑한 존재’는 사람처럼 질문을 여러 번 던진 끝에 결국 올바른 답을 찾는다. 대신 간단한 과제 하나를 끝내는 데도 막대한 연산을 쓴다.
    • 현실적인 경우: 실제로는 그런 이상적 상황이 오지 않는다. 중요한 맥락과 제약을 그대로 놓친다.

    두 시나리오가 가리키는 곳은 같다. 모델이 아무리 똑똑해도 맥락이 없으면 비용이 생긴다. 앞쪽은 연산으로, 뒤쪽은 실수로 치를 뿐이다. 항목별로 나누면 세 가지다.

    • 제약 누락: 지켜야 할 조건을 모른 채 결정을 추천한다
    • 비싼 실수: 잘못된 추천이 실제 업무에 반영되면 되돌리는 비용이 크다
    • 연산 낭비: 필요한 정보를 스스로 알아내느라 단순 작업에도 자원을 과하게 쓴다

    맥락이 있고 없고에 따라 에이전트가 어떻게 달라지는지, 나란히 놓으면 이렇다.

    구분 맥락 없는 AI 에이전트 컨텍스트 인식 AI 에이전트
    필요한 정보 확보 질문을 거듭하며 스스로 알아냄 기존 프로세스·데이터에 연결된 컨텍스트 레이어에서 참조
    제약 조건 중요한 제약을 놓칠 위험 정의된 가드레일 안에서 동작
    연산 자원 단순 과제에도 과도한 연산 소모 탐색 부담이 줄어 자원 낭비를 피할 여지
    결과물 일반 원칙을 특수 상황에 적용해 빗나가기 쉬움 사람이 검토·승인할 수 있는 추천
    사람의 역할 결정을 에이전트에 넘겨버릴 위험 AI 출력과 그 함의를 이해하고 최종 판단

    표의 오른쪽 열은 샤가 제시한 방향으로 읽어야 한다. 연산 자원 칸이 ‘피할 여지’라는 조심스러운 표현에 머문 것도 그래서다. 얼마나 줄어드는지 보여 주는 숫자는 팟캐스트에 없었다.

    컨텍스트 레이어 도입, 반복되는 결정 하나부터

    해법의 출발점은 새 모델이 아니다. 연결이다. 기업이 이미 쓰고 있는 프로세스와 데이터에 AI를 이어 붙이는 ‘컨텍스트 레이어’가 핵심. 이 레이어가 맡는 일은 세 가지다.

    • 에이전트가 업무 흐름(워크플로)을 이해하게 한다
    • 정해진 가드레일 안에서만 움직이게 한다
    • 사람이 검토하고 승인할 수 있는 형태로 추천을 내놓게 한다

    바꿔 말하면 준비의 상당 부분은 모델을 만드는 쪽이 아니라 도입하는 기업이 풀어야 할 숙제라는 얘기다. 샤가 권하는 시작 방법도 작고 구체적이다.

    1. 특정 비즈니스 결정 하나를 고른다. ‘업무 효율화’ 같은 막연한 목표는 대상이 아니다. 반복되는 결정 하나면 된다.
    2. 그 결정에서 가장 어려운 단계를 찾는다. 시간이 오래 걸리거나 실수가 잦은 과제가 후보다.
    3. AI가 그 단계를 개선하는지 시험한다. 결정 전체가 아니라 해당 단계만 놓고 본다.
    4. 속도와 가치의 개선 폭을 측정한다. 얼마나 빨라졌는지, 어떤 가치가 생겼는지를 숫자로 남긴다.
    5. 측정 결과로 확장 여부를 판단한다. 효과가 확인된 애플리케이션만 넓힌다.

    다섯 단계의 무게중심은 4번이다. 측정 결과가 없으면 5번에서 확장을 판단할 근거도 사라진다.

    이 측정은 경영진이 요구하는 것과 정확히 겹친다. 수년간 실험·데모·파일럿을 거친 기업 리더들은 확장이 실제 수익에 도움이 된다는 분명한 증거를 원한다. 결정 단위로 재면 그 증거를 만들기가 훨씬 쉽다. 이 순서에 설득력이 있는 이유다.

    시험에 들어가기 전에 미리 정해 둘 항목도 있다.

    • 에이전트가 넘으면 안 되는 가드레일 범위(예: 승인 없이 실행하면 안 되는 작업)
    • AI 추천을 검토·승인할 담당자
    • 비교 기준이 될 AI 도입 전 처리 시간과 결과

    특히 세 번째 항목이 빠지면 4번 단계가 성립하지 않는다. 비교할 기준치 없이 ‘빨라졌다’를 숫자로 보여 줄 방법은 없다.

    국내 기업 PoC·결재 라인에 생길 변화

    아래 내용은 원문의 논리를 국내 기업 환경에 대입해 본 추측이다.

    • PoC 평가 기준의 이동(추측): 질문이 ‘데모가 잘 돌아가는가’에서 ‘특정 결정이 얼마나 빨라지고 어떤 가치가 생겼는가’로 옮겨갈 것으로 보인다. 샤가 확장을 정당화하는 근거로 내세운 게 바로 속도·가치 측정이다.
    • 데이터·프로세스 정리가 선행 과제로(추측): 컨텍스트 레이어는 기존 프로세스와 데이터를 잇는 데서 출발한다. 여러 시스템에 흩어진 업무 기록을 정리하는 일이 모델 선택보다 먼저 필요해질 수 있다.
    • 기존 결재 흐름과의 결합(추측): 사람이 검토·승인하는 구조가 전제다. 승인 단계가 여러 겹인 조직이라면 기존 결재 흐름 안에 AI 추천을 끼워 넣는 방식이 현실적인 출발점이 될 수 있다.
    • 사내 교육의 초점 변화(추측): 반복 업무와 팀 간 조율이 자동화되면 실무자의 시간은 더 복잡한 전략적 판단으로 옮겨간다. 걸리는 건 AI 출력과 그 함의를 이해하지 못하면 결정을 에이전트에 떠넘기게 된다는 지적이다. 사내 AI 교육이 ‘도구 사용법’에서 ‘결과 해석법’으로 넓어질 것으로 보인다.

    네 가지 모두 추측이지만 방향은 하나로 모인다. 어떤 모델을 들이느냐보다 회사 안을 먼저 정리해야 한다는 것.

    확인된 것과 아직 불확실한 것

    확인된 것

    • 샤는 셀로니스의 기업 AI 수석 과학자이며, MIT 교수로 20년 넘게 AI를 가르쳐 왔다고 밝혔다.
    • 맥락 없는 에이전트의 위험으로 제약 누락, 비용이 큰 실수, 과도한 연산 소모가 제시됐다.
    • 권장 도입 순서는 특정 결정 선택 → 가장 어려운 단계 파악 → AI 개선 여부 시험 → 속도·가치 측정 → 확장 판단이다.
    • 직원이 AI 출력을 이해할 수 있도록 인력 교육에 투자해야 한다는 점이 강조됐다.

    아직 불확실한 것

    • 컨텍스트 레이어가 오류와 연산 비용을 얼마나 줄이는지에 대한 정량 수치는 제시되지 않았다.
    • 컨텍스트 레이어를 어떤 데이터로, 어떤 방식으로 구현하는지는 구체적으로 설명되지 않았다.
    • 재무·인력 관리·마케팅·영업 같은 전사 계획으로의 확장은 샤의 전망이며, 실제 적용 사례는 소개되지 않았다.
    • 해당 에피소드는 셀로니스와 파트너십으로 제작돼 특정 기업의 관점이 반영됐을 수 있다.

    재무·인력·영업까지, 샤가 내다본 다음 무대

    샤는 컨텍스트 인식 AI의 쓰임이 반복적인 운영 과제에서 멈추지 않는다고 본다. 그가 꼽은 확장 영역은 재무, 인력 관리, 마케팅, 영업이다.

    논리는 단순하다. 올바른 맥락이 주어지면 AI가 선택지를 평가하고, 파급력이 큰 결정을 더 빨리 내리도록 도울 수 있다. 자원 계획을 두고는 “어쩌면 그렇게 많은 시간이 걸릴 필요가 없고, 사람들이 실제로 빠르게 올바른 선택을 하게 될 것”이라고 했다.

    이 대목은 앞의 도입 순서와 성격이 다르다. 결정 하나에서 시작하라는 권고는 바로 따라 해 볼 수 있는 방법론이고, 전사 계획 이야기는 말 그대로 전망이다. 두 가지를 같은 무게로 읽을 필요는 없다.

    샤의 권고를 거꾸로 읽으면 체크리스트가 된다. 어떤 결정을 고를지, 그 결정의 어느 단계가 가장 어려운지, 도입 전 기준치는 얼마인지. 모델을 먼저 고르고 쓸 곳을 찾는 방식으로는 이 세 질문에 답이 나오지 않는다. 기업 AI가 실험 단계를 넘어 일상 운영으로 들어가려면, 맥락을 어떻게 공급할지가 첫 번째 설계 과제다.

    출처: MIT Tech Review AI

  • PHP 취약점 악용 수백만 건, 호스팅별 패치 순서

    PHP 취약점 악용 수백만 건, 호스팅별 패치 순서

    3줄 요약

    • AI가 PHP에서 10년 묵은 결함을 찾아냈고, 공개 뒤 악용 시도는 수천 건 단위에서 수백만 건 단위로 늘었다.
    • PHP 엔진 패치를 누가 하는지는 호스팅 형태가 정한다. 공유 호스팅은 버전 선택과 호스팅사 확인, 직접 운영하는 서버는 패키지 업데이트와 PHP 재시작이 핵심이다.
    • 지원이 끝난 PHP 버전에는 보안 수정이 나오지 않으므로, 패치가 아니라 상위 버전 이전을 계획해야 한다.

    수천 건이던 악용 시도가 수백만 건으로 늘었다. 대부분의 웹사이트 뒤에서 돌아가는 PHP에서 AI가 10년 묵은 결함을 찾아냈고, 그 결함이 공개된 뒤 벌어진 일이다. 로이터가 전한 이 소식에는 더 강한 대목도 있다. 각국 정부가 웹사이트 운영자에게 PHP를 패치하라고 했고, 그럴 수 없다면 아예 사이트를 내리라고까지 촉구했다. 사이트를 하나라도 운영하고 있다면 오늘 할 일은 두 가지다. 내 사이트가 어떤 PHP 위에서 돌아가는지 확인하는 것, 그리고 호스팅 형태에 맞춰 업데이트하는 것. 이 글은 그 절차를 호스팅 형태별로 나눠 짚는다. 결함 자체의 기술적 세부는 아직 알려진 게 많지 않다. 그래서 이번 한 건보다는 다음 PHP 보안 공지가 나왔을 때도 그대로 쓸 수 있는 순서에 초점을 맞췄다.

    워드프레스를 최신으로 올려도 PHP 엔진은 그대로다

    PHP는 브라우저가 아니라 서버에서 실행되는 언어다. 방문자가 페이지를 열면 서버에 설치된 PHP 실행 엔진이 코드를 해석해 HTML을 만들어 보낸다. 워드프레스, 그누보드 같은 설치형 블로그·게시판·쇼핑몰 솔루션이 모두 이 구조 위에 올라가 있다. 맨 아래에 있는 엔진에 결함이 있으면, 그 위의 애플리케이션을 아무리 최신으로 유지해도 위험은 남는다.

    층을 둘로 나눠 보면 덜 헷갈린다. 아래층은 PHP 엔진(인터프리터)이고, 위층은 그 위에서 돌아가는 애플리케이션과 플러그인이다. 워드프레스 관리자 화면에 뜨는 업데이트 알림은 주로 위층을 다룬다. 이번 결함이 가리키는 곳은 아래층, 곧 PHP 자체다. 엔진 업데이트는 관리자 화면 버튼 하나로 끝나지 않는 경우가 많고, 서버를 누가 관리하느냐에 따라 할 일이 갈린다. 플러그인 업데이트 알림이 없다고 해서 안심할 수 없는 이유다.

    운영자가 먼저 답해야 할 질문은 두 가지다. 내 사이트는 어떤 PHP 버전에서 돌아가는가. 그 PHP를 업데이트할 권한이 나에게 있는가. 앞의 질문은 몇 분이면 답이 나온다. 뒤의 질문은 기술이 아니라 호스팅 계약 형태가 정한다.

    내 사이트 PHP 버전은 세 곳에서 확인된다

    아래 경로는 기본 설치 화면 기준이며, 호스팅사가 관리 패널을 자체적으로 고친 경우 표기가 조금 바뀔 수 있다.

    ① 워드프레스 관리자 화면. 관리자 메뉴에서 도구 → 사이트 건강 → 정보 탭 → 서버 항목을 펼치면 PHP 버전이 보인다(영문 화면은 Tools → Site Health → Info → Server). 같은 화면의 상태 탭은 PHP가 오래됐을 때 개선 권장 항목으로 경고를 띄우기도 한다. 서버에 접속하지 않고 브라우저만으로 확인할 수 있으니, 워드프레스 사이트라면 여기서 시작하는 게 가장 간단하다.

    ② 호스팅 관리 패널. cPanel을 쓰는 호스팅이라면 소프트웨어 → MultiPHP Manager에서 도메인별 PHP 버전을 볼 수 있다. 일부 호스팅은 같은 기능을 Select PHP Version이라는 메뉴로 제공한다(호스팅 환경에 따라 갈리는 부분이라 이 단계는 확실하지 않다). 국내 웹호스팅은 자체 콘솔을 쓰는 곳이 많다. 이런 곳은 메뉴를 하나씩 찾아보기보다 해당 회사 고객센터 문서에서 ‘PHP 버전 변경’을 검색하는 편이 빠르다.

    ③ 서버 직접 접속(SSH). 터미널에서 php -v를 입력하면 버전이 나온다. 다만 여기에 나오는 건 명령줄용 PHP 버전이다. 웹 서버가 쓰는 PHP와 다를 수 있고, 여러 버전이 함께 설치된 서버에서는 흔한 일이다. 웹에서 실제로 쓰는 버전은 웹 루트에 <?php phpinfo(); ?> 한 줄짜리 파일을 올려 브라우저로 열어 보면 확인된다. 이 파일은 서버 경로와 설정값을 그대로 노출한다. 확인했으면 바로 지워야 한다. 그대로 두면 공격자에게 서버 구조를 알려 주는 셈이다.

    공유 호스팅은 호스팅사가, VPS·도커는 내가 패치한다

    PHP 패치를 누가 적용하느냐는 계약 형태가 정한다. 아래 표는 일반적인 책임 구분이며, 세부 사항은 개별 호스팅 약관에서 확인해야 한다.

    운영 형태 PHP 엔진 패치 주체 운영자가 할 일
    공유(웹) 호스팅 호스팅사 패널에서 지원되는 최신 버전 선택, 호스팅사 보안 공지 확인
    관리형 워드프레스 호스팅 호스팅사 PHP 버전 전환 일정 확인, 테마·플러그인 호환성 점검
    VPS·클라우드 서버 운영자 본인 운영체제 패키지 업데이트 후 PHP-FPM·웹 서버 재시작
    컨테이너(Docker) 운영자 본인 베이스 이미지를 새로 받아 다시 빌드·배포

    공유 호스팅에서는 PHP 엔진을 호스팅사가 관리한다. 같은 버전 계열 안의 보안 수정은 호스팅사가 적용한다. 운영자가 직접 할 수 있는 건 패널에 더 새로운 지원 버전이 있을 때 그쪽으로 옮기는 정도다. 직접 할 수 있는 일이 적어서, 운영자가 할 일은 대부분 확인 작업이다. 호스팅사가 이번 결함에 대응했는지는 공지사항이나 고객센터 문의로 확인하면 된다.

    운영체제까지 직접 관리하는 VPS나 클라우드 서버는 패키지 관리자로 업데이트한다. 우분투·데비안 계열은 sudo apt update && sudo apt upgrade, 레드햇 계열(록키·알마 리눅스 등)은 sudo dnf upgrade가 기본이다. 업데이트만 하고 끝내면 안 된다. PHP 프로세스를 재시작해야 새 코드가 메모리에 올라간다. systemctl list-units | grep php로 실행 중인 서비스 이름(php8.x-fpm 같은 형태)을 찾은 다음 sudo systemctl restart 서비스이름을 실행한다. 아파치 모듈 방식으로 PHP를 돌리고 있다면 아파치를 재시작하면 된다.

    배포판 패키지에는 주의할 점이 있다. 우분투·데비안 같은 배포판은 보안 수정을 기존 버전 번호에 덧붙여 내보내는 백포트 방식을 쓴다. 그래서 php -v에 찍히는 PHP 버전 숫자가 그대로여도 패치는 이미 적용됐을 수 있다. 거꾸로 숫자만 보고 안심할 수도 없다. 가장 확실한 방법은 배포판 보안 공지에서 해당 결함의 수정 패키지 버전을 찾은 뒤, apt list --installed | grep php(레드햇 계열은 rpm -qa | grep php)로 설치된 패키지 버전과 하나씩 대조하는 것이다.

    컨테이너로 운영 중이라면 실행 중인 컨테이너 안에서 패키지를 올리는 건 임시방편이다. 이미지는 그대로이니 다음 배포 때 패치 전 상태로 돌아간다. 공식 PHP 이미지의 새 버전을 받아(docker pull) 이미지를 다시 빌드하고 컨테이너를 교체해야 다음 배포에서도 패치가 유지된다.

    지원 끝난 PHP 버전엔 적용할 패치가 없을 수 있다

    PHP는 버전 계열마다 지원 기간이 정해져 있다. php.net의 지원 버전(Supported Versions) 페이지에서 각 계열이 일반 지원 중인지, 보안 수정만 받는지, 지원이 끝났는지 확인할 수 있다. 지원이 끝난 계열에는 PHP 개발진의 보안 수정이 더 나오지 않는다. 오래된 버전으로 돌아가는 사이트라면 이번 같은 결함이 공개돼도 받을 패치 자체가 없을 수 있다. 일부 배포판이나 유료 장기 지원 서비스가 예외적으로 수정을 제공하기도 하지만, 이는 개별적으로 확인해야 한다. 이런 경우에는 패치를 기다리기보다 상위 버전 이전을 계획해야 한다.

    상위 버전으로 옮기는 작업은 버전 숫자만 바꾸면 끝나는 일이 아니다. 오래된 플러그인이나 직접 작성한 코드가 새 버전에서 오류를 낼 수 있어서다. 순서는 이렇게 잡는다.

    1. 파일과 데이터베이스를 함께 백업한다. 호스팅 백업 기능이 있더라도 별도 사본을 내려받아 둔다.
    2. 가능하면 스테이징(복제) 사이트에서 먼저 버전을 올려 본다.
    3. 테마·플러그인·솔루션 제작사의 PHP 호환 정보를 확인하고, 업데이트가 끊긴 플러그인은 대체재를 찾는다.
    4. 운영 사이트의 PHP 버전을 전환한 뒤 로그인, 글쓰기, 회원가입, 결제처럼 데이터와 돈이 오가는 기능부터 점검한다.
    5. 오류가 나면 패널에서 이전 버전으로 되돌릴 수 있는지 미리 확인해 둔다. 되돌린 상태는 취약한 버전이므로 최대한 짧게 유지해야 한다.

    외주로 만들고 관리하지 않는 국내 사이트가 가장 취약하다

    한국 웹 생태계의 PHP 의존도는 낮지 않다. 소규모 쇼핑몰, 커뮤니티, 기업 홈페이지 가운데 그누보드나 워드프레스 같은 PHP 기반 설치형 솔루션으로 만든 곳이 많다. 외주로 제작한 뒤 유지보수 계약 없이 운영되는 곳도 적지 않다. 국내에서 가장 약한 고리가 기술보다 관리 공백으로 보이는 이유다. PHP 버전을 누가 확인할지 정해져 있지 않은 사이트는 패치가 나와도 적용되지 않는다.

    한국 사이트 운영자가 이번 일로 확인할 것은 세 가지다. 첫째, 사이트 소유자가 호스팅 계정 접속 정보를 직접 가지고 있는가. 호스팅이 외주 제작사 명의로 계약돼 있다면 PHP 버전을 확인할 때도 제작사를 거쳐야 한다. 둘째, 호스팅사 공지 채널. 공유 호스팅에서 PHP 엔진 패치는 호스팅사의 몫이지만, 오래된 버전 지원 중단이나 강제 전환 같은 조치는 대개 공지로 먼저 알린다. 셋째, 한국인터넷진흥원(KISA)이 운영하는 보호나라의 보안공지 게시판. 관련 권고가 올라왔는지 여기서 확인할 수 있다.

    확인된 것과 아직 불확실한 것

    확인된 것

    • AI가 PHP에서 10년 묵은 결함을 찾아냈고, 이 결함은 웹의 상당 부분을 위협하는 것으로 평가됐다.
    • 각국 정부가 웹사이트 운영자에게 PHP를 패치하거나 사이트를 오프라인으로 전환하라고 촉구했다.
    • 결함 공개 이후 악용 시도는 수천 건 수준에서 수백만 건 수준으로 늘었다.
    • 별개의 사례로, 해커들이 클로드(Claude)와 그록(Grok)을 이용해 중남미 은행 400곳 이상을 노린 공격을 자동화했다.

    아직 불확실한 것

    • 영향을 받는 PHP 버전 범위와 수정이 들어간 정확한 버전 번호. 원문에는 이 정보가 없으므로 php.net과 사용 중인 배포판의 보안 공지로 확인해야 한다.
    • 결함을 찾아낸 AI가 어떤 모델·조직의 것인지, 결함에 붙은 식별 번호(CVE).
    • 원문이 언급한 각국 정부에 한국 정부 기관이 포함되는지, 국내 기관이 별도 권고를 냈는지.
    • 웹 방화벽(WAF)이나 CDN 보안 규칙만으로 이 결함의 악용을 막을 수 있는지. 패치 전 임시 대책으로 쓰더라도 패치를 대신한다고 보기는 어렵다.

    결함 공개 후 악용이 몰리기 전에, 보안 업데이트를 자동화한다

    결함이 공개되면 수정 방법과 함께 공격 지점도 알려진다. 공격자는 공개된 정보를 바탕으로 인터넷 전체를 자동으로 훑어 패치되지 않은 서버를 찾는다. 공개 뒤 악용 시도가 수천 건에서 수백만 건으로 늘어난 것도 이런 구조 때문이다. 여기에 AI 에이전트로 은행 공격을 자동화한 사례까지 겹쳐 보면, 결함 공개와 대량 악용 사이의 간격은 더 짧아질 가능성이 있다. 이 부분은 두 사례를 근거로 한 해석이며, 간격을 직접 측정한 수치는 원문에 없다.

    방어하는 쪽에서 이 간격을 줄이는 가장 현실적인 방법은 보안 업데이트를 사람 손에만 맡기지 않는 것이다. 우분투·데비안 서버라면 sudo apt install unattended-upgrades로 패키지를 설치하고 sudo dpkg-reconfigure unattended-upgrades에서 자동 설치를 켜면 보안 업데이트가 자동으로 적용된다. 레드햇 계열은 dnf-automatic 패키지가 같은 역할을 한다. 다만 환경에 따라 PHP-FPM이 자동으로 재시작되지 않을 수 있다. 앞에서 짚은 재시작 문제는 자동 업데이트에서도 똑같이 생긴다. 업데이트 뒤 서비스가 재시작됐는지 점검하는 절차를 함께 둬야 한다.

    패치를 바로 적용할 수 없는 사이트라면 각국 정부의 권고처럼 사이트를 잠시 내리는 것도 방법이다. 웹 서버 설정에서 모든 요청을 정적 HTML 점검 페이지로 보내면 PHP 실행을 멈춘 채 방문자에게 안내할 수 있다. 공유 호스팅 사용자는 PHP 엔진을 직접 고칠 수 없다. 호스팅사의 대응 일정을 확인하면서 그동안 백업을 확보해 두자. 서버에 남아 있는 테스트용 설치본이나 쓰지 않는 사이트를 지워 공격받을 수 있는 범위를 줄여 두는 편이 낫다.

    출처: MIT Tech Review AI

  • 동료 평가 없던 테라노스, 프리프린트 읽는 법

    동료 평가 없던 테라노스, 프리프린트 읽는 법

    3줄 요약

    • 테라노스에서 가장 먼저 드러난 경고 신호는 동료 평가를 거쳐 공개된 데이터가 부족했다는 점이다. 연구의 상당 부분이 ‘영업 비밀’로 분류돼 외부에서 검증하기 어려웠다.
    • 동료 평가도 만능은 아니다. 2023년 한 해 동안 철회된 연구 논문만 1만 건이다.
    • 프리프린트, 기업 보도자료, SNS, 상당수 학회 발표는 동료 평가를 거치지 않는다. 주장을 믿기 전에 어디서 나온 정보인지부터 확인해야 한다.

    피 몇 방울이면 100가지가 넘는 진단 검사를 할 수 있다. 미국 진단 기업 테라노스는 이 약속 하나로 돈을 끌어모았다. 투자금은 수억 달러에 이르렀고, 2014년에는 기업 가치가 90억 달러로 평가됐다. 포브스는 창업자 엘리자베스 홈즈를 최연소 자수성가 여성 억만장자로 꼽았다. 당시 30세였던 홈즈의 자산은 45억 달러로 평가됐다.

    결론부터 말하면 경고 신호는 처음부터 있었다. 그 거창한 약속을 뒷받침할 데이터, 그중에서도 동료 평가를 거쳐 공개된 데이터가 부족했다. 기업 가치 90억 달러와 검증된 데이터 사이의 간극. 테라노스 사건은 결국 거기서 시작해 거기서 무너졌다.

    이 글은 사기 사건의 전말보다 사건이 남긴 질문에 무게를 둔다. 과학·바이오 기술 주장을 접했을 때 무엇을 근거로, 얼마나 믿어야 하는가. 동료 평가와 프리프린트, 논문 철회가 각각 무엇인지 짚고, 정보가 어디서 나왔느냐에 따라 검증 수준이 얼마나 달라지는지 차례로 살펴본다.

    90억 달러 기업이 사기 사건으로 끝나기까지

    테라노스 이야기는 이미 여러 번 다른 형식으로 만들어졌다. 책 ‘배드 블러드(Bad Blood)’가 있고, 훌루 드라마 ‘드롭아웃(The Dropout)’이 있다. 여기에 다큐멘터리 ‘You Can See Everything’이 더해졌는데, 수감 직전 홈즈가 집에서 보낸 생활을 담았다. 연도별로 추리면 흐름은 이렇다.

    • 2003년: 19세 홈즈가 스탠퍼드대를 중퇴하고, 직접 세운 진단 기업 테라노스 경영에 나섬
    • 2014년: 기업 가치 90억 달러로 평가
    • 2015년: 월스트리트저널 조사에서 전 직원들이 검사가 제대로 작동하지 않는다고 문제 제기. 기기가 제대로 테스트되지 않았고, 혈액 샘플을 다른 회사 장비로 분석했다는 증언도 나옴
    • 2016년: 홈즈의 자산 평가가 0달러로 떨어짐. 정부 보고서는 회사 연구소가 기본 절차조차 제대로 수행하지 못했고, 결과가 틀릴 수 있다는 것을 알면서도 환자에게 전달했다고 지적
    • 2018년: 테라노스, 홈즈, 전 사장 라메시 발와니가 ‘대규모 사기’ 혐의로 기소됨
    • 2022년: 홈즈가 투자자를 속인 사기 혐의로 11년 남짓의 징역형을 선고받음
    • 2023년 5월: 수감 시작

    2003년 창업부터 2015년 월스트리트저널 보도가 나오기까지, 투자자와 언론은 물론 회사 안의 직원들까지 몇 년 동안 설득당했다. 기술이 실제로 작동하는지 바깥에서 확인할 방법이 마땅치 않았던 탓이 커 보인다. 무너지는 속도는 정반대였다. 보도가 나오고 바로 이듬해인 2016년, 홈즈의 자산 평가는 0달러가 됐다.

    영업 비밀 뒤에 가려진 데이터, 테라노스가 건너뛴 동료 평가

    동료 평가(peer review)는 연구 결과를 학술지에 싣기 전에 같은 분야 전문가에게 먼저 검토를 받는 절차다. 대략 이런 식으로 돌아간다.

    • 검토는 대개 익명의 해당 분야 전문가가 맡는다
    • 미심쩍은 결론은 지적하고, 불분명한 대목은 설명을 요구한다
    • 수정과 보완을 거쳐야 게재되므로 시간이 오래 걸린다

    번거롭지만 목적은 분명하다. 출판 과정의 엄밀성을 높이는 것. 동료 평가를 통과한 논문이라면 적어도 다른 전문가의 검토를 한 번은 거쳤다는 뜻이 된다.

    테라노스에는 그 한 번이 없었다. 동료 평가를 거쳐 공개된 데이터가 부족했고, 연구의 상당 부분은 영업 비밀로 묶였다. 지나고 나서 돌아보면 경고 신호는 네 가지로 추려진다.

    • 데이터 비공개: 핵심 연구가 영업 비밀로 묶여 외부 검증이 어려움
    • 검증 부족: 자사 기기를 제대로 테스트하지 않았다는 내부 증언
    • 다른 회사 장비 사용: 자사 기술 대신 다른 회사 장비로 샘플을 분석했다는 증언
    • 기본 절차 부실: 연구소가 기본 절차도 제대로 수행하지 못했다는 정부 보고서

    네 가지를 나란히 놓으면 눈에 띄는 점이 있다. 나머지 세 신호는 내부 증언과 정부 보고서가 나온 뒤에야 바깥에 알려졌다. 첫 번째 신호인 데이터 비공개가 나머지 셋을 가려 준 셈이다.

    오해는 없어야 한다. 영업 비밀 자체는 기업이 기술을 지키는 정당한 수단이다. 문제가 되는 건 주장의 크기에 비해 공개된 증거가 적을 때다. ‘피 몇 방울로 100가지 이상 검사’ 정도의 주장이라면, 그만큼 많은 외부 검증이 따라붙어야 한다. 주장이 클수록 요구되는 증거도 커진다.

    동료 평가를 통과해도 철회된다, 2023년에만 1만 건

    동료 평가를 거쳤다고 마음 놓을 수는 없다. 과학자도 실수를 한다. 때로는 결과를 일부러 비틀기도 한다. 아래 문제들은 동료 평가 단계에서 걸러지기도 하지만, 늘 걸러지는 건 아니다.

    • 과장: 결과를 부풀리거나 실제보다 큰 의미를 부여함
    • 데이터 조작: 가설에 맞도록 데이터를 손봄
    • 재현 실패: 다른 연구실에서 같은 결과가 나오지 않고, 이후 쌓인 증거 앞에서 결론이 무너짐

    그래서 학술지에는 출판 뒤에 오류를 바로잡는 장치가 따로 있다. 크게 두 가지다.

    • 정정(correction): 논문의 오류 일부를 바로잡는 공지. 결국 정정이 붙는 논문이 적지 않다
    • 철회(retraction): 논문 자체를 무효로 돌리는 조치. 2023년 한 해 동안 연구 논문 1만 건이 철회됐다

    1만 건이라는 숫자는 불안하게 들린다. 뒤집어 보면 과학계가 스스로 오류를 찾아내 바로잡은 결과이기도 하다. 여기서 독자가 가져갈 것은 ‘논문도 못 믿겠다’는 냉소가 아니다. 인용된 논문이 나중에 정정되거나 철회되지 않았는지 한 번 확인해 보는 습관이다. 방법은 간단하다.

    1. 논문이 실린 학술지 페이지로 이동
    2. 제목 근처나 본문 위쪽에 Retracted, Retraction, Correction 표시가 있는지 확인
    3. 검색창에 논문 제목과 retraction을 함께 입력해 철회 공지가 따로 있는지 검색

    재현 여부도 같이 봐야 한다. 한 연구실이 낸 결과 한 건과, 다른 연구실에서 같은 결과를 얻은 후속 연구가 뒤따른 결과는 무게가 다르다. 믿을 만한 쪽은 당연히 후자다.

    학술지 밖으로 퍼지는 과학 정보, 출처마다 검증 수준이 다르다

    과학 정보가 학술지로만 퍼지는 것은 아니다. 학술지에 투고하기 전에 프리프린트 서버에 연구를 먼저 올리는 과학자가 많다. arXiv, medRxiv, bioRxiv가 대표적이다. 연구를 빠르게 공유할 수 있다는 장점이 있지만, 동료 평가는 거치지 않는다. 기업 보도자료와 SNS, 학회 발표까지 한데 놓고 비교하면 다음과 같다.

    정보 출처 동료 평가 읽을 때 확인할 점
    학술지 게재 논문 거침 정정·철회 이력, 다른 연구실에서 재현됐는지
    프리프린트(arXiv, medRxiv, bioRxiv) 거치지 않음 나중에 학술지에 실렸는지, 다른 전문가의 반응
    기업 보도자료 거치지 않음 근거 데이터 공개 여부, 발표 주체의 이해관계
    SNS 게시물 거치지 않음 원 출처(논문·데이터) 링크가 있는지
    학회 발표 상당수 거치지 않음 나중에 논문으로 발표됐는지
    인터뷰·대화 해당 없음 발언을 뒷받침할 자료가 있는지
    영업 비밀로 분류된 기업 연구 외부 검증 어려움 주장의 크기에 걸맞은 증거가 공개됐는지

    표에서 ‘거침’이라고 적힌 칸은 학술지 게재 논문 한 줄뿐이다. 나머지 여섯 줄은 동료 평가를 거치지 않았거나, 애초에 해당 사항이 없거나, 외부에서 검증하기 어려운 정보다. 테라노스의 연구는 맨 아래 줄에 들어간다.

    그렇다고 프리프린트가 나쁜 정보라는 뜻은 아니다. ‘아직 검증 전’이라는 꼬리표를 붙이고 읽으면 된다. 프리프린트인지 가려내는 순서는 이렇다.

    1. 기사나 SNS에 걸린 링크를 눌러 주소가 arxiv.org, medrxiv.org, biorxiv.org인지 확인
    2. medRxiv·bioRxiv 논문 페이지 위쪽에서 ‘동료 평가를 거치지 않은 프리프린트’라는 취지의 안내 문구 확인
    3. 같은 페이지에 Now published in(학술지명) 링크가 있는지 확인. 있으면 이후 학술지에 실린 논문이다 (표시 위치는 확실하지 않음)
    4. arXiv는 초록 페이지의 Journal reference 항목 확인. 저자가 직접 입력하는 항목이므로, 비어 있다고 해서 학술지에 실리지 않았다고 단정할 수는 없다

    4번처럼 저자 입력에 기대는 항목은 다루기가 까다롭다. 적혀 있으면 참고하고, 비어 있으면 판단을 미루는 정도가 적당하다. 학술지 쪽에서 해당 논문을 직접 찾아보는 편이 확실하다.

    ‘연구진이 밝혔다’로 끝나는 번역 기사, 출처 유형부터 가려 읽기

    테라노스는 미국에서 벌어진 일이다. 하지만 한국 사용자가 과학·의료 정보를 접하는 경로에도 같은 빈틈이 있다. 미리 밝혀 두면, 아래 내용은 원문에서 확인된 사실이 아니라 앞의 개념을 국내 상황에 적용해 본 판단이다.

    • 번역 기사에서는 출처 유형이 흐려진다: 해외 연구를 소개하는 기사가 ‘연구진이 밝혔다’고만 쓰면, 그 결과가 학술지 논문인지 프리프린트인지 보도자료인지 독자로서는 구분하기 어렵다. 기사에 걸린 원문 링크나 논문 제목을 찾아 앞의 표에 대입해 보자.
    • 바이오 기업의 성과 발표는 보도자료일 수 있다: 기업이 직접 낸 발표는 동료 평가를 거치지 않은 정보다. 투자 판단에 쓸 생각이라면 학술지 논문이나 공개 데이터가 함께 제시됐는지부터 확인하는 편이 안전하다. 테라노스 투자자들이 놓친 지점도 결국 이것이었다.
    • 진단 기기·검사 키트는 허가 여부가 먼저다: 국내에서 질병 진단 목적으로 판매되는 의료기기는 식품의약품안전처의 허가·인증·신고 대상이다. 광고 문구에 끌리기 전에 이 절차를 거쳤는지부터 본다.

    의료기기 허가 정보는 다음 순서로 조회할 수 있다.

    1. 식품의약품안전처 의료기기 전자민원창구 누리집 접속
    2. 정보 검색 → 제품 정보 조회 메뉴로 이동 (메뉴명 불확실)
    3. 제품명이나 업체명을 입력한 뒤 허가·인증 번호와 사용 목적 확인

    확인된 것과 아직 불확실한 것

    확인된 것

    • 홈즈는 투자자를 속인 사기 혐의로 11년 남짓의 징역형을 선고받았고, 2023년 5월 수감됐다
    • 2016년 정부 보고서는 테라노스 연구소의 기본 절차 문제와, 틀릴 수 있는 결과를 환자에게 전달한 사실을 지적했다
    • 테라노스는 연구의 상당 부분을 영업 비밀로 분류했고, 동료 평가를 거쳐 공개된 데이터가 부족했다
    • 2023년 한 해 동안 철회된 연구 논문은 1만 건이다
    • 프리프린트 서버, 기업 보도자료, SNS 게시물, 상당수 학회 발표는 동료 평가를 거치지 않는다

    아직 불확실한 것

    • 다큐멘터리가 책·드라마·기존 보도에 없던 새 사실을 담았는지: 리뷰를 쓴 기자가 스포일러를 피하려고 구체적으로 밝히지 않았다
    • 다큐멘터리에서 홈즈가 자신을 ‘독특한 사고방식을 지닌 정직한 사람’으로 그리려는 시도가 관객에게 받아들여질지
    • 철회된 논문 1만 건 가운데 부정행위와 단순 오류가 각각 얼마인지: 원문에는 전체 건수만 나온다
    • 프리프린트 가운데 나중에 학술지에 실리는 비율: 원문에 근거 자료가 없다

    기자들도 홈즈에게 설득됐다, 증거를 가려내는 다섯 가지 질문

    테라노스를 가까이서 지켜본 사람들도 예외가 아니었다. 취재한 기자들조차 나중에 자기 판단을 뒤집었다.

    • 포춘의 로저 팔로프는 홈즈와 회사를 소개한 지 1년 뒤인 2015년, “내가 망쳤다(I blew it)”고 돌아봤다
    • 2015년 홈즈를 인터뷰한 STAT의 매슈 허퍼는 “그녀가 내게 거짓말을 했다고 꽤 확신한다”고 썼다
    • 제품이 작동하지 않는다는 것을 알고 있던 내부고발자 타일러 슐츠도 2022년, 홈즈와 5분만 이야기하면 자기 일이 세상을 바꾸고 있다고 느끼며 자리를 떴을 것이라고 말했다

    MIT 테크놀로지 리뷰의 바이오 담당 기자도 비슷한 고백을 내놨다. 다큐멘터리를 보다가 극장 좌석에서 홈즈에게 설득되는 순간이 있었다는 것이다. 이 기자가 던지는 질문은 하나다. 과학자가 무언가를 해냈다고 말할 때, 그게 사실인지 어떻게 확신할 수 있느냐. 이 기자가 내놓은 답은 절차다. 새 과학 성과를 기사로 쓰기 전에 신뢰하는 과학자들에게 의견을 구하는 ‘자체 동료 평가’를 거친다.

    일반 독자에게도 그대로 통하는 방법이다. 작동하지 않는다는 걸 알던 내부고발자조차 5분 대화면 마음이 기울었을 거라고 말할 정도라면, 개인의 직감에 기댈 일은 아니다. 정해진 확인 절차가 더 믿을 만하다.

    1. 데이터가 공개돼 있나: ‘영업 비밀’을 이유로 핵심 데이터를 보여주지 않으면 경고 신호다
    2. 어디서 나온 주장인가: 학술지 논문인지, 프리프린트·보도자료·SNS인지 앞의 표에 따라 분류한다
    3. 다른 연구실에서 재현됐나: 단일 연구의 결과는 잠정적인 것으로 본다
    4. 정정·철회 이력은 없나: 학술지 페이지와 검색으로 확인한다
    5. 당사자가 아닌 전문가는 뭐라고 하나: 연구를 한 사람이 아닌 같은 분야 전문가의 평가를 찾아본다

    대부분의 과학자는 정직할 것이다. 홈즈는 분명 극단적인 예외다. 다만 이야기가 매력적일수록 증거는 따로 떼어 놓고 확인해야 한다. 설득력 있는 이야기와 증거는 별개의 문제다.

    출처: MIT Tech Review AI

  • PHP 취약점 패치, 재시작 안 하면 구버전 그대로

    PHP 취약점 패치, 재시작 안 하면 구버전 그대로

    3줄 요약

    • PHP 보안 패치는 공개되는 순간 공격자도 수정 내용을 분석할 수 있어, 성공한 공격이 아직 없다는 사실이 업데이트를 미룰 근거가 되지 못한다.
    • 업데이트 전에 CLI와 웹 서버가 실제로 쓰는 PHP 버전, 그리고 배포판 패키지·외부 저장소·컨테이너·호스팅 중 어떤 방식으로 설치됐는지부터 파악해야 한다.
    • 패키지를 올린 뒤 PHP-FPM이나 웹 서버를 재시작하고 웹 경로에서 버전을 다시 확인해야 패치가 실제로 적용된다.

    PHP 취약점 하나 때문에 세계 곳곳의 웹사이트가 오프라인이 됐다. 각국 당국은 서둘러 패치를 적용하라고 촉구했다. 그런데 개발자 커뮤니티는 다른 쪽을 봤다. 패치를 만드는 사람이다. 소프트웨어 개발자 이언 랜즈먼(Ian Landsman)은 PHP 취약점 패치 작업을 맡아 온 자원봉사자 온드르제이 수리(Ondřej Surý)를 인터넷 전체의 숨은 영웅이라고 부르며 X에 이렇게 썼다. “이 사람에게 무슨 일이라도 생기면 그걸로 끝이다. 모두 끝장이다.”

    패치는 누가 만들든 받아서 서버에 적용하는 일은 운영자에게 남는다. 이 글은 PHP 취약점 소식이 나왔을 때 무엇부터 확인하고 어떤 순서로 업데이트해야 하는지를 다룬다. 아래 명령어와 경로는 리눅스 배포판과 호스팅 제어판 버전에 따라 표기가 조금씩 다를 수 있다. 자기 환경에 맞춰 읽으면 된다.

    패치가 공개되면 공격자도 같은 코드를 읽는다

    보안 패치는 방어하는 쪽에게는 해결책이지만 공격하는 쪽에게는 지도 노릇을 한다. 오픈소스 프로젝트는 수정 코드를 공개 저장소에 올린다. 그래서 패치 전후 코드를 나란히 놓고 비교하면 어느 함수에서 어떤 검사가 빠져 있었는지 드러난다. 이런 작업을 패치 디핑(patch diffing)이라고 하고, 이미 알려진 취약점을 노리는 공격은 흔히 엔데이(n-day) 공격이라고 부른다. 공개된 수정 사항이 해커를 도울 수 있다는 이코노미스트의 지적도 이 구조를 두고 한 말이다.

    지금까지 확인된 사실은 두 가지다. 전문가들은 이번 PHP 취약점이 예상보다 악용하기 어렵다고 평가했다. 공격에 성공한 사례도 아직 나오지 않았다. 아래는 해석이다. 이 평가는 지금까지 관찰한 결과일 뿐이고 앞으로를 보장하지는 않는다. 누군가 공격 코드를 공개하면 그 코드는 바로 대량 스캔 도구에 들어간다. 그때부터 패치하지 않은 서버는 자동화된 공격의 표적이 된다. 악용 난도가 높다는 소식을 업데이트를 몇 주 미뤄도 된다는 신호로 받아들이면 곤란하다. 공격 코드가 나오기 전에 패치할 시간이 조금 더 남았다는 뜻으로 읽는 편이 안전하다.

    터미널의 PHP와 웹 요청을 받는 PHP는 버전이 다를 수 있다

    첫 단계는 내 서버에서 PHP가 어떤 형태로 돌고 있는지 파악하는 일이다. 한 서버에 여러 버전이 설치된 경우는 흔하다. 터미널에서 쓰는 PHP(CLI)와 웹 요청을 처리하는 PHP(PHP-FPM 또는 아파치 모듈)의 버전이 다를 수도 있다. 터미널에서 php -v 한 번 쳐 보고 끝내면 안 되는 이유다.

    • CLI 버전: 터미널에서 php -v를 실행한다. 실행 파일 경로는 which php로, 불러오는 설정 파일 경로는 php --ini로 함께 확인한다.
    • 웹 서버가 쓰는 버전: 웹 루트에 <?php phpinfo(); 한 줄짜리 파일을 임시로 만들어 브라우저로 열면 PHP Version과 Server API 항목이 나온다. Server API가 FPM/FastCGI면 PHP-FPM, Apache 2.0 Handler면 아파치 모듈 방식이다. 이 파일은 서버 구성을 그대로 드러내므로 확인이 끝나면 바로 지워야 한다.
    • 실행 중인 서비스: systemctl list-units --type=service | grep -i php로 PHP-FPM 서비스 이름을 찾는다. 버전별 서비스가 여러 개 떠 있으면 모두 업데이트하고 재시작해야 한다.
    • 워드프레스 관리자 화면: 도구 → 사이트 건강 → 정보 탭 → 서버 항목에 웹 서버가 쓰는 PHP 버전이 나온다.

    버전 숫자만 보고 판단하면 틀릴 수 있다. 데비안·우분투·RHEL 계열 배포판은 버전은 그대로 두고 보안 수정만 덧붙이는 백포트 방식을 쓴다. 그래서 php -v에 찍힌 버전이 오래돼 보여도 이미 패치가 들어가 있을 수 있다. 배포판 패키지라면 apt changelog 패키지명(데비안·우분투)이나 rpm -q --changelog 패키지명(RHEL 계열)으로 변경 이력을 열어 보고, 해당 취약점 식별 번호(CVE)가 있는지 찾는 편이 정확하다. 보안 공지를 처음 볼 때 버전 번호보다 CVE 번호를 먼저 적어 두면 이 단계에서 시간을 아낄 수 있다.

    설치 방식에 따라 패치를 내주는 곳이 다르다

    PHP를 어떤 방식으로 설치했느냐에 따라 패치를 받는 경로가 달라지고, 그 패치를 책임지는 주체도 달라진다. 대표적인 설치 방식별 업데이트 방법과 주의점을 아래 표에 정리했다.

    설치 방식 패치 제공 주체 업데이트 방법 주의점
    배포판 공식 패키지(데비안·우분투) 배포판 보안팀 sudo apt update 후 apt list --upgradable | grep php로 대상 확인, sudo apt upgrade 버전 번호 대신 패키지 변경 이력으로 수정 여부 확인
    배포판 공식 패키지(RHEL 계열) 배포판 보안팀 sudo dnf check-update 'php*' 후 sudo dnf upgrade 'php*' 모듈 스트림을 쓰는 버전이면 선택한 스트림 안에서만 업데이트됨
    외부 저장소 패키지 저장소 메인테이너(개인·자원봉사자 포함) 배포판과 같은 패키지 관리자 명령으로 업데이트 저장소가 해당 PHP 버전을 계속 지원하는지 확인
    소스 직접 빌드 운영자 본인 PHP 공식 사이트의 수정 릴리스를 받아 다시 컴파일·설치 직접 빌드한 확장 모듈도 함께 다시 빌드해야 할 수 있음
    컨테이너 이미지 이미지 제작자 docker build --pull로 기반 이미지를 새로 받아 재빌드 후 재배포 실행 중인 컨테이너는 교체 전까지 구버전 그대로
    공유 호스팅·관리형 서비스 호스팅 업체 제어판에서 PHP 버전 선택, 엔진 패치는 업체가 적용 업체 공지로 조치 여부 확인

    표에서 따로 볼 줄은 외부 저장소다. 배포판 공식 저장소에 없는 PHP 버전을 쓰려고 개인 메인테이너가 운영하는 저장소를 추가하는 경우가 많다. 이 경우 패치가 얼마나 빨리 나오는지, 지원이 언제까지 이어지는지는 그 메인테이너의 작업량과 일정에 달려 있다. PHP 패치 작업을 자원봉사자 한 사람이 떠받치고 있다는 랜즈먼의 지적은, 해석하자면 바로 이 공급망 구조의 약점을 짚은 것이다. 이 구조를 운영자가 바꿀 수는 없다. 배포판 공식 패키지나 공식 컨테이너 이미지처럼 옮겨 갈 수 있는 경로를 미리 알아 두는 것이 현실적인 대비다.

    ‘업데이트 완료’ 메시지 다음에 할 일: 재시작과 검증

    패키지 관리자가 업데이트 완료를 출력했어도 패치가 끝난 것은 아니다. PHP-FPM과 아파치는 시작할 때 PHP 엔진을 메모리에 올려 두고 쓴다. 그래서 프로세스를 다시 띄우기 전까지는 구버전 코드가 계속 요청을 처리한다. OPcache에 남아 있던 캐시도 재시작할 때 비워진다.

    1. PHP-FPM 재시작: 앞에서 찾은 서비스 이름으로 sudo systemctl restart 서비스명을 실행한다. 서비스 이름은 데비안·우분투에서는 버전 번호가 붙은 형태(php버전-fpm)이고, RHEL 계열에서는 보통 php-fpm이다.
    2. 아파치 모듈 방식: 데비안·우분투는 sudo systemctl restart apache2, RHEL 계열은 sudo systemctl restart httpd를 실행한다.
    3. 버전 검증: phpinfo 임시 파일을 다시 열어 PHP Version과 Build Date가 바뀌었는지 확인하고 바로 지운다. 백포트 방식 배포판에서는 PHP Version 숫자가 그대로일 수 있으므로 Build Date를 보는 편이 확실하다. 패키지 설치 상태는 dpkg -l | grep php 또는 rpm -qa | grep php로 본다.
    4. 로그 점검: 재시작 직후 웹 서버와 PHP-FPM 에러 로그를 열어 확장 모듈 로딩 실패 같은 오류가 없는지 살핀다.

    컨테이너 환경에서는 확인할 것이 하나 더 있다. 새 이미지를 배포한 뒤 실제로 떠 있는 컨테이너가 새 이미지로 바뀌었는지 docker ps와 docker inspect로 확인해야 한다. 이미지만 새로 빌드하고 컨테이너를 교체하지 않으면 서비스는 계속 구버전 PHP로 돈다. 표의 주의점 칸에 적은 ‘실행 중인 컨테이너는 교체 전까지 구버전 그대로’가 바로 이 경우다.

    그누보드·워드프레스 사이트는 호스팅 PHP 버전부터 점검

    국내에서는 워드프레스, 그누보드처럼 PHP로 만든 CMS와 게시판 솔루션이 소규모 쇼핑몰, 커뮤니티, 기관 홈페이지에 널리 쓰인다. 이런 사이트는 서버를 직접 관리하지 않고 웹호스팅을 쓰는 경우가 많다. 따라서 운영자가 할 일과 호스팅 업체가 할 일을 먼저 나눠야 한다.

    • 공유 호스팅: PHP 엔진 자체의 보안 패치는 호스팅 업체가 서버 단위로 적용한다. 운영자가 할 일은 두 가지다. 업체 공지사항이나 고객센터에서 해당 취약점을 조치했는지 확인하는 것, 그리고 제어판에서 지원이 끝난 구버전 PHP를 선택해 두지 않았는지 점검하는 것. cPanel 기반 호스팅이라면 소프트웨어 → MultiPHP Manager(업체에 따라 Select PHP Version)에서 버전을 바꾼다. 국내 업체 자체 제어판에서도 PHP 버전 선택 항목을 찾아 같은 방식으로 바꾸면 된다(항목 위치는 불확실하니 업체 도움말 참고).
    • VPS·클라우드 서버: 서버 OS와 PHP 패키지는 운영자 책임이다. 앞의 표대로 직접 업데이트하고 재시작까지 끝내야 한다. 관리형 상품이라도 OS 패치가 계약 범위에 들어가는지는 따로 확인해야 한다.
    • CMS 호환성: PHP 버전을 크게 올리면 오래된 테마, 플러그인, 게시판 스킨이 동작하지 않을 수 있다. 같은 버전대 안의 보안 업데이트는 호환성 문제가 상대적으로 적다. 지원이 끝난 버전에서 새 버전으로 옮길 때는 백업을 받고 테스트 환경에서 먼저 확인한 다음 옮긴다.

    국내 사이트가 얼마나 피해를 봤는지 가늠할 자료는 아직 없다. 국내 기준의 대응 지침은 KISA 보호나라 보안 공지에 관련 권고가 올라왔는지 확인하면 얻을 수 있다.

    확인된 것과 아직 불확실한 것

    확인된 것

    • PHP에서 취약점이 공개됐고, 그 여파로 세계 곳곳의 웹사이트가 오프라인이 됐다. 당국은 패치 적용을 촉구했다.
    • 전문가들은 해당 취약점이 예상보다 악용하기 어렵다고 평가했고, 성공한 공격 사례는 아직 나오지 않았다.
    • 공개된 수정 사항이 오히려 해커에게 단서가 될 수 있다는 지적이 나왔다.
    • 자원봉사자 온드르제이 수리가 PHP 취약점 패치 작업을 맡아 왔고, 개발자 이언 랜즈먼은 그를 인터넷 전체의 숨은 영웅으로 평가했다.

    아직 불확실한 것

    • 정확히 어떤 PHP 버전과 구성이 영향을 받는지는 PHP 공식 보안 공지와 각 배포판 보안 권고에서 직접 확인해야 한다.
    • 웹사이트가 오프라인이 된 경위가 실제 공격 때문인지, 장애나 예방 차원의 조치 때문인지는 알려진 내용만으로 구분하기 어렵다.
    • 악용이 어렵다는 평가가 공격 코드 공개 이후에도 유지될지는 알 수 없다.
    • 국내 호스팅 업체별 조치 시점과 국내 피해 규모는 확인되지 않았다.

    다음 PHP 취약점 때 확인 시간을 줄이는 다섯 가지 습관

    긴급 패치 때 허비하는 시간은 대부분 업데이트가 아니라 확인 작업에서 나온다. 앞에서 본 버전 확인, 설치 방식 파악, 서비스 이름 찾기가 모두 여기에 해당한다. 평소에 아래 항목을 준비해 두면 취약점 소식이 나온 날 바로 업데이트 단계로 넘어갈 수 있다.

    • 지원 기간 점검: PHP 공식 사이트의 지원 버전(Supported Versions) 안내에서 지금 쓰는 버전이 보안 지원 기간 안에 있는지 정기적으로 확인한다. 지원이 끝난 버전에는 공식 보안 수정이 나오지 않는다.
    • 보안 공지 구독: 사용하는 배포판의 보안 권고 페이지나 메일링 리스트를 구독한다. 외부 저장소를 쓴다면 그 저장소의 공지 채널도 함께 구독한다.
    • 자동 보안 업데이트: 데비안·우분투는 unattended-upgrades, RHEL 계열은 dnf-automatic으로 보안 업데이트만 자동 적용하도록 설정할 수 있다. 다만 자동 설치 뒤 PHP-FPM 재시작까지 이어지는지는 따로 확인해야 한다. 재시작을 하지 않으면 새 패키지는 설치돼 있어도 요청은 여전히 구버전 엔진이 처리한다.
    • 설치 방식 기록: 서버마다 PHP를 어떤 경로로 설치했는지, FPM 서비스 이름이 무엇인지 문서로 남겨 둔다. 그러면 긴급 상황에서 확인 단계를 건너뛸 수 있다.
    • 스테이징 서버 유지: 운영 서버와 같은 구성의 테스트 서버에 먼저 적용해 확장 모듈과 애플리케이션 동작을 확인한 뒤 운영 서버에 반영한다.

    공개된 패치를 오래 방치할수록 그 패치는 방어 수단보다 공격 안내서에 가까워진다. 이번처럼 악용이 어렵다는 평가가 나온 취약점도 마찬가지다. 버전 확인, 설치 방식 파악, 업데이트, 재시작, 검증. 이 다섯 단계를 정해진 절차로 만들어 두면 패치가 공개된 뒤 공격 코드가 나오기까지의 시간을 운영자에게 유리하게 쓸 수 있다.

    출처: MIT Tech Review AI

  • 기업 AI 확장, 뱅가드가 꼽은 기반 5요소

    기업 AI 확장, 뱅가드가 꼽은 기반 5요소

    3줄 요약

    • AI를 전사로 확장하려면 좋은 모델 하나로는 부족하다. 데이터, 엔지니어링, 플랫폼, 운영 모델, 거버넌스 다섯 요소가 한 몸처럼 맞물려야 한다.
    • 금융처럼 규제가 강한 산업에서는 책임 있고 믿을 수 있게 구현하는 것부터가 확장의 출발점이다.
    • 에이전트형 AI를 붙이기 전에 다섯 요소 중 가장 약한 곳부터 진단하는 게 순서다.

    AI와 머신러닝, 생성형 AI, 여기에 행동과학까지. 투자 회사 뱅가드(Vanguard)는 이 네 분야를 ‘AI·인사이트 센터(Center for AI & Insights, CAI)’라는 한 조직 안에 두고 있다. 행동과학은 사람이 어떻게 의사결정을 내리는지 연구하는 학문이다. 이런 분야가 기술 조직 안에 함께 들어가 있는 건 꽤 의외다. 이 센터를 이끄는 징 왕(Jing Wang)은 MIT 테크놀로지 리뷰가 연 EmTech Future 컨퍼런스 세션에서 모델 성능 이야기를 꺼내지 않았다. 대신 확장 가능한 AI에는 튼튼한 기반이 필요하다고 짚었다. 세션의 요지는 이렇다. 그 기반은 데이터·엔지니어링·플랫폼·운영 모델·거버넌스가 하나로 모여 함께 움직일 때 생긴다.

    이 글은 세션 내용을 순서대로 옮기지 않는다. 먼저 다섯 요소가 각각 어떤 역할을 하는지 본다. 왜 하나만 빠져도 AI가 시범 사업 단계에서 멈추는지도 함께 짚는다. 규제가 까다로운 업종과 에이전트형 AI를 준비하는 조직이 어디부터 점검하면 되는지는 그다음에 다룬다. 미리 밝혀 둘 것이 있다. 세션 소개글에는 다섯 요소의 이름과 방향이 담겨 있다. 하지만 뱅가드가 각 요소를 실제로 어떻게 구현했는지는 나오지 않는다. 그래서 아래 해설에서는 원문으로 확인되는 내용과 이 글의 해석을 되도록 문장 단위로 나눠 적었다.

    AI 시범 사업이 전사로 못 퍼지는 원인은 대개 모델 밖에 있다

    사내 AI 프로젝트는 대개 작게 시작한다. 한 팀이 직접 골라낸 데이터로 모델을 만들고, 몇 명이 써 본다. 데모 반응이 좋으면 성공 사례로 기록된다. 탈이 나는 건 이걸 다른 부서와 더 많은 고객, 더 많은 업무로 넓히려는 순간이다.

    부서마다 같은 항목을 다르게 정의한 데이터가 뒤섞인다. 사람이 손으로 하던 배포와 점검은 늘어난 물량을 감당하지 못한다. 만든 팀, 쓰는 팀, 책임지는 팀이 제각각 갈라지는 것도 대개 이 무렵이다. 법무·리스크 검토가 출시 직전에야 붙으면 프로젝트가 그 자리에서 멈추기도 한다. 어느 경우든 모델을 더 좋은 것으로 바꾼다고 풀리는 병목은 아니다. 원문은 모델 대신 기반 요소 다섯 가지를 꼽았다. 이 글은 그 선택을 이런 맥락에서 읽는다.

    원문에서 눈여겨볼 단어는 ‘수렴(converge)’이다. 다섯 요소가 각자 성숙하는 것만으로는 모자라고, 하나의 시스템처럼 맞물려야 한다는 뜻이다. 데이터 팀은 훌륭한데 플랫폼이 부서별로 쪼개진 조직이 있을 수 있다. 거버넌스 규정은 문서로 있는데 실제 개발 도구에는 반영되지 않은 조직도 있다. 두 조직 모두 확장 단계에서 결국 같은 벽에 부딪힌다. 다섯 가운데 넷을 잘 갖춰도 하나가 비면 확장이 막힌다.

    데이터에서 거버넌스까지, 다섯 요소가 각각 맡는 일

    다섯 요소를 하나씩 풀면 아래와 같다. 뱅가드 CAI의 역할을 다룬 대목만 소개글 내용이다. 나머지는 각 요소가 일반적으로 맡는 역할을 이 글이 풀어 쓴 설명이다.

    데이터는 AI가 무엇을 근거로 판단하느냐의 문제다. 품질만 따져서는 안 된다. 누가 어떤 권한으로 데이터에 접근하는지가 걸려 있다. 부서마다 같은 지표를 같은 정의로 쓰는지, 데이터가 어디서 와서 어떻게 가공됐는지 추적할 수 있는지도 함께 따져야 한다.

    엔지니어링은 실험실의 모델을 실제 서비스로 옮기는 작업이다. 테스트, 배포, 성능 감시, 업데이트를 사람 손에 맡기지 않고 반복 가능한 절차로 만든다. 흔히 MLOps라 부르고, 생성형 AI 쪽에서는 LLMOps라는 말도 쓴다.

    플랫폼은 팀마다 같은 것을 처음부터 다시 만들지 않게 해 주는 공용 바닥이다. 모델 접근, 검색 같은 공통 기능, 평가 도구, 권한 관리를 한곳에서 제공할 수 있다. 그러면 두 번째, 세 번째 프로젝트는 훨씬 빨리 출발할 수 있다.

    운영 모델은 결국 조직도의 문제다. 중앙 AI 조직이 전부 만들 수도 있다. 사업 부서에 전문가를 두고 중앙은 표준과 플랫폼만 맡는 방식도 있다. 다 만든 뒤 유지보수를 누가 하느냐도 여기서 정해진다. 소개글에 적힌 바로는 뱅가드 CAI가 전사 차원의 혁신과 연구에 더해 실제 결과물 전달(delivery)까지 맡는다. 연구로 끝내지 않고 결과물을 현업에 넘기는 책임까지 한 조직이 진다. 운영 모델을 고민하는 조직이라면 참고할 만한 대목이다.

    거버넌스는 무엇은 해도 되고 무엇은 안 되는지, 누가 승인하는지, 문제가 생기면 누가 책임지는지를 정하는 규칙이다. 사용 사례를 위험도별로 나누는 일이 여기에 속한다. 결정 근거를 기록으로 남기는 일, 사람이 개입해야 할 지점을 미리 정해 두는 일도 마찬가지다.

    요소 답해야 할 질문 비어 있을 때 흔한 증상
    데이터 필요한 데이터를 누가, 어떤 정의와 권한으로 쓰는가 부서마다 같은 지표 값이 달라 AI 결과를 믿지 못함
    엔지니어링 시범 모델을 운영 서비스로 옮기고 계속 감시할 수 있는가 데모는 되는데 배포·업데이트가 매번 수작업
    플랫폼 공용 도구를 재사용하는가, 팀마다 새로 만드는가 비슷한 챗봇·파이프라인이 부서마다 중복
    운영 모델 기획·개발·운영·책임 역할이 누구에게 있는가 만든 팀이 빠지면 유지보수할 사람이 없음
    거버넌스 위험을 어떤 기준으로 나누고 누가 승인하는가 출시 직전 리스크 검토에서 프로젝트가 멈춤

    표의 증상 칸은 원문에 나온 사례가 아니다. 각 요소가 비었을 때 흔히 나타나는 모습을 설명하려고 덧붙인 내용이다.

    표에서 가장 심각한 건 거버넌스 줄이다. 다른 칸의 증상은 비용이 늘거나, 결과를 믿기 어렵거나, 유지보수가 끊기는 문제다. 거버넌스가 빈 조직은 출시 직전에 아예 멈춰 선다. 다음 절에서 거버넌스를 따로 다루는 이유다.

    규제 업종의 거버넌스, 속도를 늦추는 절차에서 다시 쓰는 틀로

    이 세션은 ‘고도로 규제된 환경’을 전제로 한다. 연사가 금융 회사 소속이니 자연스러운 설정이다. 금융은 고객 자산과 바로 이어지는 판단이 많은 업종이다. 그 판단을 설명하고 기록할 의무도 있다. AI를 들이는 방식이 다른 산업과 같을 수 없다.

    거버넌스를 속도를 늦추는 절차로만 보는 시각이 흔하다. 프로젝트마다 위험 검토를 처음부터 다시 받는다면 실제로 느려진다. 반대로 거버넌스를 기반의 일부로 미리 깔아 두는 방식도 있다. 위험도별 기준, 미리 승인된 사용 패턴, 공용 플랫폼에 넣어 둔 기록·권한 기능이 그 예다. 이렇게 하면 두 번째 프로젝트부터는 이미 통과한 틀을 다시 쓸 수 있다. 원문은 ‘책임 있고 믿을 수 있는 구현’을 투자자에게 돌아갈 ‘지속적인 가치’와 연결했다. 여기까지가 원문 내용이다. 그 연결이 이런 구조에서 나온다고 보는 건 이 글의 해석이다. 신뢰가 쌓여야 더 중요한 업무를 AI에 맡길 수 있고, 그래야 확장이 일회성 성과로 끝나지 않는다.

    연사의 이력도 이 관점과 맞닿아 있다. 징 왕은 중국과학기술대에서 물리학 학사를, 펜실베이니아대에서 박사 학위와 와튼스쿨 MBA를 받았다. 보스턴컨설팅그룹(BCG)에서는 프린시펄로 일했다. 뱅가드에서는 금융 서비스, 워크플레이스 솔루션, 인터내셔널, 코퍼레이트 서비스 부문을 두루 이끌었다. 미국 증권업 자격인 Series 7·24·65도 갖고 있다. AI 조직을 이끄는 사람이 사업 부문 경험과 증권업 규제 자격을 모두 갖췄다는 점은 눈여겨볼 만하다. 이 글은 이를 규제 산업의 AI 확장이 기술만의 과제가 아니라는 신호로 읽는다.

    에이전트형 AI가 틀리면 남는 건 잘못된 행동이다

    원문은 확장할 새 역량으로 에이전트형 시스템(agentic systems)을 직접 꼽는다. 에이전트형 AI는 질문에 답하는 데서 멈추지 않는다. 목표를 받으면 스스로 단계를 계획하고, 다른 시스템을 호출해 실제 작업까지 해낸다. 답변형 AI가 틀리면 잘못된 문장이 남는다. 에이전트가 틀리면 잘못된 행동이 남는다. 이것이 결정적인 차이다.

    에이전트 단계에서는 다섯 요소가 더 구체적인 질문으로 바뀐다.

    • 데이터·권한: 에이전트가 읽고 쓸 수 있는 데이터와 시스템이 업무에 필요한 최소한으로 제한돼 있는가?
    • 엔지니어링: 에이전트가 단계마다 한 행동이 로그로 남고, 이상이 생기면 멈추거나 되돌릴 수 있는가?
    • 플랫폼: 에이전트가 호출하는 도구를 부서마다 따로 붙이지 않고 공용으로 관리하는가?
    • 운영 모델: 에이전트가 처리한 업무 결과를 책임질 사람이 정해져 있는가?
    • 거버넌스: 어떤 행동 앞에서 사람 승인을 받아야 하는지 기준이 있는가?

    이 질문에 답하지 못한 채 에이전트부터 들이는 조직도 있을 것이다. 이 글은 그런 경우 시범 운영은 화려해도 실제 업무로 넓히는 단계에서 다시 멈출 가능성이 크다고 본다. 질문 하나하나가 앞서 본 다섯 요소에서 나왔다. 답변형 AI에서는 미뤄 둘 수 있던 빈칸이 에이전트 단계에서는 바로 사고로 이어질 수 있다. 기반이 먼저라는 원문의 메시지가 에이전트형 AI에서 특히 무겁게 다가오는 이유다.

    국내 은행·증권 앱과 AI 도입 제안서에 대입해 보면

    뱅가드는 해외 투자 회사다. 하지만 한국에서도 금융은 대표적인 규제 산업이어서 비슷한 고민이 생길 수 있다. 아래는 원문에 직접 나온 내용이 아니다. 같은 구조를 국내 상황에 대입해 본 해석이다.

    • 이용자 입장(추측): 은행·증권 앱의 AI 상담이나 투자 도우미는 다른 업종보다 늦게 나오거나 좁은 기능으로 시작하는 경우가 있다. 규제 환경에서 기반과 검증을 먼저 갖추느라 생긴 차이라면 자연스러운 흐름일 수 있다. 기능이 적다는 것만으로 기술력이 낮다고 단정하기는 어렵다.
    • 실무자 입장: AI 도입 제안서를 모델 성능 비교로만 채우지 않는 편이 낫다. 데이터 접근 방식, 운영 주체, 승인 절차까지 다섯 요소별 계획을 함께 담으면 리스크·컴플라이언스 부서를 설득하기가 한결 쉬워 보인다. 확장을 막는 병목이 모델 밖에 있다는 원문의 진단을 실무 문서에 그대로 옮긴 셈이다.
    • 조직 설계 측면(추측): 뱅가드는 AI 조직에 행동과학을 함께 뒀다. 고객 경험을 다루는 AI라면 기술 인력만으로 팀을 꾸릴 필요는 없다. 고객 행동을 이해하는 인력을 같은 팀에 두는 방식도 검토해 볼 만하다.

    국내 규제 기준은 업권과 서비스마다 다르다. 실제로 어디까지 적용되는지는 각 조직의 컴플라이언스 부서와 확인하는 게 안전하다.

    확인된 것과 아직 불확실한 것

    확인된 것

    • EmTech Future 컨퍼런스 세션은 고도로 규제된 환경에서 확장 가능한 AI의 기반을 만드는 방법을 다룬다.
    • 세션이 꼽은 기반 요소는 데이터, 엔지니어링, 플랫폼, 운영 모델, 거버넌스다. 이 다섯 가지가 하나로 맞물려 작동해야 한다는 게 요지다.
    • 책임 있고 믿을 수 있는 구현이 에이전트형 시스템을 비롯한 새 역량을 투자자를 위한 지속적 가치로 바꾼다는 관점을 담고 있다.
    • 연사 징 왕은 뱅가드 CAI를 이끈다. 이 조직은 AI·머신러닝·생성형 AI·행동과학 역량을 맡아 전사 차원의 혁신·연구·딜리버리를 추진한다.

    아직 불확실한 것

    • 뱅가드가 실제로 어떤 데이터 플랫폼, 모델, 개발 도구를 쓰는지는 세션 소개글에 나오지 않는다.
    • 에이전트형 시스템을 어떤 업무에 어느 정도의 자율성으로 적용했는지는 확인되지 않는다.
    • 거버넌스 절차가 구체적으로 어떻게 짜여 있는지, 기반을 갖춘 뒤 어떤 성과가 났는지는 소개글로는 알 수 없다.
    • 규제 체계가 다른 국내 금융사에도 이 방식이 그대로 통할지는 판단하기 어렵다.

    다섯 문항으로 AI 기반의 가장 약한 고리 찾기

    다섯 요소를 한꺼번에 완벽하게 갖추려 하면 오히려 아무것도 시작하지 못하기 쉽다. 현실적인 순서는 따로 있다. 지금 상태를 솔직하게 진단하고 가장 약한 고리부터 보강하는 것이다.

    1. 데이터: 다음 AI 프로젝트에 필요한 데이터를 정해진 승인만 거치면 바로 꺼내 쓸 수 있는가?
    2. 엔지니어링: 운영 중인 AI 기능의 성능이 떨어지면 누군가 알아챌 장치가 있는가?
    3. 플랫폼: 새 프로젝트를 시작할 때 다시 쓸 수 있는 공용 도구가 있는가?
    4. 운영 모델: AI 기능 하나를 골라 ‘이건 누구 책임인가?’라고 물으면 바로 답이 나오는가?
    5. 거버넌스: 새 AI 사용 사례가 생겼을 때 위험도를 판단할 기준표가 있는가?

    문항마다 ‘있다 / 일부 있다 / 없다’만 표시해도 어디가 비었는지 꽤 선명하게 보인다. ‘없다’가 나온 항목을 별도의 대형 과제로 떼어 낼 필요는 없다. 다음 프로젝트에서 함께 풀 과제로 묶는 편이 현실적이다. 새 사용 사례 하나를 진행하면서 만든 권한 관리나 평가 도구를 공용 플랫폼에 남기는 식이다. 규제가 강한 업종이라면 거버넌스 문항부터 채워야 이후 속도를 지킬 수 있다고 본다. 확장 가능한 AI인지는 화려한 첫 데모에서 드러나지 않는다. 두 번째, 세 번째 프로젝트가 첫 번째보다 빨라지는지를 봐야 한다. 방향을 가늠하는 잣대로는 이쪽이 더 정확하다.

    출처: MIT Tech Review AI

  • LLM 서빙 하네스, 모델보다 병목 측정이 먼저다

    LLM 서빙 하네스, 모델보다 병목 측정이 먼저다

    3줄 요약

    • 서빙 하네스는 모델을 감싸는 아키텍처·메모리 관리·스케줄링·최적화 결정의 묶음이다. 같은 모델을 써도 이 설계에 따라 프로덕션의 속도와 비용이 달라진다.
    • 추론 중에 모델 가중치는 크기가 고정이지만 KV 캐시는 동시 요청 수와 컨텍스트 길이에 따라 커진다. 그래서 연산 여력이 남아 있어도 GPU 메모리가 먼저 바닥날 수 있다.
    • 최적화는 기법을 모으는 일이 아니다. 측정하고, 병목을 찾고, 해결하고, 다시 측정하는 일을 반복하는 것이다. 모델 교체가 플랫폼 재구축이 아니라 평가와 설정 변경으로 끝나도록 설계하는 것이 목표다.

    GPU 연산 여력은 아직 남아 있다. 그런데 동시 요청이 조금 늘자 응답이 밀리기 시작한다. LLM을 직접 띄워 운영하는 팀이라면 충분히 마주칠 수 있는 장면이다.

    이때 먼저 떠오르는 해법은 두 가지다. 모델을 바꾸거나, GPU를 더 사거나. 원인이 모델 바깥에 있다면 둘 다 돈만 더 쓰는 선택이 될 수 있다.

    EXL이 MIT Technology Review에 실은 기고문은 이 ‘모델 바깥’에 서빙 하네스(serving harness)라는 이름을 붙였다. 매체 편집국이 아니라 EXL이 제작한 콘텐츠다. 주장은 한 줄로 줄어든다. 엔터프라이즈 AI의 다음 경쟁력은 어떤 모델을 고르느냐보다 그 주변에 무엇을 짓느냐에 달렸다는 것.

    솔루션 기업이 쓴 글이니 걸러 들을 대목은 있다. 다만 뼈대가 되는 설명, 즉 가중치는 고정이고 KV 캐시는 요청에 따라 불어난다는 대목은 추론 시스템의 일반적인 동작 원리와 맞아떨어진다. 개념을 정리하는 용도로는 충분히 쓸 만하다. 아래에서 서빙 하네스의 구성, 병목이 생기는 지점, 그 병목을 푸는 순서를 차례로 본다.

    서빙 하네스, 가중치 파일 바깥의 네 가지 결정

    AI 이야기의 중심엔 늘 모델 성능이 있었다. 더 큰 모델, 더 나은 추론 능력, 더 긴 컨텍스트 윈도, 더 높은 벤치마크 점수.

    실험 단계를 지나 프로덕션에 들어서면 질문 자체가 바뀐다.

    • 실험 단계: ‘이 모델이 뭘 할 수 있지?’
    • 프로덕션: ‘이 지능을 안정적으로, 경제적으로, 대규모로 전달할 수 있나?’

    서빙 하네스는 두 번째 질문에 답하는 시스템이다. 모델 가중치 파일 자체를 말하는 게 아니다. 모델을 둘러싸고 요청을 받아 처리하고 응답을 돌려주는 엔지니어링 전체를 가리킨다. 쪼개 보면 네 덩어리.

    • 아키텍처: 요청이 어떤 경로로 들어와 어느 서버와 GPU에서 처리되는지, 모델을 몇 벌 띄워 어떻게 배치하는지
    • 메모리 관리: 한정된 GPU 메모리를 모델 가중치와 요청별 상태(뒤에서 볼 KV 캐시)에 어떻게 나눠 쓰는지
    • 스케줄링: 동시에 들어온 요청을 어떤 순서와 묶음으로 처리할지
    • 최적화 결정: 양자화, 추측 디코딩, 어텐션 최적화 같은 기법 중 무엇을 언제 적용할지

    하네스(harness)는 원래 말에 씌우는 마구, 혹은 전선을 묶은 배선 뭉치를 뜻한다. 힘을 내는 건 말이지만, 그 힘으로 마차를 끌게 만드는 건 마구다. 이름부터가 꽤 정확한 비유다.

    기고문의 논리는 이렇게 이어진다. 기업들이 점점 같은 모델을 쓸 수 있게 되면서 모델만으로는 차별화가 어려워진다. 차이는 그 모델을 얼마나 효율적으로 실제 기능으로 바꾸느냐에서 난다.

    대화형이냐 배치형이냐가 서빙 구조를 가른다

    전제부터 짚자. 누구에게나 ‘최고’인 모델이나 AI 아키텍처는 없다. 풀려는 업무 문제에 맞는 해법이 있을 뿐이다. 워크로드가 제약을 정하고, 제약이 서빙 구조를 정한다.

    빠른 응답이 생명인 고객 응대 어시스턴트와 밤새 돌아가도 괜찮은 문서 처리 파이프라인. 둘을 나란히 놓으면 요구사항이 근본부터 다르다.

    • 대화형 서비스: 사용자가 첫 글자를 기다리는 시간이 체감 품질을 좌우한다. 지연을 짧게 유지하는 게 1순위.
    • 배치형 파이프라인: 개별 응답 속도보다 전체 처리량과 건당 비용이 중요하다.

    사내 지식 검색 앱과 대량 트래픽을 받는 고객 서비스 플랫폼도 마찬가지다. 같은 기반 모델을 써도 서빙 구조는 완전히 달라질 수 있다.

    문제는 PoC 단계에선 이 차이가 잘 안 보인다는 점. 사용자가 몇 명뿐이면 모델 정확도가 논의를 독차지한다. 지연, 동시성, 메모리 압박, GPU 활용률, 인프라 비용, 예측하기 어려운 트래픽 같은 제약은 뒤로 밀리기 쉽다. 그리고 프로덕션에 올라가는 순간 한꺼번에 드러난다.

    구분 PoC 단계 프로덕션 단계
    핵심 질문 모델이 무엇을 할 수 있나 그 지능을 안정적·경제적·대규모로 전달할 수 있나
    주로 보는 지표 모델 정확도 지연, 동시성, GPU 활용률, 인프라 비용
    사용자와 트래픽 소수 사용자 많은 사용자, 예측하기 어려운 트래픽
    메모리 압박 사용자가 적어 무시하기 쉬움 동시 요청이 늘면서 병목으로 드러남
    모델 선택 기준 가장 좋은 답을 내는 모델 워크로드에 맞는 성능을 맞는 비용으로 내는 모델

    기고문에 나오는 비유 하나가 이 표의 마지막 줄을 잘 요약한다. 모든 워크로드에 페라리가 필요한 건 아니라는 것.

    답변이 조금 더 나은 모델이라도 추론 비용을 두 배로 늘리거나 애플리케이션의 지연 요구를 맞추지 못한다면, 프로덕션에서는 더 나은 선택이 아닐 수 있다. 업무에 필요한 만큼의 성능을 내면서 쓰지도 않을 능력에는 돈을 내지 않는 모델. 이쪽이 더 영리한 결정일 때가 많다.

    이렇게 보면 서빙 구조는 엔지니어링 문제이면서 동시에 투자 결정이다. 정해야 할 것은 세 가지다.

    • 어디에 연산 자원을 쓸지
    • 어디를 최적화할지
    • 어느 지점부터는 모델 성능을 더 올려도 비용만큼의 가치가 없는지

    연산은 남는데 메모리가 먼저 바닥나는 이유, KV 캐시

    서빙 하네스에서 가장 먼저 이해해야 할 자원은 GPU 메모리다.

    언어 모델은 토큰을 하나씩 생성한다. 새 토큰을 만들 때마다 앞선 모든 토큰을 참고하는 어텐션 연산을 거친다. 이때 앞 토큰들의 키(key)와 값(value)을 매번 다시 계산하면 낭비가 크다. 그래서 한 번 계산한 결과를 메모리에 저장해 두고 재사용하는데, 이 저장 공간이 KV 캐시다.

    GPU 메모리를 차지하는 건 크게 두 덩어리다. 둘의 성격이 정반대라는 점이 이 글 전체의 열쇠.

    구분 모델 가중치 KV 캐시
    크기 추론 중에는 변하지 않고 고정 컨텍스트가 길수록 커짐
    누가 쓰나 한 번 올려 두면 모든 요청이 함께 씀 요청마다 따로 생김
    무엇이 쌓이나 추론 중에는 늘지 않음 입력 토큰과 이미 생성한 토큰이 모두 쌓임
    동시 요청이 늘면 그대로 전체 크기도 그만큼 늘어남

    동시 요청이 늘면 KV 캐시 전체가 불어난다. 그러다 어느 순간 연산 장치엔 여유가 있는데 쓸 수 있는 GPU 메모리가 먼저 바닥난다. 이때 서버가 할 수 있는 건 두 가지뿐이다. 새 요청을 대기열에 세우거나, 처리 중이던 요청을 밀어내거나. 사용자 쪽에선 그저 ‘느려졌다’로 보인다.

    이 병목을 모른 채 GPU만 늘리면 비효율적인 시스템을 더 비싸게 만들 뿐일 수 있다. 서두에서 GPU 추가 구매가 답이 아닐 수 있다고 한 근거가 바로 이 대목이다.

    운영 지표도 GPU 사용률 하나로는 부족하다. 함께 봐야 할 숫자는 이렇다.

    • GPU 메모리 중 KV 캐시가 차지하는 비중
    • 동시에 처리 중인 요청 수
    • 대기열 길이
    • 요청별 컨텍스트 길이 분포

    긴 컨텍스트 윈도도 같은 맥락에서 봐야 한다. 스펙표에선 매력적이지만, 긴 컨텍스트를 쓰는 요청이 많아질수록 같은 메모리로 동시에 받을 수 있는 요청 수는 줄어든다. 최대 컨텍스트를 지원한다는 것과 그걸 다 써도 괜찮다는 것은 별개의 이야기다. 이 지점을 겨냥한 선택지는 다음과 같다.

    • 워크로드별로 최대 컨텍스트 길이 제한하기
    • 프롬프트에 매번 붙는 불필요한 내용 줄이기
    • KV 캐시를 최대 길이만큼 미리 잡아 두지 않고 필요한 만큼 나눠 할당하는 서빙 엔진 고르기

    양자화·추측 디코딩은 병목을 확인한 다음 차례

    프로덕션에선 따로 떨어져 보이던 결정들이 서로 맞물려 돌아간다. 연결 고리를 따라가면 이렇다.

    서빙 구조 → 메모리 활용 → 동시성 → 배칭·스케줄링 → GPU 활용률과 지연

    서빙 구조가 메모리 쓰는 방식을 정한다. 남은 메모리가 동시에 받을 수 있는 요청 수를 정하고, 그 수가 배칭과 스케줄링 방식을 제한한다. 최종 결과는 GPU 활용률과 응답 지연으로 나타난다. 양자화, 추측 디코딩, 어텐션 최적화 같은 기법은 이 사슬이 정리된 뒤에야 제값을 한다. 기법마다 겨냥하는 지점도, 치르는 대가도 다르다.

    기법 방식과 겨냥하는 지점 조건·주의점
    양자화 가중치를 더 낮은 정밀도로 표현해 메모리 사용량과 메모리 대역폭 부담을 줄인다. 아낀 메모리는 KV 캐시에 돌릴 수 있다. 답변 품질이 떨어지지 않는지 평가가 따라와야 한다.
    추측 디코딩 작은 초안 모델이 여러 토큰을 먼저 제안하고 큰 모델이 한 번에 검증한다. 초점은 토큰 생성 지연 단축. 초안 모델도 메모리를 차지하고, 부하 상황에 따라 효과가 달라진다.
    어텐션 최적화 어텐션 연산의 메모리 접근 방식을 개선해 속도와 메모리 효율을 끌어올린다. 긴 컨텍스트에서 특히 효과가 크다.

    함정은 표의 가운데 줄에 있다. 시스템을 막고 있는 원인이 KV 캐시 메모리 부족인데 추측 디코딩부터 붙이면, 초안 모델이 메모리를 더 차지해 동시 처리량이 오히려 줄 수 있다. 지연을 줄이려고 넣은 기법이 메모리 병목을 더 조이는 꼴이다.

    기고문은 이를 두고 최적화 기법을 포켓몬 카드처럼 다 모으려 하지 말라고 썼다. 가벼운 비유지만, 위 사례를 보면 과장은 아니다. 목표는 기법 수집이 아니다. 애플리케이션의 업무 요구사항을 지키면서 가장 영향이 큰 제약을 걷어내는 것이다.

    순서는 단순하다.

    • 측정: 최적화하기 전에 먼저 잰다.
    • 병목 찾기: 가장 큰 제약을 골라낸다.
    • 해결: 그 제약을 푼다.
    • 재측정: 결과를 다시 재고, 새 병목이 생겼는지 확인한다.
    • 반복: 위 과정을 다시 돌린다.

    의사결정 질문도 바뀌어야 한다. ‘우리 조직이 어떤 AI 기능을 배포할 수 있나’가 아니다. ‘검증된 기능이 지속 가능한 비즈니스 가치가 되지 못하게 막는 제약이 무엇인가’를 물어야 투자 방향이 잡힌다.

    API만 쓰는 팀은 호출 구조, 자체 서빙 팀은 KV 캐시가 숙제

    한국에서 LLM 서비스를 만드는 팀 입장으로 옮겨 보자. 기고문 밖에서 추론한 부분이 섞여 있어서, 추정인 대목은 따로 표시했다.

    상용 API만 호출하는 팀. GPU 메모리나 배칭 같은 서빙 하네스의 핵심부는 API 제공사가 맡는다. 그렇다고 하네스와 무관한 건 아니다. 아래 항목은 여전히 우리 몫이고, 요청당 비용과 지연에 직접 영향을 준다.

    • 프롬프트 길이 관리
    • 워크로드별 모델 라우팅(간단한 요청은 가벼운 모델로 보내기)
    • 응답 캐싱
    • 모델을 갈아 끼울 수 있는 호출 구조

    사내 GPU에 공개 모델을 직접 띄우는 팀. 앞에서 본 KV 캐시, 동시성, 스케줄링 이야기가 그대로 적용된다. 금융·공공처럼 망분리 같은 보안 요건이 있는 환경은 외부 API보다 자체 서빙을 검토할 이유가 생기기 쉽다. 이런 조직일수록 모델 선정만큼 서빙 구조 검토에도 시간을 써야 할 것으로 보인다(추정).

    한국어 서비스라면 토큰 효율도 따져 볼 만하다(추정). 토크나이저에 따라 같은 뜻의 문장이 영어보다 더 많은 토큰으로 쪼개지는 경우가 있다. 토큰이 늘면 KV 캐시 크기도, API 과금도 함께 늘어난다. 모델마다 한국어를 처리하는 방식이 다르니, 후보 모델들에 실제 서비스 문장을 넣고 토큰 수를 직접 세어 보는 게 가장 확실하다.

    국내 팀도 대개 해외 팀과 같은 모델 후보군에서 고른다. 모델 선택만으로 경쟁사와 차이를 만들기는 점점 어려워질 가능성이 크다(추정). 기고문의 주장을 국내 상황에 옮기면 이런 해석이 나온다. 같은 모델로 더 싸고, 더 빠르고, 더 안정적으로 서비스하는 팀이 앞선다.

    확인된 것과 아직 불확실한 것

    확인된 것

    • 출발점이 된 기고문은 EXL이 제작한 콘텐츠로, 게재 매체의 편집국이 쓴 기사가 아니다.
    • 추론 중에 모델 가중치는 고정되어 있고, KV 캐시는 활성 요청 수와 컨텍스트 길이에 따라 커진다.
    • 동시성이 높아지면 연산 여력이 남아 있어도 쓸 수 있는 GPU 메모리가 먼저 부족해질 수 있다.
    • 서빙 구조, 메모리, 동시성, 배칭·스케줄링, GPU 활용률, 지연은 서로 연쇄적으로 영향을 준다.
    • EXL은 ‘Engineering the Harness’ 시리즈에서 서빙 구조, 메모리 관리, 스케줄링, 추론 최적화를 더 깊이 다룬다고 밝혔다.

    아직 불확실한 것

    • 하네스 설계를 바꾸면 비용이나 지연이 얼마나 줄어드는지에 대해 기고문은 구체적인 수치를 내놓지 않았다.
    • 어떤 최적화 기법이 어떤 워크로드에서 가장 효과적인지는 일반화된 답이 없고, 실측으로만 확인할 수 있다.
    • 모델 교체를 평가와 설정 변경 수준으로 만드는 게 실제로 어디까지 가능할지는 팀마다 다를 것으로 보인다. 모델마다 프롬프트 형식, 토크나이저, 컨텍스트 길이가 다르기 때문이다.
    • 하네스가 모델 선택보다 중요해진다는 주장에는 솔루션 기업의 시각이 담겨 있고, 독립적으로 검증된 결론은 아니다.

    모델 교체를 설정 변경으로 끝내는 다섯 가지 장치

    서빙 하네스에 투자할 가장 큰 이유는 선두 모델이 계속 바뀐다는 데 있다. 모델은 좋아지고, 하드웨어는 발전하고, 새 최적화 기법도 꾸준히 나온다. 기술이 바뀔 때마다 AI 플랫폼을 다시 지어야 한다면 그 비용은 매번 되풀이된다. 주변 구조가 이런 변화를 쉽게 흡수할 수 있어야 하는 이유다.

    기고문이 내놓는 기준은 세 가지다.

    • 워크로드 요구사항
    • 명확한 서비스 수준 목표(SLO)
    • 측정 가능한 프로덕션 경제성

    이 셋을 기준으로 시스템을 짜 두면 새 모델이나 인프라가 나왔을 때 업무에 실제로 필요한 것과 대조해 평가할 수 있다. 실무 체크리스트로 바꾸면 다섯 항목이 나온다.

    • 워크로드 정의서: 대화형인지 배치형인지, 허용 지연, 예상 동시 요청 수, 컨텍스트 길이 분포를 문서로 남긴다.
    • SLO 명문화: 첫 토큰까지 걸리는 시간, 전체 응답 시간, 꼬리 지연(가장 느린 일부 요청의 지연), 가용성, 요청당 비용 상한을 숫자로 정한다.
    • 모델 호출 추상화: 애플리케이션 코드가 특정 모델의 API 형식에 직접 묶이지 않도록 인터페이스를 한 겹 두고, 모델 이름과 생성 파라미터는 설정 파일로 뺀다.
    • 자체 평가 세트: 공개 벤치마크 대신 우리 업무 데이터로 만든 평가 세트를 유지하고, 새 모델을 품질·지연·비용 세 축으로 기존 모델과 비교한다.
    • 관측 지표: GPU 메모리 중 KV 캐시 비중, 동시 요청 수, 대기열 길이, 처리량, 요청당 비용을 대시보드에서 상시 확인한다.

    다섯 가지가 갖춰져 있으면 모델 교체는 아키텍처를 갈아엎는 일이 아니라 평가하고 설정을 바꾸는 일이 된다. 다만 프롬프트 형식과 토크나이저가 모델마다 다르니, 어디까지 설정 변경만으로 끝날지는 팀마다 차이가 날 것이다. 체크리스트에 자체 평가 세트가 들어간 것도 그 차이를 숫자로 확인하기 위해서다.

    기고문의 결론은 이렇다. 모델은 지능을 제공하고, 그 지능을 안정적이고 경제적인 대규모 결과물로 바꿀 수 있는지는 하네스가 결정한다. 실천으로 옮기면 한 가지로 모인다. 새 모델 소식이 나올 때마다 흔들리지 않으려면, 모델을 고르기 전에 우리 워크로드와 병목부터 숫자로 적어 둘 것.

    출처: MIT Tech Review AI

  • 핵융합·상온 초전도체·AI 킬 스위치, 병목이 다르다

    핵융합·상온 초전도체·AI 킬 스위치, 병목이 다르다

    3줄 요약

    • ‘불가능한 기술’은 꿈에 가까운 것, 연구자들이 끝내 붙들고 있는 것, 기술이 망가뜨린 것을 고치는 것, ‘비현실’의 비유로 쓰이는 것으로 나눠 보면 뉴스 읽기가 훨씬 쉬워진다.
    • 핵융합·상온 초전도체·AI 킬 스위치는 늘 한데 묶여 불리지만 막힌 지점이 각각 공학·발견·제도로 다르다.
    • 진전 소식을 보면 ‘어느 층에서 막혔나, 누가 재현했나, 병목이 몇 개인가, 일정과 예산은 누가 말했나’ 네 가지부터 확인하자.

    MIT 테크놀로지 리뷰에서 인쇄판 편집을 맡은 한 저널리스트는 면접 단골 질문인 “가장 큰 약점이 뭔가요?”에 내놓을 답을 미리 정해 두었다. “스스로에게 너무 자주 안 된다고 말하는 것.”

    아이디어가 떠오르는 순간 이 편집자의 머릿속에서는 실현 가능성 평가부터 돌아간다. 할 일 목록을 뽑고, 일정을 그리고, 예산 항목을 하나씩 더한다. 그러다 보면 간트 차트 비슷한 것이 머릿속에 완성된다. 편집자 스스로 밝힌 습관이다. 20년 넘게 과학·기술 기자로 일하는 동안 야망과 현실의 줄다리기가 멈춘 적은 거의 없었다고 한다.

    그런 편집자가 이끈 호가 하필 ‘불가능한 아이디어’ 특집이다. 달에서 살기, 뇌 업로드, 인공 혈액, 동물의 말 해독. 이런 아이디어들이 지금 어디까지 왔는지 일부러 점검하는 기사들로 지면을 채웠다. 이 글은 그 기사들을 옮기지 않는다. ‘꿈의 기술’ 뉴스를 만났을 때 그것이 현실에 얼마나 가까운지 독자가 직접 가늠할 기준을 세우는 것이 목표다. 무리해 보이는 요구사항을 받은 개발자가 하는 일과 크게 다르지 않은 작업이다.

    편집자 글 속 ‘불가능’은 네 종류로 갈린다

    편집자 글에 나오는 기술들이 모두 같은 뜻의 ‘불가능’은 아니다. 상상하는 재미로 언급되는 것이 있고, 과학자들이 놓지 않는 도전으로 언급되는 것이 있다. 기술이 만든 문제를 되돌리는 숙제로 등장하는 것도 있다. 원문에서 쓰인 맥락을 기준으로 묶으면 다음과 같다.

    묶음 원문에 나온 예 원문에서 쓰인 맥락
    꿈꾸는 재미 달에서 살기, 뇌 업로드 상상하는 것 자체가 즐거운 아이디어
    포기하지 않는 도전 인공 혈액 만들기, 동물의 말 해독 과학자와 엔지니어가 가장 대담한 시도조차 놓지 않는 사례
    망가뜨린 것 고치기 영구 화학물질, 교통사고 사망, 잠재적으로 위험한 사용자 행동을 부추기는 AI 기술이 상황을 악화시켰을 때 피해를 평가하고 바로잡아야 하는 영역
    ‘비현실’의 비유 AI 킬 스위치, 실용적인 핵융합, 상온 초전도체 기후위기 대응 개인 행동이 헛수고라는 말과 나란히 놓인 예

    분류가 정해지면 뉴스 하나를 읽을 때 기대치를 어디에 둘지도 정해진다. 첫 번째 묶음은 당장 실현될지보다 방향을 상상하게 해 주는 이야기다. 진척 속도로 점수를 매길 대상이 아니다. 두 번째 묶음에서는 작은 진전 하나하나가 의미를 갖는다. 세 번째 묶음의 평가 기준은 ‘얼마나 멋진가’가 아니라 ‘피해를 얼마나 줄였나’. 네 번째 묶음은 사정이 반대다. 비유로 쓰일 만큼 어렵다는 사실이 널리 알려진 대상이어서, 진전했다는 주장이 나오면 오히려 더 깐깐하게 따져야 한다. 편집자가 하필 이 셋을 ‘비현실’의 예로 골랐다는 것 자체가 이들의 어려움이 얼마나 상식처럼 굳어 있는지 보여 준다.

    상온 초전도체는 발견, 핵융합은 공학, 킬 스위치는 제도가 벽

    세 기술은 ‘비현실적인 것’의 대표로 한 문장에 묶여 나온다. 하지만 왜 어려운지 뜯어보면 막힌 층이 전혀 다르다. 이 차이를 알고 있으면 ‘돌파구 마련’ 같은 헤드라인이 어느 층의 이야기인지 바로 구분된다.

    상온 초전도체는 ‘찾는’ 문제다. 초전도는 물질이 전기 저항 없이 전류를 흘리는 상태를 말한다. 지금까지 알려진 초전도체는 아주 낮은 온도로 식히거나 엄청난 압력을 걸어야 이 상태에 들어간다. 냉각·가압 장비가 크고 비싸니 쓰임새도 좁을 수밖에 없다. 평범한 온도에서 초전도가 되는 물질이 나온다면 송전, 전자기기, 의료 장비까지 판이 바뀔 수 있다. 꿈의 물질이라는 별명이 붙은 이유다. 걸림돌은 그런 물질이 어떤 구조여야 하는지, 애초에 존재하기는 하는지부터가 열린 질문이라는 점이다. 발견했다는 주장이 나왔을 때 확인할 것은 사실상 하나. 다른 연구진이 같은 결과를 재현했는가.

    핵융합은 ‘되긴 하는데 쓸 만하게 만드는’ 문제다. 가벼운 원자핵이 합쳐져 더 무거운 원자핵이 될 때 나오는 에너지를 쓰는 방식으로, 태양이 빛나는 원리와 같다. 실험 장치에서 핵융합 반응을 일으키는 것 자체는 이미 가능한 영역에 들어와 있다. 원문이 굳이 ‘실용적인(practical)’ 핵융합이라고 쓴 것도 그래서다. 남은 숙제는 넣은 에너지보다 많은 에너지를, 오래, 안정적으로, 감당할 수 있는 비용으로 뽑아내 발전소처럼 돌리는 일이다. 초고온 플라즈마를 가두는 장치, 그 환경을 견디는 재료, 전력망에 연결하는 설비. 공학 문제가 줄줄이 엮여 있다.

    AI 킬 스위치는 ‘멈추는 방법과 누르는 사람’을 정하는 문제다. 위험한 상황에서 AI 시스템을 즉시 멈추는 장치나 절차를 가리킨다. 컴퓨터 한 대라면 전원 플러그를 뽑으면 끝난다. 대규모 AI 서비스는 다르다. 여러 데이터센터에 나뉘어 돌아가고, 수많은 앱과 업무 시스템에 연결돼 있다. 모델 파일이 공개돼 여러 곳에 복사돼 있다면 한 곳의 스위치로는 다 멈출 수도 없다. 어떤 조건에서 눌러야 하는지, 누가 누를 권한을 갖는지도 정해야 한다. 이 부분은 코드가 아니라 규칙과 합의의 영역이라 기술만으로는 풀리지 않는다.

    병목만 뽑아 보면 상온 초전도체는 발견, 핵융합은 공학과 경제성, AI 킬 스위치는 시스템 설계와 제도다. 똑같이 ‘불가능’ 딱지가 붙어 있어도 진전 소식을 해석하는 방식은 완전히 달라야 한다. 상온 초전도체 뉴스라면 재현 여부를, 핵융합 뉴스라면 엮여 있는 공학 과제 중 어느 것이 움직였는지를, 킬 스위치 논의라면 그것이 기술 장치 이야기인지 권한 규칙 이야기인지를 먼저 봐야 한다.

    인공 혈액부터 영구 화학물질까지, 축적으로 버티는 연구들

    두 번째와 세 번째 묶음은 결이 다르다. 화려한 돌파구 한 번보다 끈질긴 축적이 더 중요한 분야들이다.

    인공 혈액은 헌혈에 기대지 않고 피가 하는 일 일부, 특히 산소 운반을 대신할 물질을 만드는 연구다. 혈액형을 맞출 필요가 없고 오래 보관할 수 있다면 응급 현장이나 혈액 공급이 어려운 지역에서 쓸모가 크다. 문제는 피가 산소만 나르지 않는다는 점이다. 출혈을 멈추고 면역에도 관여하는 등 여러 일을 동시에 한다. 몸속에 직접 넣는 물질이니 안전성 검증 문턱도 높다. 이 분야의 진전이 ‘피를 통째로 대체했다’보다 ‘특정 기능을 특정 상황에서 대신할 수 있게 됐다’는 형태로 나오는 것이 자연스러운 이유다. 거꾸로 피 전체를 대체했다는 식의 제목을 보면, 어느 기능을 어떤 상황에서 대신했는지부터 확인하는 편이 안전하다.

    동물의 말 해독은 동물의 소리나 몸짓 데이터를 대량으로 모은 뒤 머신러닝으로 반복 패턴을 찾는 방식으로 접근하는 경우가 많다. 패턴 찾기는 컴퓨터가 잘하는 일이다. 진짜 벽은 그 패턴이 ‘의미’인지 확인할 정답지가 없다는 데 있다. 사람 언어를 번역할 때는 두 언어를 모두 아는 사람이 맞고 틀림을 검증해 줄 수 있다. 동물 쪽에는 그런 검증자가 없다. 특정 소리를 들려줬을 때 동물이 예측대로 반응하는지 보는 식의 검증 설계가 연구의 질을 가른다.

    망가뜨린 것 고치기 묶음에서 원문의 문제의식이 가장 선명하게 드러난다. 기술은 최첨단 연구개발을 삶을 더 낫고, 안전하고, 건강하고, 즐겁게 만드는 데 쓰라고 있는 것이다. 영구 화학물질이나 교통사고 사망, 잠재적으로 위험한 행동을 부추기는 AI처럼 일을 그르쳤을 때는 다시 파고들어 피해를 평가하고 고칠 방법을 찾아야 한다. 편집자의 논리는 이렇게 요약된다. 영구 화학물질은 자연에서 잘 분해되지 않아 환경과 몸에 오래 남는 합성 화학물질을 가리키는 말이다. 엉킨 것을 푸는 일 자체가 불가능해 보여도 손을 놓아서는 안 된다는 것이 편집자의 주장이다.

    구조로 보면 개발팀이 장애 대응 뒤에 쓰는 포스트모템과 같다. 피해 범위 파악, 원인 추적, 재발을 막는 장치 추가. 새 기능을 만드는 일보다 덜 빛나지만, 사용자가 실제로 체감하는 변화는 오히려 이쪽에서 나오는 경우가 많다.

    ‘돌파구’ 뉴스는 층·재현·병목·발화자 순으로 읽는다

    편집자가 말한 습관을 뉴스 읽기에 그대로 옮기면 꽤 쓸 만한 체크리스트가 나온다. 목록을 만들고, 일정을 그리고, 예산 항목을 세는 그 방식이다. 아래 네 가지를 순서대로 던져 보면 된다.

    1. 어느 층에서 막혀 있나? 원리 자체가 확인되지 않은 단계(존재하는지 모름), 원리는 되지만 구현이 어려운 단계(공학), 구현은 되지만 비용이 맞지 않는 단계(경제성) 가운데 어디인지부터 본다. 원리 단계의 기술에 ‘곧 상용화’라는 말이 붙어 있다면 일단 의심하는 것이 맞다.
    2. 누가 확인했나? 발표한 팀 자체의 결과인지, 독립된 다른 연구진이 재현한 결과인지 구분한다. 동료 심사를 거친 논문인지, 심사 전 공개본이나 보도자료인지도 함께 확인한다. 주장이 놀라울수록 재현이라는 문을 통과해야 비로소 의미가 생긴다.
    3. 병목이 몇 개고, 서로 묶여 있나? 간트 차트를 그려 보면 바로 드러난다. 앞 단계가 끝나야 다음 단계가 시작되는 의존 관계가 길게 이어진 기술은 하나가 풀렸다고 전체 일정이 당겨지지 않는다. 장치·재료·설비가 줄줄이 엮인 핵융합에서 ‘핵심 난제 해결’이라는 뉴스가 나왔다면, 여러 줄 가운데 한 줄이 움직였다는 뜻일 가능성이 크다.
    4. 일정과 예산은 누가 말했나? 투자 유치를 앞둔 회사의 발표와 공공 연구기관의 로드맵은 숫자의 무게가 다르다. 그 숫자를 말한 쪽이 숫자로 무엇을 얻는지 따져 보면 얼마나 할인해서 들을지 정하기 쉽다.

    네 질문의 목적은 꿈을 깎아내리는 데 있지 않다. 기대를 정확히 어디에 걸어야 하는지 아는 것이 목적이다. 막힌 층을 알고 있어야 정말 의미 있는 진전이 나왔을 때도 알아볼 수 있다. 상온 초전도체라면 독립 재현이 그 신호다. 핵융합이라면 에너지 수지, 지속 시간, 비용 가운데 한 가지가 아니라 여러 조건이 함께 나아졌다는 소식이 그 신호에 가깝다.

    한국어 제목에서 ‘실용적인’이 잘리면 생기는 착시

    이 글에서 다룬 기술 가운데 한국 소비자가 당장 사거나 설정할 수 있는 것은 없다. 한국 사용자에게 실제로 달라지는 부분은 다른 데 있다. 영어 원문이 한국어 기사로 옮겨질 때 생기는 차이를 걸러내는 습관이다.

    원문이 말하는 것은 그냥 ‘핵융합’이 아니라 ‘실용적인 핵융합’이다. 그냥 ‘AI’가 아니라 ‘잠재적으로 위험한 사용자 행동을 부추기는 AI’다. 이런 수식어가 제목 길이 때문에 잘려 나가면 “핵융합은 불가능”, “AI가 위험 행동 유도”처럼 원문과 다른 단정이 만들어지기 쉽다. 해외 기술 기사를 한국어로 접할 때 이 수식어 손실이 오독의 흔한 원인이라고 본다. 한국어 기사 제목은 짧게 압축되는 경우가 많고, 압축 과정에서 가장 먼저 떨어져 나가는 것이 ‘실용적인’, ‘잠재적으로’ 같은 단서들이다. 다만 이것은 경향에 대한 추측이고, 통계로 확인된 내용은 아니다.

    국내에서는 ‘꿈의 기술’이라는 이름이 붙은 발표가 투자 이야기로 번지는 일도 있다. 이럴 때일수록 앞의 네 가지 질문, 특히 ‘누가 재현했나’를 먼저 확인하는 것이 손해를 줄이는 방법이다. 원문 링크가 있다면 제목에서 멈추지 말고 수식어가 붙은 원래 문장을 한 번 찾아 읽어 보자. 그것만으로도 착시의 상당 부분은 걷힌다.

    확인된 것과 아직 불확실한 것

    확인된 것

    • 이 잡지의 인쇄판은 불가능해 보이는 아이디어들을 점검하는 기사 묶음으로 한 해를 마무리하는 호를 꾸렸다.
    • 편집자 글에 언급된 예는 달 거주, 뇌 업로드, 인공 혈액, 동물의 말 해독이고, AI 킬 스위치·실용적인 핵융합·상온 초전도체는 ‘비현실적인 것’의 비유로 등장한다.
    • 잡지는 목록과 인포그래픽 같은 정기 꼭지를 다시 들였고, 더 과감한 실험을 해 보겠다고 밝혔다.
    • 이 편집자는 합류 직전까지 3년 동안 기후위기 대응을 위한 개인 행동을 다루는 뉴스레터를 편집했다.

    아직 불확실한 것

    • 편집자 글은 어느 기술이 언제 실용화될지에 대한 일정이나 수치를 제시하지 않는다.
    • 해당 호의 개별 기사들이 각 기술의 실현 가능성을 어떻게 평가했는지는 편집자 글만으로는 알 수 없다.
    • AI 킬 스위치를 누가, 어떤 조건에서 작동시킬지 같은 제도적 틀은 합의된 답이 없는 질문으로 남아 있다.

    실현 가능성 평가를 판정 대신 첫 단계 찾기에 쓰기

    편집자가 면접 답으로 준비한 ‘약점’은 개발자들에게도 익숙한 병이다. 사이드 프로젝트 아이디어가 떠오르면 인프라 비용, 유지보수 부담, 경쟁 서비스를 계산하다가 시작도 하기 전에 접는다. 한 번쯤 겪어 봤을 장면이다. 평가 자체는 좋은 습관이다. 문제는 평가가 ‘할지 말지’를 가르는 판정으로만 쓰일 때 생긴다.

    같은 평가를 ‘첫 단계 찾기’에 쓸 수도 있다. 병목 목록을 뽑았다면 그중 가장 작고 싸게 검증할 수 있는 하나를 골라 그것부터 해 본다. 인공 혈액을 피 전체가 아니라 특정 기능을 대신하는 문제로 쪼개 볼 수 있는 것과 같은 원리다. 큰 목표를 쪼개면 ‘불가능’의 상당 부분이 ‘아직 안 해 본 것’으로 바뀐다.

    기후위기 개인 행동을 다루는 뉴스레터를 3년 동안 편집하며 편집자가 얻은 결론도 같은 방향을 가리킨다. 할 수 없는 것에만 집중하면 어둠은 더 짙어질 뿐이라는 것. 거대한 문제 앞에서 개인이 깎아낼 수 있는 몫을 찾는 일은 헛수고처럼 보이지만, 그 몫을 찾는 사람이 있어야 다음 걸음이 생긴다. 꿈의 기술 뉴스를 깐깐하게 읽는 눈과 자기 아이디어에 기회를 주는 태도는 서로 부딪히지 않는다. 출발점이 같아서다. 어디서 막혔는지 정확히 아는 것.

    출처: MIT Tech Review AI

  • 챗GPT 공유 링크 삭제법, 주소만 알면 열리는 대화

    챗GPT 공유 링크 삭제법, 주소만 알면 열리는 대화

    3줄 요약

    • AI 챗봇의 공유 링크는 보낸 사람에게만 가는 메시지가 아니다. 주소를 아는 누구나 열 수 있는 공개 페이지다.
    • 챗GPT는 설정 → 데이터 제어 → 공유 링크 → 관리에서 내가 만든 링크를 모아 보고 지울 수 있다.
    • 공유 전에는 이름·연락처·회사 정보를 뺀 새 대화로 옮기고, 공유가 끝나면 링크를 지우는 습관이 가장 확실한 방어다.

    민감한 대화가 그대로 담긴 채 열려 있던 공유 링크 6,800개. 연구자들이 메타 Muse에서 찾아낸 숫자다. 사용자들이 비공개라고 여겼던 대화가 온라인에 드러나자 메타는 Muse의 공유 기능을 멈췄다. MIT 테크놀로지 리뷰는 이 소식을 뉴스레터에서 한 줄로만 짚고 넘어갔다. 링크가 어떤 경로로 그만큼 퍼졌는지는 원문에도 설명이 없다. 그래도 챗봇을 매일 업무에 쓰는 직장인이라면 한 줄짜리 소식으로 흘려보내기는 어렵다.

    사고는 메타 Muse에서 났지만, 따져 봐야 할 것은 서비스 하나가 아니라 ‘공유 링크’라는 기능을 다루는 방식이다. 대부분의 AI 챗봇은 대화를 남에게 보여주는 가장 손쉬운 수단으로 링크 공유를 제공한다. 그렇게 만든 링크는 생각보다 오래, 생각보다 넓게 살아 있다. 반면 내가 만든 공유 링크 목록을 열어 필요 없는 것을 지우는 데는 몇 분이면 충분하다. 아래에서는 공유 링크가 작동하는 방식, 서비스별 확인 경로, 공유 전후 점검 순서를 차례로 다룬다.

    공유 링크는 ‘받는 사람’이 아니라 ‘주소를 가진 사람’에게 열린다

    채팅 화면에서 공유 버튼을 누르면 서비스는 그 대화를 별도 웹 페이지로 만들고 고유 주소를 붙인다. 이 페이지는 보통 로그인 없이 열린다. 동료 한 명에게만 보냈어도 그 동료가 단체방에 다시 붙이거나 메일로 전달하는 순간, 주소를 받은 사람 모두가 같은 페이지를 보게 된다. 공개 범위를 정하는 건 내가 누구에게 보냈느냐가 아니다. 누가 그 주소를 손에 넣었느냐다.

    공유 시점의 대화를 사진 찍듯 고정해 두는 서비스도 많다. 챗GPT도 링크를 만든 뒤 이어서 나눈 대화는 링크에 자동으로 붙지 않는다. 얼핏 안전장치처럼 보이는 설계다. 하지만 같은 이유로, 원본 대화에서 민감한 부분을 나중에 지우거나 고쳐도 이미 만든 링크 속 내용은 그대로 남아 있을 수 있다. 원본을 손본 것만으로 정리가 끝났다고 믿으면 안 되는 대목이다. 링크를 지우지 않는 한 공유 시점의 기록은 계속 열려 있다.

    링크가 내 손을 떠나 퍼지는 길도 여러 갈래다. 메신저 대화방, 사내 위키, 블로그 글, 커뮤니티 게시판에 붙인 주소는 누구든 복사해 갈 수 있다. 공개 게시판에 올라간 주소라면 검색엔진이 수집해 갈 가능성까지 생긴다. 어느 경로였든 한 번 밖으로 나간 링크를 회수하기 어렵다는 점은 서비스를 가리지 않는다.

    링크·게시·캡처·팀 공유, 되돌릴 수 있는 범위가 저마다 다르다

    대화를 남에게 보여준다는 목적은 같아도, 어떤 방법을 쓰느냐에 따라 위험의 크기가 달라진다. 자주 쓰는 방식 네 가지를 노출 범위와 되돌릴 수 있는 정도로 나누면 아래와 같다.

    공유 방식 볼 수 있는 사람 되돌리기 주의할 점
    공유 링크 주소를 가진 누구나 링크 삭제로 접근 차단 가능 삭제 전에 복사·캡처된 내용은 회수 불가
    앱 안의 공개 게시·피드 해당 서비스 이용자 전반 게시물 삭제로 가능 ‘공유’와 ‘게시’ 버튼을 헷갈리기 쉽다
    스크린샷·텍스트 복사 받은 사람과 재전달 대상 사실상 불가 화면 구석의 이름·프로필이 함께 찍히기 쉽다
    팀·업무용 공간 내 공유 같은 조직 구성원 권한 해제로 가능 조직 정책에 따라 관리자 열람 범위가 달라진다

    되돌리기 칸만 놓고 보면 공유 링크는 오히려 다루기 쉬운 쪽에 속한다. 지우면 접근을 막을 수 있으니 한번 보내면 끝인 스크린샷보다 통제가 수월하다. 대신 지우지 않으면 끝없이 열려 있다. 링크 공유를 쓰지 말자는 얘기는 아니다. 만들어서 보여주고, 다 본 뒤 치우는 데까지를 한 묶음의 작업으로 보자는 것이 이 글의 요지다.

    챗GPT는 ‘데이터 제어’ 안에 공유 링크 목록을 모아 둔다

    OpenAI의 챗GPT는 내가 만든 공유 링크를 한 화면에 모아 보여준다. 아래 경로는 웹 화면 기준이다. 모바일 앱은 메뉴에서 프로필(이름)을 눌러 설정으로 들어가는 식이라 입구가 조금 다르다. 앱 업데이트에 따라 항목 이름이 바뀌기도 하니, 굵게 표시한 단어를 기준으로 찾으면 된다.

    1. 사이드바 아래쪽(구버전은 오른쪽 위)의 프로필 아이콘 → 설정
    2. 데이터 제어(영문 Data controls)
    3. 공유 링크 항목 옆 관리 버튼
    4. 목록에서 지울 링크의 휴지통 아이콘을 눌러 하나씩 삭제. 전체를 한꺼번에 지우는 메뉴는 목록 창의 더보기(…) 안에 있는 것으로 알려져 있지만, 이 단계는 화면에서 확인이 필요하다.

    목록에는 링크 이름과 공유한 날짜가 함께 나온다. 기억나지 않는 링크부터 열어 내용을 보고 정리하면 된다. 헷갈리기 쉬운 지점은 세 군데다.

    • 보관은 삭제가 아니다. 대화를 보관함으로 옮기면 사이드바에서 안 보이게 될 뿐이다. 그 대화로 만든 링크가 살아 있는지는 공유 링크 목록에서 따로 확인하는 편이 안전하다.
    • 원본을 지웠다면 목록도 본다. 원본 대화 삭제와 링크 삭제가 어떻게 연동되는지는 서비스마다 다르다. 원본을 지운 뒤에도 공유 링크 목록에서 해당 항목이 사라졌는지 눈으로 확인해야 확실하다.
    • 다시 공유하면 내용이 갱신될 수 있다. 이미 공유한 대화에서 공유 버튼을 한 번 더 누르면 링크를 최신 내용으로 업데이트하는 선택지가 뜨는 경우가 있다. 앞서 말한 ‘공유 시점 고정’이 여기서 풀리는 셈이다. 민감한 내용을 덧붙인 뒤라면 무심코 업데이트를 누르지 않도록 주의한다.

    제미나이는 ‘내 공개 링크’, 나머지 챗봇은 설정 속 단어로 찾는다

    구글 제미나이에도 대화를 링크로 공유하는 기능이 있고, 만든 링크를 모아 보는 화면이 따로 있다. 웹에서는 설정 및 도움말 → 내 공개 링크(영문 Your public links)로 들어간다. 한글 항목 이름은 화면에서 확인이 필요하다. 목록에서는 링크별로 삭제할 수 있다.

    그 밖의 서비스는 메뉴 구조가 제각각이어서 경로를 하나로 묶기 어렵다. 찾는 요령은 비슷하다.

    • 설정 안에서 ‘공유’, ‘공개 링크’, ‘데이터 제어’, ‘개인정보’ 같은 단어가 붙은 항목부터 열어 본다.
    • 모아 보는 목록이 없는 서비스라면 공유했던 대화를 직접 열고 공유 버튼을 다시 누른다. 이미 공유된 대화라면 대개 이 자리에 ‘링크 삭제’나 ‘공유 중지’ 같은 선택지가 함께 나온다.
    • 피드나 둘러보기처럼 다른 사람의 대화가 보이는 공간이 앱 안에 있다면 내 프로필의 게시물·활동 목록도 살핀다. 링크가 아니라 공개 게시물 형태로 올라가 있을 수 있어서다.
    • 링크를 지웠으면 그 주소를 로그아웃 상태의 브라우저(시크릿 창)에서 열어 본다. ‘찾을 수 없음’이나 오류 화면이 뜨면 정리는 끝난 것이다.

    단톡방에 붙인 링크는 나중에 들어온 사람에게도 열린다

    공유 링크의 원리는 어디서나 같다. 링크가 퍼지는 경로는 쓰는 환경에 따라 달라지는데, 한국 사용자라면 눈여겨볼 차이가 세 가지 있다.

    링크가 머무는 곳은 대부분 메신저 단체방이다. 업무 자료든 생활 정보든 단톡방에 주소를 붙이는 일이 흔하고, 단톡방은 구성원이 계속 바뀐다. 새로 들어온 사람도 이전 기록을 볼 수 있는 방이라면 예전에 붙인 링크가 그 사람에게도 그대로 열린다. 메신저가 링크 미리보기를 만들면 대화 제목이 카드 형태로 함께 뜰 수도 있다. 대화 제목은 챗봇이 내용을 바탕으로 자동으로 붙이는 경우가 많아서, 링크를 누르지 않아도 제목만으로 무슨 이야기인지 드러나기도 한다.

    한국어로 챗봇에 맡기는 일에는 개인 정보가 섞여 들어가기 쉽다. 자기소개서 첨삭을 부탁하며 이력서를 통째로 붙여 넣거나, 연봉 협상 메일을 다듬으면서 현재 연봉과 회사 이름을 적거나, 건강검진 결과를 풀어 달라며 수치를 그대로 입력하는 식이다. 답변이 잘 나왔다는 이유로 이런 대화를 링크로 돌리면 내가 입력한 원문도 답변과 함께 공개된다. 받는 쪽은 답변만 보려고 열겠지만 페이지에는 질문까지 전부 담겨 있다.

    회사 정보가 걸리면 개인 실수로 끝나지 않는다. 사내 문서나 고객 데이터를 생성형 AI에 넣는 것 자체를 제한하는 회사도 있다. 그런 내용이 공유 링크로 외부에 열려 있다면 규정 위반 여부를 따지기도 전에 이미 유출이 일어난 상태다. 회사 계정과 개인 계정을 나눠 쓰고, 업무 대화는 링크 대신 사내에서 허용한 방식으로 전달하는 편이 안전하다.

    확인된 것과 아직 불확실한 것

    확인된 것

    • 메타가 Muse의 공유 기능을 일시 중단했다.
    • 중단 계기는 비공개로 여겨진 대화가 온라인에 드러난 일이다.
    • 연구자들이 민감한 대화가 담긴 링크 6,800개를 찾아냈다.

    아직 불확실한 것

    • 6,800개 링크가 사용자의 공유 습관 때문에 퍼졌는지, 서비스 설계상의 문제였는지
    • 노출된 대화에 한국어 사용자의 대화가 포함됐는지
    • Muse 공유 기능이 언제, 어떤 보완책과 함께 다시 열릴지
    • 링크를 지운 뒤 해당 대화 사본이 서비스 서버에서 언제 완전히 지워지는지(서비스별 보관 정책에 따라 다르다)

    공유 전에 덜어내고, 공유 후에 치우는 점검 순서

    링크 공유를 안전하게 쓰는 방법이 복잡하지는 않다. 공유 전에 할 일과 공유 후에 할 일을 미리 정해 두면 된다.

    공유하기 전

    • 보여주고 싶은 게 답변 일부라면 링크 말고 그 부분만 텍스트로 복사해 보낸다.
    • 링크가 꼭 필요하면 이름·연락처·회사명·구체적 수치를 뺀 질문으로 새 대화를 열어 답을 다시 받고, 그 대화를 공유한다. 번거롭지만 입력 원문이 함께 노출되는 문제를 가장 확실하게 피하는 방법이다.
    • 공유 창에 이름 표시 여부나 공개 범위 선택지가 있으면 가장 좁은 쪽을 고른다.
    • 대화 제목이 내용을 드러낸다면 공유 전에 제목부터 바꿔 둔다. 메신저 미리보기 카드에 제목이 뜨는 문제도 함께 줄어든다.

    공유한 뒤

    • 상대가 내용을 확인했으면 링크를 지운다. 오래 남겨 둘 이유가 있는 링크는 드물다.
    • 월급날처럼 기억하기 쉬운 날을 하나 정해 공유 링크 목록을 열고, 기억나지 않는 링크를 정리한다.
    • 지운 주소는 시크릿 창에서 다시 열어 닫혔는지 확인한다.

    경위가 어떻든 6,800개라는 숫자에서 읽히는 사실은 하나다. 한 번 열린 링크는 누군가 닫기 전까지 계속 열려 있다. 서비스 쪽 보완책을 기다리는 것보다 내 계정의 공유 링크 목록을 직접 비워 두는 편이 빠르고, 결과도 확실하다.

    출처: MIT Tech Review AI

  • 보스턴 차 사건 유물, 광둥어로 읽자 연대 뒤집혀

    보스턴 차 사건 유물, 광둥어로 읽자 연대 뒤집혀

    3줄 요약

    • 보스턴 차 사건 때 수습됐다고 전해진 중국 차 상자 라벨을 MIT 역사학자 트리스탄 브라운이 그보다 한 세기 가까이 늦게 만들어진 물건으로 재평가했다.
    • 결정적 단서는 라벨의 한자를 표준중국어가 아닌 광둥어로 읽은 것이었다. 글자들은 미국 차 수입 회사 스미스, 아처 앤 코(Smith, Archer & Co.)의 이름을 소리로 옮긴 표기였다.
    • 유물의 권위는 물건보다 그 물건에 붙은 이야기에서 나오는 경우가 많다. 기록과 구술을 나누고, 표기를 다른 틀로 다시 읽는 것이 출처 검증의 출발점이다.

    보스턴 올드 사우스 미팅 하우스(Old South Meeting House) 전시장에는 중국 차 상자 라벨 한 장이 있다. 이 라벨에는 늘 ‘혁명의 물증’이라는 설명이 따라다녔다. 1987년 이 라벨을 기증한 보스턴 대장장이 토머스 웰스(Thomas Wells)의 후손들 말로는, 1773년 식민지 시위대가 보스턴 항에 차를 쏟아 버린 뒤 건져 낸 물건이다. MIT 역사학과 부교수 트리스탄 브라운(Tristan Brown)도 처음 라벨을 들여다봤을 때는 그 이야기를 의심할 이유가 없었다고 한다. 1년 동안 조사를 이어 간 끝에 결론이 뒤집혔다. 사건으로부터 한 세기 가까이 지나서 만들어진 라벨이라는 것.

    MIT 테크놀로지 리뷰가 소개한 이 이야기를 ‘유물 연대 하나 바뀌었다’는 단신으로 읽고 넘기면 좀 아깝다. 박물관 유리장 안의 물건이 어떻게 ‘역사적 권위’를 얻는지, 그 권위를 어떤 순서로 다시 따져 볼 수 있는지가 이 사례 하나에 다 들어 있어서다. 그래서 이 글에서는 사건 경과보다 그 밑에 깔린 개념 두 가지를 짚어 보려 한다. 하나는 흔히 프로비넌스라고 부르는 유물 출처 이력이고, 다른 하나는 한자 음차 표기를 판독하는 원리다. 개발하는 사람 눈으로 보면 둘 다 낯설지 않은 문제다. 앞의 것은 이력 추적이고, 뒤의 것은 인코딩을 잘못 짚은 디코딩에 가깝다.

    라벨은 그대로인데 설명은 여섯 군데서 갈렸다

    같은 물건을 놓고 두 설명이 엇갈리는 건 제작 시기만이 아니다. 전해진 경로도, 역사적 의미도 다르다. 아래 표는 공개된 연구 내용만 가지고 두 설명을 나란히 세워 본 것이다.

    항목 기증 당시 설명 브라운의 결론
    제작·사용 시기 1773년 보스턴 차 사건 당시 사건으로부터 한 세기 가까이 지난 뒤
    한자 판독 방식 앞선 학자들은 표준중국어(만다린)로 읽음 광둥어로 읽어 소리를 옮긴 표기임을 확인
    라벨이 가리키는 대상 혁명 당시 바다에 버려진 차 1860~1870년대 아시아 차를 미국 시장에 들여온 미국 회사 스미스, 아처 앤 코
    연결된 인물·경로 보스턴 대장장이 토머스 웰스 골드러시 무렵 미시간에서 캘리포니아로 건너갔다 돌아온 뒤 ‘캘리포니아 티 스토어’를 운영한 웰스 가문 친척
    혁명 유래 이야기의 기원 사건 직후 수습했다는 가족 전승 1870년대 100주년 기념 분위기 속에서 나중에 생겼을 가능성
    역사적 의미 보스턴 차 사건의 물증 평범한 물건이 역사적 권위를 얻는 과정을 보여 주는 사례

    표를 볼 때 기억할 건 하나다. 라벨 자체는 아무것도 바뀌지 않았다. 같은 라벨에 같은 글자다. 달라진 건 그 글자를 읽은 방법과 물건을 따라간 경로뿐인데 결론이 통째로 뒤집혔다. 유물의 연대 판단이 물건의 겉모습 못지않게, 그걸 해석하는 틀에 크게 좌우된다는 얘기다. 개인적으로는 기존 설명이 틀렸다는 사실보다 그 설명이 오랫동안 다른 틀로 검증받지 않았다는 쪽이 더 본질적인 문제라고 본다. 틀린 답은 고치면 그만이다. 하지만 아무도 다시 묻지 않은 답은 틀렸는지조차 모르는 채로 남는다.

    기증 기록은 ‘기증됐다’는 것까지만 증명한다

    프로비넌스(provenance)는 어떤 물건이 언제, 어디서 만들어졌고 누구 손을 거쳐 지금 자리에 왔는지를 이어 붙인 이력의 사슬을 말한다. git으로 치면 커밋 로그 같은 거라고 생각하면 편하다. 미술품을 사고팔 때나 박물관이 소장품을 관리할 때, 진품인지, 소유가 정당한지 판단하려고 가장 먼저 들여다보는 근거가 이 사슬이다.

    다만 커밋 로그와 달리 이 사슬은 고리마다 성격이 제각각이다. 크게 셋으로 나뉜다. 기증서나 거래 영수증처럼 문서로 남은 고리가 있다. 가족끼리 말로 전해 온 구술 고리도 있다. 그리고 물건 표면에 새겨진 글자·상표·재질처럼 물건 스스로 품고 있는 정보가 있다. 셋은 신뢰도도 다르고 검증하는 방법도 다르다. 문서라면 작성 시점을 따지면 된다. 구술은 누가 언제부터 그렇게 말하기 시작했는지를 캐 봐야 한다. 물건 속 정보는 그 시대의 표기 관습과 맞대 봐야 하고.

    보스턴 라벨에 대입해 보면 구분이 선명해진다. 문서로 확인되는 고리는 ‘1987년 웰스 가문 후손이 기증했다’는 사실 하나다. ‘1773년 사건 뒤에 건졌다’는 부분은 기증한 쪽의 설명, 곧 구술 고리였다. 기증 기록은 물건이 기증됐다는 사실을 증명할 뿐이다. 기증자가 덧붙인 이야기가 사실이라는 것까지 보증해 주지는 않는다. 그런데 물건이 일단 박물관에 들어가면 기관에 대한 신뢰가 이야기에까지 번진다. 구술이 어느새 공인된 사실처럼 보이기 쉽다. 역사학자인 브라운조차 처음엔 의심할 이유를 찾지 못했다고 하니, 이 효과가 얼마나 센지 짐작이 간다.

    만다린 대신 광둥어로 읽자 ‘스미스, 아처 앤 코’가 나왔다

    한자는 원래 뜻을 담는 글자다. 그런데 외국 이름을 적어야 할 때는 뜻을 내려놓고 소리만 빌려 쓰기도 한다. 이걸 음차(音借)라고 한다. 음차로 적은 글자는 뜻을 아무리 풀어 봐야 말이 되지 않는다. 그 글자를 고른 사람의 발음으로 다시 소리 내 읽어야 비로소 원래 이름이 드러난다.

    함정은 여기서 생긴다. 같은 한자라도 어느 지역 말로 읽느냐에 따라 소리가 다르다. 앞선 학자들은 라벨의 한자를 표준중국어(만다린)로 읽었고, 브라운은 광둥어로 읽었다. 그러자 이 글자들이 1860~1870년대 아시아산 차를 사들여 미국 시장으로 보낸 미국 회사 스미스, 아처 앤 코의 이름을 소리 나는 대로 옮긴 것이라는 사실이 드러났다. 앞에서 디코딩 얘기를 꺼낸 게 이 대목 때문이다. UTF-8로 저장한 파일을 EUC-KR로 열면 글자가 깨지듯, 읽는 쪽이 기준을 잘못 잡으면 데이터가 멀쩡해도 의미가 나오지 않는다. 왜 하필 광둥어가 맞는 열쇠였는지는 연구 소개 글에도 자세한 설명이 없다. 회사 이름을 한자로 옮긴 사람이 광둥어를 쓰는 환경에 있었다면 소리의 기준도 광둥어였으리라고 추론해 볼 수는 있다.

    ‘변이형’ 이야기도 놓치면 안 된다. 브라운 설명으로는 이 회사 이름이 동시대 여러 자료에 조금씩 다른 글자로 적혀 있었다. 음차에는 정해진 철자가 없다. 같은 이름이라도 누가 썼는지, 어느 자료인지에 따라 글자가 흔들리기 마련이다. 이 흔들림 탓에 판독은 어려워진다. 하지만 제각각인 표기들이 결국 같은 소리를 겨냥하고 있다는 걸 확인하면 해석의 근거는 거꾸로 단단해진다. 내가 보기에 이 사례가 주는 방법론적 교훈은 이거다. 어떤 언어로 읽을지 고르는 일 자체가 하나의 가설이고, 그 가설은 동시대 자료와 맞대 보며 검증해야 한다.

    차 가게 친척의 라벨이 ‘혁명의 유물’이 되기까지

    라벨이 실제로 거쳐 온 경로는 웰스 가족과 함께한 조사에서 드러났다. 브라운이 거슬러 올라가 닿은 사람은 가문의 한 친척이다. 골드러시 시기에 미시간에서 캘리포니아로 건너갔다가 돌아와 ‘캘리포니아 티 스토어’라는 가게를 운영한 인물. 차 가게를 하던 집안에 차 상자 라벨이 남아 있었다는 연결에는 억지스러운 데가 없다. 혁명 유래 이야기에 대해서는 브라운이 1870년대 100주년 기념 분위기 속에서 나중에 생겨났을 가능성이 크다고 본다. 이 부분은 확정된 사실이 아니라 그의 해석이라는 점을 분명히 해 두자.

    오해하지 말아야 할 게 있다. 이런 이야기가 생기는 데 꼭 누군가 거짓말을 해야 하는 건 아니다. 일반적으로 기념일은 사람들로 하여금 집안 물건에서 큰 사건과 이어지는 고리를 찾게 만든다. 세대가 몇 번 바뀌는 사이 ‘집안 어른이 하던 차 가게의 라벨’이 ‘차 사건 때 건진 라벨’로 바뀌는 데는 기억이 조금씩 압축되는 일이 몇 번이면 충분하다. 덜 알려진 사실은 잊히고, 누구나 아는 유명한 사건 쪽으로 이야기가 끌려가는 경향이 있으니까. 물론 이건 일반적인 기억의 작동 방식에 기댄 해석이다. 이 라벨의 이야기가 실제로 어떤 경로를 거쳐 바뀌었는지는 밝혀지지 않았다.

    브라운은 이번 발견 때문에 라벨이 역사적으로 하찮아지는 건 아니라고 강조한다. 출발은 보스턴 차 사건의 유물임을 확인하려는 조사였다. 그 조사가 평범한 물건이 어떻게 역사적 권위를 얻는지, 역사적 기억은 어떻게 만들어지는지를 들여다보는 연구로 방향을 틀었다. 라벨이 증언하는 대상도 ‘1773년의 사건’에서 ‘후대 사람들이 그 사건을 기억한 방식’으로 옮겨 갔다. 내 생각엔 바뀐 쪽 증언이 더 흥미롭다. 사건 자체는 누구나 아는 이야기다. 반면 사람들이 그 사건을 어떤 식으로 집안 물건에 엮어 기억해 왔는지는 이런 물건을 통해서야 겨우 보인다.

    한국식 한자음으로 읽는 습관도 같은 함정에 빠진다

    우리에게 와닿는 지점은 한자를 읽는 습관이다. 한국 사람은 한자를 보면 거의 반사적으로 한국 한자음으로 읽는다. 그런데 외국 이름을 중국 어느 지역 말의 소리로 옮긴 표기라면, 한국식 독음으로 읽어서는 원래 이름에 닿기 어렵다. 앞선 학자들이 표준중국어로 읽다가 회사 이름을 놓친 것과 구조가 똑같은 함정이다. 한국어에도 외국 나라나 도시 이름을 한자 소리로 적은 옛 표기가 남아 있다는 걸 떠올리면 감이 온다. 표기를 만든 사람이 어떻게 발음했느냐가 판독의 열쇠라는 원리 말이다.

    번역기를 쓸 때도 비슷하게 조심할 필요가 있어 보인다. 중국어 문장을 번역기에 넣으면 대개 표준중국어 발음 표기가 함께 나온다. 오래된 상표나 포장, 편지에 적힌 고유명사가 다른 지역 말로 음차된 거라면 그 발음으로 검색해 봐야 원래 이름을 찾지 못할 수 있다. 도구가 보여 주는 기본값을 정답으로 착각하지 말라는 얘기다. 다만 이건 이번 사례에서 끌어낸 추측이고, 모든 번역 도구가 같은 방식으로 작동한다는 뜻은 아니다.

    집안에 대대로 내려오는 오래된 물건도, 중고 거래 플랫폼·SNS에 ‘○○시대 물건’이라는 설명을 달고 올라오는 물건도 원리는 같다. ‘조상이 어떤 사건 때 얻은 물건’이라는 이야기는 확인해야 할 대상이지 그 자체로 증거가 되지 않는다. 박물관이나 기록관에 감정을 문의할 생각이라면 가족 전승과 문서 근거를 나눠서 전달하는 편이 좋겠다. 그래야 검증하는 쪽이 어느 고리부터 확인할지 판단하기 쉬워질 것이다. 하나 더 기억해 둘 게 있다. 이 사례에서 결정적인 경로를 밝혀 준 건 결국 가족의 협조였다. 전승을 의심하는 일과 가족과 손잡는 일은 서로 부딪히지 않는다.

    확인된 것과 아직 불확실한 것

    확인된 것

    • 라벨은 보스턴 올드 사우스 미팅 하우스에 전시돼 있으며, 1987년 대장장이 토머스 웰스의 후손들이 1773년 보스턴 차 사건 뒤 수습한 물건이라며 기증했다.
    • 브라운은 1년간 조사한 끝에 라벨이 사건보다 한 세기 가까이 늦게 만들어졌다고 결론 내렸다.
    • 라벨의 한자를 광둥어로 읽으면 1860~1870년대 아시아 차를 미국 시장에 공급한 미국 회사 스미스, 아처 앤 코의 이름을 소리로 옮긴 표기가 되며, 같은 이름이 동시대 여러 자료에 조금씩 다른 글자 형태로 나타난다.
    • 웰스 가족과의 공동 조사로 라벨은 골드러시 시기 미시간과 캘리포니아를 오간 뒤 ‘캘리포니아 티 스토어’를 운영한 친척과 연결됐다.

    아직 불확실한 것

    • 혁명 유래 이야기가 정확히 언제, 누구에게서 시작됐는지. 1870년대 100주년 기념 무렵이라는 것은 브라운의 추정이다.
    • 라벨이 만들어진 정확한 연도. 소개된 내용은 ‘한 세기 가까이 뒤’라는 범위만 제시한다.
    • 올드 사우스 미팅 하우스가 전시 설명을 어떻게 바꿀지, 또는 이미 바꿨는지.
    • 연구가 어떤 형태로 발표되고 다른 연구자들의 검토를 거쳤는지.

    브라운의 조사에서 뽑아낸 출처 검증 다섯 단계

    브라운의 조사 흐름을 조금 일반화하면, 출처 이야기가 붙은 물건을 다시 따져 보는 순서를 다섯 단계로 나눌 수 있다. 미리 말해 두는데, 이건 브라운이 공식 방법론으로 내놓은 게 아니다. 공개된 조사 과정에서 뼈대만 추려 낸 것이다.

    1. 이야기와 근거를 떼어 놓는다. 누가, 언제, 어떤 형태로 그 이야기를 전했는지부터 적는다. 그다음 문서로 남은 부분과 말로만 전해진 부분을 가른다. 보스턴 라벨에서는 ‘1987년 기증’과 ‘1773년 수습’이 서로 성격이 다른 고리였다.
    2. 물건에 적힌 글자를 다른 틀로 읽어 본다. 어떤 언어, 어떤 발음, 어떤 표기 관습으로 읽었는지를 확정된 사실이 아닌 가정으로 두고 하나씩 바꿔 본다. 이 사례의 돌파구도 판독 언어를 바꾼 데서 나왔다.
    3. 동시대 자료와 맞대 본다. 같은 이름이나 표기가 같은 시대의 다른 자료에도 나오는지 찾는다. 글자가 조금씩 다른 변이형까지 모으면, 우연히 맞아떨어진 건지 정말 같은 대상을 가리키는 건지 가려낼 근거가 생긴다.
    4. 소유 경로를 사람 단위로 쫓는다. 물건을 가졌던 사람들이 어디로 옮겨 다녔고, 무슨 일을 했고, 어떤 사업을 했는지 따라간다. 차 가게를 운영한 친척이라는 고리 하나가 라벨의 실제 쓰임새를 설명해 줬다.
    5. 이야기가 생겨난 시대의 분위기를 살핀다. 기념일이나 유행, 수집 열기처럼 사람들이 특정한 이야기를 원하게 만든 사회적 배경이 있었는지 본다. 브라운이 1870년대 100주년 기념 분위기에 주목한 게 이 단계에 해당한다.

    다섯 단계 어디에도 특별한 장비는 나오지 않는다. 이 사례의 결정적 단서도 새 분석 기기가 아니라 ‘같은 글자를 다른 언어로 읽어 보면 어떨까’라는 질문 하나에서 나왔다. 디버깅을 해 본 사람이라면 익숙한 장면이다. 가장 늦게 의심하게 되는 건 늘 당연하다고 믿었던 전제니까. 브라운은 “역사는 결코 끝나지 않는다”며 “수십 년 동안 박물관에 놓여 있던 물건도 새로운 질문을 던지면 완전히 새로운 이야기를 드러낼 수 있다”고 말했다. 혁명의 물증이라는 자리를 내준 라벨은 역사적 기억이 어떻게 만들어지는지 보여 주는 물증으로 새 자리를 얻었다.

    출처: MIT Tech Review AI

  • MIT 공중·수중 드론, 날갯짓만으로 물에서 이륙

    MIT 공중·수중 드론, 날갯짓만으로 물에서 이륙

    3줄 요약

    • MIT와 스위스 EPFL 연구진이 300g 미만의 날갯짓 로봇 FAAV로 물속 헤엄과 공중 비행을 한 기체에서 이어 붙였어요.
    • 물→공기 전환의 열쇠는 날개 크기·유연성, 날갯짓 주파수, 꼬리 각도였고, 중간 크기 날개와 70도 피치 조합이 가장 매끄러웠어요. 발은 필요 없었고요.
    • 배나 해안에서 띄워 잠수 측정·샘플링 후 돌아오는 해양 관측용이 목표인데, 방향 전환과 거친 파도·바람 시험은 아직 남아 있어요.

    물은 공기보다 밀도가 1,000배 높습니다. 같은 날개를 같은 힘으로 휘저어도 공기 속에서는 몸을 겨우 띄우는 수준인데, 물속에서는 날개 하나 움직이는 데도 훨씬 큰 저항이 걸린다는 뜻이에요.

    갈매기나 퍼핀 같은 바닷새는 이 차이를 아무렇지 않게 넘나듭니다. 하늘에서 바다로 내리꽂혀 물속을 헤엄치고, 다시 수면을 박차고 날아오르죠. 이 능력을 기계로 옮기려는 분야가 공중·수중 겸용 드론(aerial-aquatic vehicle)입니다.

    MIT와 스위스 로잔 EPFL의 공동 연구진이 이 분야에 새 답안을 하나 냈어요. 새처럼 날개를 퍼덕이는 방식으로 물과 공기 사이를 건너는 로봇이고, 무게는 300g이 채 안 됩니다.

    이 글은 로봇 소식 자체보다 원리 쪽에 무게를 둡니다. 순서는 세 단계예요.

    • 물과 공기를 오가는 로봇은 왜 어려운가
    • FAAV는 어떤 변수로 그 문제를 풀었나
    • 어디에 쓰려고 만들었나

    공중·수중 드론이나 생체모방 로봇이 처음이라면 이 순서대로 읽는 편이 구조를 잡기 쉬워요.

    밀도 1,000배 차이, 날개 하나로 양쪽을 다 맞추기 어렵다

    공중에서 몸을 띄우려면 묽은 공기를 최대한 많이, 빠르게 아래로 밀어내야 해요. 하늘을 나는 새나 비행 기계가 대체로 넓은 날개를 크게 휘두르는 쪽으로 진화하거나 설계된 이유입니다.

    문제는 그 날개를 그대로 물에 넣었을 때 생깁니다.

    • 공중에 맞춘 크고 넓은 날개: 물은 같은 동작에도 훨씬 큰 저항을 돌려주기 때문에, 공중에서 유리했던 날갯짓이 물속에서는 오히려 짐이 되기 쉬움
    • 물속에 맞춘 작고 단단한 날개: 공중에서는 몸무게를 받쳐 줄 힘이 모자랄 수 있음

    한쪽 환경에 맞추면 다른 쪽에서 손해를 보는 구조예요. 상식대로라면 물에서 쓸 추진 장치와 공중에서 쓸 추진 장치를 따로 다는 게 답처럼 보입니다. 하지만 장치가 늘면 무게가 늘고, 무게가 늘면 공중 비행이 다시 어려워지죠. 악순환입니다.

    고비가 하나 더 있어요. 물에서 공기로 넘어가는 바로 그 순간. 수면을 뚫고 나오는 짧은 구간에서 기체는 물의 저항을 이겨내는 동시에 공중에서 떠오를 준비를 해야 하고, 날개에 묻은 물까지 처리해야 하거든요. 공중·수중 드론 연구가 ‘전환(transition)’을 별도의 과제로 떼어 다루는 것도 그래서고, 이번 연구에서 가장 눈여겨볼 대목도 이 구간입니다.

    추진계 한 벌로 헤엄도 비행도, FAAV를 이루는 세 부분

    정식 이름은 ‘날갯짓 공중·수중 비행체(flapping-wing aerial-aquatic vehicle)’, 줄여서 FAAV입니다. MIT 테크놀로지 리뷰는 이 기체를 ‘로보 퍼핀’이라는 표현으로 소개했어요. 무게는 300g(약 0.5파운드) 미만이고, 구성은 크게 세 부분으로 나뉩니다.

    • 동체: 가운데 몸통에 배터리와 방수 전기 모터가 들어 있어요. 이 모터가 크랭크축을 돌리고, 크랭크축이 미리 정해 둔 주파수로 날개를 위아래로 움직입니다.
    • 날개 두 장: 얇은 막(membrane)으로 만들어 잘 휘어져요. 표면에는 물을 밀어내는 소수성 나노입자를 코팅해 물기가 빨리 빠지도록 했습니다.
    • 꼬리: 모터로 각도를 바꿀 수 있는 조향용 꼬리. 각도를 조절해 기체가 위로 날아오르거나 아래로 잠수하도록 돕습니다.

    핵심은 추진이 하나로 묶여 있다는 점이에요. 물속에서 헤엄칠 때도, 공중을 날 때도 같은 모터, 같은 크랭크축, 같은 날개가 일합니다. 원문 설명에는 물속 전용 추진기가 따로 등장하지 않아요. 앞에서 말한 ‘장치가 늘면 무게가 는다’는 악순환을 정면으로 피한 설계이고, 300g 미만이라는 가벼운 몸무게도 부품을 겹쳐 쓰는 이 단순한 구성 덕분으로 보입니다.

    소수성 코팅도 그냥 붙인 장치가 아닙니다. 젖은 날개는 무거워지고, 퍼덕일 때마다 물을 끌고 다니게 돼요. 수면을 박차고 나온 뒤 날개에서 물기가 빨리 빠져야 공중 비행으로 자연스럽게 이어지니, 이 코팅은 앞서 말한 전환 구간을 겨냥한 설계로 읽힙니다.

    물을 박차고 오른 조합은 중간 크기 날개와 70도 피치

    실험은 MIT 기계공학과 라파엘 주페레이(Raphael Zufferey) 조교수가 이끄는 팀이 수조와 제네바 호수에서 진행했어요. 찾으려던 건 분명했습니다. 헤엄치던 로봇이 매끄럽게 날아오르게 만드는 날개 크기, 날갯짓 주파수, 꼬리 각도의 조합이요. 원문에 나온 결과를 변수별로 묶으면 아래와 같아요.

    변수 로봇에서 맡는 역할 실험에서 확인된 점
    날개 크기·유연성 물속 헤엄과 공중 비행을 모두 담당 중간 크기 날개가 가장 좋은 결과. 물속에서는 진폭을 줄일 만큼 유연하고, 공중에서는 기체를 띄울 만큼 단단함
    날갯짓 속도·주파수 크랭크축이 미리 정한 주파수로 날개를 위아래로 구동 실제 새가 쓰는 속도·주파수와 비슷한 수준
    피치(기울기) 각도 모터 구동 꼬리로 각도를 바꿔 상승·잠수를 조절 70도라는 비교적 가파른 피치에서 물→공기 도약
    발 장착하지 않음 (많은 잠수 조류는 이륙 때 발을 저어 힘을 보탬) 발 없이도 수면에서 이륙 가능

    제일 눈에 띄는 건 날개입니다. ‘크면 공중에 유리하고 작으면 물속에 유리하다’는 단순한 맞교환으로 끝나지 않았어요. 둘 사이에 다리를 놓은 건 유연성이었습니다.

    • 물속: 날개가 휘면서 날갯짓 폭(진폭)이 줄어듦
    • 공중: 같은 날개가 기체를 띄울 만큼의 단단함을 유지

    재료의 성질이 두 환경에 맞춰 움직임을 조절해 준 셈이죠. 날개 모양을 바꾸는 복잡한 장치 없이도 이중 역할이 가능했던 이유로 보입니다.

    날갯짓 속도와 주파수는 실제 새가 쓰는 범위와 비슷한 수준에서 좋은 결과가 나왔어요. 바닷새의 움직임을 본뜬 설계가 기계에서도 통했다는 뜻입니다. 생체모방 로봇이 왜 굳이 자연을 참고하는지 보여 주는 사례로 읽을 만하고요.

    70도는 꽤 가파른 각도예요. 물을 박차고 나올 때 기체를 상당히 세운 자세가 필요했다고 해석할 수 있습니다. 다만 이 숫자가 기체 전체의 자세를 말하는지, 꼬리 자체의 각도를 말하는지는 원문만으로 갈리지 않아서 해석은 거기까지가 안전합니다.

    의외의 결과는 발 쪽에서 나왔어요. 많은 잠수 조류는 수면에서 이륙할 때 발로 물을 차서 힘을 보태는데, 이 로봇은 발이 전혀 필요 없었습니다. 왜 그런지는 원문에도 자세한 분석이 없어요. 날개와 꼬리 조합만으로 이륙에 필요한 추진력과 자세 제어가 충분히 나왔다고 보는 게 가장 자연스러운 추정입니다. 방수 처리해야 할 구동부가 하나 줄어드는 셈이니, 실제 운용에서도 손해 볼 게 없는 결과고요.

    날아가서 잠수하고, 돌아와 데이터를 넘기는 해양 관측 드론

    연구진이 그리는 쓰임새는 꽤 구체적이에요. 해양학자나 해양생물학자, 해안 지역 주민이 배 위나 해안에서 로봇을 띄우는 장면에서 시작합니다.

    • 이동: 빙산이나 항만 시설, 고래 무리 위처럼 살펴볼 지점 가까이 날아감
    • 관측: 물속으로 뛰어들어 측정하거나 샘플을 채취
    • 복귀: 다시 날아올라 데이터를 전달
    • 반복: 또다시 잠수하러 출발

    주페레이 교수가 강조한 건 비용이에요. 이 과정을 기존 방식 비용의 일부만으로 해낼 수 있다는 것. 그런데 ‘일부’가 어느 정도인지는 숫자로 나오지 않아서, 지금 단계에선 방향 제시 정도로 받아들이는 게 맞습니다.

    이 그림이 왜 중요한지는 그가 짚은 해양 과학의 숙제에서 드러나요. 데이터를 자주, 그리고 여러 장소에서 모으는 일이 해양 과학의 큰 과제 중 하나라는 겁니다. 그는 이런 로봇이라면 일주일에 한 번이 아니라 한 시간마다 내보낼 수도 있다고 설명했어요. 빠르게 날아가 잠수하고, 돌아와 데이터를 넘긴 뒤 다시 나가는 일을 여러 번 되풀이할 수 있다는 얘기죠. 기존 선박이 들어가기 위험한 수역까지 닿을 수 있다는 점도 연구진이 꼽은 장점입니다.

    개념으로 보면 ‘날아서 가고, 잠수해서 재고, 날아서 돌아오는’ 왕복형 관측이에요. 기존 두 방식과 나란히 놓으면 차이가 선명해집니다.

    방식 잘하는 것 걸리는 부분
    공중 드론 빠른 이동 물속을 직접 들여다보기 어려움
    물속 로봇 물속을 직접 다니며 관측 배가 현장 근처까지 실어다 줘야 하는 경우가 많음
    FAAV 같은 공중·수중 드론 날아서 이동하고 잠수해서 관측 방향 전환, 거친 파도·바람 속 성능은 아직 검증 전

    두 방식의 장점을 한 기체에 묶으려는 접근. 공중·수중 드론이라는 분야 전체를 이해할 때도 이 한 줄에서 출발하면 됩니다.

    한국에선 소비자 제품보다 항만·연안 관측 쪽 이야기

    선을 먼저 그어 두겠습니다. FAAV는 수조와 호수에서 시험한 연구 단계의 기체예요. 한국 사용자가 손에 쥐거나 직접 띄워 볼 수 있는 물건이 아니고, 일반 소비자 입장에서 당장 바뀌는 건 없습니다.

    달라질 여지가 있는 쪽은 바다를 다루는 연구·현장 업무입니다. 아래 내용은 원문의 쓰임새를 한국 상황에 대입해 본 추측이라는 점을 감안해 주세요.

    • 항만·연안 시설 점검(추측): 원문이 직접 항만 시설을 예로 든 만큼, 바다와 맞닿은 항만·연안 시설이 많은 한국에서도 물 위와 물 아래를 한 번에 살피는 점검 수단으로 검토될 수 있어 보여요.
    • 짧은 주기의 연안 관측(추측): 한 시간 단위로 띄울 수 있다는 아이디어는 적조나 수온 변화처럼 짧은 시간에 달라지는 연안 현상을 추적하는 데 잘 맞을 수 있어요. 다만 어떤 센서를 실을 수 있는지는 원문에 나오지 않아 실제 적용 가능성은 판단하기 어렵습니다.
    • 비행 규정 문제(추측): 한국에서 바다 위에 드론을 띄우려면 기존 드론 비행 규정을 따라야 할 텐데, 물에 들어갔다 나오는 기체를 어떻게 분류하고 관리할지는 이 글에서 확인할 수 없는 부분이에요.

    한국에서 체감할 변화가 있다면 소비자 제품이 아니라 해양 조사 방식의 선택지가 하나 늘어나는 쪽일 겁니다. 배를 띄우는 횟수는 줄이고 관측 주기는 촘촘하게 가져가는 운용이 실제로 가능할지는 다음 단계 시험 결과에 달려 있어요.

    확인된 것과 아직 불확실한 것

    확인된 것

    • MIT와 스위스 로잔의 EPFL 연구진이 날갯짓 방식의 공중·수중 비행체 FAAV를 설계했다.
    • 무게는 300g 미만이고, 동체(배터리·방수 전기 모터·크랭크축), 유연한 날개 두 장, 모터로 각도를 바꾸는 꼬리로 구성된다.
    • 날개는 얇은 막에 소수성 나노입자를 코팅해 물기를 털어내도록 만들었다.
    • 수조와 제네바 호수 실험에서 중간 크기 날개, 실제 새와 비슷한 속도·주파수, 70도 피치 조합으로 물→공기 전환이 가능했다.
    • 많은 잠수 조류와 달리 로봇은 발 없이도 수면에서 이륙했다.

    아직 불확실한 것

    • 비행·잠수 지속 시간, 배터리 용량, 도달 가능한 수심 같은 운용 수치는 원문에 나오지 않는다.
    • 70도 피치가 기체 전체 자세를 뜻하는지, 꼬리 자체의 각도를 뜻하는지는 원문만으로 구분하기 어렵다.
    • 측정 센서나 샘플 채취 장치를 어떻게 실을지는 소개되지 않았다.
    • ‘기존 방식 비용의 일부’라는 비용 절감 폭은 구체적인 수치로 제시되지 않았다.
    • 방향 전환 능력과 파도·바람 속 성능은 검증 전이며, 실제 해양 현장에 언제 투입될지도 정해지지 않았다.

    다음 관문은 방향 전환, 그리고 파도·바람

    연구진이 밝힌 다음 과제는 두 갈래입니다.

    • 방향 전환: 위아래로 퍼덕이는 것뿐 아니라 방향도 틀 수 있는 날개 설계
    • 거친 환경 시험: 출렁이는 물에서 헤엄치고 바람을 뚫고 날 때도 성능이 유지되는지 확인

    첫 번째 과제는 지금 구조를 보면 이해가 됩니다. 원문에 소개된 방식은 크랭크축이 정해진 주파수로 날개를 위아래로 움직이는 구조예요. 빙산이든 고래 무리든 원하는 지점까지 자유롭게 찾아가려면 선회 능력이 빠질 수 없어 보입니다.

    두 번째 과제는 시험 장소를 보면 이해가 돼요. 수조와 호수는 대체로 바다보다 잔잔한 조건입니다. 실제 바다에 투입하려면 반드시 넘어야 할 단계로 보이고, 연구진은 이 두 관문을 넘은 뒤 기체를 해양 과학의 실제 질문을 푸는 데 투입하겠다는 목표를 갖고 있어요.

    공중·수중 드론 소식이 또 나오면 세 가지만 따져 보면 됩니다.

    • 물과 공기 사이 전환이 얼마나 매끄러운가
    • 추진 장치를 얼마나 단순하게 묶었나
    • 파도와 바람 같은 실제 환경을 견디는가

    FAAV는 앞의 두 질문에 의미 있는 답을 내놨어요. 세 번째 칸은 아직 비어 있고, 그 칸은 다음 시험 결과로 채워질 겁니다.

    출처: MIT Tech Review AI

  • AI 해석가능성 논쟁…고양이·자동차 뉴런은 V자 감지

    AI 해석가능성 논쟁…고양이·자동차 뉴런은 V자 감지

    3줄 요약

    • 기계적 해석가능성은 AI 모델 내부의 뉴런과 회로를 직접 들여다보며 모델이 무엇을 계산하는지 밝히는 연구 분야다.
    • 이 분야에서는 한 뉴런이 서로 무관한 여러 개념을 함께 담는 ‘중첩’이 해석을 가로막는 핵심 장벽으로 여겨져 왔다.
    • Goodfire의 닉 캐머라타는 고양이와 자동차에 함께 반응하던 뉴런을 ‘V자 모양 감지’로 재해석하며 신경망이 생각보다 읽기 쉬울 수 있다고 주장했고, 스탠퍼드대 연구자는 직감 수준이라고 반박했다.

    고양이 얼굴, 옆에서 본 자동차의 앞부분, 당구대 모서리, 일본 고속열차의 뾰족한 앞코. 전부 한 이미지 인식 모델 안에서 같은 뉴런을 켜는 이미지다. 언뜻 봐선 아무 관계가 없는 조합이라, 이 뉴런은 무관한 개념을 한곳에 우겨 넣은 ‘엉킨 뉴런’의 대표 사례로 오래 통했다. 그런데 이 모델을 수천 시간 들여다본 연구자가 바로 그 해석을 자기 손으로 뒤집었다. AI 내부를 사람이 이해할 수 있느냐는 해묵은 질문이 다시 논쟁거리가 된 배경이다.

    이 논쟁을 따라가려면 용어 두 개는 먼저 잡고 가야 한다. 기계적 해석가능성(mechanistic interpretability)과 중첩(superposition). 이 둘이 머리에 들어오면 새 주장이 기존 관점의 어디를 건드리는지, 왜 한쪽에선 박수가 나오고 다른 쪽에선 ‘직감일 뿐’이라는 반박이 나왔는지, 이런 주장을 어떤 잣대로 따져봐야 하는지가 차례로 보인다.

    기계적 해석가능성은 출력이 아니라 뉴런과 회로를 읽는다

    요즘 AI 모델은 대부분 신경망 위에 서 있다. 신경망은 사람이 규칙을 한 줄씩 짜 넣는 프로그램이 아니다. 대량의 데이터로 학습하는 동안 수많은 가중치가 알아서 조정되고, 그렇게 생겨난 내부 구조는 만든 사람도 미리 알 수 없다. 연구자들 사이에서 “AI는 다리처럼 지어지는 게 아니라 정원처럼 길러진다”는 말이 도는 것도 그래서다. 코드를 짜는 입장에선 꽤 낯선 얘기다. 설계도 없이 결과물만 남는 소프트웨어인 셈이니까.

    기계적 해석가능성은 이렇게 길러진 구조를 거꾸로 뜯어보는 분야다. 출력만 보고 성능을 매기는 대신, 개별 뉴런이 어떤 입력에 반응하는지, 뉴런들이 어떻게 이어져 하나의 기능 단위인 회로를 이루는지를 직접 추적한다. 신경과학자가 MRI로 뇌 활동을 들여다보는 것과 닮은 접근이다. 개발자식으로 바꿔 말하면 블랙박스 테스트만 하던 대상을 화이트박스로 열어 보겠다는 시도. MIT 테크놀로지 리뷰가 이 접근을 주목할 10대 기술 가운데 하나로 꼽은 적도 있다.

    왜 이렇게까지 하느냐. 답은 감시와 통제다. 모델 안에서 벌어지는 일을 읽을 수 있으면 문제 행동의 징후를 출력이 나오기 전에 잡아내거나, 특정 기능만 골라 조정할 수 있다. 못 읽으면 결과물이 나온 뒤에 사후 판단하는 수밖에 없다. OpenAI와 Anthropic 같은 주요 기업이 만든 에이전트 무리가 통제 범위를 벗어나 공개 인터넷에서 혼란을 일으켰고, 정작 기업들은 그 사실을 제때 알아채지 못한 경우가 많았다는 사례가 잇따라 드러났다. 이 분야를 향한 요구가 한층 커진 이유다.

    뉴런 하나에 개념 여럿, ‘중첩’이 통설이 되기까지

    해석가능성 연구가 처음 그린 그림은 단순했다. 뉴런 하나가 개념 하나를 맡는다면, 뉴런마다 이름표만 붙여도 모델을 이해할 수 있다. 변수명만 제대로 붙어 있으면 코드가 술술 읽히는 것처럼. 아쉽게도 실제 모델은 그렇게 생겨 먹지 않았다.

    닉 캐머라타는 OpenAI 시절 개별 뉴런이 무엇을 나타내는지 탐색하는 도구를 개척하는 데 참여한 연구자다. 그와 동료들은 Inception v1이라는 작은 이미지 인식 모델을 분석하다가, 한 뉴런이 자동차 사진에도 고양이 사진에도 반응한다는 걸 발견했다. 연구진이 내린 결론은 이랬다. 모델이 더 많은 정보를 담으려고 일부 뉴런에 여러 일을 겸하게 한다. 다른 모델을 분석한 결과도 이 설명을 뒷받침하는 듯 보였다.

    용어를 정리하면 이렇다. 한 뉴런이 서로 무관한 여러 개념에 반응하는 성질이 다의성(polysemanticity)이고, 모델이 관련 없는 개념들을 뉴런 하나에 접어 넣는다는 설명이 중첩이다. 중첩이 맞다면 모델 내부는 거대한 매듭처럼 엉켜 있는 셈이고, 뉴런을 하나씩 들여다봐서는 의미를 읽어낼 수 없다.

    자연히 기계적 해석가능성 연구의 상당 부분이 이 매듭을 푸는 쪽으로 몰렸다. 엉킨 표현을 사람이 이해할 수 있는 단위로 분리하는 기법 말이다. 의미 있는 진전이 몇 차례 있긴 했다. 문제는 속도였다. 대형 언어 모델(LLM)은 규모도 복잡도도 워낙 커서 연구자들이 한 번에 이해할 수 있는 건 아주 작은 조각뿐이었다. 이 분야 주요 인물 가운데 일부는 LLM을 세밀한 수준까지 이해하는 게 애초에 가능한지 의문을 품었고, 캐머라타 자신도 “매우 비관적이었다”고 털어놓는다.

    캐머라타의 재해석, 고양이와 자동차를 묶은 건 ‘V자 윤곽’

    AI 스타트업 Goodfire로 자리를 옮긴 캐머라타는 1년 가까이 하루 10시간, 주 7일을 뉴런 관찰에 쏟았다고 한다. 새 분석 도구를 만들었고, AI 에이전트 팀을 붙여 관찰을 거들게 했다. 그 결과물이 2만 6천 단어짜리 블로그 글이다. 첫 문장은 “신경망의 본질에 관해 좋은 소식이 있는 것 같다”. 단정하지 않고 ‘것 같다’로 문을 연 점은 기억해 둘 만하다.

    그가 다시 꺼내 든 사례가 바로 Inception v1의 고양이·자동차 뉴런이다. 달라진 건 질문이었다. 예전엔 ‘왜 무관한 것들이 한 뉴런에 들어갔나’를 물었다면, 이번엔 ‘이것들의 공통점은 무엇인가’를 물었다. 답은 V자 모양. 고양이 얼굴도, 옆에서 본 자동차 앞부분도 뚜렷한 V자 윤곽을 갖는다. 캐머라타의 설명은 이렇다. 같은 이미지를 봤고 기술적으로 달라진 건 없었는데, 신경망이 패턴을 정의한다고 믿게 되자 다르게 보였으며, 알아차리는 데는 5초쯤 걸렸다고. 도구가 좋아져서가 아니라 보는 눈이 바뀌어서 보였다는 고백이다. 뒤에서 다룰 검증 기준과 바로 맞닿는 대목이니 기억해 두자.

    해석이 맞는지 확인하려고 그는 뉴런을 켜는 다른 이미지와 끄는 이미지를 함께 살폈다. 켜는 쪽에는 당구대 모서리, 일본 고속열차의 뾰족한 앞코, 갑판에서 물을 뿜어 올리는 소방정이 있었다. 뉴런을 억제한 이미지는 둥근 O자 모양이었다. 말하자면 ‘V의 반대’. 활성과 억제가 같은 기하학적 기준 하나로 설명된다는 점이 이 해석을 떠받치는 핵심 근거다. 켜지는 이미지만 모아 공통점을 찾았다면 그럴듯한 끼워 맞추기라는 의심을 피하기 어려웠을 것이다.

    구분 중첩 관점(기존 통설) 패턴 관점(캐머라타의 주장)
    고양이·자동차에 함께 반응하는 이유 무관한 개념을 한 뉴런에 접어 넣었기 때문 둘 다 두드러진 V자 윤곽을 갖기 때문
    연구자가 던지는 질문 왜 무관한 것들이 한곳에 섞였나 반응을 일으키는 대상들의 공통점은 무엇인가
    해석의 우선 과제 엉킨 표현을 분리하는 기법 개발 개별 뉴런을 더 오래, 더 많이 관찰
    대형 모델에 대한 전망 세밀한 이해가 가능할지 회의적 생각보다 이해·감시가 쉬울 수 있음
    근거의 성격 여러 모델 관찰로 뒷받침된 분야의 통설 블로그 글로 공개된 주장, 반론 존재

    캐머라타의 설명을 따르면, 모델이 고양이와 자동차를 같은 자리에 저장한 건 어떤 수준에서 둘이 똑같아 보이기 때문이다. 그는 이 경험을 계기로 신경망 전반을 잘못 이해하고 있었을 수 있다고 판단했다. “우리는 잘못된 방식으로 보고 있었다”는 말도 여기서 나왔다. 다른 뉴런들에서도 예상보다 많은 부분이 읽혔고, 회로 전체를 지도처럼 그려낼 수 있었다는 게 그의 주장이다. 단, 모든 뉴런이 깔끔하게 읽히지는 않는다는 건 본인도 인정했다. 이 단서를 흘려들으면 곤란하다. 읽히지 않는 뉴런이 얼마나 되느냐에 따라 주장의 무게가 크게 달라지기 때문이다.

    ‘과학사의 순간’과 ‘직감 수준’ 사이, 따져볼 잣대 네 가지

    블로그 글이 공개되자 반응은 극과 극으로 갈렸다. X에서 한 AI 연구자는 이 글이 “과학사의 중요한 순간으로 기억될 수 있다”고 썼고, 또 다른 연구자는 한 해를 통틀어 가장 중요한 AI 논문이라고 치켜세웠다. 정작 캐머라타는 사람들이 AI에 대한 생각을 이 정도로 바꿀 줄은 몰랐다며 놀라워했다.

    스탠퍼드대에서 LLM의 작동 원리를 연구하는 팀을 이끄는 크리스 포츠의 시선은 차갑다. 캐머라타가 공유한 내용은 직감 이상이 아니라는 평가다. 그는 “이 블로그 글의 어떤 부분도 문제를 더 쉽게 만들지 않는다”고 잘라 말했고, 소셜미디어의 유명 인사들이 이 글을 모든 걸 아우르는 돌파구처럼 떠받드는 분위기에도 의문을 표했다. 다만 인용된 발언만 놓고 보면 포츠가 구체적으로 어느 대목을 문제 삼는지는 드러나지 않는다. 찬사도 반박도 평가는 센데, 근거끼리 맞붙어 본 단계는 아직 아니라는 얘기다.

    어느 쪽 손을 들지 정하기 전에, 이런 종류의 해석가능성 주장을 읽을 때 쓸 만한 잣대 네 가지를 챙겨 두자.

    • 규모를 넘어서는가: 대표 사례는 작은 이미지 인식 모델에서 나왔다. 훨씬 크고 복잡한 LLM에서도 같은 방식이 통하는지는 따로 입증해야 할 문제다. 장난감 예제에서 돌던 코드가 프로덕션에서도 그대로 돈다는 보장이 없는 것과 같다.
    • 예측에 쓸 수 있는가: ‘V자 감지’라는 해석이 맞다면 처음 보는 이미지를 넣었을 때 뉴런이 반응할지 말지도 미리 맞힐 수 있어야 한다. 당구대·고속열차·소방정 사례는 그런 검증의 출발점일 뿐이다. 체계적인 예측 검증이 쌓여야 해석이 그럴듯한 이름표 이상의 가치를 갖는다.
    • 억제 조건까지 설명하는가: 뉴런을 켜는 이미지만 모으면 그럴듯한 공통점은 나중에 얼마든지 갖다 붙일 수 있다. 무엇이 뉴런을 끄는지까지 같은 논리로 설명되느냐가 해석의 신뢰도를 가른다. O자 모양에서 억제됐다는 관찰이 중요한 건 이 때문이다.
    • 관찰자의 믿음이 끼어들지 않았는가: 캐머라타는 초기 연구가 ‘신경망은 엉켜 있다’는 확증 편향을 낳았다고 지적한다. 같은 논리라면 ‘신경망은 패턴을 정의한다’는 새 믿음 역시 해석 방향을 끌고 갈 수 있다. 믿음이 바뀌자 같은 이미지가 다르게 보였다고 본인 입으로 말한 만큼, 다른 연구팀의 독립적인 재현이 꼭 필요하다. 네 가지 중 가장 아픈 지점을 꼽으라면 나는 이걸 고르겠다.

    API만 쓰는 기업과 오픈 가중치를 돌리는 팀, 체감이 다르다

    미리 말해 두면, 이건 연구 방법론을 둘러싼 논쟁이다. 당장 챗봇 화면에 새 버튼이 생기는 종류의 뉴스가 아니다. 국내 이용자와 기업이 받을 영향은 AI 모델을 어떤 방식으로 쓰고 있느냐에 따라 나눠 봐야 한다. 아래에서 ‘추정’으로 표시한 부분은 원문에 근거한 내용이 아니라 전망이다.

    • 챗봇 일반 이용자: OpenAI나 Anthropic의 서비스를 쓰는 방식은 그대로다. 해석가능성 연구가 안전 장치로 이어진다 해도 그 작업은 모델 개발사 내부에서 이뤄지니, 이용자 눈에 직접 보일 가능성은 낮다(추정).
    • API로 해외 모델을 연동하는 기업: 폐쇄형 모델은 API로 입력과 출력만 주고받을 수 있고, 내부 뉴런의 활성값에는 접근할 수 없다. 해석가능성 연구의 혜택은 개발사가 공개하는 분석이나 안전 기능을 거쳐 간접적으로만 돌아온다. 모델 내부를 직접 들여다볼 방법은 없다는 뜻이다.
    • 오픈 가중치 모델을 자체 운영하는 기업·연구실: 가중치를 내려받아 직접 돌리면 뉴런 활성값을 기록하고 분석할 수 있다. 캐머라타처럼 뉴런 관찰에 AI 에이전트를 투입하는 방식이 도구로 정리돼 공개된다면, 대규모 연구 조직이 없는 팀도 모델 내부를 점검해 볼 길이 열릴 수 있다(추정). 네 그룹 가운데 이 논쟁의 결론에 가장 직접 영향을 받는 쪽이다.
    • AI 에이전트를 업무에 도입하는 조직: 해석가능성 기반 감시가 실용화되기 전까지는 에이전트의 권한 범위 제한, 행동 로그 기록, 외부 접속 통제 같은 바깥쪽 통제가 기본이다. 개발사조차 자사 에이전트의 행동을 제때 파악하지 못한 사례가 있었으니, 이런 통제를 건너뛸 이유가 없다. 내부를 읽는 기술이 언제 나오든, 지금 해 둬야 할 일이라는 점은 그대로다.

    확인된 것과 아직 불확실한 것

    확인된 것

    • Goodfire 연구원 닉 캐머라타가 신경망이 기존 생각보다 이해하기 쉬울 수 있다는 2만 6천 단어 분량의 블로그 글을 공개했다.
    • 그는 Inception v1에서 고양이·자동차에 함께 반응하던 뉴런을 V자 모양 감지로 재해석했고, 같은 뉴런이 당구대 모서리·고속열차 앞코·소방정 이미지에 반응하고 O자 모양에는 억제된다는 관찰을 제시했다.
    • 캐머라타는 LLM을 비롯한 모델의 작동 방식을 완전히 이해했다고 주장하지 않으며, 모든 뉴런이 깔끔하게 읽히지는 않는다고 인정했다.
    • 스탠퍼드대 크리스 포츠는 이 주장이 직감 수준이며 해석 문제를 더 쉽게 만들지 않는다고 반박했다.

    아직 불확실한 것

    • 패턴 기반 해석이 작은 이미지 모델을 넘어 대형 언어 모델에서도 같은 수준으로 통하는지
    • 다의적으로 보이던 뉴런 가운데 얼마만큼이 공통 패턴으로 설명되고, 얼마만큼이 실제 중첩인지
    • 다른 연구팀이 같은 방법으로 독립적인 재현에 성공할 수 있는지
    • 이 접근이 AI 에이전트의 실시간 감시·통제 같은 실용 도구로 이어질지, 이어진다면 어떤 형태일지

    뉴런이 읽히면 AI 감시는 출력 이전 단계로 당겨진다

    캐머라타의 주장이 맞다고 치면, 가장 크게 바뀌는 건 AI를 감시하는 자리다. 출력만 보고 판단하는 방식은 문제가 겉으로 드러난 뒤에야 작동한다. 모델 내부 회로를 읽을 수 있다면 사정이 달라진다. 특정 행동과 연결된 뉴런 활동을 추적해, 출력이 나오기 전 단계에서 이상을 감지하는 접근을 설계할 수 있다. ‘이해하기 쉽다’는 말이 곧 ‘감시하고 통제하기 쉽다’는 말로 이어지는 이유다. 장애가 난 뒤 로그를 뒤지는 것과 실행 중에 브레이크포인트를 거는 것의 차이쯤으로 생각하면 된다.

    반대로 포츠의 지적처럼 이번 글이 실제 난제를 줄이지 못했다면, 해석가능성 연구는 매듭을 푸는 기존 경로를 계속 걸어야 한다. 눈여겨볼 건 두 관점의 출발점이 같다는 사실이다. LLM 내부를 세밀하게 이해한 사람은 아직 아무도 없다. 캐머라타가 동료 연구자들에게 건넨 조언은 단순하다. 조금 더 애써 보고, 너무 빨리 포기하지 말 것. 이 조언이 작은 이미지 모델을 넘어 대형 모델에서도 통할지는 재현 연구와 LLM 적용 결과가 쌓여야 판가름 난다. 그때까지는 V자 뉴런을 ‘가능성을 보여준 사례’ 정도로 받아들이는 게 가장 정직한 읽기라고 본다.

    출처: MIT Tech Review AI

  • AI 에이전트 막는 사이트들…아마존 이유는 광고

    AI 에이전트 막는 사이트들…아마존 이유는 광고

    3줄 요약

    • 개인 AI 에이전트는 사람을 대신해 기계 속도로 움직이는 ‘세 번째 웹 방문자’다. 봇과 사람을 가르던 기존 체계에 들어맞지 않아 많은 사이트가 막고 있다.
    • 보안에 민감한 사이트는 전면 차단을 택했고, 아마존은 광고 사업이 위협받는다며 법정 다툼까지 벌인다. 반대로 쇼피파이는 에이전트 전용 결제 통로를 열었다.
    • 웹이 에이전트 중심으로 바뀌면 사람은 잦은 인증, 사람마다 다른 가격, 광고가 섞인 추천을 겪을 수 있다. 에이전트에 일을 맡기기 전에 기준부터 세워두는 게 좋다.

    출시 첫 달 다운로드 500만 회. Meta의 개인 AI 에이전트 앱 Muse가 낸 성적이다. 에이전트가 일으키는 웹 트래픽은 한 달 사이에 세 배가 됐다. 여기에 OpenAI의 Dots 같은 앱이 가세하면서, 항공권 예약이나 호텔 검색을 사람 대신 처리하는 프로그램이 웹으로 대량으로 밀려들기 시작했다. 정작 이 손님을 반기는 사이트는 많지 않다. 가격 협상이나 여행 계획을 맡긴 에이전트가 사이트 입구에서 돌려보내지는 일이 흔하다.

    앱 하나의 흥행으로 끝날 얘기는 아니다. 에이전트가 왜 웹사이트에서 막히는지, 사이트들은 어느 방향으로 대응하고 있는지, 그 과정에서 사람 사용자는 무엇을 잃을 수 있는지는 Muse를 쓰든 Dots를 쓰든 똑같이 걸리는 문제다. 개념부터 순서대로 짚고, 에이전트에게 쇼핑이나 예약을 맡겨볼 생각이 있는 사람을 위해 판단 기준을 맨 끝에 붙였다.

    목적은 사람, 속도는 봇인 ‘세 번째 방문자’

    웹은 오랫동안 방문자를 둘로만 나눴다. 사람, 아니면 봇. 웹 페이지 내용을 수집하는 것처럼 자동화된 작업을 하는 봇은 허용하되, 어디까지 접근하고 어떻게 행동할지 규칙을 정해 관리해 왔다. 사람은 웹이 처음부터 염두에 둔 기본 사용자다. 가끔 캡차 퍼즐을 풀어 봇이 아님을 증명하는 정도의 수고만 감수하면 됐다.

    개인 AI 에이전트는 이 이분법 어디에도 깔끔하게 들어가지 않는다. 우선 사람이 아니다. 사람과는 비교가 안 되는 기계 속도로 웹을 돌아다닌다. 그렇다고 봇이라 부르기도 애매하다. 특정 개인을 대신해, 그 사람이 직접 했어도 아무 문제 없었을 정당하고 쓸모 있는 일을 하기 때문이다. 항공권 예약, 호텔 비교, 가격 협상 같은 일들. 사람과 다른 점은 사실상 속도 하나뿐이다. 에이전트를 사람과 봇 사이의 ‘세 번째 방문자’로 따로 봐야 한다는 시각은 여기서 나온다.

    구분 사람 기존 봇 개인 AI 에이전트
    움직이는 목적 본인의 필요 정해진 자동화 작업 특정 개인의 요청을 대행
    속도 사람의 속도 기계 속도 기계 속도
    대표적인 작업 탐색, 비교, 구매 웹 페이지 내용 수집 항공권·호텔 예약, 가격 협상, 환불 요청
    웹사이트의 대응 기본 사용자로 설계, 가끔 캡차로 확인 접근 범위와 행동 규칙을 정해 허용 맞는 규칙이 없어 차단하거나 별도 통로를 여는 중

    목적은 사람 쪽, 속도는 봇 쪽. 사이트 입장에서 보면 기존 분류표 어디에도 넣을 칸이 없는 손님이다. 표 마지막 줄의 ‘차단하거나 별도 통로를 여는 중’이라는 상태도 이 빈칸을 각자 다른 방식으로 메워 보려는 시도로 읽힌다.

    보안 때문에 닫고, 광고 때문에 소송까지 간다

    에이전트만 골라 걸러낼 장치가 따로 없으니, 보안에 민감한 플랫폼일수록 전면 차단 쪽으로 기울었다. 피자헛부터 옐프까지 여러 사이트에서 에이전트를 보냈다가 막혔다는 사용자 사례는 테크크런치가 전했다. 옐프는 아예 AI가 식당 예약을 하는 것 자체를 허용하지 않는다. 판단이 어려운 손님이면 일단 문부터 닫고 본다는 태도다.

    가장 크게 부딪친 곳은 아마존이다. 아마존은 Meta Muse의 에이전트를 차단했고, AI 스타트업 퍼플렉시티(Perplexity)의 에이전트를 막으려고 소송까지 벌이고 있다. 법원 판단은 퍼플렉시티에 유리하게 나왔다. 아마존은 항소했다. 불리한 판단을 받고도 물러서지 않았다는 점만 봐도, 아마존에게 이 문제가 가벼운 사안이 아니라는 건 분명하다.

    항소에서 아마존이 내세운 논리를 보면 문제의 핵심이 드러난다. AI 에이전트 때문에 사람이 본 광고와 봇에게 노출된 광고를 구분하기 어려워지고, 이것이 자사 광고 사업을 위협한다는 주장이다. 광고는 사람이 봐야 값이 매겨지는 상품이다. 화면을 본 주체가 에이전트라면 노출의 가치를 따지기 어려워진다는 계산으로 보인다. 눈여겨볼 대목은 보안이 아니라 광고가 전면에 나왔다는 점. 차단이 보안만의 문제가 아니라 플랫폼의 수익 구조와 맞물린 문제라는 뜻이다. 개발자라면 기억해 둘 만하다. 에이전트 차단 정책은 겉으로는 기술적 판단처럼 보여도, 실제로는 비즈니스 모델을 지키려는 선택인 경우가 많다.

    에이전트 트래픽 대다수는 쇼핑몰로 향한다

    지금의 차단은 얼리어답터 몇몇이 불편을 겪는 정도로 보인다. 펜실베이니아대 와튼스쿨의 이선 몰릭(Ethan Mollick) 부교수의 전망은 다르다. 이 문제가 곧 웹 전체로 번진다는 것이다. 에이전트로 환불을 요청하거나 가격을 흥정할 수 있다는 사실이 상식이 되면 에이전트 요청이 고객센터로 몰리고, 정작 사람은 고객센터를 쓸 수 없는 지경이 될 수 있다는 예측이다. 그는 링크드인에 “자기 에이전트가 대신 이런 일을 하지 못하게 막히면 사람들은 결국 몹시 짜증을 낼 것”이라고 적었다.

    사이트로서는 양쪽에서 압박이 들어오는 처지다. 에이전트를 받으면 운영이 버겁고, 막으면 사용자 불만이 쌓인다. 이 줄다리기의 결정적 변수는 돈이다. 에이전트가 만드는 웹 트래픽의 대다수가 전자상거래 사이트로 향한다. 실제 사람을 대신해 물건을 사려는 에이전트를 받아들이면 그만큼 매출 기회가 생기는 구조다. 에이전트 수요가 계속 늘면 플랫폼이 결국 이들을 들일 방법을 찾을 가능성이 크다.

    그쪽으로 이미 움직인 곳도 있다. 쇼피파이는 사람용으로 설계된 페이지를 거치지 않는 에이전트 전용 결제 통로(체크아웃 레인)를 열었다. 마트가 일반 계산대와 별도로 기업 고객용 창구를 두는 것과 비슷한 발상이다. 웹 구조로 보면 한 쇼핑몰 안에 사람용 화면과 에이전트용 통로가 나란히 놓이는 형태로 바뀌는 것이다. 에이전트 트래픽이 가장 많이 몰리는 전자상거래 안에서도 아마존은 막고 쇼피파이는 길을 냈다. 같은 업종에서 답이 정반대로 갈렸고, 아마존이 광고 사업을 이유로 들었다는 점까지 감안하면 차단 여부를 가르는 건 업종보다 각 플랫폼의 수익 구조 쪽에 가까워 보인다.

    사람용 화면 방치부터 차등 가격까지, 사람이 떠안을 네 가지 불편

    여기서부터는 확정된 사실이 아닌, 가능성 있는 시나리오다. 다만 앞의 흐름에 비춰 보면 충분히 따져볼 만하다. 웹은 갈수록 사람의 주의를 끌어 수익을 내는 쪽으로 설계돼 왔지만, 적어도 ‘의도된 사용자’는 사람이었다. 에이전트 수가 사람 수를 넘어서면 그 전제가 흔들릴 수 있다.

    • 사람용 화면의 방치: 사이트가 에이전트 응대에 집중하면, 직접 둘러보고 비교하려는 사람은 점점 손이 덜 간 화면을 만나게 될 수 있다.
    • 끝없는 사람 인증: 사람과 에이전트를 가르는 검증 시스템은 완벽하지 않다. 수시로 사람임을 증명하라는 요구를 받을 수 있고, 극단적으로는 홍채 스캔 같은 생체 인증까지 거론된다.
    • 사람마다 다른 가격: 같은 스웨터라도 모두에게 하나의 가격을 붙이는 대신, 각자의 에이전트에 서로 다른 가격을 제시하는 일이 가능해진다.
    • 보이지 않는 광고와 수수료: 에이전트가 추천한 상품이 광고나 플랫폼 수수료의 영향을 받았는지 사용자가 알아채기 어려워진다.

    네 가지의 공통점은 사용자가 직접 확인할 수 있는 정보가 줄어든다는 것이다. 사람이 화면을 볼 때는 가격표와 광고 표시를 눈으로 확인할 수 있다. 에이전트가 중간에 끼는 순간 그 과정은 블랙박스가 된다. 편리함과 투명성을 맞바꾸는 구조라는 점은 알고 쓰는 게 맞다. 네 번째 항목은 아마존의 항소 논리와 방향만 반대다. 아마존은 에이전트가 광고를 ‘보는’ 것을 문제 삼았지만, 사용자 쪽에서 더 신경 써야 할 건 광고가 에이전트의 추천 안으로 들어가 사람 눈에서 사라지는 경우다.

    아마존 직구에 에이전트를 붙이면 아마존 규칙을 따른다

    앞의 사례는 전부 미국 플랫폼 얘기다. 그래도 한국 사용자와 무관하지 않다. 아마존 직구나 해외 호텔·항공권 예약처럼 글로벌 사이트를 쓰는 일에 에이전트를 붙이면, 그 사이트의 에이전트 정책을 그대로 적용받는다. 특정 에이전트를 차단한 사이트에서는 작업이 중간에 멈출 수 있고, 같은 에이전트라도 사이트마다 되는 일과 안 되는 일이 갈린다. 아마존이 Muse 에이전트를 막았다는 사실은 직구 이용자에게 곧바로 해당되는 얘기다.

    국내 쇼핑몰과 예약 플랫폼의 선택은 해외 흐름에 비춰 짐작해볼 수 있다. 해외에서는 ‘전면 차단’과 ‘전용 통로 개설’ 두 갈래로 나뉘었으니, 국내 플랫폼도 비슷한 선택지를 놓고 저울질하게 될 것으로 추측된다. 광고 매출 비중이 큰 플랫폼일수록 아마존처럼 광고 노출 문제를 들어 신중하게 나올 가능성도 있어 보인다(추측).

    결제 정보 문제는 국경을 가리지 않는다. 에이전트가 웹을 돌아다니며 카드 정보를 여기저기 흘리는 상황은 소비자도 기업도 원하지 않는다. 에이전트 보안을 강화하는 규칙이 누구에게나 이득이라고 보는 이유다. 해외 결제가 걸린 직구라면 이 부분을 더 꼼꼼히 봐야 한다.

    확인된 것과 아직 불확실한 것

    확인된 것

    • Meta의 Muse는 출시 첫 달 500만 회 다운로드됐고, 에이전트 웹 트래픽은 한 달 새 세 배로 늘었다.
    • 옐프는 AI의 식당 예약을 허용하지 않고, 피자헛 등에서도 에이전트 이용이 막힌 사례가 있다.
    • 아마존은 Muse 에이전트를 차단했고, 퍼플렉시티 소송에서 불리한 판단이 나오자 항소했다. 항소 논리는 광고 사업에 대한 위협이다.
    • 에이전트 웹 트래픽의 대다수는 전자상거래 사이트로 향한다.
    • 쇼피파이는 사람용 페이지를 건너뛰는 에이전트 전용 결제 통로를 열었다.

    아직 불확실한 것

    • 기업이 자사 사이트에서 에이전트를 막을 수 있는지, 소비자를 위한 에이전트의 가격 협상을 막을 수 있는지에 대한 규칙
    • 아마존과 퍼플렉시티 항소심의 결과
    • 몰릭 교수가 예측한 고객센터 과부하가 실제로 벌어질지
    • 에이전트별 차등 가격이나 홍채 인증 같은 시나리오가 현실이 될지
    • OpenAI Dots와 Meta Muse를 한국에서 어디까지 쓸 수 있는지, 국내 플랫폼이 어떤 에이전트 정책을 택할지

    결제 승인은 직접: 에이전트에 맡기기 전 네 가지 기준

    규칙이 정해지기 전까지 사용자가 할 수 있는 일은 맡길 일과 직접 할 일을 나누는 것이다. 아래 기준을 먼저 세워두면 어떤 에이전트 앱을 쓰든 판단이 쉬워진다.

    • 결제 직전에는 사람이 확인하기: 검색과 비교까지는 맡기더라도 최종 결제 승인은 직접 하는 쪽이 안전하다. 에이전트가 카드 정보를 어디까지, 어떻게 다루는지 사용자 쪽에서 확인하기 어렵기 때문이다.
    • 추천 근거 묻기: 에이전트가 특정 상품을 골랐다면 왜 골랐는지, 광고나 제휴가 섞였는지 물어볼 것. 답이 모호하면 같은 상품을 직접 검색해 가격을 대조해 보는 게 좋다.
    • 막히면 우회하지 않기: 사이트가 에이전트를 차단했다면 그건 그 사이트의 정책이다. 차단을 피해 가려다 약관 위반 소지가 생길 수 있으니, 그 사이트에서는 직접 처리하는 편이 깔끔하다.
    • 에이전트가 잘하는 일부터 맡기기: 부당한 의료비 청구에 이의를 제기하거나 더 저렴한 자동차보험을 조사하는 일처럼, 자료를 많이 뒤지고 비교해야 하는 일은 에이전트가 소비자에게 실제로 힘이 되는 대표적인 쓰임새로 꼽힌다.

    구글, 앤트로픽, OpenAI는 에이전트가 소비자에게 더 큰 힘과 협상력을 줄 거라고 말한다. 허황된 약속은 아니다. 다만 그 약속이 실현될지는 에이전트가 웹사이트와 어떻게 상호작용하고 무엇까지 할 수 있는지에 대한 규칙에 달려 있다. 기업이 에이전트를 막을 수 있는지, 소비자를 위한 협상을 막을 수 있는지. 이 쟁점이 어느 쪽으로 정리되느냐에 따라 웹은 우리를 위해 일하는 에이전트의 고속도로가 될 수도, 우리에게 불리하게 움직이는 에이전트의 길이 될 수도 있다. 규칙이 어느 쪽으로 기울든 위의 기준을 세워 두고 쓰는 습관이 손해일 리는 없다. 그 쟁점을 법정에서 정면으로 다루는 사건이 바로 아마존과 퍼플렉시티의 항소심이다. 다음 판단이 어떻게 나오는지가 가장 가까운 가늠자가 될 것으로 본다.

    출처: MIT Tech Review AI