02강: IT 현업을 위한 초기 세팅: 프로젝트(Projects) 기능을 통한 도메인 지식 주입

SECTION 1. IT 실무 최적화: 왜 클로드인가? (입문)
 
• 01강: 챗GPT 대신 클로드를 선택해야 하는 이유 (아티팩트 & 20만 컨텍스트)
• 02강: IT 현업을 위한 초기 세팅: 프로젝트(Projects) 기능을 통한 도메인 지식 주입
• 03강: 프롬프트 엔지니어링 기초: IT 논리 구조를 반영한 지시 기법

SECTION 2. QA & 테스터를 위한 AI 전략 (심화)
 
• 04강: [QA] 요구사항 명세서 기반 완벽한 테스트 케이스(TC) 자동 생성
• 05강: [QA] 복잡한 데이터 흐름 분석 및 경계값 테스트 시나리오 도출
• 06강: [QA] 셀레늄/플레이라이트(Playwright) 자동화 스크립트 작성 및 오류 수정

SECTION 3. 개발 & 시스템 설계를 위한 AI 활용 (심화)
 
• 07강: [Dev] 레거시 코드 리팩토링 및 신규 라이브러리 마이그레이션 가이드
• 08강: [Dev] 에러 로그 분석을 통한 근본 원인(Root Cause) 파악 및 디버깅
• 09강: [Design] 머메이드(Mermaid)를 활용한 시퀀스 다이어그램 및 DB 설계도 그리기

SECTION 4. MCP와 자동화 에이전트로 가는 길 (실전)
 
• 10강: MCP(Model Context Protocol) 개념과 IT 도구(Notion/GitHub/Jira) 연동
• 11강: Sequential Thinking(심층 사고) 모드로 복잡한 비즈니스 로직 검증하기
• 12강: 클로드 코드(Claude Code) 입문: 터미널에서 제어하는 AI 주도 개발(ADC)

 

---

 

새 대화창을 열 때마다 같은 배경 설명을 다시 붙여넣고 계신가요. 그 지긋지긋한 반복을 단 한 번의 세팅으로 끝내는 방법을 화면 너머 디테일까지 짚었습니다.

 

지난 1강에서 우리는 클로드의 넓은 작업대, 곧 긴 맥락이 어떻게 흐트러지지 않는지를 살펴봤습니다.

 

그런데 막상 현업에 가져와 쓰다 보면 한 가지 벽에 부딪힙니다.

 

그 넓은 작업대가, 대화창을 닫는 순간 깨끗이 비워진다는 점입니다.

 

어제 우리 팀의 네이밍 규칙을 일러둔 그 대화는, 오늘 아침이면 남의 일이 되어 있습니다.

 

결국 매번 같은 배경을 다시 설명하느라 하루의 첫 십오 분을 흘려보내게 됩니다.

 

 

매일 아침 회사 소개부터 다시 시키던 외주 개발자

실력 있는 외부 인력을 데려왔다고 상상해 보겠습니다.

 

다만 이 사람은 퇴근하면 그날의 기억을 전부 지운 채, 다음 날 다시 출근합니다.

 

우리가 어떤 프레임워크를 쓰는지, 변수 이름은 어떤 규칙으로 짓는지, '정산'이라는 단어가 우리 회사에선 무슨 뜻인지를 매일 처음부터 일러줘야 합니다.

 

능력은 충분한데, 맥락이 휘발됩니다.

 

기본 대화창의 클로드가 딱 그렇습니다.

 

머리는 더없이 영민하지만, 우리 조직의 사정은 그 한 번의 대화 안에서만 살아 있습니다.

 

그래서 많은 실무자가 사내 위키 링크, 컨벤션 문서, ERD 캡처를 메모장에 모아두고 대화를 시작할 때마다 복사해 붙여넣습니다.

 

이 비효율을 구조적으로 끊어내는 장치가 바로 프로젝트(Projects) 기능입니다.

 

매일 새로 교육하는 대신, 한 번 가르쳐 두면 계속 기억하는 전용 작업 공간을 내주는 셈입니다.

 

 

프로젝트가 평범한 대화창과 갈라지는 결정적 지점

프로젝트는 하나의 서비스, 하나의 팀을 위한 독립된 방 같은 공간입니다.

 

그 방 안에서 시작한 모든 대화는, 같은 배경지식과 같은 규칙을 미리 공유한 상태로 출발합니다.

 

핵심은 두 개의 기둥입니다.

 

하나는 영구적인 자료 창고인 '프로젝트 지식', 다른 하나는 행동 지침을 붙여 두는 '커스텀 인스트럭션'입니다.

 

이 둘을 어떻게 채우느냐가 활용도의 8할을 가릅니다.

 

참고로 프로젝트는 무료 요금제에서도 만들 수 있습니다.

 

일단 가볍게 만들어 본 뒤, 자료가 쌓이고 손에 익으면 유료 요금제로 넘어가는 흐름을 권합니다.

 

 

지식 창고에는 '코드'가 아니라 '판단의 근거'를 채운다

여기서 흔한 오해가 하나 있습니다. 지식 창고를 그저 소스 코드 백업 용도로 쓰는 것입니다.

 

정작 효과가 큰 자료는 클로드가 스스로 판단할 때 근거로 삼을 문서들입니다.

 

신입에게 코드 한 뭉치를 던지는 게 아니라, 사내 매뉴얼과 용어 사전을 함께 쥐어주는 것에 가깝습니다.

 

먼저 우리 팀의 코딩 컨벤션과 설계 결정 기록을 올려두면, 답변이 뜬구름 잡는 일반론에서 벗어나 우리 코드의 결을 따라옵니다.

 

이어서 API 명세서, ERD, 그리고 외부인에겐 외계어처럼 보이는 사내 용어집을 넣어 둡니다.

 

가령 결제 모듈 ERD 이미지를 한 장 올려두면, 이후 어떤 대화에서든 클로드는 추측이 아니라 실제 테이블명과 컬럼명을 정확히 짚어 답합니다.

 

특히 인상적인 활용은 과거 장애 보고서나 회고 문서를 함께 넣어두는 방식입니다.

 

그러면 새 기능을 검토할 때 "예전 정산 배치에서 났던 그 문제와 같은 결의 위험이 보인다"는 식으로, 우리 조직의 흉터까지 기억하는 동료처럼 굴기 시작합니다.

 

자료가 한 작업대에 다 못 올라갈 만큼 쌓여도 걱정할 필요는 없습니다.

 

책장이 가득 찬 서재에서 필요한 책만 쏙 뽑아 펼치는 사서처럼, 클로드가 그때그때 필요한 대목만 꺼내 참조합니다.

 

다만 창고는 가볍게 유지하는 편이 낫습니다.

 

느슨하게 관련된 문서를 잔뜩 욱여넣으면, 정작 중요한 자료를 찾아내는 힘이 흐려집니다.

 

명세가 바뀌면 옛 문서는 지우고 갱신하세요. 낡은 지식은 없는 지식보다 위험합니다.

 

 

커스텀 인스트럭션, 답변의 결까지 정해두는 조용한 손잡이

지식 창고가 '무엇을 아는가'를 채운다면, 커스텀 인스트럭션은 '어떻게 행동할 것인가'를 정합니다.

 

알바 첫날 벽에 붙어 있는 '우리 가게 규칙' 메모 같은 것입니다.

 

좋은 지침은 대개 네 가지를 담습니다.

 

나의 역할, 이 프로젝트의 목적, 답변의 어조와 형식, 그리고 항상 지켜야 할 규칙입니다.

 

예를 들어 "너는 우리 백엔드 팀의 시니어 리뷰어다. 답은 결론부터 말하고 근거를 뒤에 붙여라. 프레임워크를 갈아엎자는 제안은 하지 마라" 정도로 박아두면, 매 대화가 이미 우리 쪽을 향해 정렬된 채 시작됩니다.

 

여기서 한 가지 구분해 둘 점이 있습니다.

 

계정 전체에 따라붙는 프로파일 설정과, 이 프로젝트 안에서만 작동하는 인스트럭션은 층위가 다릅니다.

 

전자가 '나는 누구이고 어떻게 일하는 사람인가'라는 명함이라면, 후자는 '이 방에서 우리는 무엇을 다루는가'라는 안내문입니다.

 

이미 프로파일에 적어 둔 습관을 프로젝트마다 또 옮겨 적을 필요는 없습니다.

 

같은 빈 창고가, 무엇을 올리느냐에 따라 다른 전문가가 된다

프로젝트의 진짜 위력은 직무에 맞춰 자료를 조율할 때 드러납니다.

 

QA·테스터라면 요구사항 명세서와 과거 결함 리포트, 테스트 케이스 양식을 창고의 중심에 둡니다.

 

그러면 새 명세를 던졌을 때, 클로드가 정의되지 않은 경계값이나 빠진 예외 흐름을 먼저 집어내며 검증의 출발선을 앞당겨 줍니다.

 

개발자라면 코딩 컨벤션과 시스템 구조도, 핵심 모듈의 README를 올려둡니다.

 

리팩토링이나 신규 라이브러리 검토를 맡길 때, 답변이 우리 코드의 실제 패턴을 전제로 흘러가는 차이를 곧바로 체감하게 됩니다.

 

기획자라면 서비스 기획서, 정책 문서, 그리고 앞서 말한 용어집이 핵심 자산입니다.

 

모호하게 쓴 요구사항을 던져 두고 "개발자가 오해 없이 읽도록 다듬어 달라"고 하면, 클로드가 우리 도메인 어휘를 그대로 살려 정교한 명세로 바꿔 놓습니다.

 

 

한 번의 세팅이 복리로 쌓이면, 대화는 늘 본론부터 시작된다

프로젝트를 처음 만들면 지침이 완벽할 리 없습니다.

 

서너 번 대화를 나눠 보면 클로드가 자꾸 되묻는 지점, 반복해서 헛다리 짚는 대목이 눈에 들어옵니다.

 

신입을 가르치듯, 그때마다 인스트럭션을 한 줄씩 손보고 빠진 문서를 한 건씩 채워 넣으면 됩니다.

 

이 작은 손질이 복리처럼 불어나는 순간, 더는 배경을 설명할 필요가 없어집니다. 대화창을 열면 곧장 본론으로 들어갑니다.

 

도메인 지식을 통째로 심어 둔 작업 공간이 주는, 생각보다 묵직한 일상의 변화입니다.

 

다음 3강 예고

잘 차린 작업 공간을 만들었다면, 이제는 그 안에서 클로드에게 '어떻게 말을 거느냐'가 결과를 가릅니다.

 

다음 3강 「프롬프트 엔지니어링 기초」에서는, IT 실무의 논리 구조를 그대로 지시문에 옮기는 감각을 다룹니다.

 

막연한 요청 대신 조건과 제약, 출력 형식을 분리해 설계하는 법을 함께 잡아보겠습니다.

 

※ 본 강좌는 매일 1강씩 무료로 연재됩니다. 요금제별 기능과 한도는 모델·플랜에 따라 달라질 수 있으니, 실제 적용 시 최신 안내를 확인하시기 바랍니다.