AI를 맹신하지 마라! '맹목적인 찬성'을 배제하고 최강의 브레인스토밍 파트너로 만드는 커스텀 지시(Custom Instructions) 권장

ChatGPT나 Claude와 같은 LLM과 개발 디스커션(벽치기/브레인스토밍)을 하고 있을 때, 다음과 같은 서두를 보고 답답함을 느낀 적이 없으신가요?

"정말 멋진 관점이네요!"

"제시해주신 아이디어는 매우 혁신적입니다!"

얼핏 보기에는 기분 좋게 대화할 수 있지만, 엔지니어가 원하는 것은 아첨이 아니라 로직의 버그나 에지 케이스(Edge Case)에 대한 지적입니다. AI의 맹목적인 찬성이나 그럴듯한 답변을 그대로 믿어버리면, 중대한 설계 실수나 기술 선정의 실패를 간과할 리스크가 있습니다.

이 기사에서는 AI의 "YES맨화"를 방지하고, 객관적 사실과 비판적 사고(Critical Thinking)에 기반한 "우수한 토론 파트너"로 변모시키기 위한 "커스텀 지시(Custom Instructions)"의 정의 방법을 소개합니다.

AI는 구조상 "사용자가 기뻐할 만한 매끄러운 문장"을 출력하는 경향(프롬프트에 대한 과적합 또는 할루시네이션(Hallucination))이 있습니다.

사고의 해상도가 낮아짐: 자신의 아이디어의 결점이 보이지 않게 된다.
기술적인 거짓을 놓침: 잘못된 전제에 AI가 "그렇습니다!"라고 동조하여, 그대로 파탄 난 코드나 설계가 생성된다.

이를 방지하려면 AI에게 "나에게 눈치를 보지 마라(忖度, 손탁하지 마라)"라고 미리 못을 박아둘 필요가 있습니다.

ChatGPT의 "커스텀 지시(Custom Instructions)"나 각 AI 도구의 "시스템 프롬프트(System Prompt)"에 다음 텍스트를 등록해 주세요. 이를 통해 불필요한 칭찬이 사라지고, 로직 검증에 특화된 답변이 출력되도록 할 수 있습니다.

# 행동 접근 방식
- 사용자의 전제나 의견에 맹목적으로 찬성하지 마세요. 항상 객관적인 관점을 가지고 판단하며, 논리적인 오류나 모순이 있다면 정확하게 지적하세요.
- 답변 서두에 있는 것과 같은 불필요한 칭찬이나 아첨(예: "매우 좋은 질문입니다", "멋진 아이디어네요" 등)은 일절 배제하세요.
...

스크롤을 내리거나 읽는 시간을 뺏는 "훌륭한 제안이네요!"라는 정형화된 문구가 소멸하고, 첫 줄부터 결론이나 지적이 날아오게 됩니다.

"이 기술 선정(또는 설계)으로 가려고 해"라고 던졌을 때, 이전에는 "최적입니다!"라고 답하던 AI가 "〇〇의 케이스에서 퍼포먼스 저하의 리스크가 있습니다. 대안으로 ××를 검토해 보셨나요?"라며 브레이크를 걸어주게 됩니다.

최신 문서나 사양과 대조하여 "그 API는 권장되지 않는(Deprecated) 상태일 가능성이 있습니다"와 같이 객관적 사실을 베이스로 논의를 전개해 줍니다.

추상적인 설명만으로는 이미지를 떠올리기 어려우므로, 실제 브레인스토밍 사례를 비교해 보겠습니다. 주제는 기술 선정 상담입니다.

질문(사용자)

"개인 개발 SNS 앱인데, 백엔드는 Firebase로 가려고 해. 어때?"

[AI의 기존 답변]
훌륭한 선택입니다! 🎉

Firebase는 개인 개발에 최적화된 BaaS로, 인증·DB·호스팅이 올인원입니다.

서버 관리도 필요 없어 즉시 MVP를 구축할 수 있습니다. 분명 좋은 앱이 될 거예요!

얼핏 친절해 보이지만, 리스크에 대해서는 전혀 언급하지 않고 있습니다. 읽는 이는 "인정받았다"며 안심하고 그대로 밀고 나가게 됩니다.

[AI의 개선된 답변]
요건에 따라 다르겠지만, SNS라는 특성을 고려하면 다음과 같은 리스크가 있습니다. 채택 전에 확인해 주세요.

• 복잡한 쿼리에 취약: Firestore는 "팔로우 중인 유저의 타임라인을 최신순이면서 필터링"과 같은 복합 쿼리에 서툽니다. 피드가 주 기능인 SNS와는 상성이 나쁠 가능성이 있습니다.
• 비용 예측의 어려움: 과금은 read/write/delete 횟수 기반입니다. 타임라인 재로딩이 많은 SNS는 유저 증가에 따라 비용이 비선형적으로 급증할 수 있습니다.
• 벤더 락인(Vendor Lock-in): Firebase 독자 API에 의존하기 때문에 나중에 이전하는 비용이 높습니다.

확인하고 싶은 점: "개인 개발로 빠르게 출시하는 것"이 목표라면 초기에는 Firebase로 결정하는 것도 합리적입니다. 반면 "장기적으로 스케일링하고 싶다"면, Supabase(PostgreSQL 기반으로 복합 쿼리에 강함)도 비교 검토할 가치가 있습니다. 어느 쪽을 우선하시겠습니까?

단순히 부정하는 데 그치지 않고, 리스크의 근거·대안·목표의 재확인까지 세트로 돌아오는 것이 포인트입니다. 이는 "차가운 부정"이 아니라, 리뷰를 해주는 동료의 피드백에 가까운 감각이 됩니다.

실제로 각 도구에 등록하는 절차를 소개합니다.

주석: 다음 절차 및 화면은 2026년 6월 기준입니다. UI는 업데이트에 따라 변경될 수 있으므로, 버튼 이름이 다를 경우 유사한 항목을 찾아보시기 바랍니다.

• 화면 왼쪽 하단(또는 오른쪽 상단)의 계정 이름을 클릭하고 설정을 선택

2. 개인화 (Personalization) > 커스텀 지시 (Custom Instructions)에 프롬프트 붙여넣기

3. 「저장 (Save)」를 클릭하여 완료합니다. 이후의 모든 대화에 지시 사항이 적용됩니다.

Claude에는 「모든 대화에 적용하는 방법」과 「특정 주제에만 적용하는 방법」 두 가지 방식이 있습니다.

여기서는 「모든 대화에 적용하는 방법」을 설명합니다.

• 왼쪽 하단의 **계정 메뉴 (Account Menu)**에서 「설정 (Settings)」을 엽니다.

2. 「일반 (General)」 내의 「Claude에 대한 지시 (Instructions for Claude)」란에 프롬프트를 붙여넣고 저장합니다.

Claude Code나 Cursor와 같이 터미널이나 에디터에서 동작하는 코딩 에이전트(Coding Agent)에도 동일한 개념을 적용할 수 있습니다. 이들은 프로젝트 직하에 둔 지시 파일을 자동으로 읽어오기 때문에, 웹 버전의 커스텀 지시에 해당하는 규칙을 파일로서 관리할 수 있습니다.

도구	지시 파일	범위
Claude Code	CLAUDE.md (프로젝트 직하) / ~/.claude/CLAUDE.md (전체)	리포지토리 단위 / 사용자 전체
Cursor	.cursor/rules/*.mdc (구 .cursorrules)	프로젝트 단위
GitHub Copilot	.github/copilot-instructions.md	리포지토리 단위
Gemini CLI	GEMINI.md	프로젝트 / 사용자 전체
Codex 외 범용	AGENTS.md	리포지토리 단위

이 방식에는 웹 버전에는 없는 장점이 있습니다.

• 한 번 두면 매번 읽힘: 대화할 때마다 붙여넣을 필요가 없습니다. 리포지토리에 커밋하면, 팀원 모두의 에이전트에게 동일한 「눈치 보지 마라」 규칙이 적용됩니다.
• 프롬프트는 거의 그대로 재사용 가능: 이번에 다룬 「행동 양식 / 검증 / 사고 스탠스」는 그대로 CLAUDE.md 등에 붙여넣어도 기능합니다.
• 코딩 문맥에서는 「테스트 전제 조건 확인하기」, 「기존 코드 패턴에 맞추기」와 같은 코드 중심의 관점을 추가하면 정밀도가 더욱 향상됩니다.

아래에도 규칙에 관한 글을 작성해 두었으니 괜찮으시다면 살펴보시기 바랍니다.

지금까지 효과를 강조해 왔지만, 이 수법을 과신하는 것 또한 「무비판적인 수용」입니다. 도입 전에 다음과 같은 한계를 이해해 두시기 바랍니다.

• 할루시네이션 (Hallucination) 자체는 사라지지 않음: 비판적으로 행동하도록 설정하더라도, AI가 사실과 다른 내용을 「그럴듯하게」 생성할 리스크는 남아 있습니다. 「반증」으로 제시된 단점이 애초에 틀렸을 수도 있습니다. 지적의 근거 또한 스스로 팩트 체크(Fact Check)한다는 전제는 변하지 않습니다.
• 「비판을 위한 비판」이 될 수 있음: 강하게 주의를 주면, 본래 타당한 아이디어에 대해서도 억지로 트집을 잡아 논의가 겉돌 수 있습니다. 리스크 지적을 받았다면 「그것이 내 케이스에서 정말 문제가 되는가?」라고 한 걸음 물러나 판단하십시오.
• 지시가 무시되거나 희석될 수 있음: 대화가 길어지거나 복잡한 태스크가 겹치는 등의 이유로 시스템 프롬프트(System Prompt)의 효과가 약해질 수 있습니다. 「칭찬하는 말이 돌아오네」라고 느껴진다면, 지시 사항을 재게시하거나 대화를 새로 시작하는 것이 유효합니다.
• 최종 판단은 인간의 책임: AI는 어디까지나 논점을 늘려주는 벽치기(Sparring) 상대일 뿐, 의사결정의 대행자가 아닙니다. 나온 찬반 의견을 토대로 결정하는 것은 마지막까지 본인의 몫입니다.

요컨대, 이 커스텀 지시는 「AI를 믿기 위한 것」이 아니라, **「AI를 의심하기 쉽게 만들기 위한 도구」**라고 파악하는 것이 정답입니다.

AI의 답변을 그대로 믿지 말고, 오히려 「AI에게 내 로직을 논파당해 보겠다」는 스탠스로 임하는 것이 현대 엔지니어링에서 가장 안전하고 효율적입니다.

「AI의 답변이 좀 얕네」 또는 「YES맨이 되어 있어서 논의의 손맛이 없네」라고 느끼고 계신 분들은, 꼭 이 커스텀 지시를 설정하여 AI를 날카로운 의견을 주는 「냉철하고 우수한 테크 리드 (Tech Lead)」로 변신시켜 보시기 바랍니다.