[장문장] 이제 C를 배우는 당신께
0.
일을 시작한 지 이제 2년 하고 절반이 되어간다. 아직 내 커리어가 어디로 튈지 모르겠으나, 항상 뿌리를 돌아보고 정리할 필요가 있다고는 생각했다. 경영학과 출신 비전공 개발자가 어떻게 개발자가 되었고, 어떤 일을 하고 있는지. 누군가는 꼭 듣고 싶어 할 이야기다. 그때의 내가 그토록 간절히 원했던 경험담이기 때문이다.
나는 어떻게 개발을 시작하게 되었나
3학년 1학기를 마치고 휴학을 하면서 하반기에는 셰어하우스 우주라는 사회적 기업에서 인턴을 했다. 그전까지는 1년 동안 조직/전략 학회를 했었고, 아산나눔재단이랑 동아비즈니스리뷰에 케이스 스터디도 올리고 학회장으로 있을 만큼 인사/조직 관련된 비전이 확실했다.
첫 인턴은 서비스 관리 직무여서 엑셀을 다룰 일이 굉장히 많았는데, 회사 엑셀이 꽤나 화려한 수식들로 관리되고 있었다. 매크로나 VBA 같은 코드가 들어가는 건 아니었지만, 데이터셋을 넣어서 자동으로 자료가 출력되는 시스템을 구현한 건 충분히 매력적이었다.
나는 틈틈이 그분이 만든 자료를 공부했고, 인턴을 마칠 때쯤은 내가 만든 수식으로 매일 보고가 올라갔다. 엑셀 수식으로 보고서 만들기. 이게 나의 첫 개발이었다.
인턴을 마치고 당시 후배(이하 후니)가 회장으로 있던 멋쟁이사자처럼에 지원했다. 웹 개발 베이스의 창업 동아리였다. 내 지원동기는 다음과 같다.
툴을 다룰 줄 아는 사람과 모르는 사람의 생산성 차이가 크다. 근미래에는 커스텀 코드를 넣을 수 있는 생산성 툴이 보편화될 것이다. 당시 구글 스프레드 시트에도 이미 JS 코드를 실행할 수 있었다.
경영학과에서 말로만 문제-해결책을 구성하고, 실제로 무언가를 생산할 수 있는 능력이 없는 데 질렸다. 내가 해결책이라고 생각하는 것이 실제로 문제를 해결하는 장면을 보고 싶다.
미래에 창업을 하고자 한다면, 서비스에 맞닿은 기술을 모르는 것은 큰 진입장벽이 된다. 적어도 개발자들과 이야기할 수 있는 수준의 지식이 필요하다.
엑셀 좀 만져봤는데 재미있기도 하고, 잘하기도 한다.
이 당시만 해도 개발자가 되겠다는 생각은 없었다. 복수전공도 안 하고 개발자가 된다는 건 그닥 현실적인 목표가 아니고, 주변에 그런 생각을 하는 사람도 없었다. 그저 내 역량을 하나 더 가져가려는 정도였다.
그래서 개발자가 되기까지.
멋쟁이사자처럼 첫 수업은 대략 다음과 같은 내용이다. “뷰의 post는 비둘기를 보내는 것이고 비둘기가 params안에 있는 정보를 들고 컨트롤러로 갑니다. 그럼 컨트롤러에서는 뷰에서 보낸 비둘기와 그 안에 있는 params를 확인할 수 있어요.” 지금 보면 MVC에 대한 꽤 정확한 비유지만, 당시에 이해하기는 쉽지 않았다. 여튼 이런 수업을 들으면서 3개월을 보냈고, 여름방학에 후니와 함께 마케팅 실험신청 페이지를 만들었다. 학과에서 개발비를 받으면서 진행한 첫 웹서비스였다. 물론 개발은 후니가 주도하고, 나는 보조만 했다. 덕분에 프로덕션 레벨 개발을 해본 점은 매우 유익한 경험이었다.
2학기가 되고 나는 멋사의 부회장이 되었고, 1학기부터 팀을 꾸려서 진행하던 플랫폼 서비스는 개발을 완료하고 고꾸라졌다. 생각해보니 누구도 플랫폼을 운영할 사람이 없었다. 만듦새가 조약한 건 둘째 치고, 애초에 대학교 2, 3학년이 3년씩을 존버해서 플랫폼 비즈니스를 한다는 건 말이 안 되는 일이었다. 그러니까 기획부터 실패한 프로젝트였던 것이다.
어떤 활동을 했다면 결과물이 나와야 하고, 결과물이 없다는 그것은 아무것도 한 게 아니다. 따라서 지난 1년을 헛된 것으로 만들지 않으려면 겨울방학 3개월 남짓에 빠르게 만들고, 운영을 하지 않아도 저절로 팔리는 서비스를 만들어야 했다. 그렇게 만든 것은 스클럽이었다. 신입생이 들어오는 시즌에 맞춰서 학교 동아리나 학회를 소개하는 웹서비스는 데이터만 있다면 빠르게 만들 수 있고, 딱히 마케팅을 하지 않아도 풍운의 꿈을 안은 신입생들이 하루에도 열 번씩 들어올 것이라고 생각했다. 그렇게 고작 3명이서 3개월 만에 서비스를 만들었고, 스클럽은 기대하던 대로 3천 명의 사용자를 끌어냈다. 기획의 승리였다.
하지만 그 당시에도 개발자가 된다는 생각은 해본 적이 없었다. 동아리 사람들보다 내가 더 열성적이기도 하고, 잘하기도 했지만, 역시 학위도 없고 알고리즘도 해본 적 없는 내가 개발자로 일한다는 상상은 못 했다. 위의 스펙으로 서비스 기획 쪽으로 갈까, 아니면 인사전략 쪽으로 쓸까 고민을 하고 있었다. 자신만만하던 나는 라인 서비스 기획 인턴에 서류조차 못 붙는 기염을 토하고, 인사 인턴은 공고 하나 없었다. 가까스로 선배의 추천으로 판교의 IT회사에서 인사 인턴을 하게 되었다. 거기서 나는 내가 생각하던 인사/조직/전략과 실제 인사 업무의 괴리감을 느꼈다. 내가 느낀 바는 다음과 같다.
인사 제도는 매우 민감해서 보수적 운영이 요구된다. 따라서 새로운 것을 만드는 일은 적고, 기존 시스템을 유지하는 것이 대부분의 업무다.
다른 무엇보다 실수가 없는 것이 중요하다. 창의성보다는 꼼꼼한 사람이 유리하다.
개인간의 경쟁력을 비교하기 어렵고, 자기 분야를 파고들거나 커리어를 그리기 어렵다.
나는 주로 면접 진행 보조를 맡았고, 특별하게는 대표님 훈화 말씀을 정리해서 소책자로 만드는 일을 했다. 그냥 다 때려치우고 1년 동안 알고리즘 공부나 해서 개발자로 취직해야겠다-라는 생각이 들었다. 그 와중에 SCSA 라는, 비전공자를 뽑아 6개월 동안 교육을 시킨 후 개발자로 채용하는 공채를 발견하고, 써서, 붙었다. 회사에 들어와서 알게 된 것이지만 컴공에서는 팀플도 거의 없고, 과제 코드 이상으로 코드를 짜서 서비스를 해보는 경우는 거의 없다. 그런 점에서 내가 실제로 서비스를 처음부터 끝까지 개발하고, 서비스해보았다는 것은 컴공 안에서도 특기할만한 스펙인데, 이걸 비전공자가 했으니 당연 SCSA라는 공채에서는 주목받을만했다. SCSA는 “컴공 4년을 6개월 만에 땐다”라는 모토의 스파르타 교육이었고, 합격자들은 입사예정자 신분으로 6개월 동안 8 to 22 교육을 받으며 매주 시험을 쳐야 했다. 전체 시험의 절반을 통과 못하거나, 마지막 알고리즘 시험에서 탈락하면 입사는 취소라는 나름의 필터링도 있었다. 교육과정은 컴퓨터 공학보다는 알고리즘에 치중되었고(누군가의 실적이므로), 나는 무난하게 모든 과정을 통과하고 입사를 해, 선행연구센터에 들어오게 되었다.
SW 개발자의 직무
개발자의 직무는 보는 각도에 따라 다양하게 이야기할 수 있다. HW에 가까운 쪽을 펌웨어, 혹은 임베디드 개발이라고 부르며, 네트워크 개발자가 있다면 네트워크 레이어에 따라서 2 계층 ~ 5 계층 정도로 구분한다. 서비스 개발자는 앱/웹으로 나뉘고, 또 프론트와 백으로 나뉜다.
최대한 실무적으로 분류를 해보자면 다음과 같다.
서비스(웹, 모바일, 응용), 서버(+DB), 네트워크, 보안, 임베디드, AI, 연구
이 중 내가 하는 것은 연구다. 연구의 특성은 다음과 같다.
당장 상용화할 수 있는 응용이 아닌, 미래에 필요하다고 판단되는 기술의 성능 및 구현 가능성을 판단
PoC(Proof of Concept, 기술이 주장하는 개념을 증명하는 시연)를 통해서 기술을 증명
논문, 특허 등의 산출물
정확하게 말하면 내가 하는 일은 5G 향 MEC 연구로, 네트워크 분야이다. 사업부에서 SKT, KT 등 통신사에 판매할 네트워크 장비를 생산한다면, 연구소에서는 사업부에서 3년 정도 뒤에 상품화할 수 있는 개념, 기술 등을 미리 시도하여 현재 성능과 한계 등을 파악하는 역할을 한다. 대부분의 경우 학사 출신이 이런 연구조직에 들어올 일은 없다. 나도 내가 왜 여기로 배치됐는지 잘 모르겠다. 보안이 무서워서 현재 업무를 상세하게 말할 수는 없지만, 각기 다른 망에 있는 두 서버 간 서비스를 끊김 없이 옮기는 기술을 연구하고 있다.
대부분의 개발자들이 하게 되는 것은 서비스 개발이다. 대기업, 스타트업 가릴 것 없이 일자리도 많고, 다른 직무에 비해 진입장벽이 낮아서 비전공자나 국비교육생들에게 많이 추천하는 직무다. 하지만 진입장벽이 낮다는 것은 그만큼 전문성이 없다는 뜻이고, 경쟁이 치열하기도 하다. 경영학과 졸업자로서 정체성을 유지하고 싶다면 서비스 직무에서 일하는 것이 좋은 시너지를 일으킬 것이다. 보안, 임베디드, 네트워크 같은 누구나 기피하는 업무를 파는 것이 오히려 기회를 잡을 수 있지만, 이런 분야는 독학이 어렵다는 문제가 있다. 일정 수준 이상으로는 장비가 필요한 경우가 많기 때문이다.
꼭 개발자가 될 필요는 없다. 서비스 기획이나 운영 쪽으로 가더라도 개발 지식은 상당히 많은 도움이 된다.
개발자가 역량을 쌓는 방법
어느 정도 기초가 쌓였다는 전제 하에 제안을 하자면 다음과 같다. (나도 다 해본 건 아니다)
알고리즘
모든 기업이 알고리즘 시험으로 1차적인 테스트를 진행한다. 따라서 알고리즘 공부는 선택이 아닌 필수다.
알고리즘을 잘한다는 것은 하나의 언어에 대한 이해도가 높고, 복잡한 시스템을 생각하면서 동작하는 코드를 짤 수 있음을 의미한다.
요새 내 주변에서는 리트코드를 많이 사용한다.
공공활동
오픈소스/커뮤니티 활동이다.
오픈소스 컨트리뷰터가 되면 기본적으로 코드 퀄리티, 코딩룰에 대한 이해가 있다는 의미고, 협업을 위한 깃 사용법, 문서화 등에 대해서 인정받는 것이다.
스택오버플로우 같은 커뮤니티에서 답변을 하는 것도 좋은 공부가 된다. 원래 남 가르치려면 많이 알아야 한다.
블로그
문서화 역량을 키울 수 있는 중요한 작업이다.
현업 개발자들 중에서도 문서를 잘 작성하지 않으려고 하고, 또 작성할 능력이 없는 사람들이 있다.
개발이라는 복잡한 작업을 협업하는데 문서화는 매우 중요한 역량이고, 꼭 블로그가 아니라도 본인이 아는 지식을 문서로 타인에게 전달할 수 있는 역량은 있어야 한다.
서비스
직접 서비스를 해보는 것만큼 좋은 것은 없다. 대부분 이걸 하지 않는데, 왜냐면 할 수 없기 때문이다.
컴공 출신 중에서도 서비스를 해본다는 생각조차 안 한 사람이 태반이다. 오히려 이런 부분에서 비전공자들이 유리하다.
물론 기획/개발/운영 삼박자가 갖춰지지 못하면 시간낭비만 하고 쪽박 차는 것이다.
아무리 작은 서비스라도 총체적이기 때문에, 어디서든 스펙으로 써먹을 수 있는 아주 유연한 소재가 된다. 스클럽을 만든 나와 디자이너는 다음 해 같은 회사에 취직했다.
