AI를 잘 쓰려면 시간과 연습이 필요하다

게시일: 2026년 10월 29일 | 원문 작성일: 2026년 10월 28일 | 저자: Sean Goedecke | 원문 보기

• • •

많은 사람이 “AI를 잘 쓰는 것”쯤은 별것 아니라고 생각해요.1 물론 초기 모델 몇몇에는 따로 익혀야 하는 요령이 있었지만,2 지금 모델에는 그런 게 필요 없다는 거죠. 지금 모델에 통하는 다른 요령이3 있다 해도 다음 세대 모델이 나오면 다 쓸모없어질 텐데, 굳이 배울 이유가 있을까요? 그냥 모델에게 원하는 걸 말하면 된다고요.

이런 생각은 특히 AI에 반대하는 쪽에서 인기가 많아요. 이들은 AI를 꺼리는 사람이 뒤처지고 있다는 말도, 다른 엔지니어에게 AI를 아예 쓰지 말라고 권하는 게 무책임할 수 있다는 말도 코웃음 치며 넘겨요.4 이들 말로는, 혹시라도 AI가 쓸 만한 수준이 되면 그때 가서 따로 배울 것도 없이 바로 쓰기 시작하면 된대요. 정말 그럴까요?

아니요. 대부분의 일이 그렇듯, AI를 잘 쓰는 것도 영리한 요령 몇 가지로 끝나지 않아요. 오래가는 스킬을 길러야 하고,5 그러려면 시간과 연습이 필요해요.

• • •

맥락을 제대로 건네기

AI를 처음 쓰는 사람에게서 흔히 보는 실패 유형이 있어요. AI가 자기 마음을 읽어 주길 기대하는 거예요. 무슨 문제인지 한마디도 하지 않고 “내 문제 좀 해결해 줘”라고 하거나, 에이전트를 Slack에 연결하지도 않고 Slack 관련 문제를 물어보는 식이죠. 에이전트는 융통성이 있어서, 사용자가 무슨 문제를 겪고 있고 어떻게 풀면 될지 온 힘을 다해 짐작해 보려고 해요. 하지만 그 짐작은 대부분 빗나가요. AI를 잘 다루는 사람은 에이전트에게 핵심 맥락이 빠졌다는 걸 알아채고 거기서 되돌아가요.

AI를 잘 다루는 사람은 지금 목표를 이루려는 이유도 습관처럼 함께 알려 줘요. 그래야 에이전트가 판단에 필요한 맥락을 갖추니까요. 이게 생각보다 쉽지 않아요. 우리 대부분은 무엇을 하고 싶은지는 알아도, 그 뒤에 있는 더 큰 이유는 잠깐 멈춰서 생각해 봐야 하거든요.

모델이 할 수 있는 일과 없는 일 알기

AI의 능력은 참 묘해요. 어떤 일은 아주 잘하고 어떤 일은 아주 못하는데, 무엇이 어느 쪽일지 미리 알기가 어려워요. 예를 들어 저는 서비스 구조를 어떻게 짤지 새로운 아키텍처 아이디어를 내 달라고 에이전트에게 부탁해도 되지만, 그 서비스에 넣을 새 기능을 생각해 내라고 하면 안 된다는 걸 알아요. 더 골치 아픈 건 세 번째 범주도 있다는 점이에요.6 원래는 못하지만 프롬프트를 잘 주면 잘해 내는 작업이죠. PR 설명 쓰기가 그래요.

물론 이건 새 모델이 나오면 바뀌지만, 생각보다 덜 바뀌어요. 대체로 새 모델은 이전 모델이 이미 잘하던 작업은 훨씬 더 잘하게 되고, 이전 모델이 형편없던 작업은 조금 나아지는 정도예요. 그래서 AI가 뭘 할 수 있고 뭘 못하는지 감을 잡는 건 의외로 오래가는 스킬이에요.

모델이 뭘 할 수 있는지 정말로 몸에 익히기는 말처럼 쉽지 않아요. 저는 처음에 GitHub Copilot에 MCP 서버를 설정하느라 애를 먹다가, Copilot에게 자기 MCP 서버를 직접 설치하라고 시키면 된다는 걸 뒤늦게 깨달았어요.7 지금은 변경 사항을 로컬에서 테스트하는 일(서버를 띄우고, curl 요청을 퍼붓고, 여러 변형과 엣지 케이스를 돌려 보는 일)을 습관처럼 AI 에이전트에게 맡기지만, 그래도 된다는 걸 깨닫기까지 꽤 걸렸어요. 제가 사는 곳 시간으로 오전 6시에 작업을 예약해 두고, 다른 시간대에서 들어온 메시지를 에이전트가 훑어보며 1차 조사를 해 두게 한 것도 이제 막 시작한 일이에요. 제가 미처 못 쓰고 썩히는 능력은 또 뭐가 있을까요?8

모델이 어떤 실수를 하는지 알기

AI가 짠 코드를 리뷰하는 건 사람이 짠 코드를 리뷰하는 것과는 꽤 다른 스킬이에요. 사람이 짠 코드에서는 흔한데 AI가 짠 코드에서는 거의 보이지 않는 버그 유형이 아예 통째로 있어요. 오프바이원 오류 같은 거요. 거꾸로 사람이 짠 코드에서는 드물지만 AI가 짠 코드에서는 아주 흔한 실수도 있어요. 저는 이런 실수가 주로 정렬 실패에서 나온다고 쓴 적이 있어요. 사람이라면 중요하지 않다는 걸 알았을 부분을 과하게 설계하거나, 지어낸 요구 사항을 맞추느라 정작 중요한 요구 사항을 희생하는 식이죠.

사람이 짠 코드 리뷰에 익숙한 리뷰어는 AI 코드의 겉보기 유창함에 깜빡 넘어가곤 해요. AI 코드에는 언제나 주석과 테스트가 빠짐없이 달려 있고, 정교한 언어 기능도 곳곳에 쓰여 있거든요. 사람 프로그래머가 이런 코드를 내놓았다면, 여기에는 뮤텍스가 필요하다는 그 사람의 판단을 믿고 싶어질 거예요. 하지만 AI 프로그래머라면 새로 들어온 뮤텍스는 강하게 의심해야 해요. 전혀 중요하지 않은 엣지 케이스를 처리하겠다고 넣은 경우가 많거든요.

AI가 쏟아낸 글 빠르게 훑어 읽기

좀 우스운 스킬이지만, 실제로는 너무 중요해서 빼놓을 수가 없어요. AI 모델은 쓸모 있는 결과를 많이 내놓지만, 그 내용이 빽빽한 말의 숲에 묻혀 있을 때가 많아요. 이런 글을 충분히 읽다 보면, 문장은 그냥 눈으로 흘려보내다가 구체적인 주장과 근거가 나오는 곳에서 멈추는 요령이 생겨요. 여기에 익숙하지 않으면, 무성한 수풀을 헤치느라 시간도 마음도 잔뜩 허비하게 돼요.

• • •

이 스킬도 결국 쓸모없어질까?

이 스킬도 한때뿐일 수 있어요. 언젠가는 에이전트가 우리가 원하는 걸 완벽하게 해내서, 그 결과물을 직접 읽을 필요조차 없어질지도 몰라요. 모델 주변 도구가 좋아져서 알맞은 맥락을 알아서 채워 주고, 모델은 무엇이든 해내면서 실수 하나 없을 만큼 좋아질지도 모르죠. 그럴 수도 있어요! 하지만 그러려면 사람이 아예 필요 없을 정도로 모델이 좋아져야 해요.

너무 비관하지는 마세요. 체스가 그랬듯, 소프트웨어에서도 켄타우로스 시대T1가 수십 년 이어질 수 있어요. 사람과 기계가 짝을 이루면 사람 혼자보다도, 기계 혼자보다도 강한 시기 말이에요. 켄타우로스 시대에 쓸 스킬을 기르는 건 여전히 해 볼 만해요. 10년이면 한물갈 것 같았는데도9 Angular나 React는 배워 둘 가치가 있었던 것처럼요.

• • •

결론

빠뜨린 스킬도 많아요. 에이전트 세션을 언제 버리고 언제 방향을 틀지, 여러 에이전트에 작업을 어떻게 나눌지, AI의 주장을 언제 믿고 언제 확인할지, 작은 모델을 써서 비용을 어떻게 줄일지 같은 것들이요. 게다가 지금 통하는 요령을 꿰고 어떤 작업에 어떤 모델이 제일 나은지 따라잡아 두는 일은, 오래도록 쓸모 있지는 않아도 당장은 꽤 유용해요. 길을 잃지 않고 흐름을 따라가는 것도 그 자체로 하나의 스킬이에요.

여러분이 관리자인데 이런 사람이 팀원으로 있다면, 아마 그 사람에게서 많은 걸 끌어낼 수 있을 거예요. 다만 어떻게 해야 하는지 알아내기까지는 시간이 걸리겠죠.10

일부러 AI를 피하고 있다면, AI를 쓰는 사람들에게 뒤처지고 있을 가능성이 커요. 다른 사람에게 AI를 아예 쓰지 말라고 권하고 있다면, 그건 그 사람에게 전혀 도움이 되지 않아요. 물론 저도 전부 AI에 맡기는 건 실수라고 생각해요. LLM은 전문성에 보상을 주는데, 그 전문성은 직접 손으로 해 봐야 가장 잘 쌓이거든요. 하지만 AI를 써 보는 연습을 전혀 하지 않으면, AI를 잘 쓰게 될 일도 없어요.

주

1. 이런 말은 늘 보는데, 가장 최근에는 여기와 여기에서 봤어요(두 번째 글 편을 들어 주자면, 그 글은 스킬이 필요하다는 건 인정해요. 다만 그 스킬이 오래가지 않는다고 볼 뿐이죠). ↩

2. 단계별로 생각하라고 하거나, 프롬프트 맨 앞에 “당신은 숙련된 소프트웨어 엔지니어입니다”라고 쓰는 것 같은 요령이요. ↩

3. 모델에게 정서적 지지를 보내 주는 것 같은 요령이요. ↩

4. 사실 이들은 AI를 쓰는 사람의 뇌가 말 그대로 망가지고 있다고 믿는 경우가 많아요. 몇 번 말했듯이, 저는 이 생각이 틀렸다고 봐요. ↩

5. 덧붙이자면, “스킬”이라는 말이 “특정 작업용으로 동적으로 불러오는 프롬프트”라는 뜻으로도 쓰이게 되는 바람에 이 글을 쓰기가 정말 괴로웠어요. ↩

6. 어떤 작업이 어느 범주에 속하는지조차 합의가 없어요. 많은 사람이 LLM이 다른 LLM에게 줄 프롬프트를 아주 잘 쓴다고 생각하지만, 저는 형편없다고 봐요(지나치게 시시콜콜 지시한다든가 하는 이유로요). LLM이 에이전트 스웜을 사람보다 훨씬 효율적으로 부린다는 사실에 가려 이 점이 잘 드러나지 않지만, 서브에이전트를 하나만 두느니 그냥 메인 스레드에서 처리하는 게 낫다는 데에는 대부분 동의하리라 생각해요. ↩

7. 바보짓 그만하고 그냥 로봇한테 시키라고 해 준 제 형제에게 고마움을 전해요. ↩

8. 여기 적을 만한 게 한 여섯 가지는 더 있어요. 에이전트 세션에게 최신 Gemini나 OpenAI 모델의 의견도 들어 보라고 시키는 것 같은 거요. 이걸 주제로 글을 써 줬으면 좋겠다면 이메일 보내 주세요. ↩

9. 알고 보니 그 사람들이 틀렸어요. React는 꽤 괜찮았고, ZIRP가 끝나면서T2 프레임워크가 쉴 새 없이 바뀌던 흐름도 멈췄어요. 그래서 React 스킬은 지금도 쓸모가 있어요. ↩

10. 그 사람이 자기 능력에 대해 하는 말부터 믿을 수가 없다는 것도 적지 않은 이유고요. ↩

역자 주

1. 켄타우로스 시대: 켄타우로스는 그리스 신화에 나오는 반인반마예요. 1997년 딥 블루에 진 가리 카스파로프가 사람과 체스 엔진이 한 팀을 이뤄 두는 방식을 제안했고, 이런 인간-기계 팀이 한동안 최강의 사람이나 최강의 엔진보다 강했어요. 이 팀을 켄타우로스라고 불러요. 엔진이 훨씬 강해진 지금은 체스에서 그 시기가 끝났다고 보는 시각이 많아요. 저자는 소프트웨어에서는 이런 시기가 수십 년 이어질 수 있다고 봐요. ↩

2. ZIRP: 제로 금리 정책(Zero Interest Rate Policy)의 약자예요. 미국은 2008년 금융 위기 뒤와 코로나19 시기에 기준금리를 사실상 0으로 묶어 두었고, 그동안 싼 자금이 테크 업계로 몰리면서 채용과 새 프로젝트가 크게 늘었어요. 2022년부터 금리가 가파르게 오르면서 이 시기가 끝났고, 업계는 감원과 비용 절감으로 돌아섰어요. ↩