LLM 활용 가이드-AI와 함께 일하는 현명한 방법

LLM AI가 생성한 코드를 맹신하지 말라

요즘 ChatGPT, Claude 같은 LLM들이 개발 세계를 휩쓸고 있다. 코드 작성에서부터 버그 해결, 문서화까지… 못하는 게 뭐야? 싶을 정도로 다재다능하다.

근데 실무에서 이 답변을 무작정 믿었다가는…주옥 되는 건 한순간이다. 이건 내가 직접 겪어본 이야기다.

이 글에서는 내가 팀에서 LLM 도구들 쓰면서 깨달은 팁들, 주의사항들을 공유하려 한다. 특히 개발팀에서 이 녀석들이랑 어떻게 현명하게 지낼 수 있는지 방법을 알아보자.

LLM의 치명적 약점: ‘환각’

일단 기본을 알고 가자. LLM은 “정확한 답변”을 주는 게 아니라 “그럴싸해 보이는 답변”을 만들어낸다. 모델의 성능이고 자시고 애초에 본디 이 방식에 차용된 트랜스포머, 디퓨저 모델의 원론이 그런 원리로 착안된건데 자꾸 다들 정확도의 성능을 논하고 있다…애초에 그렇게 쓰라고 나온게 아니라고!! ㅠㅠㅠ

사실 LLM Gen AI의 무분별한 상용화로 가장 두려운 건 실질적으로 인력을 줄일만큼 적절한 용도에 어디에 도입할 지 결정권자들이나 상품을 소비하는 유저나 제대로 된 판별력이 빌드업 되지 않은 상황에서 무작위로 주어진 정보로 이제 전문가들의 의견도 쌉 무시하는 분위기가 훅 퍼져버린게 가장 우려스럽다.

당장 데이터 싸이언스 전공으로 대학원 코스 이수 중인 내 말도 비 전공자/비 연구자들이 틀리다고 지적질 중인데, 뭐.

AI가 완전히 삽질하는 경우

이런 상황에서 LLM은 정말 창의적인 오답을 만들어낸다:

• 존재하지 않는 코드 지어내기: 실제 없는 클래스나 메서드를 있는 것처럼 떠들기
• 버전 꼬이기: 라이브러리 업데이트 내용 따라가지 못하고 구버전 API 추천하기
• 맥락 완전 놓치기: 프로젝트 특성 무시하고 일반론적인 답변만 내놓기

이런 게 점점 나아질 거란 말은 3년전부터 나왔지만 아직도

// LLM이 자신있게 추천한 코드 (실제론 없는 메서드)
element.textBeherit = "Hello World"; // 이런 속성 실제로 없음

// 실제로 작동하는 코드
element.textContent = "Hello World";

이런 ‘환각(hallucination)’ 현상은 내가 지어낸 말이 아니라 OpenAI, Google 같은 AI 회사들도 인정하는 문제다. 특히 코드처럼 정확도가 중요한 영역에선 더더욱 조심해야 한다.

실제로 당한 사례들

내가 실제로 겪었거나 동료들이 당한 사례들을 좀 공유해보겠다.

이런 사례들은 단순히 내 시간 낭비를 넘어서 팀 전체 생산성과 코드 품질에 악영향을 미친다. 특히 주니어 개발자가 AI 답변을 그대로 믿고 PR 날리면, 시니어 개발자가 디버깅하느라 머리 쥐어뜯는 상황이 너무 자주 벌어진다.

개발팀을 위한 생존 가이드라인

AI랑 잘 지내면서도 삽질을 최소화하는 방법을 알아보자.

1) LLM 답변은 ‘참고자료’일 뿐이다

AI 코드 제안 → 실제 코드베이스 확인 → 동작 검증 → 적용

AI가 자신만만하게 내놓은 코드나 해결책? 반드시 실제 코드랑 대조해봐야 한다. “AI가 이렇게 말했으니 맞겠지”라는 생각은 위험하다. 대신 “AI가 이런 아이디어를 줬으니, 내가 직접 확인해보고 적용해볼까?” 이런 마인드가 필요하다.

2) 코드 돌아가는지 내 눈으로 직접 확인하기

AI가 제안한 코드가 진짜 작동하는지 확인하는 습관이 중요하다:

• CSS/스타일 변경은 브라우저 개발자 도구로 눈으로 직접 확인
• 로직 변경은 테스트 케이스 작성하거나 수동 테스트로 검증
• 애니메이션/상호작용은 실제로 클릭하고 조작해보기

3) AI가 헛소리하면 팀원들에게 바로 알리기

LLM이 존재하지 않는 코드나 메서드를 추천했으면 팀원들한테 바로 공유하자. 이러면 다른 팀원들이 같은 함정에 빠지는 걸 막을 수 있다.

예시 메시지:

“방금 ChatGPT가 우리 프로젝트에 .special-container 클래스가 있다고 했는데, 실제로는 없는 클래스임. 다들 참고하세요.”

4) AI의 강점과 약점 구분하기

AI는 이런 거 할 때 진짜 좋다:

• 아이디어 브레인스토밍
• 코드 구조 예시 보여주기
• 일반적인 패턴 제안
• 문서화 초안 작성

반면 이런 건 AI한테 맡기면 망한다:

• 프로젝트 특화 코드 분석
• 복잡한 버그 디버깅
• 성능 최적화
• 보안 관련 코드 리뷰

5) AI 도움 받았으면 솔직히 말하기

PR: 로그인 기능 개선 (#123)

- 로그인 상태 관리 로직 개선
- 에러 메시지 UX 향상
- 세션 만료 처리 추가

참고: 에러 핸들링 부분은 ChatGPT 제안 참고했고, 
실제 테스트로 검증했습니다.

PR이나 코드 리뷰에서 AI 도움 받은 부분 숨기지 말고 명시하자. 이러면 리뷰어가 해당 코드를 더 꼼꼼히 살펴볼 수 있다. 팀의 코드 품질 유지하는데 중요한 습관이다.

이렇게 말해야 통한다

AI 활용 가이드라인을 팀원들이나 상사에게 어떻게 전달하면 좋을지 몇 가지 팁을 공유한다.

팀원/동료에게 할 때

"AI가 추천한 코드, 특히 스타일/클래스/메서드는 꼭 실제 코드랑 비교해봐.
없는 코드/클래스 나오면 바로 공유해줘.
검증 없이 복붙하면 나중에 디버깅하느라 머리 터짐."

직설적이고 명확한 메시지가 효과적이다. 특히 AI 환각으로 삽질한 실제 사례를 공유하면 더 설득력 있다.

운영팀/경영진에게 할 때

"AI 쓰면 생산성 오르는 것 맞습니다. 근데 검증 없이 도입하면 오히려 코드 품질 떨어지고 디버깅 비용 증가합니다.
지난 프로젝트에서 AI가 제안한 잘못된 코드 때문에 시니어 개발자 3명이 이틀 동안 디버깅했습니다.
AI는 '참고자료'로만 활용하고, 검증/리뷰 프로세스 강화해야 합니다."

운영팀이나 경영진에겐 비용과 리스크 관점에서 설명하는 게 효과적이다. 구체적인 시간 비용과 품질 영향을 숫자로 보여주면 더 설득력 있다.

실전 체크리스트

다음 체크리스트를 팀 내 가이드라인으로 활용해보자:

graph TD
    A["AI 코드 제안 활용 체크리스트"]

    subgraph SB1["코드 적용 전"]
        direction LR
        B1["• 실제 코드베이스와 일치?"]
        B2["• 참조된 클래스/함수 존재?"]
        B3["• 라이브러리 버전 호환성?"]
    end

    subgraph SB2["코드 적용 후"]
        direction LR
        C1["• 실제 동작 테스트"]
        C2["• 예외 상황 테스트"]
        C3["• 성능 영향 확인"]
    end

    subgraph SB3["PR/리뷰 시"]
        direction LR
        D1["• AI 활용 여부 명시"]
        D2["• 검증 결과 공유"]
        D3["• 집중 리뷰 요청"]
    end

    A --> SB1
    A --> SB2
    A --> SB3

이 체크리스트를 팀의 코드 리뷰 프로세스에 녹여내면 AI 도입으로 인한 삽질을 최소화할 수 있다.

결론: 현명하게 AI 부리기

LLM은 확실히 개발자 생산성을 올려주는 강력한 도구다. 하지만 그 특성과 한계를 제대로 이해하고, 적절한 가이드라인 세워서 활용해야 한다.

핵심 포인트는 이렇다:

1. AI는 “정답”이 아니라 “참고자료”다.
2. 검증 없는 AI 코드 도입은 결국 더 많은 시간을 잡아먹는다.
3. 팀 전체가 AI 활용 원칙을 공유하고 지켜야 한다.
4. 실제 코드와 렌더링 결과를 내 눈으로 확인하는 습관이 필수다.

이런 가이드라인을 문서화하고 정기적으로 팀원들이랑 경영진에게 상기시키는 게 AI 도입의 부작용을 최소화하는 가장 현실적인 방법이다. 필요하면 실제 삽질 사례(버그, 디버깅 시간, 품질 저하 등)를 숫자와 함께 정리해 공유하면 더 설득력 있다.

내가 AI랑 일하면서 깨달은 점은, AI는 훌륭한 협업자가 될 수 있지만 최종 책임은 항상 실무자에게 있다는 거다. AI 제안을 맹신하기보다는 실무자로서의 비판적 사고와 검증 과정을 통해 AI의 장점을 잘 활용하는 접근이 필요하다.