에이전틱 코딩에서 개발자 역량의 역할

• 에이전트형 코딩 어시스턴트가 더 유능해짐에 따라 반응은 매우 다양하고, 일부는 "1년 안에 개발자가 더 이상 필요하지 않을 것"이라고 주장
• 다른 사람들은 AI가 생성한 코드의 품질과 주니어 개발자를 이러한 변화하는 환경에 대비시키는 방법에 대해 우려를 제기함
• 지난 몇달간 Cursor, Windsurf, Cline 같은 에이전트형 코딩 도우미를 사용했고, 기존 코드베이스 변경에 매우 효과적임
• IDE 통합에 매우 감명받았고, 테스트 실행 및 자동 오류 수정, 린트/컴파일 오류 감지 및 수정, 웹 검색, 브라우저 프리뷰 기능까지 통합됨
• 개발자와 AI 간 협업 경험이 매우 인상적이며 빠른 문제 해결 및 기능 구현에 기여함

• 그러나 여전히 개발자의 지속적인 개입, 수정, 방향 설정이 필요했음
• 실제 커밋까지 이어지지 않은 경우도 많았으며, AI가 자율적으로 사소하지 않은 작업을 위한 코드를 작성하기에는 부족함
• 따라서 개발자의 기술과 경험은 여전히 중요하며, 앞으로도 지속적으로 훈련되어야 함

개발자가 직접 개입해야 했던 순간들

• AI 도구들은 특정 영역에서 항상 약한 성능을 보였으며, 이는 반복적으로 확인됨
• 일부는 추가 프롬프트나 커스텀 룰로 부분적으로 완화 가능하지만 완전한 제어는 불가능
  • LLM은 프롬프트의 지시를 정확히 따르지 않는 경우가 많음
  • 코딩 세션이 길어질수록 결과의 일관성이 떨어짐
• 따라서 아래에서 소개하는 사례들은 프롬프트나 설정과 무관하게 충분히 발생할 수 있는 이슈
• AI 실수들을 영향 반경에 따라 3가지 범주로 분류
  • a. 개발 속도 및 커밋 시간 저하
    • AI가 오히려 속도를 늦춤
    • 비보조 코딩보다 비효율적인 경우
  • b. 팀 작업 흐름에 마찰 유발
    • 한 iteration 내에서의 충돌이나 협업 문제 발생
  • c. 장기적인 코드 유지보수성 저하
    • 초기에는 문제 없어 보이지만, 향후 변경이나 확장 시 문제 발생
• 영향 반경이 클수록, 팀이 해당 문제를 인지하고 수정하는 피드백 루프가 길어짐

영향 반경: 커밋까지의 시간 지연

• 이 범주는 AI가 도움이 되기보다는 방해가 되었던 사례들로 구성됨
• 가장 명확한 실패 형태이기 때문에 크게 문제되지는 않음
  • 대부분 커밋 전 단계에서 개발자가 문제를 인지하고 막을 수 있음

• 작동하지 않는 코드

  • AI가 생성한 코드가 기본적으로 작동하지 않음
  • 개발자가 직접 수정하거나, AI 세션을 종료하고 수작업으로 문제 해결 필요
  • 경험 있는 개발자는 어디서 잘못되었는지를 빠르게 판단하고 조치 가능

• 문제의 잘못된 진단

  • AI가 문제의 원인을 잘못 판단하고 엉뚱한 방향으로 해결책을 시도함
  • 과거 경험을 바탕으로, 개발자가 잘못된 경로에서 AI를 끌어올 수 있었음

    예시: Docker 빌드 오류를 아키텍처 설정 문제로 오해해 설정을 수정함
    실제 원인은 잘못된 아키텍처에서 빌드된 node_modules 복사였음
    이전에 자주 겪은 문제였기 때문에 빠르게 인지하고 바로잡을 수 있었음

영향 반경: iteration 내 팀 작업 흐름

• 이 범주는 리뷰나 개발자의 개입 부족으로 인해 iteration 기간 중 팀 내 마찰이 발생하는 경우
• 저자는 과거 다양한 팀 경험 덕분에 이러한 문제를 커밋 전에 사전에 인지하고 조정할 수 있었음
• 신입 개발자들도 AI와 함께 시행착오를 겪으며 이러한 교훈을 얻어갈 수 있음
• 하지만 AI로 인해 코딩 속도가 빨라지면, 팀이 이 문제들을 감당하지 못할 수 있음

• 과도한 초기 작업

  • AI는 점진적 구현보다는 전체 기능을 한 번에 넓게 처리하려는 경향 있음
  • 이로 인해 기술 선택이 부적절하거나 기능 요구사항을 잘못 이해했을 경우, 많은 작업이 낭비될 수 있음

    예시: 프론트엔드 스택 마이그레이션 시, 전체 UI 컴포넌트를 한 번에 변환 시도
    백엔드와 통합되는 하나의 컴포넌트부터 점진적으로 적용했어야 함

• 원인 분석 없이 무작정 해결

  • AI가 문제의 근본 원인을 분석하지 않고, 단순히 외형적으로 보이는 오류를 해결하려는 방식 사용
  • 이후 문제를 맡게 된 다른 팀원이 문맥 없이 문제를 다시 분석해야 하는 부담 발생

    예시: Docker 빌드 중 메모리 오류 발생 시, 원인을 찾기보단 메모리 설정만 증가시킴

• 개발자 워크플로우 복잡화

  • AI가 생성한 빌드/실행 방식이 개발자 경험을 저하시킴
  • 즉시 커밋하면 다른 팀원들의 워크플로우에도 악영향

    예시: 프론트엔드와 백엔드를 각각 실행하는 명령어를 분리하여 제공함
    예시: hot reload 기능 누락
    예시: 복잡한 빌드 설정으로 개발자와 AI 모두 혼란스러움
    예시: Docker 오류를 사전에 감지하지 못하고, 빌드 후반에 오류를 처리하려 함

• 잘못 이해되었거나 불완전한 요구사항

  • 기능 요구사항을 명확히 주지 않으면, AI가 오해하고 엉뚱한 방향으로 기능을 구현할 수 있음
  • 초반 개입으로 바로잡는 것이 이상적이나, 자율적인 AI나 생각 없는 개발자 모두에서 후속 수정 비용이 증가
  • 이러한 잘못된 구현은 나중에 스토리 진행 중 발견되어 많은 수정 작업과 커뮤니케이션 비용을 발생시킴

영향 반경: 장기적인 유지보수성 저하

• 가장 은밀하고 위험한 영향 반경
  • 초기에는 코드가 문제없이 작동하지만, 나중에 변경과 확장이 어려워짐
• 이러한 문제는 수 주에서 수 개월 후에야 발견되는 경우가 많음
• 특히 이 영역은 필자의 20년 이상의 개발 경험이 가장 크게 작용한 부분

• 장황하고 중복된 테스트 코드

  • AI는 테스트 생성을 잘하지만, 다음과 같은 문제가 자주 발생함:
    • 기존 테스트에 통합하지 않고 새로운 테스트 함수 생성
    • 이미 커버된 부분까지 과도하게 많은 assertion 추가
  • 초보 개발자들이 오해할 수 있는 부분: 더 많은 테스트 ≠ 더 좋은 테스트
  • 중복이 많아질수록 유지보수가 어려워지고, 코드 변경 시 테스트 대량 실패 가능성 증가
  • 커스텀 명령으로 완화 시도했지만, 여전히 자주 발생

• 재사용성 부족

  • AI가 작성한 코드는 종종 모듈화가 부족하여 재사용이 어려움

    예시: 이미 존재하는 UI 컴포넌트를 인식하지 못하고 중복 구현
    예시: CSS 클래스를 쓰지 않고 인라인 스타일을 남발

• 과도하게 복잡하거나 장황한 코드

  • AI가 필요 이상으로 많은 코드를 생성하여 불필요한 부분을 수동으로 제거해야 하는 경우 많음
  • 이는 유지비용을 증가시키고, 변경 시 에러 가능성을 높임

    예시: CSS 변경 시, 많은 중복 스타일을 일일이 삭제해야 함
    예시: JSON 데이터를 보여주기 위해 불필요하게 복잡한 웹 컴포넌트 생성
    예시: 리팩토링 과정에서 기존 의존성 주입 체인을 인식하지 못하고,
    이미 주입된 값을 또 다른 매개변수로 전달하여 설계를 복잡하게 만듦

    • value = service_a.get_value(); ServiceB(service_a, value=value) 형태

결론: AI가 모든 코드를 대신 작성할 수 있을까?

• 지금까지의 경험을 바탕으로 볼 때, 1년 안에 AI가 전체 코드의 90%를 자율적으로 작성하는 일은 현실적으로 불가능
• 다만, 코드 작성 보조 역할로서는 일부 팀과 코드베이스에서 90% 보조 가능성 있음
• 실제로 필자는 15K LOC 규모의 중간 복잡도 프로젝트에서 약 80% 정도 AI 도움을 받고 있음

AI의 실수를 방지하기 위한 방법

• 개인 개발자 차원에서 할 수 있는 일

  • AI가 생성한 코드를 항상 신중하게 리뷰할 것
    • 수정할 부분이 없는 경우는 거의 없음
  • AI 세션이 혼란스러울 경우 즉시 중단
    • 프롬프트를 수정하거나, 아예 수작업으로 전환 ("수제 코딩"이라고도 부름)
  • 단시간에 기적처럼 완성된 "그럴듯한" 솔루션 경계
    • 장기 유지보수 비용이 숨어 있을 수 있음
  • 페어 프로그래밍 실천
    • 4개의 눈, 2개의 뇌가 더 나은 판단을 제공함

• 팀 및 조직 차원에서의 대응 전략

  • 기존의 코드 품질 모니터링 도구 적극 활용
    • 예: Sonarqube, Codescene
    • AI 도구 사용 시 코드 중복, 코드 냄새 등을 더 면밀히 감시해야 함
  • Pre-commit hook 및 IDE 통합 코드 리뷰 설정
    • 개발 초기에 문제를 잡기 위한 shift-left 전략 강화
  • 좋은 코드 품질 습관 재정립
    • 팀 내에서 AI 코드로 인해 발생한 문제 사례("Go-wrong 로그")를 주간 회고에서 공유
  • 커스텀 룰 적극 활용
    • 대부분의 AI 도구는 프롬프트와 함께 전달되는 규칙 세트 설정 가능
    • 팀이 함께 룰셋을 개선하면서 AI의 실수를 줄일 수 있음
    • 단, 세션이 길어질수록 룰 무시 가능성 증가
  • 신뢰와 소통이 바탕이 된 팀 문화 조성
    • AI 도입은 새로운 변화이며, 모두가 초보자라는 사실을 인지해야 함
    • "AI 있으니까 더 빨리 해라" 식의 압박은 품질 리스크를 증가시킴
    • 심리적 안전감이 있는 팀은 문제 공유와 학습이 더 활발히 일어남

[bus710]

저 툴을 쓰는 사람들은 역량을 떠나 다 개발자들일텐데.... 앞으로 개발자가 필요 없다는 식으로 광고하는 것은 조금 이상한 구석이 있는 것 같네요.

[prunusnira]

앞으로는 어떻게될지 모르겠지만 아직은 주류로 쓰기엔 별로인거 같아요... 최근에 커서를 써봤는데 기본적인 파일 import path도 제대로 못잡더라구요. 그래도 내가 만들고 싶어하는걸 어느정도 미리 예측해주는건 좀 놀라웠습니다.

[daddy]

Docker 빌드 중 메모리 오류가 발생했을 때, 처음부터 왜 그렇게 많은 메모리가 사용되었는지 질문하기보다는 메모리 설정을 늘렸음
-> 이건.. 이미 무수히 많은 사례에서 이렇게 해왔기 때문임.
-> 지금의 AI는 과거의 우리들임

[GN⁺]

Hacker News 의견

• 요즘 대부분의 개발에 Cursor를 사용함. 이 글은 내 경험과 매우 유사함

  • AI 에이전트가 2021년 즈음에 멈춘 것처럼 느껴짐. 새로운 패키지를 설치하면 Claude가 4년 전 인기 있었던 오래된 패키지나 구현으로 돌아감. 이를 수정하는 것은 매우 좌절스러움. 명확한 지침을 제공하면 문제를 완화할 수 있지만 해결되지는 않음
  • 이러한 실수의 예측 불가능성이 특히 도전적임. 몇 달 전 Claude를 사용해 유용한 웹 앱을 "원샷"으로 만들었음. 완전한 기능을 갖추고 놀랍도록 정교했음. 혼자서 만들었다면 몇 주나 주말이 걸렸을 것임. 그러나 제공된 파일을 사용해 파비콘을 업데이트하라고 요청했을 때, 한 시간 동안 쓸모없이 돌아갔음 (결국 몇 분 만에 직접 해결함). 며칠 전 비슷한 범위의 웹 앱을 다시 만들려고 했음. 약 4시간 동안 에이전트를 다루다가 코드를 완전히 버릴 준비가 됨
  • 이 접근 방식은 내가 시간, 전문성, 동기가 부족해 시도하지 못했던 프로젝트를 추구할 용기를 줌. 마찰이 줄어드는 것은 흥미롭지만 의미 있는 것을 만드는 것은 여전히 어려움. 정교한 MVP를 만드는 데 여전히 상당한 노력이 필요함
  • 나는 계속해서 토끼와 거북이를 생각함. AI 에이전트를 신뢰하는 것은 초기에는 진행이 훨씬 빠르게 느껴져 유혹적임. 그러나 결국에는 느리고 세심한 주의를 기울였을 때 더 견고한 진전을 이룰 수 있었을 것이라는 느낌이 남음. 수작업으로 만들 때는 거의 되돌아가거나 전체 접근 방식을 버리는 일이 드물음. AI 주도의 접근 방식에서는 10배 더 빠르게 이동할 수 있지만 그 과정에서 약 70%의 작업을 버릴 수 있음
  • 이러한 경험으로 인해 내 상상력으로는 1년 내에 AI가 90%의 코드를 자율적으로 작성할 것이라고 생각하지 않음. 90%의 코드 작성에 도움을 줄 수는 있을 것임
  • 현재 환경은 자율주행차의 과대광고 주기와 비슷함. 많은 대담한 약속과 진정한 발전이 있었지만, 앞으로 5년 내에 AI가 스스로 유용한 소프트웨어를 작성하는 세상을 보지 못함

• 나는 AI를 이렇게 사용함: IDE에 있는 글쓰기 보조 도구로 사용하며, 매우 멋지고 정교한 고무 오리처럼 나에게 답변해 줌

  • 특정 코드 조각에 대한 토론을 자주 반복함. 보통 맥락이 거의 없는 상태로 제공되며, 기능이 올바르게 작동할 때까지 다듬고, 더 넓은 맥락에 맞추어 제시함 (또는 내가 직접 그 부분을 처리함)
  • 이렇게 사용하지 않음: 스스로 넓은 목표를 달성해야 하는 에이전트로 사용하지 않음
  • 이유: 에이전트 시스템의 출력이 실제로 달성하려는 것과 일치하도록 보장하기 위해 투자해야 하는 시간과 노력이 너무 많음. 이 훌륭한 글에서 설명한 모든 이유 때문임
  • 역설적으로, AI를 매우 유능한 글쓰기 보조 도구로 사용하면 워크플로우가 상당히 빨라짐. 그래서 어느 정도 덜 에이전트적인 AI가 나를 더 비판적으로 만들어, 에이전트 AI의 특이점에 맞추기 위해 추가로 투자해야 할 시간에 대해 더 비판적이게 만듦

• 전혀 이해가 안 됨

  • 왜 경험 많은 개발자들이 그렇게 명백히 형편없고 만족스럽지 않은 경험에 자신을 묶는 것에 열광하는지 이해가 안 됨
  • 나는 코드를 작성하고 문제를 해결하는 것을 좋아함. 그래서 소프트웨어 개발을 직업으로 선택했음

• 예시: Docker 빌드 중 메모리 오류가 발생했을 때, 처음부터 왜 그렇게 많은 메모리가 사용되었는지 질문하기보다는 메모리 설정을 늘렸음

  • AI는 정말 우리와 같음

• 개발자 기술은 여전히 필수적임 — 운전할 수 없다면 조종할 수 없음. 하지만 개발자 에너지는 어떨까? AI 이전에는 하루에 약 2시간 정도만 코딩할 수 있었음 (실제 코드 작성 시간). 하지만 Claude Code를 사용하면 쉬지 않고 5시간 동안 쉽게 코딩할 수 있음. 자전거 대신 전기 자전거를 타는 느낌임. AI는 스티브 잡스의 마음의 자전거 비유처럼 느껴짐 — 나를 대체하지 않지만 이제 훨씬 더 멀리, 빠르게 갈 수 있음

• 이 다이어그램은 너무나 공감됨 — 우리 팀은 여기 있는 모든 항목을 체크함. 아직 AI를 사용하지 않음에도 불구하고! 우리가 결국 AI를 사용할 때를 상상해 보라...

  • "오해된 요구사항"과 "지나치게 복잡한 구현"은 사실상 우리의 마스코트임. 더 나은 초기 대화와 반복적인 리뷰를 통해 이 혼란을 천천히 풀어가고 있음. 하지만 습관은 쉽게 사라지지 않음. AI의 도움 없이 이러한 함정을 헤쳐나가는 사람도 있는가?

• 나에게는 명백한 것이 보이지 않음: 주변에서 AI를 사용함

  • 개발 도구, 내성, 로깅, 변환 등 도구를 구축하고 유지 관리해야 하는 경우가 많음. 에이전트를 사용해 이를 만들고 수정하는 데 많은 운이 좋았음. 예를 들어, 맞춤형 계획 시스템에서 데이터를 수집하고 로그를 모으는 도구
  • 이러한 도구를 구축하는 데 중요한 경로에서 생성된 보일러플레이트가 많음. 대부분의 날에는 이를 하고 싶지 않음

• AI를 많이 조종해야 하지만, 더 나은 프롬프트가 더 나은 에이전트로 이어질 것이라는 낙관적인 생각을 가짐

  • 기사에서 예를 들어보자: 코드 재사용. 코드를 작성할 때, 무의식적으로 이미 있는 코드의 정신적 인벤토리를 가지고 있음. 무의식적으로 "이 새로운 작업이 이미 작동하고 테스트된 코드와 매우 유사한가?"라고 스스로에게 묻고 있음. 코딩 에이전트가 받는 초기 프롬프트의 세부 사항을 살펴보지 않았지만, 내 직감은 에이전트에게 코드베이스에 무엇이 있는지 인벤토리를 유지하도록 지시하는 프롬프트를 추가하고, 새로운 코드 배치를 계획할 때 새로운 작업의 요구 사항을 이미 있는 것과 대조하는 것이 좋을 것임
  • 예, 이는 계획 과정에 많은 계산 사이클을 추가함. 하지만 "그것이 에이전트가 코드를 작성하는 대가"라고 솔직하게 말해야 함. 더 나은 계획 > 문제 해결 능력

• AI 도구가 내가 나열한 것들에 대해 항상 나쁘다고 서문을 달고 싶음

  • 거기에 "not"이 빠진 것 같음. 왜 그들이 항상 나쁘다고 서문을 달겠는가? 반대 방향이 더 말이 됨
  • 또한 "effected" 대신 "affected"라는 문법 오류가 있음

• Martin Fowler가 이제 그의 웹사이트에서 공간을 임대하고 있는가?