최근에 다니던 회사를 그만두고 보다 작은 스타트업으로 합류를 했습니다. 그런 선택을 하게 된 조건에는 여러가지가 있었지만 가장 큰 계기는 아무래도 학업과 병행이 가능했던 것이 가장 큰 이유였습니다. 사실 저는 산업기능요원으로 군복무를 겸해서 사회 생활을 경험했기 때문에, 아직 졸업을 하지 않은 휴학생 신분입니다. 그렇지 않아도 다음 학기부터 복학을 할 예정이었기 때문에, 다니고 있던 회사는 올해 말까지만 다닐 예정이었습니다.
그러다가 학교와 산학 연계가 되는 조건으로 다른 스타트업에서 제안이 와서 생각보다 조금 빠르게 합류를 하게 됐습니다. 회사도 다니면서 일도 할 수 있고, 학점도 딸 수 있었죠. 그래서 학교에서 인정되는 저의 공식적인(?) 직급은 파릇파릇한 새내기 인턴이긴 합니다…ㅎㅎ 3월부터는 다시 학생으로 돌아가기 때문에, 뭔가 본격적인 이직이라고 말하기에는 약간 애매한 부분이 있네요. 제 개인적인 커리어에 대한 이야기는 기회가 된다면 나중에 좀 더 자세히 다루어보도록 하겠습니다.
아무튼 지금보다 더 작은 스타트업으로 합류하는 것이었기에, 저는 개발자 역할 뿐만 아니라 어느 정도의 시니어급 역할도 함께 맡게 되었습니다. 멤버들 중에서 큰 조직을 경험해본 사람은 저 혼자였고, 대부분 학교를 막 졸업했거나 산학연계로 단기간 일하는 인턴 신분이 대부분이었습니다. 저는 경력을 갖고 합류했기 때문에 조직 내에서도 어느 정도의 자율성을 보장받는 대신 몇 가지 중요한 임무들을 맡게 되었고, 그 중 하나가 조직 문화와 개발 문화의 정착이었습니다.
그래도 나름 꽤 큰 스타트업 출신이고 누구보다도 치열하게 일하는 팀원들과 함께 일한 경험이 있으니, 조직에서 어떤 문화를 추구해야 하는지에 대해서도 배운 것이 많았습니다. 때문에 스타트업에 새로운 조직 문화를 도입시킬 수 있는 기회가 주어진 것은 저에게도 꽤 흥미로운 일이었습니다. 어느덧 2주차에 접어든 지금, 제가 어떤 접근 방식으로 조직 문화를 도입해나가고 있는지에 대해 소개해보려고 합니다. 이 글을 통해 스타트업의 조직 문화 도입에 대해 관심이 많으신 분들께 도움이 되기를 바랍니다.
조직 문화의 가치
조직 문화는 쉽게 한 마디로 표현하자면, 모두가 한 마음 한 뜻으로 움직이기 위한 바이블입니다
회사에서 가치있게 생각하는 조직 문화를 여쭤보기 전에, 문득 저 스스로가 중요시하는 가치가 무엇인지에 대해 생각해보았습니다. 우리가 다양한 사람과 어울리는 사회 생활을 하다보면, 그 과정에서 많은 조직을 경험하게 됩니다. 그 중에서도 조직 내에서 특정한 역할을 맡게 되는 경우가 있죠. 학교에서는 수업을 성실히 들어야 하는 학생이 될 수도 있고, 조별과제의 조장이 될 수도 있습니다. 반대로 회사에서는 직원으로서 최선을 다해야 할 수도 있고, 함께 문제를 해결해 나가는 동료가 되기도 하고, 리더로서 조직을 이끄는 리더쉽을 발휘해야 할 때도 있습니다.
이 과정에서 내가 공통적으로 추구하고 있는 핵심 가치가 무엇인지에 대해 생각해본 적이 없다는 것을 깨달았습니다. 스스로에 대한 이해 없이, 그냥 단순히 회사에 조직 문화를 만드는 것이 어떻겠냐고 제안하는 것은 어불성설이라는 생각이 들었죠. 그래서 저는 다른 사람에게 있어서 함께 일하고 싶은 동료가 되기 위해 나는 어떤 노력을 하고 있는지에 대해 고민해보았습니다. 그렇게 저 스스로는 업무를 하면서 세 가지의 가치를 중요하게 여기고 있고, 저와 비슷한 생각을 가진 동료와 일하고 싶다는 것을 발견할 수 있었습니다.
우선 제가 중요하다고 가치들에 대해 간단하게 소개를 해봅니다.
- Professional
- 조직 구성원은 한 분야에 전문적인 사람이어야 합니다. 맡은 임무에 대해 주인의식을 갖고 품질 향상을 위해 최선을 다해야 합니다. 본인에게 주어진 일은 마감일 내에 처리할 수 있어야 하고, 그것이 어려울 때에는 합리적인 대안을 내놓을 수 있어야 합니다.
- Communicative
- 조직 구성원은 효율적인 의사소통을 위해 고민할 수 있는 사람이어야 합니다. 업무와 관련된 모든 의사소통은 공개적이어야 하고, 기록하고 정리된 후 공유되어야 하며, 약속된 절차를 따라야 합니다.
- Inspirational
- 조직 구성원은 다른 조직 구성원들에게 영감을 불러일으킬 수 있는 사람이어야 합니다. 단순히 맡겨진 일의 해결에만 집중하는 사람, 지금보다 더 나은 방법에 대해 고민하지 않는 사람은 더 이상 성장하지 못합니다. 나의 성장이 누군가의 성장에도 자극이 되어야 하고, 다른 사람의 성장을 보면서 나 역시도 성장하는 시너지를 일으킬 수 있어야 합니다.
개인적인 원칙이지만, 이것이 조직 문화에 있어서도 잘 어울릴 수 있을 것이라는 생각이 들어서 이것을 바탕으로 확장해 나가는 것이 어떨지 제안을 드렸습니다.
한편으로는 이것을 보고 이렇게 생각하시는 분도 계실 수 있을 것 같습니다.
에이, 저렇게 당연한 소리를 누가 못해? 프로답지 않고, 커뮤니케이션 못하고, 게으른 사람을 조직에서 걸러야 하는 건 당연한 거 아냐?
어느 정도 맞는 이야기입니다. 조직 문화는 도덕책에서나 나올법한 당연한 소리를 반복합니다. 하지만 그럼에도 불구하고 조직 문화를 구체적으로 명시해야 하는 핵심적인 이유는 조직 구성원들에게서 무형(無形)의 상태로 공유되고 있는 가치는 불확실하기 때문입니다. 즉, 조직 내에서 공유되고 있는 당연한 가치들이 누군가에게 있어서는 당연하지 않은 것일 수도 있다는 이야기입니다.
흔히 스타트업의 단점 중 하나로 체계가 없다 라는 말을 쉽게 들을 수 있습니다. 아래의 예시를 읽어봐주세요.
tvN 드라마 스타트업을 보고 환상에 빠진 취업준비생 A씨. 우연한 기회가 되어 어떤 스타트업에 합류하게 된다. 동료들은 가족같이 밝은 분위기였지만, 업무를 하다가 여러모로 시스템적인 불편함을 느끼게 된다. 약속된 업무가 아닌 다른 업무가 자신에게 넘어오고, 업무와 관련된 중요한 정보들을 찾을 수 없어서 항상 문제가 생기면 사수를 찾아 직접 물어봐야만 한다. 하루는 전사 회의 때 이런 불편함에 대해 호소를 했다. 하지만 돌아온 대답은 오히려 A씨를 당황하게 만들었다.
- “우리는 거기에 대해서 불편함을 느낀 적이 없었는데? A씨가 아직 적응을 못 한 거 아냐?”
- “A씨가 알아서 잘 딱 깔끔하고 센스있게 해줘야지.”
스타트업에서 체계가 없다 라는 말이 나오는 이유 중의 하나가 바로 조직 문화의 부재 때문이라고 생각합니다. 즉 모든 조직 구성원들이 같은 판단의 근거를 갖고 있지 않고, 공통적인 이해를 가지고 있지 않아서 생기는 문제인데요, 보통 이런 스타트업에서 가장 많이 하는 말이 있습니다. 참 무책임하고 추상적인 말이죠.
알아서 잘 해주세요.
조직 구성원들이 일을 바라보는 태도, 같은 상황에서 더 높은 우선순위를 가진 것들, 조직 내의 갈등 상황에서 판단의 근거가 될 수 있는 것이 전사적으로 공유가 된다면 이런 상황들에서 불필요한 토론으로 시간을 낭비할 일은 없을 것입니다. 다수의 구성원들로 만들어진 조직이 한 마음 한 뜻으로 움직일 수 있는 바이블을 만드는 것, 이것이 바로 조직 문화의 핵심 가치입니다. 마침 제가 합류한 조직에서는 조직 문화를 통해 추구하고자 하는 구체적인 가치가 명세되어 있지 않았고, 그래서 저는 구성원들에게 이렇게 말씀드렸습니다.
지금 조직 구성원들 사이에서 공유되고 있는 가치를 명시적으로 공유해주세요.
기존의 시스템을 이해하기
기존 조직을 이해하지 않고 무작정 변화를 제안하는 것은 역효과를 일으킬 수 있습니다
인터넷 커뮤니티를 들여다 보게 되면 닥눈삼 이라는 속어를 접할 수 있습니다. 닥치고 눈팅 3일 이라는 뜻인데요, 찾아보니 어원이 그렇게 좋은 의미는 아니더군요(;;). 아무튼 이 의미는 어떤 사람이 새로운 커뮤니티에 참여하려면, 대충 적어도 3일(3개월, 3년의 바리에이션이 있긴 하지만) 정도는 눈치껏 다른 사람들의 행동을 살펴보면서 불문율과 흐름을 파악하라는 뜻입니다.
이것이 조직 문화에 대해서도 어느 정도 맞는 말이라는 생각이 들었습니다. 그러니까 내가 어떤 조직에 들어가서 무언가를 바꾸려 하기 전에, 이미 돌아가고 있는 조직을 이해하기 위해 충분한 노력을 기울여야 한다는 뜻입니다.
어떤 스타트업에서 새로운 프로젝트를 앞두고 매니저급의 기획자 B씨를 새롭게 영입했다. B씨는 성실하고 의욕이 넘쳤다. 그래서 입사하자마자 창의적인 기획들을 쭉쭉 뽑아내었고, 이것을 프로덕트에 빠르게 반영해달라고 개발자 C씨에게 요청했다. 하지만 C씨는 해당 기획을 반영하는 것이 기존의 제품을 거의 뒤엎는 수준으로 많은 수정을 필요로 하게 됨을 알게 되었고, 이 제안을 거절하게 된다.
하지만 B씨는 간단한 기능인데도 불구하고 어렵다는 C씨의 말을 이해할 수 없었다. 결국에는 C씨와 의견 충돌이 발생하게 된다. 하지만 C씨 뿐만 아니라 다른 개발자들 역시 C씨의 입장을 두둔하면서, B씨의 입장은 난처해졌다.
위의 예시는 단순히 개발을 모르는 흔한 기획자 에피소드로 생각할 수도 있습니다. 하지만 제가 말하고 싶은 것은 기존의 조직과 시스템, 제품을 제대로 이해하지 못한 채 그저 조직에 근본이 없다! 고 말하면서 모든 프로세스를 뒤집어놓으려고 한다면 내부 구성원들의 반발이 심할 것이라는 것이 생각입니다. 그래서 저는 일정 기간 동안은 합류한 스타트업의 시스템과 문화를 나름대로 익혔고, 이 과정에서 불편함을 겪었던 프로세스들을 문서로 정리해서 전체 회의 때 공유를 하곤 했습니다. (사실 개인적으로는 3일도 매우 짧다고 생각합니다)
업무 프로세스 제안하기
모든 업무는 정해진 절차를 따라야 합니다. 절차가 없다는 것이야말로 말 그대로 진정한 프로세스의 부재입니다.
모든 업무는 그 목적에 맞는 프로세스가 존재해야 한다고 생각하는 편입니다. 가령 회의를 한다고 생각해봅시다. 매주 규칙적으로 열리는 정기회의가 있을 수도 있고, 특정한 문제의 해결책을 논의하기 위해 일회성으로 진행되는 회의도 있을 수 있습니다. 이 때 문제의 종류도 정말 다양하죠. 회사에서 고객을 대상으로 하는 이벤트를 기획한다거나, 외부 업체와의 미팅을 할 수도 있고, 프로덕트 배포 후 버그가 발생해서 개발적인 원인을 파악하기 위해 급하게 열리는 회의가 있을 수도 있죠.
분명히 회사에서 고객을 대상으로 하는 이벤트 기획 회의 와, 프로덕트에서 치명적인 버그가 발생해서 진행하는 회의 의 성격은 다릅니다. 필수적으로 참여해야 하는 구성원들도 다르죠. 이처럼 업무를 하면서 발생할 수 있는 다양한 상황에 맞는 프로세스가 구축되어 있어야 합니다. 모든 상황을 고려하여 프로세스를 세팅할 수는 없지만, 적어도 규칙적으로 발생하는 업무 프로세스는 세팅되어 있어야 합니다.
회의는 참여하는 구성원들의 시간을 모두 쓰는 것이기 때문에 최대한 목적에 맞게 간결하고, 군더더기 없이 진행이 되어야 합니다. 그리고 그렇게 효율적인 업무 프로세스를 설정할 수 있게 도와주는 것이 바로 회의록입니다. 업무 목적에 따라 미리 회의록을 템플릿화 해놓으면 회의 도중 다른 길로 샐 일이 많이 줄어들죠. 아래의 예시를 살펴봅시다.
한 스타트업에서 데이터 사이언티스트로 일하고 있는 D씨. 대표가 며칠 후에 외부 업체와의 미팅이 있었기에, 서비스에서 수집된 로그를 바탕으로 유의미한 통계 자료가 있는지를 함께 살펴보고 있는 중이었다. 그러다가 문득 특정 날짜부터 지표가 낮게 나온 모습을 보고 대표가 질문했다.
- “왜 저 날부터 DAU(일일 활성 사용자 수)가 유독 줄어들기 시작한 거죠? 외부 업체와의 미팅에서 원인을 물어볼 것 같군요.”
- “경쟁사에서 기념일을 앞두고 이벤트를 개최했다고 합니다.”
- “흠… 그렇군요. 마침 다음 주가 크리스마스인데 우리도 이벤트 하나 해야 하지 않을까요? 작년에도 비슷한 이벤트 했다가 서버가 갑자기 터져서 서비스가 불통이 되는 바람에 욕을 왕창 먹긴 했지만.”
- “넵. 그때는 그렇게 많은 유저가 몰릴 줄은 몰랐죠. 미리 준비를 해 둔다면 괜찮지 않을까 싶습니다.”
- “그러면 통계 확인은 여기까지 하고, 다른 분들께 바로 기획 및 개발 준비 시키도록 할게요. 그건 그렇고 지금은 이렇게 엑셀로 보고 있지만 데이터 시각화가 구현된 백오피스 페이지도 구현되면 좋겠네요.”
회의실을 나온 대표는 기획자, 개발자, 디자이너를 따로 불러 이야기했다.
- “제가 방금 D씨와 이야기를 하다가 떠오른 건데, 당장 다음 주부터 크리스마스 이벤트를 해야 하지 않을까 싶어요. 지금 하고 계신 것은 잠시 그만두고 크리스마스 이벤트에만 집중해주세요. 기획자는 작년 이벤트와 비슷하면서도 조금 다른 포맷으로 기획해주시고, 개발자는 작년처럼 서버 터지지 않게 준비 단단히 해주시고요. 디자이너분은 작년 리소스 적당히 활용해서 만들어주세요. 그리고 나중에는 데이터 시각화 기능이 포함된 백오피스 페이지도 제작할건데, 이 기획도 시간 날 때 해두면 좋을 것 같네요.”
D씨와 대표와의 회의를 외부 업체 미팅 준비로만 알고 있었던 기획자, 개발자, 디자이너는 갑작스런 업무 변경 요청에 당황스러운 표정을 지을 수 밖에 없었다.
특히 작은 조직일수록 회의를 하다가 다른 길로 새는 일이 잦습니다. 이걸 스타트업만의 프리하고 자유로운 분위기 라고 이야기하는 분도 있지만 저는 그렇게 생각하지 않습니다. 마치 코드에서 하나의 함수가 하나의 기능을 해야 하는 것처럼, 하나의 회의는 하나의 목적만을 가져야 합니다. 회의의 목적과는 다른 결론이 부가적으로 나오게 된다면, 그 회의는 방향성이 설정되지 않아서 중구난방으로 진행된 회의입니다.
가령 포스트 모템 회의(Post mortem, 프로덕트에 심각한 결함이 발견되어서 이를 수정한 후 재발 방지 대책에 대해 논의하는 회의)를 예시로 들어봅시다. 정해진 프로세스가 없다면 누가 모여야 할 지부터 고민이 됩니다. 개발적인 이슈인데 개발자들만 모여야 하나? 기획자도 함께 모여야 하나? 모여서 막상 어떤 얘기를 해야 하나? 누구한테 잘잘못을 따져야 하나? 결국 이런 프로세스에 대한 고민을 미리 하지 않는다면, 정작 많은 사람들이 모여서 시간을 쏟아부었지만 쓸만한 결과물은 없는 허술한 회의가 되죠.
이럴 때 프로세스가 미리 있다고 생각해봅시다. 회의록은 사전에 템플릿으로 구성되어 있어서 누구나 쉽게 생성할 수 있습니다. 그리고 템플릿 최상단에는 이 회의가 언제 열리는지, 회의를 개최하는 이유와 목적, 필수적으로 참여해야 하는 인원들, 그리고 참여자들이 참고해야 할 주의사항들이 적혀져 있습니다. 가령 이 회의는 누군가를 문책하는 자리가 아니라 원인을 파악하고 재발을 방지하는 자리라는 것을 참석 인원들에게 미리 리마인드 시킬 수 있겠죠.
한편으로는 회의 진행에 앞서서 전체적인 플로우에 대해 짚은 후 회의를 시작하는 것이 주제가 다른 길로 새는 것을 방지하는 데 좋은 역할을 할 수 있다고 생각합니다. 금일 회의는 발생 일시, 사건 요약, 유발된 효과, 근본 원인, 해결책, 재발 방지책 순으로 회의를 진행할 것이라는 것 처럼요. 그 후에는 순서에 따라 회의를 진행하고, 너무 특정 항목에서 오래동안 회의가 지속되지 않게 중재를 잘 해주면 될 것 같습니다. 그리고 작성된 회의록은 내부 구성원들에게 공유하고 비슷한 사건이 재발할 때를 대비하여 쉽게 찾아볼 수 있어야 합니다.
한편으로는 회의록은 항상 회의에 참석하지 않은 구성원들에게도 공유가 되어야 한다고 생각합니다. 아래의 예시를 살펴볼까요.
스타트업에 웹 개발자로 합류한 E씨. 자신을 제외한 다른 구성원들은 한창 이벤트 기획과 개발에 쏟느라 정신이 없어보였다. E씨는 팀장에게 자신이 도울 일이 없을지를 여쭤봤지만, 팀장은 “이번에는 웹 쪽은 개발 예정된 게 없어서 다른 작업을 봐주시면 될 것”이라고 말했다.
하지만 며칠 후 배포를 앞두고 갑작스럽게 웹 개발이 필요하게 되었고 어쩌다보니 E씨가 작업을 맡게 되었다. 하지만 여태껏 단 한번의 회의에도 참여하지 못한 E씨는 지금 무엇을 목적으로 개발을 해야 하는지에 대한 히스토리를 파악할 길이 없었다. 결국 E씨는 팀장에게서 구두로 전해들은 요구사항만 구현한 채 배포를 하게 됐고, 결국 프로덕션 환경에서 버그가 터지고 말았다.
프로세스의 부재로 인해 구성원 간의 정보 불균형이 생겼고, 이것이 프로덕트에도 영향이 간 예시입니다. 채용이라던가 회계처럼 민감한 내용이면 몰라도, 업무와 관련된 모든 정보는 투명하게 공유되어야 합니다.
그래서 저는 유형 별로 프로세스가 정의되어 있지 않은 업무들을 파악했고, 업무 목적 별로 프로세스를 정리해서 템플릿을 미리 만들어 놓는 것이 좋을 것 같다고 제안했습니다. 그리고 회의 뿐만 아니라 회사에서 암묵적으로 진행되고 있는 모든 프로세스들을 파악해서 이를 문서화하는 작업도 진행을 해야 한다고 말씀드렸습니다.
채용 프로세스 제안하기
누군가가 회사에 지원을 한다는 것은 한 사람의 인생이 온다는 이야기를 들은 적이 있습니다. 그만큼 회사에서도 프로페셔널한 태도로 지원자와 입사자를 위해 신경을 써주야 합니다.
채용 프로세스에도 어느 정도 제안을 드렸습니다. 저는 JD(Job Description) 페이지가 회사의 핵심적인 조직 가치를 가장 잘 드러낼 수 있는 위치라고 생각을 하는데요, 위에서 정했던 조직 문화의 가치들이 JD에서도 바로 드러났으면 좋겠다는 것이었습니다. 때문에 여러 회사들의 JD를 리서치해보며 지금 회사에서 추구하고자 하는 가치에 대해 함께 고민해보기도 했습니다.
온보딩 프로세스에 대해서도 제안을 드렸습니다. 온보딩 프로세스는 조직에 새로 합류한 사람이 빠르게 조직 문화를 익히고 적응하도록 돕는 과정입니다. 마치 게임의 튜토리얼과도 같죠. 즉 온보딩 프로세스가 없다는 것은 새로온 구성원의 적응을 어렵게 하고 불편을 가중시키는 원인이 되기도 합니다. 뿐만 아니라 퇴사자가 발생했을 때 처리해야 하는 프로세스를 파악하는 데에도 도움이 되죠.
스타트업에 새로 합류한 개발자 F씨. 당장 어떤 업무를 시작할까 고민을 하다가 회사의 깃허브 조직에 아직 포함이 안되어 있다는 것을 알고 팀장에게 요청을 드린다. 팀장은 깜빡했다면서 깃허브에 초대를 해 준다. 하지만 깃허브 뿐만 아니라 슬랙, 노션, 트렐로, AWS, 제플린 등 다양한 도구들을 쓸 때마다 누군가에게 초대 요청을 해야 하는 일이 생기자 피곤함을 느낀다. ‘아니, 여긴 왜 이렇게 체계가 없어?’
한편 퇴사자 G씨는 퇴사 후 한 달이 지난 아직까지도 자신의 회사 AWS 계정과 노션 계정이 활성화가 되어 있다는 것을 파악한다. 마침 좋지 않게 퇴사했던 G씨는 몰래 노션 문서를 지워버리고, AWS에 올라가 있는 중요한 코드를 비활성화 해버린다.
회사에는 필연적으로 많은 사람들이 들어오고 나가게 됩니다. 매번 새로운 사람이 입사할 때마다 진행해야 하는 프로세스들을 기억에만 의존하는 것은 완전하지 않습니다. 때문에 입사 후 처리와 관련된 프로세스들을 체크리스트로 정리해서 제안을 드렸습니다.
개발 문화 도입하기
개발은 곧 협업입니다.
우선 저의 합류로 인해 웹 프론트엔드 개발자가 다수가 되었기 때문에, 프론트엔드에 한해서 코드 리뷰를 활성화시켰습니다. 그리고 개발자의 생산성을 향상시켜 줄 수 있는 여러가지 도구를 팀에 소개하고 이를 적극적으로 도입했습니다. 이 과정에서 코드 컨벤션을 맞추고, CI/CD 및 인프라 환경 설정 관련해서도 자동화를 제안을 드렸습니다. 한편으로는 보안적으로 취약한 부분들을 파악해서 개선해야 할 부분으로 남겨놓았죠.
예전 회사에서 정보 공유 라는 이름으로 여러 회사/개인의 기술 블로그를 RSS 피드로 구독할 수 있게 해둔 채널이 있었는데 이것이 개인적으로는 많은 도움이 된 것 같아서 새 회사에서도 바로 도입을 했습니다. 개발자들끼리 새로운 개발 주제에 대해 이야기할 수 있는 장이 마련된 것은 위에서 이야기한 영감을 줄 수 있는(Inspirational) 원칙에도 해당되는 듯 합니다.
마무리
조직 문화 그 자체는 굉장히 추상적입니다. 책에서 본 좋은 것만 이야기하는 것이 마치 뜬구름 잡는 이야기 같죠. 허나 이러한 원칙이 조직 구성원들에게 잘 공유가 되고, 그에 따라 행동과 판단을 하게 된다면 이것이 한 몸처럼 움직이는 조직을 만드는 데 많은 도움이 되는 것 같습니다. 괜히 대기업들이 인재상으로 다이어그램까지 그려서 소개 페이지에 올려놓는 것이 이상한 게 아니라는 생각을 하게 되더라구요.
한편으로는 예전 회사를 다니면서 배운 조직 문화들이 저에게도 정말 많은 도움이 되었습니다. 그리고 훨씬 크고 거대한 조직의 문화를 만들고 발전시켜 나간 것이 굉장히 대단하다고 느껴졌습니다. 제가 부족해서 그런 것일 수도 있지만, 아직까지는 조직의 문화를 바꾸어나간다는 것이 생각보다 어려운 일이라는 것을 깨달았거든요. 나 혼자만 열심히 해서 되는 일이 아니라 구성원들의 마음 속 깊은 곳까지를 이해해야 한다는 생각에 깊은 책임감을 느끼곤 합니다.
사실 글로 적지 못한 다양한 이슈들이 많지만, 아무튼 이런 경험을 해보는 것도 나쁘지 않다는 생각을 해 보게 되었습니다. 언젠가는 저에게도 더 큰 조직을 이끌어나갈 기회가 생길 수도 있으니까요.
