디지털 중독, 정보 중독이라 말한다면 하루 이틀 일이 아니다. 하지만 여전히 많은 사람들이 정보 중독 문제를 앓고 있다. 디지털 기기를 향정신성 의약품이라고 정의한다면 접근 방식을 조금 달리 할 수 있지 않을까. 대한민국에서 향정신성 의약품은 다음과 같이 정의된다.
제2조(정의) 향정신성의약품이란
① 인간의 중추신경계에 작용하는 것으로서
② 이를 오용하거나 남용할 경우 인체에 심각한 위해가 있다고 인정되는 다음 각 목의 어느 하나에 해당하는 것.
컴퓨터임이 느껴지는가? 몇 가지 관찰을 해보자.
기기 자체의 중독성.
화려한 인터페이스는 중독성을 준다.
알록달록한 색깔과 팝팝 튀는 진동, 부드러운 애니메이션과 지속적인 알림은 우리의 관심을 끊임없이 요구한다.
스크린 타임, 알림 요약, 방해 금지 모드와 색상 필터 (흑백), 애니메이션 비활성화, 진동 비활성화 등의 접근성 기능들을 활용해서 기기의 중독성을 제어하자.
서비스의 중독성.
이를 의존성 설계라고 부른다.
서비스들은 자신들의 수익을 늘리기 위해서 여러 심리적 전략을 사용한다.
즉석 도파민을 제조하는 좋아요부터, 바이럴 콘텐츠, 무한 스크롤, 자동 재생, 개인 맞춤 피드 등이 그 예시이다.
Potential의 "주의력 설정" 제안에서 이들의 문제와 플랫폼 운영자 입장에서 잠재적 해결 방안을 제안한다.
그렇다면 일반인의 입장에서는 무엇을 할 수 있을까?
우선, 휴대전화에서 이 서비스들을 사용하지 않는다.
휴대전화는 접근성이 너무 좋으며 프로그램을 변조할 수 없어 서비스 제공자가 원하는대로만 앱을 사용할 수 있다.
컴퓨터에서 이 서비스들을 사용하면 확장 프로그램들을 적극적으로 활용해 침략적인 중독성을 조절하자.
디지털 중독.
디지털 중독은 스스로 치료할 수 없다는 것을 인지하는 것부터 시작하자.
중독자는 자신이 중독자인지 모른다.
하루하루 중독자의 인생을 살아가면서 오늘의 도즈 「dose」 를 몸에 밀어넣는 삶을 살아갈 뿐이다.
때문에 근처에 누군가 디지털 기기에 대해 문제를 가지고 있는 것 같다면 적극적으로 도와주자.
반대로 이야기하면 내 디지털 체류 시간이 비정상적으로 길게 느껴진다면 아직 나에게는 스스로 해결할 수 있는 희망이 있다는 뜻이다.
더 늦기 전에 적극적으로 관찰하고 대응하자.
근데 넌 컴퓨터과학자잖아?
혹자는 나를 "컴퓨터로 밥벌어먹고 사는 사람이 컴퓨터의 무궁한 발전을 기원하지 않고 이게 무슨 오만함인가!"라고 소프트웨어 엔지니어가 디지털 기기를 거짓되게 비난한다고 얘기할 수 있다. 하지만 하나의 물자체 그 스스로와 그 물자체의 광적 파괴성은 분리되어 고려되는 것이 마땅하다. 나는 주로 이를 원자력에 비유한다. 핵물리학에 매력을 느끼는 과학자가 원자폭탄의 파괴성까지 지지하는 것은 아니다. 마찬가지로, 컴퓨터과학에 매력을 느끼는 엔지니어가 인간의 사고력을 서서히 침식시키는 기계의 조용한 침공까지 지지하는 것은 아니다.
All of humanity's problems stem from man's inability to sit quietly in a room alone.
디지털 중독, 정보 중독이라 말한다면 하루 이틀 일이 아니다. 하지만 여전히 많은 사람들이 정보 중독 문제를 앓고 있다. 디지털 기기를 향정신성 의약품이라고 정의한다면 접근 방식을 조금 달리 할 수 있지 않을까. 대한민국에서 향정신성 의약품은 다음과 같이 정의된다.
제2조(정의) 향정신성의약품이란
① 인간의 중추신경계에 작용하는 것으로서
② 이를 오용하거나 남용할 경우 인체에 심각한 위해가 있다고 인정되는 다음 각 목의 어느 하나에 해당하는 것.
컴퓨터임이 느껴지는가? 몇 가지 관찰을 해보자.
기기 자체의 중독성.
화려한 인터페이스는 중독성을 준다.
알록달록한 색깔과 팝팝 튀는 진동, 부드러운 애니메이션과 지속적인 알림은 우리의 관심을 끊임없이 요구한다.
스크린 타임, 알림 요약, 방해 금지 모드와 색상 필터 (흑백), 애니메이션 비활성화, 진동 비활성화 등의 접근성 기능들을 활용해서 기기의 중독성을 제어하자.
서비스의 중독성.
이를 의존성 설계라고 부른다.
서비스들은 자신들의 수익을 늘리기 위해서 여러 심리적 전략을 사용한다.
즉석 도파민을 제조하는 좋아요부터, 바이럴 콘텐츠, 무한 스크롤, 자동 재생, 개인 맞춤 피드 등이 그 예시이다.
Potential의 "주의력 설정" 제안에서 이들의 문제와 플랫폼 운영자 입장에서 잠재적 해결 방안을 제안한다.
그렇다면 일반인의 입장에서는 무엇을 할 수 있을까?
우선, 휴대전화에서 이 서비스들을 사용하지 않는다.
휴대전화는 접근성이 너무 좋으며 프로그램을 변조할 수 없어 서비스 제공자가 원하는대로만 앱을 사용할 수 있다.
컴퓨터에서 이 서비스들을 사용하면 확장 프로그램들을 적극적으로 활용해 침략적인 중독성을 조절하자.
디지털 중독.
디지털 중독은 스스로 치료할 수 없다는 것을 인지하는 것부터 시작하자.
중독자는 자신이 중독자인지 모른다.
하루하루 중독자의 인생을 살아가면서 오늘의 도즈 「dose」 를 몸에 밀어넣는 삶을 살아갈 뿐이다.
때문에 근처에 누군가 디지털 기기에 대해 문제를 가지고 있는 것 같다면 적극적으로 도와주자.
반대로 이야기하면 내 디지털 체류 시간이 비정상적으로 길게 느껴진다면 아직 나에게는 스스로 해결할 수 있는 희망이 있다는 뜻이다.
더 늦기 전에 적극적으로 관찰하고 대응하자.
근데 넌 컴퓨터과학자잖아?
혹자는 나를 "컴퓨터로 밥벌어먹고 사는 사람이 컴퓨터의 무궁한 발전을 기원하지 않고 이게 무슨 오만함인가!"라고 소프트웨어 엔지니어가 디지털 기기를 거짓되게 비난한다고 얘기할 수 있다. 하지만 하나의 물자체 그 스스로와 그 물자체의 광적 파괴성은 분리되어 고려되는 것이 마땅하다. 나는 주로 이를 원자력에 비유한다. 핵물리학에 매력을 느끼는 과학자가 원자폭탄의 파괴성까지 지지하는 것은 아니다. 마찬가지로, 컴퓨터과학에 매력을 느끼는 엔지니어가 인간의 사고력을 서서히 침식시키는 기계의 조용한 침공까지 지지하는 것은 아니다.
All of humanity's problems stem from man's inability to sit quietly in a room alone.
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>