오래전에 회사에서 프로덕션 DB에 직접 접속했다가 엄청 혼나던 동료를 본 일이 있습니다.
개발 환경에서 프로덕션 DB에 직접 연결해서 쿼리를 하다가 옆에 있던 선배에게 들킨 겁니다.

주위에 다른 개발자들도 있었는데, 눈물이 쏙 나올 정도로 크게 혼이 나서 아직도 기억이 나네요.

저렇게 혼날 일인가?
저는 다른 선배에게 물어봤습니다.

“사람은 언제든 실수할 수 있으니까 개발 환경에서 프로덕션 DB에 붙을 수 있다는 것 자체가 위험한 일이지.”

물론 위험한 일입니다.
하지만 그게 정말 그렇게 위험하다면 완벽하게 막아야 하는 것 아닌가?
그런데 완벽하게 막을 수는 있나? 터널링해서 연결하는 것까지도?
만약 그걸 완벽하게 막아버린다면 개발과 운영에 불편한 점은 없을까?

저는 어느 정도는 공감하긴 했지만 완전히 납득되지는 않았습니다.

무엇보다 그런 선배들조차 직접 디비에 쿼리를 하는 일들이 있었거든요.
그렇다면 차라리

위험하니까 너희는 프로덕션 DB에 절대 붙지 마, 진짜 필요한 경우에는 내가 붙어서 처리하고 책임질게.

라고 말했다면 완전하게 설득이 되었을 것 같습니다.

프로덕션 DB에 직접 붙는 것은 안정성과 편리함 사이의 트레이드 오프입니다.
이 오래된 고민을 AI 시대에 다시 하고 있습니다. AI에게 프로덕션 서버와 DB 접근 권한을 주면 편리한 점이 너무 많거든요.
프로덕션 서버에 접속해서 로그도 보고, 데이터도 살펴보며 빠르고 정확하게 원인을 파악해 냅니다.
기능 개발 과정에서도 구현 전에 실제 데이터를 한 번 살펴보고 만들라고 하면 더 잘 만들어 내는 경우가 많습니다.

가만, 그런데 이렇게 하다가 DB를 날려버리면 어떡하지?
사람이라면 실수할 텐데, AI도 실수라는 걸 할 수 있지 않을까? 실수하는 것 많이 봤잖아.
프롬프트로 읽기 전용으로 접근하라고 말하는 것만으로 정말 방어가 될까? 기술적으로 좀 더 나은 방법은 없을까?

새로운 시대에 맞춰서 절대 안 된다던 기존의 고정관념은 지워버리고 싶습니다.
백지에서 다시 생각하며 이 트레이드 오프를 조심스럽게 조정해 나가고 있습니다.

✔️

함께 읽으면 좋은 글: