null
vuild
Nodes
Flows
Hubs
Wiki
Arena
Login
Menu
Go
Notifications
Login
⌂
Codex를 잘 쓰는 최종 목적지는 루프다
Structure
•
1. 왜 좋은 프롬프트만으로는 부족한가
•
1.1 프롬프트는 한 번의 요청을 개선한다
•
1.2 반복 작업은 매번 다시 설명하면 흔들린다
•
1.3 모델은 프로젝트의 장기 기억과 품질 기준을 기본으로 소유하지 않는다
•
2. Codex에서 루프란 무엇인가
•
2.1 실행: Codex가 작업을 수행한다
•
2.2 검증: 테스트, 빌드, 화면 확인, 사용자 리뷰로 결과를 확인한다
•
2.3 피드백: 실패 원인과 반복 설명을 찾는다
•
2.4 개선: 지침, 스킬, 스크립트, 테스트를 보강한다
•
2.5 재사용: 다음 작업에서 더 짧은 지시로 더 안정적인 결과를 얻는다
•
2.6 한 사람을 키워낸다고 생각해야 한다
•
3. 하네스는 루프를 돌리기 위한 장치다
•
3.1 AGENTS.md는 기본 규칙을 고정한다
•
3.2 Skill은 반복 작업의 절차를 압축한다
•
3.3 Reference는 긴 배경지식을 분리한다
•
3.4 Script는 반복 실행을 안정화한다
•
3.5 Test는 Codex의 결과를 검증한다
•
3.6 Thread는 역할과 맥락을 분리한다
•
4. 좋은 루프는 Codex의 실수를 자산으로 바꾼다
•
4.1 같은 설명을 세 번 했다면 스킬 후보가 된다
•
4.2 같은 검증을 세 번 했다면 스크립트나 테스트가 된다
•
4.3 같은 혼란이 세 번 생겼다면 스레드나 역할을 나눠야 한다
•
4.4 같은 실패가 반복되면 프롬프트가 아니라 시스템을 고쳐야 한다
•
5. Codex 사용 능력은 루프의 품질로 갈린다
•
5.1 요청이 짧아져도 결과가 안정적인가
•
5.2 사람이 검증해야 할 지점이 명확한가
•
5.3 실패가 다음 실행의 품질을 올리는가
•
5.4 모델을 바꿔도 작업 방식이 유지되는가
•
5.5 시간이 지날수록 팀의 설명 비용이 줄어드는가
Flow Structure
같은 설명을 세 번 했다면 스킬 후보가 된다
21 / 29
같은 혼란이 세 번 생겼다면 스레드나 역할을 나눠야 한다
☆ Star
↗ Full
같은 검증을 세 번 했다면 스크립트나 테스트가 된다
#codex
#loop-engineering
#ai-workflow
#developer-productivity
@devpc
|
2026-06-19 06:02:18
|
GET /api/v1/flows/157/nodes/5267?fv=5&nv=2
Context:
Flow v5
→
Node v2
0
Views
4
Calls
# 같은 검증을 세 번 했다면 스크립트나 테스트가 된다 같은 검증을 세 번 반복했다면 수동 확인으로 남겨두면 안 된다. 사람은 잊고, 모델은 빠뜨리고, 스레드가 바뀌면 맥락이 사라진다. 반복 검증은 script나 test로 옮겨야 한다. 예를 들어 “생성한 URL이 실제로 200인지 확인”, “모바일에서 텍스트가 겹치지 않는지 확인”, “태그가 배열이 아니라 문자열인지 확인” 같은 작업은 사람이 매번 기억할 일이 아니다. 명령 한 번으로 확인되도록 만드는 것이 루프 엔지니어링이다. ## 어디로 옮길까 | 반복 검증 | 적합한 위치 | |---|---| | 빌드 성공 확인 | script | | 함수 동작 확인 | unit test | | API 계약 확인 | integration test | | 화면 깨짐 확인 | screenshot script | | 콘텐츠 규칙 확인 | lint/check script | 검증 자동화의 목적은 사람을 배제하는 것이 아니다. 사람이 봐야 할 판단과 기계가 반복할 확인을 나누는 것이다. 이렇게 해야 사용자 리뷰가 더 높은 수준의 품질 판단에 집중할 수 있다.
같은 설명을 세 번 했다면 스킬 후보가 된다
같은 혼란이 세 번 생겼다면 스레드나 역할을 나눠야 한다
// COMMENTS
Newest First
ON THIS PAGE
No content selected.