Amazon의 AI 프로덕션 엔지니어와 대화해 본 경험이 있음, 그분이 말하길 현재 어떤 회사도 고객과 직접 대화하는 곳에 생성형 AI만 사용하는 경우가 전혀 없다고 함, 모든 자동응답은 예전의 비생성형 "구식" 기술을 사용한다고 함, 생성형 AI의 신뢰성 문제가 기업의 명성에 걸 stake를 맡길 수 없을 만큼 큼
예전에는 "구식 AI" 상징적 기법과 전통적인 머신러닝을 결합하는 에이전트에 관심이 많았음, 하지만 주로 프리-트랜스포머 신경망에서 일하게 됐음, 결국엔 항상 인간이 개입하는 시스템을 먼저 만들고 평가 및 훈련 데이터를 수집함, 그런 뒤 시스템이 업무 일부를 맡아서 나머지 품질까지 같이 향상시키는 흐름임, 특히 '주관적' 작업에서는 심볼릭 시스템도 반드시 평가해야 함, 만약 시스템을 훈련시켜야 한다면 평가를 못 피함
실제로 많은 테크 기업이 이미 생성형 AI를 실시간 챗봇 고객지원에 도입 중임, Sonder와 Wealthsimple 같은 곳을 알고 있음, LLM이 쿼리에 답을 못 할 경우엔 대화를 바로 인간 상담사에게 넘김
아직 논의되지 않은 점이 맥락 창(context window)에 대한 것임, 인간은 전문 분야에서 사실상 "거의 무한대"에 가까운 맥락을 다룰 수 있음, 모델은 더 크고 다양한 학습 데이터로 어느 정도 한계를 극복할 수 있지만 진정한 해결책은 아니라는 생각임, 현재는 사람들이 자신만의 맥락을 프롬프트에 담아 압축해야 하기에 영어처럼 유연한 언어에서는 공학보다는 마법주문 외우기나 추측 같은 느낌임, 결정론적 방식 대신 데이터의 많은 부분을 잃는다고 느끼는 중임
인간은 "맥락"과 "가중치"가 나뉘어 고정적으로 구분되어 있지 않음, 시간에 따라 경험과 결과가 내 "가중치" 자체를 계속 바꾸는데 LLM은 아키텍처상 가중치가 읽기 전용이라 불가능함
인간이 정말 그렇게 거대한 맥락 창을 가지고 있냐는 회의가 있음, 나는 내 복잡한 문제 해결 시 인간 고유의 "맥락 창" 한계에 자주 부딪힘, 실제로 그런 예시가 있는지 궁금함
나는 AI툴 사용 경험이 대체로 긍정적이었음, 쉬어야 할 때 소규모 작업을 맡기거나, 업무를 정리 및 시동시키는 데 큰 도움이 됨, 하지만 비용 이슈가 금방 생김, 예를 들어 Claude Code를 큰 코드베이스에 쓰면 1~2시간에 $25 정도 소요됨, 자동화된 교정까지 붙이면 $50/hr까지 오름, 속도, 정확도, 비용 트레이드오프가 있음, 요즘 나온 Agent들도 그 삼각형의 지점이 아직 불명확해서 여러 실험이 흥미롭긴 해도 여전히 리스크가 있다고 생각함
약간 냉소적으로 보자면, LLM이 끊임없이 자기 자신을 리프롬프트하면서 오류를 고치는 구조, 그리고 "RAG 필요 없음! 그냥 1m 토큰 맥락창에 모든 코드를 다 던져넣어라"라는 접근이 결국 '토큰당 과금' 비즈니스 모델에 딱 맞는 프레임임
요즘 고민하는 아이디어는 여러 개의 커밋 초안을 처음부터 AI가 만들어내고, 이 결과를 사람이 직접 혹은 자동화된 방식으로 필터링 및 수동 다듬기 하는 구조임, 큰 작업일수록 초기의 작은 편차가 전체 결과를 망칠 확률이 높음, 그래서 현재 SOTA로도 에이전트들이 여러 안을 병렬로 시도하게 하면 수동 리팩터링하는 시간이 줄어듦, 관련 절차에 대해 GitHub에 글 남긴 적이 있음
구독 서비스냐고 질문하고 싶음
인간의 다단계 워크플로우에는 보통 검증 체크포인트가 있음, 인간도 99% 이상 정확하진 않기 때문임, 향후 에이전트도 출력에 검증 절차를 설계하고 다음 단계로 나아가기 전에 이 과정을 통과하도록 학습될 것임, 사전에 "여기만큼은 99% 이상 정확해야 한다" 같은 위험도 사전 평가도 할 수 있을 것임
Claude Code는 작업을 진행하기 전마다 계속 멈춰서 사용자에게 진행할지 물으며, 제안된 변경 사항도 미리 보여줌, 토큰 낭비와 비효율적인 작업을 막는 데 효과적임
많은 애플리케이션도 이런 구조에 맞춰 재설계가 필요함, 내 생각에 마이크로서비스 아키텍처가 LLM과 궁합이 좋아서 다시 유행할 것 같음
"진짜 문제는 AI의 능력이 아니라, 에이전트가 실제로 효과적으로 쓸 수 있는 툴과 피드백 시스템을 설계하는 것"이라는 데 동의함, 시장이 어떻게 받아들일지 확신이 없어 눈팅만 하다가 에이전트 만들기에 특화된 아주 작은 스타트업에 합류함, 5개월 만에 회의적→동조→확신으로 바뀜, 주제 범위를 아주 좁게 잡고, 모델이 일하기 위한 툴링에 집중하면 높은 완수율을 경험했음, 비결정론적 특성을 꺼려하는 경향이 있지만, 뛰어난 툴링과 점점 더 좁은 스코프만 있으면 현실적으로 꽤 쓸 만함, 툴링 자체가 어렵게 느껴지지만 괜찮게 해결 가능하다고 봄, 미래를 낙관함
다 해결 가능한 문제라고 생각함, 다만 빠른 ARR 확보 경쟁 때문에 많은 스타트업이 이런 문제에 집중하지 않음, 에이전트가 약속만큼 쓸모없다는 의견에도 일리는 있지만 실제로는 엔지니어링 문제임, 다른 시각으로 접근하면 작동할 거라 생각함(개인적으로 RL 쪽을 더 지지함), 예를 들면 좋은 검증자(verifier)가 필요함, 많은 작업은 직접 수행보다 검증이 더 쉬움, 80% 정확도의 병렬 생성물 5개만 있어도 99.96% 확률로 하나는 제대로 나오고 검증자가 그걸 고를 수 있음, 멀티스텝 상황에서도 수학적으로 유리해짐, 이제까지와는 다른 방식의 접근법, 글에서도 3~5단계 워크플로우 패러다임을 언급하는데 이게 실제로 잘 맞음, 앞으로 이런 모델이 더 많이 나와야 함
많은 작업에서 실제로는 검증이 작업 자체보다 더 어렵지 않냐는 논거에 의견이 있음, 특히 소프트웨어 QA 현장은 이런 논리로 구조조정이 일어나곤 했고 그 결과 품질이 나빠졌다고 느낌, 검증자는 시스템, 외부세계의 가능 상태 조합수가 기하급수적으로 늘어나서 아주 어렵게 됨, LLM은 이런 복잡한 작업환경에서 의존성을 모킹하거나 데이터를 미리 채우는 등 반복적인 노가다를 대신하는 데 매력적이나, 검증 테스트가 유의미하려면 항상 100% 정확해야 한다는 요구가 붙고 결국엔 사전조건 마다 또 검증자가 필요해짐, 결국 모든 단계가 100%여야 하면 누적적으로 확률이 줄어듦, 인간은 대부분 특정 케이스 별로 신중하게 테스트하고 모든 경우를 완벽 검증하진 않음(화이트박스 테스트가 블랙박스보다 훨씬 일반적임), LLM이 코드를 많이 생산하면 결국 작업자가 코드 전체를 이해해야만 화이트박스 검증이 가능한데, 그러면 절약한 시간이 다시 줄어듦, 현재로선 LLM이 만들고 오류도 내가 직접 다 고쳐야 해서 자신감이 더 줄고 시간도 더 듬, 일부 상황에서는 인터페이스를 LLM의 예상에 맞추는 식으로 해결할 수 있지만 범용적이지 않음, 소프트웨어를 벗어나면 검증은 아예 불가능할 때가 많음(예: "가장 유망한 게임 스타트업 5개 선정" 같은 경우 객관적 검증 불가), 이런 영역까지 사람도 아닌 기계에 무작정 맡기면 수습 불가
다섯 번 생성이 서로 독립적일 거라 가정해도 되는지 궁금함
맞는 말임, 여러 에이전트가 시도하고, 여러 번 되풀이하며 다양한 솔루션을 적용하는 게 현실적으로 효과 있음, 실제로 한 방법에서 부정적 피드백 받고 다른 접근방법으로 성공한 사례를 경험함
한 명의 개인(혹은 극소수 팀)이 개발, DevOps, 데이터오퍼레이션 등에서 실제 운영 중인 AI 에이전트를 12개 이상 만든 것은 의외임, 스타트업 실패율을 보면 "하나" 좋은 제품 만들기도 힘든데 12개나 만들었다는 것이 놀라움, 우리도 Definite 같은 데이터스택+AI 에이전트 툴을 2년 걸려 겨우 6개월 전부터 괜찮아졌음, Definite
사실 12개의 독립적 제품이 아니라, 실제로는 필요에 따라 직장에서 쓰는 아주 구체적 목적의 툴 12개를 만들었다는 의미임, 전체 글의 주제처럼 아주 단순하고 명확한 목적에만 집중해야 쓸모있는 에이전트가 됨
정규직 일을 3년이나 하면서 12개 이상 만들어냈다는 건 뭔가 어색함
나도 에이전트/AI 자동화 개발이 직업임, 오픈엔드형 코딩 에이전트는 그냥 멍청한 생각임, 인간 검증 체크포인트, 작은 탐색공간, 아주 구체적 질문/프롬프트(예: 이 이메일에 인보이스 있나 YES/NO)가 현실적임, 완전 자동 에이전트를 원하는 마음은 이해해도 기술은 아직 거기 못 미침, 나는 컨텐츠(텍스트, 이미지, 코드) 생성에는 손대지 않음, 그런 건 결국 한 방 먹일 거니까
나도 에이전트 프레임워크와 함께 chat coding(커뮤니케이션 기반 코딩)으로 작업량의 50% 정도를 줄임, GPT로 실제 효과 경험함, 하지만 10번 중 1번 꼴로 오류가 꼭 발생함, LLM 아키텍처를 근본적으로 바꾸지 않으면 이 에러율 안 고쳐질 거라 봄, 현 시점에서 hype 때문에 개발자 신뢰가 무너지지만 않는다면 향후엔 훨씬 더 견고한 시스템이 나올 것으로 확신함, 실제 팀원 채용도 예전보다 훨씬 적게 할 수 있을 정도로 생산성 향상이 눈에 띔, 각종 주제 러닝 커브도 google search 질 저하를 LLM이 보완해줘서 비약적으로 낮아짐, 자동화된 워크플로우에서 인간 업무 일부를 LLM이 맡도록 하는 Orchestration Framework가 가장 중요한 구조임, LLM이 본인 확신도 함께 보고하고, confidence %가 낮으면 바로 인간한테 넘어오도록, 테스트, 가드레일 등만 잘 되면 비핵심 업무부터 충분히 인간 대체 가능성큼, 사람을 대체하는 게 아니라 업무의 자동화로 팀 사이즈 절감이 목표임, 예시로 대형 이커머스의 상품설명, 이미지 검증·오타·이미지불일치 등 인간이 하던 작업을 LLM이 처리할 날을 확신함
대체로 동의하지만 그렇게 접근하면 남는 게 "그냥 비싼 워크플로우 시스템"일 수도 있음, 예전 기술로도 할 수 있던 걸 굳이 LLM이 해야 할 필요성이 있나 고민됨
나도 동의함, 현재는 "좁은 범위, 리스크 낮음, 반복성 높은 지루한 일"이 에이전트에 딱 맞는 포인트임, 예시로는 dev-log 마크다운 보조 작업에 에이전트 활용한 경험 여기에 남겼음
인간 검증이 체크포인트를 만들기에 가장 신뢰성 높음은 사실이나, 유닛테스트, 시스템 전체의 임시 검증(ad-hoc validation) 등 여러 방식이 추가로 존재함
나는 실제로 저자가 오히려 지금보다 자율 에이전트에 더욱 낙관적이어야 한다고 봄, 지금 하는 것 중 90%는 2024년 초엔 불가능했던 일임, 발전 곡선을 과소평가하지 않아야 함
나도 같은 생각임, 관련된 블로그 글도 있음, 핵심 차이는 HITL(Human in the loop)로 오류를 줄이는 게 맞고 HOTL(Human out of the loop)은 오히려 문제를 만든다는 점임
Hacker News 의견
Amazon의 AI 프로덕션 엔지니어와 대화해 본 경험이 있음, 그분이 말하길 현재 어떤 회사도 고객과 직접 대화하는 곳에 생성형 AI만 사용하는 경우가 전혀 없다고 함, 모든 자동응답은 예전의 비생성형 "구식" 기술을 사용한다고 함, 생성형 AI의 신뢰성 문제가 기업의 명성에 걸 stake를 맡길 수 없을 만큼 큼
예전에는 "구식 AI" 상징적 기법과 전통적인 머신러닝을 결합하는 에이전트에 관심이 많았음, 하지만 주로 프리-트랜스포머 신경망에서 일하게 됐음, 결국엔 항상 인간이 개입하는 시스템을 먼저 만들고 평가 및 훈련 데이터를 수집함, 그런 뒤 시스템이 업무 일부를 맡아서 나머지 품질까지 같이 향상시키는 흐름임, 특히 '주관적' 작업에서는 심볼릭 시스템도 반드시 평가해야 함, 만약 시스템을 훈련시켜야 한다면 평가를 못 피함
실제로 많은 테크 기업이 이미 생성형 AI를 실시간 챗봇 고객지원에 도입 중임, Sonder와 Wealthsimple 같은 곳을 알고 있음, LLM이 쿼리에 답을 못 할 경우엔 대화를 바로 인간 상담사에게 넘김
아직 논의되지 않은 점이 맥락 창(context window)에 대한 것임, 인간은 전문 분야에서 사실상 "거의 무한대"에 가까운 맥락을 다룰 수 있음, 모델은 더 크고 다양한 학습 데이터로 어느 정도 한계를 극복할 수 있지만 진정한 해결책은 아니라는 생각임, 현재는 사람들이 자신만의 맥락을 프롬프트에 담아 압축해야 하기에 영어처럼 유연한 언어에서는 공학보다는 마법주문 외우기나 추측 같은 느낌임, 결정론적 방식 대신 데이터의 많은 부분을 잃는다고 느끼는 중임
인간은 "맥락"과 "가중치"가 나뉘어 고정적으로 구분되어 있지 않음, 시간에 따라 경험과 결과가 내 "가중치" 자체를 계속 바꾸는데 LLM은 아키텍처상 가중치가 읽기 전용이라 불가능함
인간이 정말 그렇게 거대한 맥락 창을 가지고 있냐는 회의가 있음, 나는 내 복잡한 문제 해결 시 인간 고유의 "맥락 창" 한계에 자주 부딪힘, 실제로 그런 예시가 있는지 궁금함
나는 AI툴 사용 경험이 대체로 긍정적이었음, 쉬어야 할 때 소규모 작업을 맡기거나, 업무를 정리 및 시동시키는 데 큰 도움이 됨, 하지만 비용 이슈가 금방 생김, 예를 들어 Claude Code를 큰 코드베이스에 쓰면 1~2시간에 $25 정도 소요됨, 자동화된 교정까지 붙이면 $50/hr까지 오름, 속도, 정확도, 비용 트레이드오프가 있음, 요즘 나온 Agent들도 그 삼각형의 지점이 아직 불명확해서 여러 실험이 흥미롭긴 해도 여전히 리스크가 있다고 생각함
약간 냉소적으로 보자면, LLM이 끊임없이 자기 자신을 리프롬프트하면서 오류를 고치는 구조, 그리고 "RAG 필요 없음! 그냥 1m 토큰 맥락창에 모든 코드를 다 던져넣어라"라는 접근이 결국 '토큰당 과금' 비즈니스 모델에 딱 맞는 프레임임
요즘 고민하는 아이디어는 여러 개의 커밋 초안을 처음부터 AI가 만들어내고, 이 결과를 사람이 직접 혹은 자동화된 방식으로 필터링 및 수동 다듬기 하는 구조임, 큰 작업일수록 초기의 작은 편차가 전체 결과를 망칠 확률이 높음, 그래서 현재 SOTA로도 에이전트들이 여러 안을 병렬로 시도하게 하면 수동 리팩터링하는 시간이 줄어듦, 관련 절차에 대해 GitHub에 글 남긴 적이 있음
구독 서비스냐고 질문하고 싶음
인간의 다단계 워크플로우에는 보통 검증 체크포인트가 있음, 인간도 99% 이상 정확하진 않기 때문임, 향후 에이전트도 출력에 검증 절차를 설계하고 다음 단계로 나아가기 전에 이 과정을 통과하도록 학습될 것임, 사전에 "여기만큼은 99% 이상 정확해야 한다" 같은 위험도 사전 평가도 할 수 있을 것임
Claude Code는 작업을 진행하기 전마다 계속 멈춰서 사용자에게 진행할지 물으며, 제안된 변경 사항도 미리 보여줌, 토큰 낭비와 비효율적인 작업을 막는 데 효과적임
많은 애플리케이션도 이런 구조에 맞춰 재설계가 필요함, 내 생각에 마이크로서비스 아키텍처가 LLM과 궁합이 좋아서 다시 유행할 것 같음
"진짜 문제는 AI의 능력이 아니라, 에이전트가 실제로 효과적으로 쓸 수 있는 툴과 피드백 시스템을 설계하는 것"이라는 데 동의함, 시장이 어떻게 받아들일지 확신이 없어 눈팅만 하다가 에이전트 만들기에 특화된 아주 작은 스타트업에 합류함, 5개월 만에 회의적→동조→확신으로 바뀜, 주제 범위를 아주 좁게 잡고, 모델이 일하기 위한 툴링에 집중하면 높은 완수율을 경험했음, 비결정론적 특성을 꺼려하는 경향이 있지만, 뛰어난 툴링과 점점 더 좁은 스코프만 있으면 현실적으로 꽤 쓸 만함, 툴링 자체가 어렵게 느껴지지만 괜찮게 해결 가능하다고 봄, 미래를 낙관함
다 해결 가능한 문제라고 생각함, 다만 빠른 ARR 확보 경쟁 때문에 많은 스타트업이 이런 문제에 집중하지 않음, 에이전트가 약속만큼 쓸모없다는 의견에도 일리는 있지만 실제로는 엔지니어링 문제임, 다른 시각으로 접근하면 작동할 거라 생각함(개인적으로 RL 쪽을 더 지지함), 예를 들면 좋은 검증자(verifier)가 필요함, 많은 작업은 직접 수행보다 검증이 더 쉬움, 80% 정확도의 병렬 생성물 5개만 있어도 99.96% 확률로 하나는 제대로 나오고 검증자가 그걸 고를 수 있음, 멀티스텝 상황에서도 수학적으로 유리해짐, 이제까지와는 다른 방식의 접근법, 글에서도 3~5단계 워크플로우 패러다임을 언급하는데 이게 실제로 잘 맞음, 앞으로 이런 모델이 더 많이 나와야 함
많은 작업에서 실제로는 검증이 작업 자체보다 더 어렵지 않냐는 논거에 의견이 있음, 특히 소프트웨어 QA 현장은 이런 논리로 구조조정이 일어나곤 했고 그 결과 품질이 나빠졌다고 느낌, 검증자는 시스템, 외부세계의 가능 상태 조합수가 기하급수적으로 늘어나서 아주 어렵게 됨, LLM은 이런 복잡한 작업환경에서 의존성을 모킹하거나 데이터를 미리 채우는 등 반복적인 노가다를 대신하는 데 매력적이나, 검증 테스트가 유의미하려면 항상 100% 정확해야 한다는 요구가 붙고 결국엔 사전조건 마다 또 검증자가 필요해짐, 결국 모든 단계가 100%여야 하면 누적적으로 확률이 줄어듦, 인간은 대부분 특정 케이스 별로 신중하게 테스트하고 모든 경우를 완벽 검증하진 않음(화이트박스 테스트가 블랙박스보다 훨씬 일반적임), LLM이 코드를 많이 생산하면 결국 작업자가 코드 전체를 이해해야만 화이트박스 검증이 가능한데, 그러면 절약한 시간이 다시 줄어듦, 현재로선 LLM이 만들고 오류도 내가 직접 다 고쳐야 해서 자신감이 더 줄고 시간도 더 듬, 일부 상황에서는 인터페이스를 LLM의 예상에 맞추는 식으로 해결할 수 있지만 범용적이지 않음, 소프트웨어를 벗어나면 검증은 아예 불가능할 때가 많음(예: "가장 유망한 게임 스타트업 5개 선정" 같은 경우 객관적 검증 불가), 이런 영역까지 사람도 아닌 기계에 무작정 맡기면 수습 불가
다섯 번 생성이 서로 독립적일 거라 가정해도 되는지 궁금함
맞는 말임, 여러 에이전트가 시도하고, 여러 번 되풀이하며 다양한 솔루션을 적용하는 게 현실적으로 효과 있음, 실제로 한 방법에서 부정적 피드백 받고 다른 접근방법으로 성공한 사례를 경험함
한 명의 개인(혹은 극소수 팀)이 개발, DevOps, 데이터오퍼레이션 등에서 실제 운영 중인 AI 에이전트를 12개 이상 만든 것은 의외임, 스타트업 실패율을 보면 "하나" 좋은 제품 만들기도 힘든데 12개나 만들었다는 것이 놀라움, 우리도 Definite 같은 데이터스택+AI 에이전트 툴을 2년 걸려 겨우 6개월 전부터 괜찮아졌음, Definite
사실 12개의 독립적 제품이 아니라, 실제로는 필요에 따라 직장에서 쓰는 아주 구체적 목적의 툴 12개를 만들었다는 의미임, 전체 글의 주제처럼 아주 단순하고 명확한 목적에만 집중해야 쓸모있는 에이전트가 됨
정규직 일을 3년이나 하면서 12개 이상 만들어냈다는 건 뭔가 어색함
나도 에이전트/AI 자동화 개발이 직업임, 오픈엔드형 코딩 에이전트는 그냥 멍청한 생각임, 인간 검증 체크포인트, 작은 탐색공간, 아주 구체적 질문/프롬프트(예: 이 이메일에 인보이스 있나 YES/NO)가 현실적임, 완전 자동 에이전트를 원하는 마음은 이해해도 기술은 아직 거기 못 미침, 나는 컨텐츠(텍스트, 이미지, 코드) 생성에는 손대지 않음, 그런 건 결국 한 방 먹일 거니까
나도 에이전트 프레임워크와 함께 chat coding(커뮤니케이션 기반 코딩)으로 작업량의 50% 정도를 줄임, GPT로 실제 효과 경험함, 하지만 10번 중 1번 꼴로 오류가 꼭 발생함, LLM 아키텍처를 근본적으로 바꾸지 않으면 이 에러율 안 고쳐질 거라 봄, 현 시점에서 hype 때문에 개발자 신뢰가 무너지지만 않는다면 향후엔 훨씬 더 견고한 시스템이 나올 것으로 확신함, 실제 팀원 채용도 예전보다 훨씬 적게 할 수 있을 정도로 생산성 향상이 눈에 띔, 각종 주제 러닝 커브도 google search 질 저하를 LLM이 보완해줘서 비약적으로 낮아짐, 자동화된 워크플로우에서 인간 업무 일부를 LLM이 맡도록 하는 Orchestration Framework가 가장 중요한 구조임, LLM이 본인 확신도 함께 보고하고, confidence %가 낮으면 바로 인간한테 넘어오도록, 테스트, 가드레일 등만 잘 되면 비핵심 업무부터 충분히 인간 대체 가능성큼, 사람을 대체하는 게 아니라 업무의 자동화로 팀 사이즈 절감이 목표임, 예시로 대형 이커머스의 상품설명, 이미지 검증·오타·이미지불일치 등 인간이 하던 작업을 LLM이 처리할 날을 확신함
대체로 동의하지만 그렇게 접근하면 남는 게 "그냥 비싼 워크플로우 시스템"일 수도 있음, 예전 기술로도 할 수 있던 걸 굳이 LLM이 해야 할 필요성이 있나 고민됨
나도 동의함, 현재는 "좁은 범위, 리스크 낮음, 반복성 높은 지루한 일"이 에이전트에 딱 맞는 포인트임, 예시로는 dev-log 마크다운 보조 작업에 에이전트 활용한 경험 여기에 남겼음
인간 검증이 체크포인트를 만들기에 가장 신뢰성 높음은 사실이나, 유닛테스트, 시스템 전체의 임시 검증(ad-hoc validation) 등 여러 방식이 추가로 존재함
나는 실제로 저자가 오히려 지금보다 자율 에이전트에 더욱 낙관적이어야 한다고 봄, 지금 하는 것 중 90%는 2024년 초엔 불가능했던 일임, 발전 곡선을 과소평가하지 않아야 함
나도 같은 생각임, 관련된 블로그 글도 있음, 핵심 차이는 HITL(Human in the loop)로 오류를 줄이는 게 맞고 HOTL(Human out of the loop)은 오히려 문제를 만든다는 점임