Command Palette

Search for a command to run...

AI가 루프를 닫는다는 말은 AI가 한 번 결과를 만드는 데서 끝나지 않고, 그 결과를 같은 시스템 안에서 검토하고 수정하고 다시 실행하는 구조를 만든다는 뜻이다.

질문은 이것이다.

AI가 생성한 결과를 같은 시스템 안에서 검토하고 수정하고 다시 실행할 수 있게 되면 무엇이 달라지는가?

나는 이 상태를 "루프가 닫힌다"고 부른다.

Claude Design 이야기를 들을 때 그 표현이 먼저 잡혔다. 그리고 AI for Science 이야기를 들으면서 같은 구조가 다른 도메인에도 있다는 생각이 들었다.

프론트엔드 도구든 과학 실험이든 핵심은 생성 능력만이 아니다. 중요한 것은 피드백이 다음 행동으로 돌아오는 경로가 같은 시스템 안에 있는지다.

루프가 열린 도구는 사람에게 맥락 이동을 맡긴다

기존 프론트엔드 작업을 생각해 보자.

Figma에서 시안을 만든다
-> 다른 도구로 HTML/CSS를 만든다
-> 브라우저에서 확인한다
-> 문제를 발견한다
-> 다시 디자인 도구나 코드로 돌아간다

각 단계는 가능했다. 문제는 단계 사이였다.

디자인 도구는 디자인을 만든다. 코드 생성기는 코드를 만든다. 브라우저는 결과를 보여준다. 하지만 "방금 본 결과가 의도와 다르다"는 판단과 "그럼 어디를 어떻게 고쳐야 한다"는 수정 맥락은 사람이 옮겨야 했다.

도구는 많았지만 루프는 열려 있었다.

생성
-> 검토
-> 수정
-> 재실행

이 네 단계가 한 시스템 안에 있지 않으면, 사람은 계속 맥락 운반자가 된다.

Claude Design은 프론트엔드 루프를 안으로 들인다

AI Frontier EP94에서 Claude Design 이야기가 나왔다.

처음에는 "Figma처럼 만들고 코드로 내보내는 도구" 정도로 들렸다. 하지만 그렇게만 설명하면 핵심이 빠진다.

핵심은 생성-검토-수정 루프를 한 컨텍스트 안에 넣는 것이다.

프롬프트로 UI를 만든다
-> 결과를 바로 본다
-> 같은 시스템 안에서 수정한다
-> 다시 결과를 본다
-> 필요하면 코드로 내보낸다

이전에는 wrapper 서비스들이 이 연결부를 만들었다. 모델 API 위에 UI 생성, 실시간 preview, 코드 export를 붙여서 루프를 닫았다. 그런데 모델 회사가 그 기능을 제품 내부로 들이면 외부 wrapper의 value proposition이 흔들린다.

노정석 대표가 말한 "밖에 있는 것들을 안으로 들인다"는 감각이 여기서 나온다.

모델이 강해질수록 단순 wrapper는 위험해진다. 모델이 아직 닫지 못한 루프, 즉 도메인 맥락과 승인과 평가가 필요한 루프를 잡아야 한다.

루프가 닫히면 피드백이 즉시 다음 입력이 된다

루프가 닫힌다는 말은 단순히 자동 반복을 뜻하지 않는다.

중요한 것은 출력이 다음 판단과 수정의 입력이 되는 구조다.

output
-> evaluation
-> correction
-> next input

이 구조가 같은 시스템 안에 있으면 피드백 주기가 짧아진다. 중간에 사람이 도구를 바꾸며 맥락을 옮기는 비용이 줄어든다.

프론트엔드에서는 결과물을 눈으로 볼 수 있다. 버튼이 너무 크다, 글자가 겹친다, 모바일에서 깨진다, 색 대비가 약하다 같은 평가가 즉시 가능하다.

그래서 Claude Design 같은 도구는 루프를 닫기 쉽다. 결과를 바로 보고 고칠 수 있기 때문이다.

하지만 모든 도메인이 그렇지는 않다. 어떤 도메인은 결과를 평가하기 어렵다. 어떤 도메인은 실험이 오래 걸린다. 어떤 도메인은 틀린 결과의 비용이 크다.

그래서 루프를 닫을 수 있는지 보려면 먼저 평가 가능성을 봐야 한다.

AI for Science도 같은 구조를 가진다

AI for Science 이야기를 들을 때 같은 패턴이 보였다.

생명공학, 신약 개발, 재료과학, personalized precision medicine 같은 영역은 원래 루프가 길다.

예를 들어 personalized medicine을 단순화하면 이런 흐름이다.

환자 데이터 수집
-> 유전체/임상 데이터 해석
-> 표적 또는 후보 치료 전략 설계
-> 실험 또는 임상 적용
-> 결과 수집
-> 다시 해석

각 단계 사이에 시간이 오래 걸린다. 특히 데이터 해석에서 후보 설계로 넘어가는 구간은 전문가의 암묵지가 크게 작동한다. 논문과 실험 결과와 임상 경험을 연결해야 한다.

AI가 이 중 일부를 메우면 루프가 짧아진다.

더 많은 문헌과 데이터를 읽는다
-> 후보를 좁힌다
-> 실험 전 예측을 만든다
-> 실험 결과를 다시 학습/검토에 넣는다

프론트엔드와 과학은 전혀 다른 도메인처럼 보인다. 하지만 구조는 닮았다.

생성
-> 검토
-> 수정
-> 다음 생성

차이는 평가 비용이다. UI는 빠르게 볼 수 있다. 과학 실험은 느리고 비싸다. 그래서 AI for Science에서 루프를 닫으려면 더 강한 verifier와 실험 설계가 필요하다.

Verifier가 없으면 닫힌 루프는 위험하다

루프를 닫는 것이 항상 좋은 것은 아니다.

평가 기준이 없는 루프는 잘못된 방향으로 빠르게 돈다.

AI가 코드를 만들고, 테스트도 없이 자기 코드가 맞다고 말하고, 그 결과를 다시 근거로 다음 코드를 만들면 위험하다. 과학에서도 마찬가지다. 모델이 그럴듯한 후보를 만들고, 검증 없이 그 후보를 다시 학습 신호처럼 쓰면 오류가 증폭될 수 있다.

그래서 루프를 닫을 때 가장 중요한 것은 verifier다.

생성기(generator)
검토기(verifier)
수정 경로(correction path)
실행/관찰 환경(environment)

이 네 가지가 있어야 루프가 생산적으로 돈다.

Claude Design에서는 사람이 화면을 보고 verifier 역할을 할 수 있다. 자동 visual regression이나 accessibility check가 붙으면 verifier가 더 강해진다.

AI for Science에서는 wet lab 실험, 임상 결과, 물리 시뮬레이션, benchmark, peer review가 verifier 역할을 한다.

AI alignment 연구에서 말하는 Automated Alignment Researcher도 결국 verifier 문제로 돌아간다. AI가 연구를 제안해도 그 결과가 맞는지 평가할 수 있어야 한다. 모델이 인간보다 강해지는 영역에서는 인간 verifier가 약해지는 문제가 생긴다.

루프를 닫는 기술은 평가를 함께 설계하지 않으면 위험해진다.

루프가 닫히는 곳이 새로운 제품 경계다

이 관점으로 제품을 보면 기회의 위치가 달라진다.

단순히 "AI로 무엇을 생성할 수 있나"를 묻는 것만으로는 부족하다.

질문은 이렇게 바뀐다.

어디에서 생성 결과를 바로 검토할 수 있는가?
어디에서 수정 결과를 다시 실행할 수 있는가?
어디에서 피드백이 다음 입력으로 자동 연결되는가?
어디에 신뢰 가능한 verifier가 있는가?

루프가 닫히는 곳에서는 생산성이 크게 오른다. 사람이 도구 사이를 오가며 맥락을 옮기는 시간이 줄어든다. 실패도 빨리 드러난다.

반대로 루프가 열려 있는 곳은 아직 사람의 작업이 많이 남는다.

승인
책임
도메인 판단
데이터 품질
외부 시스템 연결
실험 설계
규제와 안전

이 요소들은 모델이 커진다고 자동으로 사라지지 않는다. 오히려 좋은 제품은 이 요소들을 루프 안으로 조심스럽게 들인다.

Agent도 루프를 닫는 시스템이다

Chip Huyen의 agent 글들을 보면 agent를 단순히 "도구를 쓰는 LLM"으로만 보지 않는다. planning, tool selection, execution, evaluation, failure mode가 함께 있다.

이것도 루프 관점으로 볼 수 있다.

계획한다
-> tool을 고른다
-> 실행한다
-> 결과를 본다
-> 실패를 수정한다
-> 다시 계획한다

agent가 강해지려면 tool이 많기만 해서는 안 된다. 어떤 tool을 언제 써야 하는지, tool result가 맞는지, 실패했을 때 어떻게 복구할지 알아야 한다.

여기서도 verifier가 핵심이다.

코딩 agent라면 test, typecheck, lint, diff review가 verifier가 된다. 데이터 agent라면 query result validation, schema check, row count check가 verifier가 된다. 디자인 agent라면 screenshot, visual diff, accessibility check가 verifier가 된다.

루프를 닫는다는 말은 agent를 무작정 autonomous하게 만든다는 뜻이 아니다. 생성과 검토와 수정의 경로를 한 시스템 안에서 명확히 연결한다는 뜻이다.

정리

AI가 루프를 닫는다는 것은 생성 결과가 같은 시스템 안에서 검토되고, 수정되고, 다시 실행되는 구조를 만든다는 뜻이다.

Claude Design은 프론트엔드 생성-검토-수정 루프를 안으로 들인 사례로 볼 수 있다. AI for Science는 데이터-해석-후보 설계-실험-피드백 루프를 줄이려는 더 큰 사례다.

하지만 루프를 닫으려면 verifier가 필요하다. 평가 기준 없는 루프는 오류를 빠르게 증폭시킨다.

그래서 앞으로의 제품 기회는 단순 생성기가 아니라 닫힌 루프를 만드는 시스템에 있다.

생성할 수 있는가?
보다 중요한 질문은:
검토하고 고치고 다시 실행할 수 있는가?

LLM 공부 시리즈가 모델 내부를 이해하는 글이라면, 이 글은 그 모델이 제품과 과학과 agent 시스템 안에서 어떤 구조를 만들 수 있는지 보는 글이다.

이어 읽기

시리즈는 순서대로, 편집 추천은 맥락대로, 비슷한 주제는 태그 기준으로 정리합니다.