그누보드 5.6.40 공개, LG 가상계좌 보안 강화…DB업그레이드 필수

그누보드 5.6.40 보안패치 핵심

그누보드 5.6.40은 LG 가상계좌 입금 통보의 검증과 거래 정합성을 강화한 보안 업데이트입니다. 2026년 9월 20일 배포됐으며 SIR 배포 게시물은 9월 21일 등록됐습니다. 이번 버전에서는 발신 정보와 실제 저장된 거래를 함께 확인하고, 중복·역순 통보와 처리 중 실패한 요청의 재처리까지 보호하도록 관련 로직이 보완됐습니다.

 

 

그누보드 5.6.40 배포

 

운영 중인 사이트라면 파일만 교체하고 끝내서는 안 됩니다. DB업그레이드가 필수이며, 기존 미입금 LG 거래가 남아 있다면 PG 원장과 MID를 직접 대조하는 절차도 필요합니다. 업데이트가 과거 거래의 정합성을 자동으로 복구하는 방식은 아니므로 아래 순서를 함께 확인하는 것이 중요합니다.

LG 가상계좌 통보에서 무엇이 달라졌나

가상계좌 입금 통보는 주문의 입금 상태를 실제로 변경하는 요청입니다. 기존에는 LG 상점키가 비어 있거나 다른 PG 주문인 경우에도 특정 경로에서 입금 처리로 이어질 가능성이 있었는데, 5.6.40에서는 이 부분을 차단했습니다.

 

KVE-2026-2424 보안 수정에 따라 발신 IP, 상점키, 서명을 검사하고, 통보에 포함된 내용이 저장된 상점 MID, PG, 거래번호, 계좌, 금액과 일치하는지도 대조합니다. 통보 정보 한 가지만 확인하는 것이 아니라 실제 주문 데이터와 함께 검증하는 구조가 핵심입니다.

결제 당시 LG MID를 별도로 저장

PC와 모바일의 일반 주문뿐 아니라 개인결제에서도 결제 당시 사용한 LG MID를 별도로 저장합니다. 사이트 운영 중 상점 설정이 변경되더라도 과거 거래가 어떤 MID로 처리됐는지 구분하기 위한 조치입니다.

 

이 변경은 기존 거래를 처리할 때도 중요합니다. 과거 주문 가운데 결제 시점의 MID가 저장되지 않은 거래는 현재 설정값을 기준으로 임의 추정해 처리하지 않습니다. 미입금 상태인 기존 LG 거래가 있다면 실제 PG 원장을 확인한 후 검증된 값만 보정해야 합니다.

중복·동시·역순 통보와 실패 후 재처리 보호

PG 통보는 항상 한 번만, 정해진 순서대로 도착한다고 볼 수 없습니다. 정상 입금 통보가 여러 차례 재전송될 수 있고 입금과 은행 취소의 순서가 바뀌는 상황도 발생할 수 있습니다.

 

이번 버전은 통보 처리 이력을 저장하고 관련 테이블을 잠그는 방식을 도입했습니다. 같은 통보가 다시 들어와도 중복 반영되지 않도록 구분하고, 동시에 들어오는 요청이나 순서가 바뀐 요청도 보호합니다. 처리 도중 일부 단계에서 실패한 경우에는 같은 통보를 이용해 남은 작업을 복구할 수 있도록 보완됐습니다.

입금 취소와 개인결제 처리도 보완

은행 입금 취소는 확인된 금액만 되돌림

은행에서 입금 취소 통보가 들어오면 확인된 입금 이력의 금액만 되돌립니다. 이미 출고가 끝난 주문은 물류 상태를 되돌리지 않고 그대로 유지하며, 운영자가 별도로 원장과 대조해야 한다는 기록을 남깁니다.

개인결제 연결 주문이 달라지면 취소 차단

개인결제 입금 이후 연결된 주문이 변경되거나 해제·추가된 경우에는 다른 주문에서 금액이 잘못 차감되지 않도록 취소 처리를 차단합니다. 입금 이후 주문 연결 상태가 변한 거래는 자동 처리보다 데이터 정합성을 우선하도록 바뀐 것입니다.

사용 중지된 개인결제의 기존 취소 처리

사용 중지된 개인결제라도 이미 완료된 입금에 대한 은행 취소는 처리합니다. 다만 사용 중지 상태에서 들어오는 신규 입금은 계속 거부합니다.

5.6.40 업데이트 전에 확인할 버전 정보

항목	내용
버전	5.6.40
배포일	2026년 9월 20일
SIR 게시일	2026년 9월 21일
패치 기준	5.6.391
DB업그레이드	필수, 20260918_001_lg_notification
삭제 대상 파일	없음

신규 설치 SQL과 기존 설치본의 DB업그레이드에는 LG MID 컬럼과 통보 처리 이력 테이블이 추가됩니다. 스키마가 적용되지 않은 상태에서는 주문 저장이나 통보 처리가 실패할 수 있으므로 소스만 먼저 반영한 상태로 운영을 계속하지 않는 것이 중요합니다.

DB업그레이드와 기존 거래 처리 순서

1. 주문 접수를 중지하고 전체 백업

신규 주문과 결제 접수를 잠시 중단한 뒤 현재 소스, 설정 파일, 데이터베이스를 모두 백업합니다. 이때 진행 중인 결제와 기존 미입금 LG 가상계좌 거래가 남아 있는지도 함께 확인합니다.

2. 최고관리자에서 DB업그레이드 실행

최고관리자의 환경설정 → DB업그레이드를 실행합니다. 사용 중인 DB 계정에는 관련 테이블에 대해 LOCK TABLES, SELECT, INSERT, UPDATE 권한이 필요합니다.

3. 기존 미입금 LG 거래는 원장과 직접 대조

기존 미입금 거래가 있다면 PG 원장에서 주문번호, 거래번호, 상점 MID, 운영·테스트 여부, 계좌, 금액을 각각 확인해야 합니다. 대조가 끝난 거래만 od_lg_mid 또는 pp_lg_mid를 보정한 뒤 PG 재통보를 요청합니다.

현재 사이트에 설정된 상점 MID를 과거 거래 전체에 일괄 복사하면 안 됩니다. 기존 주문은 결제 당시 다른 MID 또는 다른 운영 환경을 사용했을 가능성이 있으므로 실제 원장을 기준으로 판단해야 합니다.

4. 캐시 반영과 실제 결제 흐름 테스트

PHP 캐시를 사용하는 서버는 변경된 코드가 실제로 반영됐는지 확인합니다. HTTPS 또는 프록시를 사용하는 환경에서는 원본 IP 복원 상태도 점검해야 합니다.

 

실제 계약된 PG의 테스트 환경에서 PC·모바일 일반 주문과 개인결제를 각각 확인하고, 계좌 발급, 입금, 은행 취소, 재통보가 정상적으로 처리되는지 검증한 후 주문 접수를 다시 시작하는 순서가 안전합니다.

모든 가상계좌 형태에 같은 방식이 적용되는 것은 아님

이번 처리는 일반형 가상계좌의 전액 입금을 대상으로 합니다. 고정식 계좌나 부분입금, 계약별로 취소 금액이나 순번 형식이 다른 경우에는 PG 원장과 별도로 대조해야 합니다.

 

미완료 상태로 남은 통보 이력이 있더라도 임의로 삭제하거나 완료 상태로 변경해서는 안 됩니다. 처리 중 실패한 거래는 아래의 보안 및 복구 안내에 따라 실제 PG 원장과 대조한 후 복구 절차를 진행해야 합니다.

다운로드 파일과 상세 안내

공식 배포 페이지에서는 전체 압축 파일과 패치 파일을 확인할 수 있습니다. 실제 파일은 그누보드 5.6.40 공식 배포 페이지에서 확인하는 것이 좋습니다.

파일	용량
gnuboard5.6.40.zip	12.9 MB
gnuboard5.6.40.tar.gz	11.3 MB
gnuboard5.6.40.patch.zip	60.5 KB

업데이트 전에 아래 3개 문서를 함께 확인하면 실제 변경 코드와 DB 작업, 기존 거래 복구 범위를 구분해서 볼 수 있습니다.

• 5.6.391 → 5.6.40 변경 비교
• 5.6.40 업데이트 안내
• LG 통보 보호 및 기존 거래·실패 복구 안내

업데이트 후 가장 중요한 확인 사항

그누보드 5.6.40은 단순 파일 교체형 패치가 아니라 LG 가상계좌 통보 검증, 결제 시점 MID 저장, 통보 이력 관리, DB 스키마 변경이 함께 적용되는 업데이트입니다. 특히 기존 미입금 거래가 있는 사이트는 현재 설정을 과거 주문에 일괄 적용하지 말고 PG 원장을 기준으로 확인해야 합니다.

 

DB업그레이드를 먼저 정상적으로 완료하고 실제 계약 PG 환경에서 입금과 취소, 재통보까지 확인한 뒤 운영을 재개하는 것이 핵심입니다. 과거 거래나 미완료 통보가 남아 있다면 임의 수정에 앞서 공식 복구 안내를 기준으로 대조하는 것이 필요합니다.

 

추석 연휴 129 상담 24시간 운영…병원·약국 찾기부터 긴급복지까지