/goal 기능이 원하는 결과를 전혀 "생산"하지 못함

일단 글 쓰는 스타일 진짜 마음에 든다고 말하고 싶네. '/goal한테 거대한 성스러운 석판을 건네주고'랑 '구현물을 석판에 계속 들이박는다'는 부분에서 빵 터졌음. :D

Goal은 과정보다 결과가 더 중요할 때 유용함.

마치 샷건처럼, 딱 하나를 노리는 게 아니라 뭔가 사냥해야 할 때 잘 작동함. vbpoweredwindmill의 예시가 딱 이런 경우지.

또 스나이퍼 라이플처럼, 정확한 타겟이 어디 있는지 확실히 보일 때도 잘 작동하는데...

하지만 내가 일일이 구현 단계를 챙기지 않아도 명확하게 정의된 결과물을 향해 자율적으로 반복 작업을 수행하게 하려는 거 아님?

맞음. 이게 정확히 goal이 작동하는 방식임. "빌딩 하나 지어줘" 같은 거보다는 "이 빌딩에서 제트 연료로도 녹지 않을 빔 구조를 찾아봐" 같은 작업에 더 적합함.

사실 현실의 인간도 똑같이 일함. "빌딩 하나 지어줘"라고 하면 어이없어하겠지만, 건축가를 고용해서 몇 시간 동안 같이...

실력 문제네 💀

프로젝트 폴더에 무엇을 해야 할지 명시된 파일이 없다면, 먼저 계획을 세우라고 지시해야 해. Goal 모드는 계획 수립에도 사용할 수 있지만, 핵심은 계획이 충분히 명확해지기 전에 서둘러 구현하려고 하지 말고, 플러그인을 쓰든 아니든 먼저 기반을 다지도록 지시해야 한다는 거야.

성공 기준을 먼저 정의하는 게 좋을 듯. 테스트 형태로 만드는 게 이상적이지. 예를 들어 네 비유를 들자면, 변기가 깨끗한지 확인하는 테스트 세트를 먼저 만드는 거야. 예: 뚜껑 깨끗함, 변기 안쪽 깨끗함, 손잡이 깨끗함, 바닥에 물기 없음 등등. 그렇게 기준을 잡아두고 goal을 실행하면, 그 테스트 범위 안에서만 움직일 거야.

Skill issue네. UX한테 goal 프롬프트 좀 짜달라고 해봐. 그리고 한번 뜯어봐. 완료 조건 같은 오케스트레이션 문제인 거 보이니까. 나중에 skill issue 해결되면 이 레딧 글 지우고.

너 '실수 금지'라고 안 적었지, 백퍼.

nightshift 한번 써봐. 난 이게 goal보다 훨씬 효율적이고 사용량도 적게 먹는다고 느꼈음. 근데 가끔 작동을 멈출 때가 있어서 계속 지켜봐야 하는 게 좀 짜증 나긴 함.

이게 풍자인지 아닌지 모르겠네. 하지만 /goal은 목표가 달성되었는지 판단할 수 있는 객관적이고 구체적인 방법이 있을 때만 아껴서 사용해야 해. 예를 들어 프로그램의 결과값이 특정 값이어야 하는 경우처럼 말이야. /goal이 유용한 시나리오는 거의 드물어.