Meta Forum의 방식은 소프트웨어 팀이 눈여겨볼 만하다. 엔지니어가 에이전트가 쓰는 코드를 한 줄씩 지켜보는 대신, 에이전트가 계획, 구현, 테스트, 수정의 한 바퀴를 스스로 돌고 사람은 목표를 정하고 과정을 지켜보다가 방향이 틀어지면 개입해 마지막 승인을 한다. 2026년 10월 15일 Meta 엔지니어링 팀은 공식 글에서 소규모 팀이 독립 앱 Forum을 처음부터 만들어 8주 만에 Facebook Groups의 핵심 기능과 동등한 수준에 도달한 과정을 복기했다.
성패는 코드량이 아니라 검증으로 잰다
팀이 성공 기준으로 삼은 것은 생성된 코드의 양이 아니라 결과물이 빌드와 테스트, 리뷰를 통과해 바로 운영에 올릴 수 있는지였다. 그래서 자동 검증을 에이전트 루프 안에 넣었다. 빌드 상태, 단위 테스트, 화면 사양 대조가 명확한 합격·불합격 신호를 돌려주고 에이전트가 먼저 자체 점검을 하므로, 엔지니어 앞에는 테스트 계획과 검증 기록이 붙은 변경만 도착한다. 구체적인 예가 스트레스 테스트다. 실제 사용자처럼 격하게 스크롤하고 화면을 오가며 미디어를 반복 로딩하는 검증을 돌리자 개발 중에 메모리 문제가 발견돼 수정됐고, 메모리 사용량과 페이지 폴트가 대략 절반으로 줄었다.
바꾼 것은 프롬프트가 아니라 환경이다
복기에서 솔직하게 드러나는 판단은 성과가 프롬프트 다듬기가 아니라 코드베이스와 도구를 바꾼 데서 나왔다는 것이다. 프로젝트 규칙과 팀 관행은 재사용할 수 있는 규칙과 스킬로 남겼고, 에이전트에게는 화면을 글로 설명하는 대신 시뮬레이터에서 실제 화면 계층을 읽는 도구를 줬다. 시제품 코드는 별도 빌드에 넣어 운영 빌드에는 물리적으로 존재하지 않게 했으므로 실험 코드가 실제 사용자의 앱을 망가뜨릴 일도 없다.
전제도 분명하다. 루프에 안전하게 맡길 수 있는 일의 양은 검증 신호가 얼마나 믿을 만한지에 달려 있다. 검증이 따라오지 못하면 사람의 시간은 코드를 쓰는 일에서 완성된 것처럼 보이는 결과물을 검토하는 일로 옮겨갈 뿐이다. 대부분의 팀에게 Forum의 교훈은 순서에 대한알림이며, 테스트와 상태 조회부터 단단히 만든 뒤에 에이전트에게 더 긴 과정을 맡기라는 것이다.
