깊이 생각하던 시절이 그리워요

• AI 코딩 도구의 등장으로 깊이 사고하는 경험이 급격히 줄어들면서, 엔지니어로서의 성장이 정체된 느낌을 받고 있음
• 내 안에 있는 '빌더(Builder)'와 '싱커(Thinker)' 중, 빌더는 AI 덕분에 만족되지만 싱커는 굶주리고 있는 상태
• "바이브 코딩" 으로 아이디어에서 현실로 빠르게 전환할 수 있지만, 창의적 문제 해결의 기회가 크게 감소
• AI가 70% 수준의 "충분히 괜찮은" 솔루션을 제공하면, 실용주의적 성향 때문에 이를 거부하기 어려움
• 코딩 외부에서 깊은 사고의 만족감을 찾으려 했으나 성공하지 못했고, 두 가지 욕구를 동시에 충족할 수 있을지 불확실한 상황

---

사고의 결핍에 대한 문제 제기

• 글을 읽기 전에 “마지막으로 진지하게 생각한 때가 언제인가” 를 생각해 볼 것
• 이 글은 해결책이나 조언이 아닌, 단순히 최근 느낀 답답함을 토로하는 글

빌더(Builder)와 싱커(Thinker)라는 두 가지 성향

• 빌더(Builder): 만들고, 출시하고, 실용적인 결과를 내고자 하는 성향
  • 속도와 유용성에 의해 동기 부여됨
  • 성공적인 배포에서 오는 도파민, 실제 문제를 해결하는 시스템을 만들 때의 만족감, 누군가가 자신의 도구를 사용하고 있다는 사실에서 즐거움 발생
• 싱커(Thinker): 깊고 장기간 이어지는 정신적 씨름을 필요로 하는 성향
  • 물리학을 전공하던 대학 시절, 평균 난이도를 훨씬 넘어서는 과제 문제들이 주어졌음
  • 개념을 이해하고 있어도 접근 방법 자체를 떠올리기 어려운 문제들이 존재했음

어려운 문제에 직면한 학생들의 세 가지 유형

• 유형 1(다수): 몇 번 시도하다가 포기하고 교수나 조교에게 도움을 요청
• 유형 2(연구자형): 도서관에서 비슷한 문제나 힌트를 찾아 문제를 풀 수 있는 상태로 만듦, 대체로 해결에 도달
• 유형 3(싱커형): 오직 생각하는 방식으로 접근
  • 며칠 또는 몇 주 동안 비입출력(non-I/O) 상태의 두뇌 시간을 거의 전부 문제 해결 가능성에 사용
  • 잠을 자는 동안에도 사고가 이어짐
  • 이 방식은 한 번도 실패한 적이 없었으며, 깊고 오래 지속되는 사고가 자신의 강점이라고 인식
  • 상위 1%처럼 빠르거나 타고난 재능은 없지만, 충분한 시간이 주어지면 어떤 문제든 풀 수 있다는 확신을 가짐

AI와의 갈등

• 소프트웨어 엔지니어링이 처음 그토록 만족스러웠던 이유는 바로 이러한 이중의 만족감 때문이었음
• 빌더(유용한 것을 만들어 생산적이고 실용적인 느낌)와 싱커(정말 어려운 문제 해결) 모두를 충족
• 엔지니어로서 가장 크게 성장했던 프로젝트들은 항상 창의적인 해법이 요구되는 어려운 문제들을 다수 포함하고 있었음
• 그러나 최근에는 몇 시간 이상 하나의 문제를 붙잡고 진지하게 사고하는 경우가 급격히 줄어듦

• 이 모든 사태의 원인은 AI 탓이라고 생각함

• 그 어느 때보다 더 많이, 더 복잡한 소프트웨어를 작성하고 있지만, 엔지니어로서 전혀 성장하지 않는 느낌
• "정체된" 느낌의 이유를 되짚어보니, 싱커를 굶주리게 하고 있다는 것을 깨달음
• "바이브 코딩(vibe coding)" 은 분명히 빌더를 만족시킴
  • 아이디어가 매우 짧은 시간 안에 곧바로 현실로 구현되는 과정에서 즉각적인 쾌감 발생
  • 반면 기술적 문제에 대해 스스로 창의적인 해법을 고민해야 하는 순간은 크게 줄어듦
• 순수하게 빌더 성향인 사람들에게 이 환경은 최적의 시대임
• 그러나 나에게는 분명히 뭔가 부족함

실용주의의 함정

• “바이브 코딩으로 해결된다면 그 문제는 원래 어려운 문제가 아니었다” 는 반론을 예상함
  • 그러나 이는 핵심을 비껴간 주장임
• AI는 어려운 문제에 특별히 뛰어난 것도 아니고, 쉬운 문제에서도 항상 좋은 해법을 내놓는 것은 아님
  • 동일한 모듈을 세 번째로 직접 다시 작성한다면, AI가 만들어낸 어떤 결과보다 더 나을 것이라는 확신이 있음
• 하지만, 동시에 나는 실용주의자임
• 시간과 노력의 극히 일부만 들여 “충분히 가까운” 해법을 얻을 수 있다면, AI를 선택하지 않는 쪽이 오히려 비합리적으로 느껴짐
  • 진짜 문제는 이 실용주의를 의식적으로 끌 수 없다(무시할 수 없다)는 점임
• 본질적으로 빌더이며, 무언가를 만드는 행위 자체를 좋아함. 더 빠르게 만들 수 있다면 그 편이 항상 더 좋게 느껴짐
• AI를 거부하고, 싱커의 욕구가 코딩을 통해 자연스럽게 충족되던 시절로 돌아가려 해도, 빌더는 그 비효율을 견디기 어려움
• AI가 거의 확실하게 100% 만족스러운 해법을 제시하지는 않지만, 도달하는 70% 수준의 해법은 대개 “충분히 좋음”이라는 기준을 충족함

앞으로 어떻게 해야 할까?

• 솔직히 아직 답을 찾지 못한 상태이며, 계속 고민 중임
• 이 두 성향이 코딩이라는 한 영역 안에서 더 이상 동시에 충족될 수 있을지 확신하지 못하겠음
• 더 어려운 프로젝트를 목표로 삼아 AI가 완전히 실패하는 문제를 의도적으로 찾는 선택지는 존재함
• 그런 문제를 가끔 마주치기는 하지만, 깊은 창의적 해법을 요구하는 문제 자체가 빠르게 줄어드는 느낌
• 코딩 바깥에서 정신적 성장의 감각을 되찾으려는 시도도 하고 있음
  • 물리학과 다시 연결되기 위해 오래된 교과서를 펼쳐 보기도 함
  • 그러나 실질적인 만족으로 이어지지는 않았음
  • 무언가를 만들 수 있는 상황에서, 현재와 직접적인 관련이 없거나 최신도 아닌 물리 문제에 시간과 정신적 에너지를 쓰는 일을 스스로 정당화하기 어려움
• 빌더 성향은 그저 앉아서 미해결 문제를 붙잡고 사유하는 상태를 허용하지 않음
• 싱커 성향은 바이브 코딩이 이어지는 동안 계속해서 굶주린 채로 남아 있음
• 두 욕구가 동시에 충족되는 시점이 다시 올지에 대해서는 확신하지 못하겠음

“이제 우리는 이 존재에, 그 어떤 상상력의 힘도, 가장 대담한 환상의 비약도, 가장 독실한 신앙심도, 아무리 심오한 추상적 사고도, 황홀경에 빠진 정신조차도 결코 도달하지 못했던 것을 언제나 가리켜 온 그 익숙한 이름을 부를 권리를 갖게 되었습니다. 신(God). 그러나 이 근본적인 통일성은 과거의 것이며, 이제 더 이상 존재하지 않습니다. 그것은 자신의 존재를 변화시키는 과정에서, 스스로를 완전히, 철저히 산산조각 내버렸습니다. 신은 죽었고, 그의 죽음이 바로 세상의 생명이었습니다.”
— Philipp Mainländer

[aeolian21]

엔터프라이즈급 거대한 시스템에서 적합한 프로세싱 모델을 선정하고 파이프라인 방식을 선정하는 과정은 여전히 AI가 완성도면에서 아쉬운 모습을 보여주니 아키텍팅으로 눈을 돌려보는게 좋겠네요
물론 그것도 얼마나 가겠냐만은...

어려운 알고리즘 문제를 푸는걸로 욕구는 해소하고 비즈니스는 실용적으로 접근하던가 뭐 방법이 없어요

[pencil6962]

기계가 옷을 짜는 시대에도 뜨개질이 있는 것처럼 취미로서의 코딩을 할 수 있지 않을까 하는 생각이 드네요

[pluto]

지극히 개인적은 생각으로는
빌더, 싱커의 즐거움을 체리픽킹 할 수 있지 않을 까 싶음.

이제 완전히 낮은 비용(적은시간)으로 작동하는 무언가를 만들어 낼 수 있고
사용자들이 이걸 사용한다는 것에서 오는 즐거움, 실생활의 문제를 해결했다는 즐거움은 가져가며

아낀 시간으로 깊은 사고를 하는 문제에 시간을 쏟아 붓는다면 (실제로 그렇게 하고 있고)
그건 그것대로 의미가 있고 즐거움 또한 있지 않을 까 함.

[GN⁺]

Hacker News 의견들

• 2025년 3월 Aral Balkan의 글이 인상 깊었음
  코딩은 진흙 덩어리를 다듬어 원하는 형태로 만드는 과정과 같음. 이 과정에서 재료의 한계와 특성을 배우게 됨.
  만들기 전에는 무엇을 만들고 싶은지 가장 모르는 시점임. 디자인은 단순히 문제 해결이 아니라 올바른 문제를 발견하는 일임.
  창작 과정을 건너뛰면 배움과 발견의 인간적인 요소를 잃게 됨. 직접 다듬은 작품은 속속들이 이해하지만, 자판기에서 받은 결과물은 그저 모양만 닮은 모조품일 뿐임

  • 에이전트형 도구로 프로그래밍할 때는 아이디어가 평균적인 형태로 퇴화하지 않도록 계속 밀어붙여야 함
    새로운 아이디어일수록 도구가 이를 ‘정상화’하려 하기 때문에, 그 저항을 이겨내는 노력이 필요함.
    이 과정에서 자신의 아이디어가 무엇이고 무엇이 아닌지를 명확히 정의하게 됨. 밀어붙이기를 멈추는 순간, LLM이 프로젝트의 독창성을 덮어버림
  • 나는 이 모든 게 추상화의 연속이라고 생각함. OS나 컴파일러, 표준 라이브러리를 직접 만들지 않아도 괜찮음.
    이미 만들어진 도구를 조합해 새로운 것을 만드는 게 내 일임.
    창작 과정을 건너뛴다고 해서 작품의 가치가 떨어지는 건 아님.
    예를 들어, Zelda가 Havok 물리 엔진을 쓰거나, Unreal로 만든 게임이 훌륭하지 않은 건 아니잖음
  • 30년간 10곳의 회사에서 일하며, 회사는 나에게 ‘코드 작성’이 아니라 비즈니스 가치 창출을 기대했음
    최근 3주간 Codex, Claude, 테스트 세션을 병행하며 만든 결과물에 자부심을 느낌.
    과거엔 아이디어를 실현하는 게 목표였고, 지금은 고객 만족과 일정·예산 준수가 목표임
  • 한 단계 위로 올라갈 수도 있음. 직접 진흙을 빚는 대신, 각 부품을 명세(specify) 하고 기계가 만들게 할 수 있음
    이렇게 하면 수천 개의 부품으로 구성된 복잡한 시스템을 만들 수 있음.
    과거에는 이런 역할을 회사 조직이 대신했음 — 상층부가 명세를 내리고, 하층부가 부품을 만드는 식으로
  • Michelangelo가 “David가 아닌 부분을 깎아냈다”고 말했듯, 작업은 매체에 영향을 받음
    예전엔 Ruby on Rails로 만든 사이트를 금방 알아볼 수 있었음.
    매체의 특성을 이해하지 못한 채 사람이나 에이전트에게 일을 맡기면, 깨끗한 코드와 유지 불가능한 코드의 차이가 생김
    결국 책임은 지시자에게 있음. 매체 경험이 없으면 결과를 평가할 준비가 안 된 셈임

• 나는 단순히 타이핑이 줄었을 뿐, 여전히 똑같이 생각하고 있음
  도구가 좋아졌을 뿐, 프로그래밍은 여전히 프로그래밍임.
  낙타를 타고 사막을 건너든 헬리콥터를 타든, 결국 여행은 여행임.
  도구가 발전했다고 해서 본질이 바뀐 건 아님

  • 이 글의 댓글들을 보면 서로의 경험을 이해하려는 시도조차 없는 태도가 놀라움
    서로 다른 경험이 공존할 수 있다는 걸 잊은 듯함.
    “생각하기 싫다”는 댓글이 특히 인상적이었음
  • 헬리콥터로 사막을 나는 게 잘못은 아니지만, 직접 걸은 사람과 같은 경험은 아님
    추상화의 다음 단계로 올라가는 건 좋지만, 그 과정에서 잃는 가치도 인정해야 함
  • 저자의 말이 이해됨. 우리는 세세한 부분을 고민하던 시절을 그리워함
    LLM은 단순히 도구의 진화일 뿐이지만, 세밀한 사고 과정이 사라지는 건 아쉬움
  • 하지만 LLM 코딩은 단순한 추상화가 아님.
    오히려 다른 사람에게 일을 시키고 검토하는 행위에 가까움.
    프로그래밍을 싫어하던 사람들은 환영하겠지만, 이걸 ‘프로그래밍’이라 부를 순 없음
  • 에이전트 코딩 후에는 정신적 모델이 약해지는 느낌임
    직접 코드를 짜면 데이터 구조가 머릿속에 그려지지만, 에이전트가 대신하면 그 감각이 사라짐.
    이해 없이 코드를 커밋하는 건 나에게 가치가 없음

• LLM 기반 코딩을 기존 추상화와 동일시하는 건 잘못된 비유임
  컴파일러나 프레임워크는 누수가 없는 추상화를 목표로 하지만, LLM은 본질적으로 누수가 있음
  결국 버그를 찾고 수정하는 건 여전히 인간의 몫임.
  LLM은 우리가 피하려 했던 불확실성과 리스크를 다시 들여온 셈임

  • LLM 코딩은 결국 프롬프트를 코드로 압축 해제하는 과정임
    프롬프트에 모든 변수를 명시하지 않으면, 평균적인 결과물이 나옴.
    자연어가 이런 정보를 담기에 적합한가에 대한 의문이 있음
  • 지금의 LLM은 서툰 인턴 같음. 하지만 인간 전문가가 누수 없는 코드를 만들 수 있다면, LLM도 언젠가는 가능하지 않을까 생각함
  • LLM은 비결정적이라, 입력이 아닌 출력 결과를 버전 관리해야 함
    이는 추상화가 아니라 비결정적 코드 생성임
  • 만약 C 컴파일러가 가끔 작동하지 않는다면, 우리는 그냥 계속 빌드 버튼을 누를 뿐일 것임
    이런 점에서 LLM은 인간의 사고 방식에도 다르게 작용함
  • 많은 개발자들이 ‘추상화’의 의미를 제대로 이해하지 못한 듯함

• 나는 ‘생각하는 사람(thinker) ’이라서 AI 코딩에 큰 흥미가 없음
  OS 커널이나 그래픽 엔진을 직접 만드는 게 즐거움임.
  결과보다 문제를 푸는 과정이 내 취미이자 보람임
  반면 ‘빌더(builder)’들은 AI를 통해 더 빠르게 만들 수 있어 열광함

  • 하지만 ‘빌더=비사고형’이라는 구분은 틀림
    모든 엔지니어는 사고하는 사람임. 단지 도구의 목적이 다를 뿐임

• 수십 년간 코딩해온 입장에서, AI 도구는 자유로움을 줌
  예전엔 시도조차 못했던 아이디어를 빠르게 실험할 수 있음.
  덕분에 짧은 시간 조각을 활용해 개인 프로젝트를 진행할 수 있음

  • 휴대폰으로 프로젝트를 진행한다는 게 흥미로움. 어떻게 하는지 궁금함
  • 가족과 함께하는 삶 속에서 짧은 순간을 진전으로 바꾸는 능력이 정말 큼
  • 나도 이 의견에 동의함. 대부분의 프로그래밍은 보일러플레이트 낭비였음
    AI 덕분에 진짜 사고에 집중할 수 있게 되었음.
    이제는 싱귤래리티가 다가오고 있다고 느껴짐
  • 오후 한나절 동안 여러 접근법을 실험할 수 있음.
    실패해도 배움이고, 성공하면 품질 검증에 집중할 수 있음

• “생각하기”에도 여러 형태가 있음
  집중적으로 몰입하는 사고와, 배경에서 천천히 숙성되는 사고가 있음.
  두 방식 모두 깊은 몰입의 형태이며, AI 시대에 쉽게 잃기 쉬운 부분임

  • 나에게도 여러 종류의 ‘hard thinking’이 있음
    수학적 문제 해결, 철학적 사고, 실무의 복잡한 제약 등 각각 다른 형태의 지적 긴장감을 줌
    결국 중요한 건 어떤 형태든 깊이 있게 몰입하는 경험임

• 내 주변 시니어 엔지니어들을 보면 두 부류가 있음
  일부는 약간의 생산성 향상을 얻었지만, 사고의 깊이가 줄어든 사람들도 있음
  LLM이 제시한 답을 그대로 복붙하는 경우가 많음.
  진짜 문제는 질문을 제대로 던지는 능력의 부재임

  • 구현보다 커뮤니케이션 오버헤드가 더 큰 문제임.
    성숙한 시스템일수록 이런 비율이 90% 이상을 차지함

• 동료 엔지니어들이 AI에 열광하며 직업의 본질을 팔아넘긴 것이 아쉬움
  우리는 생산 수단을 가졌는데, 스스로 포기한 셈임

  • 단기적으로는 실업이 생길 수 있지만, 소프트웨어 수요는 무한함
    AI 덕분에 개발이 싸지고 빨라지면, 오히려 시장이 커질 것임
  • AI를 믿지만 반대하는 태도는 모순적임.
    기술 발전은 항상 특정 직군을 불리하게 만들지만, 사회 전체의 진보를 가져옴
    과거 우리가 자동화를 통해 다른 산업의 일자리를 줄였던 것처럼, 이제 그 순서가 우리에게 온 것뿐임
  • 가치 없이 효율만 추구한 실용주의자들이 문제임
    그 결과는 공허함뿐임. 하지만 그들에겐 그조차 목적이었을지도 모름
  • 이 계층은 마치 소부르주아가 더 큰 부르주아에게 흡수되는 과정 같음
  • 윤리와 철학이 결여된 기술주의의 결과임
    “할 수 있으니 한다” 는 사고가 인간성을 잃게 만듦

• AI가 사고를 없애는 게 아님. 평범한 회사와 평범한 사고방식이 문제임
  진짜 사고를 중시하는 회사를 찾아가야 함

• 나도 LLM으로 코딩하지만 여전히 깊이 생각함
  설계, 리스크, 제약, 기술 부채, 대안 등을 고민함

  • 하지만 LLM과 함께하는 사고는 다른 종류의 사고임
    여러 맥락을 오가며 관리하는 ‘매니지먼트형 사고’에 가깝고,
    며칠간 한 문제에 몰입하는 과학자형 사고와는 다름
  • 나도 비슷한 경험임. LLM 덕분에 코딩은 쉬워졌지만, 검증과 리뷰가 훨씬 어려워짐
    특히 AI를 쓰는 주니어들의 PR은 더 길고 복잡해졌고,
    이제 내 일의 대부분이 리뷰 중심으로 바뀌었음
  • LLM은 작은 단위의 반복 작업에 쓰는 게 가장 효율적임
    빠른 프로토타입, 헬퍼 함수, 코드 자동완성, 라이브러리 탐색 등에서 유용함
  • Claude Code로 100% 코드를 생성해도 여전히 깊은 사고의 비율은 높음
    오히려 단순 작업이 줄어들어 더 많이 생각하게 됨
  • 하지만 LLM 이후의 사고는 코드 자체에 대한 피드백 루프가 사라짐
    예전에는 코드 작성이 상위 설계 사고를 되돌아보게 했지만,
    이제는 그 과정이 줄어들어 ‘덜 깊이’ 생각하게 됨