AI가 자꾸 다른 델 건드릴 때
분명 한 군데만 고쳐달라고 했는데, 멀쩡하던 다른 기능이 망가져 있습니다.
AI랑 일하면서 제일 자주, 제일 답답했던 문제예요.
"여기만 고쳐"라고 했는데
예를 들어 "버튼 색만 바꿔줘"라고 합니다. 그러면 색은 바뀌는데, 어쩐 일인지 옆에 있던 기능이 안 되는 거예요. 건드리지도 않은 곳이요.
처음엔 이게 너무 황당했어요. "나는 색만 바꾸라고 했는데 왜 저게 망가져?" 코딩을 모르니 이유도 모르겠고, 그냥 답답하기만 했죠.
알고 보니 코드는 여기저기 연결되어 있어서, 한 곳을 건드리면 다른 곳에 영향이 갈 수 있대요. AI가 고치는 과정에서 의도치 않게 다른 부분을 건드리는 거죠.
대처법을 찾았다
이 문제는 몇 가지 방법으로 줄였어요.
첫째, 고치기 전에 범위를 못 박았습니다. "다른 건 절대 건드리지 말고 이것만 고쳐"라고 분명히 말해요. 그러면 확실히 사고가 줄어요.
둘째, 고친 다음에 다른 기능도 확인했어요. 색만 바꿨어도 옆 버튼, 계산 기능까지 한 번씩 눌러봐요. 망가진 게 있으면 바로 알 수 있으니까요.
셋째, 한 번에 하나씩만 고쳤어요. 역시 이 규칙이 답이었어요. 여러 개를 동시에 안 건드리니, 뭔가 망가져도 방금 그것 때문인 걸 바로 알죠.
백업의 소중함을 또 느꼈다
그래도 가끔은 망가집니다. 그때를 대비해 작업한 걸 저장해두는 게 정말 중요해요.
뭔가 크게 망가졌을 때 "아까 잘 되던 상태로 돌아가자"가 가능하려면, 그 상태가 어딘가 저장돼 있어야 하잖아요. 이 백업 이야기는 다음 글에서 제대로 다룰 만큼 중요해요. 한 번 크게 데인 적이 있거든요.
매번 겪는 딜레마
AI한테 "이것만 고쳐줘"라고 해도 가끔 다른 부분까지 손을 댑니다. 나쁜 의도는 아니에요. AI 입장에서는 더 낫게 만들려고 하는 거지만, 저는 이미 완성해둔 다른 부분이 흔들리는 게 제일 무섭습니다.
그래서 요즘은 요청할 때 파일 이름과 줄까지 최대한 구체적으로 짚어줍니다. "이 파일의 이 함수, 이 줄만 고쳐줘. 다른 파일은 절대 건드리지 마." 이렇게 범위를 좁혀서 말하면 사고가 확실히 줄어들었어요.
비개발자일수록 이 범위 지정이 더 중요하다고 느낍니다. 뭐가 잘못됐는지 코드를 보고 바로 알아챌 수 없으니까, 애초에 사고가 날 여지를 줄이는 게 최선이더라고요.
범위를 좁히는 구체적인 방법
요즘은 요청할 때 이렇게 말합니다. "이 화면의 이 버튼, 색상만 바꿔줘. 크기나 위치는 그대로 둬." 이렇게 바꿀 것과 안 바꿀 것을 같이 말해주면 훨씬 정확하게 반영됩니다.
처음엔 이렇게까지 구체적으로 말해야 하나 싶었어요. 그런데 몇 번 사고를 겪고 나니 이게 시간을 훨씬 아껴준다는 걸 알았습니다. 애매하게 말하고 나중에 고치는 것보다, 처음부터 정확히 말하는 게 결국 더 빠릅니다.
AI와 일하는 것도 결국 사람과 일하는 것과 비슷한 원칙이 적용되는 것 같아요. 명확할수록 서로 편해집니다.
범위를 좁혀서 말하는 습관은 코딩 밖에서도 쓸모가 있더라고요. 회사에서 협업업체에 일을 맡길 때도 비슷한 원칙이 적용됩니다. 애매하게 맡기면 애매한 결과가 오고, 명확하게 범위를 정해주면 훨씬 정확한 결과가 옵니다. AI와 일하면서 이 원칙을 다시 배웠습니다.
이 원칙을 세운 뒤로는 AI와의 작업이 훨씬 예측 가능해졌습니다. 뭘 요청하면 어디까지 바뀔지 대략 짐작이 가니까, 마음의 준비도 되고 결과에 놀랄 일도 줄었어요. 예측 가능하다는 게 이렇게 중요한 건지 예전엔 몰랐습니다.
"한 군데만 고치는 것도 안 돼?"
1. 범위를 분명히 못 박으세요. "다른 건 건드리지 말고 이것만"이라고 정확히 말하면 사고가 줄어요. AI는 시키는 만큼만 하니까요.
2. 고친 뒤 다른 기능도 확인하세요. 한 곳을 고쳐도 다른 데가 망가질 수 있어요. 고친 다음 주변 기능까지 한 번씩 눌러보세요.
3. 한 번에 하나씩이 답입니다. 동시에 여러 개를 건드리면 원인 찾기가 불가능해요. 하나씩 가야 사고를 막습니다.
다음 이야기
이렇게 망가지는 일을 겪으면서 뼈저리게 배운 게 백업이에요. 다음 글에서는 작업한 걸 안전하게 저장하는 법, 그리고 제가 안 해서 크게 당한 이야기를 하겠습니다.
