<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:media="http://search.yahoo.com/mrss/">
  <channel>
    <title>Team Norms · 인재덕</title>
    <link>https://jared.lynskey.co.nz/ko/tags/team-norms/</link>
    <description>소프트웨어 엔지니어링과 개발 조직 리더십에 대한 이야기. 성과 리뷰, 채용과 팀 확장, CI/CD, 데브옵스 모니터링, 에이전틱 AI. 서울에서 씁니다.</description>
    <generator>Hugo</generator>
    <language>ko</language>
    <copyright>© 2026 인재덕</copyright>
    <lastBuildDate>Wed, 28 Oct 2026 00:00:00 +1300</lastBuildDate>
    <atom:link href="https://jared.lynskey.co.nz/ko/tags/team-norms/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>개발팀에 정말로 정착하는 팀 규범 만들기</title>
      <link>https://jared.lynskey.co.nz/ko/posts/2024/2024-05-05-team-norms/</link>
      <guid isPermaLink="true">https://jared.lynskey.co.nz/ko/posts/2024/2024-05-05-team-norms/</guid>
      <pubDate>Sun, 05 May 2024 00:00:00 +0000</pubDate>
      <dc:creator>Me</dc:creator>
      <category>team norms</category>
      <category>collaboration</category>
      <category>leadership</category>
      <description>엔지니어링 매니저가 된 지 몇 달, 팀 규범에 대해 생각한 것들. 재능보다 팀이 일하는 방식이 중요하다고 저를 설득한 Google 연구(Project Aristotle) 이야기도 함께.</description>
      <content:encoded><![CDATA[<p>개발팀을 맡은 지 몇 달이 지나면서 알게 된 게 하나 있습니다. 제가 매일 다루는 마찰의 대부분은 기술 문제가 아니라는 겁니다. 코드 리뷰는 얼마나 빨리 돌려줘야 하는지, &ldquo;완료&quot;는 어디까지를 말하는지, 슬랙에서 두 번째 핑을 보내는 게 무례한 건지. 누구도 틀리지 않았어요. 그냥 규칙을 정한 적이 없었을 뿐이죠.</p>
<p>이 문제의 해결책에는 팀 규범이라는 재미없는 이름이 붙어 있습니다. <a href="https://www.ccl.org/articles/leading-effectively-articles/the-real-world-guide-to-team-norms/"  target="_blank" rel="noreferrer">Center for Creative Leadership</a>은 &ldquo;팀원들의 상호작용을 형성하는 규칙 또는 운영 원칙의 집합&quot;이라고 정의하는데, HR 서류 작업처럼 들리지만 사실은 다들 당연하다고 여기던 것들을 글로 적어두는 일일 뿐입니다.</p>

<h2 class="relative group">저를 설득한 연구
    <div id="저를-설득한-연구" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%ec%a0%80%eb%a5%bc-%ec%84%a4%eb%93%9d%ed%95%9c-%ec%97%b0%ea%b5%ac" aria-label="앵커">#</a>
    </span>
    
</h2>
<p><a href="https://rework.withgoogle.com/intl/en/guides/understanding-team-effectiveness"  target="_blank" rel="noreferrer">Google의 Project Aristotle</a>은 사내 180여 개 팀을 조사해서 좋은 팀은 뭐가 다른지 알아내려 했습니다. 결과는 의외였습니다. 팀에 누가 있는지보다 팀이 어떻게 함께 일하는지가 훨씬 중요했다는 겁니다. 아무리 뛰어난 사람들을 모아도 일하는 방식에 대한 합의가 엉망이면 평범한 결과밖에 안 나옵니다.</p>
<p>이 연구는 강한 팀을 구분 짓는 <a href="https://psychsafety.com/googles-project-aristotle/"  target="_blank" rel="noreferrer">다섯 가지 요소</a>를 찾아냈습니다. 심리적 안전감, 신뢰성, 구조와 명확성, 의미, 영향력. 그중에서도 심리적 안전감이 제일 큰 역할을 했습니다. 바보 같은 질문을 해도, 실수를 인정해도 손해 보지 않는다는 느낌 말이죠. <a href="https://www.leaderfactor.com/learn/project-aristotle-psychological-safety"  target="_blank" rel="noreferrer">여기에 붙는 숫자들</a>은 무시하기 어렵습니다. 성과 분산의 43%를 설명하고, 생산성 19% 향상, 혁신 31% 증가, 이직률 27% 감소.</p>
<p>이 목록에서 마음에 드는 점은, 다섯 가지 중 어느 것도 타고나는 성격이 아니라는 겁니다. 전부 팀이 의도적으로 만들 수 있는 것들이고, 그걸 만드는 도구가 바로 규범입니다.</p>

<h2 class="relative group">일상에서 규범은 이런 모습입니다
    <div id="일상에서-규범은-이런-모습입니다" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%ec%9d%bc%ec%83%81%ec%97%90%ec%84%9c-%ea%b7%9c%eb%b2%94%ec%9d%80-%ec%9d%b4%eb%9f%b0-%eb%aa%a8%ec%8a%b5%ec%9e%85%eb%8b%88%eb%8b%a4" aria-label="앵커">#</a>
    </span>
    
</h2>
<p>회의부터 시작하는 게 제일 쉽습니다. 나쁜 습관이 눈에 잘 보이거든요. 안건은 미리 공유하고, 정시에 시작해서 정시에 끝내고, 반박하기 전에 상대방 말을 먼저 요약합니다. 저는 <a href="https://www.ntaskmanager.com/blog/12-examples-of-team-norms-to-help-you-create-a-high-performing-team/"  target="_blank" rel="noreferrer">안건 없으면 회의도 없다</a>는 단호한 버전을 좋아합니다.</p>
<p>커뮤니케이션 규범은 더 중요하지만 눈에 덜 띕니다. 제 원칙은 이렇습니다. 애매하면 과하다 싶을 만큼 공유하고, 결정 사항은 누구나 찾을 수 있는 곳에 기록하고, 회의를 유일한 채널로 두지 않는다. 여덟 명이 모인 자리에서 절대 입을 안 여는 사람이 꼭 있으니, 그런 분들에게는 직접 찾아가 물어봅니다. <a href="https://www.focuspeople.com/2024/02/23/building-high-performing-teams-x-strategies-for-success/"  target="_blank" rel="noreferrer">다양한 관점을 가진 팀</a>이 동질적인 팀을 이긴다는 연구는 많지만, 그 관점이 실제로 입 밖에 나왔을 때 얘기입니다.</p>
<p>의견 충돌이 생기면 일단 선의를 가정하고, 사람이 아니라 문제와 싸우고, 상대가 내세우는 입장이 아니라 실제로 필요한 게 뭔지 파고듭니다. 도저히 안 끝나는 싸움은 중립적인 제3자에게 맡깁니다.</p>

<h2 class="relative group">관료주의로 만들지 않고 규범 정하기
    <div id="관료주의로-만들지-않고-규범-정하기" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%ea%b4%80%eb%a3%8c%ec%a3%bc%ec%9d%98%eb%a1%9c-%eb%a7%8c%eb%93%a4%ec%a7%80-%ec%95%8a%ea%b3%a0-%ea%b7%9c%eb%b2%94-%ec%a0%95%ed%95%98%ea%b8%b0" aria-label="앵커">#</a>
    </span>
    
</h2>
<p><a href="https://www.ccl.org/articles/leading-effectively-articles/the-real-world-guide-to-team-norms/"  target="_blank" rel="noreferrer">CCL이 추천하는</a> 방식은 이론이 아니라 경험에서 출발하는데, 저도 이쪽이 맞다고 봅니다. 각자 지금까지 겪은 최고의 팀과 최악의 팀을 이야기하고, 무엇이 그 팀을 그렇게 만들었는지 같이 파헤치고, 거기서 나온 패턴을 지금 팀을 위한 구체적인 행동으로 바꿉니다. 위에서 내려주는 게 아니라 토론해서 합의하는 거죠. 누군가 규범을 어겼을 때 어떻게 할지도 미리 정해두고(매니저가 어긴 경우 포함), 잘 보이는 곳에 적어두고, 가끔 다시 들여다봅니다.</p>
<p>하나만 덧붙이자면, 처음에는 3~5개로 시작하세요. 규범은 습관이 되어야 작동하는데, 습관 열 개를 한꺼번에 들이는 사람은 없습니다.</p>

<h2 class="relative group">무너지는 지점
    <div id="무너지는-지점" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%eb%ac%b4%eb%84%88%ec%a7%80%eb%8a%94-%ec%a7%80%ec%a0%90" aria-label="앵커">#</a>
    </span>
    
</h2>
<p>규범을 가장 빨리 죽이는 건 규범을 무시하는 리더입니다. 제가 바쁘다는 핑계로 안건 규칙을 건너뛰면 팀은 바로 알아챕니다. 그 순간부터 전부 연극이 되죠. 규범의 문구보다 책임자의 일관성이 훨씬 중요합니다.</p>
<p>그 밖에 조심할 함정도 몇 가지 있습니다. 신규 입사자가 규범을 온보딩에서 명시적으로 듣는 게 아니라 구전 설화처럼 주워듣게 되는 것, 글로벌 팀에서 내 기준이 모두의 기준이라고 착각하는 것(암묵적인 전제일수록 명시적으로 만들어야 합니다), 그리고 이 모든 걸 요식 행위로 여기는 사람들. 마지막 경우엔 설교가 아니라 규범 만들기에 직접 참여시키는 게 제일 잘 먹힙니다.</p>
<p>규범이 어디서 강화되는지 알아두는 것도 도움이 됩니다. 고성과 팀 연구에서는 <a href="https://informedi.org/2024/08/30/new-rules-for-teamwork/"  target="_blank" rel="noreferrer">같은 세 가지 습관</a>이 반복해서 발견됩니다. 제대로 된 킥오프, 정기적인 원온원, 그리고 회고. 합의가 만들어지고, 시험받고, 조용히 갱신되는 곳은 그런 자리지 정책 문서 안이 아닙니다.</p>
<p>규범이 마법이라고 생각하진 않습니다. 다만 Google의 데이터가 가리키는 방향은 지금까지 제 경험과 같습니다. 팀이 함께 일하는 방식이 멤버 구성을 이깁니다. 그래서 우리 팀 규범은 짧게 유지할 생각입니다. 합의 몇 개를 모두가 보는 곳에 적어두고, 현실과 안 맞으면 고치고요. 정착했는지는 6개월 뒤에 물어봐 주세요.</p>
]]></content:encoded>
      <media:content url="https://jared.lynskey.co.nz/en/posts/2024/2024-05-05-team-norms/featured.jpg" medium="image" type="image/jpeg" />
    </item>
  </channel>
</rss>
