나는 오랫동안 개발이라는 분야는 재능의 차이가 크게 드러나는 영역이라고 생각했다. 같은 내용을 공부해도 어떤 사람은 금방 이해하고, 새로운 기술이나 복잡한 구조도 자연스럽게 받아들인다. 처음 보는 문제를 빠르게 분석하고, 내가 한참 고민해야 이해할 수 있는 코드를 쉽게 만들어내는 사람들을 볼 때면 개발을 정말 잘하는 사람들은 애초에 다른 사람들처럼 느껴지기도 했다.
특히 실제 개발을 시작하면서 이런 생각은 더 강해졌다. 학교에서 프로그래밍 문법이나 자료구조를 배웠다고 해서 바로 좋은 서비스를 만들 수 있는 것은 아니었다. 실제 서비스에는 데이터베이스, 네트워크, 운영체제, 아키텍처, 보안, 클라우드, 협업, 도메인 지식처럼 훨씬 넓은 영역의 이해가 필요했다. 이런 지식들을 빠르게 받아들이고 서로 연결할 수 있는 사람들이 결국 개발의 상위권에 올라가는 것이 아닐까 생각했다.
반대로 나는 개발 자체가 재미있고 좋아서 꾸준히 하는 사람이었다. 특별한 재능으로 앞서가기보다는 오랜 시간 공부하고 경험을 쌓으면서 조금씩 성장하는 쪽에 가깝다고 생각했다.
그런데 Austin Kleon의 《Show Your Work!》 를 읽으면서 내가 천재라고 생각했던 사람들을 바라보는 방식이 조금 달라졌다.
천재가 아니라 Scenius
Kleon은 우리가 흔히 가지고 있는 창의성에 대한 이미지 중 하나로 lone genius, 즉 모든 것을 혼자 만들어낸 천재에 대한 신화를 이야기한다. 위대한 결과를 만든 사람의 최종적인 모습만 보면 마치 그 사람의 머릿속에서 어느 날 완전히 새로운 아이디어가 나타났고, 그것을 혼자 발전시켜 세상에 내놓은 것처럼 보인다.
하지만 실제로는 많은 창작과 발전이 그렇게 이루어지지 않는다. Kleon은 Brian Eno가 사용한 Scenius라는 개념을 소개한다. scene과 genius를 합친 표현으로, 뛰어난 아이디어와 작업은 한 사람의 천재적인 능력만으로 만들어지는 것이 아니라 서로 영향을 주고받는 사람들의 생태계에서 만들어진다는 관점이다.
누군가는 새로운 아이디어를 제시하고, 다른 사람은 그것을 발전시킨다. 또 다른 사람은 기존에 전혀 다른 분야에서 사용되던 개념을 가져오기도 하고, 누군가는 문제점을 발견하거나 더 좋은 형태로 정리한다. 서로의 작업을 보고 배우고, 영향을 받고, 복사하고, 수정하면서 아이디어는 계속 새로운 형태로 발전한다.
이 관점은 위대한 개인의 성취를 부정하는 것이 아니다. 오히려 그 성취가 만들어지기까지 존재했던 수많은 연결을 함께 보는 것이다.
이 개념을 개발에 대입하자 굉장히 자연스럽게 느껴졌다. 생각해보면 개발자는 거의 아무것도 완전히 혼자 만들지 않는다. 우리는 다른 사람이 만든 프로그래밍 언어를 사용하고, 프레임워크와 라이브러리를 설치한다. 공식 문서를 읽고, GitHub에서 다른 사람의 코드를 보고, 블로그에서 해결 방법을 찾는다. 이해되지 않는 개념은 누군가의 설명을 통해 배우고, 그 지식을 다시 자신의 프로젝트에 적용한다.
혼자 컴퓨터 앞에 앉아 코드를 작성한다고 해서 실제로 혼자 개발하고 있는 것은 아니다. 내가 작성한 코드 안에도 수많은 사람의 생각과 작업이 이미 들어 있다. 사용하는 오픈소스가 있고, 읽었던 문서가 있고, 다른 개발자의 글에서 얻은 아이디어가 있으며, 그보다 훨씬 이전 세대의 개발자와 연구자가 만들어놓은 개념들이 있다.
생각해보면 나는 이미 거대한 Scenius 안에서 개발하고 있었다. 단지 그것을 의식하지 못했을 뿐이다.
개발의 많은 것은 연결되고 다시 해석된다
최근 개발의 기초 개념들을 다시 공부하면서도 비슷한 생각을 하고 있었다. 예전에는 개발에서 사용하는 수많은 개념이 모두 소프트웨어 분야 안에서 새롭게 만들어졌다고 막연하게 생각했다. 하지만 깊이 알아갈수록 많은 개념이 완전히 무에서 탄생한 것이 아니라는 사실을 알게 됐다.
수학과 논리학에서 가져온 생각도 있고, 기존의 컴퓨터 과학 연구를 기반으로 발전한 개념도 있다. 현실 세계에서 이미 사용하고 있던 구조를 소프트웨어 안에 표현하기 위해 만들어진 방법도 있다. 오래된 아이디어가 새로운 환경과 기술에 맞게 다시 해석되는 경우도 많다.
결국 새로운 기술을 배운다는 것은 계속 새로운 개념을 암기하는 것만을 의미하지 않았다. 이미 존재하던 생각들이 서로 어떻게 연결되고, 어떤 문제를 해결하기 위해 다른 형태로 발전했는지를 이해하는 과정에 더 가까웠다.
Scenius 역시 이런 개발의 특징과 닮아 있다. 우리는 이전 사람들의 생각을 배우고, 그것을 자신의 문제에 맞게 적용하고, 때로는 조금 수정하거나 다른 개념과 연결한다. 그렇게 만들어진 결과는 다시 다른 사람에게 전달된다. 개발이라는 분야는 이런 과정이 계속 반복되면서 성장해왔다.
이 사실을 받아들이고 나니 내가 개발자로 성장하는 방법도 조금 다르게 보이기 시작했다.
이전에는 다른 사람보다 더 빨리 이해하고, 더 어려운 문제를 해결하고, 남들이 생각하지 못한 것을 만들어야 뛰어난 개발자가 될 수 있다고 생각했다. 하지만 Scenius라는 관점에서는 내가 얼마나 특별한 사람인지보다 내가 이 생태계 안에서 무엇을 배우고 무엇을 다시 기여할 수 있는지가 더 중요해진다.
모든 개발자가 새로운 프로그래밍 언어나 프레임워크를 만들 필요는 없다. 누군가는 어려운 개념을 조금 더 쉽게 설명할 수 있고, 누군가는 좋은 예제를 만들 수 있다. 누군가는 버그를 발견하거나 문서를 개선할 수 있고, 자신이 며칠 동안 헤맸던 문제의 해결 과정을 기록해 다음 사람이 같은 시간을 낭비하지 않게 만들 수도 있다.
서로 다른 두 개념을 연결해 자신만의 관점으로 설명하는 것도 하나의 기여가 될 수 있다.
소비하는 개발자에서 기여하는 개발자로
돌이켜보면 나는 지금까지 개발 생태계에서 정말 많은 것을 받아왔다. 문제가 생기면 다른 사람이 작성한 글을 검색했고, GitHub에 공개된 코드를 참고했으며, 공식 문서와 영상, 강의를 통해 새로운 개념을 배웠다. 누군가가 오픈소스로 공개한 라이브러리를 사용하면서 내가 직접 모든 것을 만들지 않고도 더 빠르게 프로젝트를 만들 수 있었다.
내가 지금까지 개발을 계속 배울 수 있었던 것도 결국 자신의 지식과 작업을 공개한 수많은 사람 덕분이다.
그래서 앞으로는 단순히 지식을 소비하는 사람으로만 남기보다 나 역시 조금씩 다시 돌려주고 싶다는 생각이 들었다.
거창한 것을 만들 필요는 없다. 내가 새롭게 이해한 개념을 블로그에 정리할 수도 있고, 프로젝트에서 만난 문제와 해결 과정을 기록할 수도 있다. GitHub에 프로젝트를 공개하고, 왜 특정 기술을 선택했는지 설명하거나 실패했던 접근 방법을 남길 수도 있다. 좋은 자료를 발견했다면 다른 사람에게 소개하고, 내가 알고 있는 내용이라면 누군가의 질문에 답할 수도 있다.
나는 아직 배우고 있는 개발자다. 모든 것을 알고 있는 전문가도 아니고 개발의 방향을 바꿀 만큼 대단한 기술을 만든 것도 아니다. 그렇다고 해서 아무것도 기여할 수 없는 것은 아니다.
내가 오늘 이해한 개념이 누군가에게는 아직 어려운 내용일 수 있고, 내가 오랫동안 해결하지 못했던 문제를 정리한 글 하나가 누군가에게는 몇 시간을 줄여줄 수도 있다. 오히려 막 이해한 사람이기 때문에 어떤 부분이 어려웠는지 더 생생하게 기억하고 있을 수도 있다.
전문가가 된 뒤에만 지식을 나눌 수 있는 것은 아니다. 배우는 과정 자체도 누군가에게는 하나의 지식이 될 수 있다.
앞선 글에서 나는 Show Your Work를 내가 하는 일이 사람들이 발견할 수 있는 상태를 만드는 것이라고 생각했다. Scenius를 알게 된 이후에는 여기에 한 가지 의미를 더하게 됐다. 내가 작업을 공유하는 것은 단순히 나를 홍보하고 발견되기 위한 행동만이 아니라, 지금까지 내가 받아온 지식의 흐름에 나 역시 참여하는 일이 될 수 있다.
내가 이해한 것을 공유하면 누군가가 그것을 읽고 자신의 경험과 결합할 수 있다. 그 사람이 다시 새로운 생각을 공유하면 나는 그 내용을 통해 또 다른 것을 배울 수도 있다. 하나의 아이디어가 사람 사이를 이동하면서 계속 바뀌고 확장된다. 이것이 Scenius라면, 공유는 개인 브랜딩을 넘어 개발 생태계의 일부가 되는 방법이기도 하다.
천재보다 좋은 Scenius의 구성원이 되고 싶다
앞으로 나는 단순히 뛰어난 개발자가 되는 것만큼 좋은 개발 생태계의 구성원이 되는 방법도 생각해보고 싶다.
좋은 개발자들의 작업을 찾아보고 그들이 어떻게 생각하는지 배우고 싶다. 내가 이해한 것은 기록하고, 다른 사람에게 도움이 될 수 있다면 공유하고 싶다. 가능하다면 다른 개발자와 생각을 나누고 오픈소스나 커뮤니티에도 조금씩 참여해보고 싶다.
이 블로그 역시 그런 과정의 일부가 될 수 있다.
모든 것을 이미 알고 있는 사람이 완성된 지식을 가르치는 공간보다는, 내가 개발을 배우면서 이해하게 된 것과 고민했던 것, 서로 다른 개념 사이에서 발견한 연결을 계속 기록하는 공간으로 만들고 싶다. 그렇게 쌓인 글을 통해 비슷한 관심을 가진 사람을 만나고, 서로의 생각과 경험을 나눌 수 있다면 그 관계 자체도 하나의 작은 Scenius가 될 수 있을 것이다.
물론 Scenius가 개인의 노력을 대신해주는 것은 아니다. 개발을 잘하기 위해서는 여전히 공부해야 하고, 직접 코드를 작성해야 하며, 수많은 문제를 만나고 해결하는 경험을 쌓아야 한다.
다만 이제는 개발자의 성장을 혼자만의 경쟁으로 바라보고 싶지는 않다.
내가 천재인지 아닌지를 고민하기보다 누구에게 배우고 있는지, 무엇을 받아들이고 있는지, 그리고 내가 배운 것을 다시 어떻게 나누고 있는지를 생각하고 싶다.
개발자로 성장한다는 것은 혼자 높은 곳까지 올라가는 과정이라기보다 수많은 사람에게 배우고, 그 안에서 나 역시 작은 무언가를 기여하면서 함께 생태계를 확장해가는 과정일지도 모른다.
나는 천재가 아닐 수 있다. 그리고 이제는 그것이 크게 중요하지 않다고 생각한다.
좋은 Scenius를 찾고, 그 안에서 계속 배우며, 내가 얻은 것을 다시 나누다 보면 언젠가는 나 역시 다른 사람의 성장에 조금이라도 도움이 되는 구성원이 될 수 있을 것이다.
그것이 《Show Your Work!》를 읽으며 새롭게 생각하게 된 개발자로서의 성장 방식이다.
References
Kleon, Austin. Show Your Work!: 10 Ways to Share Your Creativity and Get Discovered. Workman Publishing Company, 2014.
Referenced chapter: Chapter 1, “You Don’t Have to Be a Genius”
Referenced section: “Find a Scenius”
ISBN-13: 978-0-7611-7897-2.
About the concept of “Scenius”
The term “scenius” is attributed to musician and producer Brian Eno, who used it to describe a communal model of creativity rather than the traditional model of individual genius.
Jeffries, Stuart. “Surrender. It’s Brian Eno.” The Guardian, April 28, 2010. Interview with Brian Eno.
이 글은 Austin Kleon의 《Show Your Work!》 중 “Find a Scenius”를 읽고 얻은 아이디어를 개인적인 개발 경험과 연결해 재구성한 글이다. 원문의 번역이나 재수록을 목적으로 하지 않으며, 책에서 제시된 개념과 개인적인 해석 및 적용을 중심으로 작성했다. 저자의 전체 논지와 구체적인 표현은 원저를 통해 확인하기를 권한다.
