PHP

2012년 부터 본격적으로 쓰기 시작했다. 요즘 같은 시대에 아직도 PHP인가 싶겠지만 지금까지 나를 먹여주고 재워주고 살려 준 은혜로운 개발 언어라서 섣불리 버릴 수 없었다. 게다가 AAA급 서비스나 자사 운영 서비스가 아닌 이상 웹호스팅에서 구동할 수 있는 거의 유일한 언어이기 때문에 중소기업 외주, 랜딩페이지 제작 등 여러모로 쓸모가 많아 여전히 PHP로 개발하고 있다.

MariaDB

PHP의 경우 찰떡궁합 DB가 MySQL이기 때문에 PHP를 시작한 시점부터 MySQL을 썼다. 그러다 MariaDB가 나왔고 지금은 MariaDB를 활용한다. 사실 둘의 차이는 잘 모른다. "왜 모르냐?" 할 수 있지만 레이서가 자동차 엔진의 세세한 기능이나 성능까지 알 필요는 없다고 생각한다. 그 정도의 서비스 수준이라면 DBA가 필요할테니까. 나의 수준과 경력에서는 뭘 써도 비슷했지만 어찌됐든 공인된 오픈소스는 MariaDB이기 때문에 쓴다.

코드이그나이터3

2012년 중국 웹게임 플랫폼을 만들면서 접한게 계기가 되어 지금도 쓰고 있다. (공식 지원은 이미 생명을 다했다) 주의할 점은 4가 아닌 3다. 위의 맥락과 비슷한데 웹호스팅에서 FTP 파일 전송 방식으로 심플하게 운용이 가능한 PHP 프레임워크는 코드이크나이터3기 때문이다.

라라벨

코드이그나이터4와 라라벨과의 전쟁에서 코드이그나이터가 패배(?)함을 보고 라라벨로 환승했다. 2020년 7버전부터 쓰기 시작해 11버전까지 왔다. 9버전부터 Vite 번들링을 지원하는데 러닝 커브가 좀 있긴 하지만 로컬 개발시 속도면에서 확실한 차이가 난다. 국내에서는 인지도가 확 떨어진 느낌인데 9버전까지 활발하게 이루어지던 한글번역이 더는 이루어지지 않고 있다. 가끔은 굳이 PHP를 이렇게까지 무거운 프레임워크를 써야 하는 생각도 들기는 하지만 표준화된 관리 이슈 문제도 있고 더는 스파게티 코드 양산소라는 오명도 듣기 싫어 PHP=라라벨 이라고 생각한다.

도커

2019년 도커를 접하고 '웹 세상에 은총이 내려왔다'라는 생각이 들 정도로 도커는 나에게 있어 개발의 사고방식을 바꿔준 고마운 존재다. 로컬에서 개발 환경 맞추고 프로덕트 환경에서 다시 맞추기 위해 서버 셋팅 문서를 서비스마다 만들던 수고가 이제는 완전히 사라지게 됐다. 하지만 라이브 서비스에 도커 도입을 꺼리는 회사도 여전히 존재하고 대형 서비스에서 어떻게 활용하는지 겪어본 바가 없어 이 부분은 경험해 보면 좋을 것 같다.

JavaScript

웹 개발에서 자바스크립트는 사실상 뺄 수 없는 존재지만 개인적으로 나는 자바스크립트를 그렇게 좋아하지 않는다. 브라우저를 넘어 서버까지 확장했으니 자유롭다못해 우주까지 넘어간 언어가 자바스크립트라 생각한다. 게다가 현대의 프론트엔드 환경에서 자바스크립트의 활용도가 훨씬 높아졌는데 개인적으로 피로도가 너무 상승해 "있으니까 써야한다"의 느낌으로 쓸 뿐이다. 그래서 라라벨과 같이 전통적인 SSR 환경인 경우 JQuery를 활용하는 편이다. 어차피 리액트와 같은 CSR 환경은 대안이 없기에 기조에 맞춰 쓴다.

퍼블리싱

'CSS is Awesome'이라는 자조적 문구가 절실하게 와닿지만 소규모 회사에서 이것저것 하다보니 퍼블리싱도 하게됐다. 간단한 웹사이트는 혼자 만드는 편이다. 리액트 체계의 프론트엔드로 오면서 퍼블리싱도 예전과는 많이 다르다는 걸 느낀다. 특히 세계 적으로 Tailwind 활용도가 높아졌는데 Bootstrap파였던 나는 Tailwind로 넘어 온 게 그리 오래되지는 않았다. 하지만 역시 퍼블리싱은 전문 퍼블리셔다 해야한다.

파이썬

'난 자바스크립트로는 절대 서버를 만들지 않겠다!'를 충족한 언어가 파이썬이었다. 사실 그 이외의 이유는 없다. 서버는 PHP로도 충분히 만들 수 있다. 하지만 요즘에는 글로벌 서비스 API지원이 자바스크립트 or 파이썬 구도이기 때문에 자바스크립트가 싫다면? 파이썬 해야 한다. 그래서 PHP로 개발할 수 없는 백엔드는 파이썬을 활용하고 있다. 파이썬도 프레임워크 전쟁 후 몇 선택지로 나눠졌는데 FastAPI가 좋아보여 선택했다. 실제 이름대로 Fast하긴 하다. 단, 개발하는 내 마음은 Fast하지는 않다. 없는 기능도 있고 제약도 있고... 특히 ORM인 SqlAlchemy는 좀 유기적으로 돌아가지 않는 느낌도 있다.

리액트

개발자인데 리액트 안하면 무슨 대역죄인 되는게 요즘 분위기다보니 눈치 봐가며 사이드 프로젝트 몇 개 만들었다. 하면서 느낀 점은 '도대체 왜 이렇게 비효율 적으로 움직이는 것인가?' 였는데 아무래도 브라우저라는 제약이 심한 한계 안에서 어떻게든 해보려고 하다보니 그렇게 된게 아닐까 한다. 파고들면 들어갈수록 해야 할 게 너무 많아서 도대체 이게 끝은 있는건가 싶다. 요즘의 프론트엔드는 이게 문제면 저게 나오고 저게 문제면 그게 나오는 식이라 너무 피로가 심하다...

NextJS

결국 '이게 문제 저게 문제 그게 문제' 하다가 나온 리액트 보완 프레임워크 NextJS. 리액트를 해봤으니 NextJS도 해봐야 할 것 같아서 사이드 프로젝트로 해봤다. '버그, 어수선, 여전히 변신중, 용어 불일치' 등이 내가 느낀바다. 결국 라라벨이나 스프링, 장고 처럼 프론트엔드 개발자도 서버의 개념을 알아야 하는 단계까지 와버린 것이다. 과연 어디까지 프론트엔드라고 볼 것인가. 백엔드의 지원은 어디까지 인가. 작업의 경계를 어떻게 나눌 것인가? 사실 내가 이해도가 딸려서 그런거지만 현대의 프론트 세계는 참으로 어렵다.

Git

이제는 Git 안 쓰고는 뭘 할 수 없다. 버전 관리를 넘어 단순 백업 용도로도 훌륭한 서비스다. 하지만 의외로 Git을 도입하지 않은 업체도 많다. (물어보면 불편해서라고 한다) 대형 서비스에서 Git을 써본적은 없기에 어떤 구조로 활용되는지 궁금해서 기회가 되면 접해보고 싶다.

서버

초창기에는 CentOS를 썼는데 2019년부터 Ubuntu를 쓴다. CentOS는 기업형에 초점을 맞췄다면 Ubuntu는 범용성에 초점을 맞췄다는 느낌이다. 게다가 WSL2 환경에서 공식적(?)으로 쓸 수 있는 리눅스 버전이 Ubuntu이기 때문이기도 하다. 당연히 서버 엔지니어만큼은 사용할 줄 모르지만 어찌됐든 서비스 하나 구동할 수 있을 정도 활용도는 있다. (rm -rf를 조심하시오)

클라우드

면접시 꼭 나오는 질문이 "AWS 쓸 줄 아세요?"인데 질문 자체가 잘못됐다고 생각한다. AWS에 있는걸 내가 다 쓸 줄 알면 클라우드 서비스 창업하지 개발자는 안 할 것 같다. AWS든 네이버든 구글이든 NHN든 기본적인 인스턴스 생성하고 네트워크 구성하고 스토리지 추가 연결하고 오브젝트 스토리지 활용하고 이정도는 한다. AWS는 수 많은 서비스 안에서 어떻게 보물을 찾아내고 우리 서비스에 접목시키느냐가 관건인데 사실 그정도 규모의 서비스를 운용하는 회사가 없다보니 경험해볼 수 없었다. 이 부분 또한 접해볼 수 있으면 정말 훌륭한 경험이 될 것 같다.