AI 코드 생성의 한계와 인간 감각 상실에 대한 개인 사례 연구

(github.com/jackdoe)

1P by GN⁺ 5시간전 | ★ favorite | 댓글 1개

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) 임.

▲

GN⁺ 5시간전 [-]

Hacker News 의견

“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” 글도 세부 내용은 부족했음
- vibe coding은 결국 계획 능력의 대리 지표 같음
  즉흥적일수록 더 철저한 계획이 필요함. 그게 네 말의 요지인가?
공개된 코드가 이제는 더 이상 인간이 만든 것이 아니게 되었음
이런 코드가 다시 학습 데이터로 들어가면, 세상은 더 많은 무의미한 결과물로 채워질 위험이 있음
이미 언어 연구에서도 기계 생성 텍스트가 너무 많아 데이터 수집이 무의미해졌다는 사례가 있음
- 괜찮을 거라고 생각함. AI가 쓰레기 같은 코드를 많이 만들긴 하지만, 결국 인간이 그 속에서 보석을 찾아냄
  대부분의 경우 여전히 인간이 방향을 잡고 있음
  물론 12살짜리가 “yolo 3d game now”라고 치면 걱정되지만, 동시에 그건 멋질 것 같음
- 흥미로운 지적임. 이런 현상이 모델 중독(model poisoning) 과 비슷한 효과를 낼 수도 있을 듯함
vibe coding된 코드를 읽으면 마치 “English as She is Spoke” 같은 느낌임
문법은 맞지만, 인간의 언어 같지 않은 코드임
나도 비슷한 생각을 함
보통 앱을 개발할 때는 며칠 동안 머릿속에 정신적 모델이 생기고, 샤워 중에도 구조를 재구상하곤 함
하지만 vibe coding을 하면 이런 내적 맥락이 사라지고, 코드를 읽는 게 고통스러움
반면 내가 직접 쓴 코드는 읽는 게 즐거움
- 나는 여전히 그 감정을 느끼지만, 코드 레벨이 아니라 시스템 레벨에서임
  시스템 간 연결과 데이터 흐름은 이해하지만, 세부 구현은 흐릿함
나도 비슷한 경험임. LLM이 프로그래밍의 재미를 줄였음
지금의 루틴은 “프롬프트 작성 → 잠깐 대기 → 반복 → 코드 리뷰”의 연속임
코드의 구조는 이해하지만, 직접 손으로 다루지 않으니 이해의 깊이가 얕아짐
올바른 훈련이 있으면 가능하겠지만, 아직 그 단계에 도달하지 못함
- 나는 LLM에게 코드를 맡기지 않고 아이디어 브레인스토밍에만 씀
  테스트 코드 생성에는 유용함. 좋은 테스트 하나를 직접 쓰고, 나머지는 AI에게 시켜서 시간 절약함
- 최소한 LLM이 만든 코드에는 자동화 테스트를 직접 작성함
  이를 통해 한계를 파악하고, 더 나은 시스템 설계로 다시 작성함
  LLM의 장황한 코드라도, 과거 개발자들이 남긴 기괴한 코드보다는 낫다고 느낌
약간 과장된 글이지만, 나도 공감함
LLM은 기존 코드 이해와 요약, 자동완성, 비개발자의 프로토타이핑에는 유용하지만
프로덕션 코드 작성에는 절대 쓰면 안 됨
해결책은 모델을 grounding하는 것임
코드에서는 테스트 주도 개발(TDD) 이 그 방법임
테스트를 먼저 작성하고, 실패를 확인하고, 그 이유를 검증한 뒤 코드를 작성하게 함
이렇게 하면 코드의 행동 기준서가 생기고, 이후 사람이나 에이전트가 참고할 수 있는 문서가 됨

답변달기