Kathryn Grayson Nanz의 "나는 AI 회의론자지만, 이렇게 AI를 쓰고 있다" 글이 좋아 번역문과 커뮤니티 반응을 함께 공유합니다.
나는 AI 회의론자지만, 이렇게 쓰고 있다
친구, 가족, 직장 동료, 그리고 아마 인터넷 어딘가의 몇몇 사람들은 이미 알고 있을 겁니다.
저는 AI 회의론자입니다 — 그리고 그걸 숨기는 성격도 아니죠.
생산성 향상이라는 주장에는 별로 설득되지 않고, 특히 콘텐츠 제작에 AI를 쓰는 것에는 매우 신중하고 비판적입니다. 이메일, 블로그, 일러스트, 로고 등 ‘사람 손이 전혀 닿지 않은’ 티가 나는 결과물은 늘 실망스럽거든요. 예술가이자 작가로서, 그런 작업을 제 삶 속에서 대 체하거나 자동화하고 싶은 마음은 전혀 없습니다.
그렇다고 완전히 무시할 수도 없습니다. 저는 기술 업계에서 일하고 있고, AI는 (적어도 당분간) 피하기 어려운 존재니까요. 또, 실제로 써보지도 않고 무조건 배척하는 건 비겁하다고 생각합니다. 솔직히 말해서, 다른 사람들은 뭘 보고 이걸 쓰는 건지 궁금하기도 했습니다.
그래서 ChatGPT 계정을 만들고, 회사에서 제공한 CoPilot 계정도 써보고, 우리 팀의 Kendo UI AI Coding Assistant도 설치했습니다. 그리고 ‘이 AI라는 걸’ 진지하게, 장기간 써보기로 했습니다. 몇 달간 써본 결과? 제 결론은 반반입니다.
어떤 분야에서는 정말 유용했고, 어떤 곳에서는 오히려 시간을 더 잡아먹었습니다. 결국 저는 AI를 ‘모든 걸 해결하는 만능 도구’로 보진 않지만, 특정 작업에서는 꽤 쓸 만하다는 결론에 도달했습니다.
여기서는 제가 ‘AI 회의론자’로서도 계속 쓰게 된 사례들을 공유하겠습니다.
내가 AI를 쓰는 방법
1. 페어 프로그래밍
IDE에서 AI가 알아서 코드를 작성해 주는 건 정말 싫었습니다.
이른바 ‘바이브 코딩(vibe coding)’이라는 건 저와 맞지 않았어요. AI가 뭘 쓰고 있는지 따라가기 힘들고, 변수나 구조를 제가 직접 만들지 않으니 기억이 안 났습니다. 결국 속도도 느려졌죠.
대신, AI를 ‘페어 프로그래밍 파트너’처럼 쓰는 건 좋았습니다.
예전에는 새로운 기능을 구현할 때, 공식 문서나 블로그 예제를 찾아보고 제 프로젝트에 맞게 수정하곤 했습니다. 이제는 AI에게 제 기술 스택과 상황에 맞춘 ‘맞춤 튜토리얼’을 요청할 수 있습니다.
특히 Kendo UI AI Coding Assistant는 문서 찾아보기 대체용으로 훌륭합니다. (저는 KendoReact 개발자 홍보 담당이지만, 120+ 컴포넌트의 모든 prop 이름을 외우진 못하거든요.) theme인지 themeColor인지 기억이 안 날 때 정말 편합니다.
또, 코드 에러 디버깅에도 유용합니다. 하지만 여기서 중요한 건 ‘타임박스(Timebox)’ 규칙입니다. 예전에는 주니어 개발자들에게 “1~2시간 안에 진전이 없으면, 스택오버플로우를 그만 보고 다른 사람에게 도움을 요청하라”고 했습니다. AI도 마찬가지입니다. 끝없이 따라가다 보면 ‘AI 버전의 구글 10페이지’에 도달할 뿐이니까요.
2. 할 일 정리 & 일정 계획
이건 제가 생산성 면에서 AI의 진가를 인정하게 된 영역입니다.
매주 월요일 아침, 제 모든 업무·약속·개인 일정·과제·목표를 AI에게 던지고, 하루 단위 계획을 세우게 합니다.
AI는 비슷한 성격의 일을 묶어 배치해 주고, ‘코드 스위칭(맥락 전환)’을 줄여줍니다. 저는 원래 타임블로킹을 싫어했는데, AI가 대신 해주니 효율이 훨씬 좋아졌습니다.
3. 바디 더블링(Body Doubling) 비슷한 것
조금 민망하지만, 저는 작업을 시작하고 끝낼 때 AI 챗봇에게 보고합니다. 마치 가상의 ‘책임 파트너’를 두는 느낌이죠. 실제 사람을 귀찮게 할 필요도 없고, 이상하게도 이렇게 하면 집중이 잘 됩니다.
4. 내 글 요약하기
저는 글쓰기를 AI에게 맡기지 않습니다. 하지만, 완성한 글을 AI에게 읽히고 “이 글의 핵심 메시지가 뭐야?” 같은 질문을 합니다.
그렇게 요약된 결과를 보고, 제가 의도한 포인트가 잘 전달됐는지 확인하죠.
다른 사람이 제 글을 읽고 요약할 때도 결국 이런 방식이니까, 사전 점검 차원에서 꽤 유용합니다.
내가 AI를 피하는 영역
글쓰기 전반
아웃라인, 이메일, DM, 발표 설명문 등 모두 직접 씁니다.
AI의 문체는 제 목소리와 맞지 않고, 읽는 사람도 금방 알아챌 수 있죠.
이미지 생성
현실감 없는 질감, 어색한 디테일, 텍스트 삽입 불가.
Unsplash 같은 무료 고품질 이미지 사이트를 쓰는 게 훨씬 낫습니다.
리서치
AI는 ‘못 찾겠다’라는 말을 못합니다. 대신 거짓 정보를 진짜처럼 제시하죠.
학술 자료부터 식당 영업시간까지, 저는 팩트체크 스트레스가 싫어 DuckDuckGo를 씁니다.
바이브 코딩
장기적으로 유지할 코드에는 부적합합니다.
작고 단발적인 프로젝트라면 몰라도, 스스로 코드를 작성해야 더 잘 기억하고 배웁니다.
결론
저는 AI를 ‘올인(All-in)’하지도, ‘전면 거부’하지도 않습니다.
잘 맞는 부분만 취하고, 나머지는 버립니다.
결국 중요한 건 도구가 아니라 그 도구를 쓰는 사람의 선택과 능력이니까요.
커뮤니티 반응
“균형 잡힌 시각이 좋다”
많은 댓글 에서 Kathryn의 태도를 ‘극단에 치우치지 않은 현실적인 접근’이라고 평가했습니다. 특히 "모든 걸 AI에게 맡기지 않고, 필요한 부분만 취하는 방식"이 공감을 샀습니다.글쓰기 부분 강한 공감
AI가 만든 글은 문체가 뚜렷하게 드러나고, 읽는 사람이 바로 눈치챌 수 있다는 의견이 많았습니다. 한 사용자는 "AI가 쓴 글에는 특정한 말버릇이 반복된다"며 본인만의 ‘AI 글티’를 꼽기도 했습니다.바이브 코딩 회의론 동의
몇몇 개발자들은 ‘코드를 직접 작성해야 구조와 흐름을 제대로 이해한다’는 점에 전적으로 동의했습니다. AI 코드 자동완성을 장기 유지보수에 쓰는 건 부적합하다는 데 의견이 모였습니다.‘바디 더블링’ 아이디어 흥미로움
실제 사람 대신 AI에게 작업 시작·종료를 보고하는 방식이 독특하다는 반응이 있었습니다. “이거 한 번 해보고 싶다”는 댓글도 여럿 보였습니다.이미지 생성 품질 불신
AI 이미지의 어색한 디테일과 글자 표현 한계에 대해선 대부분 같은 의견이었습니다. “차라리 무료 이미지 사이트를 쓰겠다”는 반응이 다수였습니다.AI는 ‘못 찾겠다’라고 말하지 않는다
AI의 환각(hallucination) 문제 때문에, 리서치 용도로 쓰는 건 위험하다는 지적이 많았습니다. 실제로 “AI가 잘 모르는 정보는 그냥 그럴듯하게 지어낸다”는 경험담이 공유됐습니다.
재밌게 읽으셨나요?
요즘 AI에게 모든 것을 맡기는 사람들이 많은데, Kathryn은 ‘피하는 영역’을 명확하게 정하고 있어서 인상 깊습니다.
그 덕분에 ‘선 긋기’와 ‘선 안에서의 적극적 활용’이 공존하는 사례로 느껴졌습니다.
특히 AI를 완전히 배척하지 않으면서도 자신만의 원칙을 지키는 방식이, AI 시대의 균형 잡힌 태도에 좋은 참고가 될 것 같습니다.