고치기 전에 저장부터 하라는 말이 이제 이해된다

잘 돌아가는 걸 건드리는 마음

고치고 싶은 부분이 있어도 지금 되는 것까지 망가질까 봐 망설이게 됩니다. 비개발자에게는 수정한 내용보다 수정한 뒤의 상황이 더 막막할 때가 있어요. 오류가 나면 어디서부터 다시 봐야 할지 모르니까요.

저장과 되돌리기를 다룬 일기를 다시 읽었습니다. 개발자가 수정을 시도할 수 있는 이유를 돌아갈 지점이 있다는 데서 설명한 글이었어요. 예전에는 커밋이라는 말을 개발 도구의 기능 하나로 봤다면, 이번에는 다음 시도를 해볼 여유를 남기는 일로 읽혔습니다.

어디까지 괜찮았는지 남겨두기

앞으로 큰 수정을 부탁할 때는 현재 상태부터 확인하려고 합니다. 무엇이 정상적으로 되는지 보고, 그 코드 상태를 저장한 다음 바꾸는 식으로요. 저장만 해 두고 확인을 안 하면 나중에 돌아갔을 때 무엇이 되는 상태인지 또 헷갈릴 수 있습니다.

다만 코드 기록 하나로 모든 것이 되돌아오는 건 아닙니다. 운영 중인 데이터나 외부 서비스에서 처리된 일은 별도로 봐야 합니다. 그래서 요청할 때도 화면만 고치는지, 저장된 정보까지 바꾸는지 구분할 필요가 있어요. 일기를 읽고 나서 제가 더 확인하고 싶은 부분입니다.

AI가 고쳤다고 하면, 바뀐 이유도 묻기

이어 읽은 글은 AI의 답을 그대로 받는 습관에 관한 내용이었습니다. 설명을 듣고 내가 원한 방향인지 고를 수 있어야 한다는 이야기였어요. 이 글을 저장에 관한 글과 붙여 보니, 수정을 부탁하기 전과 후에 할 일이 이어졌습니다.

바꾸기 전에는 돌아갈 곳을 남기고, 바꾼 뒤에는 무엇이 달라졌는지 묻습니다. 예를 들어 오류를 없앴다고 하면 어떤 조건에서 났던 오류인지, 그 조건을 다시 만들어 확인했는지까지 보고 싶은 거예요. 버튼이 보이는지만 보고 넘어갈 때보다 질문할 내용이 분명해집니다.

설명을 읽어도 이해가 안 되면 화면에서 어떤 동작이 달라지는지 다시 물어보려고 합니다. 코드 전체를 읽을 수 없더라도 제가 부탁한 동작과 다른 답이 나왔다는 건 알아차릴 수 있어야 하니까요.

한 번에 고치는 범위도 줄여보려고 한다

저장과 확인을 제대로 하려면 한 번에 너무 많은 것을 바꾸지 않는 편이 낫겠다는 생각도 들었습니다. 화면도 바꾸고 로그인도 바꾸고 결제까지 고친 뒤 문제가 생기면, 어느 변경부터 봐야 할지 찾는 일부터 해야 합니다.

이번에는 한 부분을 바꾸고 그 부분을 눌러보기. 괜찮으면 다음으로 넘어가기. 두 일기를 묶으면서 가져온 작업 방식입니다. 고치는 속도가 조금 느려져도, 어디까지 확인했는지 아는 상태로 계속 만들고 싶습니다.