때는 바야흐로 2020년 1월 24일이었다.
나는 민사고를 졸업하고, 여기저기 떠돌다 집에 온지 한 1-2주 정도 지났었나?
어쨌든 그런 상황이었다.
우리 집에 이사 오며 2010년쯤 인테리어할 때 부모님은 일부러 내 방에 인터넷이 안 되게 하셨었다.
공부하는 학생들 공신폰 쓰게 하는 그런 심리였을까.
어쨌든 우리 집의 유일한 와이파이/인터넷은 제일 안방에서만 터졌고,
내 방은 대문에서 가장 가까운 방이었다.
벽 두어개는 가뿐히 넘어야하는 내 방에서는 신호가 거의 잡히지 않았다.
어느 정도였냐면 내가 새벽에 몰폰하러 안방에 가까이 서서 서있다가 부모님에게 걸렸었을 정도.
하여튼 내 방은 인터넷 음영 지대였다.
민사고를 졸업하고 미국 유학을 갈 때까지 반년 가까이 집에 있어야 했는데,
인터넷이 안 되는 방에서 산다는 것은 개발자로써 전혀 말이 되지 않았다!
또 나는 앰비언트 컴퓨팅을 중시하는 사람인데,
스마트 홈이나 라즈베리파이, 컴퓨터 등이 열심히 일을 하면서 오케스트레이트되려면
LTE나 셀룰러에 의지할 수 없었다.
예를 들어 당시에는 iCloud 백업이나 프로세싱, 자동 업데이트 등은 모바일 데이터로 할 수 없었다.
내가 아무리 생각해봐도, 우리 아파트는 엘리베이터에서 내리면 왼쪽과 오른쪽에 집 입구가 있는 그런 전형적인 아파트였는데, 내가 건물을 지어도 가운데 인터넷 배선을 깔고 나뭇가지처럼 양쪽 집으로 통하게 설계하지, 양쪽에서 2개의 배선을 깔지는 않을 것이었다.
즉, 어떤 구조로든 대문에 가까운 내 방 근처에 인터넷 배선 "상류"가 있는 것이고, 안방 와이파이까지 배선이 이어지는 구조였을 것이다.
이런 사고를 바탕으로, 내 방 근처 벽 안 어딘가에 인터넷 선이 있을 것이라는 합리적 추론을 했고,
인터넷에서 건물 도면 같은 것을 찾아보고 전화선과 TV선 포트가 있는 곳들을 하나하나 분해해보며 건드려보기 시작했다.
그 중 하나의 포트를 깊숙한 곳까지 들여다보기 위해 간이 잠망경을 만들어 뒤져봤다.
그때!
바로 위와 같은 도선을 찾았다.
거의 하루종일 집안을 뜯어보며 찾은 유레카 모멘트였다.
또 인터넷 선들이 절연테이프로 묶여 있었는데, 나는 이것이 인테리어 중 내 방에서 인터넷 포트를 없애버린 흔적이라고 판단했다.
이제 남은 일은 이 인터넷선을 다시 끊고(!) 전선 형태로 만들어 내 방에 Relay Wi-Fi 하나를 두면 될 일이었다.
그래서 그 순간 나는 다이소에 가서 랜선 하나와 그럭저럭 괜찮은 와이파이 기계를 샀다.
그 다음 내가 발견한 인터넷 선을 잘라버리고(!) 내가 사온 랜선도 잘라서(!) 둘의 구리선을 하나 하나 이어붙였다.
마지막에 절연 테이프로 감아서 안정적으로 연결되게 만든 다음,
와이파이 기계에 연결해서 내 방에 신호를 하나 쏘게 만들고,
안방으로도 신호를 Relay해서 보내줄 수 있게 연결했다.
결과는 대성공이었다.
툭 하나 잘못되면 우리 집 전체 인터넷이 고장나고, 업자를 불러서 벽을 뜯어서 배선 공사를 다시 해야하는 순간이었는데,
어쨌든 무슨 배짱인지 과감히 해버렸고 성공적으로 인터넷이 됐다.
인물 서적을 읽어보면 항상 첫 장에 "~누구누구는 어릴 적 TV를 뜯고 재조립해서 작동했다..." "~누구누구는 자동차를 분해하고 뜯어보며 학습했다..." 같은 내용이 나오는데, 나도 비슷한 일화가 생긴 것 같아서 재밌었다.
완전 어릴 적에 한 일은 아니지만, 어릴 적에 한 것보다는 스케일과 리스크가 있었다고 생각하니까 뭐 쌤쌤으로 치자.
때는 바야흐로 2020년 1월 24일이었다.
나는 민사고를 졸업하고, 여기저기 떠돌다 집에 온지 한 1-2주 정도 지났었나?
어쨌든 그런 상황이었다.
우리 집에 이사 오며 2010년쯤 인테리어할 때 부모님은 일부러 내 방에 인터넷이 안 되게 하셨었다.
공부하는 학생들 공신폰 쓰게 하는 그런 심리였을까.
어쨌든 우리 집의 유일한 와이파이/인터넷은 제일 안방에서만 터졌고,
내 방은 대문에서 가장 가까운 방이었다.
벽 두어개는 가뿐히 넘어야하는 내 방에서는 신호가 거의 잡히지 않았다.
어느 정도였냐면 내가 새벽에 몰폰하러 안방에 가까이 서서 서있다가 부모님에게 걸렸었을 정도.
하여튼 내 방은 인터넷 음영 지대였다.
민사고를 졸업하고 미국 유학을 갈 때까지 반년 가까이 집에 있어야 했는데,
인터넷이 안 되는 방에서 산다는 것은 개발자로써 전혀 말이 되지 않았다!
또 나는 앰비언트 컴퓨팅을 중시하는 사람인데,
스마트 홈이나 라즈베리파이, 컴퓨터 등이 열심히 일을 하면서 오케스트레이트되려면
LTE나 셀룰러에 의지할 수 없었다.
예를 들어 당시에는 iCloud 백업이나 프로세싱, 자동 업데이트 등은 모바일 데이터로 할 수 없었다.
내가 아무리 생각해봐도, 우리 아파트는 엘리베이터에서 내리면 왼쪽과 오른쪽에 집 입구가 있는 그런 전형적인 아파트였는데, 내가 건물을 지어도 가운데 인터넷 배선을 깔고 나뭇가지처럼 양쪽 집으로 통하게 설계하지, 양쪽에서 2개의 배선을 깔지는 않을 것이었다.
즉, 어떤 구조로든 대문에 가까운 내 방 근처에 인터넷 배선 "상류"가 있는 것이고, 안방 와이파이까지 배선이 이어지는 구조였을 것이다.
이런 사고를 바탕으로, 내 방 근처 벽 안 어딘가에 인터넷 선이 있을 것이라는 합리적 추론을 했고,
인터넷에서 건물 도면 같은 것을 찾아보고 전화선과 TV선 포트가 있는 곳들을 하나하나 분해해보며 건드려보기 시작했다.
그 중 하나의 포트를 깊숙한 곳까지 들여다보기 위해 간이 잠망경을 만들어 뒤져봤다.
그때!
바로 위와 같은 도선을 찾았다.
거의 하루종일 집안을 뜯어보며 찾은 유레카 모멘트였다.
또 인터넷 선들이 절연테이프로 묶여 있었는데, 나는 이것이 인테리어 중 내 방에서 인터넷 포트를 없애버린 흔적이라고 판단했다.
이제 남은 일은 이 인터넷선을 다시 끊고(!) 전선 형태로 만들어 내 방에 Relay Wi-Fi 하나를 두면 될 일이었다.
그래서 그 순간 나는 다이소에 가서 랜선 하나와 그럭저럭 괜찮은 와이파이 기계를 샀다.
그 다음 내가 발견한 인터넷 선을 잘라버리고(!) 내가 사온 랜선도 잘라서(!) 둘의 구리선을 하나 하나 이어붙였다.
마지막에 절연 테이프로 감아서 안정적으로 연결되게 만든 다음,
와이파이 기계에 연결해서 내 방에 신호를 하나 쏘게 만들고,
안방으로도 신호를 Relay해서 보내줄 수 있게 연결했다.
결과는 대성공이었다.
툭 하나 잘못되면 우리 집 전체 인터넷이 고장나고, 업자를 불러서 벽을 뜯어서 배선 공사를 다시 해야하는 순간이었는데,
어쨌든 무슨 배짱인지 과감히 해버렸고 성공적으로 인터넷이 됐다.
인물 서적을 읽어보면 항상 첫 장에 "~누구누구는 어릴 적 TV를 뜯고 재조립해서 작동했다..." "~누구누구는 자동차를 분해하고 뜯어보며 학습했다..." 같은 내용이 나오는데, 나도 비슷한 일화가 생긴 것 같아서 재밌었다.
완전 어릴 적에 한 일은 아니지만, 어릴 적에 한 것보다는 스케일과 리스크가 있었다고 생각하니까 뭐 쌤쌤으로 치자.
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>