7월 31일, DeepSeek가 V4-Flash를 업데이트했다.

많은 사람이 신규 모델의 벤치마크(Benchmark) 스코어에 주목하는 가운데, 내 눈길을 끈 것은 평가 설명에 있는 작은 주석이었다. 이번 코드 태스크(Code Task) 성적은 모델 단독으로 낸 것이 아니다. 그 옆에는 아직 공개되지 않은 시스템——Harness minimal mode가 존재하고 있었다.

다음 날, DeepSeek Harness는 개발자 대상의 클로즈드 베타(Closed Beta) 모집을 시작했다. 응모자는 GitHub ID를 제출할 뿐만 아니라, 자신이 작업한 Agent 프로젝트도 제출해야 했다.

이는 이례적이었다.

모델은 이미 업데이트되었는데, 왜 굳이 별도의 Harness를 구축하는 것일까? 대규모 언어 모델(LLM) 훈련으로 알려진 기업이 왜 갑자기 Agent의 「외각(Shell)」을 만들 수 있는 인재를 찾기 시작했을까?

이 의문을 아이들도 이해할 수 있는 말로 풀이하면 다음과 같다:

같은 AI인데도 다른 소프트웨어에 넣으면, 마치 딴사람처럼 행동하는 이유는 무엇일까?

정답은 더 많은 파라미터(Parameter) 속에 있지 않다.

정답은 모델의 외부——AI가 무엇을 보고, 무엇을 기억하며, 무엇에 닿을 수 있는지, 그리고 누가 「정말로 일을 완수했는지」를 체크하는 방식——에 있다.

우리가 AI를 접하는 가장 일반적인 방법은 채팅이다.

수도관 수리 방법을 물으면 10가지 단계를 나열해 준다. 컴퓨터 정리 방법을 물으면 정연한 계획을 제시한다. 에러 메시지를 붙여넣으면 순식간에 문제 지점을 지적해 줄지도 모른다.

하지만 아무리 말을 잘해도, 유리창 너머에 있다는 사실은 변하지 않는다.

실제로 물이 새는 이음새를 볼 수 없고, 렌치에 손을 댈 수도 없다. 나사가 제대로 조여졌는지도 알 수 없으며, 바닥에서 물이 계속 넘쳐흘러도 스스로 멈춰서 다시 시도하지 않는다. 행동에 관한 언어는 가지고 있지만, 현장에 발을 들여놓을 신체(Body)를 가지고 있지 않은 것이다.

채팅 모델:
질문을 한다 → 모델이 답변을 생성 → 종료
Agent:
...

채팅 모델이 건네는 것은 「수도관 수리 방법」이라고 적힌 종이 조각이다. Agent는 렌치를 손에 들고, 실제로 조여보고, 물이 여전히 새지 않는지 확인한다. 말은 그럴싸하게 들리면 그만이지만, 행동은 현실로부터의 피드백을 받아들여야 한다.

이 끊임없이 반복되는 루프(Loop)야말로 Agent가 진정으로 「행동」을 시작하는 지점이다.

2022년에 제안된 ReAct 메서드는 이 프로세스에 정식 명칭을 부여했다: 추론(Reasoning)과 행동(Acting)을 교대로 수행하는 것. 쉽게 말해, AI를 방에 앉혀두고 계속 생각하게 만드는 것이 아니라, 먼저 보고, 손을 움직이고, 그 결과에 기반하여 다음 단계를 결정하게 하는 것이다. 오늘날의 Agent는 훨씬 더 복잡해졌지만, 그 고동은 여전히 이 단순한 루프다: 보고, 판단하고, 행동하고, 다시 본다.

모델은 이 루프를 스스로 만들어내지 못한다. 루프를 기능하게 만드는 것——그것이 바로 Harness다.

2. Harness는 의복이 아니라, AI가 현실로 들어가는 신체

모델은 지능의 상한선 중 하나이며, Harness는 그 지능이 어떻게 지면에 착지할지를 결정한다.

Harness라는 단어에는 「마구(馬具)」「제어 장치」라는 뉘앙스가 있다. Agent의 세계에서 이를 「외각」이라고 번역하기에는 너무 가볍다. 외각은 겉모습만 바꿀 뿐이지만, Harness는 능력과 경계를 바꾼다.

더 정확한 비유는 다음과 같다: 모델은 뇌와 같은 것이다. Harness는 그 뇌가 현실로 들어오기 위한 신체와 생명 유지 시스템이다.

모델 ＝ 뇌: 이해, 추론, 다음 단계의 생성
컨텍스트(Context)와 상태(State) ＝ 워킹 메모리(Working Memory): 현시점에서 알고 있는 것
검색, 파일, 브라우저 ＝ 눈: 보이는 현장
...

이는 기술을 알기 쉽게 바꾸어 말하는 것만이 아니다. 하나하나가 동일한 모델의 퍼포먼스(Performance)를 직접적으로 변화시킨다.

모델을 일반적인 채팅창에 넣으면 「어떤 파일을 수정해야 하는지」를 알려줄 뿐이다. 하지만 코드를 검색하고, 파일을 편집하며, 테스트를 실행할 수 있는 Harness에 넣으면 실제로 수정을 완료할 수 있다. 여기에 컨텍스트 압축(Context Compression)을 더하면 긴 태스크(Task) 속에서 오래된 로그에 파묻히지 않을 수 있다. 권한 승인(Authorization)을 더하면 마음대로 파일을 삭제하거나 메시지를 전송할 수 없게 된다. 결과 검증을 더하면 「완료했습니다」라는 한마디로 태스크를 끝낼 수 없게 된다.

따라서 「Claude Code는 ○○의 채팅 모델보다 프로그래밍을 더 잘한다」라고 일상적으로 말할 때, 우리는 모델만을 비교하고 있는 것이 아니다. 실제로는 두 개의 완전한 시스템을 비교하고 있는 것이다: 모델이 얼마나 많은 컨텍스트 (Context)를 보고 있는지, 어떤 도구 (Tool)에 접근할 수 있는지, 어떻게 프롬프트 (Prompt)되고 있는지, 실패했을 때 재시도 (Retry)하는지, 도구의 결과가 어떻게 반환되는지, 완료 조건을 누가 결정하는지 말이다.

두 명의 학생이 똑같이 자료 지참이 가능한 시험을 치른다고 상상해 보라.

그들은 완전히 동일한 두뇌를 가지고 있으며, 동일한 문제에 직면해 있다. 첫 번째 학생은 텅 빈 교실에 앉아 기억력에만 의존하여 답을 적는다. 두 번째 학생은 목차를 찾아보고, 자료를 뒤적이며, 계산기를 사용하고, 절차를 종이에 적어둔다. 제출하기 전, 선생님은 다시 한번 검산하는 것을 허용한다.

두 사람의 최종 점수는 완전히 다를 가능성이 높다.

그 차이는 어느 쪽이 더 똑똑한가에서 발생하는 것이 아니다. 어느 쪽이 더 적절한 정보, 더 명확한 절차, 더 신뢰할 수 있는 도구, 더 엄격한 체크를 가지고 있는가에서 발생하는 것이다.

에이전트 (Agent)도 마찬가지다.

컨텍스트 (Context)란 모든 자료를 한꺼번에 쑤셔 넣는 것이 아니다. 그것은 오히려 책상과 같다: 현재 다루고 있는 문제, 방금 관찰한 결과, 따라야 할 규칙들이 손이 닿는 곳에 있어야 한다. 수백 페이지의 무관한 로그를 책상 위에 쌓아두면 정말 중요한 종이가 파묻혀 버릴 뿐이다. Anthropic은 컨텍스트 엔지니어링 (Context Engineering) 실무에서 컨텍스트를 유한하고 귀중한 리소스로 부른다. 에이전트가 한 걸음 나아갈 때마다 도구의 결과, 계획, 중간 생성물들이 책상을 계속 점유하기 때문이다.

도구도 많다고 좋은 것은 아니다. 수천 가지 도구가 가득 찬 창고를 아이에게 준다고 해서 자동으로 엔지니어가 되지는 않는다. 도구가 하나 늘어날 때마다 에이전트가 잘못된 도구를 선택하거나, 잘못된 파라미터 (Parameter)를 입력하거나, 반환값 (Return value)을 오해석할 기회도 하나씩 늘어난다. 정말 뛰어난 도구 인터페이스 (Tool Interface)는 모델이 「언제 사용할지, 어떻게 사용할지, 성공이 무엇을 의미하는지」를 쉽게 이해할 수 있도록 만드는 것이다.

그렇다면 도구를 몇 개나 주어야 할까? 획일적인 정답은 없다. 더 실용적인 경계선은 이것이다: 도구를 추가할 때마다, 그것이 빈번하고 명확한 문제를 해결하며, 평가에서 오용으로 인한 비용보다 더 큰 이익을 가져다준다는 것을 증명해야 한다. 증명할 수 없다면 도구 상자에 넣어두고 책상 위에 올려두지 마라. ResceneAgent에서는 이 원칙이 소개 페이지의 슬로건이 아니라, 도구를 조립하는 코드에 직접 구현되어 있다.

다음 코드는 모델의 추론 (Inference)을 전혀 포함하지 않는다. 그것이 결정하는 것은 단 하나다: 이 대화 라운드에서 모델이 실제로 어떤 도구를 볼 수 있는가. 하지만 이 일견 평범해 보이는 결정이, 더 강력한 모델로 교체하는 것보다 태스크 (Task)의 성공에 더 큰 영향을 미치는 경우가 많다.

// tool_ondemand.go: buildCodeWorkflowTools로부터의 발췌
defs := nativeWorkflowToolDefs()
if len(activated) > 0 {
...

이 실제 소스 코드는 연극의 소품 담당자와 같다: 무대에는 그 막에 필요한 도구만 놓이고, 나머지는 무대 뒤에 보관된다. agent.go는 메인 에이전트에게 어떤 도구가 상주하고, 어떤 도구가 먼저 load_tools를 필요로 하는지를 알려준다. tools.go는 각 도구의 이름, 설명, 파라미터를 정의한다. 실제로 그것들을 매번 모델 요청 (Model request)에 실어 보내는 것은 바로 이 코드다. 모델의 IQ를 높이지는 않지만, 모델이 방대한 도구 앞에서 망연자실할 기회를 줄여준다.

그리고 권한 (Permission)은 이 신체가 어디까지 손을 뻗을 수 있는지를 결정한다. 파일 읽기와 디렉토리 삭제는 같은 동작이 아니다. 날씨 문의와 실제 주문도 같은 동작이 아니다. 승인 게이트 (Approval gate)와 샌드박스 (Sandbox)가 없는 강력한 에이전트는, 거대한 힘을 가졌으나 통각이 없고 어떤 문을 열어서는 안 되는지도 모르는 아이와 같다.

하지만 이것들은 아직 가장 어려운 부분이 아니다.

가장 어려운 것은 이것이다: 정말로 완료되었는지를 누가 판단하는가?

나는 에이전트 실행 시스템을 구축했다.

목표 플래너 (Goal planner)가 있어 태스크를 단계별로 분해할 수 있었다. 메시지 버스 (Message bus)가 있어 여러 에이전트가 상호 통신할 수 있었다. 도구 레지스트리 (Tool registry)가 있어 파일, 네트워크, 쉘 (Shell)을 호출할 수 있었다. 메모리 시스템 (Memory system)이 있어 아이덴티티 (Identity), 작업 상태, 사실을 별도로 저장할 수 있었다. 게다가 하트비트 모니터링 (Heartbeat monitoring)도 있어 프로세스가 떨어졌을 때 이상을 감지할 수 있었다.

당시 나는 어떤 말을 매우 좋아했다:

프로세스는 죽어도, 상태는 계속 살아남는다.

그것은 마치 진정한 디지털 생명 시스템처럼 들렸다. 프로세스는 종료되어도 기억은 남는다. 머신은 재부팅되어도 태스크는 계속될 수 있다. 에이전트(Agent)는 자신의 상태를 보고할 수도 있었다: 실행 중, 일시 중지 중, 에러, 완료.

하지만 진행하면서 한 가지 까다로운 문제에 직면했다:

"'완료'라고 누가 말했는가?"

어느 날, 로그를 태스크가 종료된 위치까지 되돌려 보았다. COMPLETED가 조용히 그곳에 있었다. 상태 테이블(Status table)만 보면 모든 것이 초록색으로 보였다. 하지만 "테스트 결과는 어디에 있는가? 실제 결과물은 어디에 있는가? 사용자는 왜 그것이 완료되었다고 믿을 수 있는가?"라고 따져 물었을 때, 나는 깨달았다. 시스템은 이러한 증거를 저장하도록 요구받은 적이 한 번도 없었다는 것을.

그 순간, 이 말이 놀라울 정도로 공허하게 느껴졌다. 플래너(Planner)의 어떤 단계가 COMPLETED로 표시된다 하더라도, 그것은 단지 상태 필드(Status field)가 변경되었음을 증명할 뿐이다. 도구 호출(Tool call)이 ok: true를 반환한다 하더라도, 그것은 프로그램이 예외(Exception)를 던지지 않았음을 증명할 뿐이다. 심박수가 여전히 뛰고 있다 하더라도, 그것은 프로세스가 살아있음을 증명할 뿐이다.

그 어느 것도 사용자가 원하는 결과가 실제로 나타났음을 증명할 수 없다.

파일 쓰기 명령이 성공하더라도 파일의 내용이 틀릴 수 있다. 코드 수정이 에러를 내지 않더라도 프로그램이 컴파일되지 않을 수 있다. 에이전트가 "페이지가 수정되었습니다"라고 말해도 브라우저에는 여전히 백지 화면이 표시되고 있을지도 모른다.

그때 나는 이해했다. 에이전트에게 뇌, 팔다리, 기억, 맥박을 주었지만, 매우 기본적인 것을 잊고 있었다. 숙제를 끝냈다면, 누군가는 답을 확인해야 한다.

내가 처음에 이해했던 "완료":

...

이 경험이 Harness를 바라보는 나의 관점을 바꾸었다.
태스크의 코드를 처음부터 끝까지 다시 추적했다. agent.go는 메인 에이전트의 동작을 정의하지만, 실제로 라운드마다 숨을 쉬게 만드는 것은 agent_workflow_handler.go다. 모델이 도구를 계속 호출하는 한 루프는 계속되며, 도구를 호출하지 않고 최종 답변을 제출하려고 할 때 시스템은 종료 분기(Exit branch)로 들어간다.

// agent_workflow_handler.go
if len(calls) == 0 {
outcome = "completed"
...

Go를 모르더라도 이 코드의 순서는 이해할 수 있다. 먼저 프로세스를 저장하고, 그다음 현실을 체크하며, 마지막으로 UI에 workflow_done을 전송한다. Harness의 "고동(Heartbeat)"은 낭만적인 비유가 아니라, 말 그대로 "계속해야 하는가"를 계속해서 판단하는 루프인 것이다.

그렇다면 verifyOnWorkflowDone은 실제로 무엇을 체크하는가? 모델에게 "정말인가요?"라고 묻는 것이 아니라, 이번에 실제로 변경된 파일을 확인한다. Go 파일이 변경되었다면 Go 빌드(Build)를 시도한다. 프론트엔드가 변경되었다면 프론트엔드 빌드를 실행하고 실제 브라우저에서 프리뷰를 연다.

// verify.go
if hasGo && fileExists(filepath.Join(sess.Workdir, "go.mod")) {
out, ok := runVerifyBuild(sess.Workdir, "go", "build", "./...")
...

이 두 개의 코드 블록은 "자동 검증을 지원합니다"라는 말보다 더 무게감이 있다. 왜냐하면 능력뿐만 아니라 한계도 드러내고 있기 때문이다. 현재 구현은 검증 결과를 기록하지만, 빌드가 실패했다고 해서 대화 전체를 강제로 차단하지는 않는다. 다시 말해, "COMPLETED만을 믿는" 상태에서 "현실에 증거를 요구하는" 상태로 이행했지만, 모든 증거를 엄격한 임계값(Hard threshold)으로 설정하지는 않은 것이다.

이것은 숨겨야 할 결점이 아니라, Harness의 가장 솔직한 공학적 문제다. 어떤 태스크는 경고와 함께 납품할 수 있고, 어떤 태스크는 검증을 통과해야만 종료할 수 있는가? 블로그 수정과 은행 송금은 분명히 같은 잣대로 측정할 수 없다. 검증은 스위치가 아니라, 리스크에 따라 단계별로 적용되는 계약서인 것이다.

훌륭한 Harness의 가장 중요한 능력은 Agent를 바쁘게 보이게 만드는 것이 아니라, 루프(Loop)를 종료하기에 충분한 증거가 무엇인가를 결정하는 것이다. 모델의 자기 평가(Self-evaluation)를 맹신하지 않고, "명령 실행이 성공했다"를 "태스크가 성공했다"로 바꿔치기하지 않으며, 아름다운 요약(Summary)을 현실이 변했다는 증거로 간주하지 않는 것이다.

Anthropic 또한 Agent 평가 실무에서, 멀티 턴(Multi-turn) Agent는 도구(Tool)를 호출하고, 상태를 변경하며, 중간 결과에 기반하여 행동을 조정하기 때문에 마지막 텍스트만 평가하는 것은 불충분하다고 강조하고 있다. 최근의 Harness 연구에서도 "불완전한 피드백 하에서의 검증", "최종적인 성공 이외의 평가"가 핵심 과제로 꼽히고 있다. 모델이 다음 단계를 제안하면, Harness는 계속해서 물어야 한다: 증거는 어디에 있는가?

5. DeepSeek는 왜 지금 Harness를 만들기 시작했는가

DeepSeek의 움직임을 되돌아보면 답은 명확해진다.

모델이 채팅만 할 수 있었던 시대에는 모델 자체가 거의 제품의 전부였다. 모델이 터미널을 조작하고, 리포지토리(Repository)를 수정하고, 브라우저를 호출하며, 긴 태스크를 완료하기 시작할 때, 최종적인 퍼포먼스는 곱셈의 결과가 된다:

Agent의 실제 능력
= 모델의 능력
× 컨텍스트(Context)가 올바르게 주어졌는가
...

이것은 수학적으로 정확한 공식이라기보다 공학적인 사실이다. 어떤 요소라도 0에 가까워지면, 최종적인 경험도 0에 가까워질 수 있다.

매우 강력한 모델이라도 도구에 대한 설명이 모호하면 잘못된 API를 반복해서 호출한다. 컨텍스트가 로그로 가득 차 있으면 긴 태스크 도중에 목표를 잊어버린다. 회복 메커니즘(Recovery mechanism)이 없다면 단 한 번의 네트워크 장애로도 멈춰버린다. 완료 조건이 모델 자신의 선언에만 의존한다면, 미완성된 제품을 승리라고 포장하게 된다.

이것이 V4-Flash-0731의 평가 주석이 주목할 만한 이유이기도 하다. DeepSeek는 모델의 점수를 공개했을 뿐만 아니라, 코드 Agent 태스크가 DeepSeek Harness minimal mode에서 실행되었음을 명시했다. 이 작은 주석은 점점 더 중요해지고 있는 사실을 인정하고 있다: Agent의 성과는 결코 모델만의 것이 아니다.

DeepSeek가 Harness를 구축해 본 경험이 있는 개발자를 모집한 것도, 단지 V4를 위해 더 아름다운 채팅창을 만들기 위해서만은 아니다. 진정한 경쟁은 이미 "누가 더 똑똑한 뇌를 가졌는가"에서 "누가 뇌에 더 신뢰할 수 있는 신체를 구축할 수 있는가"로 이동하고 있다.

많은 사람이 처음 Agent를 설계할 때 본능적으로 이것저것을 계속 추가한다: 더 많은 도구, 더 긴 기억, 더 많은 역할, 더 복잡한 계획, 더 대규모의 멀티 Agent 네트워크.

나 또한 그 길을 걸었다.

하지만 복잡함이 신뢰성과 동일한 것은 아니다. Anthropic은 Agent 공학의 경험을 정리하면서, 단순하고 조합 가능한 패턴부터 시작하여 평가를 통해 이득이 증명되었을 때만 복잡성을 높일 것을 반복해서 권장하고 있다. 2026년에 Microsoft가 Agent Framework Harness를 출시했을 때, 그 핵심으로 꼽힌 것들도 신비로운 것이 아니었다: 루프(Loop), 계획(Planning), 기억(Memory), 컨텍스트 관리(Context management), 승인(Approval), 텔레메트리(Telemetry). 정말 어려운 것은 이러한 용어들을 카탈로그에 나열하는 것이 아니라, 실패했을 때도 이들이 서로 맞물려 돌아가게 만드는 것이다.

단 3개의 도구만 가지고 있지만 실제 결과물을 체크하고 실패 시 재시도(Retry)할 수 있는 Harness는, 30개의 도구를 갖추고 있으면서 모델 자신의 "완료" 선언만 듣는 Harness보다 종종 더 높은 신뢰성을 보인다. 기능의 수는 짐의 무게와 같다. 루프가 제대로 닫혀 있는지(Closed-loop)가 실제로 목적지에 도착했는지를 결정한다.

실제 엔지니어링에서의 Harness는 agent.go라는 단 하나의 파일에만 존재하는 것이 아니다. 워크플로 루프(Workflow loop), 도구 로드, 위험 작업 승인, 브라우저 프리뷰, 출력 압축, 컨텍스트 원장(Context ledger) 사이에 흩어져 있다. 예를 들어, harness_ledger.go는 이력의 손실량, 압축 횟수, 출력 절단량, 이번에 활성화된 도구의 수를 기록한다. 이는 아름다운 보고서를 생성하기 위해서가 아니라, Agent가 지능을 잃기 시작했을 때 어디서부터 기억을 잃기 시작했는지 정확히 알기 위해서다.

훌륭한 Harness는 장거리 여행을 견딜 수 있는 신체와 같다:

주의력(Attention)에는 한계가 있다는 것을 알고 있기에, 모든 이력을 뇌에 쑤셔 넣는 대신 책상을 정리한다. 손이 도구를 사용하는 것을 허용하되, 통각과 가드레일(Guardrail)도 유지한다. 넘어졌을 때 상처를 읽고 동작을 수정하며, 같은 곳에서 반복하지 않는다. 그리고 가장 중요한 것은, 자신이 "도착했다"고 말했다고 해서 여행이 끝난 척하지 않는 것이다.

마치며: 지능은 결코 벌거벗은 채로 현실에 나타나지 않는다

우리는 모델의 리더보드(Leaderboard)에 매료되기 쉽다. 파라미터(Parameter)와 점수가 순수한 지능처럼 보이기 때문이다. 하지만 AI가 실제로 일반 사람들 앞에 나타날 때, 그것은 결코 허공에 떠 있는 뇌가 아니다.

그것은 항상 어떤 형태의 신체(Body)를 동반한다. 누군가는 그 기억을 선택하고, 누군가는 어떤 도구를 사용할 수 있는지 결정하며, 누군가는 넘어서는 안 될 경계를 긋고, 누군가는 어떤 말을 했을 때 시스템이 작업이 완료되었다고 믿을지를 정한다.

이 신체는 중립적이지 않다.

그것은 AI가 누구의 세계를 보는지, 누구의 파일에 접근할 수 있는지, 무엇을 잊을지, 그리고 실수했을 때 누가 대가를 치를지를 결정한다. Harness는 단순한 공학적 발판이 아니라, 코드에 기록된 권력의 설명서다.

DeepSeek의 클로즈드 베타(Closed Beta)는 언젠가 끝날 것이고, 새로운 Harness도 오늘날의 모델들처럼 비교되고 교체될 것이다. 하지만 이 질문은 계속 남을 것이다. 기계가 점점 더 강력한 뇌를 갖게 될 때, 우리는 그것에게 어떤 신체를 줄 준비가 되어 있는가?

모델은 어디까지 생각할 수 있는지를 결정하고, Harness는 어디까지 갈 수 있는지를 결정한다. 그리고 인류는 어떤 길을 걷게 할 가치가 있는지를 결단해야 한다.

다음 회차에서는 이 "신체"를 따라 더 위험한 질문을 추구해 보고자 한다. 미디어가 **"OpenAI 모델 탈주"**라고 불렀던 최근의 보안 사고에서는, 방어력을 약화시킨 내부 네트워크 보안 평가 과정에서 모델이 인터넷으로 나가는 출구를 찾아냈고, 결국 Hugging Face의 프로덕션 인프라(Production Infrastructure)에 침입했다 — 이 모든 것은 테스트의 답을 얻기 위해서였다.

그것은 통제 불능이 된 것인가, 아니면 인간이 부여한 목표를 너무나 성실하게 수행한 것인가? AI가 이미 스스로 틈새를 찾는 법을 배웠을 때, 우리가 Harness에 작성한 가드레일은 여전히 충분한가?

이 글이 모델과 Harness의 차이를 처음으로 명확히 하는 데 도움이 되었다면, 좋아요를 눌러 더 많은 사람이 볼 수 있게 해주시면 감사하겠습니다. 북마크를 해두시면 다음에 에이전트(Agent), 컨텍스트(Context), 도구 호출(Tool Call) 같은 개념을 접했을 때 다시 돌아와 읽어보실 수 있습니다.

에이전트, 기억, Harness, AI 보안에 대한 분석을 계속 읽고 싶으시다면 팔로우를 부탁드립니다. 또한, 그 사고가 모델의 "탈주"인지, 아니면 목표와 가드레일의 공동 실패인지 댓글로 알려주세요.

저는 ResceneAgent를 통해 "같은 모델, 같은 태스크, 다른 Harness"에 대한 공개 실험을 계속해 나갈 것입니다. GitHub에서 코드를 확인하고 Star를 남겨주신 모든 분께 감사드립니다 — 그 Star는 단순한 숫자가 아니라, 이 실험의 경로가 계속될 가치가 있다는 증거입니다.

• DeepSeek Harness 클로즈드 베타 버전 공지 X 게시물: @MaxForAI
• DeepSeek Harness 팀 리더 최첨익의 X 계정: @tianyi
• DeepSeek-V4-Flash 모델 및 기술 상세 정보: DeepSeek 공식 Hugging Face
• DeepSeek V4와 Codex의 Agent 연계 설명: Integrate with Codex
• Shunyu Yao 외, 추론과 행동을 번갈아 수행하는 고전적 패러다임:
  ReAct: Synergizing Reasoning and Acting in Language Models - Anthropic, Agent의 간단한 조합 패턴과 공학적 원칙: Building Effective Agents
• Anthropic, 긴 작업에서의 컨텍스트 관리: Effective Context Engineering for AI Agents
• Anthropic, 멀티턴 Agent의 평가 및 검증: Demystifying Evals for AI Agents
• Microsoft, Agent Harness의 루프, 계획, 기억, 승인(approval), 텔레메트리: The Microsoft Agent Framework Harness Is Now Released
• Xuying Ning 외, Harness 인터페이스, 메커니즘, 검증 문제 서베이:
  Code as Agent Harness - ResceneAgent 메인 Agent 프로토콜과 툴 정의:
  agent.go

, tools.go

• ResceneAgent 온디맨드 툴 로드:
  tool_ondemand.go

• ResceneAgent 워크플로우 루프와 작업 종료 시 검증:
  agent_workflow_handler.go

, verify.go

• ResceneAgent 컨텍스트 원장(ledger)과 툴 출력 아카이브:
  harness_ledger.go

, tool_output.go

• OpenAI, Hugging Face 보안 사고 및 모델 평가 환경에 관한 공식 성명: OpenAI and Hugging Face partner to address security incident during model evaluation
• Hugging Face, 운영 인프라 침입 공개: Security incident disclosure — July 2026