MySQL Workbench의 Synchronize Model 기능에 오류가 생길 때

열심히 썰타임 리뉴얼을 하다가 DB 스키마에 수정을 할 필요가 생겼다. DB 스키마 수정이야 썰타임을 만들기 시작한 때부터 줄창 해오던 것이라 어떤 문제가 발생할 것이라고는 전혀 생각하지도 않고 하던 대로 MySQL 워크벤치를 켜서 모델을 불러오고 원하는 수정을 마친 뒤 Synchronize Model을 실행했다.

그런데 이게 무슨 일인가. 내 워크벤치 프로그램이 실서버 DB에 있는 테이블 하나가 아예 없으니 모델에 있는 테이블을 실서버 DB에 반영하겠다는 것이 아닌가. 또 이렇게 테이블이 하나 날아갔구나 하는 생각을 하며 당황하지 않고 실서버로 뛰어갔는데, 아니 이게 또 무슨 일인가. 워크벤치에서 없다고 나오던 그 테이블은 말짱히 존재하고 있었다. 워크벤치에서 서버에 접속을 해 DB를 확인해보니 심지어 워크벤치 자체 내에서도 존재를 하고 있었다.

그렇다면 대체 문제가 뭐라는 거야...

몇 번 케이스 스터디를 해본 결과, 문제는 워크벤치의 Synchronize Model 기능에서만 소스에 있는 특정 테이블을 인식하지 못하는 것에 있었다. 도무지 이유를 알 수 없어 관련 검색어로 구글링을 해보았으나 마땅히 답이 나오는 것이 없었다. 그저 워크벤치 상의 어떤 결함이라는 이야기들을 할 뿐 그 누구도 뚜렷한 답을 주지 않았다.

그렇게 해야 할 작업은 못하고 문제는 해결도 못한 채 징징거리고 있던 와중에 마음에 의심이 가는 부분이 하나 생겼다. 그리고 혹시나 하는 마음에 그 문제를 해결해봤더니 다시 워크벤치가 나의 테이블들을 잘 인식하게 되었다. 과연 그 문제는 뭐였을까?

굳이 따지자면 잘못은 내 쪽에 있었다. 갑자기 인식하지 못하던 테이블이 갖는 하나의 특성은 테이블 내부의 특정 칼럼에 큰따옴표가 포함된 코멘트가 달려 있다는 것이었다. 혹시나 워크벤치와 실서버 사이에서 인코딩, 디코딩의 문제나 이스케이프의 문제 따위가 발생해서 해당 정보가 제대로 인식되지 않으면, 그렇다면 어쩌면 워크벤치에서도 실서버의 테이블을 제대로 읽어오지 못하는 것이 아닌가 하는 생각을 하게 된 것이다.

그리고 결론은 나의 예상이 옳았단 것이다. 해당 칼럼의 코멘트를 싹싹 삭제하고 Synchronize Model을 다시 돌리니 모든 것이 문제없이 돌아갔다. 시간도 적잖이 날렸고 마음 고생도 적잖이 했지만 그래도 이 정도면 꽤나 훌륭한 꿀팁이라 할 수 있겠다.

부디 누군가에는 빛과 소금이 되는 포스팅이길 바란다.