안녕하세요, 

요즘 Claude, GPT-4o, Cursor, Copilot 등 AI 코딩 에이전트를 활용해 개발하시는 분들 정말 많아졌죠? 저도 그누보드5 기반 사이트를 유지보수하고 플러그인 개발할 때 AI를 적극적으로 쓰고 있는데요. Laravel, Django, Spring 같은 현대적인 프레임워크에 비해 그누보드5에서는 AI가 유독 많이 헤매는 모습을 자주 봅니다.

왜 그럴까 깊이 고민해보니, 그누보드5의 설계 특성이 AI의 코드 생성 방식(패턴 기반 추론 + 정적 분석 위주)과 근본적으로 맞지 않기 때문이더라고요. 오늘 그 이유를 세 가지로 정리해서 공유드립니다.

1. DB 테이블 명세(스키마 문서)가 공식적으로 없다

AI 코딩 도구가 데이터베이스 관련 코드를 제대로 생성하려면 테이블 구조를 명확히 알아야 합니다. 현대 프레임워크들은 보통 아래처럼 스키마를 명시적으로 정의하죠:

// Laravel 예시 (마이그레이션)
Schema::create('users', function (Blueprint $table) {
    $table->id();
    $table->string('name');
    $table->string('email')->unique();
    // ...
});

하지만 그누보드5는 어떨까요?

// 그누보드5 현실
sql_query("SELECT * FROM {$g5['member_table']} WHERE mb_id = '{$mb_id}'");

• 테이블 구조(컬럼명, 타입, 제약조건)가 PHP 코드 어디에도 명시되어 있지 않습니다.
• 공식 매뉴얼에도 상세 ERD나 컬럼 목록이 없어요.
• g5_member, g5_board, g5_write_* 테이블의 컬럼은 소스 주석이나 직접 DB를 들여다봐야 알 수 있죠.

AI는 학습 데이터에서 “member 테이블에는 보통 id, name, email, password 같은 컬럼이 있다”는 패턴으로 추론합니다. 그런데 그누보드5는 mb_id, mb_password, mb_name, mb_level, mb_point 등 독자적인 컬럼명을 쓰고, 일부 필드는 별도 테이블로 분리되기도 하죠.

결과적으로 AI가 회원 정보 수정 쿼리를 생성할 때:

• 존재하지 않는 컬럼명 사용 (예: email 대신 mb_email을 모름)
• 타입 불일치 (varchar 길이, NOT NULL 제약 무시)
• JOIN 관계 오해

이런 오류가 빈번하게 발생합니다.

2. 테이블 이름이 변수로 동적으로 매핑된다

이 부분이 AI에게 가장 큰 걸림돌입니다.

일반적인 프레임워크:

// Laravel 예시
$posts = DB::table('posts')->where('id', $id)->get();

테이블명이 코드에 정적으로 명시되어 있어 AI가 쉽게 파악하죠.

반면 그누보드5:

$write_table = $g5['write_prefix'] . $bo_table;  // 예: g5_write_free
$row = sql_fetch("SELECT * FROM {$write_table} WHERE wr_id = '{$wr_id}'");

• 게시판마다 별도 테이블(g5_write_notice, g5_write_gallery 등)이 동적으로 생성됩니다.
• $g5['write_prefix'], $bo_table 값은 런타임에 결정되죠.
• config.php에 정의된 $g5 배열을 통해 모든 테이블명이 변수로 참조됩니다.

AI 입장에서는:

• 정적 분석으로 실제 테이블명을 알 수 없음
• $bo_table이 어떤 값이 들어올지 컨텍스트 없이는 추론 불가
• 문자열 결합 쿼리를 제대로 처리하지 못해 SQL 문법 오류 발생

특히 다중 게시판 프로젝트에서 AI가 “특정 게시판의 글을 조회하는 쿼리”를 만들 때, 고정된 테이블명을 쓰거나 prefix를 빼먹는 실수를 자주 합니다.

3. 스킨 + 테마의 이중 렌더링 구조와 include 지옥

그누보드5의 뷰 렌더링 구조는 정말 복잡합니다.

대략적인 흐름:

요청 → bbs/board.php 
    → lib/common.lib.php 등 공통 라이브러리 로드
    → 테마 적용 여부 확인 (G5_THEME_PATH 정의 시)
    → 스킨 경로 결정 (/theme/테마명/skin/board/스킨명/ 또는 기본 skin/)
    → list.skin.php, write.skin.php 등 수많은 include
    → head/tail sub 파일, hook 호출 등

코드 예시:

// board.php 일부 발췌
if (defined('G5_THEME_PATH') && is_file(G5_THEME_PATH.'/skin/board/'.$board['bo_skin'].'/list.skin.php')) {
    $board_skin_path = G5_THEME_PATH.'/skin/board/'.$board['bo_skin'];
} else {
    $board_skin_path = G5_SKIN_PATH.'/board/'.$board['bo_skin'];
}
include_once($board_skin_path.'/list.skin.php');

AI가 “게시판 목록에 커스텀 필드 추가해주세요”라고 요청받으면:

• 테마가 적용됐는지, 어떤 스킨을 쓰는지 모름
• $list 배열, $write 변수가 어디서 정의됐는지 추적 어려움
• include된 수십 개 파일과 hook(G5_HOOK) 시스템을 전체적으로 고려하지 못함

결과적으로 잘못된 파일을 수정하거나, 레이아웃이 깨지거나, 변수 미정의 오류를 내는 코드를 생성합니다.

그래서 어떻게 대처하면 좋을까?

그누보드5 + AI 조합을 포기할 필요는 없습니다! 아래 팁으로 오류를 크게 줄일 수 있어요.

1. 테이블 스키마 문서를 별도로 만들어 프롬프트에 첨부
   SQL

   -- 주요 테이블 예시
   CREATE TABLE g5_member (
       mb_id VARCHAR(20) NOT NULL PRIMARY KEY,
       mb_password VARCHAR(255) NOT NULL,
       mb_name VARCHAR(255) NOT NULL,
       mb_email VARCHAR(255),
       mb_level TINYINT DEFAULT 1,
       mb_point INT DEFAULT 0,
       -- ...
   );
   
   CREATE TABLE g5_write_{bo_table} (
       wr_id INT AUTO_INCREMENT PRIMARY KEY,
       wr_num INT,
       wr_subject VARCHAR(255),
       wr_content TEXT,
       -- ...
   );

2. $g5 테이블 매핑과 프로젝트 구조를 명시적으로 알려주기
   text

   현재 프로젝트 설정:
   - $g5['member_table'] = 'g5_member'
   - $g5['write_prefix'] = 'g5_write_'
   - 사용 중인 테마: basic (또는 없음)
   - 게시판 스킨 경로: /theme/basic/skin/board/basic/

3. 수정 범위를 좁혀서 순차적으로 요청
   • 전체 기능 대신 “list.skin.php 파일만 수정해 주세요” 식으로
   • 전체 소스 zip을 컨텍스트로 제공 (Claude 3.5나 GPT-4o처럼 긴 컨텍스트 지원 모델에서 효과적)

마치며

그누보드5가 나쁜 아키텍처라는 뜻은 절대 아닙니다. 2000년대 초중반 PHP 생태계에서는 매우 합리적이고 유연한 설계였고, 지금도 수많은 중소 사이트가 안정적으로 운영되고 있죠.

다만 AI 코딩 시대에는 명시적 스키마, 정적 분석 가능 코드, 단일 책임 원칙 등이 중요해졌는데, 그누보드5는 이런 부분에서 조금 불리한 위치에 있습니다.

그누보드6나 영카트6(혹시 개발 중이라면)에서는 마이그레이션 지원, Entity 기반 ORM, 컴포넌트화된 뷰 시스템 등으로 개선되면 좋겠네요. 공식 개발팀 분들 보고 계시면 고려 부탁드려요! 😄

AI 쓰시면서 비슷한 경험 있으신 분들, 어떤 식으로 극복하셨는지 댓글로 공유해 주시면 감사하겠습니다.

p.s. 저는 최근 그누보드5 프로젝트용 “AI 전용 컨텍스트 문서”(테이블 스키마 + 주요 변수 매핑 + hook 목록)를 따로 만들어 쓰고 있는데, 오류율이 70% 이상 줄었어요. 관심 있으신 분들 많으면 별도 글로 정리해서 올려볼게요!

감사합니다 🙏