🙋‍♂️안내

이 글은 항해99라는 부트캠프를 시작하기 전 부터 마지막 주까지를 회고한 글입니다. 와주신 여러분께 너무도 감사하고, 저라는 사람이 어떤 사람인지 알아 볼 수 있는 글이니 편히 읽으시길 바랍니다.

공학도?

나는 컴퓨터공학도라는 꼬리표를 10년 이상 달고 있으면서도 컴퓨터공학을 실생활에 적용한 적이 드물다. 오히려 복수전공으로 택한 미디어나 광고같은 시적인 것들이 가미된 것을 즐기며 살았다. 가족들도 그러한 성향이 강해서 나도 그렇게 살아갈 줄 알았다.

하지만 생업을 유지해야 하는 시기가 오자 공학도라는 타이틀은 여러모로 쓸모가 있었다.

운이 좋게 3년간 계측기 시험교정일을 하면서, 한 켠으로는 일하고 있는 이 분야에 컴퓨터공학을 적용할 수 있을까는 생각이 항상 내 머리속에 들어왔다.

그러나 손을 놓은지 오래며 준비되어 있지 않았기에 어떠한 것도 적용할 수 없었다.

---

실상은...

사실 개발을 할 엄두조차 못하는 내가 너무 분하고 서러웠다. 대학동안 배운것은 너무나 얕았기 때문이다.

그렇게 다시, 조금이라도 내 전공을 적용해보고자 C언어 서적을 구입하고 그와 함께 내일배움카드로 스파르타코딩클럽 웹-앱종합반 강의를 신청하였다.

C언어나 HTML, JAVA만을 공부해봤던 대학생 저학년 수준에 머무르고 있던 나는, JavaScript와 React Native 강의를 경험하니 개발을 재밌게 그리고 효율적으로 할 수 있다는 것 알게 되었다. 객체지향의 신세계를 발견한 듯한 기분이었다.

그렇게 내 안의 개발에 대한 갈증은 더 커져갔고 수강 사이트 한쪽에 있는 부트캠프 모집글을 보고 많은 고민을 하였다. 기존의 커리어를 버리고 새로 쓰는 도전을 해야 하는가?

도전

현재까지 나에게 제일 영감을 주는 말은 스페이스X의 일론 머스크가 얘기하는 '인류의 지속 가능한 미래'이다. 내 인생 또한 지속 가능한 미래를 대비하고 있는가 물었을 때, 대답은 '아니오'였다.

그리하여 나는 내 인생을 지속 가능하게 그리고 더 흥미롭게 만들기 위해서 스스로 공부하는 멋진 일을, 처음부터 다시 시작해보자고 마음을 먹었다. 내 인생의 변환점을 만드는 도전을 해보자고.

나는 이것을 이해하고 있나?

부트캠프의 현주소는 잔혹했다. 강의를 들으며 주어진 과제들을 해결해 가보니 여기는 각자도생 서바이벌이라는 것을 깨닫게 되었다. 도태되면 사라진다. 계속해서 공부하라. 아무도 말은 안하지만 가슴에 너무나도 먹먹하게 자리 잡혀갔다. 스트레스가 이만저만이 아니고 새벽까지 계속 공부의 연속이었다. 그러나 정말로 문제인 것은 이렇게 해도 내가 이것들을 이해하고 있는가인 것이었다.

하지만 확실한 것은, 나는 계속해서 동기들과 으쌰으쌰하며 코딩을 계속 하고 있었다는 것이다. 주 100시간 이상씩 꾸준히 한다면 나중에는 정말 나중에는 복붙이 아닌 이해하며 코드를 짜게 되어있을거라는 멘토님들의 희망섞인 말과 함께 말이다.

주변에 친하게 지냈던 동기들이 하나 둘씩 하차를 할 때마다 많이 외롭기도 했지만 그럼에도 이 괴로운 과정을 끝내기는 싫었다. 괴로운데 왜 끝내기 싫었냐, 처음에 느꼈던 재밌고 효율적인일이 계속 눈앞에 나타나고 있었기 때문이다.

알고리즘과 리액트 주특기 그리고 CS스터디까지 해야 할 일들의 연속에서 How to를 배우는 것이 효율을 올리는 것이다는 깨달았다. 항상 내 한계치보다 그 이상을 요구하는 시스템에 빨리 적응하기 위해서 말이다.

또한 공부방법을 바꾸면 시행착오는 당연히 수반되었다. 9 to 25로 하루를 보내면서도 절대적인 시간이 부족하다 느꼈다. 그럼에도 프로젝트를 마치고 보면 가능한 결국 것들이었다. 어떤 것을 어떻게 배우냐의 차이를 실감했다.

협업

프로젝트로 들어오면서 백엔드와의 지속적인 소통과 협업을 하며 이제까지 경험 못 했던 협업의 즐거움을 알게 되었다. 프론트-백 어느 한쪽에서도 문제가 생기면 같이 몇 시간이고 해결하는 것에서 해결 하는 즐거움을 느끼게 되었다.

프론트엔드에서 분업을 어떻게 해야 일을 효율적으로 할 수 있는가도 알 수 있었다. 상하위 컴포넌트를 짜고 엘리먼트들을 나누며 어떻게하면 공통 분모안에서 잘 사용할 수 있을 지 의논한다. Github의 버전관리, 머지관리도 팀원들과 함께 정한다. 어느것 하나 혼자 하는게 없었다.

실전

6주간에 긴 프로젝트에서 놓치지 말아야 할 것은 내가 내 스스로 충분히 노력해서 과업을 이뤘는지 하루하루 돌아보는 것이었다. 동시에 하나 더, 프로젝트에 대한 주인의식이라 생각했다. 놓쳤던 때도 분명 있었다. 그럴 땐 팀원과 나의 과업의 양을 조절하거나 상담을 통해 팀이 나아가야하는 방향을 얘기했다.

디자이너분들과 회의를 하면서 기능구현 순서에 대해 너무 모르고 있었다는 것을 깨달았다. 앱 사용 플로우를 전체적으로 짜고 그 뒤에 와이어프레임을 짜야 했다. 아니 와이어프레임도 아니고 글로 적는 것부터 해야 했다. 앱에서 필요한 기능들을 세련되게 가공하는것은 좋으나, 필수 기능이 도중에 추가되어 MVP 스코프가 넓어져가서 점점 MVP 기한이 늘어만 갔다.

기술을 어떻게든 구현하는가가 먼저이긴 하지만 구현을 했다면 그것을 더 좋게 만드는 것도 기간이 늘어나는 이유 중 하나였다. 결국 늦게까지 후반기 작업을 하며 수정했던 모든 것들은 초반에 좌표설정을 제대로 했으면 조금이라도 줄일 수 있는 것들이었다.

마치며

이제까지 해왔던 계측기 교정은 기계의 메카니즘과 데이터의 선형성을 분석하며 의뢰 고객에 대한 서비스적인 마인드도 필요했다. 프론트엔드 개발도 다르지 않다고 본다. 기계의 작은부품처럼 작동하는 컴포넌트와 상태관리, 유저와의 최접점이라는 특성을 보면 말이다. 하지만 다른점도 있다. 교정은 최대한 표준과 같게끔 해야하지만 개발은 더 나아지기 위해 why라는 물음을 끊임없이 해야 된다는 것이다.

여러 취준생과 마찬가지로 여전히 내가 이 실력으로 더 나아지기 위한 wyh를 던질 수 있는지, 주니어 개발자로 취업하는 사람들은 대체 어느정도의 실력을 가지고 있는 것인지 궁금하고 걱정이 된다. 앞으로 남은 일주일 뒤에도 프로젝트를 새로 만들거나 인턴으로 입사를 하여도 이 생각은 계속 될 것 같다. 그러기에 초심을 잃지 말고 즐겁게 해나가는 수 밖에 없다. 그렇게 하고 싶다.