며칠 전 GeekNews 댓글창에서 nair.sh의 글 한 편이 한참 회자되는 걸 봤습니다. 제목은 "시니어 엔지니어가 후배에게 전문성을 잘 못 전달하는 이유"였습니다. 1인기업으로 부동산 중개와 AI 자동화를 같이 굴리는 저로서는, 이 글을 후배 문제가 아니라 저 자신의 문제로 읽었습니다.
저는 후배가 없습니다. 대신 매일 Claude Code와 1대1로 일합니다. 부동산 분석 자동화, 블로그 발행 파이프라인, 러닝 코치 앱, 정산 시스템까지 1년 가까이 AI에게 본업 노하우를 가르치면서 알게 된 것이 있습니다. AI에게 컨텍스트를 가르치는 일은 후배 멘토링과 정확히 같은 문제라는 것입니다. 5%만 전달되고 95%는 머릿속에 남습니다.
이 글은 nair.sh 원문을 요약하면서, 1인기업·AI 시대 시점에서 5가지 함정을 다시 보겠습니다. 시니어 개발자뿐 아니라 본인 노하우를 AI에 옮겨 일을 키우려는 모든 1인 사업자가 매일 마주치는 함정입니다.
nair.sh의 원문은 한 줄로 요약하면 이렇습니다. 시니어가 후배에게 전수하려는 것은 "복잡성을 다루는 휴리스틱"인데, 시니어 본인은 그것을 "단언의 어휘"로만 표현할 줄 안다는 진단입니다. 휴리스틱은 어려운 단어 같지만 풀어 쓰면 "경험으로 굳은 빠른 판단 규칙"입니다.
원문은 5개의 안티패턴을 짚습니다. 첫째, "No"로 답하는 습관. 둘째, 페어 프로그래밍 중 키보드 점령. 셋째, 위키에 암묵지를 쓰면 다 전수된다는 착각. 넷째, 결과 코드만 보여주고 사고 과정을 생략하는 것. 다섯째, 후배를 "내 옛날 모습"으로 가정하는 오류입니다.
저는 이 5개를 읽으면서, 작년에 Claude Code에게 부동산 분석을 가르치며 실패했던 패턴이 그대로 겹치는 걸 발견했습니다. "이거 안 돼", "내가 직접 짤게", "프롬프트 한 페이지 길게 써놓으면 알겠지"라고 했던 순간이 전부 후배 멘토링 안티패턴과 같았습니다.
1인기업 시점 인사이트: 이 글은 시니어-주니어 관계 글이 아닙니다. 본인 노하우를 외부에 옮겨 일을 키우려는 모든 사람의 문제입니다.
원문에서 가장 인상 깊었던 대목은 어휘 미스매치 부분이었습니다. 시니어가 후배에게 전달하려는 지식은 사실 불확실성을 다루는 휴리스틱입니다. "이 코드는 안 됩니다"가 아니라 "이 방향으로 가면 6개월 뒤 이런 함정에 빠질 확률이 60%쯤 됩니다"가 진짜 메시지입니다.
그런데 시니어 본인은 그 휴리스틱을 단언의 어휘로만 표현합니다. "안 됩니다", "이렇게 짜세요", "그건 잘못된 패턴입니다". 단언은 권위를 만들지만 사고 과정을 가립니다. 후배는 결론만 받고 "왜 그렇게 판단했는가"는 못 받습니다.
저는 작년에 Claude에게 "구해줘 부동산" 블로그 자동화를 시키면서 같은 실수를 했습니다. "이 키워드는 안 좋아", "이런 단어 쓰지 마"라고만 입력했는데 Claude는 매번 다른 변형으로 같은 실수를 반복했습니다. 결국 한 줄 한 줄 "왜 이 단어가 안 좋은가 — 평론가 코스프레로 보임, 제 본업 톤과 안 맞음"이라고 풀어 적은 메모리 파일을 만들고 나서야 안정됐습니다.
이 변환이 핵심입니다. 단언의 어휘를 불확실성의 어휘로 풀어내는 것. 시니어 본인은 머릿속에서 이미 풀어쓰기 단계를 끝내고 결론만 말합니다. 후배(그리고 AI)는 결론만 받습니다. 95% 손실이 여기서 발생합니다.
AI 시대 응용: AI에게 "안 돼"는 0% 전달, "이런 함정 때문에 안 돼"는 70% 전달입니다.
원문의 첫 번째 안티패턴은 후배 질문에 "No"부터 던지는 습관입니다. 후배가 새 기술 도입을 제안하면 시니어는 단점이 먼저 보입니다. 1초도 안 돼 "그건 안 됩니다"가 나갑니다.
문제는 후배에게 들리는 메시지가 "당신 판단이 틀렸습니다"라는 것입니다. 시니어 입장에서는 30번 봤던 함정을 피해주는 일이지만, 후배 입장에서는 자기 사고가 꺾이는 경험입니다. 몇 번 반복되면 후배는 질문을 안 합니다. 시니어는 "요즘 애들 의욕이 없다"고 오해합니다.
원문이 제안하는 대체 응답은 "더 빠른 우회로"입니다. "그 방향은 6개월 뒤 X 문제가 생길 가능성이 높습니다. 같은 목표를 Y 방법으로 가면 일주일 안에 검증 가능합니다." 같은 결론이지만 사고 과정과 대안이 같이 갑니다.
저는 Claude Code에 부동산 데이터 수집 스크립트를 시키면서 비슷하게 깨달았습니다. "그렇게 짜지 마"라고만 하면 Claude가 같은 실수를 또 합니다. "그렇게 짜면 호갱노노에 1초에 30번 요청이 가서 차단당합니다. rate limiter로 1초당 2번으로 제한하세요"라고 풀어 주면 그 다음부터 안 합니다. 이유와 우회로가 같이 가야 합니다.
AI 시대 응용: AI는 "안 돼"를 100번 들어도 화를 안 냅니다. 그런데 같은 실수도 100번 합니다. 시니어가 "No"만 던지면 AI도 후배와 같이 학습이 안 됩니다.
원문의 두 번째 안티패턴은 페어 프로그래밍 중 시니어가 키보드를 가져가는 행위입니다. 후배가 30분째 헤매고 있으면 시니어는 보다 못해 "잠깐 비켜봐요"하고 자기가 칩니다. 5분 안에 끝납니다. 후배는 옆에서 봅니다.
문제는 후배가 본 것이 결과 코드뿐이라는 점입니다. 시니어의 머릿속에서 "이 변수가 이상하다 → 이 함수 의심 → 디버거 켜고 stack trace 확인 → 아 여기네"로 흘러간 사고 과정은 안 보입니다. 후배 입장에서는 마법을 본 것입니다. 다음 번에 비슷한 상황이 와도 재현 못 합니다.
원문이 제안하는 대안은 후배가 타이핑하고 시니어가 질문하는 구조입니다. "지금 어떤 가설로 가고 있어요?", "이 변수 값이 왜 이럴 거 같아요?", "이 함수 호출 전후로 뭐가 바뀌어야 정상이에요?" 후배가 답을 하면서 자기 사고 과정을 외부화합니다. 시니어는 그 과정에서 어디가 빠졌는지 짚어줍니다.
저는 1인기업이라 페어 프로그래밍 상대가 없습니다. 대신 Claude에게 "이거 못 짜겠어, 네가 짜"가 아니라 "이거 짜고 있는데 막혔어. 다음 단계가 뭐가 자연스러워?"라고 묻습니다. Claude가 후보 3개를 내놓으면 제가 고릅니다. 키보드는 제가 잡고 있고 Claude가 질문 던지는 구조입니다. 신기하게 이 구조가 제 사고력을 늘립니다.
AI 시대 응용: AI에게 "다 짜줘"는 시니어가 키보드 뺏는 것과 같습니다. "다음 가설 후보 3개 줘"가 페어링입니다.
원문의 세 번째 안티패턴은 "위키에 다 적어놓으면 후배가 읽고 안다"는 착각입니다. 시니어는 자기 노하우를 위키 한 페이지로 정리합니다. 후배가 읽습니다. 그런데 막상 일을 시키면 그 위키 내용을 못 씁니다.
원문이 짚는 이유는 이렇습니다. 시니어의 판단은 수년치 사실이 엮인 월드모델입니다. 위키 한 페이지는 그 월드모델의 5%만 외부화한 결과물입니다. 빙산의 일각 같은 상태입니다. 후배는 페이지를 읽지만 그 페이지가 가리키는 95%의 맥락은 못 받습니다.
저도 같은 실수를 했습니다. Claude에게 "이 CLAUDE.md 메모리 파일 200줄 읽으면 우리 시스템 다 알 거야"라고 가정했는데 매번 새 작업마다 같은 룰을 위반했습니다. 한참 후에 깨달았습니다. 그 200줄은 작년 1년치 시행착오의 결론만 적은 거고, 결론 뒤에 깔린 사례·실패·예외는 한 줄도 없었습니다. 그래서 Claude는 결론을 응용하지 못했습니다.
해결은 "결론 + 그 결론이 나오게 된 1줄 사례"를 같이 적는 것입니다. "평론가 코스프레 금지" 한 줄이 아니라 "평론가 코스프레 금지 — 2026-04 서평 5건에서 '메타인지적 시선' 같은 단어 나와서 제가 전부 폐기시킴"으로 적습니다. 사례가 붙으면 외부화 비율이 5%에서 30%쯤으로 올라갑니다.
AI 시대 응용: 위키 한 페이지 = AI에게 시스템 프롬프트 한 페이지. 사례 없는 결론만 적으면 재현 못 합니다.
원문의 네 번째 안티패턴은 결과 코드만 공유하고 그 코드가 나온 사고 과정을 생략하는 것입니다. 코드 리뷰 시간에 시니어는 "여기 이렇게 바꾸세요"라고 diff만 던집니다. 후배는 받습니다. 다음 번에 비슷한 상황이 오면 그 diff 패턴을 흉내내지만, 살짝 다른 맥락에서는 망가집니다.
원문이 제안하는 대안은 의사결정 트레이스를 같이 남기는 것입니다. "이 부분을 X에서 Y로 바꿨습니다. 이유는 A·B·C 세 가지인데, 특히 C가 6개월 뒤 캐시 무효화 시점에 문제가 됩니다." 결론 한 줄 대신 결론 + 3가지 이유 + 미래 시나리오를 같이 적습니다.
저는 블로그 자동화 코드를 짤 때 같은 함정에 빠졌습니다. Claude가 짜준 코드를 받아서 "이 함수 빼"라고만 했습니다. 며칠 뒤 다른 자동화에서 Claude가 비슷한 함수를 또 넣었습니다. 학습이 안 된 겁니다. "이 함수 빼 — 외부 API 호출이 들어가서 토큰 만료되면 무한 대기, 작년에 새벽 5시 배치 멈춘 적 있음"으로 풀어 적은 다음부터 같은 패턴이 안 나옵니다.
코드 리뷰는 사후 정답 채점이라 사고 과정 전달이 약합니다. 정답만 보고 그 정답이 왜 정답인지는 모르는 채로 끝납니다. 사후 채점이 아니라 사고 과정 트레이스가 진짜 전수입니다.
AI 시대 응용: AI에 코드 수정 요청할 때 "왜 그렇게 바꾸는지 1줄 같이"가 다음 작업 학습률을 3배로 올립니다.
원문의 다섯 번째 안티패턴은 시니어가 후배를 "10년 전 자기 모습"으로 가정하는 오류입니다. 시니어는 자기가 주니어였을 때 SQL을 직접 짜고, 자바스크립트로 DOM 조작하고, CSS를 손으로 깎았습니다. 후배도 그 길을 똑같이 거쳐야 한다고 가정합니다.
문제는 지금 후배는 다른 세계에 있다는 것입니다. ChatGPT로 boilerplate 짜고, Copilot으로 자동완성하고, Claude Code로 리팩토링합니다. 시니어가 "기본기가 약해"라고 평가하는 부분이 사실 후배 세대에선 기본기가 아닙니다. 후배에게 진짜 부족한 건 다른 영역(시스템 사고, 도메인 판단, AI 결과 검증)입니다.
저는 이 함정을 1인기업 시점에서 다르게 봅니다. 저는 후배는 없지만 AI를 후배처럼 씁니다. AI는 boilerplate를 분 단위로 짭니다. 제가 작년에 한 달 동안 짠 정산 자동화 첫 버전을 Claude는 2시간이면 다시 짭니다. 그 영역에서 제 가치는 0에 가깝습니다.
대신 제 가치는 다른 영역으로 이동했습니다. 어떤 길은 가지 말아야 하는지 아는 것입니다. 부동산 데이터 어디서 가져오면 막히는지, 블로그 어떤 단어 쓰면 발행 직전에 폐기되는지, 러닝 데이터 어디까지 신뢰할 수 있는지. 이 판단은 1년치 시행착오에서 나온 것이지 코드를 잘 짜서 나온 게 아닙니다.
이 이동을 nair.sh 원문 표현으로 옮기면 이렇습니다. 시니어의 일은 "코딩 스킬"에서 "도메인 판단·맥락 전수"로 이동합니다. 그리고 그 전수의 1차 대상은 후배가 아니라 AI입니다. AI한테 도메인 맥락을 잘 가르치는 시니어가 가장 비싸집니다.
AI 시대 응용: 후배 멘토링 스킬 = AI 컨텍스트 엔지니어링 스킬. 같은 함정, 같은 해법입니다.
Q1. 시니어 개발자는 왜 전문성 전달에 실패합니까?
A. nair.sh 원문에 따르면 시니어의 지식은 "불확실성을 다루는 휴리스틱"인데 본인은 그것을 "단언의 어휘"로만 표현하기 때문입니다. "안 됩니다" 한 마디 안에 "60% 확률로 6개월 뒤 X 함정"이라는 사고 과정이 가려집니다. 후배는 결론만 받고 사고 과정은 못 받습니다.
Q2. 후배 질문에 "이건 안 됩니다"라고 자주 말하는 게 왜 문제입니까?
A. 후배에게 들리는 메시지가 "당신 판단이 틀렸습니다"가 되기 때문입니다. 시니어 입장에서는 함정 회피지만 후배 입장에서는 사고가 꺾이는 경험입니다. 원문은 "No" 대신 "더 빠른 우회로 + 그 이유"를 제시하라고 권합니다. "그 방향은 X 문제가 생깁니다. 같은 목표를 Y로 가면 일주일 안에 검증됩니다" 같은 응답입니다.
Q3. 암묵지를 글로 옮겨도 후배가 안 따라오는 이유는 무엇입니까?
A. 시니어의 판단이 수년치 사실이 엮인 월드모델이라 위키 한 페이지로는 5%만 외부화되기 때문입니다. 페이지에 적힌 결론은 가져가지만 그 결론 뒤의 95%(사례·실패·예외)는 못 가져갑니다. 해결은 "결론 + 1줄 사례"를 같이 적어서 외부화율을 30% 수준으로 올리는 것입니다.
Q4. 페어 프로그래밍은 정말 효과가 있습니까?
A. 답정너 페어링(시니어가 키보드 뺏고 시범 보이는 구조)은 실패합니다. 후배가 본 건 결과 코드뿐이고 사고 과정은 안 보입니다. 효과 있는 구조는 후배가 타이핑하고 시니어가 질문하는 형태입니다. "지금 어떤 가설로 가고 있어요?", "이 변수 값이 왜 이럴 거 같아요?" 후배가 자기 사고를 외부화하면서 학습합니다.
Q5. 시니어 개발자의 진짜 가치는 무엇입니까?
A. 코드를 잘 짜는 게 아닙니다. 어떤 길은 가지 말아야 하는지 아는 것입니다. 부동산 데이터 어디서 가져오면 막히는지, 블로그 어떤 단어 쓰면 안 되는지 같은 도메인 판단입니다. 이 판단은 시행착오 기록에서 나옵니다. AI 시대에는 boilerplate 코딩 가치가 떨어지면서 이 영역으로 시니어 일이 이동합니다.
Q6. 제가 후배 일을 직접 짜버리는 게 정상입니까?
A. 흔한 안티패턴입니다. 단기적으로는 빠르지만 후배 학습은 0이고 다음 번에도 시니어가 또 짜야 합니다. 원문이 권하는 자세는 "단기 손실 인정 + 후배가 실패할 권리 보장"입니다. 후배가 30분 헤매는 걸 견디고, 그 동안 옆에서 질문만 던지는 구조입니다. 본인 손이 가려운 것을 참는 훈련이 시니어 일의 절반입니다.
Q7. AI가 주니어 일을 대체하면 시니어는 누구에게 전문성을 전수합니까?
A. AI에게 전수합니다. AI 컨텍스트 엔지니어링은 후배 멘토링과 같은 스킬입니다. 도메인 맥락을 외부화하고, 사례를 곁들이고, "왜 이 방향은 안 되는가"를 풀어 적는 작업입니다. 차이는 AI는 같은 질문 100번 받아도 화 안 내고, 키보드 안 뺏기고, 사적 감정이 없다는 것입니다. 시니어 안티패턴이 안 발생하는 환경이라 학습이 빠릅니다.
Q8. 코드 리뷰만 잘하면 충분합니까?
A. 부족합니다. 코드 리뷰는 사후 정답 채점이라 사고 과정 전달이 약합니다. 후배는 정답 diff는 받지만 그 정답이 나온 의사결정 트레이스는 못 받습니다. 다음 번에 살짝 다른 맥락이 오면 응용 못 합니다. 원문이 권하는 것은 의사결정 트레이스를 같이 남기는 것입니다. "X에서 Y로 바꿨습니다. 이유 A·B·C 중 특히 C가 6개월 뒤 캐시 무효화 시점에 문제가 됩니다" 같은 트레이스입니다.
여기까지가 nair.sh 원문 5가지 안티패턴과 1인기업·AI 시대 시점입니다. 저는 후배가 없는 사업자지만 AI에게 본업을 가르치는 일은 후배 멘토링과 같은 5% 전송률 문제였습니다. 작가가 아니라 편집자로 시니어 역할이 이동하는 시대에, 같은 함정은 더 많이 보입니다.