얼마 전, 길기도 하고 짧기도 한 2년 동안의 개발자 생활을 마쳤다.
회사에 다니던 2년 동안 항상 지녔던 고민이 있었다.
이론과 현실의 괴리에서 오는 고민, 내 실력에 대한 의심 등의 이야기들이다.
이제 이 고민이,이 찝찝함이 어떤 이유로부터 나온 것인지를 알 것 같다. 그 이유 중 일부분을 정리해 보았다.
어쩌다 (웹) FE 개발자
변명이겠지만..
22년도에 FE 개발자가 되기 전..
나는 흔한 대학 2학년 학부생이었다. SW단과대에는 속해있지만 전공으로 배운 거라곤 자료구조, 알고리즘, 그리고 C 언어뿐. 파이썬으로 인공지능, 데이터 분석에 입문, 공부하던 평범한 학부생이었다.
AI 연구원, 엔지니어 사이를 고민하던 나는, 어느 날 “산업기능요원”이라는 기회를 발견하게 되었다. AI과 관련된 직무로 산업기능요원이라니, 엄청난 기회인 것이다. 하지만 이제 막 캐글에 입문하여 타이타닉 생존자 예측 문제를 풀고 있던 수준이라 현실의 벽을 넘지 못할 것 같았다.
그래서 빠르게 웹 쪽으로 눈을 돌렸고 그중에서도 가장 진입장벽이 낮아 보였던 FE 개발자를 선택하게 되었다.
2학년 수업으로 웹프로그래밍 (HTML CSS 기초) 수업을 들었지만 별로 도움이 되지 않았고, 자바스크립트, JSON, API 같은 용어들이 무엇인지도 모르는 상태로 약 반년 동안의 FE 개발 독학을 통해 입사를 하게 된다.
내가 입사 당시 알고 있었던 것들은 HTML, CSS 기초, 그리고 JS (TS 가 뭔지도 몰랐다)와 React 기초
(https://react.vlpt.us/ 적어도 여기 있는 건 다 익혔고 할 줄 알았다.. 도움을 진짜 많이 받았던 것으로 기억한다.)
흔한 팀 프로젝트와 그럴 듯 한 개인 프로젝트 하나 없이 (단순 클론 코딩) 실무를 시작하게 된다.
2024년 지금 다시 준비하라고 하면 절대 불가능했을 것이다.
그때의 시장 상황을 생각하면 운이 매우 좋은 편이었다 (흔히 "막차탑승"이라고 한다)
운도 좋았지만 나름의 취준 전략(현업개발을 위한 최소한의 개념 + 면접암기) 도 통하고
... 학교 생활을 생각보다 열심히, 성실하게 했던 것이 득이 된 듯싶다.
그래서 내가 놓쳤던 것들 (부제: FE로 개발을 시작하며 놓친 것들)
웹 FE 개발자는 기술적으로 요구하는 것이 다른 직군에 비해 상대적으로 낮게 느껴졌다.
실제로 내가 취준 했던 시절에는 당장 화면에 뭔가 띄울 수 있다면 최소한 업무는 할 수 있는 상태로 여겨졌다.
신기하게도 Java + 템플릿 언어(JSP?) , PHP를 사용하는 곳 (흔히 SI에 많다고 한다)에 비해
(모던 SPA Web 개발) FE 개발자를 필요로 하는 곳은 BE가 API , FE가 화면만 을 담당하도록 역할이 분리되어 있는 곳이 많았다.
그래서 백엔드(서버) 지식이 덜 해도, 리액트 가지고 화면만 찍을 줄만 알아도, 취업되던 시절이 존재했다.
이러한 환경에서 개발을 시작하니 내가 놓쳤던 것들을 점점 알게 되었는데, 이것들을 한번 정리해보려고 한다.
컴퓨터 네트워크 지식 (HTTP +.. )
나는 axios.get()만 날릴 줄 알았지, 사실 HTTP 가 뭔지 제대로 몰랐다. (면접 질문에 나옴 외웠으니까)
OSI 7 계층부터 어떤 건지 배워 본 적이 없으니까..
심지어 POST 메서드를 실무에서 거의 처음 써봤다. 개인 프로젝트에선 API로 정보를 가져와서 화면에 보여주는 정도만 해봤기 때문이다.
이 때문에 Request/Response Header를 까볼 줄 몰랐었고, 고생을 많이 했던 기억이 있다.
이는 NextJS(Express) 등의 서버사이드 코드를 만지게 될 때 큰 벽이 되었고, 다행히 이 업무를 맡은 덕에 공부를 할 수 있는 기회가 있었다.
사실 아직도 잘 모른다. IP 가 뭐고 DNS 가 뭐고..
데이터베이스 (SQL)
BE 분들에게 API 요청을 할 때 가끔 이렇게는 안된다는 답변이 돌아올 때가 있다.
그때 꼭 이야기했던 것이, DB를 조회할 때(Join?) 오래 걸린다나.. 뭐래나.. 알 수가 있어야지..
아무튼 데이터베이스 모르는 개발자가 어디 있냐 할 수도 있지만.. 나는 DB 한번 손을 대본적이 없는 FE 개발자였다.
개인적으로는 정말 부끄러운 부분이라고 생각한다. 요즘은 PM 분들도 SQL로 데이터 뽑아 분석하시던데...
여하튼 SQL 자체는 배우면 되니까 큰 문제는 안될 듯 하지만
그와 관련된 개념. "관계형 데이터 모델링"에 대한 지식과 경험이 부족하니 시야가 좁은 것이 느껴질 때가 있다.
가끔 FE에 데이터(상태)를 들고 페이지간, 컴포넌트 간 정보를 주고받을 상황이 생겼는데,
이때 데이터를 어떠한 구조로 들고 있어야 (무한 중첩객체는 무적..) 효율적으로, 클린 하게 코드 구조를 가져갈 수 있을까 에 대한 고민이 들었다.
이때 정말 아쉬웠던 것이, 특정 관계를 가지는 데이터들을 정리정돈, 교통정리를 하면 코드(컴포넌트)가 많이 깔끔해질 수 있다는 것이 느껴졌지만, 시야가 좁아 이를 해내지 못했다는 것이다.
만약 데이터를 효과적으로 정리하고 모델링할 수 있는 역량이 있었다라면 상황이 달라졌을 수 있었을까..?
그리고 매번 BE 분들한테 대꾸도 못하고 아 네.. 했던 게 좀 아쉽기도 ( DB 까보고 되면 어쩔 건데요?! )
AWS, Docker 등 클라우드 및 배포? 지식
SSR (NextJS)가 이렇게 까지 많이 쓰이지 않던 시절. FE 배포는 그냥 Github Page에 올리는 것으로 충분했었다.
React CSR 앱 같은 경우 그냥 빌드 결과물 (static html js 등등)만 정적 호스팅 하면 된다.
그리고 Vercel, Netlify 같은 흑마법을 부리는 친구들이 많다. Github에 연결하고 Push 하면 인터넷에 내 웹사이트를 배포할 수 있으니..
이런 이유로 AWS 한번 만져보지 못한 채로 회사 업무를 하고 있었다.
그래서 WS와 WAS의 차이는 물론 웹 서버가 대체 뭘 하고 있는 건지, 내 코드가 왜 저 인터넷에 떠있을 수 있는건지 하나도 알지 못했다.
nginx는 또 뭐고 reverse proxy는 뭐고 ssl 은 뭐 하는 건지... 로드벨런싱? 몰? 루
장애가 터졌을 때 CloudWatch를 (사실 이때 처음 들어가 봤다) 멀뚱멀뚱 쳐다만 보고 있는 나를 보니 참 한심하다는 생각이 들더라
FE 라도 알아야 하는 S3, CloudFront, CDN, Lambda 관련 내용들도 자주 등장했지만, 의미를 잘 모르거나 그때그때 찾아 대응했을 뿐이었다. 지금도 단어만 나열할 수 있지, 정확히 무엇을 하는지 잘 모른다.
요즘 FE 도 Node 서버를 띄우는 경우가 흔해졌는데(SSR) , 정적파일 호스팅에서 컴퓨터를 띄우는 상황으로 변했다는 것이고, 이는 관리해야 할 포인트(일..) 이 더 생겼다는 것이다. 하지만 이런 지식들에 익숙지 않으니..
만약 내가 배포 담당이나, 서버 모니터링 대응/담당을 맡았으면 정말 머리가 터져나갔을 것이다 (근데 차라리 이랬길 바랐다 배워야 하니)
Docker 도 비슷한 맥락이다. FE 서버를 띄울 때 이젠 Docker까지 등장하더라..
객체지향 프로그래밍 패러다임
JS의 태생적 특징, 모던 FE 생태계(React로 대동단결된..) 때문에 FE에서는 잘 다루지 않는 패러다임인 듯하다.
나는 객체 지향은 물론 접근 제한자, 상속에 대한 문법도 제대로 몰랐던 시기가 있었는데, 신경 쓰지 않으면 아예 모를 수도 있을 것 같다.
특히 React Hooks 도입 이후, Class Component에 대한 거부감이 많이 늘었는데, 이게 Class 문법을 보는 것의 거부감으로 살짝 변질된 듯싶기도 하다. Class 컴포넌트를 덜 쓰는 거지 Class 자체를 쓰지 말자는 아닌 거 같은데...
여하튼 FE 코드에서는 상속이라는 개념을 잘 찾아볼 수 없고, BE 코드의 그것들(Java의 그것..?)을 잘 볼 수가 없으니 + 함수형 코딩에 빠져있으니..?
FE로 개발을 처음 접하니 Class를 잘 만날 일이 없고, 그로 인해 객체지향과는 FE는 상관없다는 인식이 생기고, 실제로 몰라도 화면은 그려지기 때문에 신경을 쓰지 않으면 계속 모를 수도 있을 확률이 가장 높은 개념인 것 같다.
하지만 요즘 계층구조, 클린 아키텍처, 리펙토링, 심지어 함수형 코딩에 대해서 관심을 두고 공부를 하고 있는데,
이 "객체 지향"이라는 개념의 응용이나, 수정, 보완 등 연결 짓는 많은 것들이 존재하는 것 같다. 지금 이 개념을 잘 모르니까 진도가 안 나간다.
그리고 이론을 "아는 것"을 떠나서 실제로 객체 지향형으로 코드를 짜보고, 왜 이런 코드들이 나올 수 있는지 실제로 눈으로 보고 느끼는 것이 중요하다는 생각이 들었다.
최근 BE를 공부해 보려는 목적 중 하나다. 객체지향 패러다임을 실제로 몸으로 익히고 장단점을 느껴보는 것
디자인 패턴
이것도 객체지향과 비슷한 맥락이다.
근데 왜 나는 Compound Component Pattern (React) 은 안다 해놓고 왜 Proxy Pattern 은 모를까요?
얘는 단순 공부 부족인 듯싶다. 공부하자!
로그인/인증 기능 구현
그럴듯한 프로젝트 경험이 없으니.. JWT 고 Access Token, Refresh Token이고 다뤄본 적이 있었던가..? 소셜 로그인도 연동해본 적이 없었다.
근데 왜 회사에서 문제가 안되었냐면.....
회사 들어가니까 이미 다 구현되어있는 거 있죠????? 서비스에 로그인이 없을 리가 없잖아요!!!
(알아서 쿠키에 박혀 와리가리 하고 있던데...?)
그니까 수정할 일도 없고 직접 구현할 일도 없으니 가만히 있으면 계속 모른 채로 있는 거다.
기타 다른 것들 (CS 지식)
컴퓨터 구조, 운영체제에 대해서 1도 모른다.
진짜 다행인 건 1학년때 C 언어를 배워서인지 "메모리를 할당해주고, 관리해줘야 한다는 사실"은 알지만, 그 메모리가 어디에 저장되며, 프로그램은 어떻게 실행되며... 이런 내용을 아직 공부하지 못했다.
FE에서 데이터, 화면을 더 빠르게, 불필요한 요청을 줄이도록 하기 위해 "캐싱"이라는 전략을 다양하게 사용한다.
In Memory Cache, Http Cache, CDN 등등
https://yozm.wishket.com/magazine/detail/2341/
프론트엔드 개발자가 알아야 할 ‘캐싱’ 개념 정리 | 요즘IT
프론트엔드 개발자라면 아마 웹사이트 성능을 최적화하는 것에 관심이 있을 것이다. 웹사이트 로딩 시간을 줄이고, 물 흐르듯 자연스러운 사용자 경험을 만드는 것은 비즈니스에도 큰 영향을
yozm.wishket.com
이때 "캐싱" 이라는 개념과 용어를 설명할 때 CPU 캐시를 많이들 언급하는데.. 이걸 언급하며 캐시를 설명하면 대체 CPU 캐시가 뭔데 할 수밖에 없더라...
babel이나 tsc를 통해 어떠한 방식으로 우리가 작성한 코드가 다른 코드로 변환될 수 있는지 신기했다.
abstract syntax tree라고 하는 것이라는 형태로 코드를 분석한다고 하는데..
처음 볼 때는 그냥 이렇구나 했는데 ESLint Custom Rule을 만들어야 했던 업무를 할 때 또 마주치게 되더라..
마지막으로 타입 언어에 대한 이해도도 부족할 수도 있을 것 같다.
내가 처음으로 접한 언어는 1학년때 배운 C언어
그 이후엔 파이썬이나 JS 같은 동적 타입 언어를 많이 사용하게 되었다.
아무리 지금 TS를 사용한다고는 하지만... 타입 시스템, 타입 언어에 대한 개념이 분명 부족할 것 같다.
TS에 갇혀있으니 Structural , Nominal Subtyping이라는 개념을 몰랐었다. (최근에 자바 보다가 처음 알게 됨)
몰라도 일은 되더라 ( = 직접 접할 기회도 적다)
지금까지 글을 보면 대체 이 인간은 어떻게 일을 했나 싶을지도 모른다.
사실 현재 기준으로 정말 신입으로 문을 두드리지도 못할 만한 실력일 지도 모른다.
그렇지만 어째서 나는 큰 이슈 없이 개발자 생활을 이어 나갈 수 있었을까?
사실 (적어도 지금까지 다닌 회사에서는) 신사업을 크게 하지 않는 이상 + 빠르게 서비스를 접고 만들고 하지 않는 이상
이미 다 세팅된 기존 코드에 기능을 덧붙이거나, 버그를 수정하거나 하는 일이 대다수였다.
그리고 어느 정도 규모가 안정되고, 역할이 나눠져 있는 팀이라면
- 데브옵스 → 배포 인프라 관리, 모니터링까지
- 백엔드 → API 만들어주고 서버 관리해 주고, 어... FE 입장에선 API 만 받아 연결하면 되었다
이렇게 FE 개발자는
기획과 디자인대로 화면을 그리고, 그릴 때 조금 더 성능에 대한 생각, 유지보수가 가능할만한 코드
(주로 컴포넌트지만... BE 보다 생각을 덜 하고 불안정적인 건 맞는 듯)를 고려하면서 FE 개발에 대한 집중만 할 수 있게 된다.
또한 일단 신입이었기 때문에, 기존 코드와 비슷한 형태(구조)로, 주어진 이슈(기능)를 버그 없이, 시간에 맞게 해결만 한다면
1인분은 하는 것이었고, 딱히 그런 면에선 문제가 없었다. 나는 또 다른 면(DX 개선 관심, 기술 공유)에서 강점이 있었기도 했고..
문제는 이런 생활에 익숙해지고 안주한다면 점점 놓치는 것이 많아지고, 생각+경험의 확장이 느려질 수도 있다는 것이다.
이는 곧 성장과 직결된다.
특히 CS 지식 (자료구조, 컴네, 컴구, 데베, 운체, SW공학, 컴파일러 등등)을 잘 모르게 된다면 새로운 기술을 배울 때나, 조금 더 어려운 기술을 공부하고 응용할 때 벽이 되는 경우, 배우는 속도가 느리게 되는 경우가 생길 수 있을 것 같다. 실제로 몇 번 경험하기도 했다. (AST, 캐시(LRU) 이벤트 버스의 Bus 등등)
아는게 한정적이면 창의적인 아이디어를 떠올리는데 한계가 있다. 모르면 안보이는 영역이 있으니.
또 만약 모르면 "기본 지식에서 이거 저거 끌어와서.. 이 개념을 빌려와서... 이렇게 해보면 기존 문제가 해결 될지도…??"
라는 시도 자체가 막힌다.
솔직히 저 위의 모든 것을 다 갖춘 신입(제대로 안다는 가정 하)은 존재하기 힘들다. 그런 유니콘 같은 존재는 유니콘에 가있더라..
그래도 회사를 다니며 업무뿐만이 아니라 꾸준히 내가 놓치고 있는 공부를 보충하는 것이 매우 매우 중요하다는 것을 알게 되었다.
그리고 이왕이면, (필요할 땐 당연히 해야 하지만 그렇지 않다면) NextJS의 Image 최적화, React의 useSyncExternalStore, xx 프레임워크 사용법, 리액트 xxx 패턴 이런 것을 공부하는 것보다 CS 관련 내용과 연결 지어 더 근본적인 공부를 하는 것이
더 확장성 있는, 멀리 갈 수 있는, 코파일럿을 이길 수 있는 개발자가 될 수 있는 길이 아닐까? 싶다.
사실 다른 시니어분들이나 교과서적으로 다들 많이 하는 이야기기도 하다.
그래서 나도 해봤다....^^
아 그리고 내가 부족했던 건 결국
"프로덕트를 기획부터 배포 운영까지" 1사이클을 돌아보지 못했던 경험 때문인 것 같다. (취업 전 웹 서비스를 만들어본 적이 없다)
일단 BE를 할 줄 알게 된다면 해결될 부분도 보이고, 내 사이트를 localhost에서 벗어나 (vercel 치워버리고) 직접 호스팅을 해보거나
나만의 서비스를 만들어보면 일부 해결 될 일 + CS 전공수업 들으면 (이제 3학년 1학기, 6 전공 렛츠고) 나아지겠지 싶다.
요약
- 빠르게 웹 개발자가 되기 위해 FE 개발자로 시작했다.
- FE 개발은 진입장벽이 생각보다 낮아, 많이 알지 못해도 일을 할 수 있었다.
- 그러다 보니 웹 개발에 있어 중요한 개념이나 놓친 것들이 많았다.
- 이는 회사에서 큰 문제가 없었다. 회사에선 업무가 명확히 분리되어 있고, 이미 구축되어 있기 때문에, 몰라도/안해도 되었다.
- 하지만 회사 일 '만' 한다면 계속 경험하지 못할 것들이 존재한다.
- 즉 이전에 몰랐던 걸, 계속 모를 확률이 높다는 것이다.
- 이렇게 시간만 지나간다면 물경력이 될 확률도 높아진다.
- CS의 부재가 큰 비전공 FE 개발자들은 확장성 있는 미래를 위해 CS 공부를 추천한다.
다시 돌아보니..
이전의 고민들이 참 웃기다. 실제로 부족했고, 못했던 것이 맞았다. 그래놓고 공부 안 하고 징징거렸다.
근거를 들 수 있는 책 하나 읽지 않고, 테스트를 논하고, 설계, 구조를 논했다.
이제는 정말 객관적으로 어떤 것이 부족했는지 더 명확해졌다.
정말 운이 좋게도 다시 집중해서 공부할 수 있는 시간이 주어졌다. 이 시간에 대해서 감사히 여기며 부족한 것들을 하나씩 채워나갈 것이다.
그래야 한다. 화이팅..
끝
'기술 메모장' 카테고리의 다른 글
| [토스 프론트엔드 멘토링] Frontend Accelerator 1기 참여 후기! (0) | 2024.08.20 |
|---|---|
| 잘하는 개발자를 보면서 포기하지 않기 (1) | 2023.12.17 |
| 오픈소스 저장소, PR에서 볼 수 있는 것들 (feat. react-query, @toss/slash) (2) | 2022.11.16 |
| 나의 코딩 컨벤션과 폴더구조를 소개합니다. #2 (스타일 가이드와 템플릿 레포지토리) (2) | 2022.10.18 |
| 나의 코딩 컨벤션과 폴더구조를 소개합니다. #1 (깃 컨벤션과 폴더구조) (1) | 2022.10.13 |