생성형 AI를 실무에 붙이면 대체로 세 가지 벽에 순서대로 부딪힙니다. 처음엔 “코드를 시켰더니 컴파일은 되는데 실제로는 안 돌아간다”, 익숙해지면 “물어볼 때마다 표현만 다르고 알맹이는 똑같다”, 마지막엔 “이걸 회사 업무 프로세스로 어떻게 정착시키지”입니다. 세 문제는 따로 노는 게 아니라 하나의 축으로 이어집니다. AI의 출력 품질은 모델의 똑똑함이 아니라, 사용자가 넣는 맥락의 밀도와 검증 절차의 촘촘함에 비례한다는 것입니다. 이 글은 그 축을 따라 AI 코딩의 실패 구조, 답변 다양성의 원리, 프롬프트 설계, 그리고 도구화(스킬·세컨드 브레인) 전에 반드시 점검할 것을 순서대로 정리합니다.
AI 코드가 ‘컴파일은 되는데 안 돌아가는’ 구조적 이유
AI가 짠 코드가 실패하는 근본 원인은 지능이 아니라 맥락(context)의 부족입니다. 대규모 언어모델은 공개 코드를 학습해 ‘가장 그럴듯한 다음 토큰’을 확률로 예측합니다. 그래서 인터넷에 수만 번 등장한 패턴(정렬 알고리즘, CRUD API 골격, 흔한 정규식)은 거의 완벽하게 뽑지만, 사내 라이브러리의 특정 버전, 자체 인증 방식, 실제 테이블 스키마, 팀의 예외 처리 규칙처럼 학습 데이터에 존재할 수 없는 고유 정보가 개입하는 순간 정확도가 급락합니다. 겉보기엔 문법이 맞아 컴파일까지 통과하지만, 그 함수가 실제 데이터·인접 모듈과 만나는 경계에서 조용히 깨지는 이유가 여기 있습니다.
실무에서 반복되는 실패는 세 유형으로 압축됩니다. 첫째 환각(hallucination)입니다. 존재하지 않는 함수명, 설치된 적 없는 패키지, 라이브러리에 없는 파라미터를 자신 있게 지어냅니다. 최근엔 AI가 자주 만들어내는 가짜 패키지명을 공격자가 실제로 등록해 악성코드를 심는 ‘슬롭스쿼팅(slopsquatting)’ 위험까지 보고될 정도라, 설치 전 패키지 실재 여부 확인은 선택이 아닙니다. 둘째 버전 시차입니다. 학습 시점상 2~3년 전의 폐기 예정(deprecated) 문법을 최신 정답처럼 제시합니다. 셋째 국소 최적화로, 요청한 함수 하나는 잘 짜지만 전체 아키텍처와의 정합성은 보지 못합니다. 대응은 세 가지로 명확합니다. ① 사용 중인 언어·프레임워크 버전을 프롬프트 첫 줄에 못박기(예: “Python 3.12, Django 5.0 기준”), ② 관련 파일·타입 정의·기존 코드 한두 개를 함께 붙여 맥락 주입하기, ③ 생성 코드는 예외 없이 실행·테스트로 검증한 뒤 머지하기. 흔한 오해는 “모델이 더 커지면 알아서 해결된다”는 기대입니다. 맥락 주입과 검증 루프가 없으면 모델 성능이 올라도 ‘어디서 틀렸는지 모르는 그럴듯한 오답’만 정교해질 뿐입니다.
답변이 매번 판박이인 건 모델이 아니라 질문 탓
“물어볼 때마다 교과서 같은 답만 온다”는 불만의 원인은 두 가지고, 둘 다 질문 쪽에 있습니다. 첫째, 질문이 추상적이면 모델은 확률적으로 가장 안전한, 즉 가장 평균적인 답으로 수렴합니다. “마케팅 아이디어 알려줘”에는 SNS 이벤트·인플루언서 협업 같은 최빈값이 나올 수밖에 없습니다. 둘째, 같은 조건에서는 출력 분포도 비슷하기 때문에, 제약과 관점을 바꿔주지 않는 한 표현만 살짝 다른 같은 내용이 계속 재생산됩니다.
다양성은 ‘운’이 아니라 질문 구조로 강제할 수 있습니다. ① 관점을 분리 지정합니다. “보수적 CFO 관점”, “신규 진입 경쟁사 관점”, “20대 실사용자 관점”으로 각각 3개를 따로 요청하면 서로 다른 축의 답이 나옵니다. ② 제약을 숫자로 겁니다. “예산 500만 원 이하, 2주 내 실행, 오프라인 채널만”처럼 조건을 좁힐수록 답은 뾰족해집니다. 조건을 하나 추가할 때마다 뻔한 후보가 통째로 탈락하기 때문입니다. ③ 금지 목록을 명시합니다(“할인 프로모션·SNS 이벤트 제외”). ④ 2단계로 나눕니다. 먼저 후보 10개를 얕게 나열시킨 뒤, 그중 상위 3개만 골라 심화 요청하면 발산과 수렴을 분리해 질이 올라갑니다. 대표적 함정은 온도(temperature) 같은 무작위성 파라미터만 0.7에서 1.0으로 올리면 다양해질 거라는 착각입니다. 그 값은 단어 선택의 변주 폭을 넓힐 뿐이라, 표현은 튀어도 관점은 그대로입니다. 진짜 다른 답은 파라미터가 아니라 질문의 뼈대를 바꿔야 나옵니다.
프롬프트 엔지니어링의 정체는 ‘코딩’이 아니라 ‘요구 정의’
프롬프트 엔지니어링을 특수한 프로그래밍 기술로 오해하기 쉽지만, 실체는 문제를 정확히 정의하고 필요한 맥락을 빠짐없이 전달하는 요구 정의 능력에 가깝습니다. 신입에게 일을 맡길 때 목적·배경·산출물 형식·기한을 정확히 줘야 결과가 좋아지는 것과 정확히 같은 원리입니다. 그래서 이 역량의 핵심은 “AI에게 말을 잘 거는 법”이 아니라 “내가 원하는 결과가 무엇인지 스스로 명료하게 아는 능력”이며, 이 점에서 개발자 전용 기술이 전혀 아닙니다.
바로 쓸 수 있는 프롬프트 골격은 다섯 요소입니다. ① 역할(누구로서 답할지), ② 목적·대상(왜 필요하고 최종 독자는 누구인지), ③ 구체 지시(무엇을, 몇 개, 어떤 기준으로), ④ 출력 형식(표/불릿/JSON/글자 수), ⑤ 예시(few-shot)로 원하는 톤과 수준을 1~2개 실제로 보여주기. 특히 잘 만든 예시 하나는 추상적 설명 열 줄보다 결과를 확실히 끌어올립니다. 모델이 규칙을 ‘해석’하는 대신 패턴을 ‘모방’하기 때문입니다. 초보자가 가장 자주 하는 실수는 첫 응답에서 완성품을 기대하는 것입니다. 실제 정석은 첫 답을 초안으로 받고 “3번 항목에 수치 근거 추가”, “두 번째 문단을 절반 길이로”처럼 대화형으로 좁혀가는 반복 편집입니다. 프롬프트는 한 방의 주문이 아니라, 초안→피드백→수정으로 굴러가는 편집 공정에 가깝습니다.
클로드 스킬·세컨드 브레인으로 확장하기 전 점검할 3가지
단순 질의응답을 넘어, 반복 작업을 규칙으로 묶는 ‘스킬’이나 개인 지식을 축적하는 ‘세컨드 브레인’으로 AI를 확장하려는 시도가 늘고 있습니다. 스킬은 자주 쓰는 절차와 판단 기준을 미리 정의해 두고, 매번 긴 프롬프트를 다시 쓰는 대신 일관된 품질의 결과를 반복해서 얻으려는 개념입니다. 회의록 요약, 보고서 포맷 변환, 코드 리뷰 체크리스트처럼 형식과 기준이 고정된 반복 작업일수록 효과가 크고, 반대로 매번 판단이 달라지는 창의 업무에는 이득이 작습니다. 즉 ‘자동화 가치 = 반복 빈도 × 규칙의 안정성’으로 판단하면 어디에 스킬을 걸지 우선순위가 정리됩니다.
확장 전 점검할 것은 세 가지입니다. 첫째 데이터 정리입니다. 흩어진 메모·문서를 폴더·태그·제목 규칙으로 먼저 구조화하지 않고 원자료를 그대로 넣으면, 검색·요약 품질이 그만큼 떨어집니다. 잘못된 입력이 잘못된 출력으로 이어진다는 원칙은 AI 시대에도 그대로 유효합니다. 둘째 보안 경계입니다. 사내 기밀·고객 개인정보를 외부 AI에 입력하는 순간 그 데이터의 통제권을 잃을 수 있으므로, 어떤 데이터까지 입력을 허용할지 조직 정책으로 먼저 선을 그어야 합니다. 이는 개인 취향이 아니라 규정 준수의 문제입니다. 셋째 유지보수입니다. 스킬과 자동화도 코드처럼, 참조하는 규칙·양식·API가 바뀌면 조용히 오작동하므로 최소 분기 단위 점검 주체와 주기를 정해둬야 합니다. 6개월~2년 관점에서 보면 이런 도구는 개인의 작업 방식을 바꾸는 데 그치지 않고 팀의 표준 프로세스로 흡수될 가능성이 높습니다. 그래서 지금 갖춰야 할 건 화려한 기능 사용법이 아니라 검증·보안·데이터 정리라는 기본기이며, 이 기본기가 없는 자동화는 속도를 높이는 게 아니라 실수를 자동화합니다.
자주 묻는 질문
AI가 짠 코드를 그대로 프로덕션에 배포해도 되나요?
권장하지 않습니다. AI 코드는 존재하지 않는 함수·패키지를 지어내거나(환각) 2~3년 전 폐기 예정 문법을 최신처럼 제시하는 경우가 있어, 사람 리뷰와 테스트 실행 검증을 반드시 거쳐야 합니다. 프롬프트에 언어·프레임워크 버전과 관련 파일·타입을 함께 넣고, 설치 전 패키지 실재 여부까지 확인하면 실패 대부분을 앞단에서 걸러낼 수 있습니다.
프롬프트 엔지니어링은 개발자만 배우면 되나요?
아닙니다. 본질은 문제를 정의하고 맥락을 전달하는 요구 정의 능력이라 기획·마케팅·사무 등 모든 직무에 적용됩니다. 역할·목적/대상·구체 지시·출력 형식·예시라는 다섯 요소만 갖춰도 결과가 눈에 띄게 좋아지며, 여기에 잘 만든 예시 하나를 붙이는 것이 설명을 길게 늘어놓는 것보다 효과적입니다.
AI 답변이 계속 비슷하게 나올 때 가장 빠른 해결책은?
질문 구조를 바꾸는 것입니다. 관점을 나눠 각각 요청하고(예: CFO/경쟁사/실사용자), 예산·기간·채널을 숫자로 좁히고, 흔한 답을 명시적으로 제외하세요. 온도 같은 무작위성 파라미터만 올리면 표현만 달라질 뿐 관점은 그대로입니다. 후보 10개를 먼저 뽑고 3개만 심화하는 2단계 방식도 효과적입니다.
클로드를 세컨드 브레인으로 쓰려면 뭐부터 준비해야 하나요?
데이터 정리가 먼저입니다. 메모·문서를 폴더·태그 규칙으로 구조화하지 않으면 검색·요약 품질이 그만큼 낮아집니다. 이어서 사내 기밀·개인정보의 입력 허용 경계를 조직 정책으로 정하고, 참조 규칙이 낡으면 오작동하므로 분기 단위 점검 주체와 주기까지 정한 뒤 도입하는 것이 안전합니다.