나는 밑바닥 개발자였다.

적어도 2년 전까진 그랬다. 여기서 밑바닥이라는 것은 계급론적 최하층을 뜻하는 것은 아니다. 일반적으로 표현하는 소프트웨어 레이어의 가장 아래, 로우엔드, 하드웨어 디펜던시한 레이어를 뜻한다. 다시 말해 나는 디바이스 드라이버 개발자였다.

안드로이드 레이어

주 업무는 전자 부품들의 데이터 시트를 참조하여 원하는 동작을 할 수 있도록 펌웨어 / 드라이버를 개발하는 일이었다. 특별한 IDE도 없이 텍스트 에디터와 gcc를 이용해 개발을 했고, 콘솔 로그를 참조하여 디버깅을 했다. 그나마 일반적인 로직이라면 gdb 또는 콘솔 로그로 디버깅할 수 있었지만, 논리적 결함이 아닌 전자적 설정 오류나 타이밍 이슈는 오실로스코프를 이용해야 했다. 실제 데이터가 어떤 전기적 신호로 흘러가고 있는지 확인해야 했기 때문이다.

오실로스코프

전자공학이 아닌 전산학을 전공한 나는 오실로스코프 사용법은 커녕 회로도 하나 읽지 못하는 상태였다. 당연히 적응에 상당한 시간이 걸릴 수밖에 없었다. 계속해서 좀 더 로지컬한 일을 원했지만 받아들여지지 않았다. 하지만 나는 호모 디지피엔스였다. 어느새 익숙해져 실력을 인정을 받으며 10년이라는 세월이 흘렀다.

신분 레이어 상승의 욕구

실력을 인정받는다는 것은 달콤한 일이다. 그 달콤함을 버리기란 쉽지 않다. 그러나 여전히 가슴 한쪽에는 상위 레이어로 올라가고 싶은 마음이 자라고 있었다. 지금은 비록 인정받고 있다고 하지만 결국 나는 우물 안 개구리일 것이 분명했다.

drop-the-beat

Hey~ Drop the bit! 내가 가진 건 고작 0과 1, start and stop, on and off, 그게 전부지만 사실은 greater still, 그것이 바로 남자의 길~

쿵작쿵작 쿵짜작쿵짝 흐르는 010101101 비트의 세계가 남자의 길이라지만, 좀 더 많은 소프트웨어 기술들이 배틀을 하는 윗동네의 공기를 느끼고 싶었다.

그래서 과감히 회사를 그만두었다. 확실한 대책은 없었다. 일단 쉬면서 생각해 보기로 했다. 대책 없는 자유는 한없이 지루했고, 유유히 흘러가는 강물처럼 하루하루가 지나갔다. 어느새 나는 주부가 되었다.

어느덧 시간이 흐르고, 나는 제조업이 아닌 웹서비스 회사로 이직했다. 딱히 프론트엔드 같은 최상위 레이어를 원한 것은 아니었지만, 조금은 극적인 레이어 상승을 할 수 있을 것 같았다. 하지만 처음 내게 주어진 업무는 여전히 프로토콜 설계와 제어 모듈, 데몬 개발이었다. 그나마 더는 비트 단위의 프로토콜이 아닌 JSON 문서로 사람과 기계가 모두 이해할 수 있는 시멘틱을 전달할 수 있어 한 걸음 앞으로 나아간 기분은 들었다. 게다가 사람과 기계가 모두 이해할 수 있는 시멘틱은 석사 논문의 주제였던 시멘틱 웹의 궁극적인 목표가 아니었던가!

그리고 1년 후

드디어 서버 개발자로 변신했다. 물론 여전히 애플리케이션 레이어보다는 커널 레이어에 가까운 플랫폼 API 서버를 개발하고 있지만 말이다. 사실 디바이스 드라이버를 이용하는 소프트웨어에 API를 제공하는 것이나, 플랫폼을 이용하는 소프트웨어에 API를 제공하는 것이나 크게 다를 것은 없다. 그러나 그것을 구현하기 위해서 많은 것들을 새로 또는 다시 공부해야 했다.

2016년 한해 로우엔드에서 백엔드로 이동하며 공부했던 것들을 열거해보면 다음과 같다.


Python

python

주 종목이었던 c를 버렸다. 필요하다면 c로도 플랫폼 API 서버를 만들 수는 있다. 그렇지만 훨씬 쉬운 방법이 있는데 적합하지 않은 언어를 굳이 고집할 필요는 없다. 그래서 python과 flask를 공부했다. 커널의 기능을 이용하는 간단한 운영 도구도 python으로 만들 수 있다. 게다가 c로 된 라이브러리도 쉽게 사용할 수 있어 기존에 만들었던 라이브러리도 사용할 수 있다. python으로 넘어온 것은 좋은 선택이었던 것 같다.


RESTful API

restful-api

지난 10년의 경험은 javascript ui 개발을 지원하기 위한 웹 브라우저 포팅을 제외하면 웹과 거의 관련이 없었다. HTTP에 대한 지식은 겨우 학부 수준이었다. GET과 POST 메소드를 이용해 데이터를 주고받는 정도에 그쳤다. 오래전에 배운 내용은 이미 많이 변화했다. 인터페이스를 만들기 위해 HTTP와 RESTful API에 관해서도 공부해야 했다.


DB와 ORM

orm

역시 학부 이후로 DB를 거의 다루지 않았다. 제로보드 기반의 커뮤니티, 텍스트큐브와 워드프레스 기반의 블로그 등을 운영하면서 필요에 따라 조금씩 사용했던 select from where가 전부다. PK, FK, 테이블간의 관계 표현 등, 가물가물한 기억을 더듬으며 다시 공부해야 했다. 그러나 직접 쿼리를 만들 필요는 없었다. 모델링을 하고 SQLAlchemy같은 ORM을 이용하여 모델을 정의해두면 나머지는 ORM이 알아서 해준다. 신기한 세상이다.


자동 배포 도구

orm

대규모 웹 서비스를 개발해야 하니 규모를 생각하지 않을 수 없다. 여러 대의 서버를 구축하여 로드를 분산하고, 소프트웨어를 모든 서버에 자동으로 배포해야 하는 등의 개발 이외의 일들이 산재해있었다. 임베디드의 세계에서는 고려할 필요가 없었던 일들이다. 그러나 그리 어렵지 않았다. 이미 자동화되어 있는 CI 서버에서 빌드 되어 나온 펌웨어를 OTA 서버에 배포하면 끝이었다.


open source

orm

필요한 것이 있으면 일단 만들기 시작했던 구시대 개발자의 습관도 버렸다. 필요한 것은 이미 다 있다. 찾아서 사용하자. know-how보다는 know-where가 중요하다. 그러고도 개발자라면 오픈소스를 쓰자!



다시 2년전

이직을 위한 최종 면접에서 면접관 한 분이 이렇게 물었다.

임베디드 10년 경력이면 더 깊게 파는 것이 더 도움이 되지 않을까요?

물론 더 깊게 공부해 전문가(expert)가 되는 것도 좋은 선택이다. 언젠가는 전문가가 될 수도 있지만, 현실은 그렇지 않다. 전문가를 가장한 꼰대가 될 확률이 훨씬 높다. 항상 해왔던 일만 반복하는 부품이 될 확률도 만만치 않다.

나는 대답했다.

한 분야를 깊이 알기 위해서는 일단 넓게 알아야 한다고 생각합니다. 다양하게 체험해보지 않으면 깊이를 가늠하기 어렵습니다. 깊이 알기 위해 더 많은 분야를 체험해 보고 싶습니다.

그 대답의 결과로 다양한 분야를 체험하며 2016년을 보냈다. 그리고 그 체험은 앞으로도 당분간은 계속 이어질 것 같다.