Plan-Perfectly에서 Try-and-Improve로
I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (excluding the source line you already provided) here? Once I have it, I’ll keep the source link unchanged and translate the rest into Korean while preserving all formatting, markdown, and code blocks.
옛 방정식
전통적인 개발에서는 코드를 변경하는 것이 비용이 많이 듭니다.
- 작성에는 시간이 걸립니다.
- 테스트에는 시간이 걸립니다.
- 디버깅에는 시간이 걸립니다.
각 반복은 몇 시간 혹은 며칠이 걸리기 때문에, 우리는 완벽하게 계획하는 법을 배웠습니다—사고를 앞서서 미리 수행하고, 재작업을 최소화합니다. 이는 생산 비용이 높을 때는 타당했습니다.
새로운 방정식
AI가 비용 구조를 재작성합니다.
| 활동 | 기존 비용 | AI 지원 비용 |
|---|---|---|
| 코드 생성 | 시간 | 분 |
| 테스트 생성 | 시간 | 분 |
| 반복 | 비용이 많이 듦 | 사소함 |
생산 비용이 급격히 감소하면 투자 균형이 이동합니다.
| 이전 | 이후 |
|---|---|
| 계획 70%, 구축 30% | 계획/구축 20%, 검토/점검 80% |
| 먼저 종이에 정확히 적는다 | 작동시키고, 그 다음 끊임없이 평가한다 |
| 실수는 비용이 많이 든다 | 실수는 검토를 통해 발견된다 |
노력의 대부분이 창작이 아니라 평가로 이동합니다.
완벽한 계획이 실패하는 이유
여기 불편한 진실이 있습니다: 보고 나서야 원하는 것이 무엇인지 알 수 있습니다.
계획은 추상입니다. 작동하는 소프트웨어는 구체적입니다.
계획을 세울 때:
- 어떻게 작동할지 상상합니다.
- 어떤 문제가 발생할지 예측합니다.
- 요구사항을 이해하고 있다고 가정합니다.
구현할 때:
- 실제로 어떻게 작동하는지 확인합니다.
- 예측하지 못한 문제를 발견합니다.
- 이해가 불완전했음을 깨닫습니다.
계획은 가정에 기반합니다. 구현은 현실을 드러냅니다.
계획과 현실 사이의 차이는 계획의 실패가 아니라 복잡한 작업에 내재된 것입니다.
Source:
Ksql.Linq 이야기
2022년 6월부터 8월까지, 나는 라이브러리를 처음부터 네 번이나 다시 만들었습니다. 각 재구축은 완전한 재작성으로, 아키텍처, API, 핵심 개념이 모두 바뀌었습니다.
첫 번째 재구축
우리가 기본 전제를 공유하지 않았다는 것을 발견했습니다. AI와 나는 서로 다른 문제를 해결하고 있었습니다.
두 번째 재구축
우선순위 정렬이 맞지 않다는 것을 알게 되었습니다. 내가 중요하다고 생각한 것은 AI가 선택 사항으로 취급했습니다.
세 번째 재구축
내 의도가 충분히 명확하지 않아 전달되지 않았다는 것을 깨달았습니다.
네 번째 재구축
마침내 공유된 이해가 형성되었습니다.
각 완전한 재작성은 실패가 아니라 진단이었습니다. 구축하고 검토하는 과정에서 정렬이 깨진 정확한 지점을 드러냈습니다. AI‑지원 개발을 활용하면 각 사이클이 며칠 안에 완료돼, 발견 비용을 거의 제로에 가깝게 낮출 수 있습니다.
핵심 기법: 재시작할 때는 컨텍스트 롤백으로 생각하세요—공유된 이해를 알려진 좋은 지점으로 되돌린 뒤, 다르게 진행하는 것입니다. 이는 컨텍스트를 보존하는 것이 필요하며, 이때 공유 메모리 시스템이 필수적입니다.
(이 시리즈의 다음 기사에서는 컨텍스트 관리와 공유 메모리에 대해 더 다룹니다.)
핵심 통찰
형태가 있으면, 누구든지 평가할 수 있다.
- 계획은 평가를 위해 상상이 필요하다; 사람마다 시뮬레이션 방식이 달라 합의가 어렵다.
- 작동하는 구현은 상상이 필요 없다—실행해 보면 결과가 나온다. 평가는 직접적이다.
이것이 전략을 바꾼다:
| 전통적 | AI‑지원 |
|---|---|
| 계획‑우선 | 구축‑우선 |
| 모두를 맞추기 위한 긴 계획 회의 | 짧은 계획, 빠른 구축 |
| 코딩 전에 광범위하게 문서화 | 논의를 위한 무언가를 구축 |
| 제안을 추상적으로 평가 | 요구사항에 구체적으로 평가 |
가능한 한 빨리 평가 가능한 상태에 도달하라.
Source: …
실제 현장에서의 변화
프로토타입은 저렴해진다
구축 비용이 주가 아니라 일 수준이 되면, 프로토타입은 특수한 투자라기보다 일상적인 워크플로가 된다.
“A와 B 중 어느 쪽을 할까?”가 “두 개 다 만들어 보고 보자”가 된다.
사양은 구현을 따라간다
전통적인 흐름: Spec → Build → Discover gaps → Revise spec → Rebuild
AI 기반 흐름: Rough idea → Build → Evaluate → Refine understanding → Rebuild
두 번째 경로는 낭비처럼 보일 수 있지만, AI‑속도 개발에서는 더 빠르다.
실패가 주는 충격이 사라진다
각 시도가 하루 정도밖에 들지 않을 때, “실패”는 곧 “학습”이다.
질문은 “잘못된 것을 만들지 않으려면 어떻게 해야 할까?”에서 “가능한 한 빨리 올바른 것을 배우려면 어떻게 해야 할까?”로 바뀐다.
완벽한 계획이 여전히 중요한 경우
이것은 “아예 계획하지 말라”는 뜻이 아니다. 일부 결정은 충분히 고민할 가치가 있다:
- 돌이킬 수 없는 선택: 외부 API 계약, 다른 팀이 의존하는 데이터 스키마 등.
- 고비용 전환: 팀 전체에 걸친 조정이 필요한 아키텍처 변경.
- 컴플라이언스/법적 제약: “시도해 보고 보자”가 실제로 큰 영향을 미치는 경우.
이러한 경우에는 신중히 계획하라. 그 외의 모든 경우에는 구축을 우선한다.
사고 방식의 전환
가장 어려운 부분은 프로세스가 아니라 심리다. 우리는 “두 번 재고 한 번 자른다”는 신중한 계획을 가치 있게 여기도록 훈련받았다. 버릴 수도 있는 무언가를 만드는 것이 잘못된 것처럼 느껴진다. AI 덕분에 “자르는” 비용이 10배 감소했으니, 옛 지혜를 업데이트해야 한다.
한 번 재고, 자르고, 평가하고, 필요하면 다시 자른다.
무모한 것이 아니라, 새로운 제약 하에서 효율적인 접근이다.
요약
| 기존 모델 | 새로운 모델 |
|---|---|
| 계획은 투자이다 | 계획은 가설이다 |
| 구축은 비용이 많이 든다 | 구축은 저렴하다 |
| 재작업은 낭비다 | 재작업은 학습이다 |
| 시작하기 전에 완벽함 | 가능한 한 빨리 평가 가능 |
| 사양 중심 | 평가 중심 |
AI가 구축을 빠르게 만들 때, 최적 전략은 완벽하게 계획하기에서 시도하고 개선하기로 전환됩니다.
구축할 수 있는 것을 계획하지 마세요. 배워야 할 것을 구축하세요.
이 내용은 “Beyond Prompt Engineering” 시리즈의 일부로, 구조적·문화적 접근 방식이 AI‑지원 개발에서 프롬프트 최적화를 능가하는 방식을 탐구합니다.