오픈소스에 대한 미신과 배움의 비밀
* 이 글은 개발자를 대상으로 쓴 글은 아닙니다. 경영자나 IT기획하시는 분들의 보편적이 오해를 풀 수 있을까 하는 마음, 더욱 솔직하게는 그냥 지켜보고만 있기가 답답해서 쓴 글입니다.
유명한 회사가 오픈소스 솔루션을 썼다
무슨 의미가 있을까? 한 5, 6년 전에 '아마존처럼 하고 싶다'는 컨설팅 의뢰가 꽤 있었다. 지금 누군가 오픈소스 솔루션 도입을 검토하고 있다며 의견을 구하면, 그때가 떠오른다. '아마존처럼 하고 싶다'는 말이 구체적으로 무엇을 지향하는 것일까? 대개는 내용이 없다. 또한, 예나 지금이나 기성 조직에서 베스트 프랙티스 운운하는 중간 관리자를 만날 때 느끼는 감정도 그렇다. 그저 승부 자체에만 초점을 두면...
물론, 모두가 그렇게 피상적인 해답만 갖고 대신 해결해줄 해결사를 찾지는 않는다. 진정성을 가졌던 어떤 분이 있었는데, 그에게 '아마존처럼 하고 싶다'는 말은 '변화의 단초를 얻고 싶다'는 의미였다. 그러나 무엇을 바라는지를 구체적으로 정하지 않고, 좋은 방법부터 고민하는 분들에게 무슨 말을 해줄 수 있을까? 특히 실패하고 싶지 않아서 솔루션부터 찾는 분들에게는 의미있는 답이 있을까?
솔루션부터 찾으면 100% 실패한다.
당연한 일인데, 왜 수없이 반복할까? 왜 다른 사람이나 회사가 검증한 방법을 택할까? 이유는 짐작할 수 있지만, 선뜻 내뱉기 힘들다. 대신에 서양 사람들이 흔히 쓰는 관용 표현으로 화제를 돌려보자.
There's no silver bullet
대부분 들어본 말이다. 인정한다면, 알면서 다르게 행동하는 자신을 돌아봐야 한다. 한방에 점프하려고 하는 욕구는 무엇인가 부터 들여다 봐야 한다. 물론, 스스로를 돌아본다는 것은 말처럼 흔히 벌어지는 일이 아니다. 내 경우 그렇게 마법을 갈구하는 경우는 대개 '오랫동안 했어야 할 일을 하지 않고 있었'다는 사실을 발견한 경우다.
결과적으로 문제부터 명확히 정의해야 한다. 어렵고 규명하기 어려운 고질적인 문제일수록 더더욱 그렇다. 안타깝게 그 방법에 대해 명쾌할 설명할 능력은 없다.
다만, 급하게나마 오픈소스를 사용하는 일이 어떤 것인지를 이야기하고 싶었다. 그런데, 그걸 단박에 적자니 엄두가 나지 않아 한마디만 하려고 한다. 오픈소스를 사용하는 일은 대개 문제 정의에 도움을 준다는 사실이다.
남이 내가 쓸 시스템을 만들어줄 수 있을까?
당연히 있다. 그런데, 새로운 솔루션을 찾을 때 보통은 유사한 경험이 있기에 찾게 된다. 차세대 프로젝트의 경우처럼 기존 시스템에 불편함이 있는 경우 외주 개발 의뢰를 한다. 시작은 늘 문제 정의부터 한다. 보통은 배경과 기대효과를 추상적으로 잡아두고, 이를 분할하면서 구체적으로 문제를 정의한다. 대개는 '요구사항 정의'라는 말과 틀을 사용하면서...
그런데, 그때 현재 안되던 것이 정확히 무엇이고, 어떤 방식으로 작동하기를 원하는지 미리 정할 수 있을까? 아래 말을 조금 음미하길 바라는 마음에 인용문으로 구분해서 써본다.
우리는 불편함을 겪었을 뿐, 불편을 해결한 이후의 삶을 살아보지는 않았습니다.
요구사항 정의가 근본적으로 어려운 일임을 인정해야 한다. 왜냐하면 개발자가 아닌 사람이 개발에 참여하는 유일한 창구는 제대로 요구하는 일이다. 그리고, 개발자는 나의 욕구를 잘 모른다. 또한, 내가 무슨 말을 해도 개발자의 살아온 배경에 맞춰서 이해하게 되어 있다. 그런 가운데에서 진심으로 내가 원하는 바를 그가 알아듣는 방법으로 전달하지 않으면 원하는 시스템을 만들 수는 없다.
그런데, 우리는 그 어렵고도 진정성 필요한 일조차 남에게 맡기기도 한다. 더구나 그 어려운 일을 단기간에 끝낸다는 계획을 수립한다. 왜일까? 도대체 왜? 스스로를 함정에 빠뜨리는가?
순전히 외주 계약을 위해서 그렇게 한다. 경영 논리에 빠져 문제의 본질이 사라진다. 보고와 계약이라는 기업의 보편 논리에 휘말려 원래 하려던 일은 점차 희석된다.
만드는 과정에서 배워야 합니다.
답답한 이야기는 여기서 마무리하자. 다만, 문제 정의를 하는데 도움을 주는 방법을 기억하자. 나를 도울 수 있는 힘은 거기에 있다. 그것은 바로 '사용자나 고객으로부터 피드백을 받을 수 있도록 과정을 설계해야 한다'는 점[1]이다. 피드백과 학습의 비밀이 그 안에 숨어 있다.
이런 과정을 맛보는 실무적인 방법으로 매우 마음에 드는 글이 있어 번역에 참여하고, 며칠전에 popit에 올렸다. 그 중 가장 선명하게 기억에 남는 문장이 있다.
학습의 필수 원천은 바로 사용자나 고객으로부터 받은 피드백을 통해 얻는 지식이다.
오픈소스를 사용한다는 것은
마침 글을 쓰는 가운데 페이스북에 같은 상황을 겪고 있는 페친 글이 담벼락 상단에 떴다. 동시대인이란 말이 이런 의미일 것이다. 어디에 있어도 비슷한 경험을 할 수밖에 없는 한 시대를 사는 ... 그리고 지향하는 바가 유사한 사람간의 관계 혹은 경험.
카뱅에 오픈소스를 적용한 핵심 엔지니어
페친인 성동찬님은 카뱅에서 오픈소스 DB를 적용하고, 지금도 문제를 풀고 있는 엔지니어다. 그가 말하는 '과정'이 내가 강조하는 '문제'와 같다. 문제를 밝혀가는 과정에서 우리는 직업 일상을 바꿔나가는 힘을 얻는다.[2]
오픈소스 도입은 단순히 비용 절감이나 시스템 경직성 탈피 정도로 봐서는 안된다. 틀린 말은 아니지만, 주객이 전도된 목표다. 이렇게 한번 물어보자.
나에게, 내 동료의 삶에 혹은 나의 직원들의 삶에 어떤 영향을 주는가?
짧은 글로 설명할 수는 없지만[3] 오픈소스는 문제로 가는 길을 열어 준다. 엔지니어에게는 단순히 '작동한다 or 작동하지 않는다' 수준이 아니라, 그 다음으로 나아가게 해준다. 왜냐하면 이미 그 문제를 고민하는 다른 엔지니어가 블랙박스로 사용할 답을 주는 것이 아니라 스스로 열어 보고 고칠 수도 있는 미리 풀어본 해답을 코드로 제공하기 때문이다. 엔지니어는 그것을 접하며, 다른 사람의 경험을 빠르게 배우고 부족했던 용기를 채우고 서로 일을 나눠서 하는 방법을 깨달을 가능성이 많다. 창의성은 개인이 발현하는 것이지만, 오픈소스 커뮤니티를 구성하는 많은 사람들이 공유하는 문화를 자연스럽게 배우기도 한다. 그것이 진짜 오픈소스를 도입하는 이유에 가깝다.
엔지니어가 아닌데 오픈소스를 쓴다는 말은 무엇인가?
개발을 하지 않는 사람에게 오픈소스 적용은 무슨 말인가? 솔직히 말하면 별 의미가 없다. 어떤 엔지니어와 일할 것인가부터 정하라. 단순히 만들어주고 마는 개발자나 업체 말고, 당신이 시스템 주인으로서 어떤 IT 서비스를 행할 때 누가 개발을 할 것인가?
오픈소스가 어떤 의미인지는 그와 함께 일하는 과정에서 배우게 될 것이다.
주석
[1] 애자일agile이나 린lean 어쩌구 하는 움직임의 요체는 바로 이 부분이다.
[2] 그리고, 그 일상이 나의 다른 삶과 조화를 이룰 때 행복이나 평온을 느낀다.
[3] 나는 조만간 자의반 타의반으로 오픈소스가 기업에 주는 효과를 다루는 글을 쓸 가능성이 높다.