brunch

매거진 유라임 프로젝트 이야기

라이킷 30 댓글 4

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 메튜 Nov 16. 2017

혼자하는 개발이 만드는 자만심.

5개월간의 유라임 집중 개발에서 느낀 스스로의 한계와 자만심

너무나도 글이 뜸했다. 언제나처럼 바뻤다. 학교가 거의 끝난 지난 6월부터 4개월을 쉴새없이 달렸다. 그간 유라임에 적용하고 싶던 많은 것들을 하나 둘 해나갔다. 하루에 열 시간 이상을 코딩에만 매달렸다. 샌프란시스코의 카페를 전전하면서 한번 앉으면 최소 서너시간을 앉아서 개발에만 몰두했다. 예전에 ReactJS로의 마이그레이션 포기 라는 글을 쓴 적이 있었는데 이 리엑트라는 것이 한번 빠져들게 되니깐 헤어나오지 못하겠더라.

희안하게도 내가 엉덩이가 무거워진 원인은 '버그'에 있다. 즉, 내가 이 프레임워크를 제대로 이해하지 못하고 소비했던 많은 순간들. 물론 지금도 간간히 개인 블로그 (matthew.kr) 에 정리하고 있지만 정말 스프링을 개발할 때 그랬듯이, '오픈소스'가 쓰여지는 순간 정말 예상치 못하는 버그들 때문에 의도치않게 시간을 많이 잡아먹는 경향이 있다. 그리고 성격상 그 버그 혹은 에러를 해결하는 순간의 희열 혹은 쾌감을 알고있기 때문에 이를 만끽하기 위해서 밤낮을 가리지 않고 에러에만 몰두하게 된다.

사실 이런 내 성향은 20대에는 통했지만 30대가 되고 가정이 생기면서는 많은 부분에서 지장을 초래하게 되었다. 일단 집안일을 못하니 이 상황에서 파생되는 많은 문제가 있었고, 운동도 자꾸만 안하고 하루에 커피만 서너잔씩 먹고 삼시세끼를 모두 챙겨먹다 보니 살도 찌고, 자세도 자꾸만 구부정해지고. 특히 가장 문제였던 것은 한 문제를 가지고 몇날 몇일을 생각하다 보면 내가 현실세계에 있는 것인지 헷갈릴 때가 많았다. 꿈에서도 계속 개발하는 내 모습을 하루이틀도 아니고 한달 내내 지속될 때고 있었다. 내가 좋아하는 것을 만든다는 생각과, 내가 원하는 스택 (Play, Scala, ReactJS, ES6 on Containers) 을 사용한다는 생각에, 진심으로 근 5개월이라는 시간동안 흥분 속에서만 살았던 것 같다. 버그를 발견해도 이를 정리할 시간도 없었고, 느낌상으로는 목표한 10월 베타서비스까지는 공정률 100%를 위해 열심히 달려간 느낌이었다.

에러님에 대처하는 나의 모습

그런데 5개월이 지나서 베타가 나왔는가? 아니다. 아직도 총 공정률은 한 65% 정도 되려나. 그것도 기획했던 많은 부분을 제외하고 나서이다. 원인은 내 실력부족이라 생각했다. 버그나 에러가 생기면 나 스스로의 모습을 자세히 살펴봤다. 한국에 있을때는 그래도 도움을 받을 몇몇 재야의 고수 형님들과 친구들이 많아서, 난 특이하게도 술안주로 버그를 주제로 내놓고 해결하곤 했다. 그러다 미국에 와서는 영어 울렁증 때문이랄까, 집에서 도통 나가질 않고 겨우 구한 사무실에서도 혼자서 구석에 쳐박혀 있었다. 그래도 자신은 있었다. StackOverflow, Serverfault, AskUbuntu 와 구글신, 깃헙 등등 실상 많은 세계에서 나와 비슷한 에러를 가진 사람들이 존재했으니, 이리저리 질문 짜집기 하면 일단 어떻게던 해결이 되곤 했으니 말이다.

그런데 이런 버그를 자세히 살펴보니 결국 가장 근본적인 원인은 내가 가장 기본적인 근원을 이해하지 못함에 있었던 것이 많았다. 예컨데, 리엑트의 탑-다운 방식을 이해하지 못하고 어거지로 부모의 클래스를 호출할 방법을 찾거나 child끼리의 이벤트 공유에 대해 고민했다. Redux를 쓰며 모든 ajax호출을 백엔드 라우터에서 정의한 그 RESTful 처럼만 만들다보니 프론트엔드임에도 불구하고 action재활용을 하자는 측면에서, 결국 cascading방식의 리소스를 부르는 방식을 찾지 못해서 심지어는 타이머를 두기까지 했다. 결국, 내가 Promise에 대한 이해를 하면서 하나의 action을 실제 서비스 단위로 맵핑하는 식으로 처리했고, 생각해보니 이게 가장 좋은 방식이긴 했다. 예컨데 페이지에 필요한 모든 자원은 하나의 action에서 정의하는 것으로 말이다. 그런데 이렇게 하면 jQuery시절 콜백과 무엇이 다른가? 라는 생각도 들긴 했는데, 아니 비즈니스 로직 전체를 모듈화 할 필요까지 굳이 없는데 이상한 완벽한 모듈화라는 생각에 그런 생각을 저질렀다니.

위에 예로든걸 풀어서 말하자면, UserAction이란 곳에 만약 1) 사용자 로그인 처리함수 2) 사용자 token을 받는 함수 3) 사용자 정보를 받는 함수 이런게 있다면 1->2->3 의 순서를 처리하기 위한 고민에서 나는 view단에서, isFirstLoaded/isSecondLoaded/isThirdLoaded 같은 mapStateToProps된 변수를 통해 데이터가 받았다는 것을 componentDidMount()에서 최초 actionCreator 를 부르고 componentWillReceiveProps()같은 곳에서 위 맵핑된 변수를 통해 처리하려 한 것이다. 사실 이런 방식으로 하려 했던 것은 로딩바를 적용하려다 보니 데이터가 로딩되었다는 것을 액션에서 개개별로 dispatch하게 하다보니 이런 현상이 생겼다.

문제는 이렇게 하니 컴포넌트단의 코드가 너무나도 커져버린 것이다. 그리고 리소스 호출 순서도 매번 헷갈렸다. 1에서 필요로 하는 예컨데 ID같은 것이 2,3과 맛물리는데 2,3을 갑자기 먼저 호출해서 발생하는 에러도 있었다. 그래서 그냥 1,2,3의 과정을 Promise를 써서 cascading되는 함수 하나를 가지고 최초 컴포넌트 마운트시에 호출하고 이후에는 자원에 대한 터치를 유저의 액션이 있지 않는 한 건들지 않는 부분으로 바꿨다. 이렇게 하니 깔끔했다. 화면단의 Init 함수가 일단 하나이니, 관리하기도 쉬웠다.

액션도 모조리 모듈화 해버리려고 한 내가 의아했다. 왜 그럴려고 했을까? 모듈화의 정확한 장점에 대한 인식 없이 그저 모듈화가 빠르겠지 라는 생각에 내렸던, 약 8월쯤 발생했던 내 가장 큰 실수 중 하나였다. 덕분에 리소스가 엄청나게 꼬여가지고는 이를 바로잡는데 약 한 달의 시간이 소비되었었다.

이런 본질을 이해하지 못한 버그가 프론트 뿐만 아니라 백엔드에서도 존재했다. 스칼라의 map과 flatmap에 대한 이해 없이, Action.async와 맵핑되는 Future를 만들려고 그저 막무가내로 들이댔었다. 사실 지금까지 스칼라 공부를 세번이나 시도했지만 변변히 실패했다. 스칼라라는 자체가 너무나도 좋은 언어인 것은 알겠는데, 실무에서 쓰면 나의 자바를 쓰던 그 형식이 남아서 결국에는 문법이 자바처럼 된다. if/else좀 안쓰고 match/case좀 그렇게 쓰고싶어도 전체적인 스칼라의 구조의 이해 없이는 이놈의 타입 이라는 것을 그저 컴파일러의 추론에만 의존했는데, 그게 그렇게 쉽게 되나. 아직도 백엔드에서는 타입을 인지 못하고 나오는 에러들이 간간히 나온다.

비단 타입 뿐만 아니라, 일단 큰 자원 목록을 map을 하는 과정에서 어떻게 manipulation할지에 대해서도 익숙해지는데 시간이 걸렸다. 결국 DB쿼리를 짜던 시절의 그 생각으로 접근하니 일단 자원의 관리에 대해서는 손쉽게 할 수 있었다. (왜 Spark에서 스칼라를 쓰는지 대충 알겠더라.) 그런데 그렇게 lazy loading될 자원들을 어떤 타이밍에 리턴해주고, 그런 이해를 하려면 결국 플레이 혹은 스칼라의 원천을 살펴보는 수 밖에 없다. 얼마전 만난 모 스타트업 VP도 내게 "너 플레이 써봤으면 내부에서 HTTP서버 동작과정 소스코드로 이해한적 있어?" 난 그저 플레이면 Netty쓰는 줄 알고 있었는데 얼마전에 보니 Akka HTTP로 바꿨더라. 하, 결국 지금까지 나는 프레임워크의 내부적인 이해 없이 접근하는 것이 얼마나 바보같은 짓인지 알았다. 그래서 요즘에는 Akka HTTP를 조금씩 보고 있다.

오픈소스를 사용함으로 인해 발생하는 버그는, 일단 그 라이브러리의 전체적인 설계를 충분히 이해하고 들어가야 한다고 생각한다. 예제도 많이 보고, 내가 원하는 기능을 어떻게 만들지에 대한 충분한 설계가 필요했다. 물론 나도 아키텍처에 관심도 있고 해서 설계를 안한 것은 아니다. 그런데 그놈의 async라는 자체에 홀릭되다 보니 정말로 무분별한 비동기화 서비스를 지향하게 되고, 그게 좋은지도 모르고 무턱대고 쓰다 보니 에러가 생겨도 무엇인지를 모르는 것이다. 그래서 바닥부터 구글링하며 에러를 해결하는 데에 몇 날을 소비한다. 그리고 이를 해결했을 때 느끼는 성취감은, 결국 내가 너무나도 무지한 상태에서 뭐 이정도면 되겠지 라는 생각에 무턱대고 개발하다 생기는 엄청나게 높은 거대한 장벽을 넘었으니깐 당연한 것이었다. 그런데 문제는 그런 장벽이 한두개도 아니고 몇십개는 된다는 것.

그렇게 돌이켜보니 지난 5개월을 그런 몇 십개의 버그들을 넘어가면서 살아왔는데, 정작 중요한 것은 원리를 이해하려는 공부를 하지 않았다. 5년 남짓한 내 '실무'개발경력들 간에 사용했던 수 많은 오픈소스 라이브러리들을, 나는 정말 그것들이 어떻게 짜여졌는지에 대한 의문을 가진 적이 있을까? 그리고 그게 내 오픈소스를 대하는 태도의 가장 큰 문제가 아니었을까. 무턱대고 대형 프레임워크 혹은 오픈소스에 대한 신뢰 때문에 어거지로 끼워맞추려 했던 나 스스로의 모습이 말이다.

펀딩 실패 후 인식한 현실

사실 작업 속도가 느리긴 해도 일단 개발은 되긴 했다. 그러다 지난달 말, 모 VC의 스타트업 펀딩 프로그램에 지원하기 위해 갑작스래 1개월 동안 유라임을 다듬으면서 생긴 일은 이렇다. 우선 유라임 프로젝트 자체가 너무나도 크다는 인식을 드디어(!) 했다. 우선 만들고자 했던 유라임을 크게 나누면:

1) 엑셀이 질려서 100년 인생계획을 관리해주는 엑셀보다 뛰어난 웹 플랫폼을 만들어 제공한다.

2) Fitbit, Withings등 개인 데이터를 자동 취합해서 이쁘장한 차트로 보여주고 공유하는 SNS적인 기능.

3) 이 모든것에 대한 데이터의 분석을 해서 계획에 대한 인식을 담은 일종의 분석표를 대시보드 혹은 weekly email을 통해 전달해줌.

일단 1번의 경우는 조금 오버해서 2년 내내 개발해왔는데도 '엑셀'보다 뛰어난 것은 만들지 않았다. 다만 최소기능으로는 만들었을 뿐. 2번의 경우는 데이터 취합 시스템은 만들었고, SNS적 기능과 차트는 조금 더 손봐야 했다. 그래도 금방 할 것 같았다. 3의 경우는 답이 없었다. 내가 무슨 데이터 사이언티스트도 아니고, 그 수 많은 사용자의 데이터를 어떻게 정형화 시킬 수 있단 말인가. 아무리 공식을 짜내고 짜내어봐도, 일반적인 '진척도' 혹은 '성취도' 이외에는 내가 만들 수 있는 것은 별로 없었다.

그래도 일단 개발에 들어갔다. 그리고 내가 가장 잘 할 수 있는 것에 집중했다. 3번은 이번MVP에 포함시키지 않고, 2번을 끝내고 1번을 마무리해서 제출(?) 하자는 식이었다. 결과는 어땠을까, 아직도 2번을 진행중이다. 예컨데 10월 말 2주일에 걸쳐 작업했던 것은 이와 같다. 사용자가 잘 된 유라임 차트(Chart.js와 조금 내 나름대로 디자인한) 대한 TinyUrl을 제공하기 위해 해싱과 약간의 암호화 (AES) 에 대한 인식이 필요했고, 나는 사용자가 해당 URL을 통해 페북이나 하물며 이곳 브런치에서도 공유가 될 수 있었으면 좋겠다는 생각을 했다. 그런데 공유에서 가장 중요한게 섬네일인데, Chart.js와 DOM으로 디자인한 내 차트에 대해서는 일단 이미지가 들어가는 게 하나도 없어서 공유하면 딸랑 링크만 나오게 되더라.

이해를 돕기 위해 간단한 현재 개발중인 유라임의 부분 스샷을 첨부한다. 만약 내 수집된 데이터 중 "비만도 20%대 유지하기" 라는 22.895%의 데이터를 (빨간 네모박스) 내가 '잘된' 데이터라 정의하고, 이를 공유를 하고 피드백 (댓글 등)을 받게 하는 기능이 내가 만들고 싶은 기능이다. 그런데 그 공유를 할 때 가장 우측의 스크린샷과 같이 페북 공유에서 차트의 Preview 이미지가 나오게 하고 싶은데 이것을 어떻게 해야할지 감이 안왔다. 이유인즉, 일단 브라우저를 통해 DOM랜더링을 하고 이를 캡쳐해야 하기 때문이다. 한 1주일 정도 고민하다가 Selenium과 같은 headless브라우저가 있다는 사실을 알고, 이를 사용해서 백엔드 단에서 어케저케 작업을 했는데 이러다 보니 2주가 순삭됬다.

사실 이런 기능 뿐만 아니라 타임라인, 댓글, 라이크 등 일반적인 SNS기능도 넣어야 하는데 작업의 진전이 더뎠다. 그렇게 겨우 2번을 진행했었는데 어떻게 1,3번을 더 진행할 수 있었을까. 결국 펀딩은 실패로 끝났고, 여기서 나는 이 유라임 프로젝트를 하며 가장 진지하게 이 질문에 대해 고민을 했다.

"아 이거, 정말 내가 혼자 만들 수 있는거 맞아?"

나는 이 의문을 해소하기 위해 일단 유라임 개발을 중단했다. 가만히 생각해보니 지난 5개월간 내가 해온 작업이 생각보다 적었다는 것을 인지했다. 너무 나 스스로의 실력을 과대평가 하고 있던 것이다. 이미 베타 오픈을 하기로 했던 10월은 지나갔고, 11월조차 중반에 다다렀다. 점점 나 혼자 만드는 것에 대한 자신감은 상실되어 갔다. 그래서 개발이 하기 싫었다. 대신 사람들을 만났다. 마침 동네에 놀러온 형도 있었고, 자주 만나는 지인도 있었다. 한 10명 정도 만나니깐 답이 나오기 시작했다.

"아, 내가 개인 프로젝트를 진행하고 있었구나."

분명 한국에서 어느정도의 투자를 받고 진행하고 있었지만, 나를 믿고 기간을 넉넉하게 주시는 개발과의 관계 없는 사장님의 응원도 있었고, 아이디어에 대한 '유출'의 불안감 때문에 브런치를 시작하기 전 1년 정도는 혼자 개발을 했었다. 모든 고민을 혼자 앉고 갔다. 팀원따위는 없었다. 처음의 생각은, 프로토타입까지 만들 능력 없으면 개발을 하지 말자는 것이었는데 조금만 하면 될것 같은 생각이 계속되서 1년이 넘었고, 지금처럼 또 5개월을 버그와 사투하며 질질 끌어온 것이다.

그런데 자세히 살펴보면 이게 '개인' 프로젝트 같었다. '제품' 이라면 기업은 제품을 만들어서, 시장에 출시하고 지속적으로 이에 대한 변화를 수용하고, 보안해 나가며 수익창출에 대한 고민을 해야 하는데 나는 그저 아직 제대로 된 테스터 하나 없이 그저 내가 생각하는 "완벽한" 기능을 위해 달려온 셈이 아닌가. 딜레이 되는 것은 그렇다 쳐도, 프로젝트를 뒤집어 엎은 적이 한두번이 아니다. 맘에 안들어서, 혹은 최초부터 설계가 잘못되어서 계속해서 뒤집어 엎은 것이다. AngularJS에서 ReactJS로 개발중에 바꾼 것도 그 예중 하나이다. 사업성에 대한 고민이 없었다. 어딘간 유저가 있겠지, 혹은 요즘 조금은 침체기인 quantifiedself와 관계된 사람들이 있을 것이라는 생각만 했다. 광고 붙히거나 수익모델이야 나중에 만들면 되지 라는 생각. 이게 무슨 사업인가, 개인 프로젝트지.

몇주간의 고민에 걸쳐, 우선 MVP의 정의를 정말 제대로 한번 내려보기로 했고, 투자처와의 합의를 통해 조금 더 장기적으로 프로젝트를 진행하기로 했다. (덕분에 이젠 취준생의 세계에 뛰어들었다. 여긴 또 신세계네.) 그리고 이 이상으로 feature를 추가하지 않고, 완성도만 높혀서 오픈하는 것으로.

오픈소스화와 자만한 코드의 퀄리티

많은 지인들이 결코 혼자하는 것이 좋은 생각이 아니라는 조언을 해주셨다. (그리고 지금까지는 이를 새겨듣지 않았다!) 위에서 언급한 아이디어 유출에 대한 우려도 있었는데, 사실 그게 뭐가 중요한가. 일단 어떤 식으로던 빨리 만드는게 중요하지. 그런데 또 마냥 빨리 만든다는 것의 단점을 알게 되었다. 바로 코드 퀄리티다. 사실 내 코드에 대한 자신이 없다. 물론 그간의 짬(?)으로 패턴화 된 것들은 있지만, 얼마전 스칼라를 다루는 모 지인 형에게 호되게 코드리뷰를 당하고 나서, 아 정말 이대로 혼자 개발하다간 이상한 개발이 될 수 밖에 없을 것 같다는 생각이 들었다. 더 좋은 코드를 위한 고민을 하긴 하지만 그보다 더 내게 중요했던 것은 오로지 빠른 개발이었으니깐 말이다.

그래서 내 코드를 살펴봤다. 리펙토링은 나중에 라는 생각에 덕지덕지 붙어있는 주석들, 인라인으로 짜여진 파라미터들, 어느 하나 마음에 드는 부분이 없다. 깔끔한 코드에 대한 인식, 혹은 정확하지 못한 프로그램 설계에서 어떤 코드 퀄리티를 기대하겠는가, 당치도 않다. 정말 많은 생각을 했다. 아, 너무 자만감에 빠져산 것이 아닐까. 나를 너무 과신하고 있던 것 같았다. 잘 살펴보면, 일단코딩 공부를 많이 안했다. 여기서 코딩 공부란 것은 문법과 프로그래밍 언어에 대한 깊은 이해를 말한다. 뭐 자바개발 5년차니 알껀 다 안다고 생각했다. 그런 것 없이 무턱대고 빠른 개발만 원해서 개발했으니, 제품의 퀄리티에 대한 자신감이 없는 것은 물론이고, 코드에 대해서도 대체 내가 잘 하고 있는지에 대한 확신이 안섰다.

그래서 오픈소스화를 일차적으로 결심했다. 소셜 부분을 제외한 나머지는 오픈소스화 해서 개개인이 자신의 서버에서 유라임을 돌려 개인 데이터를 취합하고, 분석하는 기능을 제공하는 것으로 말이다. 유라임 웹에서는 여기에 추가로 소셜 기능을 제공하는 식으로 일차적인 정리를 했다. 솔직히 겁이 난다. 사실 난 오픈소스 세계에서 참여했던 적이 단 한번밖에 없다. Browsersync라는 곳의 contributer 로 그것도 상당히 마이너한 것을 수정했을 뿐이다. 그런데 벌써부터 내가 코드를 오픈하고 피드백을 받는다, 그것도 전세계적으로. 내가 그 엄청난 피드백을 감수할 수 있을까? 이것도 결국 웃긴 걱정이다. 당장 유저가 한명도 없을 수 있는데 뭣하러 그런 생각을 하겠는가.

아마 엔지니어가 창업했을 때 문제중 하나가, 제품은 완벽하고 뛰어난데 실제 사용자가 없어서 벌어진 경우를 많이 봐왔다. 일반화하기는 싫지만, 이대로 가다가는 나도 그 중 하나가 되지 않을까. 내 기준에서 '완벽'을 추구하며 만든 제품이 알고보니 일반 유저들한테는 전혀 쓸모없는 제품을 만드는 것 말이다. 감사하게도 나는 브런치를 통해 많은 분들의 관심을 받고 있지만, 막상 누군가에게 공개하길 꺼려하는게 현실이다. 완성도에 대한 자신도 없고, 피드백을 받았을 때 그것이 나한테 상처로 남지 않을까 두렵다. 실제로 지난 지인형의 코드리뷰에서의 한마디 한마디를 견뎌내기가 너무나도 힘들었다.

혼자하는 개발이란 혼자만의 공간에 같혀있는 것.

나는 사실 개발자라는 말보다는 조금은 예술적인 작품을 만든다는 생각을 가지고 있었다. 본래 내가 디자이너를 꿈꾸기도 했고, 그래서 물론 원천부터 디자인 한 것은 아니지만 최소한 짜집기와 브랜딩에는 자신이 있었다. 유라임 로고도, 전체 윤곽 및 모바일웹도 직접 디자인을 하긴 했다. 부트스트랩이나 fontawesome, glyphicon 등 요즘 워낙 모던웹을 만드는 데에 좋은 프레임워크도 많고 themeforest같은데에서는 예제로 볼만한 디자인 리소스가 정말 많다. 그래서 이를 짜집기 해서 유라임을 만들어냈다. 여기다 본래 개발자니깐 개발한 코드들 붙히면 뭔가 개발이 되더라.

그런데 이런 것의 치명적 단점이 있었다. 결국 이렇게 혼자 하다보니 "어, 되네?" 라는 생각을 많이 했다. 솔직히 말해 실무에서도 약간은 독고다이 같은 스타일로 작업을 진행했었는데, 대부분의 작업을 혼자 끌고가는 것을 선호했다. 그래서 그게 습관화과 되어서 스타트업을 진행하면서도 남의 도움없이 하려고 계속 시도했던 것이다.

"1인 개발자" , "혼자하는 OOO" 이런 글들을 많이 보았다. 나도 이 브런치에서 관련된 글을 많이 썼다. 아마 2009년인가, 앱개발이 유행을 타던 시절, 나도 Objective-C로 앱을 하나 띄워보고는 "오, 나도 프러덕 같은 것을 만들 수 있구나! 이걸로 혼자 개발해서 돈버는 사람도 많구나!" 라는 것이 내 머릿속에 불을 질렀고, 그 불씨가 아직도 사그라들 생각을 하지 않았다. 지금까지 개인 프로젝트를 학교 포함 약 20개 정도를 진행했는데, 어떤 코드 및 프러덕에 대한 퀄리티에 대한 검토 없이 오로지 내가 만들고자 하는 그 '목적'을 달성하기 위한 개발일 뿐이었다.

요즘에는 위에 언급했듯이 급 취준생 모드가 되어서 코딩 문제를 풀고 있다. 이 인터뷰라는 세계도 신세계이다. 그리고 재밌다. 너무나도 전략적으로 접근해야 할 것들이 많고, 스스로를 포장해야 할 것들이 한 둘이 아니다. 나처럼 자기브랜딩 좋아하는 사람은 아마 더 즐거워 하지 않을까, 하지만 유학을 왔을 때 내가 토플 GRE등을 본 것처럼 이 인터뷰 세계에는 코딩문제라는 것이 '기본기'로 분류되고 있었다. 그리고 문제들을 접해봤을 때, 나는 점차 내 스스로의 개발에 대한 생각 방식과 알고리즘 설계에 대한 부족함을 인식하고, 요즘에는 많은 사람들의 코드를 보고 내 스타일대로 해소해 나가고, 그런 과정에서 즐거움을 느끼고 있다.

내려놓음의 과정이 이토록이나 클 줄은 몰랐다. 혼자 개발한다는 '자만한' 생각 말이다. 내가 마치 개발의 신이라도 된 마냥. 20년 이상 개발하신 분들도 기초를 다지는 개발 훈련을 하는 마당에 나는 그런 기본기도 없이 너무나도 자만했다. 근 5개월의 과정을 통해, 늦었지만 나는 나 스스로를 인식했고 부족함을 너무나도 많이 알았다.상처도 많이 남았었다. 하지만 결론은 얼마나 빨리 깨우치고 일어나느냐가 아닐까.

얼마전 모 세미나에서 멘토님의 말씀이 기억난다. "완전하지 않은 사람이 되라." 모두가 편안함 속에 안주하려 하고, 조금이라도 불편한 상황이 생기는 것을 피하려 한다. 하지만 그 불편을 감수하면 결국 이 조차도 다시금 나의 현실과 편안함이 되고, 그 모습이 발전이라고 부를 수 있는 것이다. 누군가의 피드백이 두렵고 상처가 되겠지만 그런 아픔의 과정 없이 치유되고 성장한다는 자체가 모순되었다. 한해가 저물어가는 시점에, 나는 중요한 교훈을 얻고서는 초심으로 돌아간다. 내가 프로그래밍에 처음 몸을 담궜을 때에 느낀, 누군가에게 도움을 받고 이를 해결하고, 내 문제점을 알았을때의 그것. 앞으로는 코드를 더 공개하고 더 피드백을 받고, 갇혀있지 않는 삶을 살고자 부단히 노력해야 겠다는 생각을 한다.

글쓴이 메튜장 | matthew@urhy.me | http://www.matthewlab.com

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari