들어가면서

이번 글에서는 무엇을 하고 싶은지에 대해서 써보려고 한다.
아마도 현실보다는 이상향에 대한 글이겠지만 현실적인 글이 되길 소망하며 글을 시작한다.

Front End Engineer 는 무슨 일을 하시나요?

최근 면접 혹은 그와 비슷한 만남들을 진행하며 큰 고민이 생겼다. 프론트엔드 개발자의 최소한의 기술 검증을 하기 위해서 몇가지 질문들을 정리해 보았다. html, css, javascript 에서 한문제 front end 제품 동작 환경에 대해서 한문제 줄이고 줄여서 5개 정도로 좁혔다.
이 질문에 답을 잘하면 좋은 Front End Engineer 인가? 흠.. 아직도 확실한 인정을 못받았고 조금의 수정을 거치며 문제들을 들고 가고 있다.

web 은 나에게 무엇이었을까?

제일 처음에 접한 web 은 CSR 이었던 것 같다. 하지만 그 이후로는 당연히 서버에서 무언가 처리를 해야 하는 것이고, 혹 이 일을 업으로 삼으면 내가 많이 잘 안되고 있는 그런 무언가로서 다가왔었다.

홈페이지 숙제

단순히 나의 정보를 html 로 만들어 올리는 숙제를 받았던 것 같다. 아마 교양과목이었을 것이었다. 내가 나온 학교는 1학년 1학기는 수강신청을 그냥 해서 줬었다. - 그게 그렇게 불합리하다고 생각했지만 편하다고 느껴지는 데 그리 오랜 시간이 걸리지 않았긴 하다.
그래서 하고 싶은 것은 아니었으나 나모 웹 에디터 같은 것을 써서 대강 올리면 되는 숙제 였던 것 같긴 했다. 당시에는 마퀴로 글자도 흘려 보내고 그러던 시절이긴 했었어서 나름 html 로 만으로도 잘 커버가 되었었다. 하지만 CSS 를 조금 버무려야 했고, 커서를 따라다니는 신기한 이미지 리소스를 넣어야 뭔가 핫해보기긴 했었다. 그렇게 만든 html, css 혹은 약간의 javascript 파일을 어떤 경로에 올리면 서버가 잘 가져갈 수 있게 응답해 줬었다.

index.html

당시 index.html 이 없으면 해당 경로에 속한 파일 모두를 보여주는 UI 를 응답하는 서버들이 거의 다수였었다. 혹은 conf 를 수정하여 특정 경로에 가게 되면 내가 설정한 파일을 우선 응답해줄 수 있게 해주는 그런 식으로 서버가 돌아갔다.
물론 당시 정적 스토리지라고 하기에는 민망할 수 있는 그냥 하나의 PC 였고 그 PC 는 쉬지 않고 돌아가는 서버 어플리케이션에 따라 외부 응답을 잘 답변해주었었다.
나는 그렇게 서버에서 클라이언트가 받아 랜더링 할 수 있는 html 및 그 외의 무언가들을 만들어 보았었던 것 같다.

DB 숙제를 위한 증명 도구

DB 과목에서 그렇게 큰 나이스한 학점을 받지 못하였었다. 생각해보면 그럴만도 한 게, 나는 대학 졸업을 포기하고 1년 반을 보냈고, 뒤 늦게 정신을 차린 반년을 지난 후에 미쳤다고 6개의 전공을 신청한 상태였었다. 게다가 이 과목의 과제는 팀 과제였었는데, 나의 파트너는 이미 취업이 된 분이셔서 나는 혼자 갈 수 밖에 없었다. 사실 과제 제출 전에 그의 이름을 뺄까 고민도 많았지만 뭐 그 정확한 결과는 밝히지 않기로 한다.
다들 손이 비니 JSP 로 멋지게 스타일도 씌워서 만들어 놓더라. Oracle 을 사용하면서 말이다.
하지만 당시 MS 쭉 툴들을 더 다루었기에 ASP - 사실 다시는 안할 줄 알았다. 다시 만날줄은 몰랐다. - 로 DB 숙제 증명을 위한 툴을 만들었다.
간단하에 어떤 id 로 접근하면 page 를 접근하면 해당 entity 혹은 무언가를 join 해서 보여주고 그 정보를 살짝 수정해서 form submit 을 하면 DB 에 수정을 하여 처리를 하는 그런 과제 였었다.
딱 스팩만 구현했었고 그럭저럭 동작 했었다. 그리고 이런 일을 다시 하지 않으리라 생각했었던 것 같다.
정말 시대 흐름을 못따라갔었다.

그러다가…

그러다가 web browser core 를 만드는 회사를 갔었다.
사수셨던 나의 은인 - 하지만 연락을 드리지 못하는… - 분께서 어플리케이션이 무엇인지 물어보셨던 것 같다.
특별하게 고안된 임베디드 기계들이 그저 해봤자 시리얼 통신 정도만 하는 그저그런 메인프레임워크도 아닌 덜떨어진 무언가를 그렸었었다.
예상할 수 있겠지만 많이 혼났다.
그리고 웹 어플리케이션을 떠올릴 수 없다면 이 회사에서 더 일할 수 없음을 단박에 깨우쳐 주셨던 것 같다. 그 때 부터 열심히 봤다.

그래서 나는 무슨 일을 하는가?

최근 나는 함께 일하는 동료들과 1:1 을 달마다 꼭 한번은 진행하고 있다. 그러면서 조언을 감히 주기도 했었고 그 조언이 잘 납득이 되거나 되지 않거나를 경험하면서 다시 나에 대한 도전들이 생기고 있다. 약간 아쉬운건 내 상위 상급자와 탄탄하게 1:1 을 하는 환경이 못되고, 창배님은 알아서 잘 하겠지가 많이 이어지는 편이라 나의 억울함이나 나의 안탁가움은 잘 털어 놓지 못하고 있다. 그때 마다 나의 친구 혹은 친구에 준하는 예전 직장 동료 들이 그 부분을 갯벌과 같이 담당해주곤 한다.
그럼 나는 1:1 하는 사람인가?
아니다.

최근 NextJS 와 React 에 대해서

최근 NextJS 를 얼만큼 잘해야 하는 지 정말 잘 모르겠다. 나는 단순히 CRA 의 대체로 사용하고 있고 그리 심도 있게 SSR 을 생각해보지 않는다. 왜냐하면 거의 대부분은 사용자 inter action 이 필요한 페이지를 만들기도 하고 그 과정에서 SSR 이 큰 장점을 나타내지 못한다는 생각이 많이 든다.
예를 들면 나는 리스트를 보여주는 페이지를 만든다. 사실 이 리스트가 어느정도 정적이고 수정 가능하지 않는다고 하면 SSR 이 아닌 SSG 정도로 미리 잘 짜두어서 성능? 정도를 처리할 수 있을 것 같다.
하지만 그저 단순히 list 부분은 server side props 으로 만들어서 page 전달 때 주입한다고 친다면… 내가 페이지에서 수정하고 나면 그 list 들은 어떻게 받아야 할지 잘 모르겠다.
그런 의미로 NextJS 가 어떻게 hydration 하는지 등등에 큰 관심은 없다.
그저 그냥 내 의도대로 잘 동작하기만 바랄뿐이다.
이 글은 또 나의 손으로 스스로 박제하여 나를 얼마나 창피하게 만들지 모르겠지만, 굳이 이렇게 남겨 보려고 한다.
html 내에 javascript 가 속하면 랜더링이 기본적으로 멈춘다. 곧 html 을 내려 줄 때 javascript 가 끼면 생각한 SSR 느낌 처럼 그렇게 나이스 하게 화면이 바로 짠 나타나지 않는다. 사실 html, css 로 만든 페이지가 스륵 내려가고 - 기본 값이 이미 html 에 박혀 있는, 게다가 서버 연산도 거의 적게 처리된 - 해야 그나마 좀 빠르다.
그냥 서버에서 무언가 잔뜩 받아서 처리한다면 내가 대학 다닐때 ASP 할 때랑 그렇게 큰 차이가 없을 것 같다는 생각이 든다.
그래서 NextJS 에서 어떻게 동작하는지는 관심이 없고 어떤 option 이 있는지만 관심이 있다. 물론 그 option 의 흐름까지 이해를 하면 option 을 잘 사용하는 것이겠지만, 다시 빙 돌아 이야기 하면 그렇게 이해야하는 option 은 잘 된 option 인지 모르겠다.

그럼 뭘 잘하려 하는가?

나는 그저 그냥 코드를 잘 짜고 싶다.
Client Side 에서도 동작할 수 있고 Server Side 에서도 가볍게 동작할 수 있는 layer 를 잘 만들고 싶다. 그리고 그 아래 Client Side 를 잘 활용한 컴포넌트들을 잘잘 만들어 내고 싶다.
기본 기능에 대한 동작 만족과 그 만족을 위한 최적화된 코드 정도까지를 집중하고 싶다.
하지만 현실은 그렇지 못한 것 같다. 일정도 파악해야 하고, 현재 상황에 맞게 적절한 현 조직의 기술 역량에 맞는 무언가를 만들어내야 하고 등등 해야 한다.
그리서 사실 요새는 FE 에 집중을 한 무언가를 만들어 내 보거나, FE 도 아는 그저 프로그램 언어 레벨에서 혹독하게 고민하고 그 고민으로 한줄한줄 겨우 짜서 나온 무언가를 만들어 보고 싶다.
그것은 알고리즘도 아니고 NextJS 상의 어떤 옵션도 아니고 당연히 NestJS 나 Spring 은 더더욱이 아니다.

어떤 방향을 보아야 할까?

내 상황에서 혼자 무언가 순수하게 바닥에서 부터 만들어 보겠다는 것은 직무 유기라고 생각한다. 물론 직무 유기라는 단어가 요새 무서운 단어고 어떻게 해석 될지 두려운 단어지만 감히 골라 본다.
여러 현실 상황속에서 어떤 기술을 차용해야 할지 어느 정도 깊이로 차용하는 것이 괜찮을지 의견을 내는 것이 당연히 중요한 기준이라고 생각한다. 나는 코드 깍는 노인이 아니고 월급받는 엔지니어 이기 때문이라 그렇게 해야 할 것 같다.
그럼 그 기반 위에서는 보다 투명한(?) 코드를 짜 내야 할 것 같은데, 그러기 위해서는 지저분한 영역들을 잘 감당할 영역을 담당할 곳을 만들어 내는 것을 잘 생각해야 할 것 같다. 그래서 나의 투명에 가까운 소주를 많이 탄 느낌의 맥주같은 코드가 어디에서도 잘 동작할 수 있게 해야 하지 않을까 싶다.
그것이 내가 생각하는 소프트웨어 아키택트가 아닐까 생각해본다.
마치 소프트웨어 설계는 무언인가요? 라는 질문을 받았을 때 하나 하나 답변을 해 본후, 그 답변중 우선순위가 낮은 것들을 다 지우고 또 지우고 해서 하나만 남겨 놓았을 때의 결과가 이것이지 않을까 싶다.
무언가 지키기 위해서는 그만큼 불편함을 감수해야 하겠지…

급박하게 마치면서

결국 나는 어떤 일을 하는 사람인가? 할 때 결국 소프트웨어 엔지니어라고 하고 싶다. 그러고 어떤 소프트웨어 엔지니어인가요? 라고 할 때 나 혹은 여러 사람들이 같은 목적을 가지고 열심히 일을 하는데 시너지가 나게 일을 하는 그런 엔지니어라고 하고 싶고 그 기반을 만들면서 일하는 사람이라고 하고 싶다.
그럼 어떻게 그렇게 하세요? 할 때 결국 사용하는 기술의 의존성이 없는 무언가를 만들면서도 기술 적용을 빠르게 하고 있는 구조를 가지고 있어요 하고 싶고, 그 기반에는 순수 영역과 응용영역을 잘 나누는 판단이 있기 때문이라고 답변하고 싶다.
이것은 인프라웨어의 포팅 영역이거나, 컴구조의 쿼리인터페이스거나 함수형 프로그램의 액션, 계산 그리고 데이터 거나 디자인 패턴의 앱스트랙션 메소드의 추상 영역과 임플리멘테이션 구획 등등으로 항상 다른 이름으로 같은 느낌으로 나에게 다가왔던 것이라고 생각한다.
전혀 새로울 것은 없지만 항상 새로운 마음으로 다가가야 할 영역을 지켜가는 것이 나의 직업이라고 하고 싶다.
그렇게 잘 하는 지 내일 부터 잘 단속을 해 봐야겠다.