소프트웨어 개발자가 되기까지
평범한 소프트웨어 개발자의 좌충우돌 이야기
프로그래밍을 즐겨야 한다.
문득 처음으로 소프트웨어 개발자로 제대로 된 일을 시작하게 된 것이 언제인지 생각해보니, 벌써 십수 년이 지났다. 필자가 학교에 다닐 시절에는 이공계 기피 현상이 있었고, 소프트웨어 개발은 3D 업이라고 천대를 받던 시점이었다. 그런데 시대가 변했다. 요즘은 4차 산업 혁명이다, 인공지능이다, 하면서 초등학생들까지 코딩 교육을 시킨다고 난리다. 정부에서도 소프트웨어 중심 대학을 늘리고, ‘소프트웨어 교육 활성화 기본 계획’까지 세우면서 소프트웨어 강국을 만들겠다는 야심 찬(?) 포부를 보이고 있다. 이렇다 보니 소프트웨어와 관련이 없는 사람들조차도 소프트웨어에 대한 관심이 예전에 비해서 현저히 높아졌고, 심지어는 전공 불문하고 소프트웨어 개발을 업으로 삼고자 하는 사람이 많아지고 있는 추세이다.
필자는 소프트웨어 개발 업계에서 잘 알려진 사람이 아니다. 누군가처럼 전 세계에서 사용되고 있는 오픈 소스를 개발한 것도 아니고, 특정 기술을 특출 나게 잘 알고 있거나 수많은 개발자들이 흠모하는 개발자는 더더욱 아니다. 하지만, 대한민국 소프트웨어 개발의 큰 축에 속하는 회사에서 근무하면서 다양한 경험을 해 보았고, 누군가의 문제를 시원하게 풀어주는 소프트웨어를 개발하는 일을 무척 좋아하고 사랑하며, 척박한 대한민국의 개발 문화를 더 나은 것으로 만들기 위해서 노력하고 있다. 그리고 필자가 겪은 경험들이 프로그래밍 분야에 들어가기를 희망하거나 이제 막 커리어를 시작한 사람들에게 조금이라도 도움이 될 수 있지 않을까 하는 생각이 들어 글을 쓰기 시작했다.
본 글은 필자의 개인적인 경험담이며 주관적인 입장이 많이 포함되어 있다. 필자의 경험이 모든 개발자가 겪는 일반적인 것은 아니라는 것을 감안하였으면 한다. 그럼 시작해보자.
컴공 주변인, 프로그래밍이 재미있어지다
필자는 컴퓨터 프로그래밍이 좋아서 밤새 대학교 컴퓨터실에 코딩을 했던 빌 게이츠 같은 사람은 절대 아니다. 어린 시절, 컴퓨터가 주변에 있기는 했지만, 프로그래밍보다는 간단한 게임을 더 좋아했다. 국어보다 수학, 과학을 상대적으로 더 좋아했기에 자연스럽게 이과에 진학했고, 대학 전공을 선택할 때는 수능 점수가 가용한 수준의 대학의 “공학부”에 입학을 하였다. 필자의 학교는 580명 정도의 공대로 진행하는 학생들을 세부 전공이 정해지지 않은 채로 처음 1년간 “공학부”에 입학시켰고, A반부터 O반까지 이름순으로 40명씩 잘라서, 2개 반을 공대에 있는 각 과에게 배정을 하였다. “김씨”였던 A, B반 입학생들은 (내 기준으로) 운 좋게 “컴퓨터 공학과” 선배들을 만날 수 있었고, “조씨”여서 M 반에 소속된 필자는 “식품 공학과” 선배들과 1년을 보냈다. 지금 생각해보면 참으로 안타까운 일이 아닐 수 없었다. (이러한 공학부 체제는 바로 다음 해에 없어졌던 것으로 기억한다.)
대학교 2학년부터는 전공을 선택하여 전공 수업을 듣기 시작하였다. 평소에 관심 있었던 “컴퓨터 공학”을 선택했고, 컴퓨터 구조론, 알고리즘, 데이터 구조론, 프로그래밍 등의 수업들을 듣기 시작했다. 지금 생각해보니, 대학 입학 시에 처음부터 컴퓨터 공학과였던 “김씨” 친구들은 이미 많은 것을 알고 있었고, 선배들과 유대관계도 좋았으며, 랩 활동도 이미 하고 있어서 소외감을 느꼈던 것 같다. 그런 상황들이 필자를 학과 생활에 집중을 하지 못하고, 1학년 때부터 빠져있던 동아리 생활에만 치중하도록 만들었던 것 같다. 대학교 2학년을 마칠 때까지 필자는 “컴퓨터 공학” 전공생으로서는 낙제점을 받은 학생이 분명했고, 학과의 주변을 그저 맴돌기만 했었다. 필자는, 그 당시에는 흔히 말하는 ‘주변인’이었다.
휴학을 하고 군대를 가려고 했다. 남들처럼 ‘군대 갔다 오면 정신 차리고 공부에 집중할 수 있겠지’라는 생각이었다. 하지만 군대가 너무나도 가기 싫었다. 결국, 필자는 ‘진정한 소프트웨어 개발자가 되기 위해서는 반드시 군대 대신 병역 특례 업체에서 일을 해야 한다’라는, 다소 엉뚱한 자기 합리화에 빠져서 군대를 가지 않고 복학을 했다. 형편없는 학점을 채우기 위해서 전략적으로 학점관리를 하기 시작했고, 1, 2 학년 때 학점이 좋지 않았던 과목들을 모두 재수강하거나 학점을 포기하면서 학점을 끌어올리기 시작했다. 그런데 희한하게도 다른 과목들은 점수가 대부분 형편이 없었지만, 프로그래밍 관련 수업 들은 대부분 학점이 높았다. 그래서 필자는 3, 4학년 때 모든 학기에 프로그래밍 관련 수업을 더욱 적극적으로 수강하기 시작했다. 그렇게 C, C++, VC++, 자바* 등을 배우기 시작했다.
프로그래밍을 배우는 것은 쉽지 않은 일이었다. 특히 1, 2 학년 때 놀던 필자에게 주어졌던 프로젝트형 과제는 매일 밤을 새우게 만드는 것들이었다. 모르는 것을 묻기 위해 랩실에 있는 후배한테 쪽팔림을 무릅쓰고 물어보기도 하였고, 필자가 자신이 없던 과목의 과제를 하기 위해 선배의 소스 코드를 베껴서 제출했다가 조교에게 걸려 반성문을 쓴 적도 있었다. 하지만, 확실한 것은 프로그래밍을 하는 시간만큼은 답답함의 연속임에도 불구하고, 무척이나 흥미롭고 즐거웠다는 것이다. 원하는 결과를 얻었을 때의 짜릿한 쾌감은 이루 말로 표현할 수 없는 값진 기쁨이자 행복이었다. 특히, C++로 네트워크 프로그래밍*을 하다가 JAVA로 FTP* 프로그래밍을 하는 순간, 깨달았다. 이 녀석과 당분간 인생을 함께 할 것이라고..
대학을 졸업할 때까지 병역 특례 업체를 알아보았지만, 정부가 병역 특례 인력을 급감하던 시기라 자리를 찾을 수가 없었다. 결국, 병역의 의무를 다하기 위해서 다른 방법들을 찾아보았고, 우연히 군대에서도 소프트웨어 개발을 하는 병사들이 있는 것을 알게 되었다. 이름하여 “S/W 개발병”. 핵심 기술 특화병으로 그 당시 “육군 전산소”와 같이 군 관련 소프트웨어를 실제로 개발하는 곳이었다. 딱, 필자가 원하던 것이었다. 컴퓨터 공학 학사 학위증과 이력서를 제출하여 1차 서류 전형, 2차 면접 전형을 통과하였고, 졸업 후 2 개월 뒤에 입대를 하게 되었다. 이때가 바로, 필자의 소프트웨어 개발 생활의 시발점이다.
군대에서 시작한 소프트웨어 개발
군대에서 하는 소프트웨어 개발이라 수준이 낮지 않을까 하는 생각이 들 수도 있겠다. 실은 필자도 그런 생각을 군 생활 내내 했다. 사회에 나가면 이것보다는 나을 줄 알았다. 하지만 나중에 생각해보니, 사회가 오히려 더 난잡(?) 한 경우도 많았다. 군대에서 직접 개발하는 것에는 몇 가지 유형이 있었는데, 보안상 민간 기업에 공개하기 어렵거나 비용 문제로 외부 리소스를 활용 못 하거나, 외부 리소스를 활용할 만큼 규모가 되지 않는 경우 등이었다. 보안상 자세히 이야기하지는 못 하지만, 전쟁 상황에서의 시뮬레이션*을 돕는 소프트웨어, 군내 프로세스를 개선하거나 휴먼 오류로 인해 발생하는 인명 사고를 줄이는 소프트웨어도 있었고, 병무청 홈페이지나 예비군 홈페이지를 개발/운영하는 업무도 있었다. 군 특성상 업무의 범위가 정해져 있어 변수가 적었다. 그래서 오히려 사회에서의 개발 업무보다 명확하고 간결한 경우가 많았다. 그래서 프로젝트들은 꽤나 할만했다. 하지만 문제는 있었다. 바로 사람이었다.
필자가 담당한 첫 프로젝트는 이미 망가질 때로 망가진 레거시* 시스템이었다. 처음에는 외주 용역*을 맡겼다고 했지만, 알고 보니 그것도 다른 큰 프로젝트를 하나 하면서 무료로 만든 것이었다. 해당 시스템은 전시 훈련 상황 시 최소한 반나절에 한 번은 데이터를 갱신해야 하는 시스템임에도 불구하고 필자가 처음 인수인계를 받은 시점에 계산을 하는 로직을 한번 실행하면 무려 3일 동안 돌았다. 그야말로, “쓸 수가 없는 시스템”이었던 것이다. 그 당시에 해당 시스템을 담당했던 중령님은 정말 의사소통하기 어려운 분이었다. 말의 앞뒤가 맞지 않았으며, 무언가 막히면 “국가에 충성을 다해야 하지 않나”라는 식의 논리만을 펼쳤다. 주변 사람들에게 자주 소리를 질렀고, 남의 이야기는 잘 듣지 않았던 분이었다. 이분의 자리는 다른 분으로 교체되기에 이른다. 만약, 이 분과 군 생활 내내 프로젝트를 함께 진행했었다면, 아마 필자는 소프트웨어 개발을 업으로 삼지 않았을지도 모른다.
새로 부임한 중령님은 완전히 다른 분이었다. 굉장히 논리적으로 의견을 펼쳤고, 의사 전달도 분명하고 꼼꼼하게 하였으며, 일개 병사인 필자의 목소리에도 귀를 기울였다. 결국, 이 분은 필자가 생각하는 개선 방법을 따르기로 결정하였고, 시스템을 처음부터 다시 개발하기 시작했다. 개발 언어, 데이터베이스*, 개발 도구 및 방식 모두 변경하였다. 결국, 7개월 만에 수년 동안 끝을 보지 못했던 프로젝트가 성공적으로 마무리되었다. 기존에 3일씩 걸리던 연산 속도는 1차적으로는 13시간으로, 최종적으로는 4시간 30분 정도로 단축이 되었고, 전시 훈련 시 장군들이 모여있는 지하 벙커의 대형 모니터에 필자가 만든 시스템이 메인 화면을 장식하게 되었다. 또한, 군수참모부 부장 표창을 받게 되었고, 꿀맛과도 같은 포상 휴가를 다녀오기도 하였다. 필자에게는 무척이나 큰 성취감과 자신감을 불어넣어준 일이 아니었다 싶다.
이외에도 2개 정도 프로젝트를 수행했고 2년이라는 시간은 금세 지나갔다. 초보 개발자였던 나는 자바라는 언어로 여러 유형의 시스템을 처음부터 끝까지 직접 개발할 수 있었고, 개발을 도와주는 도구들이나 프레임워크*에 대한 감을 잡을 수 있었다. 특히, 프로젝트를 진행하면서 사람과 사람 사이에 일어나는 다양한 상황들을 경험했으며, 좌절감과 성취감을 모두 경험할 수 있었던 좋은 기회였다. 그리고, 야간 근무 시에 만났던 외부 업체의 기술 지원 인력들과의 대화들도 도움이 많이 되었다. 사용자가 없는 야간에 차가운 서버실에서 외롭게 작업을 하던 분들은 한사코 이 세계에 발을 들이지 말라고 하였지만, 필자 눈에는 어려운 문제를 풀어나가는 그분들이 멋져 보이기만 했다. 이러한 경험은 전역과 함께 사회에 첫 발을 디디는 데 지대한 영향을 미쳤다. 특히, 스스로 이 일을 업으로 삼겠다는 확신을 얻었기에, 필자 인생의 가장 중요한 시점이었다고 생각한다.
소프트웨어 개발을 향하여
전역 후 바로 H사의 해외 금융 기술팀에 입사하여 6개월 정도 일을 하였지만, 고객사의 자금 사정으로 출국이 미뤄지면서 희망했던 프로젝트에 투입되는 시기가 계속 지연되고 있었다. 일을 제대로 시작하지도 못하고 있어서 조바심이 났다. 가장 혈기왕성한 신입 사원 시절을 일다운 일 하나도 못 해 보고 지나가는 것 아닌가 하는 생각도 들었고, 실제로 그 프로젝트에서 사용하던 기술들은 개발 도상국에서 사용하는 시스템 개발이었기에, 필자가 사용하던 기술보다도 시대에 많이 뒤떨어져 있었다. 그래서 이직을 결심하고 S사 방법론 팀으로 회사를 옮기게 된다.
군 시절 스트럿츠*와 같은 프레임워크에 관심이 많았기에, 프레임워크 팀으로 배정이 되기를 바랐지만, 해당 팀에 자리가 없었기에 같은 센터 산하의 옆 팀인 방법론 팀으로 발령을 받았다. 이 곳에서는 전사 표준 방법론에서 제공하는 통합 개발 환경의 기술 지원이 주 업무가 되었고, 전국에 있는 관계사와 외부 프로젝트에 돌아다니면서 소스 버전 관리나 품질 관리를 도와주는 도구들에 대한 교육 및 기술지원을 주로 하게 되었다. 개발이 하고 싶었기에 프로젝트에서 필요한 지표들을 웹 애플리케이션으로 개발하여 제공하곤 했지만, 군대에서 하던 기술을 그대로 재활용하는 것은 무척 지루한 일이었다. 그리고 개발할 시간도 무척 부족했다. 결국, 팀장에게 프레임워크 팀으로 전배 요청을 했고, 입사 2년 만에 팀을 옮기게 된다. 입사 시에 이미 2년의 실무 경험이 있었기 때문에 출발선부터 동기들과 개발 역량에서 차이가 있었다. 심지어는 선배들과도 비교가 되곤 했었다. 실은 입사한 지 얼마 되지 않은 신입사원이 지금 하는 일이 맞지 않으니 전배를 보내달라고 하는 것은 그리 달갑지 않은 일이다. 업무를 제대로 파악하기도 쉽지 않은 시간이기 때문이다. 하지만, 필자는 그저 새로운 기술을 배우고 개발을 하고 싶었고, 사용자가 잘 사용하는 제품을 만들고 싶었다. 그리고 그 뜻을 이루기 위해서 적극적으로 의사 결정권자에게 어필을 하였고, 결국 원하는 곳에서 원하는 만큼 개발을 할 수 있었다. 이후 필자는 S생보사 차세대 프로젝트 2년, S전자 제조 시스템 프로젝트 3년을 수행하면서 스프링이라는 프레임워크를 만나게 되었고 프로젝트의 시작부터 끝까지 전체 과정에 깊이 참여할 수 있었다. 정말 원 없이 개발을 할 수 있게 되었다. 그렇게 지금까지 나름대로 만족하는 개발자로서의 커리어를 걸어왔다. 돌아보니 정말 우여곡절이 많았다.
소프트웨어 개발자가 되기 위해 필요한 것
필자의 사회생활 초반 이야기를 길게 했다. 학창 시절부터 프로그래밍을 본격적으로 시작해야겠다고 결심을 하게 된 계기, 그리고 이를 구체화하고 발전시켜온 과정까지 말이다. 지금 필자가 이렇게 십수 년 동안 이 일을 계속, 또 즐겁게 할 수 있는 이유에 대해 설명하려면 필요한 이야기들이었다. 그리고 자연스럽게 소프트웨어 개발자가 되고 싶다면 어떤 경험을 해야 하고, 어떤 마음가짐을 가져야 하는지도 알게 되었다.
위 이야기를 정리하자면, 필자가 생각하기에 소프트웨어 개발자가 되기 위해서 기본적으로 필요한 것은 아래와 같다.
첫째, 프로그래밍 경험이다.
필자의 경우, 학창 시절 프로그래밍에 큰 관심을 두지 못했기에 경험을 쌓기 시작한 시기가 늦었지만, 대학에서의 프로그래밍 경험과 S/W 개발병으로 군 생활을 하면서 값진 경험을 할 수 있었다. 덕분에 소프트웨어 개발자로 사회생활을 시작하기에 다소 부족했던 경험들을 채울 수 있었다. 그리고 그 경험들은 정말 많은 측면에서 도움이 되었다. 그저 이론적인 지식을 배우고 실습해 보는 것과는 달랐다. 취업을 하는 데 있어서도 회사들은 ‘반드시’ 프로그래밍 경험을 검증하려 했고, 실제로 필드에 나가서도 경험이 많으면 많을수록 업무를 더욱 능숙하게 처리할 수 있었다. 그리고 개인적으로도 이 일을 업으로 삼겠다는 강한 동기부여가 되어주었다. 대학 시절의 프로그래밍 경험, 군대에서 경험한 두어 개의 소프트웨어 개발 프로젝트는 필자의 업을 결정하게 해 준, 개발자로서의 커리어를 탄탄히 이어나가게 해 준 일등공신이다.
둘째, 프로그래밍이 즐거워야 한다.
소프트웨어 개발에 있어 프로그래밍은 빠질 수 없는 영역이다. 물론, 일부 업무는 프로그래밍 자체를 주로 하지 않을 수도 있다. (기획자, 프로젝트 관리자, 시스템 운영 등) 하지만, 이러한 업무들도 소프트웨어를 개발하는 곳에서 이루어지는 것이라면, 기본적으로 프로그래밍을 할 수 있어야 하고, 그 과정 자체를 즐거워해야 한다. ‘무조건’ 말이다. 가령, 필자의 대학 시절, C++로 네트워크 프로그래밍을 하다가, 자바로 개발을 하였을 때 느꼈던 감정이나 즐거움은, 지금도 필자가 새로운 언어나 기술을 배우는 과정을 즐겁게 만들어주는 소중한 원동력이다.
소프트웨어 개발은 눈에 잘 보이지 않는 것을 추상화하고 일반화하여 구체적으로 구현해 세상에 없던 제품을 만들어내는 일이다. 무척 어려운 일이다. 안타깝게도 국내에서는 이 일이 단순한 일이라고 생각하는 경향이 강하다. 하지만 그렇지 않다. 생각해보자. 종이에 그림을 그리는 것이 쉬운가, PPT에 그림을 그리는 것이 쉬운가, 아니면 웹 브라우저에서 보이는 화면을 개발하는 것이 쉬운가. 종이에 그린 그림을 수정하는 것은 쉽다. 하지만, 시간을 들여 만든 화면을 고치는 비용은 만만치 않다. 코딩이라는 행위 자체가 소프트웨어 개발의 전체 과정을 보았을 때, 매우 어렵고 비싼 행위인 것이다.
이러한 일이 기본적으로 즐겁지 않다면, 소프트웨어 개발을 업으로 삼기에는 무리다. 평생을 ‘즐겁지도 않고 어려운 일’을 하면서 살고 싶은 사람은 아마도 없을 것이다.
셋째, 작더라도 성공의 기쁨을 느껴야 한다.
프로그래밍이라는 행위는 개발자가 원하는 소프트웨어를 만들어가는 과정이다. 하나의 제품을 처음부터 끝까지 만들어보는 일은 그냥 책만 읽어서 되는 것이 아니다. 직접 만들어봐야 한다. 부담되는가? 혹시, 너무 거창한 것만을 생각하고 있지 않은가? 소프트웨어 개발자가 되고 싶다면 아주 간단한 것이어도 상관없으니 처음부터 끝까지 본인의 힘으로 소프트웨어를 개발하여 마무리까지 해보자. 본인의 이력서를 담고 있는 웹 버전의 프로파일이 될 수도 있고, 본인 컴퓨터에서만 돌아가는 계산기나 메모장 같은 것이 될 수도 있겠다.
소프트웨어 개발을 업으로 삼으려는 사람이라면, 본인이 만든 소프트웨어가 제대로 동작할 때 엄청난 성취감과 뿌듯함을 느끼게 될 것이다. 그래야 한다. 필자도 군대에서 레거시 시스템을 신규로 성공적으로 전환하고 포상을 받으면서 느낀 적 없던 뜨거운 성취감을 얻었다. 그리고 이는 추후 사회에서의 프로젝트에서도 성공하고자 하는 강한 동기를 부여해주었다. 만약, 산을 다 올라갔는데도 “어차피 내려갈 거 왜 올라왔지?” 혹은 다음 산을 올라갈 때 “또 올라가야 돼?”라는 식의 감정이 든다면, 소프트웨어 개발자의 길을 다시 한번 생각해보기 바란다.
넷째, 주위에 귀를 기울여라.
소프트웨어 개발 세계에서는 기술이 정말 빠르게 진화한다. 새로운 기술이 매일매일 쏟아져 나온다. 그런 기술들을 모두 섭렵하는 것은 불가능한 일이다. 하지만, 적어도 기술 트렌드에는 민감해야 한다. 현재 본인의 기술이 어떻게 바뀌고 있고, 어떤 프레임워크나 도구들이 입에 오르고 내리는지 파악하고 있어야 한다. 필자가 군대에서 사용했던 기술이나 사회에서 쓰고 있는 개발 기술 모두 해당 시점에 주변에서 가장 많이 사용하는 기술이었다. 그런 기술은 이미 검증도 많이 되었고, 주변에 참고할 자료도 많을 것이고, 그 기술을 사용할 수 있는 개발자를 찾는 것도 수월하다.
필자가 처음 개발을 시작할 때는 “소셜 네트워크”나 “스마트폰” 따위는 없었기 때문에 정보를 수집하는 것 자체가 쉽지 않은 일이었지만, 지금은 무척이나 쉽게 새로운 고급 정보를 접할 수 있다. 인지도가 높은 기술 사이트의 뉴스레터를 구독하거나, 어느 정도 이름이 알려진 개발자의 소셜 네트워크를 찾아서 팔로우만 하더라도 도움이 될 것이다. 이를 통해서 감각을 잃지 말고, 관심 있는 기술들을 지켜보면서, 새로운 기술들도 꾸준히 배우고 실무에 적용해야 할 것이다. 만약, 한 가지 기술만을 배워서 은퇴할 때까지 계속 사용할 것이다라는 생각을 하고 있다면, 이 또한 이 업으로의 진입을 심각하게 고민해야 할 것이다.
다섯째, 본인이 원하는 것을 찾아라.
위에서도 언급했지만, 기술이 도처에 널렸다. 모든 것을 다 배울 수는 없다. 그런데, 각자에게 맞는 기술이라는 게 있다. 이는 본인 성향이나 업무 하고도 밀접하게 관련이 있다. 일반적으로 눈 앞에 보이는 것을 개발하는 프런트 엔드 영역을 개발하는 기술들과 뒷단에 눈으로 보이지 않는 곳에서 바쁘게 돌아가는 로직을 담당하는 백 엔드 영역을 개발하는 기술들은 나눠진다. 프로그래밍 언어부터 다르다. 개발자들도 두 영역으로 각각 나눠지기도 하며, 둘 다 하는 풀 스택 개발자도 있다. 소프트웨어 개발보다는 소프트웨어의 운영 및 유지보수가 성격에 맞는 사람도 있다. 이런 분들은 개발언어보다는 운영체제나 시스템 소프트웨어 등에 관심을 가지는 것이 좋을 수 있다. 필자 같은 경우는 새로운 것을 아무것도 없는 상황에서 만드는 과정을 무척 즐기는 편이다. 그렇다 보니, 소프트웨어 개발 자체에 흥미를 많이 느끼고 있으며, 기술 영역 중에서도 자바를 활용한 백 엔드 영역을 선호한다. 이는 지금까지 경력을 관리하는 데 반드시 필요한 이정표가 되고 있다.
본인의 성향과 관심사를 잘 파악한 뒤, 이러한 영역을 찾아서 관련 일을 할 수 있는 곳을 찾아보자. 그리고 그곳에서 실무 경험을 해야만 진정 원하는 경험을 쌓을 수 있고, 기술력 및 제대로 된 경력을 즐겁게 쌓을 수 있을 것이다. 간혹, 대학을 졸업하고 회사에 대해 문의하는 경우가 있다. 잘 알려지지 않은 중소기업이라 망설이는 분들도 많았다. 필자는 그런 분에게 도전해보라는 조언을 많이 한다. 행여라도 회사가 없어진다고 하더라도, 그 회사에서 경험한 기술은 영원히 그 사람의 귀중한 자산이 된다. 지나치게 높은 눈높이 때문에 취업을 준비하면서 많은 시간을 보낼 바에, 필드에서 실무 경험을 하는 것이 훨씬 좋은 시도다.
혹자는 소프트웨어 개발을 하기 위하여 필요한 것은 컴퓨팅 사고력을 바탕으로 한 문제 해결 능력, 수학적 사고, 추상화 능력, 패턴 인식, 알고리즘 구축 능력 등이라고 반문할 수도 있겠다. 하지만, 필자의 생각은 조금 다르다. 이러한 능력들은 후천적으로도 충분히 기를 수 있는 것이기 때문이다.
하지만, 본질적으로 프로그래밍을 해본 적이 없거나, 프로그래밍 자체에 즐거움을 느끼지 못하는 사람들이 섣불리 혹은 우연히 이 세계에 발을 들여놓는다면 결국 오래갈 수도 없거니와 이미 업계에 있는 개발자들에게 큰 짐이 될 수 있을 것이며, 성숙한 개발 문화를 만들어가는 데 도움이 되지 않을 것이다.
오해는 하지 말았으면 좋겠다. 처음 시작하는 분들에게 “프로그래밍을 잘 해야 된다”라고 하는 것이 아니다. “프로그래밍을 즐겨야 한다” 가 중요하다. 천재는 노력하는 사람을 못 이기고, 노력하는 사람은 즐기는 사람을 못 이긴다. 프로그래밍이 재미있다면, 실력은 경험과 노력에 따라서 반드시 올라갈 것이다. 그리고 어느 시점이 되면, 다른 누군가에게 나눌 수 있게 될 것이다.
필자의 경험이 이 일을 시작하려는 분들에게 조금이나마 도움이 되기를 바란다. 만약, 소프트웨어 개발자가 되고 싶다면, 지금 당장 프로그래밍을 시작해보자.
그리고, 즐기자 :)
[각주]
C, C++, VC++, 자바 : 가장 많이 사용하는 프로그래밍 언어들이다.
네트워크 프로그래밍 : 서로 다른 컴퓨터 혹은 프로세스 (프로그래밍 실행 단위) 간에 네트워크를 활용하여 통신을 하는 프로그래밍을 말한다.
FTP : File Transfer Protocol의 약자로, 파일을 전송하기 위한 네트워크 규약이다.
시물레이션 : 실제로 실행하기 어려운 실험을 컴퓨터에서 행하는 모의실험을 뜻한다.
레거시 : 보통, 기존에 사용하고 있는 시스템을 레거시라고 부른다.
외주 용역 : 외부의 소프트웨어 개발 전문 회사에 대가를 지불하고 일을 주는 경우를 말한다.
데이터베이스 : 정확하게는 DBMS(DataBase Management System)이라고 하며, 데이터를 저장하기 위한 소프트웨어를 말한다. Oracle, MySQL, PostgresQL, SQLite 등이 있다.
프레임워크 : 개발을 도와주는 기능들을 모은 반제품 형태의 소프트웨어, 자바 진영에서는 스프링이 가장 많이 사용된다.
