Gsong's Blog

도 닦는 개발자 패턴

Tue, 13 Jan 2026 00:00:00 +0900

도 닦는 개발자: 침묵 속에 팀을 늪으로 빠뜨리는 패턴

패턴 설명

본인은 무언가 열심히 하고 있는 것처럼 보이지만, 정작 가시적인 결과물(유의미한 코드, PR 등)이 나오지 않아 전체적인 팀 속도를 저하시키는 패턴이다. 마치 깊은 산속에서 도를 닦듯 자기만의 세계에 빠져 있으며, 외부와의 소통 반응 속도가 매우 느린 것이 특징이다.

패턴 증상

반응 지연: 이메일이나 메신저 확인이 지나치게 늦다. 해당 인원이 대화에 참여하는 순간 전체 협업 프로세스의 속도가 급격히 떨어진다.
낮은 가시성: 자리에 앉아 무언가에 몰두하고는 있으나, 하루가 지나도 유의미한 코드나 업데이트가 없다. 진척 상황을 묻기 전에는 먼저 공유하는 법이 없다.
기록 및 공유의 부재: 회의나 지시 사항을 메모하지 않는다. 자신의 기억력을 과신하지만 정작 중요한 요구사항을 놓치기 일쑤다. PR 수정 완료와 같은 사소한 변경점조차 팀에 공유하지 않아 불필요한 대기 시간을 발생시킨다.
전반적인 저속화: 위 증상들이 결합되어 업무 처리 속도가 현저히 낮아진다. 특히 언어(말, 글)를 통한 소통과 코딩 결과물 산출물 모두에서 병목 현상을 일으킨다.

패턴 원인

목표 의식 부재: 일을 ‘완수’하는 것보다 ‘하는 행위 자체’에 매몰된다. 프로로서 결과물을 내야 한다는 열망보다 과정에서의 결벽증에 더 집중한다.
메타인지 부족: 본인이 현재 효율적으로 일하고 있는지, 방향이 맞는지 스스로 점검하는 능력이 결여되어 있다. 5분만 물러나 생각하면 보일 비효율을 껴안고 몇 시간을 허비한다.
커뮤니케이션 기술 결여: 소통을 업무의 연장이 아닌 ‘방해 요소’로 인식한다. “코드로 보여주면 된다”고 믿지만, 정작 그 코드조차 제때 보여주지 못하고 있다는 사실은 인지하지 못한다.

패턴 해결

강제적 피드백 루프 설정: 업무 중 주기적으로 하던 일을 멈추고 현재의 방향성을 점검하는 시간을 갖도록 가이드한다.
커뮤니케이션 규칙 명문화: 메신저 알람 설정 및 메시지 확인 후 일정 시간 이내 반응(이모지 응답 등)을 최소한의 프로토콜로 강제한다.
가시적 결과물 단위 쪼개기: 업무를 ‘기능’ 단위가 아닌 ‘시간’ 단위(2시간, 반나절 등)로 잘게 쪼개어 가시적인 진척도를 보고하게 한다.
기록의 시스템화: 모든 지시 사항은 공유 문서에 기록하게 하며, 작업 완료 시 즉시 담당자를 멘션(@)하는 행위를 업무 프로세스에 필수적으로 포함시킨다.
1:1 면담을 통한 현실 자각: “코드 자체의 문제가 아니라, 소통 지연과 기록 부재라는 ‘태도’가 본인의 기술적 가치를 갉아먹고 있다”는 점을 명확히 고지한다.

결론

도 닦는 개발자들은 관리 비용이 많이 든다. 운좋게 깊은 깨달음을 얻어 좋은 코드를 쏟아내면 다행이지만, 대부분은 그러한 갑작스러운 깨달음을 얻는데 실패한다. 왜냐하면 소프트웨어 개발은 혼자 수행하는 예술 활동이 아니라, 팀이 함께 움직이는 비즈니스 프로세스이기 때문이다. 아무리 정갈한 코드를 일필휘지로 짠다 한들, 제때 공유되지 않고 협업의 흐름을 끊는 작업은 팀에 오히려 해악을 끼친다. 결국 개발자에게 소통과 공유는 단순한 매너가 아니라, 기술 역량의 일부이다. 팀의 속도에 발을 맞추며 스마트하게 일하는 법을 익히는 것은 프로 개발자로서 생존하기 위한 필수 조건이다.

나의 개발 커리어 요약: 네번째 회사, 스마트TV 스타트업

Tue, 29 Jul 2025 00:00:00 +0900

이전 글: 나의 개발 커리어 요약: 세번째 회사, 외국계 기업에서 사무용 애플리케이션 개발

외국계 기업에서 5년 정도 근무할 때쯤이었다. 당시 스타트업 붐이 일고 있었고, 스마트폰이 열어젖힌 시장에서는 하루가 멀다 하고 새로운 앱들이 쏟아져 나왔다. 나 또한 막연히 꿈꿨던 벤처 회사의 달콤한 장밋빛 상상에 점점 빠져들고 있었다. 그때 일하던 외국계 회사 팀은 성장이 정체된 상태였다. 업무 영역에 변화가 없었고, 변화를 만들 힘도 부족했다. 일본을 중심으로 한 극동지사 개발팀의 한 갈래였는데, 로컬라이제이션 문제를 해결해주는 글로벌 툴 및 라이브러리가 개발되면서 로컬 개발팀의 존재 이유는 사라지는 중이었다. 뛰어난 관리 기술을 바탕으로 직원들을 바쁘게 만드는 데는 능숙했으나, 팀 자체가 노쇠하여 도전 정신을 찾아보기 어려웠고, 외국계 기업 특성상 그런 직원들이 많지도 않았다.

그러던 중 스타트업을 창업한 선배를 만나 이직을 결심하게 되었다. 그 스타트업은 스마트 TV에 대한 비전을 가지고 셋톱박스 제품을 만드는 곳이었다. 셋톱박스는 고등학교 때 빌 게이츠의 ‘미래로 가는 길’이라는 책을 읽으면서 처음 접한 단어였다. 그때는 아직 인터넷도 보급되지 않았던 때였고, TV는 지붕 위 안테나나 아파트 단지에 공급되는 동축 케이블로 볼 수 있었기에 셋톱박스가 무엇인지 전혀 알 길이 없었다. 빌 게이츠는 그 책에서 각 가정에 PC 한 대씩이라는 비전을 이룬 후 다음으로 중요한 시장이 각 가정의 TV를 점령하는 것이라고 내다봤던 것 같다. 그래서 엑스박스 제품을 개발하고 출시하게 된다.

물론 그것은 대기업의 이야기이고, 한국의 작은 스타트업, 심지어 투자금마저 넉넉지 않은 우리 스타트업의 이야기는 아니었다. 옮겨간 스타트업 회사는 한국에서는 보기 드물게 말 그대로 차고 스타트업(garage start-up)이었다. 주택이 많은 미국 등에서는 흔한 형태였지만, 아파트가 많은 한국에서는 개인 차고가 있는 경우가 아주 드물었기 때문이다. 사실은 투자사의 사무실 겸 인큐베이팅 공간으로 쓰던 주택 차고에 붙어 있는 창고 공간이었다. 그때 당시만 해도 지금과 같은 스타트업 지원 센터가 생기기 전이었으니, 이 정도도 아주 좋은 혜택이었다고 볼 수 있다.

비용을 아끼는 만큼 써야 할 부분에는 확실히 알뜰하게 쓰면서 진행해야 하는 것이 스타트업이다. 하지만 이직하고 나서 알게 된 사실은 당시 회사에 남은 투자금이 얼마 없었다는 것이다. 정확히는 1년을 더 버티기 어려운 상황이었다. 이런 재정 상태에서 왜 나를 스카우트해 온 건가 싶은 생각이 들 법도 했으나, 이제 막 시작한 스타트업 라이프의 단꿈에 빠져 있던 나로서는 멋진 제품을 만들어 해결하면 될 일이라고 생각했다. 그만큼 어설펐다는 말이다.

첫 번째 진행했던 프로젝트는 차량 내 DVD 스트리밍 기기였다. 당시만 해도 DVD로 영화를 보는 것이 일반적이었는데, 차량 내에 DVD 스트리밍 기기를 설치하고 디스크를 넣으면 스마트폰으로 스트리밍을 쏴서 차량 내에서 관람할 수 있도록 하는 프로젝트였다. 모 대기업의 개념 증명(PoC)을 외주로 진행하는 건이었다. DVD를 통해 디코딩된 영상을 HLS(HTTP Live Streaming)로 쏴주는 임베디드 소프트웨어를 개발하면 되었다. 동작하는 제품 개발까지는 진행되었으나 그다음 단계 개발은 더 이상 진행되지 못하고 중단되었던 것으로 기억한다.

그다음 프로젝트는 안드로이드 기반 영화 플레이어였다. 애플 TV 형태로 소장하고 있는 영화들을 둘러보고, 선택해서 재생하는 기능이었다. 문제는 이 기기에서 재생될 영화를 어떻게 수급해 올 것인가 하는 것이었는데, 작은 스타트업으로서는 이 문제를 제대로 해결하기 어려웠다. 그래서 데모용 기능으로 웹하드를 통합하는 작업을 하려고 했다. 몇 년 전부터 웹하드를 통한 불법 다운로드가 문제가 많이 되었고, 그로 인해 웹하드에서 불법 다운로드를 근절하고 과금 방식으로 변경하기 위해 제휴된 영화 파일을 검색에 노출시켜 다운로드할 수 있도록 해놓고 있었다. 구현하려 했던 기능은 특정 웹하드 계정 연동을 해두면, 기기에서 구매한 영화의 다운로드를 진행한 후 TV를 통해 관람하는 기능이었다.

그 외에도 몇몇 프로젝트가 더 있었던 것 같은데 이제는 오래되어 잘 기억이 나지 않는다. 당시 근무하며 블로그에 기록들을 남기기도 했으나, 지금 보니 프로젝트의 구체적인 내용에 대해서는 언급하지 않았던 모양이다. 아마도 그런 아이디어조차도 너무 소중하여 블로그에 공개했다가 일을 망치면 어떡하나 하는 마음이었을 것이다.

당시 팀은 영업 1인(대표)에 엔지니어 4~5인으로 구성되어 있었고, 엔지니어 위주의 빠른 개발 속도를 강점으로 하는 팀이었다. 실리콘밸리에서 시작된 창업 스타일이었는데, 개발 이외의 작업은 외주로 해결하고 특급 개발자들만 모아서 제품 개발 속도를 최대한 빠르게 끌어올리는 방식이었다. 여기에는 여러 장점이 있는데, 그중 하나는 회사가 폐업하더라도 엔지니어로만 구성된 팀은 다른 곳에서 언제든 인수 후 고용(acqhire)하기 쉽다는 것이었다. 일종의 엑싯 플랜(exit plan)에서 안전장치를 만들고 진행하는 셈이다. 하지만 달의 밝은 면이 있으면 어두운 면도 있는 법이다. 이 접근법은 지금 와서 돌이켜보면 당시 팀에는 맞지 않는 방법이었다고 생각한다.

진행했던 프로젝트들은 PoC를 하고자 하는 목적은 달성했으나 그 후 제품 개발로까지 이어지지는 못했다. 앞서 말했듯이 회사 운영 자금은 거의 바닥나 있는 상태였다. 이미 개발 완료한 제품들이 있으니, 외주 용역이라도 해서 시간을 벌어보자는 의견들이 있었으나, 어떤 이유로 인해 외주 용역은 진행하지 않았고, 폐업의 힘든 시기를 맞이하게 된다.

지금 와서 이때를 돌이켜보면, 몇 가지 패인을 찾을 수 있다. 첫째는 엔지니어로만 팀을 구성한 것이다. 이는 전적으로 앱 기반의 창업에는 효과적인 접근이지만, 하드웨어 제품의 경우에는 엔지니어들만으로는 사업의 활로를 뚫기에는 역부족이다. 양산을 위한 부품 수급 문제부터 완성된 제품을 판매하기 위한 영업력이 하드웨어 사업의 대부분이기 때문이다. 애초에 참고한 접근법은 이 영역에서는 통하지 않는 문제였다. 두 번째는 외주 용역을 보다 더 적극적으로 하지 않은 점이었다. 나 자신도 해당하지만, 임베디드 개발을 해보지 않은 개발자가 해당 영역에서 어느 정도 숙달이 되려면 전적으로 시간과 시행착오를 거쳐볼 프로젝트가 필요하다. 이 비용을 해결하기에 외주 용역은 아주 적절한 선택지였으나 택하지 않았다.

스타트업이 망하는 이유는 셀 수 없이 많지만 지금 크게 생각나는 건 이 두 가지 정도이다. 나는 이직하고 그다음 해 12월에 퇴사하게 되었고, 나머지 분들은 그대로 팀을 유지하다가 급성장하던 다른 스타트업에 팀 전체로 합류하게 되었다. 이때의 경험에서 나 스스로도 깨달은 게 적지 않았다. 무엇보다 큰 깨달음 중 하나는 그 전 회사에서 배우고 익혀 내 것이 되었다고 믿었던 많은 것들이 사실은 그 회사의 인프라 위에서만 구현 가능한 것들이라는 점이었다. 개발 방법론이나 소프트웨어 공학 측면에서 시도할 수 있었던 것들의 상당수는 이를 뒷받침해주는 인프라가 넉넉한 대기업이니까 할 수 있는 것들이었고, 매일 생존을 고민해야 하는 스타트업에서는 사치에 가까운 것들이 많았다.

이 시기를 통해 나는 이상과 현실의 괴리를 뼈저리게 느꼈다. 스타트업의 역동성과 새로운 기술에 대한 갈망은 여전했지만, 사업의 본질과 생존 전략에 대한 깊은 이해가 필요하다는 것을 깨달았다. 단순한 기술 개발을 넘어 시장성, 자금 확보, 그리고 사업 운영의 현실적인 측면을 고려해야 한다는 값진 교훈을 얻은 시간이었다. 이는 이후 나의 개발 커리어에 큰 영향을 주었으며, 다음 스텝을 고민하는 데 중요한 전환점이 되었다.

트집쟁이 패턴

Wed, 16 Apr 2025 00:00:00 +0900

패턴 이름

트집쟁이 패턴

패턴 설명

개발 결과물에서 중요하지 않은 사소한 부분에 과도하게 집착하여 문제를 제기하고, 그로 인해 개발 방향이 불필요하게 복잡해지거나 운용 비용이 증가하는 패턴이다. 정작 도입 후에는 자신이 문제 삼았던 부분은 잊은 채, 결과물의 복잡성이나 불편함을 지적하며 사용을 거부하거나 불만을 토로한다. 이는 개발팀의 사기를 저하시키고 프로젝트의 효율성을 떨어뜨리는 결과를 초래한다.

패턴 증상

개발 단계

회의 중 사소한 UI 요소, 용어, 또는 기능의 동작 방식에 대해 과도하게 상세한 질문이나 변경 요구를 반복한다.
전체적인 시스템 아키텍처나 핵심 기능보다는 주변적인 요소에 집중하여 논의를 장시간 끌고 간다.
자신의 의견이 반영되지 않으면 불만을 표현하거나 비협조적인 태도를 보인다.
요구 사항 변경의 영향에 대한 충분한 이해 없이 즉흥적인 변경을 요구한다.
이러한 요구 사항들이 누적되어 설계의 복잡성을 증가시키고 개발 일정을 지연시킨다.

도입 단계

자신이 과거에 주장했던 사항으로 인해 시스템이 복잡해졌음에도 불구하고, 결과물의 복잡성이나 사용의 불편함을 지적한다.
시스템 사용에 대한 책임을 회피하며, 과거의 자신의 요구 사항에 대해서는 언급하지 않거나 기억하지 못하는 척한다.
새로운 시스템에 대한 불만만 강조하며, 기존 시스템에 대한 향수를 표현하거나 새로운 시스템의 도입 자체를 후회하는 모습을 보인다.
심한 경우, 시스템 사용을 거부하거나 최소한의 사용만을 고집하며, 시스템 도입 효과를 저해한다.

패턴 원인

불안감 및 통제 욕구: 프로젝트의 전체적인 그림을 이해하기 어려워 느끼는 불안감을 해소하기 위해, 자신이 이해하기 쉬운 작은 부분에 집중하고 통제하려 한다.
전문성에 대한 과시 욕구: 개발 지식이 부족함에도 불구하고, 사소한 부분에 대한 지적을 통해 자신의 존재감을 드러내거나 전문적인 의견을 제시하려는 시도이다.
의사 결정 회피: 프로젝트의 중요한 결정에 대한 책임을 회피하기 위해, 사소한 문제에 집중하여 논의의 초점을 흐린다.
기억 왜곡 또는 책임 전가: 결과물의 문제점에 대한 책임을 회피하기 위해, 과거 자신의 요구 사항을 망각하거나 개발팀의 잘못으로 책임을 전가하려는 심리이다.
소통 부족: 개발팀과 의뢰자 간의 충분한 소통 없이 진행되어, 의뢰자의 우려나 오해가 사소한 트집으로 표출될 수 있다.

패턴 해결

초기 단계부터 명확한 요구 사항 정의 및 합의: 프로젝트 시작 시 의뢰자와 충분한 논의를 거쳐 구체적이고 명확한 요구 사항을 정의하고 문서화한다. 변경 사항 발생 시 영향 분석 및 승인 절차를 명확히 한다.
정기적인 의사소통 및 피드백 공유: 개발 과정 전반에 걸쳐 의뢰자와 정기적인 미팅을 통해 진행 상황을 공유하고 피드백을 받는다. 시각적인 자료(데모, 프로토타입 등)를 활용하여 이해도를 높인다.
요구 사항의 우선순위 및 영향도 명확화: 모든 요구 사항에 대해 우선순위를 매기고, 각 요구 사항이 전체 시스템에 미치는 영향(복잡성, 비용, 일정 등)을 명확하게 설명한다.
기록의 중요성 강조 및 공유: 회의록, 결정 사항, 변경 요청 내역 등을 상세하게 기록하고 의뢰자와 공유하여 추후 발생할 수 있는 오해를 방지한다.
전문적인 권위 유지: 사소한 트집에 일일이 휘둘리지 않고, 개발 전문가로서의 판단과 원칙을 유지하며 논리적으로 설명한다.
도입 전 충분한 교육 및 검증: 시스템 도입 전에 의뢰자에게 충분한 교육을 제공하고, 함께 검증 과정을 거쳐 사용상의 어려움을 최소화한다.
문제 발생 시 책임 소재 명확화: 시스템 도입 후 문제 발생 시, 과거의 기록을 바탕으로 책임 소재를 명확히 하고 합리적인 해결 방안을 모색한다.

트집쟁이 패턴에 대한 대응책은 기록과 문서 기반의 업무 처리 이다. 같은 회사 내부라 하더라도 정확한 기록을 남기고, 미팅에서는 상대방의 의도를 명확히 하는 질문을 통해 의사기록을 확실히 작성한다.

결론

트집쟁이 패턴은 조종자 패턴의 전조증상일 수 있으니, 미리 점검하여 대비하는 것이 좋다. 둘의 해결책도 유사하다. 이 패턴을 인식하고, 초기 단계부터 명확한 커뮤니케이션과 기록 관리를 통해 예방하는 것이 중요하다. 만약 이러한 패턴이 발생하더라도, 원인을 정확히 파악하고 단호하고 일관된 태도로 대처하도록 한다.

독재자 패턴

Wed, 22 Jan 2025 00:00:00 +0900

패턴 이름

독재자 패턴

설명

조종자 패턴의 발전된 형태이다. 조종자 패턴이 권력을 가지게 되면 이 상태로 발전될 가능성이 크다. 독재자 패턴의 주요 증상은 자신의 권력을 팀원에게 위임하지 않는다는 것이다. 권력을 독점함으로써만 통제할 수 있다고 믿는다. 이 패턴의 구체적인 증상들은 다음과 같다.

절대적인 권위 주장: 모든 의사 결정을 독단적으로 내리고, 다른 의견을 무시하거나 묵살함.
정보 독점: 정보를 개인적으로 소유하고, 필요한 정보를 공유하지 않으며, 의사 결정 과정에 다른 사람들을 참여시키지 않음.
비난과 책임 전가: 문제 발생 시 다른 사람에게 책임을 전가하고, 비난함.
변화에 대한 저항: 새로운 아이디어나 방법론을 받아들이지 않고, 기존 방식을 고수하려함.
개인주의적 성향: 팀의 목표보다는 개인의 이익을 우선시하고, 협업을 거부함.

보통 조직 내에 남아 있는 독재자 패턴은 ‘생존한’ 독재자 패턴이고 이는 권력 쟁취에 성공했다는 이야기이다. 그러므로 독재자 패턴은 반드시 조직 전체에 큰 영향을 미친다. 조직이 이 패턴으로 인해 받게 되는 문제들은 아래와 같은 것들이 있다.

생산성 저하: 팀원들의 창의성과 잠재력을 억누르고, 의사 결정 속도를 늦춰 생산성이 저하됨
팀워크 저하: 팀원들 간의 신뢰 관계가 무너지고, 소통이 단절되어 팀워크가 저하됨
프로젝트 실패 가능성 증가: 프로젝트 계획 단계에서 다양한 의견 수렴 없이 진행되다 보니 실패할 가능성이 높아짐
조직 문화 악화: 독재적인 리더십은 조직 전체에 부정적인 영향을 미쳐, 직원들의 이직률 증가 등의 문제 야기

이 패턴은 최종적으로 조직을 붕괴시키거나, 아니면 이직할 곳이 없으나 순종적인 저성과자들로 조직을 채우게 된다.

원인

독재자 패턴도 개인의 성향에 기반한 문제이기 때문에 개인적 원인들이 더 많다. 강한 자존심으로 인한 리더쉽에 대한 과도한 욕구가 문제의 바탕을 이룬다. 그리고 이 리더쉽 상실에 대한 두려움이 크며 상실 불안감을 극복하기 위해 자신이 모든 걸 통제하려 들게 되는 것이다.

독재자 패턴을 방지하는 것은 조직 문화를 만들어 예방하는 것이 제일이다. 조직이 일하는 문화가 단단히 자리 잡은 곳은 일개 개인을 넘어선 집단의 원칙이 존재하므로 독재자 패턴을 방지하는 효과가 있다. 특정 개인을 변화시키는 일은 쉽지 않은데다 이미 독재자 패턴으로 확인된 사람이라면 조직내 상당한 권력을 가지고 있기 때문에 단번에 해결이 불가능하다. 우리가 할 수 있는 일은 독재자의 권력을 무효화할 수 있는 문화적 장치를 만들어 가는 것이다.

해결

이러한 환경 구축을 위해 조직 입장에서 필요한 사항들은 다음과 같다.

소통 강화: 조직 내에 정보 비대칭이 발생하지 않도록 한다. 업무와 관련된 정보는 원하는 사람 누구나 접근 가능하도록 관리되어야 한다. 특정 개인이 조직의 정보를 독점하지 않도록 예방한다. 팀원간 주기적인 업무 진행 상황 공유, 공통 문서 및 이슈 관리 시스템 등을 활용한다.
역할 분담: 불명확한 역할과 책임: 팀원들의 RoR 을 명확히 한다. 각 팀원들에게 책임감과 역할범위에 따른 자율적인 의사 결정을 맡겨 리더의 권한을 분산시킨다.
의사 결정 시스템: 최종 의사 결정은 조직의 결정권자가 하더라도 그 전에 의사결정에 관여하는 팀원들의 그룹에 관련 주제를 논의할 수 있어야 한다.
코칭 및 교육: 리더에게 리더십 교육을 제공하고, 팀원들에게 효과적인 협업 방법을 교육한다.

조직 문화를 만드는 일은 아주 긴 시간이 걸리는 작업이며, 한번에 해결할 수 없다. 약한 불로 끓이는 솥 처럼 하나씩 점진적으로 해나가다보면 어느 순간부터 영향을 발휘하게 된다. 이보다 더 빠른 방법은 보다 상위의 권력을 가진 사람으로 하여금 독재자를 제거해달라고 하는 것이나, 당장의 그 빈 자리를 채울 수 있는 대안이 없다면 이것도 현실적인 해결책이 아니다.

조종자 패턴

Wed, 20 Nov 2024 00:00:00 +0900

패턴 이름

조종자

설명

조종자는 이 글 에서 언급한 테이커와 유사하기도 하다. 조종자는 타인을 자신의 의도대로 조종하는 일에 능한 사람이다. 여기에서 말하는 조종은 계약과는 다르다. 계약은 상호 간의 의사 합의에 의해 이뤄지지만, 조종의 경우 당하는 사람은 본인이 조종당하는지 인지하기 어렵다.

조종자 패턴은 일종의 상위 패턴이다. 왜냐하면 이 패턴은 여러 하위 행동들을 포함하기 때문인데, 이는 조종자 패턴이 사람의 성격과 관련된 것이라 여러 독특한 행태들을 보이기 때문이다. 그 행동들 각각을 다시 패턴으로 정의해 볼 수 있으나, 이 글에서는 상위 패턴의 개괄적인 정의만 담으려고 한다.

조종자 패턴의 핵심은 상대방이 나의 의도를 궁금해하도록 만드는 데 있다. 내 의도를 명확히 보이지 않고 끝없이 유추하도록 방치함으로써 상대방은 작은 일에도 나의 허락을 구하기 시작하게 되고, 거기에서부터 조종을 시작한다. 이를 몇몇 행동 양식으로 정리해 보면 다음과 같다.

나의 의도는 명확한 언어로 밝히지 않는다. 애매모호한 표현을 사용하거나 두루뭉술하게 말한다.
상대방의 발언은 구체적으로 물고 늘어져 상대방이 수동적으로 동작하도록 만든다.
상대방이 나의 의중을 짐작하도록 계속 요구한다.

위와 같은 행동 원칙에 따라 조종자 패턴들의 몇 가지 공통된 행동 양상이 나타나게 된다.

계획이 없거나, 있더라도 남에게 공유하지 않는다.
자신의 발언을 쉽게 뒤집는다.
프로세스에 따른 업무 처리보다는 나의 지시에 따른 업무 처리를 선호한다.

조종자 패턴을 보이는 사람은 조직 내에서 어느 정도 레벨까지는 빠르게 성장하지만, 그 이후부터는 명백한 한계를 보인다. 작은 조직이 조금 커지는 단계에서는 조종자가 어느 정도 활약을 할 수 있지만, 조직이 조금만 커지게 되면 타 부서와의 협업 등이 필요하게 되고, 이 단계에서는 조종자 패턴은 상호 간의 신뢰를 무너뜨리게 되기 때문에 조직 자체가 성장하지 못하게 된다. 또한, 대외적인 관계를 차치하고 조직 내부만을 보더라도 조종자 패턴의 한계는 명확하다. 조직 내의 인력을 육성하고 키우기 위해서는 팀원을 믿고 일을 맡겨야 하는데, 업무의 위임에 있어 계획과 공유는 필수적인 것이라, 조종자의 성장에는 그 한계가 명확하다고 할 수밖에 없다.

원인

조종자 패턴을 일으키는 구체적인 원인은 특정하기 힘들다.

해결

조종자 패턴에 대한 가장 좋은 해결책은 피하고 상대하지 않는 것이다. 그러나, 여러 이유로 피할 수 없는 경우가 있을 것이라 대응 및 해결 방안을 확보해 둬야 한다. 앞서 말했듯 조종자 패턴은 상위 패턴이라 하위에 다양한 행동 양식들이 있어 각각에 대해 다시 패턴을 기술하여 해결책을 확보해야 된다. 여기에서는 몇 가지 원칙만 적는다.

기록이 기억을 이긴다. 미팅 노트부터 시작해서, 회의가 끝나면 이를 정리해서 이메일로 신속히 공유하고 참조에 관련자들을 기재한다.
상대가 결정할 수 있는 범위에 대해 명확하게 인식하고 이를 바탕으로 대화한다.
표현되지 않는 의도를 읽으려 노력하지 않는다.
애매한 부분을 그냥 넘겨짚지 않고, 세세한 것도 사실 관계를 확인한다.

나의 개발 커리어 요약: 세번째 회사, 외국계 기업에서 사무용 애플리케이션 개발

Wed, 23 Oct 2024 00:00:00 +0900

이전 글: 나의 개발 커리어 요약: 두번째 회사 웹 보드 게임회사에서 온라인게임 팀

병역 특례로 다니던 회사를 퇴직한 뒤 복학하여 필수 이수 과목들을 듣고 학점 펑크가난 과목들을 재수강하며 보냈다. 몇 년 학교를 떠나 있으면서 수학 공식들을 모두 잊어먹고, 처음부터 배우는 마음으로 미적분학부터 재수강했었는데 수학 공부가 무척 재밌었던 기억이 난다. 수학 재미에 푹 빠져 혹시 나에게 숨어있던 수학 재능이 뒤늦게 발굴된 건가 싶어 수학과 전공 학생들이 듣는 자연대 선형대수 과목을 수강해보고는 다시금 겸손해져서 원래 하던 전공이나 잘해보기로 마음을 고쳐 먹었었다. 이런 저런 책도 많이 읽었고, 인생에서 공부가 재밌었던 몇 안되는 시기였다.

그러게 졸업시기가 다가왔고, 여름 졸업을 하려했으나 이수해야 하는 전공필수 과목 하나가 2학기에 개설이라 어쩔 수 없이 2학기까지 다녀야 하는 상황이 되었다. 교내를 걸어다가 마침 게시판에 붙은 인턴쉽 공고를 보고 그거나 해볼까 싶어 해당 회사에 지원서를 내게 되었다. 용돈이나 벌자는 생각으로 가볍게 면접을 보러 갔는데, 1차 면접 후 인사부서에서 기존 전형에 없던 부서로 면접을 한번 더 잡아 주셨다. 아마 인턴쉽 모집 분야 보다는 그 쪽이 더 회사측에도 좋을 것 같아 그리해주신 것 같다. 운 좋게 합격하여 그 회사의 개발팀에 들어가 일을 해볼 게 되었다. 나중에 알게 되었지만 해당 인턴쉽은 사실상 정직원을 채용하는 과정이었고, 용돈벌이나 기대했던 나는 외국계 소프트웨어 회사에서 졸업 후 커리어를 이어가게 되었다. 감사한 일이었다.

이곳은 소프트웨어 개발자에게는 더없이 좋은 환경이었다. 공부할 자료들이 잘 정리되어 있고, 프로세스도 잘 잡혀 있었다. 특히 당시까진 여전한 판매 방식이었던 shrink wrap 식 글로벌 최고의 매출을 올리고 있었으니, 여러모로 안목을 넓힐 기회였다. 단점이라면 본사가 아닌 지사 그것도 전체 매출의 1% 가 겨우 되는 대한민국 시장의 지사에 그치고 말아서 조직 성장에 한계가 있다는 것과 오래된 조직인 만큼 새로운 도전을 하기에는 활력이 부족하다는 점 정도가 있었다.

기술적으로는 이전에 한번도 다뤄보지 않았던 윈도우즈 기반이라 적응에 애를 좀 먹었다. 이전 까지 실무에서 쌓은 경험들은 유닉스 POSIX 표준 하에서 동작하는 프로그램들 작성이었는데, 윈도우즈는 운영체제의 기본부터 달랐다. 게다가 맡은 프로젝트의 특성 또한 이 어려움에 한 몫했는데, 당시엔 닷넷이 나와 c# 등으로 편하게 개발할 수 있는 방법이 나오고 있고, 구글에서는 웹 기반 제품이 출시되어 계속 업데이트를 해나가던 시절이었다. 하지만 내가 속한 프로젝트는 구식인 Win32 API 를 익히고, COM 기반의 라이브러리를 다루는 작업들이 주어졌다. 잘 해내기가 쉽지 않았다. 지금 돌이켜보면 웹이나 안드로이드앱 개발 같이 조금 더 어플리케이션 영역의 개발을 하고 싶었던 게 아닌가 싶다.

어쨋든 소프트웨어 명가 답게 기술도 기술이지만 그보다 프로젝트 관리나 리스크 관리 등과 관련된 것들을 더 많이 배웠던 것 같다. 글로벌 회사에서 이미 자리 잡은 제품의 다음 버전을 출시할땐 프로젝트 일정관리가 무엇보다 중요해지는데, 이유는 개발이 1개월만 늦어져도 집행예정인 마케팅 비용이 대단한 규모가 때문에 어떻게든 출시 일정을 지켜야했다. 한편 제품 필수 기능이 부러진 채 출시할 순 없으니 이 둘 사이의 균형잡기가 프로젝트 관리의 핵심이었다.

이 회사에서 시간은 마냥 잘 흘러갔다. 개발을 하며 배우는 것도 많았고, 사람들과 어울릴 일도 많았다. 특히 사내 농구 동호회에 가입하여 일주일에 한번 운동을 하였는데, 반복되는 회사 생활을 버틸 수 있었던 활력소였다. 그리고 무엇보다 큰 일은 비밀리에 사내 연애를 해서 결혼까지 한 것이다. 평생의 짝이 되는 인연을 찾았으니 사회적 기능으로서의 직장이 해 줄 수 있는 건 모두 얻었다고 볼 수 있겠다.

하지만 회사 밖에서는 아이폰이 이뤄낸 혁신을 따라 스마트폰 시장이 열리고 있었고, 온갖 스타트업들이 나와 하루가 멀다 하고 새로운 서비스와 앱들을 출시하고 있었다. 그러던 와중 결혼을 하게 되었는데, 인생의 큰 변곡점을 맞이하고 있다는 느낌이 들었다. 내 개인의 삶에서도 새로운 방향을 시도할 수 있다면 지금이라는 생각을 하게 되었고, 실천에 옮겼다.

스피드광 패턴 (더 빠르게 더 빠르게)

Sat, 19 Oct 2024 00:00:00 +0900

패턴 이름

스피드광 (더 빠르게 더 빠르게)

패턴 설명

눈앞의 긴급한 버그를 즉시 해결하고 배포해야 하는 상황에 몰입하여, 빠른 속도로 문제를 해결하는 데 집중하는 행동 패턴이다. 문제의 단서를 포착하는 즉시 해결 코드를 구상하고, 쉴 새 없이 코딩하며, 빌드 및 배포 과정을 빠르게 진행하는 것을 즐긴다. 이러한 과정에서 아드레날린 분비를 느끼며, 즉각적인 문제 해결 후에는 또 다른 긴급한 상황을 찾아 나선다.

이 패턴의 핵심적인 문제는 단기적인 속도에 집중한 나머지 장기적인 방향성을 잃을 수 있다는 점이다. 핫픽스와 같이 빠른 대응이 필요한 상황에서 집중력이 극대화되지만, 동시에 시야가 좁아지고 자기 객관화 능력이 저하된다. 그 결과, 문제의 근본 원인을 해결하지 못하거나 불필요한 코드 수정이 발생하여 또 다른 문제를 야기할 수 있다.

좁아진 시야는 핫픽스 과정에서 중요하지 않은 버그를 수정하는 등의 예상치 못한 결과를 초래할 수 있으며, 이는 불필요한 서비스 중단 시간 증가 및 잠재적인 피해로 이어질 수 있다. 주변 사람들은 담당자가 정신없이 바쁘게 일하는 모습만 보고 도움을 주기가 어렵다.

패턴 증상

눈앞의 버그에 지나치게 집중하며 주변 상황을 인식하지 못한다.
문제의 근본 원인 분석 없이 즉각적인 코드 수정에 몰두한다.
빌드 및 배포 과정에 대한 강한 조바심을 느낀다.
핫픽스 과정에서 중요하지 않은 버그를 함께 수정하려는 경향을 보인다.
수정된 코드에 대한 충분한 검토 없이 배포를 강행한다.
주변 동료와의 소통 없이 독자적으로 문제 해결을 진행한다.
본인이 매우 바쁘게 일하고 있다고 느끼지만, 실제 문제 해결과는 거리가 먼 행동을 할 수 있다.
결과적으로 서비스 중단 시간이 길어지거나 예상치 못한 부작용이 발생한다.

패턴 원인

핫픽스 배포에 대한 강한 압박감: 짧은 시간 내에 문제를 해결하고 배포해야 한다는 압박감이 인지적 터널링을 유발하여 주변을 돌아볼 여유를 잃게 만든다.
개인의 성향보다는 상황적 요인: 특정한 성향의 사람뿐만 아니라, 누구든지 긴급한 상황에 처하면 스피드광 패턴에 빠질 수 있다.
업무 프로세스에 대한 낮은 신뢰: 평소 정해진 절차를 번거로운 것으로 여기는 경우, 긴급 상황 발생 시 이러한 절차를 무시하고 속도에만 집중할 가능성이 높다.
자기 객관화 부족: 바쁜 상황 속에서 자신의 행동을 되돌아보고 평가할 시간적, 심리적 여유가 부족하여 문제 해결 방식의 효율성을 판단하기 어렵다.

패턴 해결

스피드광 패턴에서 벗어나기 위해서는 일시 멈춤과 방향 재점검이 중요하다. 마치 과속 차량을 멈추게 하는 교통 경찰처럼, 스스로 또는 주변의 도움을 통해 잠시 멈춰 서서 현재 진행 상황을 객관적으로 평가하고 방향을 수정할 수 있는 메커니즘이 필요하다. 핵심은 다른 사람과의 대화를 통해 자기 인지 능력을 회복하는 것이다.

동료에게 설명하기: 자신이 현재 어떤 문제를 해결하고 있으며, 어떤 방식으로 접근하고 있는지 동료에게 설명하는 과정을 통해 스스로의 생각을 정리하고 놓치고 있는 부분을 발견할 수 있다.
러버덕 디버깅: 옆에 동료가 없는 경우, 러버덕과 같은 대상에게 자신의 문제 해결 과정을 설명하는 것도 유사한 효과를 가져올 수 있다.
뽀모도로 기법 활용: 정해진 시간 동안 집중하여 작업하고 짧은 휴식 시간을 갖는 뽀모도로 타이머를 사용하여, 강제로 멈춰 서서 진행 상황을 되돌아보는 시간을 확보한다. 이때 휴식 시간에 동료와 대화하는 시간을 갖는 것을 권장한다.
핫픽스 처리 프로세스 준수: 핫픽스 발생 시 따라야 할 명확한 업무 처리 프로세스를 만들고 이를 준수하도록 강제한다. 이 프로세스에 동료와의 논의 및 방향성 점검 단계를 포함시켜 자연스럽게 멈춤과 재점검이 이루어지도록 설계한다.
유사 상황 대비 훈련: 실제 핫픽스 상황과 유사한 상황을 설정하여 동료와 함께 문제 해결 과정을 시뮬레이션하고, 서로의 행동을 관찰하며 피드백을 주고받는 훈련을 한다. 이를 통해 실제 상황 발생 시 당황하지 않고 효과적으로 대처하는 능력을 키울 수 있다.

결론

“스피드광” 패턴은 긴급한 상황에서 빠른 문제 해결을 추구하는 개발자의 자연스러운 반응일 수 있지만, 장기적인 관점에서 효율성과 안정성을 저해할 수 있다. 이 패턴을 인식하고, 개인 및 팀 차원에서 일시 멈춤과 방향 재점검을 위한 노력을 기울이는 것이 중요하다. 동료와의 소통을 활성화하고, 정해진 프로세스를 준수하며, 유사 상황에 대한 훈련을 통해 스피드광 패턴의 부정적인 영향을 최소화하고 보다 성숙한 문제 해결 방식을 구축할 수 있다.

소프트웨어 개발 패턴

Thu, 17 Oct 2024 00:00:00 +0900

GoF 의 디자인 패턴이 코드 상의 반복되는 문제해결법을 다루고 있는 책으로 관련 도서 중 가장 유명하다. 코딩 중에 자주 만나게 되는 설계 문제를 하나의 패턴으로 정의해서 해당 패턴에 대한 솔루션을 기술해 둔 것이다.

나도 이와 유사한 작업을 한번 해볼까 하는데, 이른바 “소프트웨어 개발 패턴” 이다. 코드 단위를 넘어서서 고객, 팀원, 일정 관리 등 소프트웨어 개발 전반에서 발생하는 문제들 중 코드 밖에서 발생하는 일들을 패턴으로 기록해 보려고 한다.

이 거창해 보이는 작업의 이유는 사실 무척 사소한 것인데, 회사 생활에서 받는 스트레스를 조금 더 건강한 형태로 풀어두기 위한 개인적인 필요 때문이다. 과거 경험을 돌아봐도 소프트웨어 개발에서 나를 힘들게 했던 부분들은 코드 밖에서 발생한 경우가 더 많았던 것 같다. 코드의 문제는 푸는 즐거움이라도 있지만, 다른 일들은 푸는 과정이 그다지 즐겁지 않았고, 그와 유사한 문제가 반복적으로 나타나더라도 이전 해법에서 배워올 수 있는 것들이 명확하지 않았다.

코드 밖의 비정형화 영역에서 발생하는 문제를 문자를 통한 정형화된 형태로 기록하는 일이 쉽지 않다는 것을 알고 있다. 그러나 그럼에도 불구하고 반복되는 것처럼 느껴지는 문제들의 공통된 부분은 분명히 존재한다. 공통의 요소들만 검증된 방법으로 해결할 수 있다면, 나머지 부분은 다루는 것은 한결 더 쉬워질 것이다.

패턴 기술 형식은 패턴의 이름, 요약, 설명, 원인, 해결 의 5가지로 나눠서 정리해 보려고 한다. 해결 부분은 시간이 걸릴 수 있어서 패턴 작성 초안에서는 ‘시도’ 로 변경해서 작성하고, 결과 검증 후 ‘해결’ 로 변경해서 다시 기재하는 식으로 정리하면 될 것 같다. 마지막에 한 섹션을 더 두어 패턴 변경 이력을 정리해 두는 것도 좋을 것 같다.

일단은 작게 베이베스텝으로 시작해보자. 내 스트레스만 줄일 수 있어도 시도는 성공한 것이다.

사용자 시나리오에서 기획을 시작해야 되는 이유

Fri, 02 Feb 2024 00:00:00 +0900

애자일 방법론 중 하나인 사용자 스토리는 많이 알려져 있지만 사용자 시나리오를 아는 사람은 생각보다 많지 않다. 아마 해당 기법이 애자일 방법론 중 하나로 나왔다기 보다는 특정 회사에서 내부 기법으로 소개 되었기 때문일 것이다. 내가 해당 내용에 대한 교육을 받았던 건 2010 년 정도 였던 걸로 기억한다. 검색해보니 2014 년에 책으로도 출판되었다. 안타깝게도 국내에 번역된 서적은 없다.

사용자 시나리오 vs 사용자 스토리 vs 사용케이스(Use case)

User scenarios, user stories, use cases

비슷한 용어들 부터 정리하고 넘어가보자. 사용자시나리오 (User Scenario) 와 사용자 스토리 (User Story), 유즈케이스 (Use Case) 는 비슷한 용도로 사용되는 문서들이다. 모두 다 솔루션이 어떤 형태여야 되는지 전달하기 위한 목적으로 작성된다. 하지만 각 문서들의 관점과 구조가 다르다.

사용자스토리는 매우 단순한 구조로 되어 있다. 아래와 같은 구조로 이뤄져 있고, 엔드유저 관점을 표현한다. As a (user type) I want to (action/feature) because (reason)
이것보다 조금 더 높은 범위를 커버하는 것이 사용자 시나리오다. 사용자 시나리오는 사용자의 동기와 환경에 대한 언급을 하게 된다. 어떤 목적으로 솔루션을 필요로 하는 담고 있는 문서로 사용자 행위의 전체 윤곽을 정의한다.
유즈케이스는 구체적으로 어떤 기능이 있어야 되는지 정의하는 문서이다. 요구사항을 구체적으로 다이어그램 형태로 풀어낸 문서다. 사용자 행동에 대해 아주 구체적이고 세밀한 단계를 정의하게 된다. 개발팀의 요청이 있는 경우 작성하는 수가 많으며, 생략하고 개발을 진행하는 곳도 많다.

사용자 시나리오의 포인트

앞서 얘기한 대로 사용자 시나리오는 사용자가 솔루션을 필요로 하는 문제 상황에 포커스를 두고 작성된다. 어떤 동기로 솔루션을 필요로 하는지 어떤 환경에 놓여 있는지 정의하고 시작한다. 그리고 문제가 해결될 때 어떤 이익과 가치를 얻게 되는지 그로 인해 사용자의 심경 변화는 어떻게 되는지 정의한다. 어떻게 해당 기능을 구현할지 결정하는 솔루션은 시나리오 작성 초기에 의도적으로 배제하는데, 바로 이 부분에 사용자 시나리오 기반 접근의 장점이 있다.

기획자는 해법을 모아서 정리하는 사람

많은 경우 기획자들은 문제 해결의 솔루션을 혼자서 생각해 내야 한다고 착각한다. 특히 경험이 적은 신입들일수록 혼자 해내지도 못할 일을 끙끙거리며 끌어 안고 있다가 업무 진행 타이밍을 놓쳐버리는 일들이 허다하다. 끙끙거림의 결과로 전혀 엉뚱한 것을 만들어 오거나 너무 큰 기획으로 만들어 오는 것은 덤이다. 사용자 시나리오는 이 과정을 반드시 개발자나 디자이너등 다른 팀원들과 함께 진행하라고 한다. 기획자가 생각해낸 솔루션은 엔지니어 입장에서 그다지 효율적이지 않거나, 디자이너 입장에선 그다지 효과적인지 않을 수 있기 때문이다. 또 어떤 경우에는 솔루션을 만들지 않고도 해결 가능한 경우가 존재할 수도 있다. 시나리오 기반 기획은 이러한 실수를 줄여 줄 수 있는 방법이다.

시나리오 접근의 단점

시나리오 기반 기획도 하나의 방법론이기 때문에 장점이 있으면 그에 따른 단점도 존재한다. 단점에 대한 이해를 제대로 갖추고 있어야 기법을 사용하더라도 부작용을 최소화할 수 있을 것이다. 하지만 이 단점이라는 건 어떻게 실행하느냐에 따라 다르게 느껴질 수 있는 부분이라 지극히 개인적인 관점에서 적어볼 수 밖에 없다.

경험상 시나리오 기반 접근은 기획이 더디다는 인상을 준다. 아무래도 일반적인 기획서가 개발 착수하기까지 절차가 더 있으므로 시간이 걸리기 때문이다. 그러나 프로젝트 시작과 끝을 염두에 두고 생각해보면 이 부분에 추가로 들어가는 시간이 꼭 단점이라고 할 순 없다고 본다. 프로젝트 중간에 이런 기능도 넣자 저런 것도 넣어달라 라는 식으로 본래 목적과 동떨어진 기능들을 구현하느라 일정을 놓쳐버리는 일이 얼마나 자주 발생하는지를 생각해보자. 시나리오 기반 접근에서는 시나리오 완성에 기여하지 않는 기능 구현은 우선순위가 낮아지게 되어, 기획이 더뎌지는 느낌을 주지만, 프로젝트 최종 결과물이 나오기 까지는 오히려 낭비 없이 짧은 시간이 보장된다.

정리

방법론은 하기 나름이라 그 결과를 보장하는 건 아니다. 형식과 틀은 제약을 만들어내지만, 개선을 위한 발판이 되기도 한다. 방법론이 바로 그런 것이다. 문제가 있는 부분은 개선을 해 나갈 수 있지만, 틀이 잡혀 있지 않으면 문제를 정의하기가 어려워 진다. 시나리오 기반 기획은 개발 리소스의 낭비 없이 사용자의 목표를 달성할 수 있도록 효과적인 개발을 하는 방법 중 하나이다.

사수를 찾아 헤매는 주니어 기획자들

Fri, 05 Jan 2024 00:00:00 +0900

최근 기획자 면접을 자주 보면서 팀에 선배 기획자가 있는지 묻는 질문을 자주 받았다. 우리 팀의 경우 기획자라는 명시적인 롤을 부여 구성원은 1인인데, Product Owner 역할을 하는 사람은 몇 명이 더 있다. 그래서 지원자의 질문에 명시적인 기획자롤은 없으나, PO 그룹에서 기획서 리뷰를 함께 하고 있고, 기획 초안은 개발자와 디자이너의 리뷰를 다시 거치도록 되어 있다고 설명하였다.

재밌는 사실은 위 질문을 한 경우에 이 대답이 그리 만족스러운 대답이 아니었던 걸로 보였다는 점이다. 같은 업무를 맡아서 할 사수의 부재가 직장 선택의 결정적 요소라니, 나로서는 그다지 이해가 가지 않았다. 그래서 이 점에 대해 나름의 생각을 정리해 둘 필요가 있을 듯 하여 글로 써보기로 했다.

우선 사수 기획자가 필요한 이유를 검색해 봤다.

대충 거칠게 요약을 해보면, 사수가 없는 경우 신입이 일을 배우기가 어려울 것이고, 그로 인해 성장은 더뎌지나 업무는 과중하게 부담되는 상황이 있을 수 있다는 걱정이 가장 큰 것 같다. 사수를 찾는 신입 기획자들에 대한 나의 반론은 “그럼 선배 사수가 있으면 위 문제가 사라지는가?” 이다. 선배 사수가 있으면 나에게 일하는 방법을 친절히 가르쳐 주고, 성장할 수 있도록 독려해주며, 과중한 업무가 배정되는 것을 막아줄까?

내 대답은 아니다 이다. 부연을 하자면 위에 나열된 것들을 찾고자 하는 욕구는 그 자체로 잘못된 것이 없다. 다만 그 해법이 “사수” 라는 한 명의 인간으로 개체화 되어 있을 거라는 가정이 잘못 되었다고 생각한다. 일을 배우고, 성장의 기회를 찾고, 업무 하중을 적절히 조절하는 것은 팀이 하는 일이지, 한 명의 인간이 이를 모두 대신해주긴 어렵다. 모든 직원은 각자의 업무를 처리해야 하며 그 업무 부하라는 것은 업무 역량에 맞춰 부과되기 때문에 자기 자신 아닌 누군가를 돌봐줄 시간과 여유란 존재하기 어렵다. 기껏해야 담배 한 대 같이 태우거나, 커피 한 잔 나누면서 담소를 나눠주는 정도가 전부일 것이다.

팀이다. 팀이 위와 같은 작업을 할 수 있도록 해야 한다. 하나의 팀으로서 우리는 모여 업무 처리에 대한 피드백을 나누고, 상호간의 배움과 성장을 도모하며, 팀의 업무 조율을 위한 작업을 해야 하는 것이다. 이것이 인간이 개개인으로 존재하며 일을 하지 않고, 유기적인 조직을 이뤄 일을 하는 이유이다. 팀이 이런 작업을 해나가려면, 정기적인 회고, 상호간의 솔직한 피어리뷰, 스터디나 세미나를 격려하는 조직장 등의 조건들로 구성되어야 한다.

파랑새를 찾아 헤매는 꿈을 꾸다 깨어나 보니 키우던 비둘기가 파랑새 였다는 소설 처럼, 신입 기획자들은 어디에도 그 존재가 확인되지 않는 “나에게 모든 관심을 쏟아줄 사수” 를 찾아 헤매지 말고, 성장의 토양이 잘 닦여 있는 팀을 찾아 나섬이 좋으리라 생각한다.