#LLM#AI#ChatGPT#Prompt Engineering#Future of Coding
AI가 나를 대체할까 두려워, AI를 부려먹기로 했다
ChatGPT가 처음 나왔을 때 개발자들은 공포에 떨었습니다. '이제 코딩은 끝났구나.' 저도 그랬습니다. 하지만 1년간 LLM을 실제에 도입하며 깨달았습니다. AI는 신이 아니라, 엄청나게 똑똑하지만 가끔 헛소리하는 인턴이라는 것을요.
2025년 8월 28일
Codemapo
ChatGPT가 처음 나왔을 때 개발자들은 공포에 떨었습니다. '이제 코딩은 끝났구나.' 저도 그랬습니다. 하지만 1년간 LLM을 실제에 도입하며 깨달았습니다. AI는 신이 아니라, 엄청나게 똑똑하지만 가끔 헛소리하는 인턴이라는 것을요.
둘 다 같은 Transformer 자식인데 왜 다를까? '빈칸 채우기'와 '이어 쓰기' 비유로 알아보는 BERT와 GPT의 결정적 차이. 프로젝트에서 겪은 시행착오와 선택 가이드.
ChatGPT는 질문에 답하지만, AI Agent는 스스로 계획하고 도구를 사용해 작업을 완료한다. 이 차이가 왜 중요한지 정리했다.
세 가지 AI 코딩 도구를 실제로 써보고 비교했다. 자동완성, 코드 생성, 리팩토링 각각 어디가 강한지 솔직한 후기.
고객 상담 챗봇이 엉뚱한 대답을 해서 식은땀 흘린 경험, 그리고 RAG(검색 증강 생성)를 도입해 '오픈북 테스트'를 치르게 한 과정을 공유합니다. 벡터 DB, 임베딩, 그리고 하이브리드 검색까지 파헤쳐봅니다.
2022년 11월, ChatGPT가 세상에 나왔을 때 제 첫 감정은 '공포'였습니다. 제가 3시간 동안 끙끙대며 짠 정규표현식을, 녀석은 3초 만에 뱉어내더군요. 심지어 제가 짠 코드보다 더 깔끔했습니다.
"아, 내 밥줄은 이제 끊겼구나. 치킨 튀기는 기술이나 배워야 하나."
하지만 그로부터 1년이 지난 지금, 저는 치킨집 사장님이 아니라 AI를 부리는 개발자가 되었습니다. 어떻게 공포를 극복하고 도구로 받아들이게 되었는지, 그 과정을 공유합니다.
처음엔 신기했습니다. "React로 투두리스트 짜줘"라고 하면 뚝딱 만들어줍니다. "이 코드 리팩토링해줘"라고 하면 변수명까지 예쁘게 고쳐줍니다.
하지만 곧 한계를 만났습니다.
제가 사용하던 특정 라이브러리의 최신 버전을 써달라고 했더니, 존재하지 않는 함수(createSuperButton())를 아주 자신 있게 만들어내더군요. (이걸 Hallucination, 환각이라고 하죠.)
그 코드를 복붙해서 실행했더니 당연히 에러가 났습니다. AI에게 따졌더니 "죄송합니다"라며 또 다른 가짜 함수를 만들어냈습니다.
이때 깨달았습니다.
"아, 이 녀석은 천재가 아니라, 그럴듯한 말을 지어내는데 특화된 앵무새구나."
이걸 깨닫고 나니 오히려 안심이 되었습니다. 판단(Validation)은 여전히 인간의 몫이었으니까요.
개발자로서 LLM을 제대로 쓰려면 원리를 알아야 합니다. LLM은 생각하는 기계가 아닙니다. "다음에 올 단어를 확률적으로 예측하는 기계"입니다.
Input: "대한민국의 수도는"
Model:
- "서울" (99.8%)
- "부산" (0.1%)
- "워싱턴" (0.01%)
수많은 텍스트를 읽어서 "대한민국 수도" 뒤에는 "서울"이 올 확률이 높다는 걸 학습했을 뿐입니다. 그래서 가끔 논리적으로 말도 안 되지만 문법적으로는 완벽한 거짓말을 하는 겁니다.
ChatGPT에게 9.11과 9.9 중 뭐가 더 크냐고 물어보면 가끔 9.11이 더 크다고 합니다.
멍청해서가 아니라, 숫자를 '단어(Token)'로 쪼개서 보기 때문입니다.
9.11을 9, ., 11로 보고, 9.9를 9, ., 9로 본다면, 뒤에 있는 11이 9보다 크니까요.
이런 토큰화(Tokenization)의 한계를 이해해야 엉뚱한 대답에 당황하지 않습니다.
LLM에는 Temperature라는 설정값이 있습니다. (0 ~ 1 사이)
우리가 쓰는 챗봇은 이 값이 적절히 섞여 있습니다. 그래서 가끔 "창의적인 헛소리"를 하는 겁니다. 코딩을 시킬 때는 "창의력 죽이고(Temperature=0) 팩트만 말해"라고 프롬프트에 명시하는 게 좋습니다.
이 원리를 이해하면 AI를 대하는 태도가 달라집니다. "정답을 알려줘"가 아니라, "내가 검증할 수 있는 초안을 써줘"로 바뀌게 됩니다.
이제 저는 개발할 때 AI 없이는 못 사는 몸이 되었습니다. 하지만 코드를 처음부터 끝까지 다 맡기진 않습니다.
인간이 하기엔 너무 귀찮고 틀리기 쉬운 문법들. "이메일 주소 검증하는 정규식 짜줘", "지난달 가입자 중 결제 안 한 사람 뽑는 SQL 짜줘" 이건 AI가 인간보다 훨씬 잘합니다. (단, 결과물 테스트는 필수)
"이 함수 이름 뭐라고 지을까?"라고 물어보면 꽤 그럴듯한 제안을 줍니다. 복잡한 레거시 코드를 던져주고 "이거 무슨 코드인지 주석 달아줘"라고 하면 분석 시간을 획기적으로 줄여줍니다.
"이 함수에 대한 엣지 케이스(Edge Case) 테스트 코드 짜줘." 제가 미처 생각하지 못한 예외 상황(null 입력, 빈 배열 등)까지 찾아서 테스트를 만들어줍니다.
AI를 잘 쓰는 개발자와 못 쓰는 개발자의 차이는 질문(Prompt)에 있습니다.
[하수]"로그인 기능 짜줘." (결과: 보안 취약점 투성이인 엉망진창 코드)
"Next.js 14 App Router를 사용하고, NextAuth.js로 소셜 로그인을 구현해 줘. 토큰은 httpOnly 쿠키에 저장해야 하고, TypeScript로 타입 정의도 확실하게 해줘." (결과: 바로 실제에 쓸 수 있는 코드)
AI에게 한 번에 정답을 요구하면 멍청해집니다. "단계별로 생각해서(Think step by step)" 답을 내라고 하면 훨씬 똑똑해집니다.
[나쁜 질문] "이 코드 버그 찾아줘."
[좋은 질문] "너는 시니어 엔지니어야.
이렇게 사고의 과정을 강제하면 환각(Hallucination)이 현저히 줄어듭니다.
AI는 전체 개발 과정의 80%에 해당하는 지루하고 반복적인 작업을 훌륭하게 처리해줍니다. 하지만 나머지 20%의 핵심 비즈니스 로직과 아키텍처 결정은 여전히 인간의 몫입니다.
많은 주니어들이 범하는 실수는 AI에게 100%를 맡기려 한다는 점입니다. AI에게 100%를 시키면, 나중에 디버깅하는 데 200%의 시간을 쓰게 될 것입니다. AI는 '부조종사(Copilot)'이지 '기장(Pilot)'이 아닙니다. 조종간은 항상 본인이 잡고 있어야 합니다. 이 법칙은 코딩뿐만 아니라 문서 작성, 이메일 쓰기, 회의록 정리 등 모든 업무에 적용됩니다.
결국 AI 시대에도 "무엇을 만들 것인가(What)"와 "어떻게 만들 것인가(How)"를 아는 개발자만이 살아남습니다. 아무것도 모르는 사람은 질문조차 제대로 할 수 없으니까요.
AI는 정말 편합니다. 하지만 그 편안함에는 대가가 따릅니다. 바로 '코드 문해력(Code Literacy)의 저하'입니다.
직접 짤 때는 한 줄 한 줄 고민하며 짰지만, AI가 100줄을 뱉어내면 우린 "대충 맞겠지" 하고 넘어가게 됩니다. 이게 반복되면 나중에는 "코드를 읽는 능력" 자체가 퇴화합니다.
이제 시니어 개발자의 역할은 '작성자(Writer)'에서 '리뷰어(Reviewer)'로 바뀝니다. 그런데 다들 아시죠? 남이 짠 코드 리뷰하는 게 내가 짜는 것보다 10배는 더 어렵다는 걸요. AI가 짠 코드를 내 코드처럼 완벽하게 이해하고 검증할 수 없다면, 당신은 그저 Ctrl+C, Ctrl+V 기계일 뿐입니다.
"AI가 나오면 주니어 개발자는 필요 없지 않나요?" 반은 맞고 반은 틀립니다. "AI가 짜준 코드가 왜 돌아가는지 모르는" 주니어는 도태됩니다. 하지만 "AI를 이용해서 시니어처럼 생산성을 내는" 주니어는 엄청난 기회를 잡을 것입니다.
이제 개발자의 역량은 "API 문법 암기"가 아니라 "문제 해결 능력"과 "AI 핸들링 능력"으로 정의될 것입니다.
두려워하지 마세요. 대신 올라타세요. AI는 여러분의 일자리를 뺏는 게 아니라, 여러분의 퇴근 시간을 앞당겨줄 최고의 파트너니까요.