25년간의 소프트웨어 개발 이야기
(susam.net)- 대학 시절부터 이어진 25년간의 프로그래밍 여정을 돌아보며, 기술 자체보다 사람과 관계, 경험에 초점을 둔 회고
- 대학 컴퓨터실에서 우연히 배운 HTML 소스 보기 10분이 개인 웹사이트를 만들고 유지해 온 긴 시간의 출발점이 됨
- 8086 프로세서의 리셋 벡터로 점프해 시스템을 재부팅한 작은 실험이, 동기에게 호기심에서 출발하는 학습 태도를 각인시킴
- 스파게티 코드 디버깅, 셋톱박스 애니메이션의 현실적 실패, CTF 대회 상위 성적 등 시행착오와 성장이 반복됨
- 시간이 흐르며 문제 해결 능력이 재능이 아닌 경험의 결과로 받아들여지는 변화를 체감하고, 결국 남는 것은 전문성·윤리·사람을 대하는 태도라고 정리
웹의 시작: 소스 보기(Viewing the Source)
- 2001년 대학에 입학한 직후, 저녁 무렵 컴퓨터실에서 웹을 둘러보다가 주소창에
susam.com을 입력하며 웹과 처음 마주함 - 어깨너머로 보던 선배가 Internet Explorer의 View > Source 메뉴를 열어, 웹사이트가 HTML로 작성된 텍스트라는 점을 설명
- Notepad를 열어
<BODY><FONT COLOR="RED">HELLO</FONT></BODY>같은 간단한 HTML을 직접 작성하고, 브라우저에서 어떻게 표시되는지 시연- 당시에는
FONT태그가 널리 쓰였고, HTML 태그를 대문자로 작성하는 관행이 일반적이었음
- 당시에는
- 글꼴 크기와 색상 변경, 가운데 정렬, 배경색 변경 등을 보여주며 웹이 작동하는 방식을 짧게 소개
- 약 10분 남짓한 설명이었지만, 월드 와이드 웹이 갑자기 덜 신비롭고 훨씬 흥미로운 대상으로 느껴지기 시작함
- 설명을 마친 선배는 자리를 돌려주지 않고 그대로 웹을 계속 사용했고, 좌석이 부족해 그대로 기숙사로 돌아가야 했음
-
susam.com도메인은 터키 요리 관련 사업체가 이미 사용 중이어서 등록하지 못했고, 이후.net도메인을 선택 - 이 짧은 만남이 이후 개인 웹사이트를 만들고 유지해 온 오랜 여정의 출발점이 됨
리셋 벡터(The Reset Vector)
- 대학 시절 컴퓨터실에서 Intel 8086 기반 MS-DOS 머신으로 어셈블리 언어 엘리베이터 제어 프로그램을 작성하던 중의 일
- 강의에서 배운, 8086이 리셋되면 CS:IP가 FFFF:0000으로 설정된다는 내용을 떠올림
-
DEBUG.EXE에서 해당 주소로 점프하면 어떤 일이 일어날지 궁금해 직접 실행-
C:\>DEBUG -G =FFFF:0000명령 실행 직후 시스템이 즉시 재부팅
-
- 이를 지켜보던 매 학기 수석이던 친구가 크게 놀라며 어떻게 그런 생각을 했는지 질문
- 일주일 뒤 기숙사를 찾아와, 성적은 항상 1등이지만 작은 사실을 떠올려 직접 시험해보는 호기심은 자신에게 없다고 고백
- 더 이상 수석을 목표로 하지 않고, 배운 내용을 탐구하고 실험하며 즐기는 방식으로 공부하겠다고 선언
- 이후에도 상위권 성적은 유지했지만, 실제로 다시는 1등을 하지 않음
- 프로세서의 리셋 진입점으로 점프한 한 번의 실험이, 누군가의 학습 태도를 경쟁에서 탐구로 바꾸는 계기가 됨
중간자 공격과 첫 번째 엔지니어링 직무(Man in the Middle)
- 대학 졸업 후 첫 직장에서 e-뱅킹 제품 기술 지원팀에 배치되어, 특정 컴포넌트를 배포하기 위한 인스톨러 실행 업무를 맡음
- Python으로 작성된 인스톨러는 대상 환경에 대한 가정이 취약해 자주 실패했고, 첫 주 동안 인스톨러를 안정화하고 단계별 사용자 가이드를 작성
- 코드 개선보다 사용자 가이드가 더 큰 호응을 얻음
- 반복적인 지원 업무에 한계를 느끼고 더 본격적인 개발 일을 원해 여러 차례 팀 이동을 요청
- 결국 다른 도시에 있는 Archie(아키텍처) 팀의 면접 기회를 소개받음
- Archie 팀은 e-뱅킹 제품 전반을 지탱하는 웹 프레임워크와 핵심 아키텍처 컴포넌트를 담당
- API 라우팅, 인증·인가, 쿠키 관리 등을 Java Servlet과 JSP로 자체 구현
- Spring이나 Django 같은 오픈소스 프레임워크가 등장하기 이전에 만들어진 구조
- 은행 환경에서 사용되는 만큼 엄격한 보안 테스트와 정기 감사가 필수
- 2006년 전화 면접에서 SQL 인젝션, XSS 대응 같은 보안 질문에는 답했지만, MITM(중간자 공격) 이라는 용어는 처음 접해 모른다고 인정
- 면접관은 “PKI와 MITM을 철저히 공부하라. 기업 뱅킹 제품에 디지털 서명 기능을 구현할 예정”이라고 설명
- 이후 몇 주 동안 RFC 문서와 공개키 인프라(PKI), 공개키 암호화 표준 자료를 집중적으로 학습
- 처음에는 어렵고 부담스럽게 느껴졌지만, 시간이 지나며 점차 직관적이고 정교한 체계로 이해됨
- 새 도시로 옮긴 뒤 약 한 달 만에 오픈소스 Bouncy Castle 라이브러리를 활용해 디지털 서명 기능을 완성
- 이후에도 제품의 여러 핵심 부분을 개발하며, 수백 개 은행과 수백만 사용자가 쓰는 성숙한 시스템에 코드가 포함되는 경험을 쌓음
- 매니저는 뛰어난 멘토였고, 그의 지지는 오랫동안 자신감의 기반이 됨
- 약 20년이 지난 지금도 해당 제품은 운영 중이며, 때때로 고객 입장에서 브라우저 개발자 도구를 열어보면 당시 작성한 코드의 흔적을 발견함
스파게티 코드(Spaghetti Code)
- 2007~2008년 무렵, OpenTV 셋톱박스용 위젯 개발을 위한 개념 증명(PoC) 작업에 참여
- 극도로 축소된 C 언어 환경에서 코드를 작성하던 중, 위젯이 간헐적으로 크래시하는 문제 발생
- 복잡하게 얽힌 로직과 무분별한 포인터 연산으로 인해, 자신이 작성한 코드조차 이해하기 어려운 스파게티 코드 상태에 이르름
- 네 명으로 구성된 팀의 리드이자 아키텍트에게 코드를 tarball 형태로 전달
- 몇 시간 동안 해결하지 못한 문제를, 아키텍트는 코드를 받은 지 불과 5분 만에 특정 파일의 포인터 버그로 정확히 짚어냄
- 해당 한 줄을 수정하자 크래시가 즉시 사라짐
- 이 경험을 통해 스스로 꽤 잘한다고 믿고 있었지만, 좋은 소프트웨어 개발자가 되기까지 아직 갈 길이 멀다는 사실을 실감
- 이후 여러 해에 걸쳐 성장하며, 현재는 당시와 비교할 수 없을 만큼 소프트웨어 복잡성을 다루는 능력을 갖추게 됨
애니메이션 텔레비전 위젯(Animated Television Widgets)
- 같은 시기의 또 다른 프로젝트에서 Java ME(Micro Edition) 기반 셋톱박스 플랫폼을 위한 위젯 개발을 담당
- 프로젝트는 세 주체가 협력하는 구조로 진행됨
- 자사: 소프트웨어 벤더 역할
- 대형 통신사: DTH 텔레비전 서비스 브랜드 보유
- 셋톱박스 제조사: 하드웨어와 플랫폼 제공
- 통신사 측에서 위젯에 슬라이드 인·아웃 같은 애니메이션 효과를 적용할 수 있는지 문의
- 파트너 회의에서 셋톱박스 제조사는 “해당 셋톱박스는 애니메이션을 지원하지 않으며, 불가능하다”고 단언
- 위젯을 그릴 수 있다면 위치를 조금씩 바꿔 반복해서 다시 그리는 방식으로 애니메이션이 가능하다고 판단
- 이 원리로 에뮬레이터에서 정상 동작하는 데모를 구현
- 다음 회의에서 데모를 공유하자 셋톱박스 제조사는 격앙된 반응을 보이며 즉각적인 작업 중단을 요구
- 공식적으로 불가능하다고 밝혔던 입장과 모순된다는 이유
- 통신사 대표가 개입해 “불가능하다고 한 기능을 이들이 구현해 보이고 있다”며
제조사인 쪽에서 자사 제품의 성능을 모른다는 것이 말이 되느냐고 강하게 질책 - 이후 실제 하드웨어에서 테스트한 결과, 에뮬레이터에서는 부드럽던 애니메이션이 TV 화면에서는 뚜렷한 끊김으로 나타남
- 몇 주에 걸쳐 프레임 레이트 조정, 버퍼링 방식 변경, 렌더링 루프 최적화를 시도
- 제한된 임베디드 하드웨어 성능이 연산과 렌더링을 감당하지 못하는 한계가 드러남
- 결국 통신사는 “어설픈 애니메이션보다는 없는 편이 낫다”고 판단해 기능 자체를 폐기
- 결과적으로 셋톱박스 제조사의 판단이 현실적으로 옳았음이 확인됨
좋은 축복(Good Blessings)
- 2009년, RSA Security에서 약 1년간 근무한 뒤 수학과 알고리듬 중심의 더 지적인 업무를 찾고자 함
- RSA Laboratories의 수석 과학자 Dr. Burt Kaliski가 직접 면담을 제안해 커리어 방향에 대해 조언
- 그 조언을 바탕으로 새로운 팀에 합류해 이후 6년간 근무
- 파서 생성기, 형식 언어 명세와 구현
- 페타바이트 규모 데이터베이스의 인덱싱 및 쿼리 엔진 개발
- 거의 매일 새로운 것을 배우며 커리어에서 가장 즐거운 시기를 보냄
- 수년이 지난 뒤, 짧았던 그 면담이 자신의 커리어 궤적을 바꿨음을 깨닫고 감사의 이메일을 보냄
- Dr. Kaliski의 답신에는 다음과 같은 문장이 포함됨
- 다른 이들이 자신의 커리어에 투자해 준 것처럼, 성장 중인 사람들에게 격려를 전하는 것이 목표
- 좋은 축복을 한 세대에서 다음 세대로 전하는 일
CTF 스코어보드(The CTF Scoreboard)
- 2019년 당시, 더 이상 20대 초반의 신입 엔지니어가 아니라 중견 스태프 엔지니어로서 수년간 C/C++ 기반 저수준 네트워킹 및 데이터베이스 시스템을 개발해 온 상태
- Go와 Python 기반 마이크로서비스 개발을 이끄는 새로운 단계로 커리어가 전환됨
- 개인 프로젝트를 통해 이미 Python과 Go를 사용해 온 덕분에 전환은 비교적 자연스러웠음
- 10월 사이버보안 인식의 달을 맞아 사내에서 CTF(Capture the Flag) 대회가 열림
- SQL 인젝션, 취약한 암호화, 바이너리 리버싱, 스택 오버플로 익스플로잇 등 다양한 유형의 기술 퍼즐로 구성
- 경쟁과 시간 제한이 있는 문제 풀이에 부담을 느끼면서도 참여했고, 약 8시간 만에 문제의 약 90%를 해결해 1위를 기록
- 대회가 진행되는 동안 동료들이 종종 자리를 찾아와 진행 상황을 보고 놀라움을 표현하며 사무실의 화제가 됨
- 존경하던 두 명의 젊은 동료 엔지니어가 성과에 대해 나누는 대화를 우연히 듣게 됨
- 한 명이 성과를 높이 평가하자, 다른 한 명이 “당연하지, C를 10년 넘게 했잖아”라고 답함
- 젊은 시절에는 이런 문제 해결이 ‘똑똑함’으로 받아들여졌지만, 이제는 자연스럽게 경험의 결과로 해석된다는 변화를 실감
- 기술적 성과가 경험 덕분으로 여겨지더라도, 앞으로는 전문성, 윤리, 그리고 동료를 대하는 태도로 좋은 인상을 남기고자 함
전체 회고
- 25년에 걸친 컴퓨팅의 여정은 호기심에서 출발해 실험, 협업, 감사, 성찰로 이어지는 흐름
- 눈에 띄는 기술적 성취보다, 그 과정에서 맺은 사람과 배움의 관계가 더 오래 남음
- 각 시기의 경험은 서로 이어지며 지속적인 성장과 겸손한 태도로 축적됨
- 소프트웨어 개발 경력의 핵심은 결국 코드 자체보다, 배우고 함께 일해 온 사람들의 이야기
Hacker News 의견들
-
예전에는 사람들에게 일을 맡기면 알아서 잘 해낼 거라는 신뢰가 있었음
그런데 요즘은 주니어 엔지니어에게 트위터급 시스템 설계를 요구하고, Leetcode 문제 풀이를 외우게 함
이런 건 예전엔 쓸모없는 절차였고, 이제 LLM이 이런 문화를 없애줄 거라 기대함- “LLM이 없애줄 거라면, 주니어들도 포함인가?”라는 농담 섞인 반응임
- 요즘은 프론트엔드만 하거나 백엔드만 하는 식으로 전문화가 심해졌음. React만 하거나 Go만 하는 사람도 많음
-
나도 비슷하게 시작했음
초등학교 3학년 때, “Make Your Own Web Page! A Guide for Kids”라는 책을 학교 북페어에서 보고 엄마에게 사달라고 했음
그때는 인터넷이 마치 기업 전용인 줄 알았는데, 내가 직접 웹페이지를 만들 수 있다는 걸 알고 완전히 빠져들었음
HTML을 배우며 해커가 된 기분이었고, 선생님이 너무 놀라 부모님께 전화까지 했음
이후 “Sams Teach Yourself C in 24 Hours”와 Flash MX 2004용 ActionScript 책, 그리고 C++ 책으로 프로그래밍을 배웠음
지금은 그 덕분에 괜찮은 커리어를 쌓았고, 최근 eBay에서 그 책을 다시 구해 읽으며 미소 지었음 -
통신사 직원이 셋톱박스 담당자에게 “그냥 닥쳐요”라고 한 부분에서 웃음이 터졌음
상황 전체가 황당하면서도 웃긴 장면이었음. 사람들이 쓸데없는 것에 집착하다가 스스로를 곤란하게 만드는 경우가 많음- 셋톱박스 담당자는 그냥 “실제 하드웨어에서는 부드럽게 구현이 어렵다”고만 했으면 됐음
괜히 자신을 바보처럼 보이게 만들었음. 그래도 정말 재미있는 글이었음
- 셋톱박스 담당자는 그냥 “실제 하드웨어에서는 부드럽게 구현이 어렵다”고만 했으면 됐음
-
Python으로 작성된 설치 프로그램이 환경 가정이 틀려서 항상 수동 개입이 필요했다는 말에 공감함
나도 SDR 개발 환경 세팅에 반나절을 썼음. 의존성 지옥은 여전함
결국 돌아가긴 했지만 정말 엉망이었음- Python은 실행 가능한 패키징 면에서 재앙 수준임
서버 사이드처럼 컨테이너로 환경을 통제할 때는 좋지만, 그 외에는 절대 쓰고 싶지 않음 - 예전에 근무한 곳들 중에는 개발 환경 세팅에 이틀씩 걸린 곳도 있었음
구식 상용 소프트웨어나 방치된 OSS 프로젝트들이 뒤섞여 있었고, 몇 달마다 랜덤하게 깨져서 개발 중단 사태가 생겼음
결국 어떤 회사는 아예 AMI 기반 EC2 인스턴스를 개발자별로 띄우는 방식을 택했는데, 그걸 관리하는 CLI조차 자주 고장났음
정말 “재미있는” 시절이었음
- Python은 실행 가능한 패키징 면에서 재앙 수준임
-
나도 이제 경력 20년 차에 접어들었는데, 웹 개발만 해와서 그런지 재미있는 일화는 별로 없는 것 같음
-
나이 들수록 기술 문제를 풀어도 사람들이 놀라지 않음
그래도 언젠가 노인이 되어서도 코딩을 하고 있다면, 그땐 다시 인상 깊게 보일지도 모름 -
“프로세서 리셋 포인트로 점프했다”는 문장에서, 단순히 CPU만이 아니라 사람의 학습 태도도 리셋된 것 같다는 생각이 듦
- 그 사람이 직접 어떤 경험을 했는지, 이후 어떻게 됐는지 정말 궁금함
-
DevOps에 관심 있다면 Davide Bianchi의 "Tales from the Machine Room"을 추천함
-
“susam.com” 도메인을 예전엔 못 샀다고 했는데, 지금은 판매 중임
정가보다 싸게 살 수도 있을 듯함. 물론 .net 도 괜찮지만, 감정적인 애착이 있다면 시도해볼 만함
좋은 이야기들 공유해줘서 고마움 -
LLM 이전의 소프트웨어 업계에서 일했던 경험은 직접 겪어봐야 이해할 수 있는 것임