1년 반의 첫 회사 생활을 마쳤다.

I'm Left, You're Right, He's Gone

모든 것에는 저마다의 합리적인 이유가 있다. 저마다의 맞음이 동시에 설 자리가 없을 때, 우린 이별한다. 눈물 대신 춤을 택하고, 미러볼은 어김없이 돌아간다. 반사된 빛의 조각들이 무겁고 찌뿌둥한 삶의 틈새를 구석구석 비춘다. 관절 하나하나가 불꽃처럼 터지며, 나는 외친다. 단 한마디로 — 자유!

퇴사 후, 나 스스로에게 한 달의 시간을 주었다. 그 이상 쉴 수 없을 것 같았기에. 그간 미뤄 놓았던 책들을 전부 읽었다. 전시란 전시는 모조리 보러 다녔다. 혼자 말하는 작가와 대화하는 작가의 차이를 느꼈다. 새로운 장소에서 새로운 사람들을 만났다. 그들은 진정, 연구자(Researcher)이자 수집가(Archiver)였다. 기술 전에 삶이 먼저 존재한다는, 그 당연한 사실을 다시금 파헤치고 드러내려는 사람들. 낡은 확신을 벗어던지고, 자리를 박차 일어나, 동시대 사람들의 이야기에 겸허히 귀 기울이는 이들. 필요를 섣불리 단정하지 않고, 끝내 ‘찾아내는’ 이들.

이들을 만나 무척 기뻤지만, 동시에 조금은 슬퍼지기도 했다. 개발을 시작했을 때의 마음가짐과 지금의 마음이 너무 달라져 버렸기 때문이다. 처음엔 사람들에게 도움이 되는 무언가를 만들고 싶었는데, 어느새 정신을 차리고 보니 기술은 단지 돈을 버는 수단으로만 남아 있다. 처음 공허함을 느꼈을 때는 개발이 나를 이렇게 만들었다고 생각했다. 하지만 그게 아니었다. 중요한 것은 ‘가치’였다. 나는 정말 가치 있는 것을 만들고 있는가? 그건 누구에게, 얼마나 가치 있는가? 그리고 그 가치가 나 자신에게조차 설득력을 지니는가?

회사를 나온 이유는, 내가 만들어내던 가치가 나에게 더 이상 설득되지 않았기 때문이다. 하지만 누군가에게는 충분히 설득되었을 것이다. 그건 좋은 일이다. 같은 가치를 좇는 이들과 함께하는 것은 분명 행복한 일이니까. 지금은 새로운 만남을 준비 중이다. 아마 또 다른 가치를 좇게 되겠지.

양재천에서 LiDAR로 돌다리를 스캔하여 Polycam으로 렌더링 해보았다. 세 번째 사진은 실제 돌다리, 네 번째 사진은 다리가 없는 곳에 증강현실로 구현한 돌다리다.

취업 성공

폭풍 같은 한 해가 지났다. 하던 일 그만두고 개발자 한다던 아들은 정말 개발자로 취업했다. 엄마와 아빠는 풍악을 울렸고, 누나들은 서울에 공짜 숙소가 생겼다며 좋아했다. 모두가 웃는데 나는 되려 걱정이 많다. 새로운 장소, 새로운 사람들, 30대에 접어든 나.

바뀐건 없다

2023년 계획 : 공부하고 협업하고 개발한다. 2024년 계획 : 공부하고 협업하고 개발한다.

전년에도 신년에도 내가 할 일은 정해져 있다. 거창한 목표들에 얽매이지 말고, 매 사건에 감정적으로 동요하지 말기. 너무 단단한 계획은 부서지기 마련, 유연하고 융통성있게 사고하기. 차분히 우직하게, 한 걸음, 또 한 걸음. 태도와 습관이 길을 만든다.

취업 전, 가장 나를 곤란하게 했던 질문

어떤 도메인에 가고 싶어요?

시니어 개발자님께 멘토링을 받을 기회가 생겼는데 위와 같은 질문을 주셨다. 대답이 떠오르지 않았다. 사실 대답을 할 수 있었다면 그게 더 이상한 일이다. 취업 혹한기다. 신입 개발자 갈 곳 없다. 들여다 보내주는 곳에는 그냥 무조건 들어가야 된다. 라는 말을 많이 들었고, 기술만 열심히 공부하고 취직하면 카멜레온 처럼 적응해야 겠다고 생각했던 내가 제대로 대답할 수 있을리가 없었다. 사실 울타리에 나를 가둔건 나 자신이다. 스스로를 믿지 못했던 것이다. 자신을 믿지 못하는 사람이 서류와 면접에서 "내가 당신이 원하는 바로 그 끝내주는 사람이다" 라고 어필한다?... 말이 안되는 것이었다. 고민은 다음과 같은 질문으로 이어졌다.

믿음은 어디서 나오나?

비전공자 개발자 취준생이라면 한 번 쯤은 필연적으로 도달하게 되는 문제, 바로 믿음이다. 종교적 믿음을 이야기 하려는 것이 아니다. 이성적인, 아주 차가운 이성에서 비롯한 믿음에 관한 것이다. 지금껏 내가 왜 객관적으로 부족한지 질문해 왔다면, 이제는 왜 내가 왜 객관적으로 훌륭한지 질문해 보자. 물론 균형이 중요하다. 전자의 질문에 치중하면 비관주의자가 될 것이고, 후자의 질문에 치중하면 비대한 자아로 똘똘 뭉친 나르시스트가 될 것이다. 하지만 필자의 입장에서 비관주의자가 되는 것이 나르시스트가 되는 것 보다 상대적으로 쉽다고 생각하기 때문에, 방향을 나르시즘 쪽으로 잡는게 밸런스 유지에 도움이 된다고 생각한다. 첫째로 한국은 치열한 경쟁 사회고, 둘째로 다양한 소셜 네트워크 서비스가 우리를 비교 문화에 노출 시키며, 이러한 환경에 놓인 개개인이 자신을 사랑하기란 그리 쉬운 일이 아니기 때문이다. 철저한 자기 객관화로 자신의 강점을 발견하고 그것을 사랑하자. 사랑은 믿음이 되고 믿음은 자신감이 된다. 앞의 과정이 끝났다면 내 이력서와 포트폴리오가 내가 가장 자신 있는 부분을 잘 드러내고 있는지 확인하자. 모든 것이 끝났다면 (물론 이력서와 포트폴리오에는 완성이라는 개념이 없지만) 이제 나는 아더이고, 나의 서류는 엑스칼리버다. 그러나...

운칠기삼

운이 7할이고 기세가 3할이라는 말이다. 내가 조니 뎁이라도 상대방이 크리스 햄스워스 같은 마초 스타일을 좋아하면 어쩔 수 없는 것이다. 거절 당하더라도 좌절하지 말고 당신이 조니 뎁이라는 사실을 잊지 말자. 조니 뎁을 좋아하는 사람은 분명 있다. 나 같은 비전공자 배불뚝이 30대 삼촌을 좋아한 회사가 있었듯이...

디지털 트윈

마침 회사 얘기가 나왔으니, 이번에 취업 한 곳에 대해 이야기 해보려고 한다. 디지털 트윈을 기반으로 자체 서비스를 만드는 스타트업으로 서울에 있다. 현실에서 주기적으로 광범위한 데이터를 수집하고 가상 세계에 동기화 한다. 현실에서 벌어지는 일이 가상에 영향을 미치고, 가상의 시뮬레이션이 현실에 영향을 미친다. 둘은 둘이기도 하고 하나이기도 하다. 강릉원주대학교 멀티미디어 학과의 최재홍 교수님께서는 가상과 현실이 서로를 돕는다는 점에서 디지털 트윈(Twin)이라는 용어 보다는 디지털 페어(Pair) 라는 용어가 더 어울린다고 말씀 하셨다. 트윈은 개발자의 손에서 태어난 "쌍둥이 세계"라는 관점에서 어울리고, "협업하다" 라는 동사적인 측면에서는 페어라는 워딩도 썩 괜찮은 듯 하다. 자율주행, 건축, 버추얼 산업 등 다양한 곳에서 활용될 수 있고, 이 중 어떤 사업에 적용되냐에 따라 내가 프론트엔드로 수행해야하는 업무의 성격도 정해질 것 같다. 아주 흥미롭다. 다만 공부할 게 많아서 걱정이다.

공부와 절대시간

공부 얘기가 나와서 하는 말인데, "많이 하는게 중요한게 아니다. 오래 하는게 중요한게 아니다." 라는 말 들어 보았을 것이다. 반은 맞고 반은 틀린 말이다. 샌드위치 1개를 만들어 본 사람과 샌드위치 100개를 만들어 본 사람은 분명한 차이가 있다. 과연 코딩이라고 다를까? 사실 필자의 경우 객관적으로 돌머리고, 남들보다 두 배, 세 배는 노력해야 지식이 머리 속에 자리잡는다. 천재 타입이 아닌 나 같은 사람은 결국 노력으로 승부를 봐야한다. 내세울 수 있는 거라고는 체력과 끈기, 그리고 집요함인데 이거라도 있어서 다행이다. 다만 개발자로 오래 일하려면 건강 관리 잘 해야 한다. 장염 걸려서 새벽 온종일 토하고, 응급실 가서 링거 맞고, 오후에 프로젝트 하러 갔던 기억이 있는데... 정말 끔찍하다. 건강 챙기자.

새해에는 모두 건강하길

다 먹고 살자고 하는 일 아닌가. 몸 건강, 마음 건강 챙기자. 행복한 사람이 주변도 행복하게 만든다. 개발자에게 가장 중요한 덕목 중 하나가 협업 능력 아닌가. 자신에게 사랑을 듬뿍 주자. 사랑이 없다면 나눌 사랑도 없기 때문이다. 사랑 많은 개발자가 되자.

본 게시물은 JSConf의** 어쨌든 이벤트 루프는 무엇인가?** 를 참고하며 작성되었다. 다만 싱글 스레드에 대한 정확한 이해 없이는 콜스택과 큐가 뭔지, 웹 API는 왜 필요한지 등에 대해 기술하는 것이 시기상조라 생각되어 본 글을 먼저 작성한다.

https://www.youtube.com/watch?v=8aGhZQkoFbQ&t=89s

싱글 스레드

자바스크립트는 싱글 스레드(Single-thread) 언어다. 싱글은 하나, 스레드는 컴퓨터 프로세스 내에서 실행되는 작은 작업 단위를 말한다. 싱글 스레드는 이 두 개념을 합친 것으로 '한 번에 하나의 작업만 처리되는 환경'을 말한다.

하나에 하나의 작업만 처리 할 수 있다는 것은 일종의 제약이다. 하나의 작업이 끝나기 전까지는 다른 작업을 수행할 수 없다는 것을 의미하기 때문이다.

useToilet(first_person); // 첫 번째 사람이 화장실을 이용한다.
useToilet(second_person); // 두 번째 사람은 첫 번째 사람이 나오기 전까지 화장실을 이용할 수 없다.

앞의 작업이 길어져서 뒤의 작업이 실행되지 못하고 있는 것, 이것을 블로킹(Blocking) 이라고 한다.

그렇다면 왜 "굳이" 제약이 있는 언어를 개발한 것일까?

*"굳이" 더 복잡한 구조가 필요하지 않았기 때문이다. *

자바스크립트가 등장한 초기에는 단순한 이벤트 기반 모델이 필요했다. 당시 웹 페이지와 애플리케이션은 주로 A라는 입력이 들어오면 B라는 출력이 되는 간단한 동작을 수행하는 것이었다. 이러한 상황에서는 싱글 스레드 모델이 코드를 단순하게 작성하고 유지보수하는 데에 도움이 되었다. 코드의 실행이 한 번에 하나의 작업만 처리되는 구조가 예측 가능하고 이해하기 쉬웠기 때문이다.

그러나 웹 기술이 진화하며, 동시에 브라우저에서의 요구사항과 복잡성 또한 증가했고, 싱글 스레드 모델의 한계가 나타나기 시작했다. 브라우저에서는 더 많은 동시성과 비동기 작업이 필요했고, 이에 대한 요구를 충족시키기 위해 멀티 스레드(Multi-thread)와 비동기 프로그래밍(Asynchronous Programming)이 중요해졌다. 자바스크립트는 이러한 환경에 대응하기 위해 발전하면서, 싱글 스레드의 제약을 극복하고 보다 복잡하고 효율적인 구조를 채택하게 되었다.

멀티 스레드

하나의 주방에서 여러 명의 요리사가 일하는 환경을 생각해 보자. 요리사들은 같은 공간에 있기 때문에 재료를 공유할 수 있으며, 한 번에 하나의 요리가 아닌 여러가지 요리를 동시에 할 수 있기 때문에 효율적이다.

*"환경은 멀티 스레드, 요리사는 스레드, 주방은 프로세스, 그리고 재료는 리소스라고 생각하면 된다." *

정리하자면, 멀티스레드 환경에서 여러 스레드들이 하나의 프로세스 안에서 함께 일하며 리소스를 공유하는 것이다.

그런데 같은 재료를 두 명의 요리사가 동시에 집으려고 할 때, 손이 꼬이거나 할 수 있다. 이것을** 경쟁 조건(Race condition)** 이라고 한다. 이때 요리사들은 사고를 방지하기 위해 규칙을 세운다. 만약 동시에 같은 재료를 원한다면, 누가 먼저 쓰고, 다음에 누가 쓸지 정하는 것이다. 이것이 바로 동기화 메커니즘(Synchronization Mechanism)이다. 두 스레드가 하나의 공유 자원에 동시에 접근할 때, 예상치 못한 에러를 방지하기 위해 사용하는 순차적 작업 규칙이라고 이해하면 된다.

싱글 스레드와 멀티 스레드, 동기와 비동기는 같은 개념일까?

"다른 개념이다."

환경(Environment)과 동작(Behavior)의 차이로 이해하면 된다. 싱글 스레드와 멀티 스레드는 어플리케이션의 실행 환경에 관한 것이고, 동기와 비동기는 작업 완료와 프로그램의 제어 흐름에 관한 것이다.

싱글 스레드 환경에서의 동기와 비동기

싱글 스레드 환경에서 비동기 작업을 처리할 때, 주로 웹 API나 외부 서비스에 요청을 보내고 그 요청에 대한 응답을 기다리지 않고 다른 작업을 계속한다. 이때 싱글 스레드의 비동기 작업은 외부 에서 처리된다고 볼 수 있다. 즉, 추가 주문이 들어오면 요리사가 외부에서 뒷 주방 요리사를 고용하는 것과 유사하다.

싱글 스레드 환경에서는 여러 명이 함께 일하는 것이 어렵고, 필요하다면 외부에서 자원을 끌어와야 하는 제약이 있다. 이것이 싱글 스레드의 특징이다. 요리사가 한 번에 하나의 음식을 만들고, 그 다음에 다른 음식을 만드는 것은 동기적인 동작에 해당하며, 앞 주방 요리사가 요리를 하는 동안 뒷 주방 요리사가 다른 요리를 만들고 완료되면 앞 주방 요리사에게 넘겨주는 것이 비동기적인 동작이다.

멀티 스레드 환경에서의 동기와 비동기

멀티 스레드는 다르다. 이 환경에서는 웹 API나 외부 서비스의 도움이 필요하지 않고, 멀티 스레드 간의 협력과 조율에 의해 작업을 처리할 수 있다. 이미 여러 명의 요리사가 한 주방에서 일할 수 있는 환경이기 때문이다. 이는 멀티 스레드가 각각의 작업을 독립적으로 처리(동기)하면서도 필요한 경우에는 서로 협력하여 효율적으로 작업을 수행할 수 있다는 것(비동기)을 의미한다.

결국 다 알아야 되는 때가 온다

devFest 2023 songdo

최근 Dart와 Flutter에 관심이 생겼는데, 마침 devFest에서 관련 세션들이 열린다고 해서 방문하게 되었다. 행사는 오후 1시 시작 이었고 5시에는 다시 지방으로 내려가야 했기에 아쉽게도 모든 발표를 듣지는 못했지만, 참여했던 세션들 중 김승빈 개발자님의 주제가 개인적으로 가장 인상 깊었다.

발표 내용은 Flutter가 분명 크로스 플랫폼 프레임워크이긴 하지만, 각종 예상치 못한 문제들에 대처하기 위해 네이티브 관련 코드를 이해하고 작성해야 되는 순간이 온다는 것이었는데, 플러터뿐만 아니라 개발에 대한 종합적인 학습과 접근을 강조하는 이야기여서 흥미로웠다.

요기요의 임성호 개발자님의 Rendering Patterns 세션도 같은 맥락으로 이해할 수 있었는데, 렌더링 패턴은 단순히 CSR, SSR, SSG만 있는 것이 아니라, 그것 외에도 수 없이 많고, 기획 단계에서 그 장단점과 효율을 적절히 비교할 수 있는 역량을 길러야 한다는 것이었다. 초기 페이지 로딩 시에 서버에서 렌더링하고, 이후에는 클라이언트에서 동적으로 업데이트하는 방식인 Universal JavaScript(Isomorphic JavaScript)을 Next.js에서 적극적으로 활용한다는 것을 들었는데, 관련 기술인 Code Splitting 등을 따로 공부할 필요가 있겠다.

세션에서 추천 받은 렌더링 패턴 관련 사이트인 Patterns

서버는 결국 누가 하나?

Next.js는 확실히 뜨거운 감자다. 이번 행사에서도 관련 질문이 나왔는데, 프론트와 백의 경계가 희미해지고 있고, 그렇다면 서버는 결국 누가 해야하나? 라는 것이었다. 일반적으로 SSR은 초기 로딩 성능과 SEO를 개선하는 데 도움이 되고, 백엔드에서 서버를 실행하는 경우에는 데이터 처리와 관리가 중요한 상황에서 유용하니, 적절히 프로젝트 상황에 맞춰 결정해야 하는게 아닌가 싶다. 한 가지 확실 하다고 생각되는 부분은, 이제는 프론트건 백이건 서버에 통달하는 편이 좋다는 것이다.

좋은 질문과 좋은 대답

의료 관련 기업 부스에서 자체 제작한 리액트 프레임워크를 사용한다는 이야기를 들었다. 나는 "와, 그렇구나. 신기하다." 정도 였는데, 옆에서 같이 설명을 듣고 계시던 분이 "그렇다면 리액트 버전이 바뀌면, 자체 프레임워크도 같이 업그레이드 되는건가요?" 라고 질문하셨다. 조금 과장하자면, 나는 이 질문을 듣자마자 머리에 돌을 맞은 기분이었다. 질문이 핵심을 파고 들었기 때문이다. 나만 회사를 필요로 하는 것이 아니라, 회사 또한 나를 필요로 하기 때문에, 면접자 입장에서는 사내에서 기술 부채가 꾸준히 메꿔지고 있는지 확인해야 한다. 기술에 대한 전반적인 이해와 자신감 없이는 절대로 할 수 없는 질문이라는 생각이 들었고, 학습에 대한 원동력을 주었다. 하얀 마스크를 끼고 있던 그 분, 감사하다.

서울 놈들, 자기들만 재밌는거 다 해!

900명 이상이 참여 하는 개발 행사라니. 지방러로서 참 부러운 일이 아닐 수 없다. 이 곳 지방에서도 다양한 행사가 열리지만, 이번 devFest 처럼 보다 규모있는 개발 행사들이 기획될 수 있다면 좋을 것 같다. 나라도 조그만한데 우리 경험의 민주화 합시다!

여담

외국에서 방문한 친구가 IT에 관심이 많았던 터라 같이 행사에 참여했는데, 영어 통역이 지원되는 세션이 많이 없어서 아쉬웠다고 한다. 한국으로 건너온 노마드 코더들도 함께 즐길 수 있는 행사가 되면 더욱 다채롭고 흥미로울 것 같다. 또한 개발자들 뿐만 아니라 업계나 기술 자체에 관심이 많은 사람들도 흥미롭게 볼 수 있는 generic한 세션들이 더 많이 추가 되어도 좋을 것 같다. 이러한 아쉬움에도 불구하고, 훌륭한 인사이트를 많이 얻을 수 있었기 때문에, 나는 이번 devFest 에 별 다섯 개를 주고 싶다.

클로저는 떠나야되는 기차를 앞에 두고 서로를 놓아주지 않는 연인과도 같다.

로맨틱 (Romantic Closure)

function createLoversClosure() {
    let lover1 = "외부 함수의 변수 (lover1)";

    function loversRelationship() {
        let lover2 = "내부 함수의 변수 (lover2)";

          // 핵심 코드
        console.log(`${lover2}는 ${lover1}을 떠나 보내지 않을거야!`);
    }

    // 클로저 반환
    return loversRelationship;
}

// 클로저 생성
let loversClosure = createLoversClosure();

// 클로저 호출
loversClosure();

코드의 구조는 아래와 같다.

• createLoversClosure은 내부 함수 loversRelationship을 감싸고 있다.

• 내부 함수 loversRelationship의 console.log()는 외부 함수의 변수 lover1을 참조하고 있다.

• 외부 함수는 내부 함수를 return하며, 이 반환값을 최상위 스코프의 변수 loversClosure에 할당한다.

• 즉, loversClouser를 호출하는 것은 내부 함수 loversRelationship을 실행하는 것과 같다.

• loversClouser는 언제나 lover1을 열정적으로 끌어 안은 채 (참조 하며) 호출된다.

로맨틱의 핵심은 외부 함수의 변수 lover1을 참조하고 있는 내부 함수의 console.log()다. 즉 저 핵심 코드가 없다면...

안 로맨틱 (Unromantic Closure)

function createLoversClosure() {
    let lover1 = "외부 함수의 변수 (lover1)";

    // 내부 함수는 더 이상 외부 변수를 참조하지 않는다.
    function loversRelationship() {
          let lover2 = "내부 함수의 변수 (lover2)";
        console.log(`${lover2}: lover1, 너는 차였다.`);
    }

    return loversRelationship;
}

let brokenLovers = createLoversClosure();

brokenLovers(); // 더 이상 로맨틱 하지 않게 되는 것이다.

로맨틱과 안 로맨틱은 유사해 보이지만 분명한 차이점이 있다.

내부 함수 loversRelationship은 외부 변수 lover1에 접근할 수는 있으나 참조하지는 않는다는 점이다.

만약 클로저가 안 로맨틱 하다면 어떻게 될까?

떠나라

lover1은 마침내 알아차렸다. 아무도 그를 필요로 하지 않는다는 사실을... lover1은 알잘딱깔센 하게 떠난다. 어디로? 가비지 콜렉터로...

안 로맨틱한 클로저들의 무덤, 가비지 콜렉터(Garbage Collector)

가비지 콜렉터는 더 이상 사용되지 않는 메모리를 정리하고 회수하는 역할을 한다. 즉, 안 로맨틱한 클로저에서 더 이상 참조되지 않는 메모리 lover1를 회수하고, 시스템 자원을 효율적으로 관리한다. 불필요한 것이 없는 깨끗한 세상이 된 것이다. Hello, Clean World!

정리

코드의 세계에서도 솔로들의 삶은 애석하다.