IT 15년 썰 - 2
1900년 대의 웹 개발
1900년대의 서비스(한메일 서비스)의 구성은 이랬다. (모든 서비스가 이런 것은 아니었겠지만)
- 웹 : Apache httpd + C cgi
- 라이브러리 : 직접 개발한 C library
- 데이터베이스 : Berkely DB
- 스크립트 : Shell(c shell, bash shell), perl
- 기타 모듈들… (말이 '기타’이지, 메일 시스템은 눈에 보이는 서비스 부분은 빙산의 일각이라고 보면 된다)
cgi로 페이지가 구성되어 있다 보니, 새 버전이 배포가 나가게 되면 돌고 있던 프로세스는 끊기게 된다.
유저가 뭔가 저장하고 있던 상황이면 날리게 되는 셈인데,
그 당시는 유저도 우리도 이 정도의 안정성에 대해서는 어느 정도 이해해주는 시절이었다.
나의 편지가 산 넘고~ 물 건너~ 순간 당신에게 전달되는 마술이 벌어지는데, 잠깐 서비스가 멈추는 정도야~
버클리디비(https://en.wikipedia.org/wiki/Berkeley_DB)는 92년에 개발된 임베디드 DB인데(현재의 SQLite 같은) 그 후 SQL 분석기와 인덱스를 붙여서 초기 mysql 이 되었고 mysql 은 2006년 오라클에 합병됐다.
어쨌건 처음엔 배포 때 긴장을 많이 했다. 서비스가 잠깐 안될 수도 있는데다, 전 국민이 사용하고 있었으니까.
최초로 내가 수정한 cgi를 배포(당시 rcp 배포)하던 때가 기억이 나는데,
"나 이거 정말 엔터 칩니다~ 지금 친다고요. 나 책임 못 져요. 지금 엔터 누릅니다, 정말 누릅니다~"
이러면서 배포를 했음. ㅎㅎ
그렇게 호들갑이었지만, 아마도 유저들이 거의 찾지 않는 구석탱이에 박혀있는 기능이었을 것으로 추측된다.
당시 그렸던 그림으로 그때의 정신상태를 짐작할 수 있다 : 나의 앞머리가 외계인과 통신하는 안테나라고 주장했다이 구조(그다지 설명드리진 않았지만 -ㅠ-)는 분산이 어렵고, 유지보수가 어렵고,
파편화 된 많은 모듈들에, 리팩토링이 쉽지 않은 구조로,
그 후 여러 단계의 개선의 길을 걷게 되는데,
아키텍처 설계나 대용량 시스템에 대한 개념을 공부하는 후배들에게 문제점 파악과 개선안을 숙제로 내주고 싶은, 좋은 대상이다.
1900년대의 시스템이라고 이름을 붙여서 그렇지, 이 세상 모든 서비스는 이렇게 시작해서 진화한다.
지금은 많은 클라우드 서비스들이 큰 짐을 덜어주지만,
그럼에도 불구하고 서비스 성장과정 중에 고민해야 하는 문제들은 그리 다르지 않을뿐더러,
도움을 주는 많은 서비스/모듈들도 이런 고민을 통해 나온 프로덕트들이기에 그 탄생의 과정에 대해 이해해 두는 것은 중요하다(고 생각한다).
그리고 2001년, 나는 첫 java 프로젝트를 하게 되는데,
- 언어 : J2SE 1.3
- 웹 : Apache Httpd / 쌩 Servlet /
Resin(레신 써보신 분 손? 하이파이브!)
- 데이터베이스 : Oracle
- IDE : vi + javac
(자바 vi로 코딩하신 분 손? 하이파이브! ㅎㅎㅎ)
그 서비스는 "카드메일" 이었다.
카드메일 보내기 화면 (검색해봤는데 이 이미지밖에 못찾았다 ㅜ.ㅜ)플래시로 만들어진 애니메이션 카드에 메일 내용을 덧붙여서 보내는 서비스였다.
(지금 찾아보니, 당시 카드 콘텐츠 제공사 중 하나였던 '샌드투유'가 아직도 서비스를 하고 있네!)
java는 제임스 고슬링 옹께서,
Write Once, Run Anywhere라는 환상적인 구호와 함께 조금씩 세상에 변화를 주기 시작했는데,
나는 98년도에 수업으로 java를 배웠었고, 실제 서비스에 적용해 본 것은 이것이 처음이었다.
제임스 고슬링 옹. 2004년 JavaOne 컨퍼런스에서 만나서 사진도 찍었다! (자랑)JDK 1.0(1996년)
JDK 1.1(1997년)
J2SE 1.2(1998년. 조금 쓸만해졌나?)
J2SE 1.3(2000년)
resin : EJB를 모두 구현한 컨테이너로, 이 당시 다른 선택지가 없는 상황이었으나 후에 유료화 되어 대부분의 서비스는 Apache tomcat으로 갈아타게 됨.
이 대목('유료화 하며 사라졌다')에서 잠깐,
소프트웨어 세상에서는 일반적인 프로덕트와 참으로 다른 생존 방식을 강구해야 한다.
그 어떤 분야보다 빠르게 발전한 힘이기도 하면서도, 꽤나 살기 피곤한 세상이기도 하다 ;)
2001년 당시, 이클립스는 세상에 없었고,
터미널 상에서 vi로 코딩을 했었는데, 당시엔 그게 불편한 것인 줄도 몰랐다.
그때 나름 OOP 방식으로 구현한다며 상속 구조도 만들고 했는데, 지금 생각해보면(기억도 안 나지만) 그다지 서비스상 필요한 구조는 아니었다.
그냥 java 의 특성에 대해 상상의 나래를 펼쳐서 연습했던 것 같다.
나의 당시 코드를 기억하는 선배님이 최근에 그 코드에 대한 기억을 고백(?) 해 주셨는데 '매우 독특하게 OOP를 구현해서, 신선했고, 그 아이디어(?)를 존중해서 그 방식대로 사고해보려고 애쓰셨다' 고.
하지만 딱히 어느 부분이 신선했는지, 무엇보다 기억이 나질 않는다 (아쉽… 코드가 어딘가 있긴 있으려나).
그리고 OOP 에 대해 장/단점 등 사례를 비롯해 많은 것들이 딱히 정리가 된 시대도 아니었다.
이 프로젝트에서 기억에 남는 또 하나는,
무려 데이터베이스가 사망할 것을 대비해서, 데이터베이스에서 읽어온 데이터 구조를 serialized 해서 파일로 떨궈두는 부분이 있었는데,
(서비스를 띄울 때 디비를 읽어서 잘 읽히면 파일로 떨궈두고, 디비가 안 읽히면 떨궈둔 파일을 읽어서 서비스한다)
지금 생각해도 신박하다.
그 정도의 데이터면 뭐하러 디비를 썼을까(디비는 서비스를 위해서가 아닌, 카드메일들을 관리 <CRUD>하는 용도였음).
역시나, 지금 돌아보면 나에게 있어서는 공부를 위한 프로젝트로 훌륭했다.
그런데 그 일이 실제로 일어난 적이 있긴 하다. 디비가 죽었고, 카드메일은 백업해 둔 파일을 읽어서 아름답게 서비스를 제공했다. :P
그리고 이 서비스는 나 혼자 시스템 구성하고, 개발하고, 운영했다. (물론 이것만 한 것도 아니고)
지금으로 말하자면 풀 스택 엔지니어?
그땐 풀 스택 밖에 없었다.
