AI 코딩 어시스턴트, 제대로 활용하지 못하는 개발자들의 3가지 특징

최근 Claude Code와 같은 코딩 어시스턴트부터 ChatGPT, Gemini 등 대화형 AI까지, 소프트웨어 개발의 패러다임을 획기적으로 바꾸는 도구들이 쏟아지고 있습니다. 단순한 코드 자동 완성을 넘어 아키텍처 설계와 트러블슈팅, 심지어 테스트 코드 작성까지 지원하는 시대가 도래하였습니다. 하지만 현장 프로젝트를 진행하며 주변 동료들을 둘러보면 동료들의 AI에 대한 반응 차이는 꽤 컸습니다. AI를 적극적으로 업무에 도입하여 생산성을 극대화하는 개발자가 있는 반면, 기대만큼의 효율을 내지 못하거나 오히려 복잡함에 지쳐 기존의 전통적인 검색 방식에만 다시 의존하게 되는 동료들도 종종 보게 됩니다.
'대체 왜 이런 극명한 차이가 발생하는 걸까?' 하는 의문을 가지고 동료들의 업무 방식과 AI 활용 패턴을 유심히 관찰해 보았습니다. 그 결과, 단순히 AI 툴 자체의 성능 문제가 아니라 'AI를 대하고 사용하는 방식'에 몇 가지 공통적인 문제점이 있다는 것을 발견할 수 있었습니다. 그래서 오늘은 현업에서 흔히 관찰되는 'AI를 잘 활용하지 못하는 개발자들의 3가지 특징'을 분석하고, 이를 극복하여 개발 워크플로우를 진정으로 혁신할 수 있는 실질적인 해결책을 공유하고자 합니다.

 

단편적인 질문과 '복붙(Copy & Paste)'의 늪

"당장 직면한 에러 메시지나 구현해야 할 함수 하나만 AI에게 던진 후, 그 결과물을 그대로 복사해서 붙여 넣는다."
이런 방식은 필연적으로 실패를 부릅니다. AI는 현재 우리가 개발 중인 프로젝트의 전체적인 아키텍처나 비즈니스 로직의 의도를 전혀 모르기 때문입니다. 결국 기존 코드 컨벤션과 충돌을 일으키거나, 당장은 동작하더라도 향후 유지보수가 불가능한 스파게티 코드를 양산하게 됩니다.

 

우리는 AI를 '우리 회사의 모든 레거시를 파악하고 있는 만능 시니어 개발자'가 아니라, '알고리즘 대회에서 1등을 차지한 압도적인 실력의 신규 입사자'라고 생각해야 합니다. 코딩 실력은 뛰어나지만, 우리 프로젝트의 구조와 배경지식은 백지상태인 것입니다.
따라서 단순히 단편적인 코드 작성을 요구할 것이 아니라, 프로젝트의 전체 구조를 먼저 파악하게 하는 과정이 필수적입니다. 더 나아가, AI가 파악한 내용을 하나의 문서에 저장해 두고 새로운 대화를 시작할 때마다 이를 참고할 수 있도록 설정하는 것이 좋습니다.

 

실전 활용 예시: 맥락 유지를 위한 구조화 예를 들어, 저는 최근 코딩 어시스턴트인 Claude Code를 사용하면서 다음과 같은 워크플로우를 구축했습니다.

• 1. 먼저 AI에게 프로젝트의 전체적인 디렉토리와 아키텍처 구조를 파악하게 한 뒤, 그 내용을 CLAUDE_STRUCT.md 파일에 기록하도록 지시합니다.
• 2. 그리고 전역 설정 파일인 CLAUDE.md에 "코드를 작성할 때 반드시 CLAUDE_STRUCT.md 파일의 내용을 참고하고, 만약 프로젝트 구조가 변경될 경우 해당 문서도 함께 업데이트해달라"는 규칙을 명시해 둡니다.

이렇게 세팅해 둔 결과, 대화 세션이 새로워지거나 새로운 에이전트가 투입되더라도 기존의 프로젝트 맥락을 즉시 파악하여 일관성 있고 안정적인 개발을 이어나갈 수 있었습니다.

 

AI 사용에 대한 부끄러움과 오해

"AI의 도움을 받는 것을 자신의 실력 부족으로 여겨 숨기려 하거나, 남몰래 사용하며 자존심을 세웁니다."

수학자가 복잡한 연산에 계산기를 쓴다고 해서 수학 실력이 부족하다고 평가받지 않듯, AI 역시 개발자의 단순 타이핑과 검색에 낭비되는 시간을 획기적으로 줄여주는 강력한 보조 도구일 뿐입니다. 따라서 AI를 활용하는 것을 결코 부끄러워할 필요가 없습니다.

 

과거 2016년 AWS(아마존 웹 서비스)가 국내에 본격적으로 도입되기 시작할 무렵, 일부 엔지니어들 사이에서는 "인프라를 다룰 줄 모르는 실력 부족한 사람들이나 클라우드를 쓰는 것"이라며 깎아내리는 시선도 있었습니다. 그러나 오늘날 AWS는 국내 IT 인프라에서 없어서는 안 될 핵심 서비스가 되었고, 엔지니어들이 가장 선호하고 필수적으로 다루어야 할 기술로 확고히 자리매김했습니다. AI의 도입 또한 이와 같은 맥락입니다.

 

새로운 도구를 사용하는 것을 비난하거나 부끄러워하며 배척하기보다는, 오히려 동료들과 "이런 상황에서는 어떤 프롬프트를 썼을 때 결과가 좋았는지" 적극적으로 노하우를 공유하는 태도가 필요합니다. 이렇게 열린 마음으로 협업하며 도구를 온전히 내 것으로 만드는 과정이야말로, 본인과 팀 모두가 가장 빠르게 성장할 수 있는 지름길이라고 생각합니다.

 

완벽주의의 함정과 '프롬프트' 피로감

"AI를 완벽하게 다루기 위해 처음부터 방대한 '프롬프트 엔지니어링' 기법을 공부하다가, 지레 지쳐서 예전의 개발 방식으로 돌아가 버립니다."

이는 도구를 배우는 데 너무 많은 에너지를 쏟아 본말이 전도되는 전형적인 경우입니다. 처음부터 완벽한 프롬프트를 작성하여 단번에 정답을 얻어내야 한다는 강박은 오히려 새로운 기술의 도입과 적응을 가로막는 장애물이 됩니다. 처음에는 평소 동료 개발자에게 질문하듯 자연스러운 대화로 가볍게 시작해 보는 것을 권장합니다. 여기서 가장 추천하는 실전 팁은 바로 "AI에게 어떻게 질문하고 설정해야 할지 AI에게 직접 묻는 것"입니다.

 

실전 활용 예시: AI와 대화하며 나만의 환경 구축하기

• 작업 속도를 높이기 위해 병렬 처리가 필요하다면 무작정 방대한 공식 문서를 뒤적이는 대신, AI에게 "서브에이전트(Sub-agent)를 사용하고 싶은데 어떻게 설정해야 해?"라고 물어보며 곧바로 작업을 진행할 수 있습니다.
• 저의 경우, AI가 작업을 수행하던 중 사용자의 승인(Permission) 대기 상태에 빠졌을 때 이를 즉각적으로 알아채기 어렵다는 불편함이 있었습니다. 그래서 제가 빠르게 확인하고 승인할 수 있는 알림 기능이 필요하다고 AI에게 요청했고, 그 결과 hooks를 활용하여 제 macOS 시스템에 직접 알림(Notification)을 띄우는 방법을 안내받아 적용할 수 있었습니다. 덕분에 터미널만 바라보고 있는 시간을 줄이고, AI의 작업 상태를 훨씬 더 빠르게 파악하여 효율적으로 대응하게 되었습니다.

이처럼 처음부터 완벽한 준비를 마치고 시작하려 하기보다는, 일단 실무에 부딪혀가며 AI를 사용해 보는 것이 중요합니다. 그때그때 불편하다고 느낀 점을 AI에게 물어보며 해결책을 찾고, 다른 개발자들은 이 문제를 어떻게 극복했는지 서로 교류하며 자신만의 워크플로우를 하나씩 발전시켜 나가는 것이 가장 성공적인 AI 활용법이라고 생각합니다.

 

마치며: 극단성을 경계하고 주도권을 잃지 않기

현업에서 프로그래머로 근무하다 보면, AI의 도입을 적극적으로 환영하는 개발자와 반대로 회의적이고 부정적인 시선을 가진 개발자를 모두 만나게 됩니다. 어느 쪽이든 각자의 타당한 이유가 있겠지만, 제가 생각하는 가장 중요한 포인트는 '극단적인 시각을 경계하는 것'입니다.

 

AI가 작성한 코드를 맹신하여 무비판적으로 수용하거나, 반대로 AI의 잠재력을 완전히 배척할 필요는 없습니다. 그보다는 '어떻게 하면 이 강력한 도구를 나의 워크플로우에 가장 잘 맞게 활용할 수 있을까?'를 치열하게 고민하는 과정이 필요합니다.

결국 시스템을 완성하고 책임지는 것은 우리 자신입니다. AI가 만들어낸 결과물이 내가 애초에 의도한 아키텍처와 방향성에 부합하는지 끊임없이 검토하고, 개발의 주도권을 잃지 않는 단단한 마음가짐을 가지는 것이 그 어느 때보다 중요하다고 생각합니다.