생각을 멈추는 방식이 통하는 시점은 오지 않음

LLM의 결과를 검증 없이 받아들이거나 오류 수정을 다시 맡기기만 하는 방식은 모델이 발전해도 직원에게 유효한 전략이 되지 못함 지금은 이런 방식으로 만든 소프트웨어에 심각한 문제가 남고, 미래에 LLM이 혼자 훌륭한 소프트웨어를 만들게 된다면 기업은 중간에서 요청만 전달하는 직원 없이 모델을 반복 실행하면 됨 가치가 높은 작업에는 품질 검증과 설계 판단이 여전히 필요하며, 명세로 옮기기 어려운 요구사항과 학습 분포 밖의 문제에서 사람의 개입이 중요함 테스트나 지표 충족이 실제 성공을 보장하지는 않으므로, 좁은 개인 용도에 맞는 도구와 상용 제품을 구분하고 산출물을 실제로 검증해야 함 인간의 노동이 곧 불필요해질 것이라고 예상하더라도, 은퇴할 준비가 되지 않았다면 판단과 노력을 포기할 이유는 오히려 줄어듦 성능이 좋아져도 단순 전달자의 자리는 남지 않음 2025년 초부터 LLM에 요약이나 코드 작성을 맡긴 뒤 제대로 됐다고 가정하는 사용 방식이 나타났으며, 당시에는 대체로 잘 작동하지 않고 우스운 결과를 낳기도 했음 모델이 좋아지면서 이런 사용이 더 늘어남. 결과가 작동하지 않으면 사람이 문제를 판단하는 대신 LLM에 다시 해결을 요청하는 경우도 있음 Niklas Gruhn은 이런 방식의 일부를 meat proxy라고 부름 Gruhn이 사람이 while이나 for 반복문처럼 행동하는 경우를 직접 다루지는 않았지만, 요청과 재시도를 중계하는 행동도 같은 맥락에 해당함 2026년 9월 시점의 관찰에서는 사람이 반복문 역할만 하는 개발도 2025년 초보다는 나아져, 결과물이 어느 정도 작동하기도 함 다만 직접 사용하고 싶거나 성공적이라고 평가할 정도는 아니었음 앞으로는 이런 방식으로도 평균적인 품질의 소프트웨어를 만들거나, 사람 없이 훌륭한 소프트웨어를 만드는 수준까지 발전할 수 있음 그런 수준에 도달하면 기업은 LLM을 직접 반복 실행하고 중간의 직원을 해고할 수 있음 현재는 품질이 부족하고, 충분히 좋아진 뒤에는 중계 역할이 불필요하므로 직원에게 유효한 방법이 되는 시점이 없음 가치가 높은 작업에는 감독과 설계 판단이 필요함 Luke Burton은 실패해도 되는 낮은 가치의 작업에 한해서만 결과를 지켜보지 않고 자리를 떠날 수 있다고 봄 가치가 높은 작업을 LLM이 한 번에 해결할 가능성은 훨씬 낮아, 사람이 품질 보증 담당자, 엔지니어링 관리자, 아키텍트 역할을 맡아야 함 반복 작업을 감독하는 과정은 마감 직전...