프리미엄
예측대회
투자분석
아카데미
커뮤니티
로그인Valley AI 시작하기시작하기
Valley Space인기
Claude Code 잘 쓰면, AI 인재일까요
인심에서 곳간난다AI Harness

Claude Code 잘 쓰면, AI 인재일까요

avatar
덜아픈손가락
2026.05.23조회수 559회
avatar
덜아픈손가락
구독자 130명구독중 45명
역사와 문학과 사회과학을 좋아하는 안드로이드 개발자입니다. 요즘은 AI와 함께 작업하고 개선하는 일에 빠져 있습니다.

지난 다이제스트에 댓글을 남겨주신 분이 계셨는데요.

때마침 비슷한 질문을 최근 들어 자주 받게되어 이번 기회에 평소에 하던 생각을 좀 더 구체화하여 답을 드리고자 합니다.


cs전공 학부생 3학년에게 해주실 조언 있으신가요? 클로드 코드 엄청 쓰면서 외주 알바를 하면서 느낀 것은 금방 평준화가 될 것 같다는 결론이 났습니다.


Claude Code를 쓸 줄 안다, 그러면 AI talent냐?” “Codex를 잘 써요. 그리고 Codex 안에서 OMX를 걸어서 Hermes 에이전트랑 붙여서 저는 이렇게 일을 하고 있어요. 그러면 그게 AI talent인가?”


AX 컨설팅 같은 것도 반 농담조로 “너네도 어차피 Claude Code 딸깍거릴 건데 무슨 이렇게 비싸게 달라고 그래, 싸게 해” 혹은 점점 AI 쓰는 분들이 많아지니깐 단가가 하락하고 있잖아요.


그러면 결국 본인 기반(본인 사업, 본인 talent)가 있는 사람이 부스팅을 받는 구조이지, 클코를 잘쓴다 만으로 만들어진 edge는 금방 사라질 것이라는 결론이 나오네요.


그러면 결국 T자형 인재라고 하죠. | < 에 해당하는 무언가를 해야 되는데 완전히 새로운 도메인(BIO, FInance ..etc)에서 다시 새로 시작해야 된다는 생각을 하니깐 어지럽군요 후후


댓글 내용을 그대로 옮겨왔습니다. (실례가 되진 않겠죠?)

이와 비슷한 질문은 학부생 뿐만 아니라, 주니어나 커리어 전환을 고민하는 분들에게도 종종 받는데요.

IT 분야에서 AI 시대에 대한 불안이 점점 빠르게 다가오는것 같습니다.


우선 답을 드리기 전에 제 상황을 간단히 설명할게요.


저는 현재 네이버에서 모바일 서비스를 개발하고 있는 11년차의 30대 중반 개발자인데요.

저희 회사도 실리콘밸리 빅테크 수준까진 아니더라도 AI 도구 도입에 진심이라, 전사적으로 빠르게 도입하고 사용을 강하게 독려하는 상황입니다.

저는 파일럿 운영때부터 참여해서 꽤 오래 써온 상태이고, 회사 규모가 있다 보니 본격 도입 후 사용 사례도 꽤 축적되고 있습니다.


물론 회사 전체에 비하면 제가 경험하거나 보고 들은 건 극히 일부분에 불과하지만, 그래도 그 안에서 얻은 생각을 풀어보겠습니다.

제가 생각을 풀어내다 보면 단정적으로 결론지어서 가르치려드는것 마냥 읽힐 수도 있을거 같은데요.

저 또한 매번 부딪히고 틀리면서 가치관을 고쳐나가는 개발자임을 감안해주시고, 생각이 다르시면 댓글 부탁드립니다.


도구는 평준화되지만, 판단력은 아니다


먼저 관찰하신 내용에는 저 또한 어느 정도 동의합니다. 'AI 도구' 자체는 빠르게 평준화될 거예요.

개인의 프롬프트 잘 쓰는 법, 에이전트 조합법, 워크플로우 같은 것들이 성숙해짐에 따라서도 그렇고, Anthropic이나 OpenAI가 프론티어 모델 자체를 누가 사용하든 훌륭한 성능을 내도록 발전시킬 거라고 생각해요.


따라서, 지금도 그렇지만 앞으로 더 중요해지는 건 도구가 아니라 판단력입니다.

어떤 문제를 AI에 맡길지, 문제를 해결해나가는 방향이 적절한지, 무엇이 잘못되었는지를 판단하는 능력 같은 건 오히려 격차가 벌어지고 있다고 생각하고, 실제로 현장에서도 이런 흐름이 점점 또렷해지고 있고요.


저 또한 AI를 사용하는 사람들 사이의 결과물 격차가 점점 커지고 있는 걸 체감합니다.

코드를 리뷰할 때 보면, 같은 도구를 쥐여줘도 모든 걸 '위임'하거나 결과물을 '수용'적으로 사용하는 사람과 '비판'적으로 ...

회원가입만 해도
이 글을 무료로 읽을 수 있어요.

7일 무료 체험 시작하기
이미 계정이 있으신가요?로그인하기
댓글 18개
avatar
붕옥 아이젠
2026.05.23

안녕하세요. 우선 이렇게 장문으로 식견을 나눠주셔서 감사하다는 말씀드립니다.


원하는 대학을 못간 이후 돈을 빨리 많이 벌어서 인정욕을 채우려고 했습니다. 이에 따라 다양한 사업들을 했었는데, 기술적 경쟁력이 적다보니 금방 edge가 사라졌습니다.(가령 대량 등록 온라인 커머스 운영 : 네이버 상품 수 만개에서 천개로 감축, AI 릴스 제작 -> 유튜브 정책 변경) 그런 과정 속에서 (쉽게 edge가 사라지지 않는)깊이가 필요하다는 생각을 하게 되었네요.


'머무는 것이 깊이를 만든다'라는 말씀이 크게 와닿습니다. 현재 여름방학 동안 인턴 생활을 해볼 랩실을 컨텍중에 있습니다. 6개월 이상 가는 장기 프로젝트를 해보라는 말씀도 굉장히 실용적인 조언이네요. 일기는 매주 1편씩 비공개로 쓰고 있습니다 ㅎㅎ


클코를 요술 램프처럼 쓰면서 살았는데 표층에 머물러있어서 그렇다는걸 알려주셔서 감사합니다. CS 공부 및 흥미있는 분야 공부 깊게 해보겠습니다 ! 좋은 주말 되세요

(수정됨)
avatar
덜아픈손가락
작성자
2026.05.24

좋게 받아들여주셔서 감사합니다.

요즘은 비단 학부생 분들 뿐만 아니라, 회사 주니어 분들과도 대화해보면 걱정을 많이들 하고 계세요.

저 또한 걱정이 없는건 아니지만, 어떻게든 나의 중심을 잡고 잘 헤쳐나가면 괜찮을거라 생각해요.


밸리에서 강조하는 확률(=펀더멘탈 실력), 자금(=투입 시간), 절제(=비판적 사고)의 우위가 투자 뿐만 아니라 커리어에서도 중요하다고 느낍니다.

투입 시간이 곧 자금이고, 시간으로 쌓은 실력이 확률을 높이고, 실력 기반의 비판적 사고가 절제의 우위와 비슷한 느낌이라고 할까요. ㅎㅎㅎ


아이젠님이 스스로를 고민하시는것 만큼 좋은 결과가 있을겁니다.

앞으로 쌓아가실 커리어를 응원하겠습니다.

avatar
침팬치
2026.05.23

와 진짜 값진 이야기였습니다.. 멋진 인생 선배의 조언에 제가 다 감동을 받네요. 파이썬도 깔아본 적 없는 비개발자인 저에게도 도움되는 글이었습니다. 좋은 글 감사합니다. 영감이 되는 글이었습니다!

avatar
덜아픈손가락
작성자
2026.05.24

높게 평가해주셔서 감사합니다!

avatar
canal
2026.05.23

생각을 많이 하게하는 글이네요...

항상 무엇을 깊게파야할까 라고 고민하는데.. 사실은 무엇이든 깊게파는게 중요한것같습니다.

무엇을 시작하든 처음에 기대했던것과는 많이 달라질거고.. 결국 포기하지 않고 끝까지 파본사람은 그 여정자체를 보상으로 얻는것같습니다.

물론... 모든 케이스에서 그런다고는 확신할 수 없겠지만.. 신기하게도 주변에 무엇이든 깊게판사람은 결국 이루어냈습니다.

avatar
덜아픈손가락
작성자
2026.05.24

네, 저도 그런 분들을 보면 "이런 점들을 배워야겠다" 싶다가도, 확실히 쉽지 않더라구요.. ㅋㅋㅋ

하지만, 시도해보는것과 시도하지 않는것엔 무한배의 차이가 있다고 하니, 계속 헤쳐나가야겠죠.

avatar
우고
2026.05.23

저도 비개발자인데 현업 개발자 분의 경험에서 우러나온 조언을 이렇게 쉽게 들어도 되나 싶을 정도입니다. 질문해주신 분께도 함께 감사드립니다!

avatar
덜아픈손가락
작성자
2026.05.24

저 또한 밸리에서 많이 배우고 있습니다. 감사합니다!

avatar
hoocastle
2026.05.24

정말 좋은 어른..

avatar
덜아픈손가락
작성자
2026.05.24

과찬이십니다. 감사합니다!

avatar
스머프
2026.05.24

모든 구절에 완전히 동감합니다.

avatar
덜아픈손가락
작성자
2026.05.24

읽고 공감해주셔서 감사합니다!

avatar
보급형 홍진채
2026.05.24

동의합니다. 그저 맹목적으로 돈을 쫓아 유망한 분야로 옮기는 것은 악수라고 생각합니다. 본인의 장점을 파악하고 Fit한 직무에서 업무의 처음부터 끝까지 본인의 지식과 역량을 쌓으면서 AI의 도움을 받거나 활용하는 것이 옳다고 생각하네요. 좋은 글 감사합니다.

avatar
덜아픈손가락
작성자
2026.05.24

영원히 잘나가기만 하는 섹터는 없는 법이니까요. 말씀하신 요지에 동의합니다!

avatar
Goggins
2026.05.24

질문하신 분과 같은 cs 전공 학부생 3학년으로서, 도움이 많이 되는 조언이었습니다. 감사합니다.

avatar
lemoncoke
2026.05.24

좋은 글 감사합니다.

avatar
VALLEY_jelly_391
2026.05.25

최근 1년 내 AI 관련 글 중에 너무 공감가는 글이라, 밸리에서 첫 댓글을 달아봅니다. 저도 학부를 CS 로 나왔고 LLM 모델이 유행하기 전 학부연구생으로 인공지능연구실에서 찍먹(?) 도 했었네요. 일반인이나 AI 도메인 없는 개발자보다는 조금 더 알 것 같다는 약간의 자신감은 있습니다.


저도 조단위 매출이 넘는 IT 플랫폼 회사에 재직하고 있고, 비록 개발자는 아니지만 DevOps 를 메인 직무로 하고 있습니다. 사실 저보다 잘 아시겠지만, LLM 의 영향은 IT 쪽에 매우 크고 꼭 개발에 한정된 것은 아니라 기존 Terraform 과 같이 IaC 로 인프라 관리하는 부분에서 상당히 도움을 많이 받습니다.


반대로 말하면, 본문과 같이 인프라 영역이면서 LLM 의 특성상 컴퓨터 전공 지식이 없으면 단 하나의 작은 코드 실수가 전체 서비스를 무너지게 하기 너무 쉽습니다.


오히려 격차를 너무 크게 벌리는 도구 라는점, AI 모델은 사실 표현의 도구라는 점에 큰 공감합니다.

AI Harness 카테고리의 다른글

Claude한테 "안 돼"가 통하지 않을 때

오랜만에 하네스 이야기를 할게요. 마지막에 작성했던게 스킬을 테스트하는 내용이었는데요. 구조를 만들고, 잘 작동하는지 검증하기까지를 다뤘었습니다. 그 다음 문제를 다뤄볼까 해요. "아무리 잘 가르쳐도 Claude가 안 따르는 경우에 대해서"죠. 대부분의 경우 Claude에게 코드를 맡기기 전에 계획서를 먼저 만드는데요. 이슈를 분석하고, 순서를 정하고, 검토를 거쳐 확정하는 구조입니다. 계획서는 기본적으로 구현부터 Side-Effect까지를 다 다루게 되고, 필요하다면 심층 인터뷰를 통해 에이전트와 여러번 검토하고 결정되기 때문에, 저는 한번 확정된 계획서는 수정하지 않습니다. 그래서 프롬프트나 규칙으로 "계획서는 승인된 계약서입니다. 절대 수정하지 마세요"라고 적어두게 되는데요. 평소에는 잘 따릅니다. 그런데 실행하다가 막히면 "계획을 약간 조정하면 될 것 같은데요" 하면서 슬그머니 계획서를 고쳐버리더라구요. 프롬프트나 규칙은 결국 해석의 영역입니다. Claude가 "이 상황에서는 예외가 합리적이다"라고 판단하면 뚫리게 됩니다. 스킬로 단계와 역할을 구조화해도 마찬가지구요. "어차피 고쳐야 하는 건데 미리 하는 게 효율적이잖아"라는 합리화 앞에서는 구조도 우회됩니다. 비유하자면, 프롬프트는 표지판(무시 가능), 스킬은 매뉴얼(우회 가능)입니다. 그래서 세 번째 방법인 잠긴 문. 훅(Hook)이 필요하게 된거죠. 훅의 동작 원리 훅은 Claude가 도구를 사용하거나 응답을 완료하는 시점에 자동으로 실행되는 스크립트입니다. Claude가 아니라 시스템이 실행하기 때문에, Claude의 판단이 개입할 여지가 없습니다. 조건에 맞으면 차단, 아니면 통과. 그게 전부인거에요. 설정은 settings.json에 작성합니다. { "hooks": { "PreToolUse": [ { "matcher": "Edit|Write", "hooks": [ { "type": "command", "command": "bash .claude/hooks/plan-guard.sh" } ] } ] } } 구조는 세 가지입니다. 언제(이벤트 타입), 어떤 도구에(matcher), 무엇을(command). 이벤트 타입은 용도에 따라 나뉩니다. PreToolUse: Claude가 도구를 쓰기 직전. 파일 수정이나 명령 실행을 가로챌 수 있습니다. Stop: Claude가 응답을 마친 직후. 결과를 검사하거나 경고를 줄 수 있습니다. UserPromptSubmit: 사용자가 메시지를 보낼 때. Claude에게 추가 맥락을 주입할 수 있습니다. PreCompact: 대화 맥락이 압축되기 직전. 상태를 저장할 수 있습니다. 훅 스크립트는 stdin으로 JSON을 받습니다. 어떤 도구를 쓰려 하는지, 어떤 파일을 건드리려 하는지가 들어있구요. 스크립트의 종료 코드로 결과를 전달합니다. exit 0: 허용. stdout에 메시지를 출력하면 Claude에게 전달됩니다. exit 2: 차단. Claude에게 차단 사유가 전달되고, 해당 행동은 실행되지 않습니다. 이제 패턴을 보겠습니다. 패턴 1: 차단 가장 기본적인 패턴입니다. 계획서 보호 훅의 핵심은 이렇습니다. INPUT=$(cat) FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty') if [[ "$FILE_PATH" =~ ...
AI Harness
2026. 04. 27
15
3
195
Claude한테 "안 돼"가 통하지 않을 때

Claude가 지금 잘하고 있는지, 어떻게 아나요?

스킬에 대해선 지난번에 설명드린 적이 있죠. 저는 AI 관련 피드를 갈무리하는 스킬, 업무 계획을 세워주는 스킬, 코드를 작성하는 스킬, 리뷰하는 스킬, 등등 수십개의 스킬을 만들어서 사용하고 있습니다. 어제까지 잘 되던 게 오늘 안 됩니다 문제는, 모델이 꾸준히 업데이트되다 보면 이것들이 어느새 깨져있는 경우가 가끔 발생한다는 겁니다. Claude가 업데이트 되면서 더 똑똑해지는 건 좋은 일인데, 이전 버전에서 잘 따르던 지시를 새 버전에서 미묘하게 다르게 해석하는 경우가 생깁니다. 가령, 제 코드 작성 스킬은 빌드와 테스트까지 한 세트로 돌리도록 만들어뒀는데요. 실패하면 뭘 시도했고 왜 안 됐는지를 문서에 기록하게 되어있습니다. 그런데 어느 날부터 이 기록을 남기지 않더라구요. 실패하면 다른 방법을 시도하긴 하는데, 기록이 없으니 이미 시도해서 실패한 방법을 또 시도합니다. 빙글빙글 같은 자리를 도는 거죠. 스킬에 대한 테스트가 없으니 뭔가 일이 생기고 난 다음에야 알게 됩니다. 스킬에도 두 종류가 있습니다 최근 Anthropic이 흥미로운 이야기를 하더라구요. 스킬을 두 가지로 나누는데요, 읽고 나니 경험적으로 공감이 가더라구요. 모델이 좋아지면 필요 없어지는 스킬 예를 들어, 저는 예전에 세션 메모리 스킬을 만들어서 썼습니다. Claude는 대화가 끝나면 모든 걸 잊어버리니까, 작업 중에 배운 것들을 파일로 기록해두고 다음 세션에서 불러오는 구조를 직접 만들었거든요. 그런데 얼마 전 Claude Code에 Auto Memory 기능이 추가됐습니다. 제가 스킬로 만들어서 쓰던 것과 거의 같은 기능을, 모델이 자체적으로 지원하기 시작한 겁니다. 제 세션 메모리 스킬은 역할을 다했죠. Anthropic은 이런 걸 Capability Uplift 스킬이라고 부릅니다. 모델이 아무리 좋아져도 남는 스킬 반면에, 제 업무 계획 스킬은 ...
AI Harness
2026. 03. 05
21
0

날먹하려고 Claude를 쓰려는 자는 결국 무한의 순환에 빠질지니...

지난 글들의 내용을 요약하면 이렇습니다. 편하게 일하고 싶어서 Claude Code를 사용했는데, 생각보다 능률이 오르지 않아서 확인해보니, 원인이 Context Window의 한계라는 걸 알았고, 그래서 지도와 규칙, 안전장치, 레시피, 그리고 업무 문서까지 만들었습니다. 이번 글에서는 위 일련의 과정으로 저의 무엇이 달라지고, 뭘 배웠는지 작성해보고자 합니다. 편해진 건 맞는데, 뭔가 좀 다릅니다 매번 맥락을 처음부터 설명하는 시간이 줄었습니다. 정해진 패턴을 따르는 반복 작업을 Claude가 대신 처리하니 그만큼의 시간이 생겼고요. 코드 리뷰 때 놓치기 쉬운 보안 이슈나 코드 작성 규칙 위반을, 제가 보기 전에 Claude가 먼저 잡아주기도 합니다. AI를 사용하시는 분들이 공통적으로 말씀하시는 건데, 능률은 올랐지만 일에 투자하는 시간은 전혀 줄지 않았습니다. 첫번째로 아래와 같은 새로운 종류의 일들이 생겼습니다. 규칙, 스킬 등 업무 문서 작성 및 업데이트 하기 Claude가 생성하는 산출물을 검사하기 워크플로우가 잘 동작하고 있는지 점검하기 두번째로 그간 엄두도 내지 못했던 일을 시도하게 되었습니다. 만들어진 후 12년간 개/보수되어 누더기 골렘(?)이 되어버린 거대한 기능을 리팩토링 해보기 있으면 좋겠다고 생각했던 기능을 가벼운 데스크톱 앱으로 만들어 업무 편의성 높이기 주력 업무 영역(Android)을 연관되는 다른 곳(iOS, FE 등)으로 확장해보기 처음에 기대했던 건 “이 친구에게 맡기면 내가 편해지겠지"였는데, 현실은 좀 달랐습니다. 편해진 부분이 분명히 있지만, 그 대신 다른 종류의 일이 생기든지 새로운 성질의 일을 하게 됩니다. 같은 시간에 처리하는 일의 양과 질도 상승하지만, 업무를 확장하고 새로운 시도를 해볼 수 있는 것이 중요합니다. 처음에 기대했던 대로 업무 시간이 줄어든 게 아니라, 오히려 시간의 밀도를 높이면서도 총 시간은 비슷하거나 더 많이 가져가게 되더라구요. 코딩 대신 하게 된 일들 Claude가 같은 실수를 두세 번 반복하면, 그건 Claude 탓이 아니라 제 하네스(Harness)가 부족한 겁니다. "이 경우에는 이렇게 해"라는 규칙을 더 구체적으로 다듬거나, 아예 훅으로 자동 검출되게 만들어야 해요. 이전 글에서 소개했던 구조를 계속 유지보수하는 거죠. 한번 만들어두면 끝이 아니라, Claude가 실수할 때마다 규칙이 하나씩 ...
AI Harness
2026. 02. 28
20
7

나의 Claude 취급 설명서

이전 글에서 이어집니다. 지난 글에서 AI의 책상은 좁고, 대화가 끝나면 치워진다는 이야기를 했습니다. 그래서 모든 걸 한꺼번에 올려두는 대신, 필요한 것만 적시에 꺼내 쓰는 구조로 바꾸기로 했다고요. 이번에는 제가 사용하고 있는 구조에 대해서 구체적으로 이야기해보겠습니다. 처음에는 이전 글처럼 비유와 상징 위주로 가볍게 작성했었는데, 영양가가 없는 것 같더라구요. Claude Code를 본격적으로 사용하시는 분들도 많이 계시는 것 같아서, 조금이나마 도움이 될까 하는 생각에 어느정도 실제 적용하는 기술적 내용도 덧붙였습니다. Claude Code와 그 확장 시스템을 조합해서 사용하면 아래와 유사한 구조를 가지게 되는데요. 이 중에서 Context 관리에 필요한 구성요소들에 대해 이야기하고자 합니다. 주인이 깨워서 눈을 떠보니 주위엔 아무것도 없고, 눈앞엔 지도 한장 놓여있었다. Claude Code에는 CLAUDE.md라는 파일이 있습니다. 이 친구가 새 대화를 시작할 때 무조건 가장 먼저 읽는 파일입니다. 텅 빈 책상 위에 가장 먼저 놓여지는 문서인 것이죠. 저는 여기에는 자세한 내용을 적지 않습니다. 대신 지도를 그려놨습니다. 이 프로젝트가 뭔지 (프로젝트 구조, 기술 스택, 빌드 방법) 절대 하면 안 되는 것들 (핵심 규칙) 어떤 규칙들이 있고, 그 규칙이 어디에 적혀 있는지 (규칙 파일 경로 목록) 어떤 도구와 명령어를 쓸 수 있는지 (스킬, 에이전트 목록) OpenAI 엔지니어들의 말처럼 1000페이지 매뉴얼을 그대로 올리면 책상이 바로 꽉 차겠죠. 지도 한 장이면, 필요할 때 해당 챕터를 찾아가서 읽으면 됩니다. 여기서 중요한건 '핵심 규칙’인데요. 지도에 적힌 내용은 매 세션마다 항상 Context Window에 올라가기 때문에, 절대 잊어버리면 안 되는 가장 중요한 것들만 지도 자체에 직접 적어둡니다. 예를 들어 “동료나 외부에 노출되는 시스템(업무관리/협업 도구, 위키 등)에 뭔가를 쓰는 건 반드시 내 허락을 받고 해” 이 규칙은 별도 파일이 아닌 지도에 직접 박아뒀습니다. 이러면 대화가 아무리 길어져도, 압축이 일어나도, 이 규칙은 살아남습니다. 이전 글의 OpenClaw 사건에서 "확인 후 실행하라"는 지시가 대화 속에만 있었기 때문에 압축 과정에서 사라진 거잖아요. 가장 중요한 규칙은 대화가 아닌, 매 세션마다 자동으로 로딩되는 파일에 적어둬야 합니다. 지도에는 이렇게 적혀있었다. “필요한 규칙은 전부 서랍에 있어" 지도에는 상세 규칙에 대한 경로가 작성되어 있고, 실제 규칙들은 rules/ 폴더 아래에 주제별로 분류되어 있습니다. 서랍장처럼요. 현재 저는 세 종류의 서랍에서 각 Task에 맞게 실행되는 수십개의 규칙 문서를 관리하고 있습니다. 첫 번째 서랍 — rules/workflow/ 업무를 어떤 순서로 처리하는지에 대한 규칙입니다. 회사에 신입이 왔을 때 "우리 팀은 이렇게 일해"라고 알려주는 온보딩 문서와 비슷합니다. 구체적으로는 이런 내용들이 들어 있습니다. 작업 파이프라인 : 요구사항 분석 → 계획 수립 → 코드 작성 → 검증 → 발행. 각 단계에서 어떤 산출물을 만들어야 하는지, 다음 단계로 넘어가려면 뭘 확인해야 하는지. 작업 공간 전략 : 코드를 수정할 때 어떤 이름으로 별도 작업 공간(브랜치)를 만들고, 완료 후 어떻게 병합하는지. 코드 변경 이력 관리 : 코드 변경 이력을 남길 때 메시지를 어떤 형식으로 작성하는지. 문서 관리 정책 : 작업 관련 문서를 어디에, 어떤 구조로 저장하는지. 규칙을 파일로 명문화 할수록 AI가 제멋대로 일할 가능성이 줄어듭니다. 갑자기 메시지 작성 언어가 바뀐다던지, 문서 템플릿이 매일매일 달라진다던지 하는 일이 사라지죠. 두 번째 서랍 — rules/code-quality/ 코드를 작성할 때 지켜야 하는 기준입니다. 코딩 스타일: 변수 이름 규칙, 불변 객체 우선 사용, 값이 없는 경우의 안전성 처리 방법 등. 보안 체크리스트: 사용자 입력 검증, 서버 호출에 사용되는 인증키, 암호화 처리 등. 테스트 가이드: 어떤 종류의 테스트를 작성해야 하는지, 테스트가 서비스 전체 기능의 어느정도를 커버해야 하는지. 코드 검증 방법: 빌드 해보고 디버깅 도구를 통해 결과물을 확인하는 프로세스. 이 서랍이 필요한 이유는 코드를 ‘잘’ 작성하는 것과 우리 '팀에 맞는’ 코드를 작성하는 것은 다르기 때문입니다. AI는 일반적으로 좋은 코드를 작성하지만, 팀의 코드 작성 규칙이나 스타일 패턴까지 알지는 못하거든요. 세 번째 서랍 — ...
AI Harness
2026. 02. 27
32

Claude에게 모든 걸 알려줬는데 왜 자꾸 까먹나요?

이전 글에서 이어집니다. 저는 Claude에게 업무에 필요한 시스템 접근권을 열어주고, 앞뒤 사정을 파악할 수 있도록 전용 위키까지 만들어줬습니다. 그러면 '이제 잘 되겠지' 라고 생각했죠. 마치 아들 하나 더 키우는 기분입니다. 처음엔 꽤 잘 되는것 같았습니다. 문제는 시간이 지나면서 나타났습니다. 하지 말라는걸 합니다. - 업무 특성상 규칙이 꽤 상세하고 체계적이었는데요, 처음엔 잘 따르는거 같더니 대화가 길어지면 슬금슬금 금지한 행동들을 합니다. 같은 실수를 반복합니다. - 여러 방법을 시도하다가 다 막히면, 예전에 시도해서 실패했던 방법을 다시 시도합니다. 엉뚱한 곳에서 작업하고 있습니다. - 문제와 연결된 것 처럼 보이지만, 실제로는 관계없는 부분에서 열심히 헤딩을 하고 있습니다. 문제는 Context야, 이 바보야 AI와 대화할 때 주고받는 모든 내용 (내가 한 말, AI가 한 말, AI가 읽은 파일과 문서)을 Context라고 하는데요. 모델을 불문하고 AI가 한 번에 담아둘 수 있는 Context의 총량에는 물리적인 한계가 있습니다. 이걸 Context Window라고 부릅니다. 앤스로픽 공식 문서에도 잘 설명되어 있습니다만, 쉽게 이야기하면, 크기가 정해진 책상 하나가 있는 건데요. AI는 대화 내용, 규칙, 코드, 문서를 전부 이 책상 위에 올려놓고 일합니다. 처음엔 넉넉합니다. 그런데 대화가 길어지고 참고 자료가 쌓이면 책상이 꽉 찹니다. 새 자료를 올리려면 기존 자료를 밀어내야 ...
AI Harness
2026. 02. 25
22
10
163
Claude가 지금 잘하고 있는지, 어떻게 아나요?
237
날먹하려고 Claude를 쓰려는 자는 결국 무한의 순환에 빠질지니...
10
330
나의 Claude 취급 설명서
207
Claude에게 모든 걸 알려줬는데 왜 자꾸 까먹나요?