칸을 늘릴 때(마이그레이션)
이미 손님 기록이 들어 있는 장부에 칸을 새로 만들거나 고치는 일이에요. 기록은 그대로 두고 구조만 바꿔야 하는데, 순서를 틀리면 어제까지의 기록이 조용히 사라져요.
쉽게 말하면
가게를 1년 굴려서 예약 장부에 이름·전화번호·날짜 세 칸으로 삼천 줄이 적혀 있어요. 이제 알레르기 칸을 하나 더 만들고 싶어요. 새 장부에 칸 하나 그리는 건 쉽죠. 어려운 건 이미 적힌 삼천 줄이에요. 그 줄들의 알레르기 칸에는 무엇을 적어야 하나요. 마이그레이션은 이 질문에 답을 먼저 정하고 칸을 늘리는 일이에요. 답을 정하지 않고 칸부터 그리면 장부가 작업을 거부하거나, 최악의 경우 그 줄들을 버려요.
그래서 이 작업은 데이터베이스 문서의 다음 단계이면서, 성질이 완전히 달라요. 장부를 읽고 쓰는 일은 아무리 틀려도 되돌릴 수 있어요. 장부의 칸 구조를 바꾸는 일은 되돌릴 수 없는 순간이 중간에 한 번 있어요.
이미 적힌 삼천 줄이 그 순간 규칙을 어기는 상태가 돼요. 반영이 중간에서 멈추거나, 강제로 밀면 그 줄들이 정리 대상이 돼요.
기존 줄은 빈칸으로 그대로 살아 있어요. 새 예약부터 채우고, 옛 줄은 손님에게 물어서 천천히 채우면 돼요.
왜 위험한가
장부에는 서로 다른 두 가지가 함께 살아요. 칸 구조(어떤 칸이 있고 각 칸에 무엇이 들어갈 수 있는지)와 이미 적힌 기록이에요. 개발자는 앞의 것을 스키마라고 불러요.
화면을 고치는 일과 근본이 달라요. 화면은 지워도 다시 그리면 원래대로 돌아와요. 기록은 지우면 돌아올 곳이 없어요. 백업이 없으면 그걸로 끝이에요.
그래서 칸 구조를 바꿀 때 장부는 늘 같은 질문을 해요. "이미 있는 줄들이 이 새 규칙을 지키나요?" 지키지 못하면 장부는 둘 중 하나를 해요. 작업을 거부하거나, 명령대로 정리해요. 무서운 건 두 번째예요.
- 1새 칸을 하나 늘려요. 이때 빈칸 금지가 기본으로 붙는 경우가 많아요. 사람이 붙이지 않아도 도구가 알아서 붙여요.
- 2반영을 누르면 장부가 이미 적힌 줄들을 검사해요. 그 줄들의 새 칸은 전부 비어 있어요. 규칙 위반이에요.
- 3여기서 갈려요. 그냥 멈추면 다행이에요. 도구가 "그럼 이 표를 지우고 새로 만들까요?"라고 묻는 경우가 있는데, 그 물음에 예를 누르는 순간 기록이 사라져요.
- 4화면은 정상으로 보여요. 새 예약도 잘 들어와요. 없어진 건 어제까지의 기록이라 오늘은 아무 에러도 안 나요. 그래서 며칠 뒤에 알게 돼요.
빈칸 허용으로 시작하세요
칸을 새로 만들 때는 빈칸 허용으로 만들고, 값이 다 채워진 뒤에 빈칸 금지로 조여요. 두 걸음이 한 걸음보다 안전해요. 순서를 바꾸면 첫 걸음에서 막히거나, 막히지 않으려고 기록을 버리게 돼요.
무너지는 다섯 가지 모양
| 하려던 일 | 실제로 벌어지는 일 | 알아채는 시점 |
|---|---|---|
| 칸 추가(빈칸 금지) | 이미 있는 줄이 규칙을 어겨 반영이 멈춰요. 강제로 밀면 표를 다시 만들면서 기록을 버려요 | 즉시 막히면 다행, 밀어버리면 며칠 뒤 |
| 칸 이름만 바꾸기 | 도구가 "옛 칸 삭제 더하기 새 칸 생성"으로 해석하는 경우가 있어요. 그러면 그 칸 내용만 통째로 비어요 | 그 칸을 쓰는 화면에서 값이 안 보일 때 |
| 칸 종류 바꾸기(글자를 숫자로) | 숫자로 못 읽히는 값이 한 줄이라도 있으면 거기서 멈추거나 0으로 뭉개져요 | "010-1234" 같은 값이 사라진 뒤 |
| 안 쓰는 칸 지우기 | 정말 안 쓰는지 확인이 어려워요. 정산이나 월간 통계처럼 한 달에 한 번 도는 것이 그 칸을 보고 있어요 | 다음 달 정산이 안 돌 때 |
| 표를 통째로 다시 만들기 | 가장 깨끗해 보이지만 그 표의 기록이 전부 사라져요 | 즉시. 그리고 되돌릴 수 없어요 |
다섯 줄에 공통점이 있어요. 화면은 멀쩡하다는 것이에요. 기록이 사라진 자리에는 빨간 글씨가 안 떠요. 빈칸일 뿐이니까요. 에러 메시지가 알려주는 사고와 성질이 다르고, 그래서 이 작업만은 눈으로 보지 말고 숫자로 확인해요. 작업 전 줄 수와 작업 후 줄 수를 대조하는 것 하나가 나머지 점검을 다 이겨요.
선택지와 대가
방법이 하나가 아니에요. 상황에 따라 정답이 달라지고, 각 방법에는 반드시 대가가 붙어요. 공짜로 안전한 방법은 없어요.
| 방법 | 언제 맞나 | 대가 |
|---|---|---|
| 바로 반영하기 | 손님이 아직 없거나 연습용 기록만 있을 때 | 되돌릴 계획이 없어요. 실수하면 백업이 마지막 줄이에요 |
| 계획서를 파일로 남기는 방식 | 손님 기록이 있는 모든 경우의 기본값 | 준비에 손이 더 가요. 대신 무엇을 언제 바꿨는지가 남고 되돌리는 문장도 함께 남아요 |
| 넓혔다 좁히기(배포 세 번) | 가게 문을 닫지 않고 바꿔야 할 때 | 배포를 세 번 하고 며칠이 걸려요. 그동안 옛 칸과 새 칸이 함께 살아요 |
| 새 표로 옮겨 담기 | 줄이 아주 많은 표의 구조를 바꿀 때 | 가장 오래 걸리고 손이 가장 많이 가요. 대신 원본을 끝까지 건드리지 않아요 |
| 안 쓰는 칸 재활용 | 권하지 않아요 | 공짜처럼 보이지만 "메모 칸에 알레르기가 들어 있는" 장부가 돼요. 1년 뒤엔 아무도 못 읽어요 |
세 번째가 낯설 텐데 원리는 단순해요. 먼저 새 칸을 옆에 만들어 두고, 코드가 두 칸을 다 볼 수 있게 한 다음, 새 칸에 값이 다 찬 뒤에 옛 칸을 치워요. 손님은 중간에 아무 일도 못 느껴요. 진열대를 밤에 통째로 뜯지 않고, 새 진열대를 옆에 세워 물건을 옮긴 뒤 옛것을 빼는 것과 같아요. 게시를 세 번 하는 게 번거로워 보여도, 문을 닫지 않는 값이에요.
기본값을 정하면 절반이 해결돼요
새 칸에 기본값을 정해 두면 이미 적힌 줄도 그 값으로 채워져요. 규칙 위반이 아예 생기지 않아요. 단 기본값이 거짓말이 되지 않게 골라야 해요. 알레르기 칸의 기본값을 "없음"으로 하면 물어보지도 않은 삼천 명이 알레르기가 없다고 기록돼요. "확인 안 됨"이 정직한 기본값이에요.
규모가 커지면 달라지는 것
줄이 몇백 개일 때 이 작업은 눈 깜빡할 사이에 끝나요. 그래서 처음에는 위험이 안 보여요. 문제는 똑같은 명령이 줄 수에 따라 성질이 바뀐다는 거예요.
칸을 새로 만들면서 이미 적힌 모든 줄을 다시 쓰는 종류의 변경이 있어요. 이때 장부는 그 표를 잠가요. 잠긴 동안 손님 요청은 줄을 서서 기다려요. 줄이 적으면 아무도 모르고, 줄이 아주 많으면 그 기다림이 그대로 서비스 정지예요.
정확한 한계 줄 수를 숫자로 못 박을 수는 없어요. 쓰는 장부 종류와 버전, 서버 성능에 따라 다르고, 같은 명령이 어떤 버전에서는 표를 잠그고 어떤 버전에서는 안 잠가요. 대신 사장님이 직접 재는 방법이 있어요.
- 1지금 장부를 복사해서 연습용 장부를 하나 만들어요. 줄 수가 같아야 의미가 있어요. 열 줄짜리 연습은 아무것도 알려주지 않아요.
- 2연습용에 똑같은 변경을 걸고 시간을 재요. 걸린 시간이 곧 예상 정지 시간이에요.
- 3그 시간이 손님이 참을 수 있는 시간보다 길면 방법을 바꿔요. 넓혔다 좁히기나 새 표로 옮겨 담기로요.
- 4잠금이 생기는지 확실하지 않으면, 쓰는 장부 이름과 버전 그리고 걸려는 변경을 그대로 적어 그 장부 공식 문서에서 확인해요. 추측으로 넘기지 않아요.
시간을 재는 것이 유일한 정답이에요
인터넷에 도는 "몇 건까지는 괜찮다"는 숫자는 그 사람 서버 얘기예요. 내 장부의 답은 내 장부를 복사해서 재봐야 나와요. 이 리허설 한 번이 심야 작업 계획 전체를 결정해요.
이럴 때는 하지 마세요
여기가 이 문서의 핵심이에요. 하는 법은 개발자가 알아요. 사장님이 쥐고 있어야 하는 건 오늘 하지 않겠다고 말하는 권한이에요.
- 1손님이 가장 많은 시간대. 잠금이 조금만 생겨도 그 시간엔 전부 대기예요. 예약이 몰리는 시간을 피해요.
- 2백업 시점을 모를 때. "아마 어제 백업 있을 거예요"는 백업이 아니에요. 파일을 열어 본 것만 백업이에요.
- 3되돌리는 문장이 아직 안 적혔을 때. 되돌리는 방법을 말로만 아는 상태면 준비가 안 된 거예요. 글로 적혀 있어야 새벽에 손이 움직여요.
- 4금요일 저녁과 연휴 전날. 사고는 반영 직후가 아니라 몇 시간 뒤에 드러나요. 그때 사람이 없어요.
- 5다른 변경 열 개와 한 배포에 섞여 있을 때. 무엇이 원인인지 못 가려요. 칸을 바꾸는 배포는 그것만 따로 해요.
- 6"이름만 바꾸는 거"라고 믿을 때. 사고가 가장 많이 나는 항목이에요. 이름 바꾸기는 안전한 작업이 아니에요.
멈추는 게 손해가 아니에요
칸 하나 늘리는 일을 하루 미뤄서 잃는 것은 하루예요. 잘못 늘려서 잃는 것은 그 장부의 과거 전부예요. 이 비교는 늘 같은 답을 내요. 사고 대응으로 넘어가기 전에 멈추는 편이 언제나 쌉니다.
남에게 맡길 때
외주나 개발자에게 맡길 때 사장님이 코드를 볼 필요는 없어요. 대신 요구할 것과 확인할 것이 정해져 있어요. 이 표 하나만 들고 있으면 대화가 됩니다.
| 작업 전에 요구할 것 | 작업 후에 확인할 것 |
|---|---|
| 무엇이 지워지고 무엇이 남는지 목록으로 | 줄 수를 전후로 대조. 숫자가 줄었으면 즉시 멈춰요 |
| 되돌리는 방법을 글로 | 새 칸이 채워진 비율. 절반만 찼으면 아직 안 끝난 거예요 |
| 백업 시점과, 그 백업으로 되살려 본 적이 있는지 | 옛 칸이 아직 살아 있는지. 넓혔다 좁히기면 며칠 살아 있어야 정상이에요 |
| 같은 줄 수로 리허설했는지, 걸린 시간은 몇 분인지 | 작업 시각 전후의 에러 기록. 조용한 실패가 여기 남아요 |
| 작업 시각과 예상 정지 시간 | 손님 화면에서 실제로 한 건 만들어 보기. 저장까지 되는지 |
장면 1 · 개발자가 말했다
“칸 하나 추가하는 거라 5분이면 돼요. 지금 바로 반영할게요.”
5분이라는 말은 사실일 수 있어요. 확인할 건 시간이 아니라 세 가지예요. 빈칸 허용인가, 기본값이 무엇인가, 되돌리는 문장이 적혀 있는가. 셋에 바로 답이 나오면 믿을 만한 5분이에요. 하나라도 "해보고 말씀드릴게요"면 오늘은 하지 않아요.
장면 2 · 반영이 중간에서 멈췄다
“기존 데이터가 규칙을 만족하지 않는다고 나와요. 표를 다시 만들지 물어보는데 눌러도 되나요?”
누르지 마세요. 그 물음은 "이 표의 기록을 버리고 깨끗하게 새로 만들까요"라는 뜻인 경우가 많아요. 멈춘 것은 사고가 아니라 안전장치가 작동한 거예요. 여기서 할 일은 새 칸을 빈칸 허용으로 바꾸거나 기본값을 정하는 것이고, 그러면 그 물음 자체가 안 나와요.
장면 3 · 두 주 뒤 월말 정산이 안 돈다
“지난달까지 잘 되던 매출 정리가 오늘부터 빈 화면이에요. 그 사이에 바꾼 건 안 쓰는 칸 하나 지운 것뿐인데요.”
매달 한 번 도는 것은 평소에는 그 칸을 안 쓰는 것처럼 보여요. 그래서 칸을 지우기 전에 물어야 할 질문은 "화면에서 쓰나요"가 아니라 "한 달에 한 번, 1년에 한 번 도는 것까지 포함해서 쓰나요"예요. 안 쓰는 칸은 지우는 대신 몇 달 그냥 두는 편이 싸요.
자주 묻는 것
- Q. 화면 문구나 색을 고치는 것도 마이그레이션인가요?
- 아니에요. 문구·색·배치는 진열대라서 잘못돼도 되돌리기로 돌아와요. 이 문서가 말하는 위험은 손님 기록이 사는 장부의 칸을 건드릴 때만 생겨요.
- Q. 손님이 아직 한 명도 없어요. 그래도 조심해야 하나요?
- 훨씬 편하게 해도 돼요. 잃을 기록이 없으니까요. 오히려 지금이 구조를 크게 바꿔 볼 유일한 시기예요. 첫 손님이 들어온 날부터 규칙이 달라진다는 것만 기억하세요.
- Q. 칸 이름이 마음에 안 들어요. 바꾸면 안 되나요?
- 바꿀 수 있는데 순서가 있어요. 새 이름 칸을 만들고, 값을 옮기고, 코드를 새 이름으로 바꾸고, 며칠 지켜본 뒤 옛 칸을 지워요. 한 번에 이름만 바꾸는 명령은 도구에 따라 삭제로 해석될 수 있어요.
- Q. 백업만 있으면 아무렇게나 해도 되나요?
- 백업은 마지막 줄이지 첫 줄이 아니에요. 되살리는 데 시간이 걸리고, 되살리면 사고 이후에 들어온 주문과 예약은 사라져요. 백업으로 돌아가는 순간 그 사이의 기록은 없던 일이 돼요.
- Q. 자동으로 반영해 주는 도구를 쓰면 안전한가요?
- 편한 것과 안전한 것은 다른 얘기예요. 도구는 사장님이 무엇을 잃어도 되는지 몰라요. 편한 도구일수록 "그럼 다시 만들까요"를 쉽게 물어봐요. 그 물음에 답하는 건 여전히 사람이에요.
- Q. 옛 칸은 언제 지우면 되나요?
- 새 칸만으로 서비스가 도는 것을 며칠 지켜본 뒤예요. 급하게 지워서 얻는 것은 용량 조금이고, 잘못 지워서 잃는 것은 기록이에요. 비교가 안 돼요.
확인해 보세요
예약 삼천 건이 있는 장부에 "알레르기" 칸을 새로 만들려고 해요. 가장 안전한 첫 걸음은?
하나 더
반영 중에 "기존 데이터가 규칙을 만족하지 않습니다"가 뜨고, 도구가 표를 다시 만들지 물어봐요.
직접 해보기
백업 시점을 지금 확인해 두세요
칸을 건드리기 전에 할 일은 하나예요. 가장 최근 백업이 언제인지 눈으로 확인하는 것. 연결 센터에서 내 데이터베이스 연결을 열어 보고, 백업 설정이 어디에 있는지 위치만 찾아 두세요. 오늘 아무것도 바꾸지 않아도 이건 해 둘 값이 있어요.
연결 센터 열기직접 해보기
요청문을 이렇게 적어 보세요
칸을 늘려 달라고 부탁할 때 이 세 줄을 같이 적으면 사고 대부분이 사라져요. "새 칸은 빈칸 허용으로 만들어 주세요. 기본값은 이 값으로요. 기존 기록은 지우지 말고 그대로 두세요." 짧지만 이 세 줄이 이 문서의 절반이에요.
스튜디오에서 적어 보기더 깊이 (안 읽어도 괜찮아요)
스키마라는 말 · 개발자가 스키마라고 부르는 건 장부의 칸 구조 설계도예요. 어떤 표가 있고, 표마다 어떤 칸이 있고, 각 칸에 무엇이 들어갈 수 있는지 적은 종이예요. 마이그레이션은 이 설계도를 고치는 일이고, 어려운 이유는 설계도만 고칠 수 없기 때문이에요. 이미 그 설계도대로 지어진 기록이 있으니까요.
빈칸과 0과 빈 글자는 다른 것이에요 · 사람 눈에는 다 비어 보이지만 장부에서는 셋이 다른 값이에요. 빈칸은 "모른다", 0은 "0이다", 빈 글자는 "적었는데 내용이 없다"예요. 매출 칸이 빈칸인 날과 0원인 날은 뜻이 완전히 달라요. 새 칸의 기본값을 정할 때 이 차이를 먼저 정해야 해요.
왜 계획서를 파일로 남기나 · 손으로 칸을 고치면 기록이 안 남아요. 그래서 현장에서는 변경 하나하나를 파일로 남기는 방식을 써요. 언제 무엇을 바꿨는지 순서대로 쌓이고, 새 서버를 세울 때 그 파일들을 처음부터 다시 돌려 같은 장부를 만들 수 있어요. 되돌리는 문장도 같은 파일에 함께 적어요.
칸을 늘리는 것보다 무서운 것 · 칸 추가는 그래도 되돌릴 여지가 있어요. 진짜 어려운 건 한 칸에 있던 것을 여러 칸으로 쪼개거나, 여러 칸을 한 칸으로 합치는 일이에요. 기록의 뜻 자체를 바꾸는 작업이라 되돌리는 문장을 쓰기가 어려워요. 이 경우는 새 표로 옮겨 담는 방법만 씁니다.
코드와 장부는 같은 시각에 안 바뀌어요 · 반영은 순간이 아니라 짧은 구간이에요. 그 구간 동안 코드와 장부가 서로 다른 세대일 수 있어요. 코드가 먼저 새 칸을 찾으면 없는 칸을 찾다 에러가 나고, 장부가 먼저 옛 칸을 지우면 아직 도는 옛 코드가 죽어요. 그래서 순서 규칙은 하나예요. 더하는 변경은 장부 먼저, 지우는 변경은 코드 먼저.
이것만 기억하세요
- ·칸 구조와 이미 적힌 기록은 따로 살아요. 위험은 늘 그 사이에서 나와요
- ·새 칸은 빈칸 허용과 정직한 기본값으로 시작해요. 조이는 건 나중이에요
- ·반영이 멈추는 건 사고가 아니라 안전장치예요. "다시 만들까요"에 예를 누르지 않아요
- ·줄이 많아지면 같은 명령이 서비스 정지가 돼요. 복사한 장부로 시간을 재보세요
- ·맡길 때는 되돌리는 문장·백업 시점·전후 줄 수를 요구하고 확인해요