작년에는 회고가 없었지만 올해는 생각보다 정리할거리가 있어서 회고를 해보고자 한다
2021년 처음 코딩을 접했다. 사실 처음 접했던건 2학년 교양과목이었다. 이때 접했던 코딩은 아주 매운맛이었다. AOS 강의였는데 자바 문법을 안알려줬다. 이거면 얼마나 매운맛이었는지 짐작할 수 있다고 본다.... 교수님은 신나서 타이핑하시는데 수강생들은 열심히 따라치기 바쁘거나 포기하는 모습을 보고는 이런게 코딩이구나... 그러다 점차 문법들을 이해하고 스스로 최소한의 코드를 짜내고 결과물을 만들어 냈다.
그러다
21년에 국비로 코딩을 접하고
개발을 배웠다.
국비가 끝나고 공부를 하다 취업도하게 되었다.
그렇게 메인 기술스텍이 PHP가 되었다.
언어에 좋고 나쁘다 편견은 없지만 메인 기술스텍이 php인 점에서 약점 또한 될 수 있다고 짐작했다.
하지만 큰 신경을 쓰지는 않았다. 딱 하나 언어에 가리는게 있다면 내가 하고자 하는 코드에 부수적으로 달려야하는 코드들이 많은 언어는 안좋아한다. 이게 영어지문도 아니고 읽어야하는 특정 구간만 있는것도 가독성을 해치기 때문에 별로다.
우선 정리하기에 앞서 개발상황이 조금 변해왔던거같다.
이전에는 프레임워크라고 하면 풀 프레임워크 백, 프론트 둘다 지원되는 프레임워크 였다면 이제는 프론트와 백이 분리된 모습을 보이고 있다. 그렇다면 이런 모습도 가능해진다. 서비스별로 백엔드 언어와 프레임워크를 다르게 줄 수 도 있고, 기능별로 쪼갤 수 도 있고, 페이지별로 쪼갤 수 도 있다.
이게 아무래도 완전완전 큰 글로벌 대기업? 정도의 서비스 규모가 되면 정말 다양한 개발자가 모이게 되고 그런 개발자들은 원하는 기술을 발휘하기 위해 각각 다른 언어를 사용하고 그 다양한 언어를 지원하기 위해서 이렇게 쪼갠건 아닌가 생각이 든다.
백엔드만 말했지만 프론트도 얼마든지 가능하다. 각각의 서비스 별 프레임워크를 다르게 가져갈수있다. 한가지 다른점은 페이지별로 프레임워크를 쪼개는거는 안된다.
백은 API 주소를 만들어서 보낼 데이터만 만들면되고
프론트는 API주소를 요청해서 받은 데이터를 뿌려주기만 하면 된다. 하지만 서버 자원낭비 방지를위해 한번 받고 다시 쓸거같은 데이터는 프론트에서 따로 보관해야하고 관리해야한다.
추가로 이게 다시 성능상의 이유로 풀프레임워크로 돌아가는 분위기가 다시 보인다. 하지만 내 생각에는 이게 어느정도는 쪼개질것으로 보인다. 이유는 한번 쪼개진 기능들이 다양한 언어로 구현이 되어있다면 한가지언어로 합치거나 하나의프레임 워크로 합치기 위해서는 올라운드로 지원이 되는 프레임워크가 등장해야한다.
위에서 말한거처럼 약점 또한 될수도 있다는 것에서 나는 다양한 언어와 프레임 워크를 배워보기로 했다.
국비가 끝나고 공부를 하는 동안 자바 스프링 부트를 공부해봤으니 패스.
백엔드
js의 익스프레스 - 이건 조금 다뤘는데 뭔가 취향이 아니었다.
파이썬의 장고 - 확실히 코드도 많이 생략되었지만 생략된만큼 상상력으로 코딩하는 기분이나는 장고매직..
파이썬의 FastAPI - 이건 성능이 빠르고 다 좋았지만 인지도가 낮다는게 아쉬웠다.
프론트
리액트 - 기본 문법부터 html 스럽지 않았다. html을 리턴하는것도 이해하는데 어려웠고 input 이나 html 컨트롤을 위해서 따로 핸들러를 달아줘야하는거에서 일단 멘붕했다. 그리고 상태관리도 많이 어려웠다. 예제로는 리덕스를 사용했는데 파일을 여러개를 왔다갔다해야하고 엄청 어렵게 느껴졌다. 변화가 일어날때마다 알려줘야했던걸로 기억하고 라이브러리마다 자동으로 변화를 감지하는 것도 있다는데 확실히 가볍게 많이 배우려다보니 스킵한 것도 있다.
뷰 - 리액트를 보다가 뷰를 보니 선녀였다. 뷰는 초기에 점진적 적용을 목적으로 개발된거다보니 원하는 페이지에서만 뷰를 사용하고 빼고 할 수 있다는거에서 자유로웠다.
스벨트 - 스벨트는 처음 접했을때는 엄청 좋긴했다. 하지만 스벨트에서 권장하는 몇가지 규칙들을 어느정도 정하고나니 뭔가가 어색했다. html스럽긴 하지만 한가지 아쉬운게 뷰처럼 기존에 구현된 html 코드에 녹아들어갈 수 있도록 지원이 안되는거같아서 아쉬웠다. 하지만 스벨트에서 페이지 별 라우터를 볼 수 있게 지원해줘서 테스트 하기도 편했다.
여기서 앱은 어떨까라는 생각에 앱도 관심이 생겨서 플러터를 조금 배웠다. 플러터에서 사용하는? 상태관리 라이브러리가 몇개있는데 그중에 Provider와 GetX를 봤는데 확실히 이건 리액트스러웠다. 변화를 추적하기 위해 여러 사전 작업을 하고 최종적으로 변수를 담았을때 변수가 변했다는걸 알려야한다. 뭔가 좀 더 쉽고 간단한 방법이 언젠가는 나올거같다는 판단으로 플러터는 지켜보기로 했다.
이처럼 여러 프레임워크를 사용해보고 경험해보면서 느낀것은 다들 비슷한 동작을 하는데 어쩜이리 다 다르게 굴러가는건가 라는 생각이 들었다. 프론트에서 리액트가 나오고 다들 다양한 방향이 나오게 된건 리액트에서 변화된 요소만! 새로고침 한다는거에서 가장 큰 변화를 불러일으켰다. 웹에서 실시간 갱신 또는 일반적인 웹에서는 스크롤 유지에 주로 사용되는기능이다. 덕분에 위에서 말한부분말고 다양한 부분들이 비동기화되면서 웹이 앱과 비슷한 사용자경험을 주게되었다.
앞으로의 계획과 생각
앞으로의 웹과 앱은 어떻게 될지는 사실 잘 모르겠다.
플러터에서 하나의 코드로 AOS와 IOS를 둘다 지원이 가능하고 PC 웹과 PC 프로그램까지 지원을 목표로 한다는데 여기서 궁금한거는 이거다.
그럼 HTML 코드를 코틀린, 스위프트로 변경해서 빌드하면 되겠네?
그렇다면 역으로도 앱으로 짠 코드를 여러 방식으로 변경해서 빌드하면 되겠네?
끝으로
프레임워크들을 여러가지를 다뤄보면서 너무나도 피곤해졌다. 시간도 많이 썼다. 다들 본인의 프레임워크가 좋다길래 얕게나마 써봤다.
사실 언어와 방식만 다르지 차이가 거의 없다. 각 프레임워크별 지원하는 기능이 당장은 다른게 있더라도
시간이 지나면 분명 지원되거나 다른식으로 풀어나간다.
근본적으로 다가간다면 나의 생각은 백에서는 서버 자원 많이 안쓰고 성능 좋은게 장땡이다.
이걸 코드로 잘 풀어나가는 것 또한 중요하다. 프론트는 백에서 했던말 또 안하게 잘 관리하는게 중요하다.
내년에는 프레임워크 공부는 어느정도 마무리하고
개발에 대해 더 깊게 배우는 것을 목표로 가지고 가야겠다
서버라던지, 보안이라던지, 어떻게 협업을 잘할 수 있는지 이런 부분 공부를 해야겠다.