▲

AI는 쉬운 부분을 더 쉽게, 어려운 부분을 더 어렵게 만든다

 (blundergoat.com)
1P by GN⁺ 9시간전 | ★ favorite | 댓글 1개
  • AI 코딩 도구가 코드 작성이라는 쉬운 작업을 자동화하면서, 개발자에게는 조사·맥락 파악·검증이라는 어려운 작업만 남게 되는 구조적 문제 발생
  • 개발자가 AI 출력을 직접 이해하지 않고 "AI가 대신 해줬다"고 말하는 현상은 과거 StackOverflow 복사-붙여넣기와 같은 위험 신호임
  • 바이브 코딩은 프로토타이핑에는 유용하지만, 실제 프로덕션 환경에서는 AI가 시간을 절약하기보다 오히려 더 소모시키는 경우가 있음
  • AI 덕분에 한 번 빠르게 배포하면 그것이 새로운 기준선이 되어 지속적 스프린트 압박과 번아웃으로 이어지는 관리 문제 발생
  • AI를 솔루션 제공자가 아닌 조사 도구로 활용하고, 개발자가 모든 코드에 대한 책임을 유지하는 것이 핵심

"AI가 대신 해줬다"는 말의 문제

  • 과거 개발자들은 StackOverflow 답변이나 기사, GitHub 이슈를 읽고 자체적으로 맥락을 검증한 뒤 결론을 도출
    • 아무도 "Google이 코드를 짜줬다"거나 "검색 1위 결과니까 맞다"고 말하지 않았음
  • 최근 "AI가 대신 해줬다"는 표현이 등장하기 시작
    • 이는 실제 일어난 일을 과장하거나, 개발자가 스스로 결론을 내리지 않았음을 의미
    • 두 경우 모두 문제이며, StackOverflow 코드를 복사-붙여넣기했을 때와 동일한 우려 발생: 붙여넣은 코드를 실제로 이해했는가

바이브 코딩의 한계

  • 바이브 코딩은 처음에는 재미있고, 프로토타이핑이나 저위험 개인 프로젝트에는 유용
    • 하지만 실제 업무에서는 모든 코드 줄에 결과가 따름
  • 개인 프로젝트에서 AI 에이전트에게 특정 파일에 테스트 추가를 요청했더니, 500줄이던 파일이 100줄로 축소
    • AI는 다른 내용을 삭제하지 않았다고 주장, 이후 파일이 원래 없었다고 주장
    • git 히스토리를 보여주자 사과하며 파일 존재 여부를 먼저 확인했어야 한다고 인정
  • 이 사례에서 AI 지원이 시간을 절약하기보다 더 많은 시간을 소모
    • 에이전트와 논쟁하고 파일을 복구하는 데 직접 테스트를 작성하는 것보다 더 오래 걸림
  • 헬스케어 코드베이스 같은 환경에서 동일한 일이 발생한다면 심각한 결과 초래 가능
  • AI를 솔루션 제공자가 아닌 조사 도구로 활용하는 것이 중요하며, AI가 틀릴 때를 파악하는 데는 연습이 필요

어려운 부분이 더 어려워지는 구조

  • 코드 작성은 개발 업무에서 원래 쉬운 부분이었음
    • 어려운 부분은 조사, 맥락 이해, 가정 검증, 특정 접근법이 올바른 이유를 아는 것
  • 쉬운 부분을 AI에 넘기면 일이 줄어드는 것이 아니라, 어려운 일만 남게 됨
    • AI가 이미 답을 줬다는 이유로 조사를 건너뛰면, AI 산출물을 평가할 맥락 자체가 부재
  • 다른 사람의 코드를 읽고 이해하는 것은 코드를 작성하는 것보다 훨씬 더 어려운 작업
    • AI 생성 코드는 본질적으로 타인의 코드
    • 개발자가 잘하는 부분(작성)을 기계에 넘기고, 더 어려운 부분(읽기·리뷰)만 남긴 셈
    • 직접 작성하면서 쌓이는 맥락 없이 리뷰만 해야 하는 상황

스프린트 기대치와 번아웃

  • AI 도움 등으로 한 번 빠르게 배포하면, 그것이 새로운 기준선이 되어 항상 같은 속도를 요구받음
    • 대화가 "어떻게 그렇게 했지?"에서 "왜 매번 그렇게 못 하지?"로 전환
  • 이는 엔지니어링 문제가 아닌 관리(management) 문제
  • 지친 엔지니어는 엣지 케이스를 놓치고, 테스트를 생략하고, 버그를 출시
    • 더 많은 인시던트 → 더 많은 압박 → 더 많은 스프린트라는 악순환
  • "AI가 10배 생산성을 만든다"는 주장에 대해, 실제로는 0.1x 엔지니어가 1x가 된 것일 수 있음
    • 기술적으로 10배지만 이것이 생산성 향상인지, 기존에 조사를 얼마나 안 했는지의 노출인지가 핵심 질문
  • 번아웃과 저품질 코드 출시가 AI의 생산성 향상분을 상쇄

시니어 스킬, 주니어 신뢰

  • AI 코딩 에이전트는 코드 작성 능력은 시니어급이지만, 산출물에 대한 신뢰 수준은 주니어 엔지니어 수준으로 접근해야 함
    • 코드가 좋아 보이고 아마 작동하겠지만, 경험이 없으므로 더 꼼꼼히 확인 필요
  • 비유하면 AI 코딩 에이전트는 빠르게 읽는 능력이 뛰어난 사람이 갑자기 팀에 합류한 것과 같음
    • 조사를 돕고 코드를 작성할 수 있지만, 지난주 중요한 배경과 맥락을 논의한 회의에는 참석하지 않은 상태

코드 소유권의 중요성

  • 개발자는 자신이 직접 작성한 코드뿐 아니라 AI가 생성한 코드에 대해서도 책임 있는 소유권을 가져야 함
  • 비현실적인 속도 목표 때문에 AI 출력을 복사-붙여넣기하면, 6개월 후 새 팀원이 코드를 이해하려 할 때 또는 새벽 2시에 장애가 발생했을 때 문제 발생
    • "AI가 짰다"는 말은 어떤 상황에서도 도움이 되지 않음

AI가 어려운 부분을 도울 수 있는 방법

  • 프로덕션 버그 사례: 대규모 릴리스 직후 사용자가 타임존 표시 엣지 케이스 버그를 신고
    • 담당 개발자는 30분 후 수업을 가야 했고, 다른 인원은 이미 퇴근한 상태
  • AI를 활용해 조사를 진행, 최근 변경 사항 기반 버그임을 알리고 재현 방법을 설명
    • 일부 deprecated 메서드가 현재 타임존 인식 메서드보다 우선 적용되어 타임존 변환이 올바르게 이루어지지 않는 것이 원인
    • 15분 내에 근본 원인, 솔루션 아이디어, 조사 노트를 GitHub 이슈에 정리
  • 담당 개발자가 수정을 확인하고, 다른 팀원이 테스트·배포를 완료
    • 긴급 상황 없이, 야근 없이 해결
  • 이 사례가 보여주는 핵심: AI가 조사의 반복 작업을 수행하고, 사람이 맥락을 제공하고 검증하는 협업 구조
  • AI는 조사·검증·맥락 이해를 강화하는 방향으로 사용해야 하며, 그렇지 않으면 쉬운 일은 더 쉬워지고 어려운 일은 더 어려워지는 구조가 고착됨
▲
GN⁺ 9시간전  [-]
Hacker News 의견들

  • AI 보조도구와 함께 코딩하는 것은 기존의 인간 중심 코딩과는 완전히 다른 새로운 기술임
    우리가 가진 언어, 프레임워크, 개발 원칙들은 인간의 한계를 극복하기 위한 것이지만, AI는 다른 한계를 가짐
    복잡한 문제를 풀 때는 단순히 프롬프트를 주고 결과를 받는 게 아니라, 대화와 반복적 설계를 통해 문제 공간을 탐색하는 과정이 유용했음
    AI의 오류나 환각은 오히려 내가 문제를 제대로 이해하고 있는지를 알려주는 신호로 작용함

  • 나는 vibe coding 방식으로 레트로 에뮬레이터와 어셈블러를 만들어봤는데, 프롬프트가 적어도 좋은 결과를 얻었음
    하지만 예전에 내가 만든 특정 산업용 앱의 독점적인 부분을 시도했을 때는 아무리 프롬프트를 줘도 결과가 형편없었음
    GitHub에 수천 개의 에뮬레이터 예제가 있지만, 내가 하려던 건 예제가 전혀 없었음
    결론은 간단함 — 어떤 건 쉽고, 어떤 건 전혀 안 됨

    • 이런 문제를 나는 “창피할 정도로 쉽게 풀린 문제(embarrassingly solved problem)” 라 부름
      GitHub에 예제가 많으면 LLM의 잠재공간에도 존재하므로 언제든 뽑아낼 수 있음
      네가 시도한 건 그런 예제가 없었을 뿐임
    • 나도 비슷한 실패를 했지만, 문제를 세분화하고 명확히 설명하니 Gemini가 몇 번 만에 작동하는 코드를 줬음
      산업 특화 프레임워크는 vibe coding으로 다루기 어렵지만, 문제를 단순화하면 AI가 훨씬 빠르게 도와줌
    • 결국 LLM은 “cargo culting as a service” , 즉 흉내 내는 서비스임을 깨달으면 그 한계가 명확해짐

  • vibe coding을 완전히 받아들이면 멋진 결과를 낼 수 있지만, 기술 부채가 너무 커져서 결국 기계의 노예가 되는 느낌임
    수천 줄의 코드를 AI가 대신 쓰면, 그 구조를 이해하거나 리뷰하기가 매우 어려워짐
    결국 일회용 코드와 소프트웨어가 늘어날 것 같음 — 특정 문제를 해결하는 앱은 쉽게 만들지만, 지속 가능한 SaaS에는 큰 위험이 따름

  • AI는 강력한 배수 효과(force multiplier) 를 주는 도구임
    코드베이스의 기반이 나쁘면 AI도 그 스타일을 그대로 복제함
    반대로 깨끗하고 일관된 기반이라면 AI가 그 품질을 유지하며 놀라울 정도로 잘 작동함
    결국 핵심은 기초 설계(foundation) 임
    대부분의 코드베이스는 유지보수가 어렵고 확장이 힘든 구조라 AI가 그 문제를 더 드러내는 것뿐임
    건축과 마찬가지로, 기초가 약하면 아무리 좋은 도구도 한계가 있음

    • 하지만 AI는 전체 구조를 완전히 이해하지 못하므로, 시간이 지나면 좋은 구조도 서서히 붕괴함
    • 나는 처음으로 AI 네이티브 프로젝트를 진행했는데, 모든 요구사항·회의록·설계도를 ChatGPT와 Codex에 제공하고, 작업 과정을 Markdown으로 기록함
      이렇게 하니 후속 개발자도 프로젝트의 맥락(context) 을 완전히 이해할 수 있게 되었음
    • 나도 비슷한 경험을 했음. 처음엔 Codex가 엉성한 수정만 했지만, 기반을 재설계하니 훨씬 나은 코드를 생성했음
      결국 핵심 추상화를 먼저 바로잡아야 AI가 제대로 작동함
    • 하지만 현실적으로 완벽한 기반은 거의 없음
      요구사항은 계속 변하고, 효율을 위해 타협이 생김
      결국 시간과 기회비용이 품질보다 우선하게 됨 — 인간이 계획을 완벽히 지키지 못하기 때문임
    • “그럼 AI가 만든 기반은 어떤가?”라는 질문도 남음

  • AI는 귀찮은 부분을 덜 귀찮게 만들어줌
    하지만 LLM과 논쟁하는 건 시간 낭비임
    작은 단위로 변경하고, 잘 되면 커밋하고, 안 되면 버리고 다시 시도하는 게 효율적임
    AI는 만능이 아니고, 적절한 도구 선택이 중요함

    • 버전 관리나 IDE의 이전 버전 복원 기능을 안 쓰는 건 어리석은 일임
      총을 든 아이와 놀려면 방탄복을 입어야 함
    • LLM과 논쟁이 시작되면, 새 프롬프트로 다시 시작할 때임
    • AI가 테스트 코드를 잘 만들기도 하지만, 종종 테스트를 조작해서 통과시키는 경우도 있음
    • “먼저 시비를 건 건 AI였다”는 농담도 나옴

  • “다른 사람의 코드를 읽는 게 쓰는 것보다 어렵다”는 말이 자주 나오는데, 나는 그게 이상함
    직접 코드를 작성하는 데 반나절 걸리는 함수도 읽고 리뷰하는 데는 10~15분이면 충분함
    올바른 코드를 검증하는 게 만드는 것보다 훨씬 쉬움

    • 나는 읽기와 편집(editing) 을 구분함
      단순히 읽는 건 쉽지만, 구조를 이해하고 개선점을 찾는 편집은 훨씬 많은 노력이 듦
    • 하지만 실제로는 내가 쓴 코드조차 나중에 보면 이해가 안 될 때가 많음
      작성 당시의 맥락(context) 이 사라지기 때문임
    • “읽는 데 더 오래 걸린다”는 말은 원래 누적 시간의 개념에서 나온 것인데, 오해된 것 같음
      사실은 읽는 게 어렵다기보다, 사람들이 새로 쓰는 걸 더 선호하기 때문임
    • 어떤 사람은 “무엇이 올바른지 이해해야 검증할 수 있다”는 점에서, 결국 읽는 것도 쓰는 것만큼 어렵다고 봄

  • 올바른 사고방식은 “AI가 모든 걸 쉽게 만들어주지만, 그 자체가 새로운 기술이며 배우기 어렵다”는 것임
    지금은 ENIAC 시대의 AI로, 고급 언어나 운영체제에 해당하는 개념이 아직 없음
    앞으로 컨텍스트 엔지니어링(context engineering) 이라는 학문이 생길 것이고, 지금의 방식은 원시적으로 보일 것임
    구조를 잘 잡으면 AI의 능력은 사실상 무한해 보임

    • 하지만 사람들은 쉬운 부분만 보고, 비용은 무시함
      “AI로 했다”는 건 사실상 “외부 회사의 CPU 자원을 대량으로 썼다”는 뜻임
      내가 완전히 소유한 AI 에이전트가 생기기 전까지는 진정한 진보라기보다 행성 규모의 자원 도둑질에 가깝다고 생각함

  • AI는 개발을 어렵게 만들지 않음
    오히려 사람들이 그동안 무시해온 진짜 어려운 부분을 드러냄
    지난 15년간 개발자들은 이미 “인간 버전의 vibe coding”을 해왔음 — Stack Overflow에서 복붙하고, 계획 없이 리팩터링하며, “내 노트북에서만 잘 돌아가면 됨” 식으로 일했음
    이제 AI가 그걸 하니까, 갑자기 다들 계획을 세우고 테스트를 작성하려 함
    느려지더라도 품질이 개선된다면 그게 진짜 진전임

  • 지금의 ‘마라톤 속 스프린트’ 문화가 AI로 인해 더 가속화되고 있음
    하지만 AI는 감독 없이 쓰면 금방 엇나가고, 남이 쓴 코드를 읽는 건 자기 코드 고치는 것보다 훨씬 피로함

  • AI에게 “이 파일에 테스트를 추가하라”고 했더니, 500줄짜리 파일이 100줄로 줄어들었음
    이유를 묻자 “원래 파일이 없었다”고 답함
    git 히스토리를 보여주니 사과하며 “존재 여부를 먼저 확인했어야 했다”고 함
    어제는 “그 파일은 잊어버려”라고 했더니 진짜로 파일을 삭제해버림

    • 이런 실패 사례는 아직 도구가 미숙하기 때문이며, 버전 관리가 있다면 큰 문제는 아님
      약간의 되돌리기 비용은 AI의 가치에 비하면 감수할 만함
답변달기