컴퓨터과학과를 2학년에 중퇴했다. 특별한 사연이 있는 것은 아니다. 수업보다 실제 개발이 더 재미있었고, 당시 웹 개발 수요가 넘쳐나던 시기라 일감을 구하는 게 어렵지 않았다. 젊은 자신감으로 “학위 없이도 잘 할 수 있다”고 생각했다. 15년이 지나고 보니, 맞기도 하고 틀리기도 한 판단이었다.
Table of contents
Open Table of contents
초기 — PHP와 외주 개발
처음 시작은 PHP 외주였다. 2010년대 초반, 소규모 웹사이트와 쇼핑몰 개발 수요가 많았다. 게시판, 회원 관리, 결제 연동 — 이런 것들을 반복적으로 만들었다. 프레임워크 없이 순수 PHP로 시작했고, 이후 CodeIgniter를 거쳐 Laravel로 넘어갔다.
외주 개발은 기술력보다 의사소통 능력이 중요했다. 고객이 원하는 것을 정확히 파악하고, 구현 가능한 범위를 명확히 설명하고, 일정을 지키는 것. 기술적으로 완벽한 코드보다 “약속한 날짜에 동작하는 결과물”이 평가 기준이었다.
이 시기에 배운 것 중 가장 중요한 것은 “완성”의 감각이다. 사이드 프로젝트에서는 70%까지 만들고 흥미를 잃어도 되지만, 외주에서는 100%까지 끌고 가야 한다. 마지막 30%가 전체 시간의 절반 이상을 잡아먹는다는 것을 몸으로 익혔다.
프리랜서 vs 정규직
3년 정도 외주를 하다가 정규직으로 전환했다. 이유는 단순했다. 외주는 프로젝트가 끝나면 코드도 끝이다. 내가 만든 시스템이 시간이 지나면서 어떻게 되는지 볼 수 없었다. “유지보수”라는 것을 제대로 경험하고 싶었다.
정규직으로 들어간 첫 회사는 직원 수가 한 자릿수인 작은 곳이었다. 면접에서 학위 이야기가 나왔지만, 포트폴리오와 이전 외주 결과물을 보여주니 문제가 되지 않았다. 작은 회사의 장점은 이것이다 — 결과물이 곧 자격이다.
이후 경력이 쌓이면서 정규직과 프리랜서를 몇 번 오갔다. 패턴이 있었다. 정규직에서 한 분야를 깊이 파고, 프리랜서로 나가서 다양한 프로젝트를 경험하고, 다시 정규직으로 돌아와서 넓어진 시야를 적용하는 순환이었다.
프리랜서의 장점은 연봉 구간이 빠르게 올라간다는 것이었다. 정규직에서는 연차에 따라 천천히 오르지만, 프리랜서는 실력이 검증되면 단가가 크게 뛰었다. 단점은 불안정성이다. 프로젝트 사이의 공백기, 4대 보험 자가 부담, 은퇴 후 대비 — 이런 것들은 젊을 때는 신경 쓰지 않지만 나이가 들면 무게가 느껴진다.
학위 없는 개발자의 현실
솔직하게 쓰자면, 학위 때문에 불이익을 받은 적이 있다. 대기업 지원 자격에서 학력 요건에 걸린 적이 두어 번 있었다. 서류 단계에서 탈락하면 실력을 보여줄 기회조차 없다.
그러나 중소기업, 스타트업, 프리랜서 시장에서는 학위가 거의 문제되지 않았다. 이 업계에서 학위의 가치는 경력 초기에 집중되어 있다. 경력 5년이 넘어가면 이전 직장에서 무엇을 했는지가 학위보다 훨씬 중요해진다.
학위가 없어서 아쉬운 부분은 따로 있다. 알고리즘, 자료구조, 운영체제, 네트워크 — 이런 기초 과목을 체계적으로 배우지 못한 것이 나중에 발목을 잡을 때가 있었다. 독학으로 보완했지만, 체계적 교육과 독학은 효율이 다르다. 특히 알고리즘 지식이 부족해서 특정 유형의 문제를 풀 때 돌아가는 길을 택한 적이 많았다.
반대로 학교를 다니지 않은 덕분에 얻은 것도 있다. 실무에 일찍 뛰어들면서 “학교에서 가르치지 않는 것들” — 서버 운영, 배포, 장애 대응, 고객 소통 — 을 동기들보다 몇 년 먼저 경험했다.
작은 회사의 CTO
경력 10년 차쯤에 작은 회사에서 개발 총괄 역할을 맡게 되었다. 직함은 CTO였지만 실질적으로는 시니어 개발자 겸 인프라 담당 겸 DBA 겸 코드 리뷰어였다. 팀 규모가 작으니 모든 것을 해야 했다.
이 역할에서 가장 어려운 것은 코딩이 아니었다. 기술 의사결정의 무게감이었다. 프레임워크 선택, 서버 아키텍처, 데이터베이스 구조 — 이런 결정들이 이후 몇 년간의 개발 방향을 좌우한다. 결정을 내릴 때마다 “내가 이것을 결정할 자격이 있는가”라는 의문이 들었다.
작은 회사의 CTO가 갖춰야 하는 능력은 특정 기술의 깊은 전문성이 아니다. 폭넓은 기술 이해를 바탕으로 “지금 이 상황에서 최선의 선택”을 판단하는 능력이다. 완벽한 아키텍처보다 현실적인 아키텍처가 필요하다. 팀의 기술 수준, 프로젝트 일정, 예산 — 이런 제약 조건 안에서 최적의 타협점을 찾는 것이 CTO의 일이다.
한 가지 고백하자면, 처음에는 모든 것을 직접 하려고 했다. 다른 사람이 작성한 코드가 마음에 들지 않으면 새벽에 혼자 다시 짰다. 이것은 CTO의 역할이 아니다. 시간이 걸렸지만, “70%짜리 코드를 팀이 함께 이해하는 것”이 “100%짜리 코드를 나만 이해하는 것”보다 낫다는 것을 배웠다.
기술 변화에 적응하기
15년 동안 기술 스택은 여러 번 바뀌었다. PHP → Node.js → Python/Go 순서로 주력 언어가 이동했고, 서버 관리는 물리 서버 → 가상 서버 → Docker → 오케스트레이션으로 변화했다. 프론트엔드는 jQuery → AngularJS → Vue.js 순으로 바뀌었다.
변하지 않은 것도 있다. SQL은 15년 전이나 지금이나 거의 같다. HTTP 프로토콜의 기본도 그대로다. Linux 명령어, 네트워크 기초, 자료구조 — 이런 기반 지식은 한번 익히면 오래 간다.
기술 변화에 적응하는 나름의 원칙이 생겼다.
새로운 기술은 사이드 프로젝트로 먼저 시도한다. 운영 중인 프로젝트에 검증되지 않은 기술을 도입하는 것은 도박이다. 개인 프로젝트에서 한 사이클을 돌려보고, 장단점을 직접 경험한 후에 도입을 검토한다.
트렌드와 기반 기술을 구분한다. Docker는 기반 기술이다. 한번 배우면 10년은 쓴다. 특정 CSS 프레임워크는 트렌드다. 트렌드는 개념만 이해하고, 기반 기술에 시간을 투자한다.
완전히 새로운 것은 거의 없다. 대부분의 “새로운” 기술은 기존 개념의 재조합이다. 컨테이너는 chroot의 발전이고, 마이크로서비스는 SOA의 변형이다. 근본 개념을 이해하면 새 기술의 학습 곡선이 완만해진다.
15년 후의 솔직한 감상
중퇴를 후회하지 않느냐고 물으면, “후회는 아니지만 아쉬움은 있다”고 답한다. 학위가 있었다면 열리지 않았을 기회가 있었고, 기초 지식의 구멍을 메우는 데 불필요한 시간을 쓰지 않았을 것이다.
그러나 중퇴라는 선택이 아니었다면 외주 개발을 일찍 시작하지 않았을 것이고, 그 경험이 없었다면 지금의 실무 감각도 없었을 것이다. 결과적으로 학위 유무보다 “무엇을 만들어 왔는가”가 경력을 결정했다.
개발자 커리어에서 확실히 말할 수 있는 것이 하나 있다면, 꾸준함의 가치다. 특출난 재능이 아니라 매일 조금씩 배우고, 만들고, 개선하는 습관이 15년을 버티게 했다. 화려한 이력서보다 “지금 이 사람에게 일을 맡기면 해낼 것인가”라는 신뢰가 모든 것을 결정한다.
지금은 AI가 코딩을 대신하는 시대가 되었다. 15년 전 학위 없이 시작한 것처럼, 지금도 변화에 적응하면서 “다음에 가치 있는 것은 무엇인가”를 찾아가는 중이다. 답은 아직 모르겠지만, 적어도 그 답을 찾는 과정 자체가 이 직업의 본질이라는 것은 안다.