버그
만든 대로 안 움직이는 것이에요. 고장(버그)과 기능 미비(원래 없는 것)를 구분해야 고쳐 달라는 요청이 정확해져요.
쉽게 말하면
메뉴판에는 3,000원인데 계산대에서 4,000원이 찍히는 것, 이게 버그예요. 정해 둔 규칙이 있는데 실제 움직임이 그 규칙과 다른 상태예요. 반대로 손님이 "디카페인은 없나요?"라고 묻는 건 버그가 아니에요. 메뉴판에 애초에 없던 것이니까요. 그건 고장이 아니라 메뉴 추가 요청이에요.
버그는 만들 때 정한 대로 서비스가 움직이지 않는 상태를 부르는 말이에요. 컴퓨터가 멋대로 구는 게 아니라, 코드 어딘가에 사람(또는 AI)이 남긴 실수가 있어서 그래요. 그래서 원인을 찾으면 반드시 고칠 수 있어요.
이 구분이 왜 중요하냐면, 요청하는 말이 완전히 달라지기 때문이에요. 버그는 "원래 이래야 하는데 지금 이래요"라고 말하고, 기능 미비는 "이런 걸 새로 넣어 주세요"라고 말해요. 이 둘을 섞어 말하면 AI도 개발자도 엉뚱한 곳을 고쳐요.
고장인지, 원래 없는 기능인지, 무엇이 어떻게 이상한지 아무것도 안 담겨 있어요. 받은 쪽은 추측으로 고치기 시작해요.
원래 이래야 한다(기준)와 지금 이렇다(증상)가 다 있어요. 이런 요청은 한 번에 고쳐질 확률이 훨씬 높아요.
버그인지 아닌지 가르는 법
"안 돼요"라고 느끼는 상황이 전부 버그는 아니에요. 크게 세 갈래로 나뉘고, 갈래마다 대처가 달라요. 아래 표에 내 상황을 대 보세요.
| 갈래 | 이런 상황이에요 | 무엇을 해야 하나 |
|---|---|---|
| 버그(고장) | 예전엔 됐거나, 되기로 한 것이 지금 다르게 움직여요. 계산이 틀리거나, 버튼이 엉뚱한 화면으로 가요 | 증상과 기준을 적어서 고쳐 달라고 해요. 이 문서의 다음 절이 그 방법이에요 |
| 기능 미비 | 고장이 아니라 애초에 그 기능을 만든 적이 없어요. 취소 알림, 엑셀 내려받기 같은 것 | "새로 만들어 주세요"라고 요청해요. 고쳐 달라고 하면 대화가 헛돌아요 |
| 환경 문제 | 내 폰에서만, 인터넷이 느릴 때만, 특정 시간에만 이상해요. 코드가 아니라 주변 조건이 원인일 수 있어요 | 다른 기기나 다른 인터넷에서 한 번 더 해봐요. 거기서도 나면 버그로 넘겨요 |
"원래 어때야 하는가"를 먼저 정해요
버그 판정의 기준은 언제나 원래 정한 규칙이에요. 그런데 규칙을 정한 적이 없는 부분이면 고장이라고 말할 근거도 없어요. "품절 상품은 주문이 막혀야 한다"처럼 기준을 한 줄로 적어 보고, 그 기준과 실제가 다를 때만 버그라고 부르세요.
확인해 보세요
손님이 "포인트로 결제하는 기능이 안 돼요"라고 했어요. 내 서비스에 포인트 결제를 만든 적이 없어요. 이건?
버그를 발견하면 이렇게 적어요
버그를 고치는 쪽(AI든 개발자든)에게 필요한 정보는 정해져 있어요. 아래 네 줄만 적으면 대부분의 버그는 대화 한두 번에 잡혀요.
- 1어디서: 어느 화면, 어느 버튼인지 적어요. "예약 화면의 취소 버튼"처럼요.
- 2무엇을 했더니: 내가 한 동작을 순서대로 적어요. 이 순서를 자세히 적는 법은 따로 있어요. 재현 절차 쓰기에서 다뤄요.
- 3어떻게 됐나: 실제로 일어난 일을 적어요. 화면에 에러 문구가 떴다면 그 문구를 그대로 옮겨 적어요. 문구 읽는 법은 에러 읽는 법에 있어요.
- 4원래는 어때야 하나: 기대한 결과를 적어요. 이 줄이 있어야 받은 쪽이 무엇이 틀렸는지 알아요.
가게 사장님이 말했다
“"결제가 안 돼요"라고만 보냈더니 AI가 결제 화면을 통째로 다시 만들었어요. 실제 문제는 쿠폰을 쓸 때만 금액이 틀리는 거였는데요.”
증상을 뭉뚱그리면 고치는 쪽은 범위를 크게 잡고 멀쩡한 곳까지 손대요. 그러면 다른 곳이 새로 깨지는 일도 같이 생겨요. "쿠폰을 적용했을 때만, 합계가 쿠폰 금액만큼 안 빠져요"처럼 좁혀 말하는 것이 가장 빠른 길이에요.
자주 묻는 것
- Q. 버그가 나오면 잘못 만든 건가요?
- 아니에요. 세상의 모든 소프트웨어에 버그가 있어요. 큰 회사의 서비스도 매주 버그를 고쳐서 내보내요. 잘 만든 서비스와 그렇지 않은 서비스의 차이는 버그가 없는 게 아니라, 빨리 발견하고 빨리 고치는 체계가 있느냐예요.
- Q. AI가 만든 코드에도 버그가 있나요?
- 있어요. AI는 사람보다 오타는 적지만, 요청을 다르게 이해해서 생기는 버그는 똑같이 만들어요. 그래서 만들어 달라고 한 뒤에는 직접 눌러 보며 확인하는 습관이 필요해요. 확인 요령은 고치고 나서 확인하기에 있어요.
- Q. 작은 버그는 그냥 둬도 되나요?
- 화면 글자가 살짝 어긋나는 정도면 미뤄도 돼요. 하지만 돈, 예약, 손님 정보에 닿는 버그는 작아 보여도 바로 고쳐야 해요. 계산이 100원 틀리는 버그는 손님 수만큼 곱해져서 돌아와요.
- Q. 어제는 됐는데 오늘 안 돼요. 이것도 버그인가요?
- 버그일 가능성이 높아요. 그리고 이 경우엔 단서가 하나 더 있어요. 어제와 오늘 사이에 무엇을 바꿨는지예요. 그 사이에 고치거나 추가한 것이 있다면 범인은 거의 거기에 있어요. 바꾼 내용을 함께 말하면 훨씬 빨리 잡혀요.
- Q. 버그인지 내 실수인지 모르겠어요
- 괜찮아요. 판정은 요청받은 쪽의 몫이에요. 사장님은 위의 네 줄(어디서, 무엇을, 어떻게 됐나, 원래는)만 적어서 넘기면 돼요. 내 실수로 밝혀져도 잃는 것은 없고, 그 과정에서 서비스를 더 알게 돼요.
하나 더
"어제는 됐는데 오늘 예약 확인 문자가 안 가요"라는 버그를 신고하려 해요. 함께 적으면 가장 도움이 되는 정보는?
직접 해보기
네 줄 신고를 직접 해보세요
지금 만들고 있는 프로젝트에서 이상하게 움직이는 곳을 하나 골라, 스튜디오 채팅에 어디서, 무엇을 했더니, 어떻게 됐나, 원래는 어때야 하나 네 줄로 적어 보세요. 뭉뚱그려 말할 때와 결과가 어떻게 다른지 바로 느껴질 거예요.
스튜디오 열기이것만 기억하세요
- ·버그는 만들 때 정한 대로 안 움직이는 상태예요. 원인이 있고, 찾으면 고쳐져요
- ·만든 적 없는 기능이 없는 건 버그가 아니라 기능 요청이에요. 요청하는 말이 달라요
- ·신고는 네 줄이에요. 어디서, 무엇을 했더니, 어떻게 됐나, 원래는 어때야 하나
- ·되던 것이 안 되면 그 사이에 바꾼 것을 먼저 의심해요
- ·돈과 손님 정보에 닿는 버그는 작아 보여도 바로 고쳐요