Skip to content
Published on

1:1과 피드백의 기술 — IC와 매니저 모두를 위한 실전 가이드

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

들어가며 — 왜 1:1이 다시 화두인가

원격·하이브리드 근무가 표준이 되고, AI 에이전트가 일상 업무의 상당 부분을 처리하는 2026년. 역설적으로 Hacker News와 GeekNews에서 가장 꾸준히 올라오는 주제 중 하나는 지극히 인간적인 것, 바로 1:1 미팅과 피드백입니다. "매니저와의 1:1이 status update로 전락했다", "연말 평가에서 처음 듣는 피드백에 뒤통수를 맞았다" 같은 글에는 어김없이 수백 개의 공감 댓글이 달립니다.

이유는 명확합니다. 코드 작성은 에이전트가 도와주지만, 신뢰를 쌓고 사람을 성장시키는 일은 자동화되지 않기 때문입니다. Will Larson(lethain)은 1:1을 "매니저가 가진 가장 비싼 정기 투자"라고 불렀고, Kim Scott의 Radical Candor는 "직접적으로 도전하되 개인적으로 아끼는" 피드백 문화를 제안했습니다. 이 글은 그 고전적 통찰을 2026년의 일터에 맞게, IC(Individual Contributor)와 매니저 양쪽의 관점에서 실전 도구로 정리합니다.

1:1이 형식적이 되는 이유

먼저 병의 원인부터 진단합시다. 1:1이 죽어가는 전형적인 경로는 이렇습니다.

1단계: 아젠다 없이 시작 ("뭐 얘기할 거 있어요?")
   |
   v
2단계: 할 말이 없으니 업무 진척 보고로 채움
   |
   v
3단계: "그건 스탠드업에서 들었는데..." -> 둘 다 시간 낭비라고 느낌
   |
   v
4단계: "바쁘면 이번 주는 스킵할까요?" -> 격주가 되고, 월 1회가 되고
   |
   v
5단계: 분기 평가 때 서로 놀람 (서프라이즈 평가의 탄생)

핵심 원인 세 가지:

  1. 목적 부재: 1:1은 업무 보고 시간이 아닙니다. 업무 진척은 비동기(티켓, 슬랙, 스탠드업)로 충분합니다. 1:1의 고유 목적은 비동기로 다루기 어려운 것 — 장애물, 관계, 커리어, 감정 — 입니다.
  2. 준비 부재: 양쪽 모두 준비 없이 들어오면 가장 만만한 주제(업무 상태)로 수렴합니다.
  3. 후속 조치 부재: 말한 것이 바뀌지 않으면, 말할 이유가 사라집니다.

좋은 1:1의 구조

공유 아젠다 문서

가장 효과 높은 단일 개입은 둘이 함께 보는 아젠다 문서 하나를 만드는 것입니다. Notion, Google Docs, 위키 어디든 좋습니다.

# 1:1 — 영주 x 매니저 (매주 화 14:00, 30분)

## 다음 미팅 아젠다 (둘 다 미리 추가)
- [영주] 결제 마이그레이션에서 타팀 의존성 막힘 — 에스컬레이션 필요한지
- [매니저] 다음 분기 프로젝트 배정 관련 의견 듣고 싶음

## 반복 체크 (매번 2분)
- 지난주 액션 아이템 리뷰

## 액션 아이템
- [ ] (매니저) 플랫폼팀 리드에게 API 일정 확인 — 6/16까지
- [ ] (영주) 커리어 목표 문서 v1 작성 — 6/19까지

## 지난 기록 (최신이 위)
### 2026-06-09
- 논의: ...
- 결정: ...

규칙:

  • 미팅 24시간 전까지 아젠다 항목 추가. 항목이 하나도 없으면 그 주는 취소해도 됩니다. 단, 2회 연속 취소되면 그 자체를 아젠다로 올립니다.
  • 기록은 같은 문서에 누적합니다. 6개월치 기록은 평가 시즌에 양쪽 모두의 보험이 됩니다.

3트랙 구조

30분 1:1의 시간 배분 권장안:

트랙내용시간빈도
상태컨디션, 워크로드, 번아웃 신호5분매번
장애물막힌 것, 갈등, 에스컬레이션 필요 사항15분매번
커리어성장 목표, 피드백, 다음 단계10분격주 이상

커리어 트랙이 핵심입니다. 매번은 아니어도 좋지만, 한 달 이상 커리어 이야기가 없었다면 그 1:1은 경고등이 켜진 상태입니다.

IC 편 — 1:1을 주도하는 법

1:1의 주인은 매니저가 아니라 IC입니다. 이 인식 전환 하나가 모든 것을 바꿉니다. 매니저의 시간 30분을 내 성장을 위해 할당받은 예산이라고 생각하세요.

준비 템플릿 (미팅 전 5분)

이번 주 1:1 준비 메모
1. 지금 나를 가장 막고 있는 것 한 가지는?
   (기술 문제 / 사람 문제 / 프로세스 문제)
2. 매니저만이 해결해 줄 수 있는 것은?
   (권한, 정보, 에스컬레이션, 정치적 지원)
3. 지난주에 한 일 중 매니저가 모를 가치 있는 일은?
   (셀프 어필은 1:1의 정당한 용도다)
4. 받고 싶은 피드백이 있는 영역은?
   ("지난번 설계 리뷰에서 제 커뮤니케이션 어땠나요?")
5. 커리어: 지금 하는 일이 내 목표와 연결되어 있나?

올리기 좋은 주제 vs 나쁜 주제

좋은 주제 (1:1 전용 가치)나쁜 주제 (다른 채널이 나음)
팀 동료와의 협업 마찰단순 업무 진척 보고
커리어 방향과 다음 단계코드 리뷰 요청
워크로드와 번아웃 신호회의로 정할 수 있는 기술 결정
매니저에 대한 피드백티켓에 쓰면 되는 버그 논의
조직 변화에 대한 불안휴가 일정 공유 (메일로 충분)
애매해서 묻기 어려웠던 질문이미 결정된 사안의 재논의

막힌 것을 말하는 기술

장애물을 올릴 때는 불평이 아니라 의사결정 요청 형태로 만듭니다.

[나쁜 예]
"플랫폼팀이 API를 안 줘서 진행이 안 돼요. 답답해 죽겠어요."

[좋은 예]
"플랫폼팀 API 일정이 2주 밀리면서 마이그레이션이 블록됐어요.
제가 보는 옵션은 셋입니다.
A. 기다린다 (일정 2주 지연 수용)
B. 임시 어댑터를 만든다 (이틀 추가 작업, 나중에 버림)
C. 매니저님이 플랫폼팀 리드와 우선순위를 조정한다
저는 B가 낫다고 보는데, C가 가능하면 그게 최선입니다. 어떻게 보세요?"

옵션과 본인 의견까지 가져가면, 매니저는 "문제를 떠안는" 대신 "판단만 하면" 됩니다. 이것이 매니지 업의 기본기입니다.

매니저 편 — 질문 라이브러리와 침묵

질문 라이브러리 20

좋은 1:1은 좋은 질문에서 나옵니다. 상황별로 정리했습니다.

[열기 — 상태 확인]
1. 이번 주를 색깔로 표현하면? 왜?
2. 요즘 에너지를 가장 많이 쓰는 일은 뭐예요?
3. 워크로드는 10점 만점에 몇 점? 7점 넘으면 뭘 내려놓을까요?

[장애물 발굴]
4. 지금 가장 답답한 게 뭐예요?
5. 내가 이번 주에 하나를 해결해 줄 수 있다면 뭘 골라요?
6. 일하는 속도를 늦추는 프로세스가 있나요?
7. 어떤 회의가 시간 낭비라고 느껴져요?

[팀과 관계]
8. 팀에서 요즘 신경 쓰이는 분위기가 있나요?
9. 누구와의 협업이 제일 잘 되고, 누구와는 마찰이 있어요?
10. 내가 모르고 있는 것 같은 일이 있나요?

[커리어와 성장]
11. 지금 하는 일 중 더 하고 싶은 것과 덜 하고 싶은 것은?
12. 1년 뒤에 어떤 일을 하고 있으면 성공이라고 느낄까요?
13. 최근에 배우고 있는 게 있어요? 회사가 그걸 도울 방법은?
14. 다음 단계로 가려면 뭐가 부족하다고 스스로 생각해요?

[피드백 양방향]
15. 최근 제 결정 중에 동의 안 되는 게 있었나요?
16. 제가 뭘 더 하고 뭘 덜 하면 일하기 좋아질까요?
17. 팀 회의 운영 방식, 솔직히 어때요?

[닫기]
18. 오늘 얘기 중 액션으로 만들 것은 뭘까요?
19. 다음 1:1까지 내가 확인해 줄 것이 있나요?
20. 오늘 못 다룬 것 중 다음에 꼭 다룰 것은?

침묵을 견디는 기술

매니저가 가장 못 하는 것이 침묵입니다. 좋은 질문을 던지고 3초가 지나면 불안해서 본인이 답을 채웁니다. 그 순간 1:1은 매니저의 독백이 됩니다.

  • 질문 후 속으로 7초를 세세요. 깊은 질문일수록 상대는 생각할 시간이 필요합니다.
  • 상대가 짧게 답하면 "조금 더 말해 줄래요?" 한 마디로 한 층 더 내려갑니다.
  • 말하는 비율 목표: 매니저 30, IC 70. 끝나고 비율을 회고해 보세요.

피드백 프레임워크 비교 — SBI, COIN, Radical Candor

피드백 프레임워크는 많지만 본질은 같습니다. 관찰 가능한 사실에서 출발해, 영향을 말하고, 다음 행동을 합의한다. 대표 3종을 비교합니다.

프레임워크구조강점약점적합 상황
SBI상황-행동-영향간결, 외우기 쉬움다음 행동 단계가 없음가벼운 일상 피드백
COIN맥락-관찰-영향-다음후속 행동까지 포함SBI보다 길어 무거움교정이 필요한 피드백
Radical Candor직접 도전 x 개인적 관심의 2축문화 차원의 나침반대화 템플릿은 아님피드백 문화 설계

Radical Candor의 사분면은 이렇게 그려집니다.

                  개인적으로 아낀다 (Care Personally)
                          ^
                          |
   파괴적 공감            |        진정한 솔직함
   (Ruinous Empathy)      |        (Radical Candor)
   문제를 알지만          |        아끼면서 직접
   상처 줄까 봐 침묵      |        말한다 <- 목표
                          |
  --------------------------------------------------->
                          |       직접적으로 도전한다
   교활한 가식            |       (Challenge Directly)
   (Manipulative          |
    Insincerity)          |        불쾌한 공격성
   뒤에서만 말함          |        (Obnoxious Aggression)
                          |        아끼지 않고 직설만

흔한 오해: Radical Candor는 "솔직하게 막 말해라"가 아닙니다. 사분면의 핵심은 개인적 관심이 전제되지 않은 직설은 그냥 공격이라는 것입니다. 평소에 신뢰 잔고를 쌓지 않았다면, 어떤 프레임워크를 써도 피드백은 실패합니다.

어려운 피드백 스크립트 5

실제 대사 수준으로 만든 시나리오별 스크립트입니다. COIN 구조(맥락-관찰-영향-다음)를 기본으로 합니다.

스크립트 1 — 성과: 마감을 반복적으로 놓치는 동료/팀원

"이번 스프린트 얘기 잠깐 해도 될까요? (맥락)
최근 세 번의 스프린트에서 맡은 티켓이 마지막 날에 절반 정도 미완료로
넘어갔어요. (관찰 — 사실만, '항상 늦는다' 같은 일반화 금지)
그러면 QA 일정이 밀리고, 다른 팀원이 주말에 커버하는 일이 생겨요. (영향)
제가 궁금한 건, 추정이 어려운 건지, 중간에 끼어드는 일이 많은 건지예요.
원인을 같이 찾고 싶어요. 어떻게 보고 있어요?" (다음 — 진단을 함께)

스크립트 2 — 협업: 코드 리뷰 톤이 공격적인 팀원

"어제 PR 리뷰에 남긴 코멘트 얘기인데요. (맥락)
'이걸 왜 이렇게 짰는지 이해가 안 된다'는 문장이 있었어요. (관찰 — 인용)
받은 분 입장에선 코드가 아니라 사람이 평가받는 느낌이 들 수 있고,
실제로 그 뒤로 그분 PR 올리는 빈도가 줄었어요. (영향)
지적한 내용 자체는 타당했어요. 같은 내용을
'이 접근의 의도가 궁금해요. X 케이스는 어떻게 처리되나요?'로 바꾸면
기술적 날카로움은 유지하면서 방어심은 안 생겨요. 시도해 볼래요?" (다음)

스크립트 3 — 태도: 회의에서 다른 의견을 차단하는 시니어

"오늘 설계 회의에서 느낀 걸 공유하고 싶어요. (맥락)
주니어 두 명이 대안을 꺼냈을 때, 두 번 다 '그건 예전에 해봤는데 안 돼요'로
첫 문장에서 마무리됐어요. (관찰)
경험에서 나온 판단이라는 건 알아요. 그런데 그 패턴이 반복되면
회의에서 새 의견 자체가 안 나오게 되고, 결국 검토 안 된 리스크는
모두 우리 몫이 돼요. (영향)
다음부터는 결론 전에 '어떤 상황을 가정한 제안이에요?' 한 번만
물어봐 주면 좋겠어요. 시니어인 당신의 그 한 문장이 회의 전체의
안전감을 결정해요." (다음)

스크립트 4 — 성장: 잘하지만 보이지 않게 일하는 팀원

"좋은 피드백이라 편하게 들어요. (맥락)
지난달 장애 때 근본 원인을 찾은 게 사실상 당신 분석이었는데,
회고 문서에도 발표에도 그 과정이 안 드러났어요. (관찰)
결과적으로 평가 자료에 남는 건 문서와 발표뿐이라,
당신 임팩트가 실제보다 작게 기록되고 있어요. 그건 본인 손해이기도 하고,
팀이 좋은 분석 방법을 배울 기회를 잃는 것이기도 해요. (영향)
다음 분기엔 분석 과정을 짧은 글로 남기는 걸 목표로 잡아 볼까요?
첫 글은 제가 같이 다듬어 줄게요." (다음)

스크립트 5 — 번아웃 신호: 갑자기 조용해진 팀원

"요즘 어떤지 궁금해서요. (맥락)
최근 2주간 회의에서 발언이 거의 없었고, 평소엔 먼저 잡던
페어 세션도 안 잡으시더라고요. (관찰 — 추측이 아니라 행동)
뭔가 잘못됐다는 말이 아니라, 평소와 달라서 마음이 쓰여요. (영향 대신 관심)
업무 때문이든 다른 것 때문이든, 말하고 싶은 만큼만 말해 주면 돼요.
지금 얘기하고 싶지 않으면 그것도 괜찮아요." (다음 — 강요하지 않는 문)

공통 원칙:

  • 사실(녹화 가능한 것)과 해석을 분리합니다. "태도가 나쁘다"는 해석, "회의에서 세 번 말을 끊었다"는 사실입니다.
  • 한 번에 하나의 주제만. 피드백 몰아주기는 모든 메시지를 죽입니다.
  • 빠르게. 사건과 피드백의 간격이 멀수록 효과는 지수적으로 떨어집니다.

받는 기술 — 피드백을 자산으로 만들기

피드백을 잘 받는 능력은 잘 주는 능력보다 희귀하고, 그래서 더 눈에 띕니다.

방어 반응 다루기

비판을 들으면 뇌는 위협 반응을 일으킵니다. 정상입니다. 문제는 그 상태로 입을 여는 것입니다.

방어 반응이 올라올 때의 4단계
1. 멈춤: 첫 문장을 삼킨다 ("아니 그게 아니라..."는 금지)
2. 메모: 들은 내용을 그대로 적는다 (적는 행위가 감정을 식힌다)
3. 명료화 질문: "구체적인 예를 하나 들어줄 수 있어요?"
4. 시간 요청: "중요한 얘기라 생각할 시간을 갖고 싶어요.
   내일 다시 얘기해도 될까요?" — 즉답 의무는 없다

명료화 질문 모음

  • "구체적으로 어떤 상황에서 그렇게 느꼈어요?"
  • "그게 한 번의 일이었나요, 패턴이라고 보세요?"
  • "제가 어떻게 했다면 더 좋았을까요?"
  • "이건 제 성장을 위한 조언인가요, 평가에 영향이 있는 사안인가요?" (중요 — 무게를 확인)

받은 피드백에 동의하지 않아도 괜찮습니다. 다만 "듣고, 이해하고, 검토했다"는 신호는 반드시 줘야 합니다. 동의와 경청은 다른 행위입니다.

상향 피드백 — 매니저에게 말하기

권력 비대칭 때문에 가장 어려운 피드백입니다. 안전한 화법의 핵심은 개인 비판이 아니라 효과에 대한 관찰로 프레임하는 것입니다.

[안전한 상향 피드백 공식]
"저의 일하는 방식 관점에서 공유하면" (주어를 나로)
+ 관찰 가능한 사실
+ 나에게 생긴 영향
+ 요청 (명령이 아니라 실험 제안)

[예시 1 — 마이크로매니징]
"제 작업 방식 관점에서 공유드리면, 진행 중 작업에 하루 두세 번
디테일 확인이 오면 컨텍스트 전환으로 집중 시간이 끊겨요.
일일 요약을 제가 먼저 슬랙에 남기는 방식으로 2주만 실험해 볼 수 있을까요?"

[예시 2 — 방향이 자주 바뀜]
"최근 한 달간 우선순위가 세 번 바뀌면서, 팀이 착수한 작업을
두 번 버렸어요. 변경 자체는 어쩔 수 없다고 생각하는데,
변경 시점에 '무엇이 바뀌어서인지' 배경을 한 줄이라도 공유해 주시면
팀이 납득하고 전환하는 속도가 빨라질 것 같아요."

매니저가 상향 피드백을 받고 싶다면, 먼저 본인의 부족함을 구체적으로 공개하세요. "제가 회의에서 말이 길죠. 줄이려고 하는데 다음에 길어지면 신호 주세요" 같은 자기 공개가 안전감의 마중물이 됩니다.

원격 1:1 팁

  • 카메라보다 산책: 가능하다면 가끔 음성 전용 산책 1:1을 시도하세요. 화면 응시가 사라지면 어려운 주제가 더 잘 나옵니다.
  • 문서 먼저, 화면 공유는 나중: 아젠다 문서를 각자 먼저 읽고 시작하면 30분이 두 배 깊어집니다.
  • 시차가 있다면 비동기 1:1 보완: 주 1회 영상 + 주중 비동기 음성 메모 조합이 효과적입니다.
  • 감정 신호의 대역폭 손실을 의식: 원격에서는 표정과 침묵의 정보가 줄어듭니다. "지금 표정이 잘 안 보여서 그러는데, 방금 제안 어떻게 느꼈어요?"라고 명시적으로 물어야 합니다.

피드백 문화 만들기 — 주기와 심리적 안전

개인기를 넘어 팀 차원의 시스템으로 만들려면:

  1. 주기를 짧게: 연 1회 평가에 피드백을 몰면 반드시 서프라이즈가 생깁니다. 주간 1:1의 가벼운 피드백 + 분기별 정리가 기본 리듬입니다.
  2. 긍정 피드백의 비율: 교정 피드백만 흐르는 팀에서는 피드백 자체가 처벌 신호가 됩니다. 잘한 것을 구체적으로(역시 SBI로) 말하는 빈도가 교정의 3배는 되어야 합니다.
  3. 리더가 먼저 받기: 팀 회고에서 리더가 자신에 대한 피드백을 먼저 요청하고, 받은 것을 실제로 고치는 모습을 보여줄 때 심리적 안전이 생깁니다.
  4. 피드백 요청을 정상화: "이번 발표 어땠는지 한 가지만 말해 줄래요?"를 팀의 일상 언어로 만드세요. 요청된 피드백은 방어를 일으키지 않습니다.

기록과 후속 조치 — 액션 추적

말한 것이 바뀌어야 1:1이 삽니다.

액션 아이템 규칙
- 모든 액션에 담당자와 기한 (없으면 액션이 아니라 희망사항)
- 다음 1:1 첫 2분은 무조건 지난 액션 리뷰
- 3회 연속 이월된 액션은 삭제하거나 재정의 (좀비 액션 금지)
- 커리어 관련 합의는 별도 문서에 누적 (평가 시즌의 근거 자료)

기록은 IC에게 특히 중요합니다. 6개월치 1:1 기록과 액션 완료 이력은 승진 케이스를 만들 때 가장 강력한 1차 자료입니다.

안티패턴 모음

안티패턴증상처방
샌드위치 남용칭찬-비판-칭찬에 메시지가 묻힘교정은 교정대로, 칭찬은 따로
서프라이즈 평가평가 면담에서 처음 듣는 문제주간 피드백 루프로 분산
상태 보고 1:1스탠드업과 같은 내용 반복업무 보고는 비동기로 이관
잦은 취소바쁘면 1:1부터 희생취소 2회 연속이면 아젠다로
매니저 독백말하는 비율 70 대 30 역전질문 후 7초 침묵 훈련
좀비 액션같은 액션이 매주 이월3회 이월 시 삭제 또는 재정의
피드백 몰아주기분기치 피드백을 하루에사건 후 48시간 내 1주제씩

샌드위치 기법에 대해 한마디 더. 칭찬으로 시작해 비판을 끼우고 칭찬으로 닫는 방식은, 받는 사람이 패턴을 학습하는 순간 모든 칭찬을 비판의 전조로 의심하게 만듭니다. 칭찬의 가치까지 파괴하는 이중 손실입니다. 교정 피드백은 존중을 담아 단독으로 전달하는 것이 낫습니다.

함정과 비판적 시각

  • 프레임워크 만능주의 경계: SBI를 외워도 신뢰가 없으면 "잘 짜인 공격"으로 들립니다. 프레임워크는 신뢰 잔고 위에서만 작동합니다. 순서는 관계가 먼저, 기술이 나중입니다.
  • 문화권 차이: 직설의 수용 범위는 문화마다 다릅니다. Radical Candor의 "직접 도전"을 그대로 적용하면 어떤 조직에서는 무례로 읽힙니다. 팀의 컨텍스트에 맞게 강도를 보정해야 합니다.
  • 1:1이 만능은 아님: 구조적 문제(인력 부족, 잘못된 목표)는 1:1로 해결되지 않습니다. 1:1에서 같은 장애물이 3주째 나온다면 그것은 대화의 문제가 아니라 조직의 문제입니다.
  • 기록의 양면성: 1:1 기록이 평가나 법적 절차에 쓰일 수 있는 조직도 있습니다. 민감한 개인사는 기록 범위를 합의하고 남기세요.

최종 체크리스트

IC용

  • 1:1 공유 아젠다 문서가 있고, 24시간 전에 항목을 올리는가
  • 장애물을 옵션+의견 형태로 가져가는가
  • 한 달에 한 번 이상 커리어 주제를 올리는가
  • 피드백을 받으면 명료화 질문을 하고 즉답 대신 검토하는가
  • 상향 피드백을 관찰+영향+실험 제안 형태로 전달하는가
  • 1:1 기록과 액션 완료 이력을 누적하고 있는가

매니저용

  • 말하는 비율이 30 이하인가 (질문 후 7초 침묵)
  • 질문 라이브러리에서 매주 다른 트랙의 질문을 쓰는가
  • 교정 피드백을 사건 후 48시간 내에 전달하는가
  • 긍정 피드백이 교정의 3배 이상인가
  • 평가 면담에 서프라이즈가 없는가 (있다면 내 실패)
  • 팀원에게 나에 대한 피드백을 먼저 요청했는가
  • 액션 아이템에 담당자와 기한이 있고 매번 리뷰하는가

마치며

AI가 코드를 쓰는 시대에 매니저와 IC에게 남는 일의 본질은 결국 사람입니다. 1:1과 피드백은 그 본질을 다루는 가장 작고 가장 자주 반복되는 단위입니다. 거창한 조직 개편 없이도, 다음 주 1:1에 아젠다 문서 하나를 만들고 질문 하나를 바꾸는 것으로 시작할 수 있습니다. 작은 루프가 돌기 시작하면, 신뢰는 복리로 쌓입니다.

참고 자료

Discuss on Twitter • View on GitHub