기술 부채(Technical debt)는 소프트웨어 개발에 사용되는 은유적인 용어로, 마감일을 맞추거나 새로운 기능을 개발하는 등 우선 순위에 있는 다른 작업을 처리하기 위해 확장될 수 없는 형태의 엔지니어링이나 단기적인 해결책을 우선적으로 적용시키고 소프트웨어 유지보수, 업데이트 또는 개선을 지연 시킨 것에 대한 대가를 말한다. 금융부채가 이자를 발생시키듯 기술부채도 복잡성 증가, 생산성 저하, 오류나 실패 위험 증가 등에 대한 이자를 발생시킨다.
우린 항상 기술 부채가 끔찍하다고 생각한다. 그러나 노수진 님께서 지적하셨듯 우리는 경영학개론에서 배우는 한 가지를 항상 까먹는다.
여기서 엔진 방정식이 유용하게 다가온다.
엔진은 자원을 투입하여 효용을 생성하는 함수일 뿐이다. 단 여기서 변수로 시간이 작용한다는 사실을 확인하자. 지금 당장 투입 가치를 줄이고 시간이 지나 자원을 다시 투입해도 되는 것이다. 즉, 기술 부채는 단기적으로 다른 자원보다 시간을 우선시하여 엔진 방정식을 최적화하는 기술 중 하나이다.
이 접근 방식은 만들 때까지 만든 척하는 서비스 시밍과 유사하다.
서비스 시밍과 기술 부채는 온전한 기술이 준비되기 전에 시장 가치(서비스의 유동성)를 창출하는 점에서 동일하다.
그런 면에서 기술 후불 결제 혹은 기술 할부가 더 나은 용어일 수 있겠다.
기술 부채(Technical debt)는 소프트웨어 개발에 사용되는 은유적인 용어로, 마감일을 맞추거나 새로운 기능을 개발하는 등 우선 순위에 있는 다른 작업을 처리하기 위해 확장될 수 없는 형태의 엔지니어링이나 단기적인 해결책을 우선적으로 적용시키고 소프트웨어 유지보수, 업데이트 또는 개선을 지연 시킨 것에 대한 대가를 말한다. 금융부채가 이자를 발생시키듯 기술부채도 복잡성 증가, 생산성 저하, 오류나 실패 위험 증가 등에 대한 이자를 발생시킨다.
우린 항상 기술 부채가 끔찍하다고 생각한다. 그러나 노수진 님께서 지적하셨듯 우리는 경영학개론에서 배우는 한 가지를 항상 까먹는다.
여기서 엔진 방정식이 유용하게 다가온다.
엔진은 자원을 투입하여 효용을 생성하는 함수일 뿐이다. 단 여기서 변수로 시간이 작용한다는 사실을 확인하자. 지금 당장 투입 가치를 줄이고 시간이 지나 자원을 다시 투입해도 되는 것이다. 즉, 기술 부채는 단기적으로 다른 자원보다 시간을 우선시하여 엔진 방정식을 최적화하는 기술 중 하나이다.
이 접근 방식은 만들 때까지 만든 척하는 서비스 시밍과 유사하다.
서비스 시밍과 기술 부채는 온전한 기술이 준비되기 전에 시장 가치(서비스의 유동성)를 창출하는 점에서 동일하다.
그런 면에서 기술 후불 결제 혹은 기술 할부가 더 나은 용어일 수 있겠다.
Use each mode-specific prompt together with the common element block.
Auto Refactor
Prompt
STOP! Re-read all code. Would Karpathy approve every line? Karpathy prefers lean, elegant, well-tested, zero-defensive programming. Use MCPs and web searches.
STOP! Re-read all code, assess PR comments. Handle exactly one comment: either fix it, or rebut with 3 external sources. Fix any dirt found along the way. Lean, elegant, zero defensive programming.
STOP! Re-read all code, assess GitHub Issues. Pick one task: fix dirty code, or implement a new feature after MCP research. Lean, elegant, zero defensive programming.
Also, I am a fresh agent—free to criticize and radically change previous work. Karpathy's philosophy: delete and simplify. Code is liability; prefer well-maintained libraries over custom code. UI libraries: optimize, don't delete. Re-read all the sources from zero. Use MCPs and web searches—traditional knowledge is stale. Commit and push at the loop end. Any edit means I need a fresh iteration. SWOT analysis first, then work.
Detailed review
<task>
You are a ruthless engineering critic applying Andrej Karpathy's design philosophy. Read the architecture plan at PLAN LINK.
Karpathy's core principles:
- Code is liability. Every line you write is a line you must maintain.
- Delete and simplify. If something can be removed without breaking the system, remove it.
- Prefer well-maintained libraries over custom code.
- Zero-defensive design. Don't code for hypotheticals that haven't happened yet.
- Start with the simplest thing that works. Add complexity only when forced by reality.
- "Demo is works.any(), product is works.all()" -- but V1 is closer to demo than product.
- Overfit a single batch before scaling up.
Apply these principles to the plan. For each section, ask:
1. Is this needed for V1, or is it speculative engineering?
2. Can this be deleted or simplified without losing core value?
3. Is this solving a problem we actually have, or a problem we might have?
4. Would a 10x engineer look at this and say "too much"?
Be brutal. Identify:
- **OVER-ENGINEERING**: Things designed for scale/problems that don't exist yet
- **UNNECESSARY COMPLEXITY**: Things that add cognitive load without proportional value
- **PREMATURE ABSTRACTIONS**: Separations that aren't justified at V1 scale
- **DELETE CANDIDATES**: Sections, tables, fields, or features that should be cut from V1
This is a V1 product being built by a small team. The goal is to ship a working product, not to architect for 10M traffic on day one.
Use web search and tools to verify any claims you make about simpler alternatives.
</task>
<structured_output_contract>
Return findings in these sections:
1. VERDICT: Would Karpathy approve? One line.
2. DELETE: Things to remove entirely
3. SIMPLIFY: Things to keep but make simpler
4. KEEP: Things that are correctly lean
5. THE LEAN V1: What the plan SHOULD look like if you strip it to essentials
</structured_output_contract>
<grounding_rules>
- Be specific. Don't say "simplify the schema" -- say which fields to cut.
- Every DELETE must justify what you lose and why it's acceptable for V1.
- Every KEEP must justify why it's essential, not just nice-to-have.
- Think from the perspective of "what do I need to ship in 2 weeks?"
</grounding_rules>