r/cursor•4개월 전•4•16

40분 넘게 프롬프트 돌리는 사람들, 어떻게 제대로 된 결과물을 뽑아내는 거임?

People who run 40min+ prompts, how do you manage to actually get good outputs?

핵심 요약

40분 이상 걸리는 긴 프롬프트 작업의 신뢰성을 확보하고 좋은 결과물을 얻는 노하우에 대한 질문입니다.

긴 프롬프트 — 40분 이상 소요되는 작업의 신뢰성 의문 제기
결과물 검증 — 코드의 품질과 정확성을 어떻게 보장하는지 질문
작업 방식 — 한 번에 기능을 구현하려다 실패하는 경험 공유
범위 설정 — 작은 단위의 프롬프트가 더 효과적인지 고민

온라인이나 직장에서 사람들이 1시간씩 걸리는 프롬프트를 막 돌리는 걸 보는데 진짜 이해가 안 감. 결과물을 어떻게 믿음? 코드가 개판이 아니라는 걸 어떻게 아는 거임? 진짜 제대로 된 결과물이 나오긴 함?

기능 하나를 통째로 한 번에 구현하려고 실험해봤는데, 보통은 부족하거나 구현 측면에서 완전히 망해버림 (특히 codex는 장기적인 작업에서 젬병이라 더함).

이걸 제대로 하는 방법을 찾으려고 하는데, 아니면 그냥 프롬프트 범위를 작게 잡는 게 답인가?

원문

커뮤니티 목록

r/cursor•4개월 전•4•16

40분 넘게 프롬프트 돌리는 사람들, 어떻게 제대로 된 결과물을 뽑아내는 거임?

People who run 40min+ prompts, how do you manage to actually get good outputs?

핵심 요약

40분 이상 걸리는 긴 프롬프트 작업의 신뢰성을 확보하고 좋은 결과물을 얻는 노하우에 대한 질문입니다.

긴 프롬프트 — 40분 이상 소요되는 작업의 신뢰성 의문 제기
결과물 검증 — 코드의 품질과 정확성을 어떻게 보장하는지 질문
작업 방식 — 한 번에 기능을 구현하려다 실패하는 경험 공유
범위 설정 — 작은 단위의 프롬프트가 더 효과적인지 고민

이걸 제대로 하는 방법을 찾으려고 하는데, 아니면 그냥 프롬프트 범위를 작게 잡는 게 답인가?

주요 댓글

r/cursor

사용자들은 긴 프롬프트보다는 작업을 세분화하여 단계적으로 처리하는 방식을 선호하며, 잘 정의된 프로젝트 목표 설정의 중요성에 대해 공감하고 있습니다.

난 AI 결과물을 주니어 개발자라고 생각함. 주니어 개발자가 짠 코드는 엄청 꼼꼼하게 PR 리뷰를 해야 하잖아. 내가 코드를 이해 못 하면 절대 머지 안 함.

가끔 모델이 엄청 느려서 1분이 아니라 1시간씩 걸릴 때가 있음... 자동화를 빡세게 돌리면 며칠이나 몇 주 동안 감독 없이도 많은 일을 처리할 수 있어. 결국 상세한 스펙이랑 잘 정의된 소프트웨어/목표가 핵심임.

요즘 그런 게 공통적인 테마인 것 같네: 상세한 스펙이랑 잘 정의된 소프트웨어/목표 말이야. 이건 확실히 과학보다는 예술의 영역에 가까운 것 같아서, 상세 스펙이나 잘 정의된 목표에서 말하는 '좋은 감각'이 대체 뭔지 파악하려고 하는 중임. 혹시 공유해 줄 수 있음?

공개 안 한다는 조건이면 예시 하나 보여줄 수 있음... DM 확인해. 잘 정의된 프로젝트들은 널려 있음. 근데 사람들은 맨날 다음 대박 아이템만 찾으려고 하지. 그런 건 그냥 거르고, 지금 개판으로 돌아가는 것들 중에 잘할 수 있는 거 찾아봐. 업계에 그런 기회 엄청 많음.

아니 1시간짜리 프롬프트는 대체 어떻게 만드는 거임? "레딧 만들어줘"라고 시키는 거냐?? 내 프롬프트 98%는 다 쪼개져 있고, Claude 없이 소프트웨어 엔지니어로서 일할 때처럼 작업함. 작은 변경들을 합쳐서 결과를 만드는 거지. 다들 이렇게 하는 거 아님? 새 프로젝트 시작할 때 처음부터 다 짜야 해서 시간이 좀 걸리는 건 이해함.

훌륭한 PRD네. 작은 단위로 쪼개서 작업해. 랄프 루프를 돌리거나 서브 에이전트를 써. 확실한 백프레셔를 주고, 적대적 리뷰어를 활용해. 최고의 모델을 쓰고. 잘못된 행동을 하면 새로운 지침과 가드레일로 하네스를 개선해. 아니면 getindigo.ai 같은 걸 써봐, 알아서 많이 처리해주니까. (내가 창업자라 홍보 같으면 마지막 줄은 무시하고 앞 두 문단만 읽어) 행운을 빌어!

솔직히 여기서 HQ 홍보하려는 건 아님. 내 기록 확인해 봐도 됨. 그냥 상황에 맞는 것 같아서 말한 거임. 어쨌든 행운을 빈다! 🤍

40분짜리 결과물을 통째로 믿으려 하면 안 됨. 작은 계약들의 연속으로 바꿔야 해. 뭐가 변할 수 있고, 뭐가 변하면 안 되는지, 기대되는 동작은 뭔지, 그리고 제대로 작동하는지 확인하는 테스트를 짜는 거지. 그 경계 안에서만 에이전트를 길게 돌려. 거대한 코드 뭉치가 아니라 좁은 범위의 약속을 검토하는 거라 리뷰가 훨씬 쉬워짐.

첫 토큰이 나오기 전에 종료 조건을 명시해. '느낌이 좋은가' 같은 게 아니라 기계가 확인할 수 있는 걸로. 그게 없으면 40분 동안의 결과물은 그냥 40분 동안 자신감 있게 헛소리한 거나 다름없음: ultrathink.art/blog/explicit-success-criteria-transaction-log

블로그 방금 다 읽었는데 진짜 흥미롭네. 몇 가지 질문 좀: - 현재 정지 조건(stop conditions)은 어떻게 구성하고 있음? - 정지 조건 구현을 단계별로 함, 아니면 한 번에 다 함? 단계별로 한다면, 에이전트 간에 새로운 컨텍스트로 전달하는 거임, 아니면 그냥 한 세션 안에 다 담는 거임? - 현실적으로, 트랜잭션 로그는 얼마나 자주 읽고, 정지 조건이나 워크플로우는 얼마나 자주 수정함?

원문r/cursor