1990년대 개발자 이야기
F-Lab : 상위 1% 개발자들의 멘토링
성장에 관심이 많은 F-Lab 백앤드 멘토 Elkein
스타트업 여럿과 NHN, 넷마블, 크래프톤 등을 거쳤으며
게임 산업, 클라우드 플랫폼 개발, 웹 개발 등을 두루 경험한 19년 차 엔지니어개요
나는 90년대 개발자다.
오해의 소지가 있어서 설명하자면, 90년대생이 아니라, 90년대에 개발을 시작한 개발자라는 뜻이다.
그 시절 이야기를 가볍게 해보고자 한다.
컴퓨터 학원
나는 95년 말에 처음 컴퓨터 학원을 다녔다.
당시 컴퓨터 학원의 주 목적인 컴퓨터 그 자체에 익숙해지는 것이면서, 동시에 컴퓨터 이용권을 획득하는 개념에 가까웠다.학원의 수강 시간은 물론이고, 이외의 시간에도 수강생은 어느정도 컴퓨터를 사용할 수 있는 권한을 주었기에 이를 이용해서 게임을 즐기는 것이 주 목적이었다.
컴퓨터 학원을 다니면서 만나게 된 동갑내기 친구는 Q-Basic을 이미 쓸 수 있었다. 그 친구는 여러가지 정보에 빠삭했는데, 어떻게 알게 된 것인지 초등학교 5학년이었음에도 게임을 만들려면 C언어를 배워야 한다, Basic으로는 할 수 있는게 한계가 많다, Basic은 이름 부터 기초다, 남자라면 강력한 언어인 C언어를 해야 한다, Cobol이나 Fotran, Pascal은 너무 올드하다 같은 얘기를 듣게 됐다.
그렇게 나는 그 녀석의 설득에 넘어가 C언어 책을 사게 됐고, 그렇게 시작된 프로그래밍은 지금도 나를 프로그래머로써의 삶을 살게 해줬다.
C언어
위에 컴퓨터 학원에서 만난 친구를 언급한 이유는, 당시에 C언어와 비견 될 수 있는 언어 중에서 Cobol, Fotran, Pascal, Basic 모두 시대의 변화에 사라졌지만, 유독 C언어만 다양한 목적하에 살아남았다는 점이다.
C언어는 저수준의 하드웨어 접근과 이식성, 성능 면에서의 강점, 다양한 응용 분야에서의 사용 가능성 등으로 인해 지속적으로 사용되고 있다. C++은 복잡하지만, C언어는 컴팩트하면서 강력하다. 여전히 수 많은 패키지의 내부는 C언어로 작성된 코드로 동작하고 있다.
컴퓨터 과학 기초와 기본기를 다지는 수 많은 커리큘럼은 C언어를 이용한다. 다양한 책과 컬럼에서 우려하던, 더이상 C를 배우지 않는 국내외 수 많은 컴퓨터 과학 (공학) 커리큘럼... 여기에서 오는 갈증을 해소하기라도 하려는 것인지, 기본기를 위해서는 C언어 부터 배워야 한다는 것이 다시금 중요해지고 있다.
90년대에 사용된 개발자 팩
90년대 개발자 스타터팩 | GeekNews (hada.io)
Turbo-C 2.0
책에는 없지만, 나는 Borland 사의 Turbo-C 2.0을 가장 먼저 사용하게 된 컴파일러다.당시 PC통신에서 가장 손쉽게 구할 수 있고, 용량이 적어서 종량제 통신비를 아낄 수 있어서 먼저 써보게 됐다.당시에는 Borland 사의 Turbo C와 Borland C가 C 컴파일러에서 메이저한 컴파일러였으며, 지금도 종종 언급되고, 쓰이는 회사가 존재하는 생산성의 끝판왕인 Delphi도 이 회사의 제품이다. 참고로 Delphi는 현대 언어의 아버지 Anders Hejlsberg - Wikipedia 가 만든 작품이다.
이 분은 이후에 Microsoft로 옮겨가 C#과 TypeScript라는 전설적인 언어를 만들었다.
Visual Studio
위 링크는 5.0이지만, 내가 처음 사용했던 버전은 Visual Studio 4.0 이다. 그렇게 시작됐던 Visual Studio가 17.0까지 출시됐고, 앞으로도 출시 될 예정이다. 수 많은 언어가 지원됐다가 만료됐고, 새로 추가되고 있지만 C언어와 C++만큼은 굳건하다.모르는 분이 많으실 수도 있어서 언급하자면 C++은 C언어의 슈퍼셋이기에 C++이 지원되는 컴파일러에서는 C언어로 구현, 컴파일이 가능하다. 물론 리눅스에서도 gcc를 통해 컴파일이 가능하다. 꽤나 많은 다수의 언어에서 사용되는 기능들이 gcc를 통해 빌드된 파일을 쓰거나, 직접 빌드를 거쳐서 사용하게끔 스크립팅 되어있다.
MSDN
당시에는 인터넷이 상시 연결 환경이 아니었다보니, 버전이 높아 질 수록 CD 장수가 많아지곤 했다. Visual Studio 6.0 기준 CD 6장이고, 그 중 4장이 MSDN이었던걸로 기억한다. 당연하게도 구글링을 포함해 검색 엔진을 이용 할 수 없었기에, MSDN을 참고해서 용법에 맞게 잘 구현하는 것이 너무나도 중요하던 시기다
MFC
Microsoft Foundation Classes의 약어다. MFC를 이용한 윈도우 UI 어플리케이션 개발을 할 수 있었고, MFC 기능들을 조합해 커스텀 브라우저도 만들 수 있었다. MFC는 상속 기반의 거대한 라이브러리였는데, 당시 Visual C++ 관련 책을 사면 MFC 클래스 구조도 브로마이드를 제공 해주기도 했다. 당시에는 그걸 벽에 붙여놓고 뿌듯해 했던 기억도 난다.
WIN32 API
지금은 직접 WIN 32 API를 써서 코딩하는 경우는 흔치 않아졌다.
#include <Windows.h>
int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR lpCmdLine, int nCmdShow)
{
MessageBox(NULL, "Hello, Welcome to Win32 Programming",
"Hello, World", MB_OK | MB_ICONINFORMATION);
return 0;
}
나의 시대에는 WIN32 API를 이용한 어플리케이션을 개발 하는 일이 많았는데, MFC가 복잡도도 높고 커스터마이징이 유연하지 않은 문제가 있기도 했고, 내가 꽤 오랜 경력 동안 작성했던 Native TCP Socket 어플리케이션을 작성할 경우에는 MFC가 제공해주는 대부분의 기능이나 오버헤드가 적합하지 않았기 때문이기도 하다.
여하튼 이렇게 WIN32 API를 직접 이용해서 많은 어플리케이션을 만들었는데, 지금은 크로스 플랫폼 라이브러리도 워낙 많고, 대부분의 언어가 WIN32 API나 POSIX API를 직접 호출하기 보다는 추상화 된 함수를 호출하게끔 지원되고 있으니 이러한 변화도 내 입장에서는 신기한 적도 있었다.
무어의 법칙에서 멀티 코어의 시대로
무어의 법칙을 알고 있는가?
무어의 법칙 - 위키백과, 우리 모두의 백과사전 (wikipedia.org)
반도체의 집적회로의 성능이 24개월마다 2배로 증가한다는 법칙이었는데, 이 법칙은 소비 전력과 발열을 한계로 인해 코어의 클럭은 더이상 높아지지 못했고, 멀티코어의 방향으로 변화하게 된다.
이 변화로 인해 어플리케이션 개발에서 큰 변화가 오는데, 바로 멀티스레드 프로그래밍이다.
당시만 해도 많은 개발자들이 멀티 스레드를 제대로 제어하지 못해서 다양한 블러킹 상황이나, 동기화 이슈를 겪어야 했으며, 이러한 문제들을 해소하기 위해서 다양한 논의와 고민이 있었는데 POSA Vol.2에서 이미 많은 멀티스레드 패턴이 정립됐고, 현대의 트렌드는 잠금 객체를 최소화하고 비동기 처리를 잘 할 수 있게 메커니즘을 가져가는 데에 있다고 볼 수 있다.
이러한 흐름의 변화도 왜 이렇게 흘러왔는지도 지금 다시 돌이켜보면 재밌지만, 당시에는 멀티스레드 어플리케이션을 어떻게 구현해야 블러킹 상태에 덜 빠지고, 데드락에 걸리지 않으면서 로직 구현을 손쉽게 할 수 있는 고성능 어플리케이션 구조를 갖춰야 하는지 고민했던 시기도 떠오른다.
마치며
90년대 개발자로 자라서 2000년대 초반에 취업한 입장에서는 당연했던 것들이 지금은 당연하지 않다.
너무나 많은 것이 바뀌었고, 중요시 여기는 것들이 바뀌었다.
오늘 이야기한 내용에 포함되지는 않지만, 온 프라미스에서 클라우드 환경의 변화도 꽤 컸고, 무어의 법칙이 깨지고 멀티 코어의 시대의 변화도 꽤 컸다. 이렇게 변화하는 트렌드와 흐름에 적응하고 이해하면서 개발자로 살아온지도 어느덧 프로그래밍 자체로는 28년, 직업 개발자로 계산 해도 20년이 가까워지고 있다.
오히려 이렇게 변화와 흐름이 자주 바뀌고, 새로운 것들을 자주 접해야 되서 더 즐겁게 오랫동안 해올 수 있었던게 아닐까 싶다.
이 컨텐츠는 F-Lab의 고유 자산으로 상업적인 목적의 복사 및 배포를 금합니다.
