개인의 경험을 바탕으로 생각을 쓴 글입니다.
정답 보다는 이런 관점도 있구나.. 라는 정도의 "글"로만 읽어주세요.
2024년 새해가 밝았는데.. 출근해야 하는데.. 새벽에 잠이 안오고 잡다한 생각들이 많이 나서 개발 포지션에 대한 글을 써보고자 한다..
간략한 회고를 해보자면 내가 "웹 생태계"의 개발자로 발을 딛기 시작했을 무렵에는 나에게 적합한 포지션은 없었다. 그저 주어진 기술 스택에 맞춰서 빈 공간을 제공해주면 알아서 설계하고 구현하고 비즈니스의 가치를 만들 뿐, 각각의 요소 요소에 맞추어 깊게 생각할 틈은 없었다.
아마 처음 시작하는 개발자들 또한 포지션이 있을 수도, 없을 수도 사실 명함에만 포지션이 있을 수도 있을 것 같다. (대기업을 제외하고 개발자들이 명함을 내밀 일이 얼마나 많을까)
프론트엔드, 백엔드라는 포지션이 생긴 시점도 10년이 안된 것 같다. 원래는 "한 사람"이 담당했던 작업이 "포지션"이라는 이름 하에 나뉘게 되었다. 한 사람이 두 주인을 섬길 수 없기 때문이다.
한 사람이 두 주인을 섬길 수 없다?
우리에게 돈이나 이익을 주는 사람이 "주인"이다. 개발자는 손가락과 머리로 주인을 만족시키기 위해 열심히 고민하며 두드린다.
웹 서비스의 관점에서도 주인이 있고 주인은 지시(= Trigger)를 하는 입장의 모든 것이고 이는 크게 사용자의 액션, API 호출, 시간 스케쥴, 가스라이팅이 될 수 있다.
이 관점으로 정의한다면 프론트엔드, 안드로이드, IOS, 백엔드 포지션이 이렇게 구분지어질 수 있다.
프론트엔드
- 인터넷 브라우저 내에서 사용자가 액션하는 이벤트를 핸들링하는 포지션
안드로이드
- 안드로이드 OS 핸드폰 내에서 발생하는 이벤트를 핸들링하는 포지션
IOS
- iOS 핸드폰 내에서 발생하는 이벤트를 핸들링하는 포지션
백엔드
- 이벤트 핸들링을 제외한 모든 Trigger 에 대해 핸들링하는 포지션
(백엔드가 존나 일이 많은게 당연한거다)
돌아와서..
원래 이 모든걸 담당하던 "한 사람"이 있었는데 돈을 주는 주인의 접점에 있는 사람을 분리해두고 IT 용어로 "클라이언트"라고 구분지어 한 사람이 한 사람을 상대하는 구조로 변모시켰다. (아니.. 사용자 DAU 가 100만이면 프론트엔드:100만 아니야??)
그래서 사실상 백엔드 포지션의 클라이언트는 프론트엔드, 안드로이드, IOS 이다. 주인의 최전선에 있지는 않지만 이들이 없으면 주인은 그 어떤 서비스도 제공받지 못하는 것 또한 사실이다. 원래 한 몸이였는데 팔, 다리가 분리된 것 처럼 분리된 것이기 때문에..
이 글의 목적
나는 포지션이 백엔드 엔지니어다. 새벽에 잠이 안왔던 이유는 나의 포지션에 대한 정체성에 혼란이 왔기 때문이라고도 생각이 든다. 이제 사회는 백엔드 엔지니어 중에서도 어떤 주인을 상대하는 백엔드 엔지니어가 될 것인지 물어보는 추세가 되고 있다. 나는 그 중 같은 백엔드 엔지니어를 주인으로 섬기는 Devops 엔지니어의 길을 가고 싶은 것이 나의 최종 목표이다.
넋두리, 사이드 프로젝트
어느날 한 사람이 백엔드로 사이드 프로젝트를 하고 싶은데 뭘 해야 할지 질문을 주었다. 내가 했던 대답이 잘 기억이 나질 않지만 백엔드 사이드 프로젝트의 핵심은 API 가 인터넷 브라우저, 모바일 컴포넌트 등의 이벤트 액션으로 Trigger 되는 부분이 없다는 것이다. 그래서 UI 를 하지 않고 만들 수 있는 제일 쉬운 사이드 프로젝트는 CLI 프로젝트이다.
실제로 유명하다고 하는 오픈소스는 모두 CLI 가 있고, 내부적으로는 백엔드 서버와 통신 프로토콜을 통해 통신하는 구조를 취하고 있다.
본인이 생각한 사이드 프로젝트의 내부 핵심 도메인 로직을 백엔드 코드로 작성해서 오픈소스로 올려두고 "아, CLI 부분과 플랫폼화를 위한 UI 부분이 남았습니다 독립 레포지토리로 기여해 주세요!" 하고 홍보하는 것 또한 하나의 방법이다. (도커라이징이 안되어 있으면 개발하기 불편할 것 같죠?)
API 에 대한 말, 말, 말
백엔드 Http 통신을 API 라고만 부르는 아예 정의해 버리는 사람들이 많은 것 같은데 자신을 하나의 통신 프로토콜에 가두는 일은 하지 말자
두 SW의 통신 프로토콜의 집합체인 API 는 Http 말고도 GRPC, RPC, Message(메시지 내에는 수없이 많은 프로토콜) ... 등 무수히 많이 존재한다.
각 계층을 넘어갈 때 블랙박스 영역이 존재하는 레이어를 연결지을 때도 API 를 정의해서 사용한다.
API = Http 통신이 아니다.
