이젠 없으면 안 될
도대체 GPT 이전의 시대에는 어떻게 정보를 찾았을까 싶을 정도로 이제는 삶에 깊숙히 침투한 GPT를 필두로한 다양한 인공지능 챗봇들. 현재는 다양한 산업에서 다양한 챗봇들이 사용되고 있다는 소식을 쉽게 접할 수 있습니다.
저도 몇년 전까지만 해도 개발을 한다 또는 개발 블로그에 글을 투고한다 하면 한 쪽에는 Google을 띄워 놓고 참조 자료들을 찾아가며 작성을 했었습니다.
그런데 요즘은 한 쪽에 GPT, 다른 한 쪽에 Google을 띄워 놓는 것이 하나의 정석 포지션으로 자리잡게 되었습니다.
예전에는 여러 사이트에서 추합한 자료들을 정리해서 블로그에 작성했었는데 GPT의 등장 이후로는 GPT에 질문을 슥 던져 넣으면 깔끔하게 답변을 정리해서 주다보니 엄청난 시간 단축도 되고 학습에 사용하기도 용이하다고 느꼈습니다.
GPT는 모든 것을 알지 못한다
너무나도 편리했기에 저도 모르는 사이에 GPT에게 많은 일을 떠맡기고 있었고 아무생각없이 GPT의 의견을 수긍하게 되었습니다.
그리고 몇 가지 문제들을 직면하고 나니 한 가지 의문을 스스로에게 던져보게 되었습니다.
"그동안 GPT를 과도하게 믿고 있었던 것은 아닐까?"
GPT 맹신의 함정
어느날 작은 모듈을 개발하고 있었는데 에러가 발생했습니다. 처음 사용해보는 라이브러리를 사용하던 중에 발생한 에러였기에 바로 원인을 찾아서 고쳐낼 수는 없던 쉽지 않은 오류였습니다.
부끄러운 과거지만 저는 에러에 시간을 많이 소비하지 않고 빠르게 개발을 완료하고 싶다는 마음에 에러 메세지로부터 발생 위치와 발생 에러를 찾아서 GPT에 바로 질문을 던져버리는 선택을 하고 말았습니다.
그런데 이 오류가 좀처럼 쉽게 해결되지 않았습니다.
왜냐하면 GPT가 A 답변을 내놓으면 B 오류가 발생하고 B 오류에 대한 답변으로 코드를 수정하면 다시 A 오류가 발생하면서 무한루프에 빠진 것 처럼 같은 오류를 계속 마주해야했습니다.
이렇게 GPT의 답변만으로는 해결할 수 없었던 일이 발생한 것이었습니다.
무한루프에 빠져 도저히 해결이 되지 않자 예전처럼 Google에도 쳐보고, 프로젝트 내의 모든 관련 코드들을 살펴보면서 에러 원인을 찾기 시작했습니다.
이 경험은 이 블로그를 작성하게 된 계기가 되기도 했으며 그동안 GPT를 무지성으로 사용하는 모습을 반성하게 되는 계기가 되기도 했습니다.
GPT도 상당히 자주 틀린다
GPT가 학습 데이터 기반으로 대부분은 맞는 정보를 답변해주지만 틀리는 경우도 상당히 많습니다.
특히 설정이나 환경이 자주 바뀌는 Frontend 계열의 라이브러리 등에 대한 답변을 할 때 안정적으로 판단된 최신 사양 대신 구버전의 사양을 알려주는 경우가 상당히 많았던 것을 직접 경해봤습니다.
즉, 출시 등이 오래전 시점이라 많은 문헌이 발생한 부분에 대해서는 정확도가 올라가지만 최신 정보를 요구할 수록 정보가 부정확해지는 문제가 발생하는 것이었습니다.
애초에 GPT 설명서에 답변이 틀릴수도 있다라고 명시하고 있습니다.
GPT를 곁에 두기 위한 규칙들
이런 경험들을 겪고 자기 반성을 해보고나서 저는 GPT에 종속적인 사람이 아닌 GPT를 도구로써 잘 사용하는 사람이 되기위해 스스로 몇 가지 규칙을 세우게 되었습니다.
1. 10분 룰을 지키자
이해가 잘 가지 않는 문제 상황, 에러 발생 등의 상황이 발생하면 최소한 10분은 스스로 생각, 해결하려는 노력을 해보고 GPT에 물어보자라는 것이 10분 룰입니다.
이해가 잘 가지 않는 문제 상황이라면 최대한 이해를 해보려고 하는 시간을 10분 가집니다. 그 이후에도 아예 감을 잡지 못했다면 GPT에게 도움을 요청합니다. 만약 10분 고민해보고 일부분이라도 해결이되었다고 한다면 조금 더 생각을 해봅니다.
에러 발생같은 경우는 이전에 해왔던대로 구글링, 중단점 디버그 모드, 코드 전수 검사 등을 10분 동안 해봅니다. 이 과정에서 어느정도 실마리가 잡히면 스스로 조금 더 고민해보고 그렇지 못하면 GPT에게 도움을 요청합니다.
10분이라는 시간을 규정한 이유는 대부분의 상황에서 약 10분을 깊게 고민해보면 실마리가 잡히는 경우가 많았기 때문입니다.
보통10분을 고민해봤는데 실마리조차 못잡았다는 것은 "모르는 것"에 가깝기 때문에 이 이상 시간을 소모하는 것은 효율이 좋지 못하다고 생각하게 되었습니다.
2. 교차 검증을 하자
잘 몰랐던 것을 GPT를 통해 답을 얻어낸 다음에는 확실한 문서를 통해 교차 검증을 해보자라는 교차 검증 규칙입니다.
예를들어 스프링 프레임워크를 처음 배운다고 치면, GPT에 검색을 해본 후 그 결과를 Spring 프레임워크 공식 문서에 들어가서 한 번 교차 검증을 해보는 것입니다.
교차 검증을 수행하는 이유는 GPT가 공식 문서를 기반으로 답변을 해주더라도 내 질문으로 인해 문맥 추론 과정에서 잘못된 답변을 내어줄 확률이 있기 때문에 답변이 무조건 정확하다고 단정지을 수 없기 때문입니다.
3. 코드는 단순 반복만 처리하자
코드는 단순 반복적인 부분에 대해서만 짜달라고한다라는 규칙입니다.
GPT를 효율적인 도구로 잘 사용하기 위해서는 이런 부분이 가장 중요하다고 생각합니다. 핵심 로직이나 전체적인 틀은 스스로 잡되, 생각할 여지가 없고 시간을 소모하게 되는 단순 반복 작업에 대해서만 코드를 짜달라고 하자는 것입니다.
아마 이 부분은 사람마다 크게 다르게 느낄 것 같기도 합니다.
4. 잘 만들어진 질문을 던지자
질문을 하는 형식이나 깊이에 따라 GPT는 서로 다른 답을 내어줍니다. 그렇기 때문에 잘 만들어진 질문을 하도록 고민해보자입니다.
자세하게 질문을 한 경우에 더 명확하고 깔끔한 답변을 내줌을 보여주죠?
이처럼 단순 질문보다는 좋은 질문을 던지는 것이 원하는 결과를 제대로 얻게될 확률이 더 높습니다.
또한 질문을 하기 위해 문제의 원인을 명확하게 짚어야하기 때문에 이 과정에서 에러 해결 능력을 높일 수도 있다고 생각합니다.
물론
좋은 질문이라는 것이 주관적인 개념이기에 딱 이거다라고 정의할 순 없지만 저는원인과 결과가 명확하게 적힌 질문이 좋은 질문이라고 생각하고 있습니다.
GPT는 이제 삶에서 빼놓기 어려운 도구가 되었습니다. 그만큼 GPT에 대한 의존을 경계하고 스스로 생각해보는 태도를 지속해서 가질 수 있는 것이 중요하다고 생각이 됩니다.
GPT에게가 아닌 GPT와 함께 문제를 고민해보고 검증하며 활용하는 사람이 더 좋은 개발자의 모습이라고 저는 생각합니다.
