AI 코딩 도구를 처음 써 보는 분들과 이야기하다 보면, 도구 자체보다 도구에 대한 기대에서 어긋남이 시작되는 경우가 많습니다. 기능이 어렵다기보다, “이 도구가 무엇을 해주는 것인가”에 대한 그림이 실제와 다른 것이죠. 그 그림만 조금 손보면, 같은 도구가 갑자기 훨씬 쓸 만해집니다.
이 글은 사용법을 정리한 정보형 글이라기보다, 최근 입문자들에게서 자주 보이는 오해를 지켜보며 느낀 점을 적은 칼럼입니다.
‘다 알아서 해줄 것’이라는 기대
가장 자주 보이는 오해는 도구가 시작부터 끝까지 알아서 처리해 줄 거라는 기대입니다. 그래서 한 번의 요청으로 원하는 결과가 바로 나오길 바라고, 그렇지 않으면 “도구가 별로다”라고 느끼곤 합니다. 하지만 실제로는 무엇을 원하는지 사람이 먼저 분명히 정해 주어야 하고, 나온 결과가 맞는지 판단하는 몫도 여전히 사람에게 남습니다.
조금 더 들여다보면, 이 기대의 뿌리에는 “요청을 막연하게 던져도 알아서 좋은 쪽으로 채워 주겠지” 하는 마음이 있습니다. 그런데 막연한 요청에는 막연한 결과가 돌아옵니다. 같은 도구라도 “무엇을, 어떤 조건에서, 어디까지” 해 달라고 좁혀서 부탁하면 결과의 질이 눈에 띄게 달라집니다. 결국 도구의 성능 이전에, 요청을 또렷하게 만드는 것이 사용자의 첫 번째 일인 셈입니다.
✍️ 직접 써보고 느낀 점
저도 처음엔 한 번의 요청으로 완성된 결과가 나오길 기대했다가, 엉뚱한 방향으로 흘러간 코드를 받아 들고 당황한 적이 있습니다. 기대를 ‘완성품을 받는다’에서 ‘초안을 같이 만든다’로 바꾸고 나서야, 같은 도구가 훨씬 쓸 만하게 느껴졌습니다. 작게 시키고, 결과를 보고, 다시 방향을 잡아 주는 식으로 주고받으니 오히려 속도가 붙더군요.
‘코드를 이해 안 해도 된다’는 착각
두 번째로 자주 보이는 흐름은, 도구가 만들어 준 코드를 이해하지 않고 그대로 받아쓰는 태도입니다. 잘 돌아갈 때는 문제가 없어 보이지만, 막상 결과가 틀리거나 멈췄을 때 손을 댈 수 없게 됩니다. 도구가 내놓은 코드도 결국 내가 책임지고 읽어야 할 글이라는 점은 바뀌지 않습니다.
특히 입문 단계에서는 “돌아가니까 됐다”와 “이해했으니까 됐다”를 구분하기 어렵습니다. 그런데 이 둘은 시간이 지날수록 격차가 벌어집니다. 짧게라도 “이게 왜 이렇게 동작하지?”를 한 번 짚고 넘어가는 습관이, 나중에 문제가 생겼을 때 훨씬 큰 시간을 아껴 줍니다. 도구를 빠르게 쓰는 것과 이해를 건너뛰는 것은 다른 이야기입니다.
‘틀리지 않는다’는 믿음
세 번째는 도구가 항상 맞는 답을 준다고 믿는 경우입니다. 그럴듯하게 정리된 결과일수록 의심 없이 받아들이기 쉬운데, 실제로는 사실과 다른 내용을 자신 있게 내놓는 일도 드물지 않습니다. 문장이 매끄럽다는 것과 내용이 옳다는 것은 별개인데, 잘 다듬어진 결과 앞에서는 그 구분이 흐려지기 쉽습니다.
그래서 처음 쓰는 분일수록 결과를 ‘정답’이 아니라 ‘초안’으로 받아들이는 태도가 안전합니다. 특히 파일을 지우거나 시스템을 바꾸는 종류의 명령이라면, 실행 전에 무슨 동작인지 한 번 더 확인하는 습관이 필요합니다. 의심은 도구를 불신하라는 뜻이 아니라, 결과를 내 손으로 한 번 검증하라는 뜻에 가깝습니다.
그래서, 어떤 태도가 도움이 될까
오해를 뒤집으면 자연스럽게 권하고 싶은 태도가 보입니다. 무엇을 원하는지 구체적으로 정해서 부탁하고, 결과를 작은 단위로 받아 확인하고, 중요한 작업은 되돌릴 수 있게 해 두는 것입니다. 이 세 가지만 지켜도 도구와의 호흡이 한결 안정적으로 바뀝니다. 도구를 더 잘 쓰는 일은 결국 더 좋은 명령어를 외우는 것이 아니라, 도구와 사람이 역할을 어떻게 나눌지를 정하는 일에 가깝습니다.
정리하며
요즘 입문자들이 헷갈리는 지점은 도구의 성능이 아니라, 도구를 ‘대신해 주는 존재’로 보느냐 ‘보조해 주는 존재’로 보느냐의 차이에 가깝습니다. 무엇을 시킬지 정하고, 결과를 읽고, 맞는지 판단하는 일은 여전히 사람의 몫입니다. 도구를 보조로 받아들이는 순간, 오히려 더 잘 쓰게 된다고 느낍니다. 다음 칼럼에서는 비슷한 맥락에서, 개발환경 세팅에 시간을 너무 많이 쏟지 않는 방법을 정리해 보려 합니다.