25년간의 소프트웨어 개발 이야기

핵심 요약

한 사람의 25년 컴퓨팅 경력을 통해 호기심, 실험 정신, 멘토링, 기술 성장, 경력 전환의 핵심 요소들을 정리한다.

기술 자체보다 '어떻게 배우고, 어떻게 사람과 일하며, 어떻게 성장하는가'를 중심으로 이해할 수 있도록 재구성했다.

학생, 주니어, 시니어 모두 자신에게 맞는 시점의 인사이트를 발견할 수 있도록 구체적 사례와 함께 설명한다.

웹 소스 보기: 기술 입문의 문턱 낮추기

인터넷이 아직 낯설던 시절, 브라우저의 "View Source" 한 번이 한 사람의 인생을 바꿨다.

HTML이 단순한 텍스트라는 사실, <BODY><FONT COLOR="RED">HELLO</FONT></BODY> 같은 코드가 화면을 바꾼다는 경험은 "웹은 마법이 아니라 사람이 쓴 문법"이라는 깨달음을 준다.

기술을 처음 만날 때 중요한 것은 완벽한 강의나 두꺼운 책이 아니라, "이거 나도 해볼 수 있겠다"는 감각을 주는 짧고 구체적인 체험이다.

또 한 가지 흥미로운 점은, 그 선배의 진짜 목적은 "자리를 뺏는 것"에 가까웠지만, 의도와 상관없이 그 10분이 한 사람을 평생 웹을 만드는 사람으로 만들어 버렸다는 사실이다.

우리는 누군가에게 아주 가볍게 보여 준 5~10분짜리 설명이, 그 사람의 진로를 바꿀 수 있다는 점을 종종 잊는다.

리셋 벡터: 호기심이 이론을 '자기 것'으로 만드는 방식

8086 CPU가 리셋되면 CS:IP가 FFFF:0000에서 시작한다는 이론은 강의 중에 스쳐 지나가는 하나의 사실일 뿐이다.

하지만 이 글의 화자는 그걸 보고 "그럼 거기로 점프해 보면 진짜 리셋될까?"를 떠올리고, DOS의 DEBUG.EXE에서 직접 G =FFFF:0000을 실행해 본다.

이 차이는 단순하다. 한쪽은 "외운다", 다른 한쪽은 "시험해 본다". 이론을 외우는 사람과, 실험해서 자기 몸에 새기는 사람의 차이다.

그 과정을 지켜본 친구는 성적 상위권이었지만 "그렇게 생각해 보는 발상" 자체를 부러워한다. 그리고 더 이상 1등을 고집하지 않고, 호기심과 실험에 시간을 쓰겠다고 마음먹는다.

여기서 배울 수 있는 핵심은, '똑똑함'보다 '시험해 보는 습관'이 장기적으로 더 큰 차이를 만든다는 점이다. 강의에서 들은 작은 디테일 하나라도, 실제로 실행해 보고, 깨지고, 확인하는 사람에게 기술은 빠르게 자기 것이 된다.

초반 커리어: 작은 일에서도 '실력 + 설명력' 쌓기

첫 직장은 취향과 맞지 않았다. 허술한 인스톨러를 돌리고, 실패하면 수동으로 땜질하는 일이 반복되는 팀이었다.

그는 두 가지를 했다. 하나는 설치 스크립트 자체를 안정화시키는 작업, 또 하나는 "누가 해도 따라 할 수 있는 상세 사용 설명서"를 만든 것이다.

흥미로운 점은, 코드 개선보다 이 설명서가 더 큰 칭찬을 받았다는 점이다. 조직 입장에서는 "문제를 줄이는 자동화"와 함께 "사람들이 실수 없이 쓰게 돕는 문서화"가 동시에 가치가 있기 때문이다.

하지만 그는 이 일을 오래 하기엔 만족감이 부족하다고 느끼고, 다른 팀으로 옮기기 위해 적극적으로 요청하고, 도시까지 옮길 각오를 한다. 이 결단 덕분에 웹 프레임워크와 보안 아키텍처를 하는 팀으로 이동해, 커리어의 방향이 크게 바뀐다.

초반 커리어에서 기억할 점은 두 가지다. 지금 손에 쥔 일이 마음에 안 들어도, 그 안에서 "실력"과 "설명력(문서, 가이드, 정리)"을 남기고, 동시에 자기에게 맞는 팀으로 옮기기 위해 꾸준히 움직여야 한다는 것이다. 둘 중 하나만으로는 판이 잘 안 바뀐다.

MITM과 PKI: 낯선 개념을 깨는 공부법

아키텍처 팀 면접에서 나온 "MITM 공격을 어떻게 막을 수 있는가?"라는 질문 앞에서 그는 "MITM이 뭔지 모른다"고 솔직히 인정한다.

면접관은 오히려 그걸 기점으로 "PKI와 MITM을 공부해 오라, 디지털 서명을 구현해야 한다"는 미션을 준다. 즉, 모른다는 사실을 숨기지 않았지만, 그게 기회를 막지 않았다.

이후 그는 RFC와 문서를 매일 조금씩 읽으며 공개키 암호, 인증서, PKI, 디지털 서명 개념을 몸에 익힌다. 처음엔 위압적이지만, 시간이 지나면서 그 복잡한 구조가 직관적인 그림으로 바뀐다.

여기서 보이는 공부법의 특징은 두 가지다. 실무 과제를 '공부의 목표'로 삼고, 표준 문서(RFC 등) 같은 1차 자료를 지속적으로 읽는다는 점이다. 인터넷 요약글만 읽는 것보다, 처음엔 어렵더라도 원문을 읽으면 장기적으로 훨씬 단단해진다.

이 과정을 통과한 뒤 그는 수백 개 은행과 수백만 사용자가 쓰는 시스템의 핵심 보안 기능을 구현하게 되고, 나중에 고객 입장으로 그 시스템을 마주하게 되었을 때, 20년 전 자신이 쓴 HTML 흔적을 다시 발견하는 경험을 한다. "내 코드가 오래 살아 남는 구조물을 만들었구나"라는 직업적 만족감이 여기서 나온다.

스파게티 코드와 디버깅: 복잡성을 다루는 진짜 실력

셋톱박스용 C 코드로 위젯을 만들다가, 포인터 실수로 인한 랜덤 크래시가 발생한다. 작성자인 본인조차 이해하기 힘든 스파게티 코드였고, 몇 시간 동안 디버깅해도 원인을 못 찾는다.

팀 리드가 코드를 받아 가서 단 몇 분 만에 문제 지점을 정확히 짚어낸다. 같은 코드를 봐도, 어떤 사람은 숲을 보지 못하고 나무에 매달리지만, 어떤 사람은 구조를 빠르게 파악하고 예민하게 "이상한 곳"을 찾아낸다.

이 경험은 "내가 꽤 잘 한다고 생각했지만, 위에는 훨씬 더 넓은 세계가 있다"는 깨달음을 준다. 즉, 실력 상한선을 한 번 보고 나면, 그 순간부터는 성장 속도가 전혀 달라진다.

여기서 중요한 건 부끄러워하기보다, "저 사람은 어떻게 그렇게 빨리 구조를 파악할까?"를 의식적으로 관찰하고, 자기 코드 작성 습관과 디버깅 방식을 바꾸는 것이다. 이후 그는 코드 복잡성을 다루는 능력을 크게 개선했다고 회상한다.

성장의 핵심은, "내 실력이 꽤 괜찮다"는 착각을 깨뜨리는 강한 레퍼런스를 일찍 만나는 것이다. 그런 사람과 같이 일할 수 있다면, 그 자체가 최고의 교육이다.

애니메이션 위젯: 기술적 가능성과 현실 제약의 충돌

Java ME 기반 셋톱박스에서 위젯 애니메이션을 구현해 달라는 요구가 들어온다. 제조사 쪽은 "그건 우리 셋톱박스로는 불가능하다"고 단정하지만, 그는 "화면에 그릴 수 있으면, 지우고 다시 그려서 움직이는 효과를 내는 것도 가능하다"고 보고 직접 구현해 낸다.

에뮬레이터에서는 부드러운 애니메이션이 잘 돌아간다. 문제는 실제 하드웨어였다. 실제 TV에서는 프레임이 끊기고, 아무리 최적화를 해도 내장된 제한적인 CPU와 그래픽 처리 능력이 요구사항을 만족시키지 못한다.

이 사건은 두 가지를 보여준다. 첫째, 현장의 "불가능" 선언이 때로는 보수적 관성 때문에 나오는 것일 수 있다는 점. 실제로 코드를 짜 보기도 전에 불가능 판단을 내리는 경우는 많다.

둘째, "이론적으로 가능하다"와 "제품으로 쓸 만큼 매끄럽게 가능하다"는 전혀 다른 문제라는 점이다. 제한된 임베디드 자원 위에서는, 기능의 가능성보다 "사용자가 봤을 때 품질이 충분한가"가 더 중요하다.

최종적으로 고객(통신사)은 "중途半端한 애니메이션이면 안 하느니만 못하다"고 판단하고 기능을 접는다. 여기서 얻을 수 있는 교훈은, 엔지니어는 종종 "할 수 있다"에 초점을 맞추지만, 제품 관점에서는 "제대로 된 경험으로 제공할 수 있느냐"가 기준이라는 점이다.

좋은 상사와 멘토: 경로를 바꿔주는 한 번의 대화

RSA에서 1년쯤 근무한 후, 그는 더 수학적이고 알고리즘적인 일을 하고 싶다고 여러 번 이야기하지만 당장은 변화가 없다.

그러다 Labs의 최고 과학자가 직접 불러 "어떤 일을 하고 싶은지, 어떤 팀이 맞을지"를 함께 논의해 준다. 그리고 구체적으로 갈 만한 팀들을 제안한다. 이 짧은 만남은 이후 6년간 이어지는 최고의 적합 팀으로 이어진다.

그 팀에서 그는 파서 생성기, 형식 언어 명세, 페타바이트급 데이터베이스의 인덱싱과 쿼리 엔진 등, 고난도 주제를 다루며 거의 매일 새로 배우는 경험을 한다.

세월이 흐른 뒤, 그는 그 짧은 면담이 자신의 커리어 경로를 크게 바꾸었다는 사실을 깨닫고 감사 메일을 보낸다. 멘토는 "내가 받은 좋은 영향과 격려를 다음 세대에게 넘겨주고 싶다"고 답하며, 이를 "좋은 축복(good blessings)을 전달하는 것"에 비유한다.

여기서 얻을 수 있는 교훈은, 뛰어난 멘토는 "정답을 주는 사람"이 아니라 "다음 단계를 향해 한 걸음 옮길 수 있게 방향과 용기를 주는 사람"이라는 것이다. 동시에, 우리가 어느 순간 누군가에게 그런 역할을 해 줄 준비를 해야 한다는 점도 드러난다.

CTF 경험: '천재'에서 '경험 많은 사람'으로의 인식 변화

중년이 된 뒤, 그는 C, C++ 중심의 시스템 프로그래밍 경력을 쌓아 왔지만, 취미로 Python, Go 등을 다뤄 왔기에 마이크로서비스 개발로 전환도 자연스럽게 해낸다.

사내 CTF 대회에서는 SQL 인젝션부터 바이너리 리버싱, 스택 오버플로우까지 다양한 문제를 풀며, 8시간 만에 약 90%를 해결해 1위를 한다. 젊은 시절부터 퍼즐을 잘 풀고 복잡한 문제를 즐겼던 이력과 자연스럽게 이어지는 결과다.

그런데 주변의 평가는 예전과 다르다. 예전에는 이런 성취를 보면 "와, 저 사람 진짜 똑똑하다"고 말하곤 했지만, 이번에는 "그는 C로 10년 넘게 했으니 당연하지"라는 반응이 나온다.

이는 나이가 들수록 개인의 성취가 '재능'이 아니라 '경력 연차'로 설명되는 경향을 보여준다. 사람들은 더 이상 그걸 특별한 재능으로 보지 않고, "그 정도 경력이면 그럴 수 있지"라고 여긴다.

그는 여기에 집착하지 않는다. 대신 "기술력은 이제 경험으로 치부되더라도, 내가 함께 일하는 사람들에게 남길 수 있는 건 전문성뿐 아니라 윤리, 태도, 친절함일 것이다"라고 생각한다. 나이가 들수록 자신을 증명하는 방식이 바뀐다는 사실을 받아들이는 태도다.

인사이트

기술 경력 25년의 에피소드는 모두 하나의 공통된 축을 가진다. 호기심, 실험, 설명, 협력, 멘토링, 그리고 태도다.

첫째, 이론을 듣고 그냥 넘어가지 말고 "한 번 해보면 어떻게 될까?"를 습관처럼 실행하는 사람이 결국 더 많이 배운다. 리셋 벡터에 점프해 보는 작은 실험이 그 예다.

둘째, 마음에 안 드는 일이라도 그 안에서 실력을 다듬고, 문서화·정리·설명 능력을 키우면, 그게 다음 단계로 이동할 수 있는 신뢰 자산이 된다. 동시에, 가만히 있지 말고 원하는 방향을 위해 이동을 요청하고, 실제로 움직여야 한다.

셋째, 잘 모르는 영역(암호, 보안, 임베디드 제약 등)을 만났을 때, 겁부터 내지 말고 "이 프로젝트를 완수한다"는 목표를 걸고 원문 문서와 실제 실험으로 점진적으로 파고들면 어느 순간 이해가 직관으로 바뀐다.

넷째, 자기보다 훨씬 잘하는 사람과 부딪히는 경험을 피하지 말아야 한다. 그 충격이 없으면 "내가 어느 정도 수준인지"를 착각하고 머무르기 쉽고, 그 충격이 있어야 성장 속도가 가속된다.

마지막으로, 경력이 쌓이면 "천재" 소리 대신 "연차 많은 사람"으로 보이기 쉽다. 그 시점부터는 문제 해결 실력뿐 아니라, 후배에게 건네는 한 마디, 커리어를 열어 주는 한 번의 대화, 함께 일하는 태도가 더 오래 남는다는 것을 기억할 필요가 있다. 이 글의 화자처럼, 언젠가 "좋은 축복"을 다음 사람에게 넘기는 역할을 자신도 하게 될 수 있다.

출처 및 참고 : Twenty Five Years of Computing - Susam Pal