한줄 요약: Access를 한 번도 열지 않고, PowerShell 스크립트 한 번 실행으로 4-테이블 + 인덱스 + 관계 + 시드데이터까지 들어간 .accdb 파일이 통째로 생성됐습니다.
이런 경우에 도움이 돼요
설계문서(SQL DDL)는 만들었는데, Access GUI에서 컬럼 90개를 일일이 클릭해서 입력할 생각에 한숨이 나올 때
"이런 자동화가 가능하다는 걸 알았다면 진작 시도했을 텐데" 싶을 때
비개발자지만 PowerShell이라는 단어에 거부감은 없다 싶을 때
동일한 DB 구조를 여러 환경(개발/운영/백업)에 반복 배포해야 할 때
소개: 시도하고자 했던 것과 그 이유
이전 글(1)·(2)에서 Excel 양식 14개와 Access DB 설계서를 완성했습니다. 그 다음 단계는 당연히 Access를 열고 → 새 데이터베이스 만들기 → 테이블 디자인 모드로 들어가서 → 컬럼명과 데이터 타입을 하나씩 입력하기였습니다.
그런데 컬럼 수를 세어보니 4개 테이블에 총 100개(46+37+13+4)였습니다. 인덱스 15개, 관계 1개, 시드 데이터 9건도 손으로 넣어야 했죠. 한 번 만들고 끝나면 그래도 견딜 만한데, 설계 변경이 일어날 때마다 처음부터 다시 만들어야 한다는 게 부담이었습니다.
그래서 Claude에게 가볍게 물어봤습니다.
"Database기획.xlsx에 AccessDB가 기획되어 있어. 이걸 기반으로 이 폴더에 Access 파일을 만들고 거기에 테이블을 생성하고 관계까지 만드려고 해. 이 작업을 실행할 수 있는 계획을 제시해줘."
저는 솔직히 "엑셀에서 SQL DDL 텍스트를 뽑아서 Access에 복붙하는 가이드"가 나올 줄 알았습니다. Access 파일 자체를 자동으로 만든다는 발상은 머릿속에 없었거든요. 그런데 Claude가 내놓은 답이 예상 밖이었습니다.
진행 방법: 어떻게 AI와 협업했나요?
도구: Claude Code, PowerShell, Microsoft ACE OLEDB Provider (Access 설치하면 같이 깔려 있음)
"오, 이거 진짜 되네!" 했던 순간
Claude가 제시한 계획은 간단했습니다:
PowerShell + ADOX(COM 객체)로 빈 .accdb 파일 생성
ADODB.Connection으로 SQL DDL 실행 (CREATE TABLE / CREATE INDEX / INSERT)
검증까지 한 스크립트 안에서 자동 출력
저는 이 조합 자체를 처음 알았습니다. Windows에 이미 깔려 있는 PowerShell과 Office가 깔려 있으면 따라오는 ACE OLEDB만으로 .accdb 파일을 통째로 만들어낼 수 있다는 것. Access를 한 번도 열지 않고요.
그리고 더 놀라운 건, 제가 이전 단계에서 만들어둔 Database기획.xlsx의 AccessDB설계 시트를 Claude가 직접 PowerShell로 읽어서 컬럼 정의 100개를 한 줄도 빠트리지 않고 스크립트에 옮겨담았다는 것입니다.
# Create-ProductionDB.ps1 (핵심부)
# 1. ACE Provider 자동 탐지
foreach ($p in @('Microsoft.ACE.OLEDB.16.0', 'Microsoft.ACE.OLEDB.12.0')) {
try { ...; $provider = $p; break } catch {}
}
# 2. ADOX로 빈 .accdb 생성
$cat = New-Object -ComObject ADOX.Catalog
$cat.Create("Provider=$provider;Data Source=$DbPath;")
# 3. ADO Connection 열고 SQL 실행
$conn = New-Object -ComObject ADODB.Connection
$conn.Open($connStr)
# tbl_생산의뢰 (46 cols, UK 생산의뢰번호)
$conn.Execute(@"
CREATE TABLE [tbl_생산의뢰] (
[ID] AUTOINCREMENT PRIMARY KEY,
[생산의뢰번호] TEXT(30) NOT NULL,
[의뢰일] DATETIME,
... (나머지 43개 컬럼)
CONSTRAINT UK_생산의뢰번호 UNIQUE ([생산의뢰번호])
);
"@)
# tbl_작업지시 (37 cols, FK to tbl_생산의뢰)
$conn.Execute(@"
CREATE TABLE [tbl_작업지시] (
...
CONSTRAINT FK_생산의뢰 FOREIGN KEY ([생산의뢰번호])
REFERENCES [tbl_생산의뢰]([생산의뢰번호])
);
"@)
스크립트를 실행하니 3초 만에 304KB짜리 생산관리.accdb 파일이 폴더에 떡 하니 생겼습니다. Access로 열어보니 테이블 4개, 관계 1:N 선까지 그대로 그려져 있었고, tbl_가공팀마스터에는 가공1, 가공2, 외주3~9 9건이 미리 들어가 있었습니다.
정말 솔직한 감상은 이거였습니다.
"엑셀 양식이 만들어지는 건 이해했어. 그런데 Access DB 파일까지 만들어 줄 줄은 몰랐네. ㅎㅎ"
진행하면서 곤란했던 부분 ①: 한글 인코딩
스크립트를 처음 실행하니 에러가 줄줄이 떴습니다.
$sql_?�업지??= @"
'[' 뒤에 식별자가 없습니다.
원인은 황당했습니다. Windows에 기본 설치된 PowerShell 5.1은 .ps1 파일을 ANSI(CP949)로 읽습니다. Claude가 만든 스크립트는 UTF-8이었고, 그 안에 한글 변수명($sql_작업지시)과 한글 SQL이 들어 있었으니 PS 5.1이 이걸 깨진 글자로 읽고 파싱 에러를 낸 것이죠.
해결책은 UTF-8 BOM을 파일 앞에 붙이는 것이었습니다. BOM이 있으면 PS 5.1도 UTF-8로 인식합니다.
$content = [System.IO.File]::ReadAllText($path, [System.Text.Encoding]::UTF8)
$utf8Bom = New-Object System.Text.UTF8Encoding $true
[System.IO.File]::WriteAllText($path, $content, $utf8Bom)
진행하면서 곤란했던 부분 ②: PowerShell 5.1의 미묘한 차이
BOM을 붙이니 한글은 통과했는데 이번엔 다른 에러가 났습니다.
$PSScriptRoot가 빈 값으로 들어와서 기본 경로 계산이 실패검증 단계에서
Write-Host -ForegroundColor (if($x){'Green'}else{'Red'})같은 inline if 표현식이 PS 5.1에서는 인식 안 됨
둘 다 작은 차이지만, PowerShell 7에서는 멀쩡히 돌아가는 코드입니다. 회사 PC에 깔린 게 PS 5.1뿐이라면 호환성을 신경 써야 한다는 걸 배웠습니다.
다행히 가장 중요한 부분(테이블 생성, 인덱스, FK, 시드 INSERT)은 첫 성공 실행에서 모두 통과했고, 검증 블록만 별도로 돌려서 결과를 확인할 수 있었습니다.
=== Tables ===
[OK] tbl_BOM cols=13 expected=13
[OK] tbl_가공팀마스터 cols=4 expected=4
[OK] tbl_생산의뢰 cols=46 expected=46
[OK] tbl_작업지시 cols=37 expected=37
=== FK on tbl_작업지시 ===
Key: FK_생산의뢰 Type=2 (Foreign) RelatedTable=tbl_생산의뢰
=== tbl_가공팀마스터 rows ===
P01 | 가공1 | 사내
P02 | 가공2 | 사내
O03 | 외주3 | 사외
... (총 9건)
DB size: 304.0 KB
결과와 배운 점
결과물:
생산관리.accdb파일 1개 (304KB) — Access를 한 번도 열지 않고 생성Create-ProductionDB.ps1스크립트 1개 — 설계가 바뀌어도 다시 돌리면 그만4개 테이블 / 100개 컬럼 / 15개 인덱스 / 1개 FK 관계 / 9건 시드데이터 — 모두 한 번에
배운 점:
"이건 AI가 못 할 테니까 내가 해야할꺼야"는 생각을 버리고 본다. 예전에 AI는 이진파일은 생성하지 못하는 줄 알았습니다. 그래서 나는 처음에 "Access 파일까지는 못 만들겠지, SQL 스크립트나 받아서 내가 복붙해야지"라고 미리 한계선을 그었습니다. 그런데 실제로는 가능했습니다. AI에게 부탁하는 범위를 좁히는 가장 큰 원인은 AI의 한계가 아니라 내가 가진 선입견이었습니다.
이미 깔려 있는 도구를 새롭게 조합하는 게 강력합니다. PowerShell, COM, ACE OLEDB는 다 Windows/Office에 기본으로 들어있는 것들입니다. 새로 설치할 게 하나도 없는데 이게 합쳐지니 GUI 클릭 수백 번이 한 번의 스크립트 실행으로 압축됐습니다. AI는 이런 "이미 있는 것들의 새로운 조합"을 잘 떠올려줍니다.
재현 가능한 빌드의 가치. 손으로 만들면 1번 만들고 끝이지만, 스크립트로 만들면 10번이든 100번이든 똑같이 만들 수 있습니다. 설계 변경이 두렵지 않게 됐습니다. "테이블 컬럼 하나 추가해야 해" → 스크립트 한 줄 고치고 다시 실행하면 끝.
PS 5.1의 함정. 회사 PC에 깔린 PowerShell 버전을 미리 확인하세요. 한글이 들어간 스크립트는 UTF-8 BOM 필수, inline if 표현식 같은 PS 7 전용 문법은 피하기.
다음 단계
이제 진짜 마지막입니다. Excel VBA 매크로(검색/등록/수정/삭제)를 이 .accdb를 가리키도록 연결하고, Dropbox 공유 폴더에 배포해서 6명이 동시 사용할 수 있는 환경을 만드는 것. 그리고 BOM 전개, 가공팀별 실적 집계, 출하확인서 출력 같은 추가 기능 5종을 실제로 돌려보는 일이 남았습니다.
3편에 걸쳐 글을 쓰면서 가장 크게 바뀐 건 제 자신의 마음가짐이었습니다. "이 정도까진 못 하겠지"의 경계가 매번 한 칸씩 뒤로 밀렸습니다.
재사용 가능한 프롬프트
[xlsx 파일 또는 SQL DDL 문서]에 Access DB 스키마가 정의되어 있어.
이걸 기반으로 [경로]에 .accdb 파일을 자동 생성하는
PowerShell 스크립트를 만들어줘.
요구사항:
1. PowerShell + ADOX/ADODB로 빈 .accdb 생성 (Access GUI 안 열고)
2. ACE OLEDB Provider 자동 탐지 (16.0 → 12.0 순)
3. CREATE TABLE → CREATE INDEX → INSERT (시드 데이터) 순서로 실행
4. FK 제약은 참조 컬럼이 PK 또는 UNIQUE여야 함을 고려
5. 한글 식별자는 [대괄호]로 감싸기
6. PowerShell 5.1 호환 (inline if 표현식 사용 금지)
7. 파일 저장 시 UTF-8 BOM 필수 (한글 깨짐 방지)
8. 마지막에 검증 블록: 테이블 목록, 컬럼 수, FK, 시드 행 수 출력
9. 기존 파일이 있으면 덮어쓰지 말고 중단
먼저 스키마 정의부터 정확히 추출한 뒤,
컬럼 수를 보고하고 작성을 시작해줘.