AI 코딩 어시스턴트: 도움이 될까, 해가 될까?

Source: Dev.to

위에 제공된 텍스트가 없습니다. 번역을 원하는 전체 내용을 알려주시면 한국어로 번역해 드리겠습니다.

AI 코딩 에이전트의 “어두운 면”에 대한 Denis Tsyplakov

Denis Tsyplakov, DataArt 솔루션 아키텍트, AI 코딩 어시스턴트의 덜 논의되는 측면을 탐구합니다. 생산성을 높일 수 있지만, 과소평가하기 쉬운 위험도 함께 가져옵니다.

짧은 실험에서 Denis는 AI 코드 어시스턴트에게 간단한 작업을 해결하도록 요청했습니다. 그 결과는 명확했습니다: 강력한 코딩 실력과 시스템 아키텍처에 대한 확고한 이해가 없으면, AI가 생성한 코드는 금세 과도하게 복잡해지고 비효율적이며 유지 관리가 어려워질 수 있습니다.

AI 코딩 어시스턴트에 대한 복합적인 감정

• 일부는 이것이 혁명적이라고 생각한다.
• 다른 사람들은 전혀 신뢰하지 않는다.
• 대부분의 엔지니어는 그 사이 어딘가에 있다: 조심스럽지만 호기심이 있다.

성공 사례는 거의 도움이 되지 않는다. “내 5‑살 아이가 15 분 만에 만들었다”와 같은 주장은 종종 마케팅 과장으로 일축된다. 이러한 회의론은 채택을 늦추지만, 동시에 중요한 점을 강조한다: 이 도구들의 장점과 한계 모두에 대한 현실적인 이해가 필요하다.

Market Pressure on Vendors

Reputable vendors are forced to compete with hype‑driven sellers, often leading to:

• Drop in quality – products ship with bugs or unstable features.
• Development decisions driven by hype, not user needs.
• Unpredictable roadmaps – what works today may break tomorrow.

공급업체에 대한 시장 압력

신뢰받는 공급업체는 과대광고에 의존하는 판매자와 경쟁하도록 강요받으며, 이는 종종 다음과 같은 결과를 초래합니다:

• 품질 저하 – 제품이 버그가 있거나 불안정한 기능을 포함한 채 출시됩니다.
• 과대광고에 의해 좌우되는 개발 결정, 사용자 요구가 아니라.
• 예측할 수 없는 로드맵 – 오늘 작동하는 것이 내일은 깨질 수 있습니다.

실험: AI 코딩은 얼마나 깊게 들어갈까?

세 개의 AI 코드 어시스턴트를 사용해 작은 실험을 진행했습니다:

1. GitHub Copilot
2. JetBrains Junie
3. Windsurf

과제

후보자의 기술 아키텍처에 대한 설명 능력을 확인하는 간단한 인터뷰 형식 문제.
시니어 엔지니어라면 올바른 접근법을 3–5 초 안에 제시할 수 있습니다. 우리는 이를 여러 번 테스트했으며, 결과는 언제나 즉각적이었습니다. (이 글이 공개된 후 후보자를 위한 다른 과제를 만들 예정입니다.)

• Copilot‑계열 도구는 알고리즘 문제에 대해 과거에 강점을 보여왔습니다.
• 간단한 클래스와 잘 정의된 문서화된 메서드 구현을 요청하면 매우 좋은 결과를 기대할 수 있습니다.
• 문제가 되는 부분은 아키텍처 결정이 필요할 때—즉, 구현 방식을 정확히 어떻게 할지입니다.

Junie, Copilot, Windsurf 모두 비슷한 결과를 보였습니다. 아래는 Junie에 대한 프롬프트 단계별 분석입니다.

프롬프트 1 – “클래스 로직 구현”

결과는 코드 리뷰를 통과하지 못합니다.
주어진 과제에 비해 로직이 불필요하게 복잡하지만, 전반적으로는 허용 가능한 수준입니다.
Java 기술 아키텍처에 대한 지식이 없다고 가정하고 이 솔루션을 받아들여 주세요.

프롬프트 2 – “이 코드를 스레드‑안전하게 만들어 주세요”

어시스턴트는 기술적으로 올바른 솔루션을 제시했습니다.
그래도 과제 자체는 사소했습니다.

프롬프트 3 – “List getAllLabelsSorted()를 구현해 주세요. 이 메서드는 [0,0] 점에 대한 근접도 순으로 모든 라벨을 정렬해서 반환해야 합니다”

• 여기서 문제가 시작되었습니다.
• 코드가 더 간결해질 수 있었습니다.
• LLM은 알고리즘 작업에 뛰어나지만 그 이유가 좋지는 않습니다: long을 두 개의 int로 풀어 매번 메서드가 호출될 때마다 정렬합니다.
• 저는 **TreeMap**을 사용하길 기대했는데, 이는 모든 정렬된 엔트리를 저장하고 삽입·조회 모두 O(log n) 복잡도를 제공하기 때문입니다.

프롬프트 4 – “메서드가 호출될 때마다 라벨을 다시 정렬하고 싶지 않아요”

오마이갓!!! 캐시!!! 더 나쁠 수 있을까요?!

그 뒤 여러 프롬프트를 시도했으며, TreeMap과 같은 구조와 비교자를 가진 레코드(직접 TreeMap을 언급하지 않음, 제가 그것을 모른다고 가정)를 목표로 했습니다.

결과: 운이 없었습니다. 질문을 할수록 솔루션은 점점 복잡해졌고, 읽기 힘든 코드 세 페이지가 나왔습니다.

원하는 솔루션 (단순화)

• 특정 클래스를 사용합니다.
• 스레드‑안전합니다.
• 과도한 데이터를 저장하지 않습니다.

예, 이 접근법은 의견이 반영된 것입니다. O(log n) 복잡도를 갖습니다—바로 제가 원했던 것이죠.

핵심 인사이트: 최소 50 % 이상의 해결책을 이미 알고 기술적인 용어로 설명할 수 있을 때만 AI에게서 원하는 코드를 얻을 수 있습니다. 원하는 결과에 대한 명확한 이해 없이 AI 에이전트를 사용하면 출력이 사실상 무작위가 됩니다.

AI 에이전트를 올바른 기술 아키텍처를 사용하도록 지시할 수 있을까?

• 예를 들어 records 를 사용하도록 지시할 수는 있지만 상식 을 가르칠 수는 없습니다.
• project.rules.md 파일을 만들어 특정 규칙을 정의할 수는 있지만 이를 모든 프로젝트에 적용 가능한 보편적인 해결책으로 재사용할 수는 없습니다.

가장 큰 문제: 지원 가능성

• 코드가 동작할 수는 있지만 품질이 의심스러운 경우가 많습니다.
• 지원하기 어려운 코드는 변경하기도 어렵습니다 – 자주 업데이트가 필요한 운영 환경에서는 심각한 문제입니다.

일부 사람들은 앞으로 도구가 요구사항만으로 코드를 생성해줄 것이라고 기대하지만, 이는 아직 멀리 남아 있는 일입니다. 현재는 지원 가능성이 가장 중요합니다.

AI 코딩 어시스턴트가 코드를 읽을 수 없는 엉망으로 만들 때

AI를 사용하면 안 된다는 의미는 아닙니다.
단지 생성된 코드의 모든 라인을 검토해야 한다는 뜻이며, 이는 강력한 코드 읽기 능력을 필요로 합니다. 문제는 많은 개발자들이 이러한 경험이 부족하다는 점입니다.

AI 지원 코딩은 얼마나 더 빨라질 수 있을까?

• 언어와 프레임워크에 따라 최대 10~20배 빠를 수 있습니다.
• 코드를 읽고 검토해야 합니다.

AI 어시스턴트가 빛나는 영역

• 구조가 강력한 언어(예: Java, C#, TypeScript)에서 안정적이고 전통적이며 규격을 준수하는 코드.

AI 어시스턴트가 어려움을 겪는 영역

• 강력한 컴파일이나 검증이 없는 코드베이스.
• 코드 리뷰와 같은 소프트웨어 개발 라이프사이클의 일부에서는 AI가 생성한 코드가 자주 깨집니다.

실용적인 시사점

1. 코드를 요청하기 전에 무엇을 만들고 있는지 알아두세요.
2. 현재 모범 사례에 익숙해지세요 (예: Java 11이 아니라, Angular 12가 아니라).
3. 받은 코드를 읽어보세요 – AI 출력물을 초안으로 여기고, 프로덕션 준비된 코드로 간주하지 마세요.
4. AI 어시스턴트를 보일러플레이트 작성이나 탐색적 프로토타이핑에 사용하되, 코드 리뷰나 최종 구현에 의존하지 마세요.

제 의견으로는 어시스턴트가 이미 코드를 작성하는 데 유용하지만, 코드 리뷰를 대체할 준비는 아직 안 됐습니다. 앞으로는 바뀔 수도 있겠지만, 오늘은 아닙니다.

nytime soon.

이러한 모든 도전을 염두에 두고, 여러분이 집중해야 할 사항은 다음과 같습니다:

• 의미가 있을 때 AI 어시스턴트를 사용하기 시작하세요.
• 메인 프로젝트가 아니라면, 다른 곳에서 실험해 보며 최신성을 유지하세요.
• 언어 사양을 철저히 검토하세요.
• 실습을 통해 기술 아키텍처 역량을 향상시키세요.

신중하게 사용하면 AI가 당신의 속도를 높일 수 있습니다. 무분별하게 사용하면 나중에 속도가 느려집니다.