7. 요청 하나가 배포까지

좋아, 실제로 있었던 흐름으로 따라가보자. 첫 질문 — "투자 대시보드 만들어줘"라는 한 문장만 놓고 보면, 이걸로 바로 코드를 짤 수 있을까? 이 문장에 빠진 정보가 있을까?

맞아. 5장에서 배운 "①조립 단계"에서, 그 빠진 정보를 모델이 마음대로 추측하게 두면 엉뚱한 결과가 나올 수 있어. 그래서 좋은 에이전트는 애매하면 바로 코드를 짜지 않고, 먼저 되물어. "어떤 종목/시장? 분석 깊이는? 뉴스는 뭘 원해?" 이게 순수 텍스트 응답이라 도구 호출 없이 그 턴에서 루프가 바로 끝나 — 2장에서 배운 대로.

맞아. 답이 들어오면 그게 다시 ①조립에 합쳐지고, 모델이 이번엔 도구 호출을 포함한 텍스트를 낼 차례야. 순서를 볼까:

1. 폴더 생성 도구 호출 → 실행 → 결과("생성됨")가 다시 텍스트로 들어옴
2. 서버 코드 파일 쓰기 도구 호출 → 실행 → "파일 저장됨"
3. 가격 데이터를 가져오는 외부 API 호출 테스트 (터미널 도구) → 결과 확인 → 잘못된 값 발견하면 여기서 5장에서 말한 "재조립"이 한 번 더 일어나서 코드를 고침
4. 서버 실행 도구 호출 → 백그라운드 프로세스 시작
5. 포트를 외부에 연결하는 도구 호출 → 공개 주소 생성
6. 더 이상 도구가 필요 없다고 판단 → 순수 텍스트로 "완성했어요, URL은 이거예요"

이 1~5단계 하나하나가 전부 "추론 → 도구호출 → 실행 → 재조립"의 반복이야. 사용자 눈에는 "몇 분 뒤 링크 하나 뚝" 떨어지는 걸로 보이지만, 안에서는 이 루프가 수십 번 돌고 있는 거지.

있어. 예를 들어 "기존에 이미 돌고 있는 다른 서버를 실수로 꺼버리는" 도구 호출이 나올 수 있는데, 이런 위험한 명령은 훅(hook)이나 권한 규칙으로 미리 막아두거나 확인을 받게 설계해. 실제로 이런 사고가 나면(예: 포트 충돌로 다른 서비스까지 같이 꺼짐), 그건 "모델이 멍청해서"가 아니라 "그 도구 호출의 위험 범위를 시스템이 충분히 제한하지 못해서" 생기는 문제야. 그래서 하네스를 잘 설계한다는 건 결국 이런 안전장치를 얼마나 촘촘하게 까느냐의 문제이기도 해.