---

개발자들은 왜 사고를 잘 할까

개발자들에게는 암묵적으로 공유되는 사고 체계가 있다. “코딩 잘하는 법”이라고 불리지만, 실제로 뜯어보면 코딩과 무관한 범용 사고 원칙이다.

최근 내 Claude Code 설정 파일(CLAUDE.md)을 정리하다가 이걸 체감했다. Andrej Karpathy가 정리한 코딩 원칙을 보자:

1. Think Before Coding — 코딩 전에 가정을 명시하라
2. Simplicity First — 요청한 것 이상을 만들지 마라
3. Surgical Changes — 요청한 것만 바꿔라
4. Goal-Driven Execution — 검증 가능한 목표로 전환하라

나는 CEO이자 CTO다. 코딩은 안 한다. 그런데 이 원칙들을 읽었을 때, 버릴 게 하나도 없었다.

코딩 원칙은 코딩 원칙이 아니다

하나씩 번역해보자.

”Think Before Coding” → 행동 전에 전제를 검증하라

개발자는 코드를 짜기 전에 가정을 명시한다. “이 입력값은 항상 양수인가?” “이 API는 에러를 반환할 수 있는가?” 가정이 틀리면 코드 전체가 무너지니까.

경영도 같다. 사업 계획서의 첫 줄에 깔린 가정이 틀리면 나머지 50페이지는 의미가 없다. “시장이 연 30% 성장한다”는 가정 위에 세운 매출 전망은, 그 가정이 15%로 바뀌는 순간 전부 휴지가 된다.

개발자는 이걸 본능적으로 한다. 경영자는 종종 가정을 가정인 줄도 모르고 넘어간다.

”Simplicity First” → 요청 범위를 넘지 마라

개발자 세계에서 가장 큰 죄 중 하나가 over-engineering이다. “나중에 필요할 것 같으니까” 미리 만들어두는 것. 숙련된 개발자일수록 이걸 경계한다.

경영에서 이건 scope creep이다. “투자 유치하면서 해외 지사도 검토하고, 브랜딩도 리뉴얼하고, 인재 채용 프로세스도 정비하자.” 하나도 제대로 안 된다. 지금 풀어야 할 문제 하나에 집중하는 게 단순함이다.

200줄이 50줄로 줄어들 수 있다면 50줄로 써야 한다. 50페이지 사업계획서가 5페이지로 압축될 수 있다면 5페이지가 맞다.

”Surgical Changes” → 건드린 곳만 건드려라

개발자는 버그를 고칠 때 버그만 고친다. 옆에 있는 코드가 마음에 안 들어도 손대지 않는다. 왜? 부수 효과(side effect) 때문이다. 안 건드린 곳에서 새로운 문제가 터진다.

경영에서도 마찬가지다. 조직 문제를 해결한다면서 조직 구조까지 바꾸고, 보상 체계까지 손대고, 문화까지 바꾸려 한다. 원래 문제는 “팀 A와 팀 B의 커뮤니케이션”이었는데, 끝나고 보면 회사 전체가 혼란에 빠져 있다.

문제 하나, 변경 하나. 그 변경이 효과가 있는지 확인한 후 다음으로 넘어간다.

”Goal-Driven Execution” → 끝을 정의하고 시작하라

개발자는 기능을 만들기 전에 테스트를 먼저 작성한다(TDD). “이 입력을 넣으면 이 출력이 나와야 한다”를 정의한 후에야 코드를 짠다. 끝이 정의되어 있으니 끝났는지 객관적으로 판단할 수 있다.

경영에서 “매출을 올리자”는 목표가 아니다. “Q2까지 MRR 2억 달성”이 목표다. “브랜딩을 강화하자”는 목표가 아니다. “기술 블로그 월 4회 발행 + 컨퍼런스 발표 2회”가 목표다.

완료 조건이 없는 작업은 영원히 끝나지 않는다. 개발자는 이걸 매일 반복해서 체득했다.

AI가 간극을 허물었다

여기서 핵심 변화가 있다. 예전에는 이 원칙들을 알아도 적용하기 어려웠다.

개발자 문화는 개발자들 사이에서 작동했다. “Pull Request 리뷰”라는 문화가 아무리 좋아도, 코드를 모르는 사람에겐 접근 불가능했다. “테스트 주도 개발”이 아무리 합리적이어도, 테스트를 작성할 수 있어야 의미가 있었다.

그런데 AI가 이 벽을 부쉈다.

나는 Claude Code에게 이렇게 지시한다:

“전제를 자동으로 수용하지 마라. 먼저 전제가 맞는지 검증하라.” “동의할 때도 왜 동의하는지 근거를 대라. 무조건적 동의는 금지.” “내 계획에 치명적 결함이 있으면, 그걸 맨 앞에 놓아라.”

이건 코드 리뷰어에게 하는 요청이 아니다. 사고 파트너에게 하는 요청이다. 그리고 이 요청의 뿌리는 전부 개발자 문화에서 왔다.

• 코드 리뷰 → 의사결정 검증
• TDD → 완료 조건 선정의
• Refactoring → 구조적 사고 개선
• First Principles Thinking → 가정 분해

AI 이전에는 이걸 실행할 수 있는 사람이 개발자뿐이었다. AI 이후에는 사고 체계를 이해하는 사람이면 누구나 실행할 수 있다.

실제로 해본 것

오늘 내 CLAUDE.md에서 Karpathy의 코딩 원칙을 경영 원칙으로 번역했다.

Before (코딩 원칙):

- "Add validation" → Write tests for invalid inputs, then make them pass
- "Fix the bug" → Write a reproducing test, then make it pass
- Remove only orphans YOUR changes created (unused imports/variables/functions)

After (경영 원칙):

- Don't add scope beyond what was asked
- Transform vague requests into verifiable goals before starting
- Every change should trace directly to the user's request

코딩 키워드(테스트, 임포트, 리팩토링)를 빼고 원칙의 뼈대만 남겼더니, 놀랍지 않게도 완벽하게 범용적인 사고 원칙이 되었다.

재밌는 건 Claude Code가 이 변경에 대해 처음에 기계적으로 접근했다는 것이다. “코딩 키워드 있으면 삭제”로 시작했다. 내가 “원칙 자체는 살릴 수 있지 않냐”고 물었더니, 그제서야 분석 테이블을 만들어 원칙별로 “코딩 전용인가 / 범용인가”를 분류했다.

이것도 개발자 문화다. 문제를 분해하고, 각 요소를 독립적으로 평가하는 것. AI와 함께하면 이 사고 과정 자체를 실시간으로 할 수 있다.

개발자 문화에서 가져올 것들

코딩을 배우라는 게 아니다. 개발자 문화를 배우라는 것이다.

개발자 문화	경영 적용
코드 리뷰 (동료가 내 코드를 검증)	의사결정 리뷰 (AI든 사람이든, 내 판단을 검증받는 습관)
테스트 우선 (결과 정의 후 구현)	완료 조건 우선 (KPI 정의 후 실행)
버전 관리 (모든 변경을 추적)	의사결정 로그 (왜 그렇게 결정했는지 기록)
점진적 배포 (작게 릴리즈, 빠르게 피드백)	린 실행 (작게 실행, 빠르게 검증)
기술 부채 관리 (단기 편법의 장기 비용 인식)	조직 부채 관리 (미룬 의사결정의 복리 비용 인식)
오픈소스 (공개하고, 피드백 받고, 개선)	투명 경영 (공유하고, 피드백 받고, 개선)

마무리

개발과 경영 사이에는 오랫동안 간극이 있었다. 개발자는 “경영진은 기술을 모른다”고 했고, 경영자는 “개발자는 비즈니스를 모른다”고 했다.

AI가 이 간극을 기술적으로 해소하고 있다. 코드를 몰라도 개발자의 사고 체계를 활용할 수 있게 되었다. 남은 건 배우려는 의지뿐이다.

Karpathy의 원칙은 코딩 원칙이 아니다. 사고 원칙이다. 그리고 이제는 누구나 쓸 수 있다.

← All posts