일상 업무에서 LLM을 효과적으로 사용하는 방법 — 실무 튜토리얼

1. 개발 업무를 위한 핵심 원칙

• LLM은 산출물(Artifacts)을 변환하고 반복하는 데 가장 뛰어납니다 (요구사항 → 설계, 설계 → 코드, 코드 → 테스트, 코드 → 문서).
• "내 시스템 전체를 구축해줘"라는 요청보다는 작고 집중된 프롬프트(Prompt)를 사용할 때 더 나은 결과를 얻을 수 있습니다.
• "똑똑해 보이는" 텍스트를 그대로 믿기보다는 항상 구조화된 검토(정렬, 정확성, 완전성, 리스크)를 거쳐 출력을 확인하십시오.

연습 문제:

다음에 작업이 막혔을 때, "이 기능 전체를 작성해줘"라고 하는 대신 다음과 같이 질문해 보세요: "여기서 누락된 산출물(요구사항/설계/코드/테스트/문서)은 무엇인가?" 그런 다음 모델에게 해당 산출물만 요청하십시오.

2. 실제로 도움이 되는 프롬프트 패턴

소프트웨어 엔지니어링(Software Engineering)에 특히 유용한 몇 가지 프롬프트 패턴이 있습니다.

a) "당신은 X입니다" 역할 프롬프트 (Role Prompts)

모델에게 역할, 제약 조건, 그리고 출력 형식을 부여하십시오.

패턴

당신은 {도메인} 팀의 시니어 {언어/프레임워크} 엔지니어입니다.

목표: {하나의 명확한 목표}.

제약 조건: {표준, 스택, 제한 사항}.

출력: {글머리 기호 목록, 코드 블록, 체크리스트 등}.

예시 (백엔드)

당신은 핀테크 백엔드 팀의 시니어 TypeScript 엔지니어입니다.

목표: 실패한 결제를 재시도하기 위한 안전한 설계를 제안하십시오.

제약 조건: Node 20, PostgreSQL, 외부 큐(Queue) 사용 금지.

출력: 간략한 아키텍처 설명, 그 다음 재시도 로직을 위한 의사코드(Pseudocode).

연습 문제:

현재 진행 중인 작업을 가져와서 다음 AI 질문을 이 패턴으로 다시 작성해 보세요. 평소에 사용하던 "일상적인" 프롬프트와 출력 품질을 비교해 보십시오.

b) 원자화된 (단일 목적) 프롬프트 (Atomized Prompts)

업무를 아주 작은 단계로 나누십시오: 하위 작업 하나당 프롬프트 하나를 사용합니다.

다음 대신:

NestJS에서 JWT를 사용하여 전체 인증 시스템을 구축하고 테스트를 작성해줘.

다음과 같은 체인(Chain)을 사용하십시오:

1. “이 앱 설명을 바탕으로, 내가 해결해야 할 인증 관련 사항들을 나열해줘.”
2. “인증을 위한 데이터 모델과 엔드포인트(Endpoints)를 설계해줘.”
3. “내 스타일 가이드를 사용하여 로그인 엔드포인트에 대한 NestJS 코드만 생성해줘: …”
4. “Jest를 사용하여 이 로그인 엔드포인트에 대한 단위 테스트(Unit tests)를 생성해줘.”

이것이 바로 “작업 분해(Task decomposition)” 또는 “분해된 프롬프팅(Decomposed prompting)”입니다.

연습 문제:

이번 주에 해야 할 실제 작업 중 하나를 선택하세요. 문제 해결부터 작동하고 테스트까지 완료된 코드에 도달하기 위한 5~8개의 프롬프트 목록을 작성해 보세요. 하나의 거대한 프롬프트(Mega-prompt)를 사용하는 대신, 이들을 순차적으로 사용해 보세요.

c) “비평가(Critic)” 및 “심판(Referee)” 프롬프트

모델에게 무언가를 처음부터 만들라고 하는 대신, 무언가를 공격하거나 검토하도록 요청하세요.

패턴

• 코드 리뷰 (Code review):

엄격한 코드 리뷰어 역할을 수행해줘. 이 코드와 다음 표준들을 바탕으로, 구체적인 문제점과 제안된 변경 사항을 나열해줘.

• 설계 비평 (Design critique):

시스템 아키텍트(System architect) 역할을 수행해줘. 여기 내 설계안이 있어. 확장성 리스크(Scaling risks), 장애 시나리오(Failure scenarios), 그리고 불분명한 책임 소재를 식별해줘.

GitHub Copilot의 가이드라인도 본질적으로 이와 같습니다. AI가 코드 조각을 검토하고 개선 사항을 제안하게 하되, 무엇을 수용할지는 여전히 사용자가 결정하는 것입니다.

연습 문제:

최근 작성한 PR(Pull Request) 중 하나(또는 단순화된 버전)를 붙여넣고 다음과 같이 물어보세요:

“엄격한 리뷰어 역할을 수행해줘. 가장 중요한 5가지 문제점(정확성, 가독성, 성능, 보안)은 무엇인가요?”

그런 다음, 실제로 어떤 코멘트를 반영할지 결정하세요.

d) 자기 점검 / 성찰(Self-check / reflection) 프롬프트

모델이 생성한 자신의 출력물에 대해 다시 질문하세요:

네 마지막 답변을 다시 읽어봐. 최소 3가지의 잠재적인 오류, 누락된 엣지 케이스(Edge cases), 또는 안전하지 않은 가정을 식별해줘. 그리고 구체적인 수정 방안을 제안해줘.

이는 품질을 향상시키는 것으로 증명된 “내성적(Introspective)” 프롬프트 패턴을 활용하는 것입니다.

연습 문제:

마음에 드는 긴 답변을 얻었다면, 항상 위와 같은 자기 점검 프롬프트를 이어서 사용하고 결과를 비교해 보세요.

3. 작업 분해(Task decomposition): 언제, 어떻게 하는가

LLM에게 기능 전체를 구축하도록 시도하는 것은 대개 취약하고 테스트 불가능한 코드를 생성합니다. 대신, 산출물(Artifacts)과 복잡도에 따라 작업을 분해하세요.

좋은 분해 축 (Good decomposition axes)

• 산출물(Artifact) 기준: 요구사항(requirements) → API 명세(API spec) → 데이터 모델(data model) → 엔드포인트 스텁(endpoint stubs) → 구현(implementation) → 테스트(tests) → 문서(docs).
• 복잡도(complexity) 기준: 순수 함수(pure functions)를 먼저, 그다음 통합(integration), 마지막으로 UX / 와이어링(wiring).
• 리스크(risk) 기준: 코딩을 시작하기 전에 모델에게 위험한 영역(동시성(concurrency), 인증(auth), 실패 모드(failure modes))을 별도로 탐색하도록 요청하세요.

작업 분해(task decomposition)에 관한 한 블로그에서는 정확히 이 점을 보여줍니다. “이 기능 전체를 수정해줘”라고 말하는 대신, 디버깅을 “이 에러 메시지의 원인이 무엇인가?” 및 “auth.js에서 무엇을 변경해야 하는가?”와 같이 집중된 질문으로 분해합니다.

예시 시퀀스 (버그 수정)

1. “여기 실패한 테스트와 에러 메시지가 있습니다. 무엇이 잘못되고 있는지 요약해 주세요.”
2. “여기 auth.js가 있습니다. 이 실패와 관련이 있을 법한 줄(lines)을 지목해 주세요.”
3. “다른 동작을 변경하지 않으면서 테스트를 통과할 수 있는 최소한의 수정안을 제안해 주세요.”
4. “이 버그에 대한 회귀(regressions)를 잡아낼 수 있는 새로운 테스트를 생성해 주세요.”

연습:

실제 버그를 하나 가져오세요. 손을 대기 전에 이 네 가지 프롬프트를 사용해 보세요. 본인의 진단과 모델의 진단을 비교하고, 모델이 도움이 된 부분이나 혼란을 준 부분을 기록하세요.

4. ChatGPT, Claude, Gemini 중 선택하기

다양한 모델을 도구 벨트(tool belt)에 들어있는 도구처럼 취급하여, 작업에 따라 선택할 수 있습니다.

실무자들이 보고하는 일반적인 사용 패턴은 다음과 같습니다:

• **헤비 코딩 및 리팩터링 (heavy coding and refactoring)**을 위한 모델 (종종 Claude 또는 코드에 최적화된 ChatGPT).
• **심층 연구 및 추론 (deep research and reasoning)**을 위한 모델 (종종 ChatGPT의 더 높은 "사고(thinking)" 모드).
• API 사용, 브라우징, 또는 컨텍스트 내 코드 작업과 같은 **멀티모달(multi-modal) 또는 도구 중심 작업 (tooling-heavy tasks)**을 위한 모델 (종종 Gemini 또는 플러그인을 사용하는 ChatGPT).

전형적인 "도구 벨트" 접근 방식은 브레인스토밍이나 아이디어 생성을 위해 가장 빠른 모델로 시작한 다음, 구조를 잡고 정교화하기 위해 더 느리고 신중한 모델로 넘어가는 것입니다.

실무자 사례:

한 아키텍트는 Claude가 대규모 코드베이스에서 작업할 수 있도록 Gemini를 Claude와 연결하여 사용하고, 더 무거운 코딩 작업과 반복적인 정교화에는 Claude 자체를 사용합니다. 하지만 여전히 모델에게 "완전한 제품을 설계해줘"라고 요청하지는 않습니다.

연습:

다음과 같이 자신만의 소규모 "LLM 플레이북 (playbook)"을 작성해 보세요:

• "ChatGPT는 다음을 위해 사용한다: ..."
• "Claude는 다음을 위해 사용한다: ..."
• "Gemini는 다음을 위해 사용한다: ..."

그 다음, 일주일 동안 이를 반드시 따르려고 노력하고, 실제로 효과가 있었던 내용을 바탕으로 플레이북을 조정하세요.

5. 전문가처럼 AI 생성 코드 리뷰하기

AI를 타자 속도는 매우 빠르지만 과도하게 자신감이 넘치는 주니어 개발자(junior dev)라고 생각하세요. 당신의 역할은 리뷰하는 것입니다.

리뷰 체크리스트 (실제 가이드라인 기반 수정)

GitHub는 AI 코드가 컴파일(compile)되고, 테스트를 통과하며, 당신의 요구사항 및 패턴과 일치하는지 확인하라고 제안합니다. 더 광범위한 "리뷰어 모드 (reviewer-mode)" 체크리스트에는 정렬(alignment), 정확성(accuracy), 완전성(completeness), 그리고 리스크(risk)가 추가됩니다.

스스로에게 다음과 같이 질문해 보세요:

1. 정렬 (Alignment) - 이것이 내가 실제로 요청한 문제를 해결하는가? 아니면 그저 근처에 있는 무언가를 해결하는가?
2. 정확성 (Accuracy) - 라이브러리 호출(library calls), 타입(types), 그리고 API가 실제 존재하며 올바르게 사용되었는가? (필요에 따라 문서를 확인하세요.)
3. 완전성 (Completeness) - 중요한 엣지 케이스(edge cases), 오류, 그리고 검증(validations)이 포함되어 있는가?
4. 리스크 (Risk) - 이것이 보안 취약점, 데이터 손실, 레이스 컨디션(race conditions), 또는 성능 문제를 유발할 수 있는가?

연습:

AI가 생성한 파일 하나를 가져오세요. 위의 네 가지 차원 각각에 대해, (PR에서 하는 것처럼) 1~2개의 구체적인 코멘트를 작성해 보세요. 오직 그 후에 무엇을 남길지 결정하세요.

6. 판단력을 날카롭게 유지하기

AI를 과도하게 사용할 때의 위험은 "사고의 외주화 (outsourcing thinking)"입니다. 이는 명시적으로 평가를 연습함으로써 피할 수 있습니다.

"리뷰어 모드"에 관한 2026년 기사에서는 다음과 같이 제안합니다: 말투를 걷어내고 오직 로직(logic)과 가정(assumptions)만을 검사하세요. 그리고 질문하세요:

• 이 코드는 어떤 가정을 하고 있는가? 그 가정은 명시되어 있는가, 아니면 숨겨져 있는가?
• 만약 동일한 구조를 다른 사실 관계에 적용한다면, 여전히 설득력 있어 보이지만 틀린 결과가 나올 수 있는가?
• 내가 주니어 동료로부터 이 코드를 수정 없이 그대로 받아들일 수 있는가? 만약 그렇지 않다면, 무엇을 수정하라고 요청하겠는가?

구체적인 습관

• 사소하지 않은 모든 AI 제안에 대해서는 항상 한 번의 정렬 확인 (alignment check), 한 번의 정확도 확인 (accuracy check), 그리고 한 번의 리스크 확인 (risk check)을 수행하십시오.
• 주기적으로 AI 없이 먼저 문제를 해결한 다음, 자신의 기술을 교정하기 위해 AI의 접근 방식과 비교해 보십시오.
• 자신의 코드에 있는 개념을 설명하는 데 AI를 사용하십시오: "이 함수를 한 줄씩 설명하고, 내가 어떻게 하면 이 코드를 망가뜨릴 수 있을지 알려줘." 이는 주도권 (agency)을 포기하지 않으면서도 이해의 공백을 드러낼 수 있는 방법입니다.

연습 문제:

이번 주에 AI의 답변 중 하나를 골라 마크다운 (markdown) 파일에 10분 동안 짧은 "리뷰"를 작성해 보십시오: 무엇이 좋았는지, 무엇이 틀렸는지, 무엇을 바꿀 것인지, 무엇을 배웠는지에 대해 작성합니다. 이것이 바로 AI 사용을 의도적인 연습 (deliberate practice)으로 전환하는 방법입니다.

7. 실제 프로젝트에서의 구체적인 사용 사례

실제 사례들은 다음과 같은 성공적인 패턴을 보여줍니다:

• 코드 초안 작성 후 리뷰를 통한 반복 (iteration): 인간이 아키텍처 (architecture)와 최종 결정을 제어하는 동안, LLM을 사용하여 코드 스니펫 (code snippets)을 제안하고, 작은 문제를 디버깅 (debug)하며, 리팩터링 (refactor)하는 방식입니다.
• 테스트 및 문서 작성에 AI 사용: 새로운 코드에 대한 단위 테스트 (unit tests)를 생성하고 주석으로부터 API 문서를 작성하여, 인간이 까다로운 로직과 설계에 집중할 수 있도록 합니다.
• 아키텍처 피드백: 구현하기 전에 ChatGPT나 Claude에게 솔루션을 제시하고 아키텍트 스타일의 비판을 요청하는 방식입니다.

미니 프로젝트 연습:

작은 기능 하나(예: "이 API에 속도 제한 (rate limiting) 추가하기")를 정하고, 각 단계에서 의도적으로 AI를 사용해 보십시오:

1. 요구사항 명확화 (LLM이 사용자 및 시스템 제약 조건을 나열하는 데 도움을 줌).
2. 설계 비판 (LLM이 당신의 설계를 공격함).
3. 스켈레톤 코드 (skeleton code) 생성.
4. 테스트 생성.
5. 문서 초안 작성.

각 단계마다, 마치 주니어가 작성한 것처럼 검토하고 수정하십시오.

8. 반복할 수 있는 연습 문제

다음은 주기적으로 반복할 수 있는 압축된 세트입니다:

1. 분해 연습 (Decomposition drill):

   • 아무 티켓(ticket)이나 하나 선택하십시오. 5~10단계의 LLM 상호작용 계획(무엇을 어떤 순서로 질문할 것인지)을 작성하십시오.
   • 계획대로 실행한 후, 다음 세 가지 사항을 기록하십시오: 도움이 된 점, 시간을 낭비한 점, 변경하고 싶은 점.

2. 프롬프트 패턴 연습 (Prompt‑pattern drill):

   • 하나의 작업에 대해 다음 순서로 시도해 보십시오: 역할 프롬프트 (role prompt) → 원자화된 프롬프트 (atomized prompts) → 비판 프롬프트 (critic prompt) → 자기 점검 프롬프트 (self‑check prompt).
   • 각 레이어를 추가했을 때의 효과를 비교하십시오.

3. 모델 선택 연습 (Model‑choice drill):

   • 동일한 초기 프롬프트를 사용하여 ChatGPT, Claude, Gemini로 동일한 문제를 해결해 보십시오.
   • 검토 체크리스트를 사용하여 각 출력을 평가하고, 해당 범주의 작업에 어떤 모델을 선호하는지 결정하십시오.

4. 레드팀 연습 (Red‑team drill):

   • LLM에게 당신이 까다롭다고 알고 있는 해결책을 요청하십시오.
   • 그 다음, 모델에게 자신의 해결책에서 결함을 찾아내라고 명시적으로 요청하십시오.
   • 모델이 놓친 문제 중 당신이 찾아낼 수 있는 것이 무엇인지 확인하십시오.

당신의 주요 기술 스택(예: “TypeScript/React”, “Java/Spring”, “Python/data”)을 알려주시면, 해당 스택에 특화된 예시 프롬프트와 연습 문제가 포함된 짧고 구체적인 “훈련 계획”으로 만들어 드릴 수 있습니다.

현재 주로 어떤 기술 스택과 종류의 업무(기능 개발, 백엔드 API, 데이터, DevOps 등)에 LLM을 사용하고 계신가요?

Rizwan Saleem — https://rizwansaleem.co