현장에 출근한 AI, 신뢰의 조건은 기록과 규율이다

01TREND 01 · BIM × SITE질의응답 문서에, 에이전트가 출근한다⁠↗

RFI(Request for Information·질의서)는 건설 프로젝트에서 가장 흔하고 가장 느린 문서 중 하나입니다. 질문 하나에 답하기 위해 담당자가 도면·시방·회의록을 뒤지는 시간이 쌓여 공정 지연의 단골 원인이 됩니다. 건설관리 플랫폼 PlanRadar가 8월 20일 정식 공개한 AI 에이전트는 바로 이 지점을 겨냥합니다. 에이전트가 수신된 RFI를 읽고, 프로젝트 문서를 검색해, 근거 출처를 밝힌 답변 초안을 만들어 몇 시간 걸리던 응답을 몇 분 단위로 줄입니다.

주목할 것은 속도보다 통제의 설계입니다. 에이전트의 실행 범위는 그것을 만든 사용자의 권한을 넘지 못하도록 사전 검증되고, 모든 행위는 특정 사용자 이름으로 로그에 남습니다. 배포 전에 에이전트의 행동을 미리 볼 수 있고, 자연어 지시만으로 팀 고유의 에이전트를 만들 수 있습니다. 전 요금제에 기본 포함으로 풀렸다는 점은 이런 기능이 프리미엄 옵션이 아니라 플랫폼의 기본값이 되고 있다는 신호입니다.

설계사무소 입장에서는 두 가지를 볼 만합니다. 하나는 시공 단계 커뮤니케이션의 응답 속도가 빨라질수록 설계 문서의 품질 — 검색 가능하고, 근거를 추적할 수 있는 문서 체계 — 이 그대로 에이전트의 성능이 된다는 점입니다. 다른 하나는 ‘권한 한도 내 실행 + 전 행위 기록’이라는 설계가, 사무소가 자체 자동화를 도입할 때 그대로 가져다 쓸 수 있는 신뢰 모델이라는 점입니다.

02TREND 02 · AI SECURITY짠 것도 AI, 뚫은 것도 AI였다⁠↗

자동 생성 코드의 안전성 논쟁은 오래됐지만, 지금까지는 대체로 가정법이었습니다. 8월 17일 공개된 사건은 이것을 실증으로 바꿨습니다. 보안사 Wiz의 자율 레드팀 에이전트가 Snowflake의 공개 저장소에서 명령 주입 취약점을 찾아냈고, 이를 따라 들어가 내부 업무 시스템까지 닿는 침투를 시연했습니다. 문제로 지목된 코드가 GitHub Copilot의 자동 수정(Autofix) 기능이 공동 작성한 것이었다는 점이 사건의 성격을 바꿨습니다.

GitHub은 자동 수정이 취약점을 ‘만들었다’는 서술에 반박했고, 책임 소재를 둘러싼 공방이 이어지고 있습니다. 논쟁의 결론과 무관하게 구조는 분명해졌습니다. 코드를 쓰는 쪽에도, 뚫는 쪽에도 이미 자율 에이전트가 투입되어 있으며, 사람의 검토가 빠진 자리에서 두 자동화가 직접 만났다는 사실입니다. 취약점을 만든 쪽과 찾아낸 쪽이 모두 AI였던 첫 대형 사례로 기록될 것입니다.

건축 실무로 옮기면 이것은 소프트웨어 회사만의 이야기가 아닙니다. 파라메트릭 스크립트, BIM 자동화 매크로, 협업 플랫폼의 자동 응답 — 설계사무소가 AI에게 맡기는 산출물도 결국 ‘검증 없이 반영된 한 줄’의 문제를 공유합니다. 생성은 넘겨도 책임은 넘길 수 없다는 것, 그래서 AI 산출물의 검증 절차를 문서화해 두는 것이 곧 사무소의 방어선이라는 것이 이 사건의 실무적 결론입니다.

03TREND 03 · AI × DATA데이터를 남기지 않는 계약이 온다⁠↗

설계사무소가 클라우드 AI 앞에서 머뭇거리는 가장 큰 이유는 성능이 아니라 데이터였습니다. 비밀유지협약(NDA) 아래의 프로젝트 정보를 외부 서버에 올리는 순간, 그 데이터가 어디에 얼마나 남는지 답할 수 없었기 때문입니다. OpenAI가 8월 19일 발표한 제로 데이터 보존(Zero Data Retention·ZDR)은 이 질문에 대한 계약 언어를 제시합니다. 요청 처리가 끝나면 프롬프트와 응답을 서버에 남기지 않고, 기업 데이터는 명시적 동의 없이 학습에 쓰지 않는다는 약속입니다.

구조도 공개됐습니다. 보관이 필요한 콘텐츠는 고객 인프라에 두거나 고객이 쥔 키로 암호화해 저장하고, 안전성 감시는 내용 전체가 아니라 제한된 위험 신호만 읽는 방식(Private Safety Processing)으로 수행합니다. 기술 백서와 정식 롤아웃은 9월로 예고됐습니다. 아동 착취물 등 법정 신고 의무 대상은 예외로 보존된다는 조건도 명시됐습니다.

실무 시사점은 명확합니다. 지금까지 사무소가 기밀 프로젝트에 AI를 쓰려면 ‘보내지 않는’ 방법 — 온프레미스, 오픈소스 — 밖에 없다고 여겨졌지만, 이제 ‘보내되 남기지 않게 하는’ 계약 조항이 선택지에 들어왔습니다. 클라우드 AI 도입 검토서에 ZDR 지원 여부, 암호화 키의 소재, 학습 사용 배제 조항 세 줄을 추가할 시점입니다. 데이터 주권은 이제 인프라의 문제이기 전에 계약서의 문제입니다.

04TREND 04 · AI GOVERNANCE능력이 임계에 닿자, 속도를 늦췄다⁠↗

프런티어 AI의 능력 평가는 지금까지 대체로 ‘출시 전 검사’의 문제였습니다. 모델을 다 만들어 놓고 위험을 재고, 통과하면 내보내는 순서였습니다. OpenAI가 8월 18일 공개한 입장문은 이 순서를 뒤집습니다. 차기 모델이 사이버 보안 부문에서 ‘임계(Critical)’ 능력 문턱에 닿을 수 있다는 내부 판단이 나오자, 출시가 아니라 개발 그 자체의 속도를 조절 대상으로 삼았다고 밝혔기 때문입니다.

공개된 조치는 구체적입니다. 최신 모델 계열의 강화학습(RL) 훈련을 2주간 중지했고, 계획했던 최대 규모의 프런티어 훈련은 소규모 평가가 끝날 때까지 보류 상태입니다. 신뢰할 수 없는 코드 실행을 격리하는 샌드박스와 네트워크 분리를 강화했고, 이상 징후를 30분 안에 경보하는 다단계 감시 체계를 일정 능력 이상의 모든 훈련·평가에 의무화했습니다. 이 감시에 들어가는 비용이 추론 연산의 약 20%로 추산된다는 수치도 함께 공개됐습니다.

설계사무소 관점에서 이 발표는 두 가지를 시사합니다. 첫째, 우리가 쓰는 도구의 능력 향상 속도는 앞으로 기술 곡선이 아니라 운용 규율에 의해 계단식으로 움직일 수 있습니다. 도입 계획을 ‘다음 모델이 나오면’이 아니라 ‘지금 모델로 무엇을 정착시킬까’에 두는 편이 합리적입니다. 둘째, 감시에 연산의 20%를 쓰는 회사가 프런티어의 표준이 된다면, 사무소 내부의 AI 운용에도 같은 질문이 돌아옵니다 — 우리는 산출물 검증에 업무 시간의 몇 %를 배정하고 있는가.

CARD EDITION

인스타그램·모바일용 카드 6장 — 누르면 원본 크기로 열립니다.