# AI는 사고를 대체하지 말고 끌어올려야 함 > Clean Markdown view of GeekNews topic #28937. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28937](https://news.hada.io/topic?id=28937) - GeekNews Markdown: [https://news.hada.io/topic/28937.md](https://news.hada.io/topic/28937.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-04-27T11:34:44+09:00 - Updated: 2026-04-27T11:34:44+09:00 - Original source: [koshyjohn.com](https://www.koshyjohn.com/blog/ai-should-elevate-your-thinking-not-replace-it/) - Points: 3 - Comments: 1 ## Topic Body - **그럴듯한 산출물**을 빠르게 만들수록 이해 없는 반복이 쉬워지고, 판단력을 키우는 연습을 건너뛰면 **장기 역량**이 약해짐 - 익숙한 패턴에서는 도움이 크지만 낯선 문제, 모호한 조건, 불완전한 정보, 상충하는 제약에서는 **얕은 모방**이 쉽게 무너지고 실제 실력이 드러남 - 강한 엔지니어는 보일러플레이트, 요약, 테스트 스캐폴딩, 조사 가속 같은 **기계적 작업**은 맡기되, 문제 정의와 검토, 선택과 폐기는 **직접 소유함** - 소프트웨어 엔지니어링의 높은 가치는 코드 생산보다 **판단력**에 있고, 숨은 제약을 보고 잘못된 문제를 알아차리며 모호한 논쟁을 트레이드오프로 바꾸는 능력이 더 중요해짐 - 특히 경력 초반과 조직 운영에서는 **실제 이해**를 지키는 기준이 더 중요하며, 무엇을 위임하고 무엇을 직접 맡을지 구분할수록 AI는 사람의 가치를 키우는 도구가 됨 --- ### 사고를 외주화할 때 생기는 실패 모드 - **A.I.** 는 코드 생성, 회의 요약, 개념 설명, 설계 초안 작성, 상태 업데이트 작성 같은 작업을 빠르게 처리하지만, **이해 없이 그럴듯한 결과물만 내는 습관**도 쉽게 만들 수 있음 - 기계가 낸 답을 자기 이해인 것처럼 반복하면, 역량을 쌓지 않은 채 **유능해 보이는 상태**만 흉내 내게 됨 - 생성된 결과물로 자신의 이해를 대체할수록 판단력을 키우는 연습을 건너뛰게 되고, **장기 역량**을 **단기 외형**과 맞바꾸게 됨 - 낯선 문제, 모호한 조건, 불완전한 정보, 상충하는 제약처럼 템플릿으로 처리되지 않는 상황에서는 얕은 모방이 쉽게 무너짐 - ## 시험 답안 베끼기 비유 - 답을 베껴서 좋은 성적을 유지할 수는 있어도, 실제로 **이해가 필요한 상황**에 들어가면 기반이 비어 있음이 드러남 - 스스로 작업하며 쌓이는 직관이 없으면, 익숙하지 않은 문제를 추론하거나 조건 변화에 대응하기 어려움 - A.I.가 준 답을 반복해서 가져다 쓰면 **숙련의 외형**만 빌릴 뿐, 실제 숙련은 쌓이지 않음 - ## 계산기 비유 - 계산기는 시간을 아껴 주는 좋은 도구지만, **수 감각** 없이 의존하면 결과가 말이 되는지 점검할 수 없게 됨 - 기반이 있는 엔지니어는 A.I. 출력을 검토하고, 오류를 걸러내고, 수정하거나 폐기할 수 있음 - 기반이 없는 엔지니어는 A.I.를 쓰는 것이 아니라 **A.I.에 끌려가게 됨**, 특히 정확성과 결과 책임이 중요한 직무에서는 더 위험해짐 - ## 자율주행차 비유 - 자율주행은 피로를 줄이고 일상 상황을 처리해 주지만, 운전을 이해하기 전에 의존하면 **조작 권한만 가진 승객**에 가까워짐 - 시야 불량, 복잡한 도로, 예측 불가능한 다른 차량, 시스템 실패, 갑작스러운 위험처럼 비표준 상황에서 실제 실력이 드러남 - A.I.도 일반적 패턴과 익숙한 구조에서는 강하지만, 엔지니어링은 요구사항 변화, 미묘한 버그, 불명확한 소유권, 경쟁하는 아키텍처 목표, 부분 데이터, 조직 마찰, 완벽한 답이 없는 트레이드오프로 계속 벗어남 ### 뛰어난 엔지니어가 A.I.를 쓰는 방식 - 뛰어난 엔지니어는 A.I.를 덜 쓰는 것이 아니라 **더 적극적으로 쓰되**, 사고 자체는 넘기지 않음 - 보일러플레이트 작성, 문서 요약, 테스트 스캐폴딩 생성, 리팩터링 제안, 실패 가능성 탐색, 조사 가속, 반복 업무 압축 같은 **기계적 작업**은 기꺼이 넘김 - 대신 더 날카로운 질문을 만들고, 눈앞의 요청이 아니라 **실제 문제**를 정의하며, 실질 없는 매끈한 문장보다 **명확성과 간결함**을 우선함 - 시스템 안의 기존 지식을 재조합하는 데 그치지 않고, **새로운 고가치 지식**을 만들어 냄 - 이렇게 확보한 시간을 더 높은 수준의 사고와 판단에 다시 투자함 ### 가치의 실제 원천 - 소프트웨어 엔지니어링을 오랫동안 **코드 생산**과 동일시해 왔지만, 가장 높은 가치는 거기에 있지 않음 - 문법적으로 맞는 코드를 만드는 일만 핵심이었다면 A.I.가 직무의 큰 부분을 직접 대체하는 흐름이 되겠지만, 실제 핵심은 **판단력**에 있음 - 가치 있는 엔지니어는 장애를 일으키기 전 **숨은 제약**을 보고, 팀이 잘못된 문제를 풀고 있음을 알아차리고, 모호한 논쟁을 선명한 트레이드오프로 바꾸고, 빠진 추상화를 찾아내고, 코드가 아니라 **현실을 디버깅**함 - A.I.는 이런 작업을 지원할 수는 있어도, 그것을 대신 떠맡지는 못함 - 앞으로 더 큰 가치를 만드는 엔지니어는 A.I.가 더 유용해지도록 만드는 **설계 원칙, 도메인 이해, 패턴, 맥락, 의사결정 프레임워크**를 만들어 내는 쪽에 가까움 - 이 환경에서는 엔지니어가 A.I.에 대체되기보다, **원시 출력 위 단계**에서 일하면서 더 큰 레버리지를 얻게 됨 ### 경력 초반 엔지니어에게 더 큰 위험 - 이 문제는 특히 **경력 초반**에 더 중요함 - 초기 몇 년은 디버깅 감각, 시스템 직관, 정밀함, 취향, 회의적 검토, 문제 분해 능력, 왜 동작하는지 설명하는 능력 같은 **기초 역량**이 형성되는 시기임 - 이런 역량은 마찰, 시행착오, 실패 수정, 근본 원인 추적, 현실과 부딪히며 깨지는 경험을 통해 쌓임 - 학습 과정에서 A.I.가 모든 어려움을 제거하면, 단기 효율은 얻어도 **역량이 벼려지는 단계**를 건너뛰게 됨 - 한두 분기 동안은 효율적으로 보일 수 있어도, 미래를 떠받칠 능력을 조용히 놓치게 될 수 있음 - 지원 시스템이 기능하는 것처럼 보이게 만들 수는 있어도, **실제 능력**까지 대신 만들어 주지는 못함 ### 판단력에는 지름길이 없음 - 생성된 설명을 읽는 것만으로, 스스로 작업하지 않고도 **숙련이 머릿속으로 이전되지는 않음** - 추론을 오래 외주화해 놓고도 결국 강한 추론 능력을 갖게 되는 길은 없음 - 기계적 작업을 외주화하고, 조사 속도를 높이고, 반복 업무를 압축하는 일은 가능하며 바람직함 - 하지만 **기술 형성 과정** 자체를 건너뛰고도 그 기술을 가진 상태가 되지는 않음 - 가장 순진한 A.I. 활용의 핵심 착오는 시간을 아낀다고 생각하면서, 실제로는 **약한 판단력, 얕은 이해, 낮은 적응력**이라는 청구서를 뒤로 미루는 데 있음 ### 구분선과 조직 차원의 함의 - A.I.가 **이해를 더 빠르게 만들고**, 더 깊이 생각하게 하고, 더 높은 수준에서 일하게 돕는다면 사람의 가치가 커짐 - A.I.가 이해를 피하게 하고, 어려움을 피하게 하고, 추론의 소유권을 피하게 돕는다면 사람의 가치가 줄어듦 - 한쪽 경로는 복리처럼 쌓이고, 다른 쪽은 속을 비우며 **무관해지기 쉬운 상태**로 몰아감 - 미래는 A.I.를 단순히 사용하는 엔지니어보다, **무엇을 위임하고 무엇을 직접 소유할지** 정확히 구분하며 시간 절약을 더 나은 사고로 바꾸는 엔지니어에게 유리함 ### 조직 건강에 더 크게 작용하는 이유 - 엔지니어링 관리도 **이해를 가속하는 활용**과 **이해를 흉내 내는 활용**을 구분해야 하는 같은 경계에 서게 됨 - 강한 리더십은 매끈한 결과물과 **실제 판단력**을 구별할 수 있어야 하며, 속도·유창함·발표력만 보상하면 기술적 깊이의 신호를 놓치게 됨 - 낮은 이해와 높은 유창함의 작업이 퍼지면 개인 산출물 품질만 떨어지는 것이 아니라, 조직의 **지식 환경** 자체가 약해짐 - 리뷰는 더 약해지고 - 설계 논의는 더 얕아지고 - 문서는 더 매끈하지만 덜 유용해짐 - 시간이 지날수록 조직은 자신이 의존하는 명확성과 기술 판단을 만들어 내는 힘을 잃게 됨 - 그래서 핵심은 A.I. 도구 도입 자체보다, **실제 사고·학습·장인정신이 살아남는 조건**을 지키는 데 있음 - 채용 단계부터 겉보기 유창함이 아니라 **실제 이해**를 가려낼 방법이 필요함 - 인터뷰는 polished answer보다 **추론 과정**을 시험해야 함 - 평가는 출력량보다 **명확성, 깊이, 건전한 판단, 오래가는 기술 기여**를 보상해야 함 - 팀 설계와 문화에도 영향이 큼 - 강한 엔지니어가 사고를 외주화한 사람이 만든 **그럴듯하지만 얕은 작업**을 과도하게 정리하는 데 시간을 쓰지 않게 해야 함 - 이를 막지 못하면 높은 성과자는 자신 외의 모두를 위한 증폭기로 소모되고, 그 결과 **좌절, 기준 하락, 이탈**로 이어지기 쉬움 - A.I. 시대의 조직 품질은 결국 리더십이 **레버리지와 의존성**, **가속과 모방**, **실제 역량과 설득력 있는 출력**을 계속 구분할 수 있는지에 더 크게 달리게 됨 ## Comments ### Comment 56372 - Author: neo - Created: 2026-04-27T11:34:45+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47913650) - 이 논지를 반복해서 읽을수록 **표현의 세련됨**은 계속 좋아지는데, 아직 **경구** 단계까지는 못 갔다고 느낌 "the medium is the message", "you ship your org chart", "9 mothers can't make a baby in a month"처럼 몇 마디로 다수에게 꽂히는 문장이 되려면, 의미를 깎아내는 작업에 수년에서 수십 년이 걸림 그리고 우리는 의미 형성을 RL로 다루는 법조차 모르니, AI가 그걸 대신해주진 못함 - > "can't make 9 babies in a month" 원래는 "9 women can't make a baby in one month"가 맞음 - **직접 하면서 배움**. 이 한마디가 더 경구에 가까워 보임 - **Intelligence amplification, not artificial intelligence**가 괜찮아 보임 줄이면 **IA, not AI**가 되고, 스페인어로 옮기면 "AI, no IA"라서 더 재밌어짐 - **취향**과 **판단력**은 AI가 낳아주지 못함 - >the medium is the message 미국인 100명에게 이 경구의 뜻을 물어보면, McLuhan의 원래 의미를 제대로 짚는 사람은 거의 없을 듯함 - AI는 대체로 두 방식으로 쓸 수 있다고 봄 하나는 내가 **소유하고 이해하는 코드**를 쓰는 데 보조로 쓰는 방식이고, 다른 하나는 AI를 **추상화 계층**처럼 써서 코드 작성과 유지보수를 맡기는 방식임 후자는 프로토타입, 예제, 레퍼런스처럼 수명이 짧고 코드 품질이나 내 이해도가 크게 중요하지 않은 곳엔 괜찮음 문제는 사실 **1이 필요한 일**에 2를 갖다 쓰면서 자신과 남을 속일 때 생김 빠르고 쉬워 보여도 결국 코드베이스를 저당 잡히는 셈이고, 그때부터 역량 위축도 시작된다고 봄 - 많은 엔지니어가 가까운 미래의 어느 시점엔 AI가 **1번 방식**도 완벽히 해줄 거라고 막연히 믿고 있어서, **2를 활용해 1을 더 쉽게 만드는 인프라**에 투자하자는 얘기는 팔기 더 어려움 - 문제는 그게 **저당 잡히는 느낌조차 안 든다**는 데 있음 기능은 계속 나가고 겉보기엔 멀쩡한데, 뭔가 터지는 순간 모델에 다시 묻지 않고는 자기 코드도 디버깅 못 한다는 걸 깨닫게 됨 - 현대적인 **IDE**, 메모리 관리가 있는 언어, GitHub나 패키지 매니저의 라이브러리 없이는 일 못 하는 엔지니어도 많음 그래서 AI 의존도도 내겐 아주 본질적으로 다르게 느껴지진 않음 **Engineer**라는 말의 의미도 변할 수 있고, 실제로 Webflow나 WordPress만 쓰는 "web developer"도 이미 존재함 - **Engineer**라는 용어는 이미 크게 변했음 엄격한 정의로 가면 Software Engineering 분야 사람들 중 실제 **공인 엔지니어**는 거의 없고, 어떤 나라에선 자격과 타이틀까지 붙음 - 진짜 **못 한다**는 건지, 아니면 **안 한다**는 건지 구분해야 함 커리어 초반엔 시간이 충분하면 거의 뭐든 했겠지만, 지금은 할 수 있어도 재미없어서 안 하는 일이 길게 늘어섬 - 큰 차이는 우리가 **최종 비용**을 아직 모른다는 점임 AI가 Slack 구독료 수준의 비용일지, 팀원 한 명의 비용일지, 아니면 서비스가 사라져서 AI 접근권 있는 사람을 따로 고용해야 할지 알 수 없음 - 적어도 지금은 대부분에게 **로컬 실행**이 현실적이지 않음 그래서 AI에 의존하는 건, 로컬이나 오픈소스 도구일 수 있는 IDE에 의존하는 것과는 꽤 다름 - "넌 대체 무슨 엔지니어냐"라는 말이 **Jesse Plemons**의 새빨간 선글라스 장면처럼 떠오름 - 경력 **10년**쯤 된 사람은 코드의 흐름과 논리를 알아서 AI를 써도 코드를 만들고 자기 방식도 개선할 수 있음 반대로 초보자는 흐름이나 논리를 모르고 그냥 복붙하게 되기 쉬워서, AI가 그런 사람들에게 생각할 여지를 더 줄 것 같진 않음 - 지금의 AI 사용 방식은 지난 **20년간의 프로그래밍**보다 더 피곤하게 느껴짐 문제를 던지고, 제안을 평가하고, 그중 맞는 방향을 고르고, 이상한 제안을 걷어내고, 다시 다듬어서 거의 맞는 상태로 만드는 과정이 특히 지침 그 뒤 코딩은 1~5시간 돌려서, 내가 직접 했다면 적어도 2~3주는 걸렸을 결과를 내주기도 함 그런데 이렇게 5시간쯤 계획 중심으로 일하면 완전히 녹초가 되고, 이건 순수한 프로그래밍만 할 때의 피로와는 다름 뭔가 배우는 것 같기도 하지만, 솔직히 **관리자 일**에 더 가까운 느낌도 듦 - 나도 비슷하게 느낌 LLM과 천천히 문제를 정의하고 그럴듯한 해법을 찾으려면 계속 **집중 상태**를 유지해야 해서, 예전 같은 **몰입 흐름**이 잘 생기지 않음 산더미 같은 출력을 계속 처리하면서 핵심을 반복해서 골라내야 하고, 대체로 좋아도 늘 어딘가 미묘하게 어긋나 있어서 꽤 거슬림 LLM 특유의 이상한 오류와 추론 결함 때문에 높은 경계심도 계속 유지해야 하고, 그 비인간적인 커뮤니케이션 스타일을 해석하는 것 자체도 지치게 만듦 - AI의 장점 중 하나는 **시작을 해주고 계속 밀어준다**는 데 있음 다만 pacing이나 procrastination이 오히려 인간에게는 일종의 **압력 해소 밸브**일 수도 있겠다는 생각도 듦 - 애초에 생각을 잘 못하는 엔지니어는 많고, AI가 그 사실 자체를 바꾸진 못함 - 진짜 핵심은 **제대로 생각하지 못하는 것**임 그게 Software Engineering 영역이 많이 망가진 이유 중 하나고, AI는 해결은 못 하고 더 큰 혼란을 잠시 미룰 뿐일 수 있음 - 일부는 동의하지만, AI는 리더십이 사람들의 **허풍과 헛소리**를 간파하기 더 어렵게 만드는 효과는 분명히 있다고 봄 - 공학 학위를 받고도 생각을 못 한다는 게 어떻게 가능한지 궁금함 대학에서 컨닝으로 버틴 사람도 안 들키고 빠져나가려면 결국 **비판적 사고**는 필요했음 듣기 싫어할 수 있지만, **컨닝을 잘하는 것**조차 꽤 많은 사고력을 요구함 - AI에게 어느 수준에서든 **생각을 맡기는 사람**은 원래 그것을 가치 있게 여기지 않았다고 봄 "use it or lose it"라는 말처럼, 이를 뒷받침하는 연구는 점점 늘어나는데도 소프트웨어 개발에서 LLM 사용은 괜찮고 우리의 가치는 사고력에 있다는 식의 글도 계속 나옴 - 이게 ADHD나 불안 성향과 관련 있을 수도 있고, 컴퓨터로 일하는 사람들에게 꽤 흔한 특성일 수도 있지만, 나는 거의 항상 생각하고 있음 다른 일에 완전히 몰입했다가도 불쑥 해결책이 떠오르는 순간이 이 일의 아름다움 중 하나임 이제 AI는 그런 생각을 **행동으로 빠르게 바꾸는 도구**가 되어줌 예전엔 실마리를 잡기도 전에 흐름을 놓칠 때가 있었는데, 지금은 휴대폰으로 몇 분 안에 생각을 부분적으로라도 현실로 만들고 다시 하던 일로 돌아갈 수 있음 시선을 잠깐 돌리면 아이디어를 잃어버릴까 걱정하지 않아도 되는 점이 특히 큼 - 지금 **numba를 다시 만들고** 있는데, 이걸 손으로만 하는 건 상상하기 어려움 몇 년 전에 시도했을 땐 몹시 고통스럽고, 느리고, 지저분했음 수년간 쌓인 추상화 위에 작은 것들이 끝없이 얹혀 있어서 더 그랬음 이번엔 **LLM**을 써서 다시 하고 있는데, 원래 몇 주 걸릴 일이 하룻밤 사이 끝나기도 함 그래도 코드는 직접 보고, 생성된 C 출력도 보고, 앞으로 나와 LLM이 함께 다루기 쉽도록 아키텍처 통제도 계속 쥐고 있음 이게 내 사고를 대체하는지는 잘 모르겠음 수개월 동안 수작업으로 쓰고 고치며 버텼다면 컴파일러나 트랜스파일러를 더 많이 배웠겠지만, 그러면 이것만 붙잡고 있었을 것임 대신 지금은 **Golang으로 커스텀 파일시스템용 NFS 서버 지원**까지 따로 작성할 시간도 남음 - 나도 AI가 내 사고 과정의 어떤 부분을 대체하고 있는지 걱정함 이제는 에이전트들이 기능 전체에 필요한 변경사항을 찾아내고, 계획 단계에서 아주 세밀하게 풀어둔 뒤, 구현은 거의 **처음부터 맞게** 해내는 수준의 시스템을 만들어 둠 지난 1년 동안 내가 직접 코드를 읽는 일은 점점 줄어들었고, 지금 시스템에 대해 내가 느끼는 **편안함**이 과한 건 아닌지 자주 자문하게 됨 워낙 높은 정확도와 성공률을 반복해서 봐서 이제는 본능적으로 의심하지 않게 됨 언젠가 크게 데일 거라 계속 기다리는데도, 이상하게 그 순간이 잘 오지 않음 물론 작은 누락과 되돌림은 있었지만 그건 예전에도 있었음 차이는 예전엔 내가 고생해서 쓴 코드라 훨씬 개인적인 관계가 있었다는 점임 이제 문제가 생기면 코드를 탓하기보다, 왜 시스템이 스스로 정답을 못 냈는지, 혹은 왜 구현 전에 계획에서 그 전체를 드러내지 못했는지를 다시 파고들게 됨 - 소프트웨어에서 AI의 가장 큰 장점은 **코드를 더 빨리 만들 수 있다**는 데 있음 가장 큰 단점은 **엄청나게 더 빨리 만들고 싶게 유혹한다**는 데 있음 - 그래서 개인 프로젝트에는 AI를 쓰지 않음 **머리를 날카롭게** 유지하고 싶기 때문임 AI를 포함하는 프로젝트라면 예외가 있을 수 있어도, 그 코드를 짜는 데 AI를 쓰진 않음 반면 회사 일은 신경 안 씀 매니저가 Claude로 완전히 **vibe coding**하길 원하면 그렇게 할 뿐이고, 그로 인해 생기는 기술 부채 비용을 내가 내는 건 아니기 때문임