Junie가 정식 버전 발표 시, 다음과 같은 문구가 있었습니다.

Database integration. Junie connects to the databases configured in your IDE through DataGrip and the JetBrains Database plugin, and then it queries your real data and writes, fixes, and validates SQL in the same session that handles your code.

"IDE에 설정된 데이터베이스에 연결하여, 실제 데이터를 조회하고, SQL을 작성·수정·검증한다"라고 되어 있었지만,

AI에게 진짜 데이터베이스를 조작하게 해도 괜찮은 걸까? 실수로 DELETE를 실행해 버린다면?

DB에 연결하면, 내용이 외부 LLM으로 전송되는 것 아닌가?

등의 생각이 들었습니다.

그래서 이번에는 테스트용 SQLite DB를 만들어 Junie가 읽기·쓰기·스키마 변경을 수행하는지 실기에서 확인했습니다.

• 승인은 「데이터 읽기 / 데이터 쓰기 / 스키마 읽기 / 스키마 변경」의 4종류로 나뉘어 있음
• 데이터 읽기 승인에는 "해당 데이터를 AI 모델로 전송합니다"라고 명시됨
• Junie의 Brave Mode(승인 스킵)를 켜도, DataGrip 측의 DB 승인은 계속 나타남

이하, 순서대로 무엇을 던졌고 무엇이 나왔는지 작성합니다. 운영 DB는 사용하지 않았습니다.

Junie가 독자적으로 DB 인증 정보를 갖는 것은 아닙니다. DataGrip의 Database 플러그인에 내장된 MCP 서버를 통해, IDE에 등록된 Data Source를 조작하는 구조입니다. 승인 또한 이 MCP 서버 측에서 제어됩니다.

• 제품: DataGrip 2026.1 (DB 데이터 조작용 MCP 기능은 이 버전에서 추가됨)
• AI 에이전트: Junie (DataGrip의 AI Chat 내에서 선택. 모델은 GPT-5.5 / High effort)
• consent (승인) 설정 위치:
  설정 | 도구 | 데이터베이스 | AI 도구

(Settings | Tools | Database | AI Tools)

DataGrip 측의 MCP 서버가 공개하는 DB 조작은 연결 설정 취득·스키마 목록·객체 참조·실행 중인 쿼리 확인·SQL 실행/취소·테이블 프리뷰/CSV 취득 등입니다. 이에 대해 기본적으로 4종류의 사용자 승인이 요구됩니다 (스키마 참조 / 데이터 참조 / 스키마 변경 / 데이터 변경).

이번에는 테스트용 SQLite DB를 준비했습니다. SQLite라면 DataGrip에서 파일을 새로 생성했습니다.

데이터 소스 생성 → SQLite

로 생성. 연결 후, 쿼리 콘솔에서 고객 2명·주문 3건의 테스트용 데이터를 넣습니다.

CREATE TABLE customers (id INTEGER PRIMARY KEY, name TEXT, email TEXT);
INSERT INTO customers (name, email) VALUES ('Alice','a@example.com'), ('Bob','b@example.com');
CREATE TABLE orders (id INTEGER PRIMARY KEY, customer_id INTEGER, total REAL);
...

먼저 Junie에게 물어보았습니다.

junie_test 데이터베이스의 customers 테이블에는 데이터가 몇 건 있나요? 실제로 쿼리를 실행해서 답해 주세요.

그러자 Junie는 database-text-to-sql이라는 내부 스킬을 불러온 뒤, datagrip/execute_tool을 호출하려고 시도하며 승인 다이얼로그가 나타났습니다.

이 문장은 데이터베이스의 데이터를 읽습니다. Junie는 해당 데이터를 AI 모델로 전송합니다.

내용이 외부 LLM으로 전달된다는 점까지 명시하여 동의를 구합니다. 대상 DB·스키마·실행하려는 SQL 전문(SELECT COUNT(*) AS customer_count FROM customers;)도 확인할 수 있습니다. 여기서 「허가」를 누르자, 2건이라고 올바르게 답변이 돌아왔습니다.

Junie가 발행한 SQL은 execute_sql_query --connectionId ... --queryText 'SELECT COUNT(*)...'

라는 형태로 채팅 로그에 남습니다.

다음은 집계를 요청하겠습니다.

customers와 orders를 JOIN 하여, 고객별 총 주문 금액을 많은 순서대로 출력해 주세요.

Junie의 답변

SELECT c.name, SUM(o.total) AS total_order_amount
FROM customers AS c
JOIN orders AS o ON o.customer_id = c.id
...

결과는 Alice: 2000 / Bob: 500. (Alice는 1200+800).

• Allow running MCP? (Yes / No / Always allow "datagrip:execute_tool") … Junie 측의 「MCP 툴을 실행해도 되는지」에 대한 승인
• 데이터 읽기 허용 (허용 / 거부) … DataGrip 측의 DB consent (동의)

에이전트 측과 툴 측에서 승인 레이어(Layer)가 나누어져 있다는 것을 알 수 있습니다.

읽기가 통과되었으므로, 쓰기를 요청하겠습니다.

customers 테이블에 이름 Carol, 이메일 c@example.com인 고객을 추가해 주세요.

여기서 나타난 승인 다이얼로그는 읽기 때와는 다른 문구가 나왔습니다.

이 스테이트먼트(Statement)는 데이터베이스의 데이터를 변경합니다. Junie가 INSERT, UPDATE, DELETE 스테이트먼트를 실행하거나… 이 스키마 내의 데이터를 변경하는 것을 허용합니까?

4종류의 consent (동의)가 읽기와 쓰기에 따라 분기되는 것을 확인할 수 있었습니다.

업무 도입을 고려할 때 안심할 수 있었던 지점이 바로 여기입니다. "AI에게는 읽게 하되, 쓰기는 매번 내가 승인한다"라는 운용이 설정으로 성립됩니다.

이 쓰기 테스트에서 Junie는 첫 번째 시도에 실패했습니다.

채팅 로그를 보면, 첫 번째 INSERT는 다음과 같았습니다.

-- 1회차 (실패)
INSERT INTO customers (name, email) VALUES (Carol, c@example.com) ...

문자열임에도 불구하고 쿼트('...')가 없습니다. 이는 구문 오류(Syntax Error)이며, Junie 자신도

지정한 고객 추가를 시도했으나, SQL문의 구문 오류로 인해 실행에 실패했습니다. 데이터베이스는 쓰기가 가능한 상태였습니다.

라고 보고했습니다. 그리고 그대로 자동 수정하여 재실행했습니다.

-- 2회차 (성공)
INSERT INTO customers (name, email)
VALUES ('Carol', 'c@example.com')
...

이것이 서두의 인용구에 있었던 "writes, fixes, and validates"의 실체입니다.

• fixes: 쿼트 누락 오류를 실행 결과를 보고 스스로 수정
• validates: RETURNING을 붙여 추가된 행(id=3, Carol)을 가져와 검증

"AI가 DB를 만진다"라고 하면 만능 자동화를 상상하게 되지만, 실제로는 AI도 평범하게 SQL 실수를 합니다. 그렇기에 실수를 실행해 버리기 전에 인간이 승인하는 consent (동의) 설계가 의미 있다는 것을 알게 되었습니다.

마지막으로 SELECT * FROM customers;로 Alice / Bob / Carol의 3개 행을 확인하며, 읽기·쓰기·생성·자기 수정의 일련의 과정을 모두 마쳤습니다.

여기까지는 DB 단독 조작이었습니다. 다음은 소스 코드를 읽게 하여, 그것을 바탕으로 DB를 변경할 수 있는지 테스트합니다.

먼저, DB 측에는 아직 없는 phone 필드를 가진 모델을 하나 준비합니다.

# Customer.py
class Customer:
    id: int
    ...

이 프로젝트의 Customer.py 클래스의 필드를 확인하여, junie_test의 customers 테이블에 부족한 컬럼을 추가해 주세요.

라고 요청했습니다.

Customer.py를 읽음 (코드의 필드를 파악) - DB의 스키마를 읽음. 여기서 승인이 나왔습니다.

Junie가 데이터베이스 스키마를 읽습니다. Junie가 이 스키마를 읽는 것을 허용합니까?

• 코드와 DB를 대조하여 차이점을 설명함

Customer.py의 Customer 클래스:
id, name, phone

현재의 customers 테이블:
id, name

• 부족한 컬럼:
  phone

phone은 Python 측에서 str 타입이므로, SQLite에서는 TEXT로 추가합니다. 제약 조건이나 기본값(Default value)은 코드 측에 지정되어 있지 않으므로, 기존 행에 미치는 영향을 피하기 위해 nullable 상태로 추가합니다.

str이기 때문에 TEXT, 기본값 지정이 없으므로 기존 행을 망가뜨리지 않도록 nullable 상태로, 코드의 타입을 근거로 SQL을 구성하고 있습니다.

• ALTER TABLE customers ADD COLUMN phone TEXT;를 실행하려고 하자, 또 다른 승인이 나타났습니다.

이 문구는 데이터베이스의 스키마(Schema)를 변경합니다. Junie가 CREATE, ALTER, DROP 문 등을 실행하여 이 스키마를 변경하는 것을 허용합니까?

앞서 확인한 데이터 변경(INSERT/UPDATE/DELETE)과는 문구가 다르며, 이번 것은 스키마 변경(CREATE/ALTER/DROP)입니다. 허가 후, customers에 phone 열이 추가된 것을 확인했습니다.

이 일련의 테스트를 통해 4종류의 동의(Consent)를 모두 실제 기기에서 확인할 수 있었습니다.

"데이터를 읽기", "데이터를 쓰기", "구조를 읽기", "구조를 바꾸기"가 각각 별도의 승인으로 나뉘어 있습니다. AI에게 어디까지 맡길지를 이 정도의 입도(Granularity)로 결정할 수 있습니다.

Junie에는 Brave Mode(모든 조작 승인을 스킵하는 모드)가 있습니다.

이를 켜고 동일한 조작을 시도해 본 결과:

• Allow running MCP? (Junie 측의 승인)는 더 이상 나타나지 않음 (자동 허가됨)
• DataGrip 측의 DB 데이터 액세스 승인은 Brave Mode를 켜도 나타남

실수로 Brave Mode인 상태로 DB에 연결하더라도, 적어도 데이터 액세스에 대한 동의는 유지됩니다.

단, 확인한 것은 DataGrip 2026.1 + SQLite 조합뿐입니다. 아울러 터미널이나 파일 조작은 Brave Mode에서 통과되므로, DB 이외의 요소도 고려한다면 Off로 두는 것이 무난합니다.

Junie의 DB 연동은 "AI에게 실제 데이터를 만지게 한다"라는 언뜻 무서워 보이는 기능을, 읽기/쓰기로 분리된 4종의 승인과 Junie 측 · DataGrip 측의 2중 레이어로 감싼 구조였습니다.

데이터 읽기 동의 화면에 "AI 모델로 전송합니다"라고 명시되므로, 외부로 무엇이 나가는지도 승인 시점에 판단할 수 있습니다.

AI도 평범하게 SQL을 틀리는 것을 볼 수 있었기에, 동의(Consent) 과정을 생략하는 운영 방식은 취하지 않는 것이 좋겠다는 것이 이번 테스트의 실감입니다.

우선은 운영(Production) DB에 연결하지 말고, 테스트용 DB에서 시도해 본다면 이 기능에 대한 이해도가 높아질 것입니다.

저희 회사는 JetBrains 제품에 관한 질문이나 상담 등을 받고 있습니다. 저희의 X(구 Twitter) 또는 이메일로 연락해 주시기 바랍니다.