※ 이 글은 wada kentaro(和田健太郎) 글 https://qiita.com/WdknWdkn/items/9b7dea889fec59194df5 을 의역한 것입니다.

주니어에게 AI를 사용하게 했는데… 어떤 문제가 발생했을까?

처음에는 다음과 같은 이유로 AI를 사용하게 했다.

  • 개발속도 향상
  • 최신 기술의 습득
  • 코드 품질 향상 기대

얼마 지나지 않아 이 주니어 개발자들의 코드를 리뷰했는데 충격이었음. 주요 문제점들은

  1. 모델 계층에 HTML생성(MVC아키텍처의 무시)
  2. 디버그 코드가 배포판에 들어가 있음
  3. 500행이 넘는 대규모 JS코드
  4. 테스트 코드가 전혀 없음
  5. 변수명이나 함수 명이 기존 코드와 전혀 맞지 않음

이 중 하나인 MVC 아키텍처의 무시 사례를 보면

<?php
class Product_Model_Service_AiDescriptionService
{
    public function generateCategorySelectHtml($keyword)
    {
        // ❌ Model층에 html을 넣었다.
        $htmlOutput = '';
        foreach ($categories as $category => $items) {
            $htmlOutput .= '<div class="category-group">';
            $htmlOutput .= '<h3 class="category-title">カテゴリ: ' .
                           htmlspecialchars($category, ENT_QUOTES, 'UTF-8') . '</h3>';
            $htmlOutput .= '<ul class="product-list">';

            foreach ($items as $item) {
                $htmlOutput .= '<li class="product-item">';
                $htmlOutput .= '<input type="checkbox" name="products[]" value="' .
                               htmlspecialchars($item['sku'], ENT_QUOTES, 'UTF-8') . '">';
                $htmlOutput .= htmlspecialchars($item['name'], ENT_QUOTES, 'UTF-8');
                $htmlOutput .= '</li>';
            }
            $htmlOutput .= '</ul></div>';
        }
        return $htmlOutput;
    }
}

분명 이 코드는 문제없이 돌아가겠지만, 유지보수성 관점에서는 분명 좋은 코드는 아니다. 이렇게 만든 이유를 담당자에게 물어보았는데..

‘AI가 이렇게 만들어 주었기 때문에 이게 맞다고 생각했습니다!!’

‘솔직히 AI가 만든 코드가 제가 만든 것보더 더 정확하다고 느낄 때가 있어요. 이제 거의 신이나 다름없네요.’

이런 반응을 보고 필자는 AI의 출력 결과를 판단할 ‘기초’ 가 없다면 상당히 위험한 일이 되겠다고 느꼈다. 그래서

AI금지령

을 내렸다 .

그러면서 시킨 것은 다음과 같다.

  1. 공식 문서 읽히기
  2. 기존 코드 읽히기
  3. 설계의 표현법 익히기
    • 개발 전에 설계서를 만들기
    • 책임 분리를 다이어그램으로 표현하기

그랬더니

질문이 바뀌었다.

이전에는

“이런 에러가 뜨는데, 어떻게 해야 되나요?” “작동을 안해요”

였지만 AI금지령 이후에는

“이 설계에 따르면, Controller층에 구현이 집중되어 있는데 이를 Service층으로 옮기는게 좋지 않을까요?” “기존 ProductHelper와 지금의 ProductService의 명명규칙이 다른데, 어떤게 맞나요?”

질문이 구체적으로 바뀌었다.

AI금지만이 전부는 아니다.

단순히 AI 금지만 시키면 관리자로서 너무 무책임하다는 생각이 들었다. 주1회 프로젝트 피드백 진행 시 단계적으로 구현을 진행하도록 아래와 같은 단계로 진행을 했다 .

Step1. 클래스명, 함수명만 리뷰

  • 클레스 명과 함수명만 작성케 하여 여기부터 리뷰를 진행했다.
  • 어떤 클래스를 만들까? 어떤 함수가 필요할 까를 고민하게 만들었음

Step2. 주석문만 작성하여 리뷰

  • 클래스, 코드명에 대해 어느 정도 합의가 이루어지면, function내 구현 코드가 아닌 주석문만 작성케 한다.
  • 클래스, 함수 내의 처리의 흐름을 정리하기 위해서 이다.

Step3. CSS, 레이아웃을 무시한 구현 리뷰

  • 일단 프론트의 CSS, 레이아웃은 무시하고 구현을 시킨 후 이에 대해 리뷰를 한다.
  • 데이터의 흐름, 비즈니스 로직의 리뷰에 주력한다
  • 흔히 말하는 코드 리뷰의 활동과 유사

Step4. CSS, 레이아웃을 반영하여 리뷰

  • 이제는 전반적으로 화면까지 적용한 후에 체크하는 작업

AI를 사용한 개발체계에서는 이런 4단계의 리뷰는 불가능할 것이다. 당연하겠지만, AI는 이미 완성 코드를 만들어 주기 때문에 단계적인 분리도 불가능할 뿐더러 주니어 개발자들이 ‘문제의 본질’에 접근하는 길이 원천차단 되어 버린다.

3개월 후 이렇게 바뀌었어요

MVC애 따른 책임의 분리

<?php
// Model층: 데이터만 돌려준다
class Product_Model_Service_AiDescriptionService
{
    public function getCategoryCandidates($keyword)
    {
        return $categories; // 순수 데이터 array
    }
}

// ViewHelper: HTML생성
class Product_View_Helper_CategoryProductList extends View_Helper_Abstract
{
    public function categoryProductList(array $categories)
    {
        $html = '';
        foreach ($categories as $category => $products) {
            $html .= $this->view->partial(
                'partials/category-products.phtml',
                ['category' => $category, 'products' => $products]
            );
        }
        return $html;
    }
}

DataProvider패턴을 사용한 단위 테스트

<?php
class Coupon_Model_Service_CalculatorTest extends TestCase
{
    public function provideCalculateDiscountCases(): array
    {
        return [
            '고정금액할인：일반ケース' => [
                'subtotal' => 10000,
                'discountType' => 1,
                'discountValue' => 500,
                'expected' => 500,
            ],
            '퍼센트할인：소수점 이하 버림' => [
                'subtotal' => 1999,
                'discountType' => 2,
                'discountValue' => 15,
                'expected' => 299,
            ],
        ];
    }

    /**
     * @dataProvider provideCalculateDiscountCases
     */
    public function test_calculateDiscount($subtotal, $discountType, $discountValue, $expected): void
    {
        $result = $this->calculator->calculateDiscount($subtotal, $coupon);
        $this->assertSame($expected, $result);
    }
}

그 외에 개선점은

  • ViewHelper에 의한 View로직의 분리
  • CSS/JavaScript의 외부파일화
  • 전자상거래 특성에 맞춘 비즈니스 로직의 구현

필자는 무엇보다도 구현 내용에 대해 QA 가 가능해졌다는 점이 큰 개선점이라고 생각했다.

AI의 금지령 해제, 그 이후 변화

금지령 이전 AI의 사용법

  • “쿠폰 기능을 만들어 줘” 라고 요청
  • 출력된 코드를 그대로 복붙하기
  • 작동만 되면 OK

금지령 이후 AI사용법

  • 단계를 나누어 지시
    • “먼저 데이터 모델의 설계안을 만들어 줘”
    • “다음으로는 이 설계에 대한 테스트 케이스를 만들어 줘”
    • “그 후에 구현 코드를 만들어 줘”
  • AI의 제안에 본인의 의견을 역제안
    • “이 HTML생성은 ViewHelper로 분리해야 하는 거 아닌가?”
    • “이 처리는 Service층에서 해야 하는 거 아닌가?”
  • 최종 판단의 책임은 자신이 진다.
    • AI의 제안을 받아들일까, 자기가 직접 할까를 판단할 수 있다.

결국 필자는 AI에 전부 맡기는 것이 아닌, 커뮤니케이션을 하는 대상으로 보게 된 것이 가장 큰 수확이라는 것이다.

AI금지령을 전략적으로 …

필자는 코드 리뷰를 대상으로 AI의 금지령 경험을 적었지만 다음과 같은 경우에도 금지령을 적용할 수 있을 거라 적었다.

  1. CRUD의 기본을 가르치기
  2. SOLID원칙을 가르치기
  3. 디자인 패턴을 가르치기
  4. 성능 최적화를 가르치기

모두 개발의 기본 내용이며 이를 위해서 일시적으로 AI금지령을 내리는 것이 좋을 것이다.

정리하면

  1. AI라는 도구를 쥐어주는 것만으로 AI인재는 육성되지 않는다
  2. ‘금지’ 일까 ‘해제’ 일까 … 단계적으로 이 둘을 반복하여 적용한다
  3. AI시대에서 ‘생각하는 토대’ 를 지닌 인재를 길러야 한다.
  4. 질문의 질을 높여야 한다
    • ‘어떻게 하면 될 까’ 에서 ‘이 설계가 맞을 까? ’ 로의 질문의 변화