[iid] 조직 운영의 균형(正反合) 잡기 가이드
이드의 HR Quicknote
[Edited by iid the HRer]
※ Quicknote는 '스타트업HR모험기'의 쇼츠(Shorts) 버젼으로 개인적인 경험/고민을 바탕으로 작성되었다.
✅ 고민/상담이 있다면 커피챗 w iid' ( 신청 링크 )
균형은 타협이 아니다
우리가 오해하는 ‘균형’
우리는 흔히 ‘균형’이라는 말을 들으면, 양쪽의 의견을 잘 절충해낸 어떤 ‘중간값’을 떠올린다. 조금씩 양보하면 모두가 만족할 수 있을 거라는, 어딘가 이상적인 지점 말이다. 하지만 실제 조직 운영에서의 균형은 그런 정적이고 안전한 형태가 아니다.
균형은 ‘가운데’가 아니라, 서로 충돌하는 힘 사이에서 만들어지는 긴장 상태다.
예를 들어 자율을 강조하면 몰입과 창의성이 높아지지만, 동시에 책임 경계는 흐려진다. 위임이 늘어나면 팀의 실행력은 강해지지만, 전체 전략과의 연결은 약해질 수 있다. 수평성이 강화되면 심리적 안정은 좋아지지만, 결정과 실행은 느려진다. 그리고 이 균형의 붕괴는 아주 느리고 조용하게 다가온다.
이런 맥락에서 HR이 해야 할 일은 ‘좋은 제도를 강화하는 것’이 아니라, 그로 인해 발생할 수 있는 반작용까지 설계하는 것이다.
조직 운영에서의 균형은 정반합(正反合)의 흐름을 따른다. 어떤 하나의 운영 원칙(正)을 밀어붙이면, 그 반작용(反)이 반드시 따라오고, 그 두 힘이 충돌하는 가운데, 새로운 질서(合)가 만들어지는 것이다.
정(正) : 하나의 원칙을 강화한다. (예: 자율 강조)
반(反) : 그로 인한 균열이 드러난다. (예: 책임 회피)
합(合) : 양쪽의 충돌을 넘어선 새로운 질서를 만든다. (예: 책임 기반 자율체계)
이것은 단순한 ‘절충안’이 아니다. 정과 반이 충돌하는 그 한가운데서, 조직이 다음 단계로 나아가기 위한 더 강한 설계를 만드는 일이다. 균형이란, 멈춰 서 있는 상태가 아니라, 충돌을 받아들이고 새로운 흐름을 만들어내는 일이다.
조직 운영의 정반합, 어떻게 만들 것인가?
그렇다면 HR은 어떻게 이 균형을 구현할 수 있을까? 정답은 없다. 대신 ‘질문’이 있다. 조직이 마주하는 주요 운영 가치마다, HR은 아래와 같은 질문을 던져야 한다
이 질문 하나하나가 정반합의 설계를 요구한다. 그리고 바로 이 충돌을 조율해내는 기술이, HR의 진짜 실력이다.
정반합은 이론이 아니다. 조직이라는 유기체 안에서는 어떤 선택이든 반드시 반작용이 따라온다. 좋은 개념은 언제나 현장에서 검증되어야 하고, 정교한 설계는 바로 그 충돌 속에서 태어난다. 이 흐름을 읽으면, HR이 해야 할 일이 ‘강화’가 아니라 ‘충돌을 넘는 설계’임을 알 수 있다.
[사례 ①] 자율 강화의 그림자 → 책임 회피 → 기준의 재구성
어느 스타트업은 '몰입을 위해선 자율이 답'이라며 출퇴근도, 보고 체계도 없앴다. 초기 6개월간은 놀라웠다. 빠른 실행, 창의적인 시도, 몰입도 상승. 그러나 곧, 프로젝트 우선순위는 엇갈리고, 책임자는 누구인지 모호해졌다. 이 조직은 자율(正)을 극단까지 밀어붙인 뒤 혼란(反)에 봉착했다. 그러나 HR은 다시 ‘관리’를 도입하지 않았다. 대신 역할별 기준표를 만들었다. 자율 안에서 책임을 명확히 하는 설계(合)였다. 자율은 지키되, 기준은 세운 것. 그게 조직을 다시 굴러가게 만들었다.
[사례 ②] 수평성 강화의 딜레마 → 의사결정 정체 → 구조적 조율
어느 회사는 수평성에 진심이었다. 직급 없이 모두가 친구처럼 지냈다. 그런데 문제가 생겼다. 중요한 이슈 앞에서 누구도 결정을 내리지 않았다. 모두의 의견을 듣는 회의는 많았지만, 끝나고 나면 다음 단계가 없었다. HR은 회의 체계를 바꾸지 않았다. 대신 ‘의사결정 권한맵’을 설계했다. 누가 결정할지, 누구와 협의할지, 언제 실행할지를 명확히 한 것. 수평성(正)을 유지하면서, 실행 지연(反)을 넘어 구조적 질서(合)를 만든 셈이다.
[사례 ③] 위임 확대의 반작용 → 전략 일관성 붕괴 → 목표 재정렬
회사의 성장 속도에 맞춰 각 팀에 강한 권한을 부여한 조직도 있었다. 자율적 실행은 살아났지만, 방향은 팀마다 달랐다. 결국 ‘회사는 어디로 가고 있는가’에 대한 감각이 사라졌다.이때 HR은 위임(正) 자체를 회수하지 않았다. 대신 ‘OKR 기반 목표 연동 시스템’을 도입했다. 각 팀은 자유롭게 목표를 정하되, 상위 전략과 연결된 구조 안에서만 움직일 수 있게 설계한 것이다. 정렬을 회복한 것이 아니라, 방향성과 자율성을 동시에 세운 것. 이것이 합(合)이었다.
조직에서 균형은 '세운다'기보다는 '만들어지는 것'에 가깝다. 제도를 기획하는 것과, 그것이 실제 조직 안에서 작동하도록 설계하는 것은 완전히 다른 기술이다. 특히 HR이 다루는 균형은 정적인 틀보다, 긴장과 파동을 어떻게 다루느냐에 따라 성패가 갈린다. 그 긴장은 설득이 아니라, 경험과 리듬을 통해 체화된다.
✅ 작은 실험으로 시작하라
대부분의 HR 설계 실패는 ‘좋은 제도’가 없어서가 아니라, ‘너무 갑작스럽고 크기 때문’이다. 조직은 본질적으로 변화를 두려워한다. 아무리 좋은 제도라도 갑자기 전사 재택제를 실시하거나, 보고 체계를 급격히 강화하면 반감부터 생긴다. 그래서 균형 설계는 언제나 ‘작은 실험’으로 시작해야 한다. 단일 팀, 단일 사례, 단일 상황에서 ‘예외’를 먼저 만들어 보는 것이다. 실험은 리스크를 줄이고, 시행착오를 통해 맥락을 확보하게 만든다. 결과가 좋다면 확산하고, 반응이 미미하면 조정하고 철회할 수 있다. 이런 접근은 HR이 ‘완성된 구조’를 정답처럼 들이밀지 않고, ‘흐름 위에서의 설계자’ 역할을 하게 만든다.
✅ ‘중간 설계자’로서 리더를 활용하라
모든 실행은 현장에서 구현된다. 특히 팀 단위의 리더는 HR과 구성원 사이의 설계자이자 번역자다. HR이 아무리 정교한 기준을 만들어도, 그것을 리더가 설득력 있게 적용하지 못하면 조직은 반발한다. 그래서 HR은 팀 리더들을 ‘정답 전달자’가 아니라 ‘균형 실험의 중간 설계자’로 키워야 한다. 예를 들어 “일괄적으로 주 1회 재택근무”라는 지침이 아니라, “각 팀이 성과와 리스크 기준을 정해 자율적으로 재택근무를 설계하되, 2주간 사례를 공유하자”는 식의 접근이 필요하다. HR은 리더가 그 긴장을 감각적으로 느끼고, 자기 방식으로 적용할 수 있도록 돕는 구조를 만드는 것이 중요하다.
✅ 경험에서 인식이 나오게 하라
조직은 말로 바뀌지 않는다. 특히 균형이나 정반합처럼 복잡한 개념은 강의나 공지로는 체감되지 않는다. 그래서 HR은 조직이 직접 경험을 통해 ‘스스로 느끼게’ 해야 한다. 예를 들어 수평성 강화 이후 회의가 늘어지고 실행 속도가 떨어졌다면, 그 사실을 단순히 경고하기보다는 데이터를 통해 ‘보여줘야’ 한다. “회의 발언 빈도수”와 “결정 지연 건수”를 비교해서 공개하면 구성원 스스로 체감한다. HR은 데이터와 흐름을 연결해, 조직이 스스로 균형을 감각할 수 있는 ‘운영 언어’를 만들어야 한다. 인식은 언제나 체험에서 나온다.
✅ 결과보다 흐름을 먼저 설계하라
좋은 HR은 단기 성과를 위한 제도를 만드는 것이 아니라, 그 성과가 반복적으로 나오는 흐름을 설계하는 데 있다. 처음부터 완성형 제도를 내놓기보다는, 흐름 안에서 정합의 사이클이 반복될 수 있도록 설계하는 것이 중요하다. 예를 들어 “OKR을 전사적으로 도입하자”는 접근보다, “현재 목표 간 단절이 문제다 → 팀별로 상위 목표와 연동 실험 → 결과를 통해 구조 설계”라는 식의 접근이 더 강력하다. 이 방식은 조직이 제도를 받아들이는 과정을 하나의 리듬으로 만들며, 실질적인 내재화를 유도한다. 즉, 정답이 아니라 경로를 설계하는 것. 이것이 정반합의 작동 방식이다.
✅ 피드백 프로세스를 구조화하라
균형은 한 번 맞췄다고 끝나는 것이 아니다. 조직은 끊임없이 바뀌고, 리더도, 사람도, 상황도 모두 달라진다. 그래서 초기 설계가 아무리 정교해도, 일정 시간이 지나면 다시 균형이 흔들릴 수밖에 없다. 그래서 HR은 이 균형의 ‘흔들림’을 감지하고, 다시 조정할 수 있는 피드백 구조를 미리 내장시켜야 한다. 예를 들어 제도 도입 후 3개월 뒤, 팀별 현장 리포트와 1:1 인터뷰를 수집하고, 리더 간 설계 리팩토링 워크숍을 진행하는 방식이다. 이는 단순한 설문조사가 아니라, 흐름의 긴장을 다시 분석하고 구조를 재설계하는 ‘순환 메커니즘’을 의미한다. HR의 진짜 역할은 바로 이 반복 가능성, 즉 피드백 구조를 설계하는 데 있다.
※ 전체 Full version은 아래 링크를 확인바랍니다.
