여기어때, AI 설계와 규칙 기반 렌더링을 나눈 ERD 도구 제작

ARCH-B

ARCH-B

여기어때 기술블로그 기반 · 2026년 10월 12일 · 5분 분량

0

한눈에 보는 핵심요약

여기어때 광고플랫폼개발팀이 AI에 ERD 전체를 맡기는 대신 설계 대화와 도구의 명명·타입·배치 처리를 분리했다. MCP 편집 경로와 오류 응답도 다듬었다. 내부 실험에서는 호출 실패가 줄었지만 작은 모델의 명명 오류가 남아 검토의 필요성을 보여준다.

  • AI는 설계 대화를 맡고 전용 도구는 팀 규칙에 따른 이름·타입·배치를 처리한다.
  • 편집 도구를 통합하고 원자적 변경·명확한 거절·이전과 현재 값 반환을 적용했다.
  • 내부 여섯 실행에서 실패 호출은 61회에서 3회로 줄었으나 명명 오류는 남았다.
여기어때, AI 설계와 규칙 기반 렌더링을 나눈 ERD 도구 제작
이미지 제공: 여기어때 기술블로그 · 원출처 기사

설계 대화와 반복 가능한 그림 처리를 분리

여기어때 광고플랫폼개발팀은 AI가 설계한 데이터베이스 구조를 일관된 ERD로 표현하기 위해 전용 도구를 만든 사례를 공개했다. 기술블로그는 Mermaid와 HTML로 다이어그램을 만들 때 배치와 관계선, 명명 결과가 요청마다 달라졌다고 설명한다. 팀은 AI가 사용자와 설계 내용을 논의하고, 도구가 이름·타입·테이블 위치와 관계선 경로를 처리하는 구성으로 역할을 나눴다.

대화는 기존 AI 클라이언트에서 진행하고 ERD의 조회와 편집, 정렬·내보내기·되돌리기 기능은 MCP로 제공했다. 도구에 등록한 용어사전과 도메인 규칙이 한글 이름에서 영문 이름과 타입을 정한다. 예를 들어 기술블로그의 판매금액 예시는 sales_amount와 INTEGER로 변환된다. 이는 해당 팀의 규칙이며 모든 서비스의 금액 데이터 타입에 대한 일반 권고는 아니다.

도구가 받아들이는 편집 경로를 좁히다

기술블로그는 제공하는 MCP 도구 13개 중 ERD를 수정하는 도구는 하나로 합쳤다고 밝혔다. 여러 변경을 함께 받되 하나라도 처리하지 못하면 아무것도 바꾸지 않도록 구성했다. 같은 이름의 테이블이 여럿이면 임의로 선택하지 않고 확인을 요구하며, 알지 못하는 요청은 성공으로 넘기지 않는다. 명확한 편집 경로와 입력 검증을 도구에서 담당하게 한 것이다.

MCP 공식 명세는 도구를 모델이 문맥에 따라 발견하고 호출하는 기능으로 설명하며, 각 도구의 이름과 설명, 입력 스키마를 정의한다. 도구를 연결한다고 모델이 항상 원하는 기능을 고르는 것은 아니다. 팀은 도구 설명에 언제 사용하고 피해야 하는지를 넣고, 운영 DB에 반영할 SQL은 변경분을 추출하는 도구를 사용하도록 안내했다고 설명했다.

편집 결과와 실패 뒤의 다음 행동을 함께 반환

팀은 미리보기를 건너뛰는 모델도 자기 결과를 확인할 수 있게 편집 응답에 이전 값과 현재 값, 함께 바뀐 항목을 담았다. 열려 있는 ERD가 없다는 응답만 받은 에이전트가 저장소의 샘플 파일을 찾아 수정한 사례 이후에는, 어떤 파일을 다루고 왜 막혔으며 어떻게 해결할지를 응답에 포함했다. 삭제 복구도 새로 만들기보다 선택한 편집을 되돌리도록 개선했다.

기술블로그는 오류 세 건을 넣은 9개 테이블의 가상 쇼핑몰 ERD에서 쿠폰 설계 요청 10개와 정비 요청 12개를 여러 모델에 맡겨 여섯 번 실행했다고 밝혔다. 개선 전후 전체 도구 호출은 272회에서 153회, 실패 호출은 61회에서 3회로 줄었다. 하지만 Haiku의 컬럼 이름 두 개는 규칙과 달랐다. 이는 제한된 내부 과제의 결과이며 모든 설계가 오류 없이 자동화됐다는 뜻은 아니다.

ARCH.B 분석

결정적인 도구에도 설계 판단은 남는다

ARCH.B의 관점에서 일관된 그림을 얻는 일과 올바른 데이터 모델을 만드는 일은 따로 검토해야 한다. 명명과 타입, 선의 배치를 도구가 같은 규칙으로 처리해도 어떤 테이블을 만들고 관계를 연결할지는 사용자와 AI의 설계 대화에 달려 있다. 같은 설계에서 같은 화면이 나온다는 목표가 업무 요구와 데이터 정합성까지 자동으로 증명해 주지는 않는다.

따라서 검토 화면에는 규칙으로 정해진 표현과 설계상 선택을 구분해 보여줄 필요가 있다. 도구가 부여한 타입과 이름의 근거를 확인하고, 관계를 바꿀 때 생긴 컬럼이나 삭제된 항목도 함께 살피면 사람이 판단할 범위를 좁힐 수 있다. 이때 도구의 성공 응답은 변경 적용을 뜻할 뿐, 실제 운영 데이터에 안전하게 반영할 수 있다는 승인으로 다뤄서는 안 된다.

ARCH.B 분석

실패를 줄이는 응답은 작업 경계를 설명한다

샘플 파일을 잘못 수정한 사례는 오류 메시지가 이후 행동을 바꾼다는 점을 보여준다. 대상이 없다는 설명만으로는 에이전트가 다른 경로를 찾아도 되는지 판단하기 어렵다. 처리할 대상과 필요한 입력, 복구 방법을 알려주면 도구 밖의 우회 행동을 줄일 여지가 있다. 다만 안내 문구만으로 작업 범위가 강제되는 것은 아니므로 실제 접근 권한과 대상 검증은 도구가 책임져야 한다.

내부 실험 결과를 기록할 때는 호출 감소율만큼 남은 오류의 종류도 중요하다. 미리보기를 자주 쓰는 모델은 호출이 많아도 검토를 충실히 했을 수 있고, 적은 호출은 확인을 생략한 결과일 수도 있다. ERD 파일과 작업 요청, 도구 버전, 명명 위반과 복구 결과를 함께 보존하면 다음 개선을 속도와 정확성 중 어떤 기준으로 판단할지 더 분명해진다.

출처

여기어때 기술블로그의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.

시킬 때마다 다른 결과를 내는 AI에게 도구를 쥐여 주었습니다 — AI가 쓰는 ERD 도구 제작기 (새 창)

Share

Related

함께 읽기 좋은 글