# AI 코드 생성의 한계와 인간 감각 상실에 대한 개인 사례 연구 > Clean Markdown view of GeekNews topic #24295. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24295](https://news.hada.io/topic?id=24295) - GeekNews Markdown: [https://news.hada.io/topic/24295.md](https://news.hada.io/topic/24295.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-11-11T15:33:23+09:00 - Updated: 2025-11-11T15:33:23+09:00 - Original source: [github.com/jackdoe](https://github.com/jackdoe/pico2-swd-riscv) - Points: 1 - Comments: 1 ## Topic Body - **RP2350 RISC-V 코어**를 디버깅하기 위한 **SWD 프로토콜 구현 라이브러리**로, Raspberry Pi Pico2를 이용해 다른 Pico를 프로브로 사용하는 구조 - 코드의 약 **80%가 AI(Claude)** 로 생성되었으며, 작성자는 오실로스코프와 문서를 통해 기본 프로토타입을 만든 뒤 AI가 코드를 확장하도록 함 - 프로젝트 진행 중 **AI 코드의 무의미한 토큰 구조**, **맥락 상실**, **코드 소유감 상실** 등으로 인해 강한 **혐오감과 회의감**을 경험 - 반면, AI를 문서 분석·데이터 디코딩·구조체 생성 등 **보조 도구로 활용**할 때는 긍정적 경험을 얻음 - 이 사례는 **AI 코드 생성의 품질·감각·소유 문제**를 드러내며, 프로그래밍의 본질과 인간 역할에 대한 근본적 질문을 제기 --- ### 0. VIBE CODE WARNING - 전체 코드의 약 80%가 **AI 생성(vibe coded)** 이며, README 대부분도 자동 생성 - 작성자는 오실로스코프와 문서를 참고해 **SBA, 레지스터 읽기/쓰기, 추상 명령, PROGBUF** 등을 직접 구현한 후 AI에 라이브러리화를 맡김 - 코드가 1천 줄에서 4천 줄로 늘어나면서 **코드 구조와 의미를 완전히 상실**, 자신이 작성한 코드로 느껴지지 않음 - AI가 `dap_read_mem32`를 잘못 해석해 **프로토콜 오류와 비논리적 코드**가 대량 발생 - 결과적으로 1만 줄 가까운 코드를 10시간 만에 완성했지만, **성취감이나 성장감이 전혀 없음** ### AI 코드와 인간 코드의 차이 - 인간이 작성한 코드는 **의도와 목적이 있는 토큰**으로 구성되어 이해가 가능하지만, AI 코드의 토큰은 **의미 없는 조합**으로 읽기 어려움 - AI 코드의 일부는 인간보다 더 나은 품질을 보이지만, 바로 아래 줄은 **겉보기만 그럴듯한 오류 코드**일 수 있음 - 이러한 불균질성과 **감각적 신뢰 상실**이 프로그래머의 판단력을 마비시킴 - 코드가 커질수록 “좋은 코드인지 나쁜 코드인지 느끼는 감각(taste)”이 사라지고, **정신적 모델과 소유감이 붕괴**됨 ### 인간적 감정과 회의 - 작성자는 “이것이 프로그래밍인가?”라는 질문을 던지며 **혐오감과 수치심**을 표현 - AI가 코드를 대신 쓰는 시대에, 인간은 무엇을 만들고 어디까지 개입해야 하는지에 대한 **존재적 혼란**을 토로 - 단순히 “코드를 안 쓰는 것”이 발전인지, “문제를 모델링하지 않는 것”이 효율인지조차 확신하지 못함 - 자신은 여전히 **무언가를 직접 만들고 싶지만**, AI 중심 개발 환경에서 그 의미가 희미해졌다고 언급 ### AI의 긍정적 활용 경험 - AI를 **문서 분석, 오실로스코프 데이터 디코딩, C 구조체 자동 생성** 등에 활용할 때는 효율적이고 만족스러웠다고 평가 - 특히 첫 번째 레지스터를 읽고 SBA를 통해 메모리를 읽었을 때는 **진정한 성취감**을 느낌 - 즉, **AI를 코드 작성자가 아닌 조력자**로 사용할 때 긍정적 경험이 가능함 ### 결론적 성찰 - AI 코드 생성은 빠르지만, **의미·감각·소유의 상실**을 초래 - 인간이 느끼는 “좋은 코드의 맛(taste)”이 사라질 때, 프로그래밍의 본질도 흔들림 - 작성자는 이 현상이 **일시적 과도기**이길 바라며, “더 나은 프로그래밍”이 무엇인지 스스로도 알 수 없다고 마무리 --- 원문 이후의 기술적 섹션(1~20)은 **RP2350 RISC-V 디버그 프로토콜의 상세 구현 문서**로, SWD 계층 구조, DAP/DAPC 레지스터, PROGBUF 실행, SBA 접근, 하트 제어, 트레이싱, 리셋, 듀얼 하트 구조 등 **전체 디버그 스택의 완전한 기술 사양**을 포함함. 그러나 핵심 주제는 “AI가 생성한 코드와 인간 감각의 단절”에 대한 **개인적 사례 연구(Vibe Code Warning)** 임. ## Comments ### Comment 46193 - Author: neo - Created: 2025-11-11T15:33:24+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=45874987) - “AI가 프로그래밍의 재미를 빼앗았다”고 말하는 사람들의 감정에 공감하지만, 나는 **‘하는 것’보다 ‘완성하는 것’** 이 더 중요하다고 생각함 과거 가스등을 켜던 사람이 전등으로 인해 일자리를 잃었지만, 결국 중요한 건 도시의 **빛을 제공하는 일**이었음 나에게 AI는 아이디어를 실현하고 결과를 만들어내는 도구임. 나는 여전히 ‘진짜 프로그래머’들만큼 시간과 노력을 들이지만, 그 초점은 문제 정의, 모듈화, 테스트, 버그 수정, 반복 개선에 있음 - “하는 것 vs 완성하는 것”이라는 이분법은 위험한 사고임 인간이 **의미와 존엄, 즐거움**을 느낄 수 있는 세상을 만드는 게 중요함. 만약 맛있는 음식을 먹는데 그걸 만든 사람들이 고통받았다면, 혹은 악의적인 세력이 로봇으로 만든 음식이라면 나는 원하지 않음. 사회는 인간을 위한 것이지, 단순히 효율을 위한 체크리스트가 아님 - “완성하는 것”이란 무엇인가? AI가 가져온 **속도와 복잡성** 때문에 결과 검증이 점점 어려워지고 있음 개인 프로젝트에서는 괜찮지만, 고객이나 사용자, 주주가 있는 환경에서는 **증명 가능한 결과**가 필요함 가스등 비유는 적절하지 않음. AI는 전기처럼 물리적 시스템이 아니라 **소프트웨어**임. 결국 중요한 건 문제 해결임. 해결이 안 되면 그건 단지 노동일 뿐임 - 가스등 비유는 부적절함. 가스등을 켜는 일은 창의적 표현이 아니지만, **코드 작성은 창의적 행위**임 많은 사람은 단순히 유용한 소프트웨어를 만들기 위해서가 아니라, **창작의 즐거움** 때문에 코드를 씀 “진짜 프로그래머”들도 마찬가지로 생각하고, 정의하고, 테스트하고, 수정하는 데 시간을 씀 - AI와 기술이 만들어내는 것 중 상당수는 사실 **필요 없는 일**임 ‘스마트 치실 디스펜서’나 자동 화장지 구매기, 혹은 클리피 같은 봇들은 시간과 에너지 낭비임 - 장인정신과 **지식에 대한 관계**가 중요함 단순히 결과를 얻는 것보다, 배우고 이해하는 과정에서 오는 만족감이 큼 생존 기술서 *Adrift, 76 Days at Sea*를 읽으며, 깊은 지식이 생사를 가른다는 걸 느꼈음 이는 데이터를 직접 호스팅할지, 중앙화된 서비스에 맡길지의 문제와도 닮아 있음 - 인터넷에서 내 생각을 완벽히 표현한 글을 보면 정말 **위로받는 느낌**이 듦 “프롬프트를 이렇게 조정하라”는 소음 대신 인간적인 경험을 이야기해줘서 고마움 - 나도 같음. AI를 오래 쓰다 보면 유튜브를 무의식적으로 스크롤할 때처럼 **공허하고 무목적한 감정**이 듦 이 상태에서 벗어나려면 하룻밤 푹 자야 함 - 어떤 사람은 AI를 **Excel처럼 다루면 된다**고 생각하지만, 나는 **슬롯머신**에 더 가깝다고 느낌 거의 맞는 답을 주지만, 심리적으로 도박기계와 비슷한 중독성을 가짐 - 누군가 “AI로 1만 줄 코드를 10시간 만에 썼지만 끔찍했다”고 했는데, 그 경험은 접근 방식에 따라 완전히 달라짐 **프롬프트 구조화, 계획, 검토, 테스트, 속도 조절** 등 모든 요소가 사람마다 다름 많은 초보 개발자는 ‘**vibe coding**’이라 불리는 즉흥적 접근을 시도하다가 실패함 - 나도 에이전트 시스템을 조정해보며 **새로운 실패 방식**을 끊임없이 발견했음 피로감이 커서 잠시 쉬는 중이며, 언젠가 **직접 에이전트를 만들 계획**임 OpenAI, Microsoft, Anthropic 같은 빅테크에 이런 걸 맡기는 건 위험하다고 느낌 - 아직 **vibe coding으로 만든 대규모 오픈소스 프로젝트**를 본 적이 없음 결국 말뿐인 유행어에 불과하다고 생각함 - 그렇게 노력했는데, 결국 **직접 코딩하는 것보다 빠른가?** 의문임 새로운 라이브러리를 배우기 싫어서 프로젝트 관리로 도망치는 느낌임 - 네 말이 맞지만, “올바른 접근법”이 뭔지 구체적으로 말해주는 사람은 없음 예전에 화제가 된 [“Just Talk to It” 글](https://steipete.me/posts/just-talk-to-it)도 세부 내용은 부족했음 - vibe coding은 결국 **계획 능력의 대리 지표** 같음 즉흥적일수록 더 철저한 계획이 필요함. 그게 네 말의 요지인가? - 공개된 코드가 이제는 더 이상 **인간이 만든 것**이 아니게 되었음 이런 코드가 다시 학습 데이터로 들어가면, 세상은 더 많은 **무의미한 결과물**로 채워질 위험이 있음 이미 언어 연구에서도 기계 생성 텍스트가 너무 많아 데이터 수집이 무의미해졌다는 사례가 있음 - 괜찮을 거라고 생각함. AI가 **쓰레기 같은 코드**를 많이 만들긴 하지만, 결국 인간이 그 속에서 **보석을 찾아냄** 대부분의 경우 여전히 인간이 방향을 잡고 있음 물론 12살짜리가 “yolo 3d game now”라고 치면 걱정되지만, 동시에 그건 멋질 것 같음 - 흥미로운 지적임. 이런 현상이 **모델 중독(model poisoning)** 과 비슷한 효과를 낼 수도 있을 듯함 - vibe coding된 코드를 읽으면 마치 [**“English as She is Spoke”** ](https://en.wikipedia.org/wiki/English_as_She_Is_Spoke) 같은 느낌임 문법은 맞지만, 인간의 언어 같지 않은 코드임 - 나도 비슷한 생각을 함 보통 앱을 개발할 때는 며칠 동안 머릿속에 **정신적 모델**이 생기고, 샤워 중에도 구조를 재구상하곤 함 하지만 vibe coding을 하면 이런 내적 맥락이 사라지고, 코드를 읽는 게 고통스러움 반면 내가 직접 쓴 코드는 읽는 게 즐거움 - 나는 여전히 그 감정을 느끼지만, **코드 레벨이 아니라 시스템 레벨**에서임 시스템 간 연결과 데이터 흐름은 이해하지만, 세부 구현은 흐릿함 - 나도 비슷한 경험임. LLM이 프로그래밍의 재미를 줄였음 지금의 루틴은 “프롬프트 작성 → 잠깐 대기 → 반복 → 코드 리뷰”의 연속임 코드의 구조는 이해하지만, 직접 손으로 다루지 않으니 **이해의 깊이**가 얕아짐 올바른 훈련이 있으면 가능하겠지만, 아직 그 단계에 도달하지 못함 - 나는 LLM에게 코드를 맡기지 않고 **아이디어 브레인스토밍**에만 씀 테스트 코드 생성에는 유용함. 좋은 테스트 하나를 직접 쓰고, 나머지는 AI에게 시켜서 시간 절약함 - 최소한 LLM이 만든 코드에는 **자동화 테스트**를 직접 작성함 이를 통해 한계를 파악하고, 더 나은 시스템 설계로 다시 작성함 LLM의 장황한 코드라도, 과거 개발자들이 남긴 **기괴한 코드**보다는 낫다고 느낌 - 약간 과장된 글이지만, 나도 공감함 LLM은 **기존 코드 이해와 요약**, 자동완성, **비개발자의 프로토타이핑**에는 유용하지만 **프로덕션 코드 작성**에는 절대 쓰면 안 됨 - 해결책은 모델을 **grounding**하는 것임 코드에서는 **테스트 주도 개발(TDD)** 이 그 방법임 테스트를 먼저 작성하고, 실패를 확인하고, 그 이유를 검증한 뒤 코드를 작성하게 함 이렇게 하면 코드의 **행동 기준서**가 생기고, 이후 사람이나 에이전트가 참고할 수 있는 문서가 됨 - GitHub의 README를 끝까지 읽어보니, 작성자가 코드의 3/4이 **AI 생성물**임을 인정하면서도 **저작권을 주장**하고 있었음 인간이 만든 것이 아닌 콘텐츠는 **법적으로 저작권 보호를 받을 수 없다**는 판례가 이미 존재함