2P by GN⁺ 6시간전 | ★ favorite | 댓글 1개
  • 대학 시절부터 이어진 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조차 자주 고장났음
      정말 “재미있는” 시절이었음
  • 나도 이제 경력 20년 차에 접어들었는데, 웹 개발만 해와서 그런지 재미있는 일화는 별로 없는 것 같음

  • 나이 들수록 기술 문제를 풀어도 사람들이 놀라지 않음
    그래도 언젠가 노인이 되어서도 코딩을 하고 있다면, 그땐 다시 인상 깊게 보일지도 모름

  • “프로세서 리셋 포인트로 점프했다”는 문장에서, 단순히 CPU만이 아니라 사람의 학습 태도도 리셋된 것 같다는 생각이 듦

    • 그 사람이 직접 어떤 경험을 했는지, 이후 어떻게 됐는지 정말 궁금함
  • DevOps에 관심 있다면 Davide Bianchi의 "Tales from the Machine Room"을 추천함

  • “susam.com” 도메인을 예전엔 못 샀다고 했는데, 지금은 판매 중
    정가보다 싸게 살 수도 있을 듯함. 물론 .net 도 괜찮지만, 감정적인 애착이 있다면 시도해볼 만함
    좋은 이야기들 공유해줘서 고마움

  • LLM 이전의 소프트웨어 업계에서 일했던 경험은 직접 겪어봐야 이해할 수 있는 것임