풀스택 개발자란 용어에 대한 단상.

[boojongmin]

현대 웹개발에서는 풀스택이라는 단어는 특별한 사람들을 의미했지만
내가 처음 웹 개발을 할 때에는 누구나 지금처럼 풀스택 개발자였다.

그럼 당시 내가 경험한 풀스택을 살펴보면

----------
javascript          -----   (1) 
----------
jsp html rendering  -----   (2)
----------
java business logic  -----   (3)
----------
sql                 -----   (4)
----------
db 모델링           -----   (5)

대략 이런 구조로 나뉘었다. 당시 SI 작업환경에서는 개발자가 투입되기전 ERD가 먼저 나와있던 구조였기에 DBA가 모델링을 먼저해둬서 상대적으로 위의 1~4 영역을 개발하곤 했다. 단, 여기서 (2)의 영역인 html 작성은 퍼블리셔라고 부르는 마크업 개발자 html과 css를 작성해주면 나는 그것에 jsp로 옮겨서 화면을 그리고 browser에서 동작할 부분은 javascript로 처리하곤 했다.

요즘은 퍼블리싱 능력도 풀스택의 영역이므로 엄밀히 말하면 풀스택이 아니지만 개발 범위를 보면 지금처럼 둘로 나뉜 (1),(2) 프론트 (3),(4),(5) 백엔드를 백엔드에서 한번에 다 개발하기 때문에 당시 웹 개발자들은 모두 풀스택이라고 생각을한다.

그래서 백엔드를 잘 하면서 프론트를 잘하는 개발자들은 이러한 배경에 의해 나올 수 있다고 생각한다.

반대로 프론트로 시작해서 백엔드를 두루하는 젊은 세대분들은 만나보기 힘든 것도 과거 웹개발과 지금은 달라져서 발생하는 현상이라고 생각한다.

시간의 흐름을 현재로 옮겨 지금의 프론트 백엔드로 나뉘게 되는건 프론트 업무 영역의 전문화라고 생각한다.
사람들은 브라우저로 보는 web page라는 개념이 web application으로 눈길을 돌렸고 이런 복잡한 상호작용은 브라우저에서도 상태를 관리하게 되고 이러한 흐름에서 front와 backend는 극단적으로 갈라지게 되었다.

물론 많은 백엔드 개발자들은 "화면 개발은 역시 어려워"하며 기피하는 현상도 이 무렵 보게 되었고.(과거에는 선택이 아니라 필수였는데 이제는 선택의 영역)

이러한 추세가 장기간 이어지더니 현재처럼 완전히 분리된 개발환경을 갖게 되었고 나조차도 회사에서는 백엔드 팀에 소속되어 개발을했다. 백엔드 팀의 소속이 프론트 개발에 대해 말을 하는건 백엔드 개발자가 나대네라는 인상을 주게 되어 프론트쪽에는 언급을 자제하곤했다.

하지만 이렇게 분리가 되면 집단이 만들어지고 그 안에서 정치가 생기게 되는것은 필연이였던 것 같다. 화면 하나를 온전히 내가 개발할 때 없었던 커뮤니케이션 비용이 백엔드 api를 설명하기와 설득하기 비용이 발생하곤하는 것이다. 가끔 고집이 강한 front와 backend가 맞붙게 되면 유혈사태가 발생하곤 한다.

(나는 비둘기이므로 금을 바친다.🕊)

어라? 뭔가 이상한데라고 생각조차 할 수 없게 지금은 이러한 개발 방법이 완전히 정착되어 있다.

예전에는

front <------> backend

이런 느낌이였다면

지금은

front <------------------------------------ 안드로메다 -------------------------------------> backend

이렇게 갈라져가고 있다고 느낀다.

사실 풀스택이라고해서 그렇지 용어가 애매하게 쓰는 것이 있다.

웹개발 한정이라 그렇겠지만 실제로는

|------- 브라우저 -------|--------------------서버------------------------------|
|--- front application ---|---------front server -------|----backend server -----|

나는 주구장창 front application과 front server 만 이야기를 했다. backend server는 또 다른 이야기이지만... (나는저 3개를 다 다뤄야 풀스택이라고 바라보긴하지만 front application/server를 다뤄도 풀스택이라고 할 수 있다고 본다.)

그래서 혹자들은 front application + front server를 합쳐서 "front 개발을 하시네요"라고 말을 한다. (이 기준에서 혹자들은 front가 풀스택이 되어버리는 순환이 되어버리는 문제가...)

아무튼 나는 이렇게 점점 파편화되고 쪼개지는 개발 프로세스에 영향을 미치는건 유행이라고 생각한다.

"큰회사들은 리액트를 쓴대." "큰회사 들어가려면 스프링으로 백엔드 개발을 배워야한대"

이런 대화들이 실제로 오가고 있고 실제로 갈라파고스 자한민국에서 defacto이고 그 대열에 합류하고 살고있는(ing) 1인이기에 할 말은 없지만 아쉬움이 따르는 건 사실이다.

사실 기술이란 그 비지니스를 해결하기 위한 부차적인 요소인데...
(물론 큰회사는 채용을 위해서 인재풀이 많은 리액트, 자바를 채용하는 것도 이해를 하고. 시스템의 복잡도로 인해 풀스택보다 프론트 백엔드 분리가 당연한 구조라고 생각한다.)

그런데 위가 저렇게 되어 있으니 작은 회사에서도 리액트, 스프링을 고집하는 주니어 개발자들을 보게된다.(비지니스 문제가 아닌 개인의 커리어 관리를 위해) 먹고사니즘이 앞서니 회사에서는 노드나 python을 쓰는 해도 주말이나 퇴근후 저녁에 카페에서 스터디를 하는 것을 보면 개인적으로는 아쉬움이 앞서는 부분이긴하다.

언제부터 기술셋이란게 개인의 커리어 관리를 위해 회사에서 챙겨줘야하는 것이 되었고, 채용을 위해 선택을하게 된 것이다.

그래서 지금 당장 생산성을 위해서는 php도 좋아. jquery 수준만 써도 충분한 것 같은데?라는 말을 하면 레거시 틀딱이 되고 pnpm create vite 명령어로 프론트 프로젝트를 만들고 시작해야한다.

어디서부터 어디가 잘못된건지 알수는 없지만 내가 원하는데로 하고 싶은데

나혼자 개발을 해야한다는 사실은 확실하다.

그래서 나는 혼자서 서비스를 만들면 어떻게할지에 대한 고민과 이 것과 관련해 기술들을 리서칭을 하곤했고

지금은 어느정도 내가 나 혼자 서비스를 만든다면?이란 고민의 결과로 나름 기술 셋들을 정리를 해두고 요새는 여러 시도를 하는중이다.

참고로, 위에 작성을 못한것중에 풀스택의 조건중에 인프라 운영 능력도 포함이라고 생각하는데.

개발의 편리성과 못지 않게 운영의 편리성 중요한 요소이다.
또 스케일에 따라 인프라 아키텍처도 달라지기도하고 스케일업에 대응하기 위해 소스를 다 뜯거나 새로 기술셋을 정해서 만드는 경우도 흔하니...

고로 결론을 내리면

현재 개발환경에서 풀스택이 가능한 구조가 되려면 규모가 작은 팀에서 멀티플레이어의 경험이 있어야 가능하다고 본다. 과거에 비해 풀스택을 유지하기 위해 많은 노력도 필요하고.

큰회사에 가려면 프론트, 백엔드 전문분야를 만드는게 유리할 것이다.

테크리딩을 하려면 풀스택을하셔라(백엔드가 힘을 주면 프론트가 힘들고, 프론트에 힘을 주면 백엔드가 힘듦)

개인이 서비스를 만들고 싶으면 풀스택을 해라(이게 내가 프론트를 놓지 않는 이유)

개인적으로는 프론트 개발자, 백엔드 개발자가 아니라

그냥 개발자(developer)가 되고 싶다.

[boojongmin]

글을 쓰다가 같이 찾게된 micro frontend

https://micro-frontends.org/

지금의 프론트가 이런 모습이라면

이런 마이크로 프론트엔드도 괜찮아 보인다. 물론 팀에서 프론트 백엔드 개발자가 나누어서 개발하는건 마찬가지겠지만. 도메인의 익숙함 이후는 프론트도 백엔드에 기여할 수 있는 팀문화가 만들어지기 쉬울 것으로 생각된다.(물론 반대도 가능)

현대 웹서비스가 과거에 비해 덩치가 커진만큼 마이크로로 쪼개는건 이런면에서 의미가 있어 보인다.

[boojongmin]

이러한 생각의 연속선에는 과거로의 회귀처럼 보이는 SSR이 현재 유행하는 것과 일맥상통하다고 보고 있다.