평범한 개발자 그 이상이 되기 위한 야생 학습 비결

얼마전 발행된 SI 개발 10년차인데 코드 좀 봐주세요 라는 글에 많은 부분이 공감했다. 그 글에서 내가 언급된 탓에 덧붙이는 수준으로 몇 가지 생각을 보태려고 글을 쓴다. 제목에 명시한 표현을 어떤 뜻으로 썼는지 먼저 명시하고 팁을 뒤에 이어간다.

평범한 개발자 그 이상

평범한 개발자란 무엇인가? 모호한 정의이지만, 자신의 욕구에 따라서 정확한 정의없이 사람들이 말하기도 하고, 꿈꾸기도 하는 것 같아서 언급했다. 개발이 좋아서 시작했다가 그게 직업이 된 단계를 작위적지만 '평범한 개발자'라고 하자. 여기서 '평범함'이란 값으로 평가되는 것이 아니다. 그저 나를 포함한 많은 개발자를 관찰해보면 더 나은 다음 단계를 꿈꾸더라는 점을 표현하고 싶을 뿐이다. 그러나 그게 비범한 개발자로 귀결되는 것은 아니다. 그저 그 이상을 꿈꾸는 점만 공통점을 발견할 수 있고, 대개 발전하는 양상이나 각자의 인식이나 다음 행동은 다르기 마련이다.

야생학습이란

보편적 정의가 있다고 생각하지 않는다. 분명하지 않은 기억이지만 김창준님 글에서 처음 본 듯하다. 게다가 그 정의는 모호한 상태였는데 어느날 김창준님 페북에서 야생학습과 학교의 학습을 비교하는 표현을 보면서 '야생학습'의 스스로의 정의를 생각해본 일이 있다. 지금 스스로에게 다시 물으면 이렇게 답할 수 있다.

고미숙선생님에게 들은 '생활지'라는 표현처럼 일상에서 써먹을 수 있는 지식을 배우는 행위. 다시 말해서 머리로 이해하고 몸으로 익혀서 나 자신의 행동의 일부로 배양하는 행위^[1]

좀 더 여러분의 생각을 자극할 수 있도록 야생학습이 아니라 생각하는 예시를 들어보겠다.

• 출근해서 써먹거나 재미삼아 구현이라도 해볼 일이 없는 프로그래밍 책을 장시간 읽는 행위
• 유명한 컨퍼런스/세미나/교육을 듣기만 하고 그 달이 지나도록 내 일이나 내 코드에 반영하지 않는 행위
• (필자의 학교 생활 기준으로) 대부분의 학교 공부
• 몇 달을 스터디 했지만, 회사에서는 적용할 수 없다면 아쉬워하고 마는 순간 그때까지 했던 노력
• 오랜 운영으로 알게 된 지식에 대해서 명확하게 설명하지 못하는 경우

평범함을 넘어서기

창준님의 책 <함께 자라기>에 보면 의도적 수련에 대해 설명하고 있다. SI 개발 10년차인데 코드 좀 봐주세요 에도 비슷한 설명이 있다. 평범함을 넘어서는 것을 의도적으로 아주 간단히 또 정의해보겠다. 자신이 평범한 개발자라고 느낀다면 지금 못하는 것을 하게 되면 평범함을 넘어서는 것이다.

실천 방법 자체는 아주 쉽다. 지금 못하는 것 중에서 당장 시도할 수 있는 것을 꼽아서 어떻게 해볼 것인지 계획하면 끝이다. 어려운 것은 실제로 그 일을 계속하는 것이다.

내 경우를 돌아보면^[2] 처음에는 목표를 크게 잡아서 쉽게 달성하지 못하거나 중간에 포기하고 말았던 기억이 많다. 다행히 요령을 터득해서 언젠가부터는 아주 작은 목표 작업을 만들어서 해볼만한 게임으로 만들었다. 그러던 어느날 TDD 책을 보니 그거나 그거나 마찬가지라는 사실을 눈치챘다.

작은 단계를 계속 반복해서 목표를 달성하는 방법을 익힌 다음 단계는 일상의 대부분의 작업도 그렇게 바꾸는 것이다. 일상에서 깨알같은 실패와 성공을 맛보면서 나도 모르게 시간이 한참 흐르면 예전에는 생각도 못했던 일을 하도록 습관으로 만들어가는 것이다.

반드시 전략은 필요하다

SI 개발 10년차인데 코드 좀 봐주세요 를 보면 기술적인 고민이 차단된 환경은 가능하면 빨리 벗어나라고 조언한다. 경영자를 위한 글이 실리는 HBR 기사 중에서 싫든 좋든 전략은 이미 존재한다는 구절을 읽은 기억이 난다. 기사의 맥락이 개발자들의 그것과는 다르지만 나는 공통점을 발견할 수 있다. 더 나아지고 싶지만 방법을 모른다는 분들에게도 전략부재라는 공통점이 있기 때문이다. 전략이 없으면 대체로 나도 모르게 둘 중 한가지로 흘러가는 경향이 있다.

하나는 시키는대로 하는 노예형이 되는 것이다. 그냥 누군가가 시키는 일을 한다. 해야 하는 이유나 의도 자체를 완전히 하는 것이기 아니기 때문에 자기 손으로 한 일에 대해서도 완전한 배움이 어렵다. 동기부여도 떨어져서 몸으로 익힌 내용에 대해 생생함도 떨어진다. 무엇보다 의도하고 해온 작업이 아니라 조금만 다르게 응용을 해보라고 하면 못한다.

그렇지 않으면 자기위안형이 된다. 현장과 떨어진 배움에 집착하거나 실제적인 가치를 도외시하고 자기 스타일을 고집하는데 지나치게 많은 시간을 투자한다. 혹은 빨리 일을 끝내고 퇴근한 후에 책을 보며 신기술을 그냥 따라해보거나 친한 친구들과 어울려 주제를 바꿔가며 스터디를 하면서 회사에서 쌓인 불만을 해소한다. 이중으로 노력하지만 각자가 시너지가 나는 것이 아니라 배타적이 되는 일상의 틀을 갖게 된다.

학습하는 사람과 문화가 있는 곳으로 가라

사실 어디에서든 학습할 수 있다. 야생학습이라는 말의 어감처럼 말이다. 하지만, 여러분이 만일 위에서 말하는 전략이라는 단어에 고개를 갸우뚱하거나 스스로 전략이 없다고 생각하신다면 일단 학습하는 사람들이 있는 곳으로 가라고 말하고 싶다. 더 좋은 곳은 학습하는 문화가 있는 곳이다. 그런 문화의 존재 여부는 어떻게 확인할 수 있는가? 몇 가지 간단한 체크리스트가 있다.

• 그 회사가 오픈소스 활동을 지원하는가?
• 그 회사가 github 혹은 gitlab을 사용하는가? 이슈나 코드에 대해 토론하는 흔적이 그 안에 있는가?
• slack이나 dooray 같은 협업 시스템을 사용하는가? 그 안에 토론한 흔적이 있는가?

서로 코드를 어떻게 짜는지 일상에서 투명하게 보고 의견을 주고 받는 일은 엄청난 훈련 효과가 있다. 게다가 이런 것들이 일상이 되면 마치 SNS 사용과 같은 리듬을 만들어준다. 대단한 노력이 없어도 서로 소소한 변경 소식을 나눌 수 있고, 사소한 실수를 발견해줄 수 있다. 또한, SNS로 뉴스를 받아 보듯이 새로운 프로그램 기법을 배울 수 있다. 또한, 이렇게 서로에게 유대감이 생기고, 모르는 것을 서로 알려주는 일이 자연스러운 일상이 된다.

토론이 달려 있는 Merge Request 목록

개인이 아니라 팀 차원에서 보면 github/gitlab을 통한 코드 리뷰하는 문화가 있다면, 가벼운 작은 시간 투자의 연속으로 서로 지식을 공유하는 리듬을 아주 쉽게 배울 수 있다.

dooray와 같은 협업 시스템을 쓰는 문화가 있는 조직이라면 코드로 표현되는 지식 뿐 아니라 또 다른 다양한 형태의 지식도 전파된다. 아래 예시는 기술 이슈에 대해 한 동료가 파악한 내용을 남기고 관련자들에게 공유한 예시인데, 이런 내용이 노출되면 웹 서버와 같은 인프라 설정을 담당한 동료가 이에 대해 의견을 내기도 하고, 자연스럽게 시니어 개발자가 조언을 해주기도 한다. 모든 작업에 담당자가 있긴 하지만 자연스럽게 문제를 함께 풀어가는 문화가 생겨난다.

막내 개발자가 CORS 이슈에 대해 스스로 파악한 내용을 두레이 작업 댓글에 공유한 내용

dooray와 gitlab 협업을 통해 필자가 최근 3년간 직접 경험한 조직의 변화 양상 중에 기억나는 것을 아래와 같은 일들이다.

• 필자가 UML 표기^[3]를 사용했더니 UML 표기법을 배우지도 않은 많은 동료들이 그걸 흉내내서 그리기 시작했다. 실제로는 소스를 복사해 수정하는 식으로 했을 것으로 짐작된다.
• 관련 작업을 묶어서 협업이 필요한 작업 관리를 하는 방식을 팀원들 사이에서 자연스럽게 배운다. 앱 화면 개발자와 서버 API 개발자의 수정 시점이나 테스트 담당자사이에서 모호한 소통으로 대기시간이 발생하는 일이나 그로 인한 짜증을 줄이는 방법을 찾아내고, 그런 노하우가 자연스럽게 전파된다.
• 여러 사람의 연속된 댓글을 통해서 설계가 진행된다. 그리고 설계에 참여한 사람들이 설계 변경에 따라 자기들이 어떤 일을 해야 하는지 금새 확인해서 소통 시간이 줄어드는 부수효과도 함께 누린다.
• 혼자만 알고 있는 정보로 일종의 권력을 갖으려고 하는 사람들이 힘을 쓰기 어렵고, 소통을 모호하게 하던 사람들이 압박을 느껴 변화를 수용한다.
• 대면 회의시간이 줄어들고, 대면 회의를 할 때에도 협업시스템에서 이뤄졌던 대화를 토대로 (대부분 화면에 띄워 두고) 풀리지 않는 부분을 좁히는 형식이기 때문에 회의 만족도가 높아지고 소통 오류가 줄어든다.
• 평소에 쉽게 말을 걸기 어렵던 동료(주로 상급자)에게도 글로 쓰다보니 용기를 내어 소통을 하게 된다.

그리고 스스로에게 물어보라

마지막으로 남이 해줄 수 없는 부분중 하나는 전략을 수립하는 것이다. 다른 말로는 가치관이라고 할 수도 있겠다. 뭐라 하든 그것은 스스로 세우고 만들어가는 삶의 일부다. 그렇기에 그저 하나의 팁으로 스스로에게 던져볼만한 몇 가지 질문을 예로 들고 마치겠다.

• 당장 어떤 행동을 하면 더 나아질 수 있겠는가?
• 계속 지금처럼 할 것인가? 아니면 어떻게 다르게 행동할 것인가?
• 내가 지속해온 행동은 무엇을 위한 것인가?

주석

[1] 첫번째 정의인 터라 기름기가 엿보인다. 여러분의 관심에서 나온 질타라면 달게 받아 언젠가는 정의를 정제할 의향이 있으니 비판적인 견해와 댓글을 두 손 들고 환영합니다. (조국장관 대하는 기자들같은 태도라면 장담은 못하지만)

[2] 몇 달 전 이야기를 하는 것이 아니라 최소한 10년이 넘는 기간동안 노력(삽질)해온 과거 기억에서 대강 추출한 내용이다.

[3] dooray는 plantuml 플러그인을 제공하여 텍스트 표기로 UML 도해를 그릴 수 있게 해준다.