조직 리팩토링은 누가, 언제 하는가

부제

리더가 저절로 생기지 않는 팀에서 1on1의 주기와 정리의 타이밍을 고민하며

URL

작성일

2026/10/13

사진: m-louis ., 「Pine pruning 2 Akashi, Hyogo, 2021-11-28」. 소나무 가지치기 장면. 원문, CC BY-SA 2.0. 크기 조정 외 변경 없음.

본문

※ 이 글은 2026년 10월까지 공개된 자료를 바탕으로 썼다. 연구 결과와 그에 대한 나의 해석을 구분하려 했다.

오늘 한 동료가 하루 종일 1on1을 돌면서 여기저기 정리를 하고 다니는 모습을 봤다. 누가 무엇을 맡고 있는지, 어디서 일이 막혀 있는지, 다음에는 무엇을 다르게 할지. 옆에서 보기만 했는데도 꽤 많은 에너지가 드는 일이라는 게 느껴졌다.

그걸 보면서 든 생각은 이렇다. 조직 리팩토링은 생각보다 많은 노력이 든다. 그리고 누군가 명시적으로 그 일을 맡지 않으면, 암묵적인 리더십만으로는 해낼 수 없다.

사실 이번 정리는 자연스럽게 시작된 것에 가깝다. 기대했던 결과가 나오지 않는 일이 있었고, 그 일이 모두에게 "이대로는 안 된다"는 신호가 됐다. 그렇다면 질문이 남는다. 그런 일이 없었다면 누가 이 정리를 시작했을까?

그래서 오늘 세 가지를 찾아봤다.

리더 한 명이 자연스럽게 생기지 않는 팀에서는 조직 리팩토링을 어떻게 할 수 있을까.

1on1은 얼마나 자주 하는 게 좋을까.

조직 리팩토링은 언제 해야 할까. 코드와 달리 조직은 살아 있으니까.

이 글에서 따라갈 순서는 이렇다.

암묵적 리더십은 왜 부족한가 → 리더 대신 무엇을 나눠 가질 것인가 → 1on1의 주기 → 코드의 리팩토링과 생명체의 리팩토링 → 그래서 나는 무엇을 해볼 것인가

구조 없는 팀은 없다

"우리 팀은 수평적이라 리더가 따로 없어요." 연구 조직에서 자주 듣는 말이고, 나도 꽤 좋아하는 말이다. 그런데 50여 년 전에 이 말의 함정을 정확히 짚은 글이 있다.

Jo Freeman은 1970년 처음 발표한 「구조 없음의 횡포(The Tyranny of Structurelessness)」에서 이렇게 썼다. 구조 없는 집단이란 존재하지 않는다. 어떤 목적으로든 사람들이 일정 시간 모이면 집단은 반드시 어떤 식으로든 구조를 갖게 된다. 구조를 만들지 않겠다는 선택은 비공식 구조가 생기는 것을 막지 못한다. 공식 구조가 생기는 것만 막을 뿐이다. The Tyranny of Structurelessness

그 결과 의사결정의 규칙은 소수만 알게 되고, 나머지는 무언가 돌아가고 있다는 느낌만 받은 채 혼란스러워한다. 그래서 Freeman의 결론은 단순하다. 모두가 참여하려면 구조는 암묵적이 아니라 명시적이어야 한다.

Freeman이 겨냥한 것은 1960~70년대 여성운동 모임이었지만, 지금 읽어도 연구팀 이야기처럼 들린다. 리더가 없는 팀에도 사실은 늘 누군가 정리하는 사람이 있다. 그 일이 공식적인 역할이 아니면 두 가지가 문제가 된다. 그 사람이 지치면 정리가 멈추고, 그 사람의 판단에 아무도 이의를 제기할 통로가 없다.

오늘 본 장면도 이 틀로 읽힌다. 평소에는 각자 알아서 잘 돌아가던 팀이, 결과가 나오지 않자 누군가 명시적으로 나서야 하는 상황이 됐다. 암묵적인 리더십은 순항할 때는 충분하지만, 방향을 틀어야 할 때는 부족하다.

리더 한 명 대신, 리더십을 나눠 갖기

그렇다고 리더를 한 명 세우는 게 유일한 답은 아니다. 리더가 자연스럽게 생기지 않는 팀이라면 다른 길이 있다. 리더십을 쪼개서 나눠 갖는 것이다.

이 방식이 실제로 효과가 있는지는 꽤 연구가 쌓여 있다. 42개 표본을 모은 메타분석에서 공유 리더십(shared leadership)과 팀 효과성의 상관은 ρ = .34였다. 흥미로운 점은 팀원의 일이 복잡할수록 효과가 더 컸다는 것이다. Wang et al., 2014 50개 효과크기를 모은 다른 메타분석도 공유 리더십과 팀 성과 사이의 양의 관계를 확인했다. D'Innocenzo et al., 2016 연구처럼 정답이 정해지지 않은 일을 하는 팀에 특히 어울리는 결과다.

다만 Wang 등의 메타분석은 무엇을 나눠 갖느냐가 중요하다고도 말한다. 그러면 무엇을 어떻게 나눌까. Freeman은 같은 글에서 구조를 민주적으로 만드는 원칙 일곱 가지를 제안했는데, 그중 몇 가지는 지금 바로 써먹을 수 있다.

•

특정한 일에 대한 특정한 권한을 특정한 사람에게 위임한다. 어쩌다 떠맡은 일은 믿을 만하게 처리되지 않는다.

•

권한을 받은 사람은 그 권한을 준 사람들에게 책임을 진다.

•

역할은 돌아가며 맡는다. 한 사람이 너무 오래 쥐고 있으면 그 사람의 소유물이 되고, 너무 자주 바꾸면 일을 제대로 배울 시간이 없다.

•

정보는 모두에게, 가능한 한 자주 퍼뜨린다.

첫 번째 원칙을 실무 언어로 바꾸면 Apple의 DRI(Directly Responsible Individual)가 된다. 프로젝트마다 성패에 최종 책임을 지는 사람을 한 명 정해 두는 것이다. DRI는 매니저일 수도, 실무자 한 명일 수도 있다. 그 사람이 일을 다 하는 것도 아니다. 다른 사람들과 상의하고 일을 나누되, 일이 되게 만드는 것이 그 사람의 몫이다. GitLab Handbook

Google이 팀 효과성을 연구한 Project Aristotle에서 꼽은 다섯 요소 중 하나인 구조와 명확성도 같은 이야기다. 팀 진단 설문에는 "우리 팀에는 효과적인 의사결정 과정이 있다"는 문항이 들어 있다. Google re:Work

여기서 내가 내린 결론은 이렇다. 리더가 저절로 생기지 않는 팀에서 해야 할 일은 리더를 억지로 세우는 게 아니라, 조직 리팩토링이라는 일 자체에 DRI를 붙이는 것이다. "팀 상태를 점검하고 정리하는 사람"을 역할로 만들고, 프로젝트 주기마다 돌아가며 맡는다. 그러면 정리하던 사람이 지쳐서 멈추는 일도, 정리가 한 사람의 취향이 되는 일도 줄어든다.

1on1은 얼마나 자주

조직 리팩토링의 가장 기본 도구는 결국 1on1이다. 오늘 동료가 한 일도 그것이었다. 그럼 얼마나 자주 해야 할까.

고전적인 답은 Andy Grove의 『하이 아웃풋 매니지먼트』에 있다. 그는 주기를 업무 성숙도(task-relevant maturity)로 정하라고 했다. 그 일에 경험이 적은 사람과는 자주(예를 들어 일주일에 한 번), 노련한 사람과는 덜 자주(몇 주에 한 번) 만나라는 것이다. 그리고 1on1은 팀원의 회의이며, 의제와 분위기는 팀원이 정해야 한다고 강조했다. Lighthouse

최근 연구도 크게 다르지 않다. 회의 연구자 Steven Rogelberg는 지식노동자 1,000명 대상 글로벌 설문을 포함한 세 개의 연구를 바탕으로 세 가지 선택지를 제시한다. HBR, 2022

매주 30분 정도. 직급과 상관없이 가장 선호됐고, 몰입도(engagement)도 가장 높았다.

격주 45~60분. 두 번째로 높은 평가를 받았다.

사람에 따라 주 1회와 격주를 섞는 혼합형.

월 1회는 가장 덜 선호됐고 몰입도 향상도 가장 작았다. 한 달에 한 시간으로는 신뢰를 쌓기 어렵고, 몇 주 전 일은 잘 떠오르지도 않기 때문이다. Gallup의 연구도 같은 방향을 가리킨다. 15~30분짜리 대화라도 자주 하면 30~60분짜리보다 효과가 컸고, 매주 피드백하지 않으면 따라잡기 위해 더 긴 대화가 필요해진다. Gallup

주기만큼 중요한 것도 있다. Rogelberg의 연구에서 1on1의 성공을 가장 잘 예측한 것은 팀원이 말하는 시간의 비율이었고, 이상적인 범위는 50~90%였다. 팀원이 의제를 함께 만들 때 평가가 가장 높았고, 1on1을 자주 취소하면 팀원은 자신이 우선순위에서 밀렸다고 느꼈다.

그런데 이 연구들은 대부분 매니저와 팀원 사이의 1on1을 다룬다. 리더가 따로 없는 팀이라면 어떨까. 여기서부터는 내 해석이다. 나는 앞에서 말한 '정리 담당 DRI'가 이 1on1을 맡으면 된다고 생각한다. 기본은 격주 30분으로 두고, 결과가 안 나왔거나 새 사람이 들어왔거나 방향을 바꾸는 시기처럼 팀이 흔들릴 때는 주 1회로 올린다. Grove의 업무 성숙도를 사람이 아니라 팀의 상태에 적용하는 셈이다. Rogelberg도 팀이 클 때는 팀원끼리 서로 피드백을 주고받는 동료 멘토링을 함께 쓰라고 권한다.

코드의 리팩토링: 조금씩, 늘

이제 마지막 질문이다. 조직 리팩토링은 언제 해야 할까.

먼저 코드의 답을 보자. Martin Fowler는 리팩토링을 일정을 잡아서 하는 큰 행사보다 기회가 될 때마다 하는 일로 권한다. 코드를 보다가 불분명한 곳을 발견하면 그 자리에서, 늦어도 몇 분 안에 고친다. 이른바 캠프장 규칙, 처음 왔을 때보다 더 깨끗하게 해 두고 떠나라는 것이다. 모두가 이렇게 하면 코드베이스는 매일 조금씩 건강해진다. Opportunistic Refactoring

Fowler도 일정을 잡아서 하는 리팩토링에 자리가 있다는 건 인정한다. 다만 기본값은 작고 잦은 정리다. 그리고 그는 조건을 하나 단다. 테스트가 통과하는 상태에서만 리팩토링하라.

조직에도 이 원칙이 꽤 잘 들어맞는다. 정기적인 1on1이 조직의 캠프장 규칙이다. 작은 어긋남을 그때그때 고쳐 두면 큰 재편이 덜 필요해진다.

생명체의 리팩토링: 마디가 있다

하지만 조직은 코드가 아니다. 살아 있다. 그래서 코드에는 없는 성질이 두 가지 있다.

첫째, 조직은 자주 뜯어고치면 다친다. 미국 교통안전위원회(NTSB)가 1994년에 항공 사고를 분석한 보고서에서, 자료가 있는 사고 15건 중 11건(73%)이 기장과 부기장이 처음 같이 비행한 날 일어났다. NTSB, 1994 팀 연구의 대가 J. Richard Hackman이 좋은 팀의 다섯 가지 조건 중 첫 번째로 안정된 팀을 꼽은 것도 같은 맥락이다. Leading Teams 인도의 한 소프트웨어 회사 데이터에서도 팀원들이 서로 같이 일해 본 경험이 많을수록 성과가 좋았다. Huckman et al. 코드는 아무리 자주 리팩토링해도 지치지 않지만, 사람은 구조가 바뀔 때마다 서로에게 다시 적응해야 한다.

둘째, 조직은 정해진 마디에서 바뀐다. Connie Gersick은 1988년 프로젝트 팀 8개를 처음부터 끝까지 관찰했다. 팀들은 단계를 밟아 차근차근 발전하지 않았다. 첫 회의에서 정한 방식을 관성처럼 유지하다가, 주어진 기간의 정확히 절반쯤에서 한꺼번에 바뀌었다. 기간이 일주일이든 6개월이든 그랬다. 이 전환기에 팀들은 옛 방식을 버리고, 바깥의 관리자들과 다시 이야기하고, 새 관점을 받아들이며 극적인 진전을 이뤘다. Gersick은 중간점이 자명종처럼 작동한다고 썼다. 시간이 한정돼 있다는 걸 일깨우고, 지금 있는 곳과 가야 할 곳을 비교하게 만든다는 것이다. Gersick, 1988

이 연구를 읽고 나니 이번 일이 조금 다르게 보였다. 기대한 결과가 나오지 않은 것은 분명 불상사였지만, 팀 입장에서는 자명종이 울린 순간이기도 했다. 문제는 그 자명종이 사고의 모양으로만 울린다는 것이다. 그래서 Gersick의 연구를 실무에 옮긴 글들은 마일스톤을 여러 개 두어 전환점을 일부러 여러 번 만들라고 권한다. APE

팀의 크기도 리팩토링 시점을 알려주는 신호다. Will Larson은 엔지니어링 팀은 평소 6~8명이 적당하고, 4명 미만은 팀이라기보다 개인들의 묶음이라고 말한다. 새 팀이 필요하면 빈 팀을 만들지 말고, 기존 팀을 8~10명까지 키운 다음 둘로 나누라고 한다. Sizing Engineering Teams 팀이 이 범위를 벗어나기 시작하면 구조를 다시 볼 때가 된 것이다.

정리하면 이렇다.

•

작은 리팩토링은 늘 한다. 정기 1on1에서 어긋남을 그때그때 고친다.

•

큰 리팩토링은 마디에서 한다. 프로젝트의 중간점, 결과가 나온 직후, 팀 크기가 바뀔 때.

•

그리고 마디를 사고에 맡기지 않는다. 달력에 미리 새겨 둔다.

아직 배울 게 많다

Fowler의 조건으로 돌아가 보자. 코드에서는 테스트가 통과할 때만 리팩토링한다. 리팩토링은 동작은 그대로 두고 구조만 바꾸는 일이고, 테스트가 그걸 보증해 주기 때문이다.

조직에서 그 테스트에 해당하는 건 뭘까. 나는 신뢰라고 생각한다. 구조가 바뀌어도 우리가 잘하던 일은 계속 잘할 수 있다고 팀원들이 믿을 때, 조직 리팩토링은 비로소 리팩토링이 된다. 그 믿음이 없으면 같은 변화도 그냥 혼란이 된다. 오늘 동료가 한 사람 한 사람과 1on1을 하며 다닌 것도, 어쩌면 구조를 바꾸기 전에 테스트부터 초록불로 만드는 과정이었는지 모른다.

그래서 내가 해보고 싶은 것은 세 가지다. 조직을 정리하는 일에 이름과 담당자를 붙이고 돌아가며 맡는 것. 1on1을 격주로 두되 팀이 흔들릴 때는 주 1회로 올리는 것. 그리고 큰 정리의 날을 사고가 아니라 달력이 정하게 하는 것.

물론 이건 오늘 하루 찾아본 것으로 세운 가설이다. 조직은 생명체라서, 실제로 해보면 또 다른 답이 나올 것이다. 아직 배울 게 많다.