임프라브와 다양성 (2)
PART 2. 개발자와 개발과 다양성
헬렌
이제 '개발자와 개발과 다양성'에 대해서 한번 얘기를 해볼까 합니다. 개발자 세 분을 모셨는데요. 아까 소개해 주시긴 했지만, 이번에는 개발자로서 좀 더 구체적으로, 각자의 개발 분야나 하고 계신 일의 설명을 부탁드려도 될까요?
의제 저는 대기업에서 안드로이드 앱 개발을 하고 있습니다. 소셜 커뮤니케이션 앱에서 채팅 서비스 영역을 담당하고 있어요. 그래서 대부분 채팅 관련 기능을 개발해요. 채팅 화면 내에 화상 통화 기능도 있어서, 요즘은 화상 통화와 관련된 기능들을 추가로 개발하고 있습니다. 예를 들면 통화 중에 가상 배경을 넣는 기능 같은 거죠. 앱 개발 이전에는 3년 정도 서버 개발도 했었어요. 서버 개발을 하다가 앱 개발로 넘어간 사례입니다.
휘동 저도 이것저것 했어요. 서버 개발도 했었고 게임 개발도 잠깐 해봤었고요. 몇 년 전부터는 스타트업에서 웹 개발 중에서도 프론트엔드 쪽에 집중하고 있고, 리드 역할을 맡은 지는 2년 반 됐습니다.
계홍 저는 24년 차 프리랜서 웹 개발자이자 애자일 코치입니다. 저는 개발을 좋아해요. 제가 좋아하는 개발을 잘하고 싶고, 그리고 다른 개발자들도 개발을 좋아하고 잘할 수 있도록 돕고 싶어요. 그러다 보니 애자 일에 관심을 갖게 되었습니다.
2009년부터 국내 애자일 커뮤니티에서 활동을 해 왔고, 지금은 애자일 코리아 얼라이언스 보드멤버로 1년에 한 번씩 진행하는 애자일 코리아 컨퍼런스(https://agilekorea.kr)와 1달에 한 번 진행하는 애자일 밋업 행사를 돕고 있습니다.
또 플레이 애자일팀(https://playagile.co.kr) 멤버로 활동하고 있습니다. 애자일을 쉽고 재미있게 전달하기 위해 다양한 직군 5명이 모여서 레고4스크럼이라는 과정을 중심으로 다양한 애자일 과정을 만들어 교육하고 있습니다.
보라 제가 개발자가 아니다 보니 갑자기 궁금해졌는데요, 여러분이 생각하기에 개발자들이 갖는 공통점이 있을까요? 예를 들면 개발자 사회 안에서도 "개발자들은 참 유난해, 독특해" 같은 말을 듣는 경우가 있는지 궁금해요.
헬렌 맞아요. 저도 비개발자로서 개발자에 대한 전형적인 편견이 조금 있거든요. 예를 들면 개발자들은 매우 논리적이다, 또는 혼자 일하는 걸 좋아한다. 왜냐하면 혼자 컴퓨터로 맨날 코딩하는 것 같이 보이니까.
의제 개발자 공통점 하면 우스갯소리로 청바지에 체크 남방을 가장 먼저 떠올릴 것 같아요.(웃음) 제가 있는 회사에서 크게 3가지 직군이 나뉘어요. 개발, 기획, 디자인 직군인데요. 다른 직군에 비해서 개발 쪽 분들이 옷을 좀 편하게 입어요. 고객을 만날 일이 없어서 그런가? 아무튼 그렇습니다. 그리고 좀 더 논리적으로 말하거나 보이고 싶어 하는 특징이 있습니다. 대화에 ‘리소스'라는 단어를 많이 쓴다든지요. 예를 들면 ‘이번 이슈는 리소스가 부족해서 어려울 것 같습니다.’ 그리고 이건 대학생 때부터 느꼈던 건데, 뭔가 최단 거리를 찾거나 효율적인 방법을 찾는 걸 좋아했던 기억이 있습니다.
계홍 의제님 얘기에 공감되는데, 개발자들은 공통으로 논리적이고 문제 해결 중심인 것 같아요. 개발자들이 하는 일이 문제를 찾고, 문제를 해결하는 것이다 보니 그럴까요? 이 특징이 일상생활과는 맞지 않는 부분이 있어서 생각이 자주 나네요.
저도 개발자라서 이런 경우가 많아요. 다른 사람의 이야기를 들으면서 자연스럽게 그 속에 있는 문제를 찾고, 그 문제를 해결하기 위한 방법을 생각하고, 이야기하거든요. 그런데 원래 이야기한 사람은 그냥 이야기를 들어주고, 공감받기를 원하는 경우가 많더라고요. 게다가 문제 해결을 위한 솔루션들은 오히려 역효과를 내는 경우가 많고요.
휘동 저는 '개발자의 공통점'에 대해 쉽게 얘기하기가 좀 어렵네요. 『팩트풀니스(Factfulness)』라는 책에서 나온, "집단 간 차이보다는 집단 간 유사성이 더 많고, 집단 내 개체들 사이의 차이가 훨씬 크다, 우리가 집단으로 일반화하는 걸 주의해야 한다"는 말을 좋아하거든요. 저는 거의 스타트업에서만 일을 해봤기 때문에 스타트업이라는 조직 특성 때문에 생기는 편견이 있을 것이고 개발자로서 나오는 편견이 있을 거라서… 아무튼 저와 제 주변을 바라보면서 생각나는 걸 좀 얘기해 보겠습니다.
저는 개발자들이 논리적인 거랑 비슷하게, 구조나 원리를 파악하는 걸 좋아하는 것 같습니다. 디테일에 집착하는 건데요. 어떤 현상이 있을 때 그렇구나, 에서 끝나는 게 아니라, 왜 그렇지? 저걸 내가 직접 만들면 어떻게 할 수 있을까? 아니면 저걸 어떻게 만들었을까? 이런 걸 많이들 궁금해합니다. 특히 웹 개발자들은 브라우저에서 홈페이지를 직접 뜯어볼 수 있으니 뜯어보는 행위도 많이 하는 것 같고요.
또 하나는, 개발자는 여러 도구를 가져다가 조합해서 쓰는 데 익숙합니다. 그런 데서 오는 자유로움이 있어요. 예를 들면 예전에는 인터넷은 무조건 "인터넷 익스플로러"로만 해야 하는, 그러니까 인터넷 익스플로러라는 브라우저가 곧 인터넷인 분들이 있었죠. 저도 어릴 때는 그랬고요. 개발자들은 새로운 도구들을 많이 접하면서, 사실은 브라우저라는 도구가 단일하지 않고 여러 개 중 내가 선택할 수 있구나, 같은 걸 깨달으면서 자유로움이 생깁니다. 그게 성격에도 조금은 반영되지 않나 싶어요. 하나에 정착 잘 못하고 여기저기 옮겨 다니는?
마지막으로, 성장과 학습이라는 키워드에 대한 집착이 있습니다. 카카오톡 상태 메시지나 블로그 대문 같은 데에 성장 얘기 써둔 주니어 개발자 정말 많을 거예요. 저도 아기 키우기 전까지 마찬가지였고요.
헬렌 비개발자인 제가 보기에는 개발 업무에서 요구되는 특성과 임프라브에서 요구되는 특성이 굉장히 달라 보이는데 이 굉장히 다른 특성을 보인 활동을 같이하면 생기는 장점은 뭐고 단점은 뭘까요?
예를 들면 개발자로서 요구되는 특성이 있을 거고 임프로바이저로서 요구되는 특성이 있을 텐데, 개발자이면서 임프라브를 하시는 세 분께 혹시 이런 걸로 인한 장점이 있거나 단점이 있다면 뭐가 있을까요.
계홍 아까 말씀드린 것처럼 개발자는 어떤 컴퓨터 안에서 생겨나는 문제를 해결하는 데 포커스를 두는데, 임프라브는 사람과 커뮤니케이션해야 하잖아요. 그래서 달라 보이는데, 이걸 조금 더 넓게 가면 아까 말씀드린 것처럼 또 비슷한 면이 있어요.
요즘은 프로젝트를 할 때도 컴퓨터만 잘하는 게 아니라 협력이 중요해지면서 고객, 아니면 다른 팀((기획자나 디자이너)과도 대화해야 하는데, 때로는 서로 사고하는 방식이 너무 다르다 보니까 대화하기가 힘들 때가 있어요. 그러면 커뮤니케이션하면서 오해가 일어나요. 기획자가 이야기한 것과 내가 만든 게 다른 일이 반복되면 일하기가 너무 싫어지거든요.
근데 임프라브에서 다양성을 훈련하고, 커뮤니케이션하면서 서로 다르게 생각할 수 있다는 걸 생각하게 되면 대화와 업무에서도 조금 더 여유가 생기는 것 같아요. 그래, 우리 잘못 생각할 수 있지. 이게 심리적 안정감하고도 좀 연결이 되는 것 같은데요. 다른 사람을 이해하지 못하게 되면 '아니 이 쉬운 걸 이해를 못해? 어떻게 저런 말도 안 되는 생각을 하지?' 이런 생각을 하게 되고요. 반면 서로의 다른 점을 인정하고 발견하면서 호기심을 가지면 일하기가 굉장히 편안해지죠.
그래서 임프라브와 개발은 굉장히 다른 면이 있지만, 임프라브에서 커뮤니케이션을 경험하는 게 개발자에게도 매우 도움이 됩니다.
휘동 임프라브를 통한 단점은 솔직히 모르겠고요. 저는 임프라브를 개인적 재미와 희열 쪽으로만 많이 바라봤었어요. 그래서 임프라브를 하는 게 나에게 영향을 주고, 그게 다시 실무에 영향을 주는 간접적인 관계에서는 분명히 장점이 있었다고 생각하는 데 직접적인 관계로서의 장점은 잘 모르겠네요.
그러면 간접적인 부분에서는 어땠냐고 생각을 해보면, 계홍님 얘기하고 좀 비슷합니다. 저는 리더 입장에서 사람들을 채용하고자 할 때 '코딩은 잘하는데 협력이 잘 안되는 사람'과 '협력이 잘 되는데 코딩을 잘 못하는 사람' 중에서는 대부분 후자를 택했던 것 같아요. 왜냐면 코딩을 잘하는데 협력 못하는 사람이 애초에 거의 없어요. 협력은 못 해도 코딩을 잘하는 것처럼 보이는 사람이 실제로는 코딩도 못 하는 사람인 경우가 많았어요.
탁월한 개발자의 아주 중요한 특징 중에 '다른 사람의 효과적 의사결정을 도울 수 있다'는 게 있거든요. 그런데 협력을 못 하면 남을 도울 수가 없기 때문에, '협력을 못 하면서 코딩을 잘한다'는 것 자체가 애초에 모순적인 명제라는 생각이 들어요. 이런 협력적인 측면을 발전시키는 데는, 꼭 일을 위해서가 아니더라도 임프라브가 많은 도움이 된다고 생각합니다. 임프라브의 기본이 예스앤드고, 동료를 포용해 주고 백업해 주는 훈련을 많이 하잖아요. 이런 게 실무에서도 동료를 관찰하고 돕는 자세를 발달시키는 훈련이 된다고 생각합니다.
의제 저도 비슷한 맥락이에요. 컴퓨터 개발이랑 임프라브에 요구되는 역량 자체는 명확히 다르다고 생각해요. 개발에서 중요한 역량은 문제해결이고 임프라브는 커뮤니케이션 혹은 표현하는 쪽이라고 생각합니다. 이렇게 두 개가 너무 상반되지만, 그게 서로 보완이 된다고 봐요. 개발을 혼자 하는 게 아니잖아요. 팀으로 개발하다 보니까 서로 커뮤니케이션하는 부분이 많죠. 그래서 같이 일할 때 임프라브에서 배운 것들이 도움이 돼요.
그리고 인사평가를 잘 받으려면 또 일을 잘하는 척도 해야 하잖아요. (웃음) 그럴 때 연기에서 배운 표현하고 전달하는 법이 많은 도움이 되었어요. 그리고 상대방이 뭘 원하는지 관찰하는 습관도 길러줘서 도움이 됐습니다.
계홍 휘동님 이야기를 듣다 보니까 생각나는 게 있어요. 저는 개발자들이 아무래도 내성적인 분들이 많이 있는 편이라고 생각해요. 혼자 일해도 자신의 가치와 능력을 보여줄 수 있거든요. 그런 특성 때문에 개발 팀장과 같은 리더급이 되면 협력과 커뮤니케이션의 중요성이 갑자기 더 올라가는 느낌이 있어요. 그러다 보니 같이 연결되는 게 의지력이나 회복력 같은 부분도 있다고 생각해요. 일도 일이지만 사람들을 만나서 대화하는 것 자체만으로도 스트레스를 받고 힘든 거죠. 이런 스트레스는 직급을 막론하고, 그리고 어떤 일을 하든지 항상 있는 일이기는 하죠.
임프라브 자체가 코미디라 많이 웃을 수 있기도 하고요. 또 다양한 역할, 다양한 연기를 하면서 감정 표현도 많이 하게 되는데, 그러면서 스트레스가 확 풀리는 느낌들이 좀 있거든요. 임프라브의 이런 특성들은 다른 일상생활을 할 때도 큰 도움이 되는 것 같아요. 새롭게 일을 시작할 수 있도록 몸과 마음을 회복해 주는 것 같습니다.
헬렌 네, 제가 임프라브를 오랫동안 가르치면서 개발자인 분들 그리고 또 개발자가 아닌 분들한테 질문을 한 적이 있었어요. 임프라브가 실제로 도움이 되느냐, 실제로 회사에서 현실적으로 쓰냐, 라고 여쭤봤는데요. 개발을 오래 하시다가 리더 역할을 하시는 분께서 "관리자로서 팀을 이끌다 보면 중재 역할을 굉장히 많이 하게 되는데 중재 역할을 할 때 다른 가면을 써야 할 때가 많다. 그럴 때 임프라브가 매우 큰 도움이 되었다."라고 얘기해 주시더라고요.
업무 외적으로도 예스앤드 화법을 쓰면서 부부 사이가 좋아졌다거나 사춘기 자녀분들하고 관계가 굉장히 좋아졌다는 얘기를 들었네요. 또 어린아이를 기르는 분들은 아이와의 스토리텔링 11) 이나, '뭐하고 있어?' 12) 같은 게임을 하면서 아이랑 재미있게 잘 놀아주게 되었다거나 이런 일반적인 내용으로 얘기를 많이 들은 것 같아요.
계홍 또 하나 생각나는 게 있어요. 일을 할 때 팀워크나 협력은 정말 중요한데 잘 안되는 경우도 많잖아요. 가만 보면 회사에서 일할 때는 협력한다는 게 뭔지도 잘 모르는 분들도 있어요. 저는 '협력도 해 본 사람이 잘한다'고 생각해요. 협력하면서 함께 공동의 목표를 이루는 경험이 있는 다른 협력을 할 때도 도움이 된다고 봐요.
저는 그 느낌을 임프라브에서 경험하기 쉽다고 생각해요. 임프라브 할 때, 예스앤드의 마법이랄까 정말 생각지도 못했던 방향으로 뭔가 착착 스토리가 진행되면 깜짝 놀라거든요. 완전 창의적이고 너무 멋진 극이 만들어질 때가 있어요. 저는 이런 경험이 일을 할 때도 도움이 된다고 생각해요. 일을 할 때도 어떤 일이든 어려움은 있잖아요. 길이 안 보이기도 하고요. 그걸 해결하기 위해서 함께 일을 할 줄 아는 사람들이 있어요. 그런 분들의 작은 행동 하나하나가 다른 사람을 이끄는 리더십이 되고, 그런 것들이 쌓여서 좋은 결과를 만들어 내게 되거든요. 정말 일하는 분위기부터 다르기는 해요. 저는 이런 경험? 분위기? 리더십? 같은 것을 임프라브에서 경험하기 좋다고 생각해요.
헬렌 그렇다면, 임프라브가 개발자로서 일할 때 새로운 관점을 갖는 데 도움이 되었나요? 신선한 관점, 예를 들면 버그가 발생했는데 해결이 잘 안되다가, 임프라브를 통해서 해결된 사례가 있으신가요?
휘동 사례는 아니고 좀 반성이 되는데요. 아까도 얘기했지만, 너무 개인적인 관점에서만 임프라브를 바라보지 않았었나 싶어요. 제가 임프라브를 더 잘하기 위해 고민했던 게 있고 개발자로서, 특히 팀 리드로서 고민했던 게 있는데 좀 더 의식적으로 노력했다면 이 둘이 잘 맞닿을 수도 있었겠네요.
의제 업무에 직접적인 도움보다는 간접적인 방향으로 도움이 돼요. 상대방의 피드백을 좀 더 열린 마음으로 받아들이면서 성장할 기회가 됩니다. 업무 중에 코드 리뷰라는 게 있어요. 동료 간에 서로 작업한 내용을 보고 코멘트를 달아주는 건데요. 그 과정에서 가능하면 동료가 준 코멘트를 반영하려고 해요. 혹은 새로운 기술을 한번 적용해 보자는 제안을 줬을 때, 가능하면 받아주려고 하고요. 그 과정에서 실력이 많이 성장한 것 같아요. 그리고 이렇게 수용하는 자세가 함께 일하는 팀 분위기를 좋게 만들어 주니까 좋은 것 같습니다.
계홍 저는 이게 임프라브 때문인지는 잘 모르겠는데, 임프라브를 하기 전에 대화할 때는 정보를 제공하려고 많이 했던 것 같아요. 어떤 일을 문제 해결 중심으로 본다는 것도 같은 맥락이고요. 대화할 때 어떤 정보가 오고 가지 않으면 흥미도 떨어지고, 대화하기 어려운 것을 느껴요. 예를 들면 논쟁 같은 것, 어떤 주제를 가지고 이야기하면 편안하게 할 수 있는데, 주제가 주어지지 않으면 대화하기 어려웠어요. 그래서 불평불만 같은 것도 좋아하는 편은 아니에요. 공감도 잘 안 가고요.
임프라브에서 토론하는 연기를 하지는 않잖아요. 일상생활과 관련된 연기를 많이 하고요. 그러면서 저는 좀 더 사람에 대해서 관심을 두게 된 것 같아요. 그리고 공감도 좀 더 하게 된 것 같고요.
어쨌든 저는, 제가 그런 사람인지 몰랐는데, 생각보다 사람에 관심이 좀 없더라고요. 저는 다른 사람들을 좋아한다고 생각하고, 도움이 필요하다면 언제든지 도와주고 싶은 마음도 많거든요. 그런데 사람 자체에 대해서 호기심이 생기지는 않더라고요. 이런 부분을 알고 나니, 조금 더 사람에 관심을 두게 되고, 임프라브도 더 흥미롭게 보이는 것 같아요. 이런 생각은 임프라브만은 아니고 제가 받는 상담도 많은 도움이 되었어요.
보라 듣다 보니까 저희 대화 내용이 지금 대학에 다니고 있는 학생 또는 청년들에게 도움이 많이 될 것 같아요. 이것도 편견일 수 있겠습니다만 (웃음), 제가 현업에서 일하고 있는 친구들한테 듣거나 또는 매체에서 이야기하는 걸 보면, 요즘의 청년들은 자기 일을 굉장히 열심히 하지만 내 일만 잘하면 된다는 마인드로 임하시는 분들이 간혹 있다는 얘기를 들어요. 그런데, 아까 세 분 다 협력이라는 관점에서 임프라브가 도움이 되는 것 같다고 말씀하셨어요. 그리고 실제로도 개발 업무를 할 때 그게 굉장히 중요한 요소라고 말한 것들이 앞으로 사회에 진출하고 사회에 적응해 나가려는 사람들한테 영감이 될 만한 말이지 않을까 하고 생각을 해요.
헬렌 개발하거나 또는 회사 생활을 하면서 다양성과 관련된 어떤 상황이 있으셨는지 궁금해요. 그런 이야기가 앞으로 사회진출을 앞둔 분들한테 혹시 도움이 될 수도 있을 것 같아서요.
휘동 팀 구성이나 채용 측면에서 다양성과 관련된 사례가 많았습니다. 특히 초기 스타트업에서는 지인 위주로 채용을 많이 하거든요. 근데 지인의 풀이 결국 지인의 지인까지 포함해도 한정적이에요. 그래서 채용을 넓히려면 어쩔 수 없이 새로운 세계로 나가야 합니다. 어떤 형태로든 새로운 사람을 팀에 데려오면, 그분의 지인으로 채용 풀이 넓어지는 효과도 있지만 예상치 못했던 낯섦으로 인한 효과도 많이 보게 됩니다.
간단한 예로, 사실 개발자 중에서는 여성 비중이 엄청나게 적은 편이거든요. 그래서 그런지 몰라도 여성 개발자가 처음으로 팀에 오셨을 때 느껴지는 변화가 분명히 있었습니다. 우선 문서 가독성이 갑자기 좋아지더라고요. 이보다 중요한 건, 우리가 저도 모르게 평소에 사용하는 약어나 단어에서 좀 더 조심스러워지는 면이 있습니다. 누가 그렇게 하자고 명시적으로 말한 건 아니지만, 그룹 마인드처럼 다들 언행을 더 조심하게 되는, 그러니까 조직 자체가 더 성숙해지는 느낌이 있었어요.
계홍 아까 휘동님이 개발 분야에서는 도구나 기술들을 많이 조합해서 갖다가 쓴다고 해주셨잖아요. 이런 좋은 도구나 기술을 찾고, 빨리 배우는 것이 중요한데, 기존에 잘 사용하던 것을 바꾸기는 항상 어렵잖아요. 개발자들에게도 마찬가지예요. 바꾸라고 하는데, 정말 바꾸기 싫을 때도 있고, 바꾸고 싶은데 절대 안 된다고 하기도 합니다.
개발자 중에는 새로운 것 자체를 좋아하는 분들도 많은 편이지만, 아닌 분들도 많죠. 저는 그럴 때 바로 옆에 있는 사람들이 영향을 많이 주는 것 같아요. 옆에서 새로운 기술과 도구를 멋지게 사용하고 있으면 그게 동기부여도 되고, 학습 속도도 엄청 빠르게 해 줍니다. 저는 그래서 프로젝트를 하면서 새로운 도구나 기술을 사용하고, 그리고 주변에 알려주는 것을 좋아해요.
개발자가 다양한 동료, 다양한 프로젝트, 다양한 회사를 경험하는 것은 이런 측면에서도 중요하다고 생각해요. 이런 다양한 경험이 빠른 IT 기술의 변화를 따라갈 수 있게 하는 거죠.
저는 프리랜서 개발자잖아요. 어떤 프리랜서 개발자분이 프리랜서의 매력이 자기가 원하는 프로젝트를 선택할 수 있다는 점이라고 하더라고요. 자기가 원하는 프로젝트를 선택해서 새로운 도구와 기술을 만나면서 빠르게 적응해 나갈 수 있게 되는 거죠.
휘동 다시 채용 얘기인데요. 제가 지난 직장에서 채용 프로젝트를 다양한 사람들하고 진행해 보면서 기술적 역량이 엄청나게 향상됐었거든요. 한 회사에 특히 오래 있다 보면 계홍님 말씀처럼 쓰는 기술만 쓰게 돼요. 하지만 그 기술이 굉장히 빠르게 노후화됩니다. 도구 자체는 트렌디해도 버전 업데이트 한참 동안 못 하는 일 많거든요. 근데 신규 프로젝트는, 특히 채용 프로젝트는 사람들이 자기가 해보고 싶었던 욕망을 최대한 거기 분출합니다. 새로운 기술을 마구 가져다 써요. 저는 엔지니어를 평가할 때 '자기가 어떤 기술을 왜 쓰는지 장단점을 다 알고 선택할 수 있는가?' 를 중요하게 보기 때문에, 새 기술 가져오시면 그걸 다른 후보 대신 왜 선택했는지 항상 물어봅니다. 그렇게 대화하다 보면 이게 생각보다 안정적인 기술이네, 생각보다 좋게 이런 걸 저도 많이 배웁니다. 그래서 채용 프로젝트가 저에게 더 많은 다양성을 가져다주고, 컴포트 존(comfort zone)을 벗어나게 해주고, 성장시켜 주는 도구이기도 했어요.
그리고 저의 지금 회사가 미국에 본사를 두고 있지만 개발팀은 대부분 한국에 있어요. 저희 프론트엔드 팀도 다 한국에 계신 한국인이고요. 이 팀이 세팅된 지 반년쯤 됐고, 시간대와 언어가 맞으니까 상당히 효율적으로 운영되고 있어요. 그런데 최근에 대표님이 미국 본사 쪽으로 취직을 원하는 어떤 미국인의 이력서를 한번 검토해달라고 보내주셨어요. 제가 그거 보고 갑자기 여러 가지 고민이 들더라고요.
분명히 다양성은 도움이 되고, 언젠가는 우리 회사도 더 글로벌하게 가야 할 텐데, 하지만 지금 당장은 이 사람을 받아들임으로써 득보다 실이 더 클 것 같다. 시간대와 언어가 다 다르니까 생산성이 많이 떨어질 것이다. 이런 생각이 들어서, 굉장히 특출난 사람이 아니라면 채용에 반대한다는 얘기를 일단 했고요. 그러면서 제가 너무 편협하게 생각하는 게 아닌가 하는 우려는 된다는 얘기도 했어요.
'우리가 언젠가는 규모를 키우려면 이런 외부의 새로운 풀도 받아들이고, 또 외국인도 받아들여야 할 텐데 그걸 못하는 게 아닌가? 근데 이 적절한 타이밍이 언제인지 모르겠다. 우리는 언제나 단기적인 효율성을 추구하게 될 텐데 그러면 언제 이걸 확대해야 하는가?' 그랬더니 대표님도 기본적으로 리더의 의견을 존중하지만 자기도 사실 그 답을 못 내리겠다고 하시더라고요. 이게 요즘 제게 중요한 한 가지 화두였습니다.
계홍 이야기하다 보니, 개발과 다양성을 이야기할 때 개발 관련된 백그라운드를 이야기 안 하고 갑자기 이야기하려니 좀 어렵다는 생각이 드네요. 그런 면에서 보면 IT 쪽은 기술의 변화 속도가 굉장히 빠르다고 이야기 많이 하잖아요. 그런 것들이 정말 많이 있거든요. 그래서 개발자도 계속하려고 하면 적절한 타이밍에 자기 기술을 바꿔야 해요.
아까 휘동님이 이야기한 건 조직 관점인데, 개인의 IT 개발자 관점에서도 비슷한 이슈가 '내가 갖고 있는 기술을 언제 다른 걸로 바꿔야 하지?' 이런 게 있어요. 저도 지금은 자바(Java)로 백엔드 웹 개발을 하고 있지만, 이전에는 프론트엔드를 한 적도 있고, 웹이 아니라 윈도우즈 프로그램을 개발한 적도 있어요. 그런데 많은 개발자가 자의적으로 전직을 하기도 하지만, 기술의 변화에 적응 못 해서 전직을 하는 경우도 많아요. 저도 다른 기술을 배우다가 실패도 많이 해봤고요.
뭐든 변화에 적응하기가 쉽지는 않잖아요. 적절한 타이밍에 잘 넘어가기가 어려워요. 변화에 적응하지 않아도 한동안은 문제없거든요. 그렇지만 언젠가는 한계가 오고 말죠. 그래서 흔히 그런 이야기들도 있어요. 예를 들면 웹 개발을 크게 두 부분으로 나눌 수 있어요. 휘동님은 프론트엔드 개발자라고 해서, UI(User Interface)라고 하는 사람들의 눈에 보이고, 직접 조작하는 부분을 주로 개발해요. 저는 백엔드 개발자인데, 사용자가 버튼을 누르면 그 결과를 만들어 주는 기능을 개발합니다. 그런데 이 기술들의 중요성이 왔다 갔다 해요. 어떨 때는 프론트엔드 기술이 중요해지고, 그래서 발전하게 되고, 또 어떨 때는 백엔드 기술이 중요해지면서 발전하기도 합니다. 그래서 최근에는 양쪽 다 중요하다고 생각해요.
개발자가 이런 기술을 바꿔 가고 계속 업그레이드를 해야 하는데, 실제로는 기술 하나만 바꾸는 것처럼 보이지만 이게 기술 하나가 아니라, 기술을 바꾸면 도구도 바꿔야 해요. 그리고 프로젝트 할 때는 매우 많은 도구를 사용하니까, 정말 많은 도구를 새로 배워야 해요. 기술도 마찬가지고요. 큰 기술은 많은 작은 기술들을 포함하고 있거든요. 그래서 개발자들이 이걸 잘 활용할 수 있는 수준까지 가는 것이 힘든 거죠.
그래서 개발자들은 '지금 내가 이 기술로 먹고 살 수는 있는데, 앞으로 5년 후, 10년 후에도 혹은 내년에도 이 기술로 먹고 살 수 있어?'라고 끊임없이 자문하게 돼요. 그러면서 불안해하고, 그러면서 공부하려고 노력하게 만들죠. 그래서 개발자들이 끊임없이 새로운 기술에 대해서 귀를 열어놓고 있는 것이죠.
헬렌 많은 기술이 급변하는 상황에서 새로운 기술들이 필요하고 그래서 그 변화에 적응할 수 있어야 하고 그래서 개발자들도 자기 기술과 도구를 다양화해야 한다는 얘기로 정리하면 될까요.
계홍 맞아요. 그래서 기술과 도구의 다양성이 개발자에게 기본적으로 중요하다고 이야기하고 싶었습니다.
보라 방금 계홍님 말씀하신 게 미래 사회에서 요구되는 역량이라고 많이 이야기하는 것들입니다. 앞으로의 사회 문제가 점점 더 복잡해진다고 얘기하거든요. 그런데 복잡한 문제를 해결하기 위해서는 하나의 시선으로는 해결하는 게 어려워요. 그렇기 때문에 다양한 사람과 협력하고 소통하면서 문제를 같이 해결해 나가는 게 중요해질 거라고 하고, 그래서 교육에서도 이것을 어떻게 풀어나갈 것인가 고민이 많아요. 그런 면에서 아까 이야기 나왔던 협력이나 소통과 같은 키워드가 좀 더 중요해지는 것 같고요.
헬렌 혹시 다양성과 관련해서 더 하고 싶은 이야기가 있나요?
휘동 저희는 번역 관련 서비스를 만들다 보니 다국어 지원이 아주 중요합니다. 예전에는 언어 선택 폼에서 언어의 이름만 보여줬었어요. English(United States) 같은 식으로요. 그런데 디자이너분이 새로 오면서, 이 폼이 시인성이 떨어지니까 국기를 넣자는 의견을 주셨고, 다들 와 좋다 해서 그렇게 디자인이 됐어요.
실제로 굉장히 예뻐졌고 시인성도 좋아졌는데, 구현하려고 보니 좀 애매한 거예요. 예를 들어 스페인어는 스페인에서도 쓰이고 미국에서도 쓰이는데 이건 국기를 뭘 넣어야 하는가, 같은 문제가 있었습니다. 그래서 내부에서 토론도 하고 찾아보고 했는데, 결론은 국기 이미지를 다 빼는 게 대세더군요. 그 언어를 쓰는 사람이 특정 국가에 살고 있다는 보장이 없으니 그걸 존중하지 않으면 분명히 이슈가 생긴다는 거죠. 실제로 애플 같은 사이트 보면 언어 선택하는 폼에 국기를 표시하지 않습니다. 그래서 저희도 국기를 빼고, 대신 그 언어를 나타낼 수 있는 문자열을 이용해서 시인성을 높였어요. 영어는 'En'을 쓰고, 한국어는 '한'을 쓰고, 일본어는 'あ'을 쓴 이미지를 사용하는 식입니다.
헬렌 저도 관련해서 에피소드 하나 말씀드릴 수 있는데, 미국 LA에 있는 모바일 게임 개발자분을 한 번 만난 적이 있었어요. 그래서 저는 당연히 영어로 개발할 거로 생각했어요. 왜냐하면 미국에 있는 미국인이 개발해서 미국에 퍼블리시할 게임이니까요. 그런데 스페인어를 우선으로 만든다고 하더군요. 그 이유는 미국 현지에도 지금 멕시코 등지에서 엄청 사람들이 몰리고, 특히 모바일 게임을 하는 타깃 유저 중에서 우버 기사처럼 기다리는 시간이 많은 사람이 많대요. 그런데 이민자들이 우버 기사를 굉장히 많이 하다 보니, 스페인어 사용자들의 모바일 게임 인구가 매우 많다고 하더라고요. 저도 깜짝 놀랐어요.
휘동 다국어 관련 이야기가 하나 더 있습니다. 웹 브라우저 화면을 꾸며주는 언어로써 CSS라는 게 있어요. 여기에 두 요소 사이의 간격을 표시하는 margin이라는 속성이 있거든요. 이 속성이 기본적으로는 위, 아래, 왼쪽, 오른쪽 이렇게 정의하게 되어있어요. 그런데 최근에 블록 시작/끝, 줄 시작/끝이라는 의미의 속성이 추가됐습니다. 이게 왜 중요하냐면, 아랍권에서는 텍스트를 오른쪽에서 왼쪽으로 읽잖아요. 그래서 '왼쪽 margin'으로 구현하면 아랍권에서는 의도와 다르게 표현될 수 있어서 이런 다국어 지원이 어려웠습니다. 대신 '줄 시작 margin'으로 두면 아랍권 언어에서 예외 처리할 필요 없이 처리할 수 있습니다. 이것도 개발 세계에서 다양성을 더 존중하게 되면서도 더 효율적인 코딩을 하게 된 예시라고 봅니다.
다음은 시니어 개발자로서 보는 다양성에 대한 것인데요. 저는 어떤 현상을 다층적으로 해석하는 것도 다양성의 일부라고 생각합니다. 개발에서 아주 중요한 개념이 '추상화'거든요. 저는 시니어 개발자가 될수록 굉장히 구체적인 것부터 점점 더 추상적인, 더 넓은 범위에서 생각할 수 있어야 한다고 보고, 팀원들에게도 요구하고 저도 노력합니다. 예를 들면 버그가 발생해서 오류를 수정해야 할 때 주니어들은 그것 하나만 수정하거든요. 근데 시니어가 될수록 그 버그가 왜 일어났는지 근본 원인을 분석해서 환경을 바꾸고, 앞으로 유사 버그가 더 안 일어나게 하고, 유사 버그가 생겼을 때 더 빨리 우리가 인지하려면 어떻게 해야 하는지 고민하고… 같은 식으로 행동하거든요. 저는 어찌 보면 이것도 다양성을 인지하는 한 측면이 아닌가 싶어서 얘기하고 싶었습니다.
또한 아까 계홍님도 얘기하셨지만 개발이라는 세상이 굉장히 빨리 바뀌거든요. 그래서 한편으로는 자기가 가만히 있어도 다양성을 계속 확보할 수 있는 환경에 있어야 해요. 뉴스레터를 많이 본다거나, 커뮤니티에 속한다거나. 그런데 이렇게 트렌드에 쫓아가는 게 어찌 보면 너무 피곤해요. 모든 걸 다 쫓아갈 수도 없고, 효율적이지도 않고요. 그래서 그런 환경을 갖추면서도 다른 한편으로는 계속 본질에 집중해야 하거든요. 기술 하나하나를 잘 다루는 데 집중하는 게 아니라, 좋은 코드를 짜고 좋은 엔지니어가 되려면 어떻게 해야 하나를 고민하는 거죠. 이게 결국에는, 즉흥연기에서도 재미를 추구하기보다는 그냥 예스앤드 잘하자, 캐릭터 잘 만들자 같이 기본에 충실해야 하는 거랑 비슷한 것 같아요.
말이 너무 길었는데, 마지막으로 다양성이 확보되는 환경 갖추기에 대한 고민이 하나 있어요. 저에게는 임프로그도 그런 다양성을 갖추는 환경인데, 저는 개인 차원에서 다양성을 확보하는 수단으로 인터넷 커뮤니티를 활용했었거든요. 그런데 페이스북 같은 SNS는 결국 나와 비슷한 의견을 가진 사람들이 내 주변에 모이게 되잖아요. 그래서 다양성 확보에서 분산이 부족해지는 면이 있는데, 그렇다고 너무 다양성이 큰 익명 커뮤니티는 나도 모르게 바람직하지 못한 언어에 오염된다거나, 오히려 대중적 편견이 너무 강하다거나 하는 위험이 있는 것 같아 고민되기도 합니다.
계홍 이야기를 듣다 보니 개발자들은 기술 트렌드를 따라가는 것도 중요한데, 협력을 잘하는 것도 중요하다고 생각하거든요. 그런 면에서 개발자들이 다양한 역할을 해 보는 것도 중요하다고 생각해요. 특히 리더 역할을 경험해 보면 좋겠어요. 저는 커뮤니티 활동을 다양하게 했는데, 특히 제가 커뮤니티를 만들어서 했던 경험이 실제 업무를 하는 데도 큰 도움이 되었습니다. 우리가 직장에서 리더나 상사에 대해서 불평불만을 하기는 쉽잖아요. 그리고 직장 생활하자마자 리더 경험을 하기도 쉽지 않고요. 저는 커뮤니티를 만들어서 리딩해 보니, 일의 전체를 보는 관점이 쉽게 생기더라고요. 다른 사람들에 대해서 여러 가지 생각을 하게 되고요. 그게 일을 하는 데도 많은 도움이 되었습니다.
헬렌 마지막으로 다양성이 왜 필요한지, 리고 이야기를 나눈 전후로 생각이 바뀐 점이 있는지 같이 이야기를 나눠보고 싶어요.
저부터 먼저 얘기를 한번 해볼게요. 저는 일단 다양성이 필요한 이유는 생존과 지속 가능성인 것 같아요. 임프라브도 그렇고 IT도 그렇고 모든 곳에서 같은 종만 같은 사람만 있으면 지속 가능하지 않을 것 같아요. 저 같은 사람만 임프로그에 15명 있었으면 6개월도 못 가고 끝났을 것 같고요. 또 임프로그가 다양한 포맷을 하므로 또 오랫동안 할 수 있는 거거든요. 만약에 한 가지 포맷만 계속했다면 임프로그가 살아남지 못했겠죠. 지겨웠을 거고 우리도 재미가 없었을 거고 관객도 재미가 없었을 거고 발전도 없었을 거예요. 다양성이 일차적으로는 도덕적으로 정의로운 측면에서 필요하고 우리가 받아들이고 존중해야 하는 거라 생각해요. 나와 다른 사람들을 받아들이고 존중하는 거 인정하는 거, 일차적으로는 그렇게 생각해요. 이차적으로는 그런 게 일어나지 않으면 어떤 세상이 될까를 상상해 봤어요. 나와 다른 생각을 받아들이지 않고 잘못됐다고 생각해서 종교전쟁이 일어났듯, 폭력이 난무하고 피가 난무하고 결국은 세계 종말이 올 것 같더라고요. 그래서 저는 살아남기 위해서, 더 잘 살기 위해서, 또 지속 가능하게 재미있는 걸 오래 잘하기 위해서 다양성은 꼭 필요한 거로 생각했습니다.
오늘, 이 이야기들을 저는 사실 나누기 전과 나눈 후에 달라진 생각이 아주 크지는 않지만, 그래도 좀 확장되긴 한 것 같아요. 여러분들의 이야기를 들으면서 뭔가 제가 어떤 쪽으로 꽂혀 있던 생각 하나가 좀 더 많이 스펙트럼이 커진 것 같은 기분이 듭니다. 사실 제가 임프라브랑 IT 쪽 외에는 다양성에 대해서 사실 생각을 많이 안 해봤거든요. 근데 좀 그 외에 분야에 대해서도 다양성을 좀 생각하게 된 계기인 것 같아요.
휘동 헬렌이 얘기한 생존과 지속 가능성이란 키워드가 제가 얘기하려고 했던 거랑 정확히 일치해서 깜짝 놀랐어요. 일단 정의롭다는 측면에서, 사실 어떤 가치가 유지되려면 결국 그게 유전자 입장에서 생존에 유리해야 하잖아요. 저는 우리가 다양성이 정의롭다고 생각하는 이유는 다양성이 생존에 유리하기 때문이라고 생각해요. 그래야 그 유전자가 환경에 더 잘 적응해서 오래 살아남을 테니까요. 그래서 생존과 지속 가능성이라는 키워드에 크게 공감합니다.
그리고 저는 개발과 다양성에 대해서는, 생각이 바뀌기보다는 제 생각을 정리하는 계기 정도가 된 것 같습니다. 하지만 임프라브와 다양성 쪽으로는 반성을 많이 하게 됐어요. 임프라브를 단순히 취미로만 여기지 않아도 되겠다, 이걸 훨씬 더 내 삶에 더 접목할 수 있겠다. 그런 기분 좋은 발견을 하고 갑니다.
의제 그냥 다른 사람들이 나의 그대로의 모습을 인정하고 받아줬으면 좋겠어요. 원래 받고 싶은 대로 주라고 하잖아요? 그래서 저도 다른 사람들을 있는 그대로 인정해주고 받아주려고 해요. 그러면 서로서로 잘 지낼 수 있지 않을까요? 그게 저에게는 다양성이고 필요한 이유입니다. 서로 잘 지내는 거요.
다른 분들의 이야기를 들으면서 기존에 생각이 확장되고 풍성해진 느낌입니다. 그리고 개발 분야에서 다양성에 대해 할 얘기가 많지 않을 거라는 편견이 있었는데요. 휘동님의 이야기를 들으면서 아 맞다 그런 부분이 있었다고 하는 지점들이 많았어요. 그리고 다양성이 리드의 자리에 있으면 더 중요하게 다가오겠다고 하는 생각을 했습니다. 휘동님 고마워요!
계홍 저는 다양성이 왜 필요하냐는 질문은 좀 이상한 것 같아요. 다양성이 아까 모든 분이 이야기한 것처럼 다양성은 필요할 수밖에 없잖아요. 생명체들은 생명을 유지할 수 있는 다양한 루트를 많이 갖고 있더라고 하거든요. 그래서 어떤 한 가지가 부족해도 다른 것들로 그걸 대체해서 생존할 수 있도록 시스템이 돼 있다고 해요. 그래서 저는 다양성은 당연히 필요할 수밖에 없다고 생각해요. 우리가 이런 질문을 하는 건 아마 다양성이 왜 필요한지보다는 우리가 다양성이 필수적인데도 불구하고 왜 인지하지 못하는지가 중요한 것 같아요.
다양성은 당연히 필요하지만, 작은 규모로 보면 다양성이 필요 없어 보일 수 있는 것 같아요. 비슷한 사람들끼리 같은 목적을 위해 모였을 때 유리한 것도 있잖아요. 그러다 보니, 우리가 우물 안 개구리처럼 되기도 쉬워서 다양성이 필수적이지 않은 것처럼 생각하는 사람들도 많은 것이 아닌가 싶어요. 그래서 작은 규모에서는 다양성의 필요성을 인지하기 어렵다 보니, 다양성을 신경 쓰지 않고 오히려 다양성에 반대되는 행동을 하게 되기도 하는 것 같아요.
하지만, 작은 규모가 유리한 부분도 있지만 큰 규모가 유리한 부분도 많잖아요. 작은 규모에서 큰 규모로 확대를 해 나가려고 하면 다양성이 갖는 장점들이 큰 힘을 발휘하게 될 테니, 다양성을 더 빨리 받아들이고, 준비할수록 큰 규모에서 원하는 목표에 더 잘 도달할 수 있게 될 것 같습니다.
보라 여러분들 말씀 들으면서 생각이 발전한 부분이 있는데요. 저도 다양성이 왜 필요한지 굳이 설명하라고 하면 사회적인 관점에서는 ‘지속가능성’인 것 같고 제 개인 차원에서는 저는 ‘재미’인 것 같아요. 다양한 사람과 만나고 소통하는 게 재밌고 다양한 활동을 해보고 체험해 보는 걸 좋아하니까, 제 삶을 충만하고 풍요롭게 한다는 면이 있는 것 같아요. 사회에서 왜 다양성이 필요한가 하고 생각하면 아까 헬렌님도 말씀하셨지만 지속가능성인 것 같아요. 계홍님 말씀도 전적으로 동의가 갔어요. 다양성이 왜 필요한가 하면, 세상이 원래 다양하고 사람이 원래 다양한데 우리가 하나의 기준으로 자꾸 사람들을 보려고 하거나 내 기준으로만 보려고 하니까 다양해 보이지 않는 게 아니냐는 생각이 들었어요. 그러므로 왜 필요한지가 아니라 원래 자연스러운 게 그것인데 우리가 인간이 뭔가 손쉽게 사고하기 위해서, 혹은 게으르니까 정보 처리를 빨리하기 위해 다양성을 마음속에서 거부했던 것이 아닌가 하는 생각이 들었습니다.
오늘 이야기하면서 바뀐 또 다른 생각은요. 저는 주로 다양성에 대해 생각할 때는 구성원의 다양성이라는 관점에서 생각을 많이 하는 편이거든요. 제가 교육 분야에 있어서 그런 것도 있어서 그런 것 같아요. 그런데 오늘 도구에 대한 다양성도 얘기가 나왔어요. 여러 가지 도구나 툴을 사용할 줄 알면 때와 필요에 맞게 도구를 활용할 수 있어서 유연하게 일하는 데에 도움이 될 수 있겠다는 생각을 새롭게 한 것 같습니다.
의제 저는 대기업에서 안드로이드 앱 개발을 하고 있습니다. 소셜 커뮤니케이션 앱에서 채팅 서비스 영역을 담당하고 있어요. 그래서 대부분 채팅 관련 기능을 개발해요. 채팅 화면 내에 화상 통화 기능도 있어서, 요즘은 화상 통화와 관련된 기능들을 추가로 개발하고 있습니다. 예를 들면 통화 중에 가상 배경을 넣는 기능 같은 거죠. 앱 개발 이전에는 3년 정도 서버 개발도 했었어요. 서버 개발을 하다가 앱 개발로 넘어간 사례입니다.
휘동 저도 이것저것 했어요. 서버 개발도 했었고 게임 개발도 잠깐 해봤었고요. 몇 년 전부터는 스타트업에서 웹 개발 중에서도 프론트엔드 쪽에 집중하고 있고, 리드 역할을 맡은 지는 2년 반 됐습니다.
계홍 저는 24년 차 프리랜서 웹 개발자이자 애자일 코치입니다. 저는 개발을 좋아해요. 제가 좋아하는 개발을 잘하고 싶고, 그리고 다른 개발자들도 개발을 좋아하고 잘할 수 있도록 돕고 싶어요. 그러다 보니 애자 일에 관심을 갖게 되었습니다.
2009년부터 국내 애자일 커뮤니티
또 플레이 애자일팀(https://playagile.co.kr) 멤버로 활동하고 있습니다. 애자일을 쉽고 재미있게 전달하기 위해 다양한 직군 5명이 모여서 레고4스크럼이라는 과정을 중심으로 다양한 애자일 과정을 만들어 교육하고 있습니다.
보라 제가 개발자가 아니다 보니 갑자기 궁금해졌는데요, 여러분이 생각하기에 개발자들이 갖는 공통점이 있을까요? 예를 들면 개발자 사회 안에서도 "개발자들은 참 유난해, 독특해" 같은 말을 듣는 경우가 있는지 궁금해요.
헬렌 맞아요. 저도 비개발자로서 개발자에 대한 전형적인 편견이 조금 있거든요. 예를 들면 개발자들은 매우 논리적이다, 또는 혼자 일하는 걸 좋아한다. 왜냐하면 혼자 컴퓨터로 맨날 코딩하는 것 같이 보이니까.
의제 개발자 공통점 하면 우스갯소리로 청바지에 체크 남방을 가장 먼저 떠올릴 것 같아요.(웃음) 제가 있는 회사에서 크게 3가지 직군이 나뉘어요. 개발, 기획, 디자인 직군인데요. 다른 직군에 비해서 개발 쪽 분들이 옷을 좀 편하게 입어요. 고객을 만날 일이 없어서 그런가? 아무튼 그렇습니다. 그리고 좀 더 논리적으로 말하거나 보이고 싶어 하는 특징이 있습니다. 대화에 ‘리소스'라는 단어를 많이 쓴다든지요. 예를 들면 ‘이번 이슈는 리소스가 부족해서 어려울 것 같습니다.’ 그리고 이건 대학생 때부터 느꼈던 건데, 뭔가 최단 거리를 찾거나 효율적인 방법을 찾는 걸 좋아했던 기억이 있습니다.
계홍 의제님 얘기에 공감되는데, 개발자들은 공통으로 논리적이고 문제 해결 중심인 것 같아요. 개발자들이 하는 일이 문제를 찾고, 문제를 해결하는 것이다 보니 그럴까요? 이 특징이 일상생활과는 맞지 않는 부분이 있어서 생각이 자주 나네요.
저도 개발자라서 이런 경우가 많아요. 다른 사람의 이야기를 들으면서 자연스럽게 그 속에 있는 문제를 찾고, 그 문제를 해결하기 위한 방법을 생각하고, 이야기하거든요. 그런데 원래 이야기한 사람은 그냥 이야기를 들어주고, 공감받기를 원하는 경우가 많더라고요. 게다가 문제 해결을 위한 솔루션들은 오히려 역효과를 내는 경우가 많고요.
휘동 저는 '개발자의 공통점'에 대해 쉽게 얘기하기가 좀 어렵네요. 『팩트풀니스(Factfulness)』라는 책에서 나온, "집단 간 차이보다는 집단 간 유사성이 더 많고, 집단 내 개체들 사이의 차이가 훨씬 크다, 우리가 집단으로 일반화하는 걸 주의해야 한다"는 말을 좋아하거든요. 저는 거의 스타트업에서만 일을 해봤기 때문에 스타트업이라는 조직 특성 때문에 생기는 편견이 있을 것이고 개발자로서 나오는 편견이 있을 거라서… 아무튼 저와 제 주변을 바라보면서 생각나는 걸 좀 얘기해 보겠습니다.
저는 개발자들이 논리적인 거랑 비슷하게, 구조나 원리를 파악하는 걸 좋아하는 것 같습니다. 디테일에 집착하는 건데요. 어떤 현상이 있을 때 그렇구나, 에서 끝나는 게 아니라, 왜 그렇지? 저걸 내가 직접 만들면 어떻게 할 수 있을까? 아니면 저걸 어떻게 만들었을까? 이런 걸 많이들 궁금해합니다. 특히 웹 개발자들은 브라우저에서 홈페이지를 직접 뜯어볼 수 있으니 뜯어보는 행위도 많이 하는 것 같고요.
또 하나는, 개발자는 여러 도구를 가져다가 조합해서 쓰는 데 익숙합니다. 그런 데서 오는 자유로움이 있어요. 예를 들면 예전에는 인터넷은 무조건 "인터넷 익스플로러"로만 해야 하는, 그러니까 인터넷 익스플로러라는 브라우저가 곧 인터넷인 분들이 있었죠. 저도 어릴 때는 그랬고요. 개발자들은 새로운 도구들을 많이 접하면서, 사실은 브라우저라는 도구가 단일하지 않고 여러 개 중 내가 선택할 수 있구나, 같은 걸 깨달으면서 자유로움이 생깁니다. 그게 성격에도 조금은 반영되지 않나 싶어요. 하나에 정착 잘 못하고 여기저기 옮겨 다니는?
마지막으로, 성장과 학습이라는 키워드에 대한 집착이 있습니다. 카카오톡 상태 메시지나 블로그 대문 같은 데에 성장 얘기 써둔 주니어 개발자 정말 많을 거예요. 저도 아기 키우기 전까지 마찬가지였고요.
헬렌 비개발자인 제가 보기에는 개발 업무에서 요구되는 특성과 임프라브에서 요구되는 특성이 굉장히 달라 보이는데 이 굉장히 다른 특성을 보인 활동을 같이하면 생기는 장점은 뭐고 단점은 뭘까요?
예를 들면 개발자로서 요구되는 특성이 있을 거고 임프로바이저로서 요구되는 특성이 있을 텐데, 개발자이면서 임프라브를 하시는 세 분께 혹시 이런 걸로 인한 장점이 있거나 단점이 있다면 뭐가 있을까요.
계홍 아까 말씀드린 것처럼 개발자는 어떤 컴퓨터 안에서 생겨나는 문제를 해결하는 데 포커스를 두는데, 임프라브는 사람과 커뮤니케이션해야 하잖아요. 그래서 달라 보이는데, 이걸 조금 더 넓게 가면 아까 말씀드린 것처럼 또 비슷한 면이 있어요.
요즘은 프로젝트를 할 때도 컴퓨터만 잘하는 게 아니라 협력이 중요해지면서 고객, 아니면 다른 팀((기획자나 디자이너)과도 대화해야 하는데, 때로는 서로 사고하는 방식이 너무 다르다 보니까 대화하기가 힘들 때가 있어요. 그러면 커뮤니케이션하면서 오해가 일어나요. 기획자가 이야기한 것과 내가 만든 게 다른 일이 반복되면 일하기가 너무 싫어지거든요.
근데 임프라브에서 다양성을 훈련하고, 커뮤니케이션하면서 서로 다르게 생각할 수 있다는 걸 생각하게 되면 대화와 업무에서도 조금 더 여유가 생기는 것 같아요. 그래, 우리 잘못 생각할 수 있지. 이게 심리적 안정감하고도 좀 연결이 되는 것 같은데요. 다른 사람을 이해하지 못하게 되면 '아니 이 쉬운 걸 이해를 못해? 어떻게 저런 말도 안 되는 생각을 하지?' 이런 생각을 하게 되고요. 반면 서로의 다른 점을 인정하고 발견하면서 호기심을 가지면 일하기가 굉장히 편안해지죠.
그래서 임프라브와 개발은 굉장히 다른 면이 있지만, 임프라브에서 커뮤니케이션을 경험하는 게 개발자에게도 매우 도움이 됩니다.
휘동 임프라브를 통한 단점은 솔직히 모르겠고요. 저는 임프라브를 개인적 재미와 희열 쪽으로만 많이 바라봤었어요. 그래서 임프라브를 하는 게 나에게 영향을 주고, 그게 다시 실무에 영향을 주는 간접적인 관계에서는 분명히 장점이 있었다고 생각하는 데 직접적인 관계로서의 장점은 잘 모르겠네요.
그러면 간접적인 부분에서는 어땠냐고 생각을 해보면, 계홍님 얘기하고 좀 비슷합니다. 저는 리더 입장에서 사람들을 채용하고자 할 때 '코딩은 잘하는데 협력이 잘 안되는 사람'과 '협력이 잘 되는데 코딩을 잘 못하는 사람' 중에서는 대부분 후자를 택했던 것 같아요. 왜냐면 코딩을 잘하는데 협력 못하는 사람이 애초에 거의 없어요. 협력은 못 해도 코딩을 잘하는 것처럼 보이는 사람이 실제로는 코딩도 못 하는 사람인 경우가 많았어요.
탁월한 개발자의 아주 중요한 특징 중에 '다른 사람의 효과적 의사결정을 도울 수 있다'는 게 있거든요. 그런데 협력을 못 하면 남을 도울 수가 없기 때문에, '협력을 못 하면서 코딩을 잘한다'는 것 자체가 애초에 모순적인 명제라는 생각이 들어요. 이런 협력적인 측면을 발전시키는 데는, 꼭 일을 위해서가 아니더라도 임프라브가 많은 도움이 된다고 생각합니다. 임프라브의 기본이 예스앤드고, 동료를 포용해 주고 백업해 주는 훈련을 많이 하잖아요. 이런 게 실무에서도 동료를 관찰하고 돕는 자세를 발달시키는 훈련이 된다고 생각합니다.
의제 저도 비슷한 맥락이에요. 컴퓨터 개발이랑 임프라브에 요구되는 역량 자체는 명확히 다르다고 생각해요. 개발에서 중요한 역량은 문제해결이고 임프라브는 커뮤니케이션 혹은 표현하는 쪽이라고 생각합니다. 이렇게 두 개가 너무 상반되지만, 그게 서로 보완이 된다고 봐요. 개발을 혼자 하는 게 아니잖아요. 팀으로 개발하다 보니까 서로 커뮤니케이션하는 부분이 많죠. 그래서 같이 일할 때 임프라브에서 배운 것들이 도움이 돼요.
그리고 인사평가를 잘 받으려면 또 일을 잘하는 척도 해야 하잖아요. (웃음) 그럴 때 연기에서 배운 표현하고 전달하는 법이 많은 도움이 되었어요. 그리고 상대방이 뭘 원하는지 관찰하는 습관도 길러줘서 도움이 됐습니다.
계홍 휘동님 이야기를 듣다 보니까 생각나는 게 있어요. 저는 개발자들이 아무래도 내성적인 분들이 많이 있는 편이라고 생각해요. 혼자 일해도 자신의 가치와 능력을 보여줄 수 있거든요. 그런 특성 때문에 개발 팀장과 같은 리더급이 되면 협력과 커뮤니케이션의 중요성이 갑자기 더 올라가는 느낌이 있어요. 그러다 보니 같이 연결되는 게 의지력이나 회복력 같은 부분도 있다고 생각해요. 일도 일이지만 사람들을 만나서 대화하는 것 자체만으로도 스트레스를 받고 힘든 거죠. 이런 스트레스는 직급을 막론하고, 그리고 어떤 일을 하든지 항상 있는 일이기는 하죠.
임프라브 자체가 코미디라 많이 웃을 수 있기도 하고요. 또 다양한 역할, 다양한 연기를 하면서 감정 표현도 많이 하게 되는데, 그러면서 스트레스가 확 풀리는 느낌들이 좀 있거든요. 임프라브의 이런 특성들은 다른 일상생활을 할 때도 큰 도움이 되는 것 같아요. 새롭게 일을 시작할 수 있도록 몸과 마음을 회복해 주는 것 같습니다.
헬렌 네, 제가 임프라브를 오랫동안 가르치면서 개발자인 분들 그리고 또 개발자가 아닌 분들한테 질문을 한 적이 있었어요. 임프라브가 실제로 도움이 되느냐, 실제로 회사에서 현실적으로 쓰냐, 라고 여쭤봤는데요. 개발을 오래 하시다가 리더 역할을 하시는 분께서 "관리자로서 팀을 이끌다 보면 중재 역할을 굉장히 많이 하게 되는데 중재 역할을 할 때 다른 가면을 써야 할 때가 많다. 그럴 때 임프라브가 매우 큰 도움이 되었다."라고 얘기해 주시더라고요.
업무 외적으로도 예스앤드 화법을 쓰면서 부부 사이가 좋아졌다거나 사춘기 자녀분들하고 관계가 굉장히 좋아졌다는 얘기를 들었네요. 또 어린아이를 기르는 분들은 아이와의 스토리텔링 11) 이나, '뭐하고 있어?' 12) 같은 게임을 하면서 아이랑 재미있게 잘 놀아주게 되었다거나 이런 일반적인 내용으로 얘기를 많이 들은 것 같아요.
계홍 또 하나 생각나는 게 있어요. 일을 할 때 팀워크나 협력은 정말 중요한데 잘 안되는 경우도 많잖아요. 가만 보면 회사에서 일할 때는 협력한다는 게 뭔지도 잘 모르는 분들도 있어요. 저는 '협력도 해 본 사람이 잘한다'고 생각해요. 협력하면서 함께 공동의 목표를 이루는 경험이 있는 다른 협력을 할 때도 도움이 된다고 봐요.
저는 그 느낌을 임프라브에서 경험하기 쉽다고 생각해요. 임프라브 할 때, 예스앤드의 마법이랄까 정말 생각지도 못했던 방향으로 뭔가 착착 스토리가 진행되면 깜짝 놀라거든요. 완전 창의적이고 너무 멋진 극이 만들어질 때가 있어요. 저는 이런 경험이 일을 할 때도 도움이 된다고 생각해요. 일을 할 때도 어떤 일이든 어려움은 있잖아요. 길이 안 보이기도 하고요. 그걸 해결하기 위해서 함께 일을 할 줄 아는 사람들이 있어요. 그런 분들의 작은 행동 하나하나가 다른 사람을 이끄는 리더십이 되고, 그런 것들이 쌓여서 좋은 결과를 만들어 내게 되거든요. 정말 일하는 분위기부터 다르기는 해요. 저는 이런 경험? 분위기? 리더십? 같은 것을 임프라브에서 경험하기 좋다고 생각해요.
헬렌 그렇다면, 임프라브가 개발자로서 일할 때 새로운 관점을 갖는 데 도움이 되었나요? 신선한 관점, 예를 들면 버그가 발생했는데 해결이 잘 안되다가, 임프라브를 통해서 해결된 사례가 있으신가요?
휘동 사례는 아니고 좀 반성이 되는데요. 아까도 얘기했지만, 너무 개인적인 관점에서만 임프라브를 바라보지 않았었나 싶어요. 제가 임프라브를 더 잘하기 위해 고민했던 게 있고 개발자로서, 특히 팀 리드로서 고민했던 게 있는데 좀 더 의식적으로 노력했다면 이 둘이 잘 맞닿을 수도 있었겠네요.
의제 업무에 직접적인 도움보다는 간접적인 방향으로 도움이 돼요. 상대방의 피드백을 좀 더 열린 마음으로 받아들이면서 성장할 기회가 됩니다. 업무 중에 코드 리뷰라는 게 있어요. 동료 간에 서로 작업한 내용을 보고 코멘트를 달아주는 건데요. 그 과정에서 가능하면 동료가 준 코멘트를 반영하려고 해요. 혹은 새로운 기술을 한번 적용해 보자는 제안을 줬을 때, 가능하면 받아주려고 하고요. 그 과정에서 실력이 많이 성장한 것 같아요. 그리고 이렇게 수용하는 자세가 함께 일하는 팀 분위기를 좋게 만들어 주니까 좋은 것 같습니다.
계홍 저는 이게 임프라브 때문인지는 잘 모르겠는데, 임프라브를 하기 전에 대화할 때는 정보를 제공하려고 많이 했던 것 같아요. 어떤 일을 문제 해결 중심으로 본다는 것도 같은 맥락이고요. 대화할 때 어떤 정보가 오고 가지 않으면 흥미도 떨어지고, 대화하기 어려운 것을 느껴요. 예를 들면 논쟁 같은 것, 어떤 주제를 가지고 이야기하면 편안하게 할 수 있는데, 주제가 주어지지 않으면 대화하기 어려웠어요. 그래서 불평불만 같은 것도 좋아하는 편은 아니에요. 공감도 잘 안 가고요.
임프라브에서 토론하는 연기를 하지는 않잖아요. 일상생활과 관련된 연기를 많이 하고요. 그러면서 저는 좀 더 사람에 대해서 관심을 두게 된 것 같아요. 그리고 공감도 좀 더 하게 된 것 같고요.
어쨌든 저는, 제가 그런 사람인지 몰랐는데, 생각보다 사람에 관심이 좀 없더라고요. 저는 다른 사람들을 좋아한다고 생각하고, 도움이 필요하다면 언제든지 도와주고 싶은 마음도 많거든요. 그런데 사람 자체에 대해서 호기심이 생기지는 않더라고요. 이런 부분을 알고 나니, 조금 더 사람에 관심을 두게 되고, 임프라브도 더 흥미롭게 보이는 것 같아요. 이런 생각은 임프라브만은 아니고 제가 받는 상담도 많은 도움이 되었어요.
보라 듣다 보니까 저희 대화 내용이 지금 대학에 다니고 있는 학생 또는 청년들에게 도움이 많이 될 것 같아요. 이것도 편견일 수 있겠습니다만 (웃음), 제가 현업에서 일하고 있는 친구들한테 듣거나 또는 매체에서 이야기하는 걸 보면, 요즘의 청년들은 자기 일을 굉장히 열심히 하지만 내 일만 잘하면 된다는 마인드로 임하시는 분들이 간혹 있다는 얘기를 들어요. 그런데, 아까 세 분 다 협력이라는 관점에서 임프라브가 도움이 되는 것 같다고 말씀하셨어요. 그리고 실제로도 개발 업무를 할 때 그게 굉장히 중요한 요소라고 말한 것들이 앞으로 사회에 진출하고 사회에 적응해 나가려는 사람들한테 영감이 될 만한 말이지 않을까 하고 생각을 해요.
헬렌 개발하거나 또는 회사 생활을 하면서 다양성과 관련된 어떤 상황이 있으셨는지 궁금해요. 그런 이야기가 앞으로 사회진출을 앞둔 분들한테 혹시 도움이 될 수도 있을 것 같아서요.
휘동 팀 구성이나 채용 측면에서 다양성과 관련된 사례가 많았습니다. 특히 초기 스타트업에서는 지인 위주로 채용을 많이 하거든요. 근데 지인의 풀이 결국 지인의 지인까지 포함해도 한정적이에요. 그래서 채용을 넓히려면 어쩔 수 없이 새로운 세계로 나가야 합니다. 어떤 형태로든 새로운 사람을 팀에 데려오면, 그분의 지인으로 채용 풀이 넓어지는 효과도 있지만 예상치 못했던 낯섦으로 인한 효과도 많이 보게 됩니다.
간단한 예로, 사실 개발자 중에서는 여성 비중이 엄청나게 적은 편이거든요. 그래서 그런지 몰라도 여성 개발자가 처음으로 팀에 오셨을 때 느껴지는 변화가 분명히 있었습니다. 우선 문서 가독성이 갑자기 좋아지더라고요. 이보다 중요한 건, 우리가 저도 모르게 평소에 사용하는 약어나 단어에서 좀 더 조심스러워지는 면이 있습니다. 누가 그렇게 하자고 명시적으로 말한 건 아니지만, 그룹 마인드처럼 다들 언행을 더 조심하게 되는, 그러니까 조직 자체가 더 성숙해지는 느낌이 있었어요.
계홍 아까 휘동님이 개발 분야에서는 도구나 기술들을 많이 조합해서 갖다가 쓴다고 해주셨잖아요. 이런 좋은 도구나 기술을 찾고, 빨리 배우는 것이 중요한데, 기존에 잘 사용하던 것을 바꾸기는 항상 어렵잖아요. 개발자들에게도 마찬가지예요. 바꾸라고 하는데, 정말 바꾸기 싫을 때도 있고, 바꾸고 싶은데 절대 안 된다고 하기도 합니다.
개발자 중에는 새로운 것 자체를 좋아하는 분들도 많은 편이지만, 아닌 분들도 많죠. 저는 그럴 때 바로 옆에 있는 사람들이 영향을 많이 주는 것 같아요. 옆에서 새로운 기술과 도구를 멋지게 사용하고 있으면 그게 동기부여도 되고, 학습 속도도 엄청 빠르게 해 줍니다. 저는 그래서 프로젝트를 하면서 새로운 도구나 기술을 사용하고, 그리고 주변에 알려주는 것을 좋아해요.
개발자가 다양한 동료, 다양한 프로젝트, 다양한 회사를 경험하는 것은 이런 측면에서도 중요하다고 생각해요. 이런 다양한 경험이 빠른 IT 기술의 변화를 따라갈 수 있게 하는 거죠.
저는 프리랜서 개발자잖아요. 어떤 프리랜서 개발자분이 프리랜서의 매력이 자기가 원하는 프로젝트를 선택할 수 있다는 점이라고 하더라고요. 자기가 원하는 프로젝트를 선택해서 새로운 도구와 기술을 만나면서 빠르게 적응해 나갈 수 있게 되는 거죠.
휘동 다시 채용 얘기인데요. 제가 지난 직장에서 채용 프로젝트를 다양한 사람들하고 진행해 보면서 기술적 역량이 엄청나게 향상됐었거든요. 한 회사에 특히 오래 있다 보면 계홍님 말씀처럼 쓰는 기술만 쓰게 돼요. 하지만 그 기술이 굉장히 빠르게 노후화됩니다. 도구 자체는 트렌디해도 버전 업데이트 한참 동안 못 하는 일 많거든요. 근데 신규 프로젝트는, 특히 채용 프로젝트는 사람들이 자기가 해보고 싶었던 욕망을 최대한 거기 분출합니다. 새로운 기술을 마구 가져다 써요. 저는 엔지니어를 평가할 때 '자기가 어떤 기술을 왜 쓰는지 장단점을 다 알고 선택할 수 있는가?' 를 중요하게 보기 때문에, 새 기술 가져오시면 그걸 다른 후보 대신 왜 선택했는지 항상 물어봅니다. 그렇게 대화하다 보면 이게 생각보다 안정적인 기술이네, 생각보다 좋게 이런 걸 저도 많이 배웁니다. 그래서 채용 프로젝트가 저에게 더 많은 다양성을 가져다주고, 컴포트 존(comfort zone)을 벗어나게 해주고, 성장시켜 주는 도구이기도 했어요.
그리고 저의 지금 회사가 미국에 본사를 두고 있지만 개발팀은 대부분 한국에 있어요. 저희 프론트엔드 팀도 다 한국에 계신 한국인이고요. 이 팀이 세팅된 지 반년쯤 됐고, 시간대와 언어가 맞으니까 상당히 효율적으로 운영되고 있어요. 그런데 최근에 대표님이 미국 본사 쪽으로 취직을 원하는 어떤 미국인의 이력서를 한번 검토해달라고 보내주셨어요. 제가 그거 보고 갑자기 여러 가지 고민이 들더라고요.
분명히 다양성은 도움이 되고, 언젠가는 우리 회사도 더 글로벌하게 가야 할 텐데, 하지만 지금 당장은 이 사람을 받아들임으로써 득보다 실이 더 클 것 같다. 시간대와 언어가 다 다르니까 생산성이 많이 떨어질 것이다. 이런 생각이 들어서, 굉장히 특출난 사람이 아니라면 채용에 반대한다는 얘기를 일단 했고요. 그러면서 제가 너무 편협하게 생각하는 게 아닌가 하는 우려는 된다는 얘기도 했어요.
'우리가 언젠가는 규모를 키우려면 이런 외부의 새로운 풀도 받아들이고, 또 외국인도 받아들여야 할 텐데 그걸 못하는 게 아닌가? 근데 이 적절한 타이밍이 언제인지 모르겠다. 우리는 언제나 단기적인 효율성을 추구하게 될 텐데 그러면 언제 이걸 확대해야 하는가?' 그랬더니 대표님도 기본적으로 리더의 의견을 존중하지만 자기도 사실 그 답을 못 내리겠다고 하시더라고요. 이게 요즘 제게 중요한 한 가지 화두였습니다.
계홍 이야기하다 보니, 개발과 다양성을 이야기할 때 개발 관련된 백그라운드를 이야기 안 하고 갑자기 이야기하려니 좀 어렵다는 생각이 드네요. 그런 면에서 보면 IT 쪽은 기술의 변화 속도가 굉장히 빠르다고 이야기 많이 하잖아요. 그런 것들이 정말 많이 있거든요. 그래서 개발자도 계속하려고 하면 적절한 타이밍에 자기 기술을 바꿔야 해요.
아까 휘동님이 이야기한 건 조직 관점인데, 개인의 IT 개발자 관점에서도 비슷한 이슈가 '내가 갖고 있는 기술을 언제 다른 걸로 바꿔야 하지?' 이런 게 있어요. 저도 지금은 자바(Java)로 백엔드 웹 개발을 하고 있지만, 이전에는 프론트엔드를 한 적도 있고, 웹이 아니라 윈도우즈 프로그램을 개발한 적도 있어요. 그런데 많은 개발자가 자의적으로 전직을 하기도 하지만, 기술의 변화에 적응 못 해서 전직을 하는 경우도 많아요. 저도 다른 기술을 배우다가 실패도 많이 해봤고요.
뭐든 변화에 적응하기가 쉽지는 않잖아요. 적절한 타이밍에 잘 넘어가기가 어려워요. 변화에 적응하지 않아도 한동안은 문제없거든요. 그렇지만 언젠가는 한계가 오고 말죠. 그래서 흔히 그런 이야기들도 있어요. 예를 들면 웹 개발을 크게 두 부분으로 나눌 수 있어요. 휘동님은 프론트엔드 개발자라고 해서, UI(User Interface)라고 하는 사람들의 눈에 보이고, 직접 조작하는 부분을 주로 개발해요. 저는 백엔드 개발자인데, 사용자가 버튼을 누르면 그 결과를 만들어 주는 기능을 개발합니다. 그런데 이 기술들의 중요성이 왔다 갔다 해요. 어떨 때는 프론트엔드 기술이 중요해지고, 그래서 발전하게 되고, 또 어떨 때는 백엔드 기술이 중요해지면서 발전하기도 합니다. 그래서 최근에는 양쪽 다 중요하다고 생각해요.
개발자가 이런 기술을 바꿔 가고 계속 업그레이드를 해야 하는데, 실제로는 기술 하나만 바꾸는 것처럼 보이지만 이게 기술 하나가 아니라, 기술을 바꾸면 도구도 바꿔야 해요. 그리고 프로젝트 할 때는 매우 많은 도구를 사용하니까, 정말 많은 도구를 새로 배워야 해요. 기술도 마찬가지고요. 큰 기술은 많은 작은 기술들을 포함하고 있거든요. 그래서 개발자들이 이걸 잘 활용할 수 있는 수준까지 가는 것이 힘든 거죠.
그래서 개발자들은 '지금 내가 이 기술로 먹고 살 수는 있는데, 앞으로 5년 후, 10년 후에도 혹은 내년에도 이 기술로 먹고 살 수 있어?'라고 끊임없이 자문하게 돼요. 그러면서 불안해하고, 그러면서 공부하려고 노력하게 만들죠. 그래서 개발자들이 끊임없이 새로운 기술에 대해서 귀를 열어놓고 있는 것이죠.
헬렌 많은 기술이 급변하는 상황에서 새로운 기술들이 필요하고 그래서 그 변화에 적응할 수 있어야 하고 그래서 개발자들도 자기 기술과 도구를 다양화해야 한다는 얘기로 정리하면 될까요.
계홍 맞아요. 그래서 기술과 도구의 다양성이 개발자에게 기본적으로 중요하다고 이야기하고 싶었습니다.
보라 방금 계홍님 말씀하신 게 미래 사회에서 요구되는 역량이라고 많이 이야기하는 것들입니다. 앞으로의 사회 문제가 점점 더 복잡해진다고 얘기하거든요. 그런데 복잡한 문제를 해결하기 위해서는 하나의 시선으로는 해결하는 게 어려워요. 그렇기 때문에 다양한 사람과 협력하고 소통하면서 문제를 같이 해결해 나가는 게 중요해질 거라고 하고, 그래서 교육에서도 이것을 어떻게 풀어나갈 것인가 고민이 많아요. 그런 면에서 아까 이야기 나왔던 협력이나 소통과 같은 키워드가 좀 더 중요해지는 것 같고요.
헬렌 혹시 다양성과 관련해서 더 하고 싶은 이야기가 있나요?
휘동 저희는 번역 관련 서비스를 만들다 보니 다국어 지원이 아주 중요합니다. 예전에는 언어 선택 폼에서 언어의 이름만 보여줬었어요. English(United States) 같은 식으로요. 그런데 디자이너분이 새로 오면서, 이 폼이 시인성이 떨어지니까 국기를 넣자는 의견을 주셨고, 다들 와 좋다 해서 그렇게 디자인이 됐어요.
실제로 굉장히 예뻐졌고 시인성도 좋아졌는데, 구현하려고 보니 좀 애매한 거예요. 예를 들어 스페인어는 스페인에서도 쓰이고 미국에서도 쓰이는데 이건 국기를 뭘 넣어야 하는가, 같은 문제가 있었습니다. 그래서 내부에서 토론도 하고 찾아보고 했는데, 결론은 국기 이미지를 다 빼는 게 대세더군요. 그 언어를 쓰는 사람이 특정 국가에 살고 있다는 보장이 없으니 그걸 존중하지 않으면 분명히 이슈가 생긴다는 거죠. 실제로 애플 같은 사이트 보면 언어 선택하는 폼에 국기를 표시하지 않습니다. 그래서 저희도 국기를 빼고, 대신 그 언어를 나타낼 수 있는 문자열을 이용해서 시인성을 높였어요. 영어는 'En'을 쓰고, 한국어는 '한'을 쓰고, 일본어는 'あ'을 쓴 이미지를 사용하는 식입니다.
헬렌 저도 관련해서 에피소드 하나 말씀드릴 수 있는데, 미국 LA에 있는 모바일 게임 개발자분을 한 번 만난 적이 있었어요. 그래서 저는 당연히 영어로 개발할 거로 생각했어요. 왜냐하면 미국에 있는 미국인이 개발해서 미국에 퍼블리시할 게임이니까요. 그런데 스페인어를 우선으로 만든다고 하더군요. 그 이유는 미국 현지에도 지금 멕시코 등지에서 엄청 사람들이 몰리고, 특히 모바일 게임을 하는 타깃 유저 중에서 우버 기사처럼 기다리는 시간이 많은 사람이 많대요. 그런데 이민자들이 우버 기사를 굉장히 많이 하다 보니, 스페인어 사용자들의 모바일 게임 인구가 매우 많다고 하더라고요. 저도 깜짝 놀랐어요.
휘동 다국어 관련 이야기가 하나 더 있습니다. 웹 브라우저 화면을 꾸며주는 언어로써 CSS라는 게 있어요. 여기에 두 요소 사이의 간격을 표시하는 margin이라는 속성이 있거든요. 이 속성이 기본적으로는 위, 아래, 왼쪽, 오른쪽 이렇게 정의하게 되어있어요. 그런데 최근에 블록 시작/끝, 줄 시작/끝이라는 의미의 속성이 추가됐습니다. 이게 왜 중요하냐면, 아랍권에서는 텍스트를 오른쪽에서 왼쪽으로 읽잖아요. 그래서 '왼쪽 margin'으로 구현하면 아랍권에서는 의도와 다르게 표현될 수 있어서 이런 다국어 지원이 어려웠습니다. 대신 '줄 시작 margin'으로 두면 아랍권 언어에서 예외 처리할 필요 없이 처리할 수 있습니다. 이것도 개발 세계에서 다양성을 더 존중하게 되면서도 더 효율적인 코딩을 하게 된 예시라고 봅니다.
다음은 시니어 개발자로서 보는 다양성에 대한 것인데요. 저는 어떤 현상을 다층적으로 해석하는 것도 다양성의 일부라고 생각합니다. 개발에서 아주 중요한 개념이 '추상화'거든요. 저는 시니어 개발자가 될수록 굉장히 구체적인 것부터 점점 더 추상적인, 더 넓은 범위에서 생각할 수 있어야 한다고 보고, 팀원들에게도 요구하고 저도 노력합니다. 예를 들면 버그가 발생해서 오류를 수정해야 할 때 주니어들은 그것 하나만 수정하거든요. 근데 시니어가 될수록 그 버그가 왜 일어났는지 근본 원인을 분석해서 환경을 바꾸고, 앞으로 유사 버그가 더 안 일어나게 하고, 유사 버그가 생겼을 때 더 빨리 우리가 인지하려면 어떻게 해야 하는지 고민하고… 같은 식으로 행동하거든요. 저는 어찌 보면 이것도 다양성을 인지하는 한 측면이 아닌가 싶어서 얘기하고 싶었습니다.
또한 아까 계홍님도 얘기하셨지만 개발이라는 세상이 굉장히 빨리 바뀌거든요. 그래서 한편으로는 자기가 가만히 있어도 다양성을 계속 확보할 수 있는 환경에 있어야 해요. 뉴스레터를 많이 본다거나, 커뮤니티에 속한다거나. 그런데 이렇게 트렌드에 쫓아가는 게 어찌 보면 너무 피곤해요. 모든 걸 다 쫓아갈 수도 없고, 효율적이지도 않고요. 그래서 그런 환경을 갖추면서도 다른 한편으로는 계속 본질에 집중해야 하거든요. 기술 하나하나를 잘 다루는 데 집중하는 게 아니라, 좋은 코드를 짜고 좋은 엔지니어가 되려면 어떻게 해야 하나를 고민하는 거죠. 이게 결국에는, 즉흥연기에서도 재미를 추구하기보다는 그냥 예스앤드 잘하자, 캐릭터 잘 만들자 같이 기본에 충실해야 하는 거랑 비슷한 것 같아요.
말이 너무 길었는데, 마지막으로 다양성이 확보되는 환경 갖추기에 대한 고민이 하나 있어요. 저에게는 임프로그도 그런 다양성을 갖추는 환경인데, 저는 개인 차원에서 다양성을 확보하는 수단으로 인터넷 커뮤니티를 활용했었거든요. 그런데 페이스북 같은 SNS는 결국 나와 비슷한 의견을 가진 사람들이 내 주변에 모이게 되잖아요. 그래서 다양성 확보에서 분산이 부족해지는 면이 있는데, 그렇다고 너무 다양성이 큰 익명 커뮤니티는 나도 모르게 바람직하지 못한 언어에 오염된다거나, 오히려 대중적 편견이 너무 강하다거나 하는 위험이 있는 것 같아 고민되기도 합니다.
계홍 이야기를 듣다 보니 개발자들은 기술 트렌드를 따라가는 것도 중요한데, 협력을 잘하는 것도 중요하다고 생각하거든요. 그런 면에서 개발자들이 다양한 역할을 해 보는 것도 중요하다고 생각해요. 특히 리더 역할을 경험해 보면 좋겠어요. 저는 커뮤니티 활동을 다양하게 했는데, 특히 제가 커뮤니티를 만들어서 했던 경험이 실제 업무를 하는 데도 큰 도움이 되었습니다. 우리가 직장에서 리더나 상사에 대해서 불평불만을 하기는 쉽잖아요. 그리고 직장 생활하자마자 리더 경험을 하기도 쉽지 않고요. 저는 커뮤니티를 만들어서 리딩해 보니, 일의 전체를 보는 관점이 쉽게 생기더라고요. 다른 사람들에 대해서 여러 가지 생각을 하게 되고요. 그게 일을 하는 데도 많은 도움이 되었습니다.
헬렌 마지막으로 다양성이 왜 필요한지, 리고 이야기를 나눈 전후로 생각이 바뀐 점이 있는지 같이 이야기를 나눠보고 싶어요.
저부터 먼저 얘기를 한번 해볼게요. 저는 일단 다양성이 필요한 이유는 생존과 지속 가능성인 것 같아요. 임프라브도 그렇고 IT도 그렇고 모든 곳에서 같은 종만 같은 사람만 있으면 지속 가능하지 않을 것 같아요. 저 같은 사람만 임프로그에 15명 있었으면 6개월도 못 가고 끝났을 것 같고요. 또 임프로그가 다양한 포맷을 하므로 또 오랫동안 할 수 있는 거거든요. 만약에 한 가지 포맷만 계속했다면 임프로그가 살아남지 못했겠죠. 지겨웠을 거고 우리도 재미가 없었을 거고 관객도 재미가 없었을 거고 발전도 없었을 거예요. 다양성이 일차적으로는 도덕적으로 정의로운 측면에서 필요하고 우리가 받아들이고 존중해야 하는 거라 생각해요. 나와 다른 사람들을 받아들이고 존중하는 거 인정하는 거, 일차적으로는 그렇게 생각해요. 이차적으로는 그런 게 일어나지 않으면 어떤 세상이 될까를 상상해 봤어요. 나와 다른 생각을 받아들이지 않고 잘못됐다고 생각해서 종교전쟁이 일어났듯, 폭력이 난무하고 피가 난무하고 결국은 세계 종말이 올 것 같더라고요. 그래서 저는 살아남기 위해서, 더 잘 살기 위해서, 또 지속 가능하게 재미있는 걸 오래 잘하기 위해서 다양성은 꼭 필요한 거로 생각했습니다.
오늘, 이 이야기들을 저는 사실 나누기 전과 나눈 후에 달라진 생각이 아주 크지는 않지만, 그래도 좀 확장되긴 한 것 같아요. 여러분들의 이야기를 들으면서 뭔가 제가 어떤 쪽으로 꽂혀 있던 생각 하나가 좀 더 많이 스펙트럼이 커진 것 같은 기분이 듭니다. 사실 제가 임프라브랑 IT 쪽 외에는 다양성에 대해서 사실 생각을 많이 안 해봤거든요. 근데 좀 그 외에 분야에 대해서도 다양성을 좀 생각하게 된 계기인 것 같아요.
휘동 헬렌이 얘기한 생존과 지속 가능성이란 키워드가 제가 얘기하려고 했던 거랑 정확히 일치해서 깜짝 놀랐어요. 일단 정의롭다는 측면에서, 사실 어떤 가치가 유지되려면 결국 그게 유전자 입장에서 생존에 유리해야 하잖아요. 저는 우리가 다양성이 정의롭다고 생각하는 이유는 다양성이 생존에 유리하기 때문이라고 생각해요. 그래야 그 유전자가 환경에 더 잘 적응해서 오래 살아남을 테니까요. 그래서 생존과 지속 가능성이라는 키워드에 크게 공감합니다.
그리고 저는 개발과 다양성에 대해서는, 생각이 바뀌기보다는 제 생각을 정리하는 계기 정도가 된 것 같습니다. 하지만 임프라브와 다양성 쪽으로는 반성을 많이 하게 됐어요. 임프라브를 단순히 취미로만 여기지 않아도 되겠다, 이걸 훨씬 더 내 삶에 더 접목할 수 있겠다. 그런 기분 좋은 발견을 하고 갑니다.
의제 그냥 다른 사람들이 나의 그대로의 모습을 인정하고 받아줬으면 좋겠어요. 원래 받고 싶은 대로 주라고 하잖아요? 그래서 저도 다른 사람들을 있는 그대로 인정해주고 받아주려고 해요. 그러면 서로서로 잘 지낼 수 있지 않을까요? 그게 저에게는 다양성이고 필요한 이유입니다. 서로 잘 지내는 거요.
다른 분들의 이야기를 들으면서 기존에 생각이 확장되고 풍성해진 느낌입니다. 그리고 개발 분야에서 다양성에 대해 할 얘기가 많지 않을 거라는 편견이 있었는데요. 휘동님의 이야기를 들으면서 아 맞다 그런 부분이 있었다고 하는 지점들이 많았어요. 그리고 다양성이 리드의 자리에 있으면 더 중요하게 다가오겠다고 하는 생각을 했습니다. 휘동님 고마워요!
계홍 저는 다양성이 왜 필요하냐는 질문은 좀 이상한 것 같아요. 다양성이 아까 모든 분이 이야기한 것처럼 다양성은 필요할 수밖에 없잖아요. 생명체들은 생명을 유지할 수 있는 다양한 루트를 많이 갖고 있더라고 하거든요. 그래서 어떤 한 가지가 부족해도 다른 것들로 그걸 대체해서 생존할 수 있도록 시스템이 돼 있다고 해요. 그래서 저는 다양성은 당연히 필요할 수밖에 없다고 생각해요. 우리가 이런 질문을 하는 건 아마 다양성이 왜 필요한지보다는 우리가 다양성이 필수적인데도 불구하고 왜 인지하지 못하는지가 중요한 것 같아요.
다양성은 당연히 필요하지만, 작은 규모로 보면 다양성이 필요 없어 보일 수 있는 것 같아요. 비슷한 사람들끼리 같은 목적을 위해 모였을 때 유리한 것도 있잖아요. 그러다 보니, 우리가 우물 안 개구리처럼 되기도 쉬워서 다양성이 필수적이지 않은 것처럼 생각하는 사람들도 많은 것이 아닌가 싶어요. 그래서 작은 규모에서는 다양성의 필요성을 인지하기 어렵다 보니, 다양성을 신경 쓰지 않고 오히려 다양성에 반대되는 행동을 하게 되기도 하는 것 같아요.
하지만, 작은 규모가 유리한 부분도 있지만 큰 규모가 유리한 부분도 많잖아요. 작은 규모에서 큰 규모로 확대를 해 나가려고 하면 다양성이 갖는 장점들이 큰 힘을 발휘하게 될 테니, 다양성을 더 빨리 받아들이고, 준비할수록 큰 규모에서 원하는 목표에 더 잘 도달할 수 있게 될 것 같습니다.
보라 여러분들 말씀 들으면서 생각이 발전한 부분이 있는데요. 저도 다양성이 왜 필요한지 굳이 설명하라고 하면 사회적인 관점에서는 ‘지속가능성’인 것 같고 제 개인 차원에서는 저는 ‘재미’인 것 같아요. 다양한 사람과 만나고 소통하는 게 재밌고 다양한 활동을 해보고 체험해 보는 걸 좋아하니까, 제 삶을 충만하고 풍요롭게 한다는 면이 있는 것 같아요. 사회에서 왜 다양성이 필요한가 하고 생각하면 아까 헬렌님도 말씀하셨지만 지속가능성인 것 같아요. 계홍님 말씀도 전적으로 동의가 갔어요. 다양성이 왜 필요한가 하면, 세상이 원래 다양하고 사람이 원래 다양한데 우리가 하나의 기준으로 자꾸 사람들을 보려고 하거나 내 기준으로만 보려고 하니까 다양해 보이지 않는 게 아니냐는 생각이 들었어요. 그러므로 왜 필요한지가 아니라 원래 자연스러운 게 그것인데 우리가 인간이 뭔가 손쉽게 사고하기 위해서, 혹은 게으르니까 정보 처리를 빨리하기 위해 다양성을 마음속에서 거부했던 것이 아닌가 하는 생각이 들었습니다.
오늘 이야기하면서 바뀐 또 다른 생각은요. 저는 주로 다양성에 대해 생각할 때는 구성원의 다양성이라는 관점에서 생각을 많이 하는 편이거든요. 제가 교육 분야에 있어서 그런 것도 있어서 그런 것 같아요. 그런데 오늘 도구에 대한 다양성도 얘기가 나왔어요. 여러 가지 도구나 툴을 사용할 줄 알면 때와 필요에 맞게 도구를 활용할 수 있어서 유연하게 일하는 데에 도움이 될 수 있겠다는 생각을 새롭게 한 것 같습니다.
Typescript 언어로 만든 오늘 대화 요약