AI가 당신의 사고를 대신하게 두지 마라 — 엔지니어를 위한 실용 가이드
AI에게 당신의 사고를 넘기지 마라
실행이 쉬워질수록, 사고는 조용히 줄어든다 — 엔지니어를 위한 실용 가이드
이 글이 말하는 네 가지
- AI로 코드 생성이 빨라질수록, 엔지니어가 사고를 단련할 기회인 디버깅·추론·씨름의 순간이 압축되거나 건너뛰어진다. 속도는 이해와 같지 않다.
- 여러 연구가 AI에 크게 의존하는 학습자는 새로운 기술 형성이 줄어든다는 '인지 오프로딩(cognitive offloading)' 현상을 보고하고 있다. 핵심은 AI를 피하는 것이 아니라, 사고를 유지하는 방식으로 사용하는 것이다.
- 저자는 5년간 주니어에서 시니어 엔지니어로 성장하며 얻은 교훈을 바탕으로 15개 성찰 연습을 담은 'Thinking in the Age of AI' 가이드를 제작했다. 각 연습은 2~5분짜리다.
- 대표 도구인 'AI Dependency Detector'는 4단계 자가진단을 통해 AI가 당신의 사고를 강화하는지, 대체하는지를 판단하도록 돕는다.
누가 이 글을 썼는가
워릭 대학교(University of Warwick) 출신의 소프트웨어 엔지니어로, 현재 토론토를 거점으로 활동한다. 주니어에서 시니어로 성장하는 5년 동안 핀테크 분야에서 실무 경험을 쌓았으며, 특히 스웨덴 기반 글로벌 핀테크인 Klarna에서 시니어 엔지니어로 재직하며 수백만 고객의 선제적 신원 확인 시스템을 설계·구축한 것으로 알려져 있다.
2025년부터는 개발자용 저널링 앱 Jots를 창업해 운영 중이다. Jots는 개발자가 AI 시대에도 성찰과 성장을 이어갈 수 있도록 돕는 도구로, 이 글에서 소개하는 사고 가이드와 철학을 같은 맥락 위에 둔다.
그의 글쓰기와 프로젝트를 관통하는 주제는 일관되다 — "AI 시대에 엔지니어가 어떻게 판단력과 직관을 계속 키워갈 수 있는가." 그는 기술 회의론자가 아니며, 오히려 AI 네이티브 도구를 적극적으로 만든다. 하지만 AI를 쓰는 방식이 사고를 강화하느냐 대체하느냐에 대해서는 분명한 입장을 갖고 있다.
AI에게 당신의 사고를 넘기지 마라 — 엔지니어를 위한 실용 가이드
AI 의존도 자가진단
엔지니어를 위한 '사고 가이드(Thinking Guide)'를 설계했다. 그리고 지금 당신의 피드백을 구하고 있다.
우리는 지금 소프트웨어 엔지니어링의 새로운 시대로 들어서고 있다.
코드는 이제 즉시 생성된다. 함수 전체, 컴포넌트, 심지어 시스템까지 몇 초 만에 뼈대가 잡힌다.
이것은 거대한 기회다.
하지만 최근 계속 생각하게 되는 미묘한 트레이드오프가 하나 있다.
실행이 쉬워질수록, 사고는 조용히 줄어들 수 있다.
우리가 덜 유능해져서가 아니다. 우리를 억지로 생각하게 만들던 순간들 — 디버깅, 씨름, 추론 — 이 이제 압축되거나 아예 건너뛰어지고 있기 때문이다.
그 어느 때보다 빠르게 출시할 수 있다.
그러나 속도만으로는 이해가 쌓이지 않는다.
여러 연구는 AI 도구에 대한 과도한 의존이 인지적 노력을 줄이고, 비판적 사고를 약화시키며, 장기적 학습을 저해할 수 있다고 시사한다. 이것들은 모두 인지 오프로딩(cognitive offloading)의 한 형태다.
Psychology Today에 실린 최근 실험 학습 연구("Cognitive Offloading: Using AI Reduces New Skill Formation")는, 복잡한 기술(예: 코딩 보조)을 습득하는 과정에서 AI에 크게 의존한 학습자들이 같은 과제를 AI 없이 수행한 학습자들보다 훨씬 적은 수의 새로운 기술을 형성했다고 보고했다. 저자들은 학습을 목표로 한 과제에서 핵심 단계를 AI에 넘기면 기술 형성이 "상당히 줄어든다"고 결론지었으며, 독립적 숙련도가 충분히 쌓이기 전에는 AI 지원을 유예할 것을 권장한다.
핵심은 AI를 피하라는 것이 아니다. AI가 당신의 사고를 대체하지 않고, 계속 생각하게 만드는 방식으로 쓰라는 것이다.
왜 이 가이드를 썼는가
지난 몇 년 동안 나는 경력이 전혀 없던 신입에서 시니어 소프트웨어 엔지니어가 되기까지 5년을 보냈다. 그 사이에 나 자신의 프로젝트도 만들고 런칭했다.
그 과정에서 깨달은 한 가지가 있다.
성장은 더 많은 코드를 쓴다고 오지 않았다.
내가 쓴 코드를 되돌아보는 데서 왔다.
이슈를 디버깅한 뒤, 어떤 단서가 나를 근본 원인으로 이끌었는가? 시스템을 설계한 뒤, 어떤 트레이드오프를 감수했는가? AI를 쓴 뒤, 나는 그것이 생성한 것을 실제로 이해했는가?
그래서 나는 일 주변에 작은 성찰 습관을 만들기 시작했다. 시간이 지나면서 이것은 구조화된 시스템이 되었고, 최근 나는 그 시스템을 하나의 가이드로 묶었다. 이름은 "Thinking in the Age of AI"다.
목표는 단순하다. 엔지니어가 AI 도구를 사용하면서도 자신의 판단력과 직관을 계속 발전시킬 수 있도록 돕는 것.
어떻게 사용하는가
이 가이드는 한 번 읽고 잊는 것이 아니다. 일하는 동안 짧은 순간에 꺼내 쓰도록 설계되었다. 대부분의 연습은 2~5분이면 끝난다. 총 15개 연습.
전부 사용할 필요는 없다. 먼저 하나의 도구를 골라 꾸준히 적용하라. 핵심은 더 많이 성찰하라가 아니라, 의도적으로 성찰하라는 것이다.
예시 1 — AI 의존도 탐지기
가이드에 담긴 도구 중 하나는 AI가 당신의 사고를 강화하는지 대체하는지를 빠르게 평가하는 자가진단이다. 원문에서 발췌한 전체 연습은 아래와 같다.
Part 1 — 빠른 자가진단
각 항목이 자주 해당된다면 체크하라.
- 문제를 직접 생각해보기 전에 AI를 먼저 쓴다.
- AI가 생성한 코드를 충분히 읽지 않고 붙여넣는다.
- AI가 만든 해법을 나중에 설명하기 어렵다.
- 예전엔 혼자 풀 수 있던 문제에도 AI에 의존한다.
- AI 생성 코드를 내 스타일로 다시 쓰는 일이 드물다.
- AI 없이 비슷한 문제를 푸는 것이 불편하게 느껴진다.
- 완전히 이해하지 못한 AI 해법도 받아들인다.
- 어려운 인지적 노력을 피하기 위해 AI를 쓴다.
결과 해석
| 0–2개 | AI가 당신의 사고를 가속하고 있을 가능성이 높다. |
| 3–5개 | 사용을 관찰하고, 일부러 마찰(friction)을 다시 도입하라. |
| 6개 이상 | 한동안 독립적 문제 해결 시간을 의도적으로 늘릴 것. |
Part 2 — 의존 신호
다음 질문에 스스로 답하라.
AI를 쓸 수 없을 때, 비슷한 문제를 푸는 데 얼마나 자신이 있는가?
지난 몇 달 동안 독립적 디버깅 능력은 어떻게 변했는가?
- 향상되었다
- 그대로다
- 쇠퇴했다
내일 AI가 내 워크플로우에서 사라진다면, 가장 먼저 약해질 능력은?
________________________________________
Part 3 — 인지 강도 체크
AI 사용 직후, 코드를 보지 않고 답해보라.
- 로직을 단계별로 설명할 수 있는가?
- 엣지 케이스를 짚어낼 수 있는가?
- 시간·공간 복잡도를 추론할 수 있는가?
- 해법을 자신 있게 수정할 수 있는가?
여러 항목에 "아니오"라면, 그것은 실패가 아니라 신호다.
Part 4 — 조정 계획
의존이 커지는 게 보인다면, 교정 행동을 하나 택하라.
- AI를 쓰기 전 5–10분 스스로 해법을 시도한다.
- AI 생성 코드를 내 언어로 다시 쓴다.
- 해법을 생성한 뒤 소리 내어 설명한다.
- 제약 조건을 명확히 정의한 뒤에만 AI를 쓴다.
- 특정 카테고리(예: 디버깅)에서는 AI 사용을 제한한다.
예시 2 — 성찰 프롬프트 카드
나는 엔지니어링 주제별로 프롬프트 카드 세트도 만들었다. 시스템 디자인, 디버깅·장애, 학습, 승진·임팩트, AI 사용 — 다섯 영역이다. 카드를 출력해 책상 위에 둔다. 제품을 만드는 동안 적절한 카드를 뽑아 스스로에게 올바른 질문을 던진다.
예를 들면 이런 질문들이다.
- 여기서 나는 어떤 트레이드오프를 의식적으로 감수했는가?
- 무엇이 나를 근본 원인으로 이끌었는가?
- 처음부터 다시 만든다면 무엇을 다르게 할 것인가?
이 작은 질문들이 시간이 지나면서 쌓이고 직관이 된다.
피드백을 구한다
가이드는 무료로 배포 중이다(원하는 가격을 0으로 설정하면 된다). 유용하다고 느낀다면 자발적 후원은 환영이지만, 필수는 아니다. 내가 정말 원하는 것은 다른 엔지니어들의 피드백이다. 특히 이런 질문들.
- 어떤 연습이 유용했고, 어떤 것이 불필요했나?
- 무엇이 빠져 있는가?
- 이것이 당신의 실제 워크플로우에 어떻게 맞는가?
그리고 당신에게 묻고 싶다
당신은 어떻게 AI 도구에 사고의 속도를 맞추고 있는가? 어떤 습관이나 시스템을 갖고 있는가?
AI는 코드를 생성할 수 있다. 그러나 눈에 띄는 엔지니어는 AI를 쓰면서도 깊이 사고하는 사람들일 것이다.
그것이 내가 만들고 있는 것이다. 이 가이드는 나를 돕고 있다. 당신에게도 도움이 되기를.
핵심 용어 정리
| 용어 | 설명 |
|---|---|
| 인지 오프로딩Cognitive Offloading | 인지적 부담을 외부 도구(계산기, 검색엔진, AI 등)로 이전하는 행위. 단기적으로는 효율을 높이지만, 학습 중일 때 핵심 단계를 오프로딩하면 새 기술 형성이 줄어든다는 연구가 있다. 사고를 확장하는 쓰임과 사고를 대체하는 쓰임을 구분하는 것이 핵심. |
| 기술 형성Skill Formation | 반복적 시도·피드백·교정을 통해 뇌 속에 절차적 지식이 축적되는 과정. 이 과정의 '마찰'이 AI로 압축될 때 출력물은 유지되지만 내면의 기술 형성은 약해진다. |
| 의도적 마찰Deliberate Friction | 학습과 이해를 위해 일부러 속도를 늦추거나 AI 사용을 미루는 전략. 'AI 쓰기 전 5–10분 혼자 시도', 'AI 코드 내 언어로 다시 쓰기' 같은 연습이 여기 속한다. |
| AI 사용 모드Modes of AI Use | 댓글에서 독자 Leonidas Williamson이 제안한 분류. 생성(Generation)은 인지 오프로딩 위험이 높고, 설명(Explanation)과 검토(Review)는 낮으며, 스캐폴딩(Scaffolding)은 시간만 절약한다. 어떤 모드로 AI를 쓰고 있는지 자각하는 것이 중요. |
| 사고 가이드Thinking Guide | 저자가 제작한 15개 연습 모음. 각 2~5분짜리의 짧은 성찰 도구로, AI 의존도 진단부터 시스템 설계·디버깅·학습·커리어 반성까지 엔지니어링 전반을 다룬다. |
| Jots | 저자가 창업한 개발자용 저널링 앱. AI를 활용해 사용자의 저널에서 개발자 맞춤형 성찰·학습 프롬프트를 제공한다. 이 글에서 제시된 철학이 제품화된 형태. |
원문 주장 검증
본문이 놓친 관점들
"사고는 사라지는 게 아니라 위로 이동한다"는 반론
원문 댓글 중 Mykola Kondratiuk(PM 디렉터)가 던진 짧은 반론은 이 글의 전제 자체를 흔든다. AI가 실행을 처리하면 사고가 줄어드는 것이 아니라 상류(upstream)로 이동한다는 관점이다. 어떻게 만들까 대신, 이것을 만들어야 하는가가 즉시 중심 질문이 된다.
이 견해는 원문이 충분히 다루지 않은 측면을 드러낸다. 저자의 프레임이 개별 엔지니어의 사고 근육에 맞춰져 있다면, 이 반론은 사고의 층위 자체가 재배치된다는 시스템적 관점이다. 두 견해는 배타적이지 않다 — 실행 쪽 근육은 위축될 수 있고, 동시에 판단·기획 쪽 근육은 더 빨리 요구될 수 있다. 각자 훈련해야 할 것이 다를 뿐이다.
개인 성찰의 한계 — 팀 레벨의 사각지대
원문이 제시한 15개 연습은 전부 개인 단위다. 하지만 AI 의존이 가장 문제적으로 발현되는 지점은 종종 팀 레벨이다. AI가 쓴 코드가 리뷰에서 쉽게 통과되고, 팀원이 이해하지 못한 채 머지되고, 그 결과 누구도 이해하지 못하는 코드베이스가 조용히 자라난다.
댓글에서 Leonidas Williamson이 제안한 실무 장치들 — 'AI가 놓친 것은 무엇이었는가'를 묻는 포스트모템, AI 사용 코드에는 왜 그 접근을 선택했는지를 주석으로 남기게 하는 리뷰 룰, 주니어 앞에서 일부러 AI 없이 디버깅하는 세션 — 이 저자의 개인 연습보다 조직적으로 더 큰 영향을 줄 수 있다. 가이드의 다음 버전은 팀 의례로 확장될 필요가 있다.
모드 구분: 단순한 분류가 아니라 인지 비용의 지도
원문 본문은 "AI를 어떻게 쓸 것인가"를 다루지만 쓰임의 종류를 구분하지는 않는다. 댓글에서 독자들이 보충한 구분 — 생성(Generation) / 설명(Explanation) / 검토(Review) / 스캐폴딩(Scaffolding) — 은 사실 가이드의 핵심 축이 되어야 할 만큼 중요하다.
이해하기 전의 생성은 위험하고, 시도한 후의 설명은 학습을 증폭한다. 같은 AI, 같은 프롬프트라도 시점이 다르면 인지 비용이 정반대다. 이는 최근 학술 연구(PMC12255134)가 보고한 "깊은 대화 vs 즉답 구하기"의 구분과 정확히 일치한다. 실용 가이드의 다음 단계는 각 상황에서 어떤 모드가 적절한지를 판단하는 의사결정 트리다.
주니어에게 이 조언은 그대로 적용되지 않는다
저자는 "경력 없는 신입에서 5년 만에 시니어"라는 본인의 궤적을 전제로 글을 쓴다. 그러나 저자가 겪은 성장의 마찰 — 디버깅으로 밤을 새고, 설계를 고민하며 씨름한 경험 — 은 오늘 신입이 동일한 AI 환경에서 재현하기 어렵다. 저자에게 AI는 이미 형성된 근육을 보조하는 도구였지만, 오늘 신입에게 AI는 형성되어야 할 근육을 대체하는 도구가 되기 쉽다.
팩트체크 세 번째에서 인용한 연구가 바로 이 지점을 지적한다. '사고 가이드'의 실효성도 그 사람이 이미 어느 정도 독립적 문제 해결을 경험해봤느냐에 달려 있다. 주니어에게 먼저 필요한 것은 성찰 연습이 아니라, AI를 의도적으로 끄고 작업하는 시간을 제도적으로 확보하는 환경일지 모른다.
도구 제작자의 자기 모순 — 그리고 그것이 갖는 신뢰성
저자는 AI로 코딩하는 제품을 만드는 창업자이면서 동시에 AI 의존을 경계하는 글을 쓴다. 표면적으로는 모순처럼 보이지만, 바로 이 위치가 이 글의 신뢰성을 만든다. 순수 반-AI 진영의 경고는 쉽게 무시되고, 순수 AI 낙관론은 이런 성찰을 하지 않는다. AI 도구를 적극적으로 쓰고 만드는 사람이 같은 도구의 인지적 비용을 걱정하는 것 — 이 긴장이 이 글을 실제로 유용하게 만든다.
더 나아가 이것은 AI 시대에 진지한 기술자가 갖춰야 할 자세의 한 예시이기도 하다. 도구에 열광하면서도 그 도구가 당신에게 무엇을 하는지 관찰할 것. 두 시선을 동시에 유지하는 능력 자체가 이 글이 말하는 '사고'의 실체일지 모른다.