호환이 깨지는 변경

쉽게 말하면

그래서 증상이 늘 비슷해요. 어제까지 되던 화면 몇 개가 오늘 한꺼번에 안 돼요. 손님 신고는 "사이트가 이상해요" 한 줄로 들어와요.

사장님이 잘못 누른 것도, 손님 인터넷이 느린 것도 아니에요. 무엇이 언제 바뀌었는지 찾는 일이 수리의 절반이에요.

이 변경은 어디서 날아오나

사장님 코드를 아무도 안 건드려도 서비스는 멈출 수 있어요. 규격을 바꾸는 쪽이 대부분 가게 밖이에요.

표기 한 줄로 미리 읽는 위험

다행히 대부분의 부품은 미리 알려 줘요. 번호 앞자리가 그 신호예요. 번호를 읽는 법은 버전 번호 규칙 편에 있고, 여기서는 설정 파일에 적힌 받는 범위 표기를 봐요. 이 한 줄이 앞자리가 예고 없이 들어올지 말지를 정해요.

받기 전에 하는 판정 순서

새 판을 받는 결정은 감이 아니라 순서로 해요. 이 순서는 부품에도, AI 모델에도, 외부 창구에도 그대로 써요.

1. 1왜 올리는지 한 줄로 적어요. 보안 수정, 꼭 필요한 새 기능, 지원 종료 예고 셋 중 무엇인지. 셋 다 아니면 오늘은 안 올리는 게 정답인 날도 있어요.
2. 2올리려는 판의 변경 기록을 열어요. 제거 · 이름 변경 · 더 이상 지원하지 않음 이 세 낱말만 찾아요. 변경 기록
3. 3그 이름을 내 서비스가 실제로 쓰는지 찾아요. 안 쓰면 앞자리가 올라가도 나에게는 아무 일도 없어요. 이 단계가 판정의 심장이에요.
4. 4손님이 안 보는 연습 무대에서 먼저 올려 봐요. 실제 가게에서 처음 열어 보는 것과 여기서 열어 보는 것의 차이가 사고의 대부분이에요. 연습 무대
5. 5돈이 오가는 화면, 로그인 화면, 저장되는 화면 셋을 손으로 눌러 봐요. 자동 점검이 있으면 같이 돌려요. 화면 눌러 보는 점검
6. 6되돌릴 방법을 확인한 뒤 실제로 올려요. 되돌리기 계획이 없으면 오늘은 올리지 않아요. 되돌리기

내가 깨는 쪽일 때

서비스가 커지면 방향이 바뀌어요. 손님 앱, 연동 업체, 손님이 만든 자동화가 내 규격을 보고 만들어져 있어요. 이때부터 규격을 바꾸는 일은 남의 가게를 멈추는 일이에요.

이미 멈춘 뒤 순서

원인을 찾기 전에 손님이 쓰던 상태로 되돌리는 것이 먼저예요. 조사는 되돌린 다음에 해요. 이 순서를 바꾸면 손님이 멈춘 시간만 길어져요.

1. 1직전 판으로 되돌려요. 원인 파악보다 먼저예요. 되돌리기
2. 2되돌려서 정상이 되면 원인은 이번 변경 안에 있어요. 되돌려도 안 되면 원인은 밖에 있어요. 이 갈림길 하나로 조사 범위가 절반으로 줄어요.
3. 3오늘 무엇이 바뀌었는지 목록을 뽑아요. 내 코드 변경, 부품 판 변경, 외부에서 온 공지 세 갈래를 각각 봐요.
4. 4오류 문장 첫 줄을 그대로 붙여서 물어봐요. 호환 문제는 "없는 함수", "필수 값 누락", "지원하지 않는" 같은 말로 나와요. 오류 문장 읽기
5. 5고친 뒤에는 같은 사고가 다시 나는지 확인하는 점검 한 줄을 남겨요. 이걸 안 남기면 몇 달 뒤 같은 자리에서 또 멈춰요. 고쳤던 게 또 고장 남

버그와 뭐가 달라요

이름이 비슷한 세 가지가 있어요. 대처가 완전히 달라서 구분해 두는 것이 값어치가 있어요.

세 번째는 지원 종료 예고예요. 아직 동작하지만 언제 끊긴다고 미리 알려 준 상태죠. 예고 기간이 사장님에게 주어진 유일한 여유이고, 그 기간 안에 옮기면 멈추는 날이 아예 없어요.

자주 묻는 것

Q. 그럼 업데이트를 아예 안 하면 안전한가요?

반대예요. 안 올리면 보안 수정도 안 들어오고, 나중에 한꺼번에 올릴 때 앞자리 여러 개를 한 번에 넘어야 해요. 그게 가장 비싼 방식이에요. 안전한 습관은 작게 자주, 연습 무대를 거쳐서예요.

Q. 앞자리가 올라갔다는데 제 서비스는 아무 일도 없었어요.

정상이에요. 앞자리 올림은 "누군가는 깨진다"는 신고이지, "모두가 깨진다"는 뜻이 아니에요. 사라진 기능을 내가 안 쓰면 나에게는 해당되지 않아요. 그래서 판정 순서 3번이 가장 중요해요.

Q. 바이브캠퍼스로 만들면 이걸 제가 직접 챙겨야 하나요?

만드는 동안은 대화로 요청하면 필요한 수정을 같이 해요. 이 문서가 진짜 필요해지는 순간은 문을 연 뒤예요. 외부 창구를 붙였거나, 앱을 스토어에 올렸거나, 다른 업체가 내 규격을 보고 만들었을 때. 그때부터는 밖에서 오는 예고를 읽는 사람이 필요해요.

Q. 외부 창구를 쓰는 쪽인데, 상대가 바꾸는 걸 미리 알 방법이 있나요?

대부분의 창구는 판 번호를 주소 안에 넣어 두고, 옛 판을 언제 닫는지 공지해요. 계약서나 연동 문서에 그 공지를 어디로 보내는지 적혀 있어요. 받을 메일을 개인 이름이 아니라 대표 주소로 등록해 두는 것이 실무에서 가장 큰 차이를 만들어요. 담당자가 바뀌면 공지가 사라지니까요.

Q. 손님 앱은 제가 되돌릴 수 없는데요.

맞아요. 손님 폰에 깔린 앱은 깔린 그날의 판이에요. 그래서 앱이 걸린 서비스는 서버 쪽을 옛 앱도 받아 주는 모양으로 유지하는 것이 원칙이에요. 정말 못 받아 줄 때만 업데이트 안내로 끊어요. 앱 강제 업데이트

Q. 옛 방식을 계속 같이 유지하면 짐이 쌓이지 않나요?

쌓여요. 그 짐이 기술 부채예요. 그래서 "옛 방식은 언제까지"를 처음부터 적어 두고, 그 날짜가 오면 실제로 없애는 것까지가 한 세트예요. 겹치는 기간을 두는 것과 영원히 두는 것은 전혀 다른 이야기예요.