뭘 해야 하는지 알 것 같다.
나는 앞으로 코딩을 배워나가는 동안, 트러블 슈팅을 목적으로 글을 써나갈 것이다.
나의 공부와 진전을 알리기 위한 블로그 글 중에서 최고로 치는 가치는 ‘문제를 해결한 경험을 쓴 글’이 될 것이다.
내가 무엇을 공부했는지보다 어떤 사소한 문제라도 어떻게 해결했다는 과정이 더 중요한 글감이 될 것이다.
기왕에 ‘나를 알리고 내보이기 위한’ 글을 쓴다면, 더 예쁘고 명료하게 정리하지도 못할 정보글들을 재생산하기보다 차라리 사소하더라도 내가 맞닥뜨린 문제들과 그를 해결하기 위해 발버둥친 기록이 더 내보일 가치가 있을 것이다.
프로젝트는 포트폴리오에, 트러블 슈팅은 블로그에.
내가 누군가 말하는 것처럼 예기치 못한 에러를 만나면 그 자체를 성장의 발판으로 여기고 기뻐하며 달려드는 진성 (변태) 프로그래머가 되지는 못할 것 같다. 그렇지만 문제 상황을 맞닥뜨렸을 때 이를 이력에 기록으로 남길 기회로 받아들일 수는 있을 것 같다. 집안일을 싫어하지만, 용돈이 필요한 아이가 용돈을 벌 수 있다는 걸 알게 된 후로 집안일을 찾아다니게 되듯.
경험을 해 보았는가는 결국 문제들을 많이 해결해 보았는가로 귀결되는 것 같다.
프로젝트를 많이 해봤거나 서비스를 많이 런칭해보았거나를 경험으로 칠 수 있을 것이다. 거기서 뭔가 결과를 빠르고 능숙하게 생산해 낼 수 있는가 하는 ‘빠른 생산성’이라는 특성도 경험을 많이 한 사람의 특징이 될 수 있을 것이다. 하지만 뭔가를 그냥 만들라는 것은 신입이든 누구든 어느 정도 할 수 있을 것 같다. 도중에 아무 문제도 만나지 않는다는 전제 하에. 결국 ‘일 좀 잘하는 신입’과 ‘경력’의 차이는 이 문제 상황을 많이 맞닥뜨려봤고 그걸 해결해 보았는가에 있다고 할 수 있지 않을까?
회사에서도 왜 ‘경력’을 원하는가? 내가 회사가 안 되어봐서 다른 많은 사정들은 모르겠다. 하지만 왜 경험 많은 기술 이사를 회사에 스카웃하고, 전문가를 초빙하는가. 결국 그 많은 사정들의 핵심은 이러저러한 문제를 잘 해결해주기를 기대하고 바라서가 아닐까? 경험 많고 일 잘하는 사람이란 결국 그 일에서 나올 수 있는 문제들을 더 많이 접하고 더 잘 해결해 본 사람을 말하는 것 아닐까? 그렇다면 답은 나왔다. 작더라도 실제 업무에 맞닥뜨릴 수 있을 만한 문제들을 많이 겪고 해결해 봤다는 신입이 되면 되겠다. 얘가 진짜인지 아닌지 일단 뽑아서 써보자 하는 마음이라도 갖게 될 것 같다. 그렇게 개인적으로 해결해 본 경험이 회사에서도 통하도록 능력을 발휘해주면 따봉이고, 그렇지 못해도 다른 신입과 똑같이 가르치면 되니까 뭐 이런 생각으로. 그렇게 경력같은 신입이 혜성처럼 등장하여 회사와 함께 성장하게 되는데, 어느날… 하는 해피해피한 청사진을 그려본다.
너무 당연한 얘기들 같은데 왜 이런 얘기를 하냐면, 그동안은 트러블 슈팅 경험보다는 프로젝트 결과물이 더 내 이력에 핵심이라고 생각했기 때문이다. 그 생각이 지금 바뀌고 있다.
비전공자 신입으로서 포트폴리오 하나로만 취업을 노려야 하는 상황에서, 다른 건 내세울 여지가 없고 블로그 개발일지와 프로젝트 결과물들이 내 이력이라는 생각으로 공부하고 있었다. 프로젝트를 어떻게 해서 결과물이 나오는 건지와 협업이란 걸 경험해보기 위해서 스파르타 부트캠프에도 지원한 것이고.
그런데 CS 이론을 공부하던 중 ‘어느 정도의 이해도를 목표로 잡고 공부해야 하는가’하는 질문에 한 튜터님이 해준 대답이 생각의 발단이 되었다. 시간이 오래 걸리는 일이라는 것이다. 지식으로 받아들이고 외우기보다는 실제로 뭔가를 해보다가 문제를 만나서 그걸 꼬리에 꼬리를 물고 추적할 때 어차피 다 필요하게 되고 만나게 되는 지식이라고. 입사 면접 때 단골 질문이라는 이유로 공부하는 CS 지식이라면, 더욱 그냥 외운 사람과 실제로 문제로 맞닥뜨려본 사람의 대답이 다를 수 밖에 없다고. 꼬리 질문 들어가면 바로 털린다고.
내 생각에도 ‘HTTP와 HTTPS가 뭐가 달라요?’하는 질문에 대답을 하더라도, 그 이후로 한 단계만 더 들어간 질문에 대답하지 못하면 처음부터 대답하지 못할 경우와 그렇~게 큰 차이는 없을 것 같다. 첫 번째 질문에 대답할 수 있는 게 그래도 한 4~50% 큰 차이를 만들어 낸다면 정말 달달 암기라도 해서 가겠다. 하지만 꼬리 질문 두 번째에 바로 털린다면 아예 모르는 것과 한 10% 정도밖에는 차이가 없을 것 같고, 또 내가 그렇게 얕고 넓게라도 달달 외우는 데 강점이 없기 때문에 어차피 쓰지 못할 전략이 될 것이다.
결국 컴퓨터 공학적인 지식을 어느 정도로, 어떻게 의미있게 내 것으로 흡수할 것이냐 하는 문제는 튜터님 말씀대로 팀 프로젝트나 스터디 등에서 만나게 되는 문제를 추적하는 과정을 통해서 얻어내야 할 것 같다. 실제로 문제를 맞닥뜨려봐야 하기 때문에 ‘시간이 오래 걸리는 일’이라고 한 것일 테고.
그렇다면 여기서 문제, 어떻게 프로젝트를 빨리 만날까?
일단 부트캠프에서 기다리고 있는 팀 프로젝트가 서너 개쯤 있다. 어떤 문제가 생길 수 있을지 감도 잡히지 않지만 이 때를 기대해보기로 한다.
또 뭐가 있지? 프로그램 설치 관련 문제도 내 안에서 이슈가 아주 많다. 이런 것도 다 트러블 슈팅이라고 기록할 것이다. 최근에 알게 된 건데 이런 ‘가 외’ 같아보이는 문제들도 다 데브옵스에 들어가는 거더만. 뭐 틀릴 수도 있지만 과감히 다 데브옵스 과목이라며 트러블 슈팅 태그를 달고 올려버릴 테다.
그래도 범위는 좀 좁혀줘야 할 것 같다. 모든 하드웨어적인 문제, 예를 들면 모니터 두 대를 연결하여 쓰다가 하나를 떼고 컴을 켜니 저쪽 모니터에 가 있는 프로그램을 데려올 수가 없더라는 문제나 Zep을 엣지에서 실행하는 게 부하가 덜하냐, 크롬에서 실행하는 게 부하가 덜하냐를 알아보자(…)같은 문제까지 다 파고들 시간은 없을 테니. 음. 물론 유용도 하고 아주 나중에 쓸모있을 지식으로 연결될 수도 있겠지. 우연히 해결된 문제라면 짧게 기록하는 것도 나쁘진 않겠다. 하지만 지금은 범위를 더 좁혀서, 머지 않은 미래에 더 짧은 기간 내에 내게 유용할 ‘가까운’ 문제들을 먼저 만나고 해결하자.
결론 - 앞으로의 공부와 개발일지 방향 :
트러블 슈팅을 메인 먹잇감으로 삼되, ‘가까운’ 지식들을 더 타겟팅할 것.
사실 뭐가 가까운 시일 내에 필요한 지식일지 어떻게 판단하겠냐만은.
음. 회사에서 만났을 때 진짜 믿음직하고 감탄하게 될 것 같은 동료상을 그리고 닮기 위해 노력해볼까? …그러다 회사판 수퍼맨을 상상하고 있는 거 아닌가 몰라.
Uploaded by N2T