개발일지 (10월 회고)

2021. 11. 7. 14:49Developer History

 

 

내가 지향하는 개발의 초점을 "어떤 기술을 적용할 것인가"에서 (물론 중요한 부분을 차지하고 있다) "어떤 제품을 만들 것인가?"로 바꾸면서 개발일지가 커버하는 범위가 어째 많이 넓어진 것 같다. 다음 달부터는 개발일지에서 아예 LifeLog정도의 이름으로 변경할까 고민이 된다.

 

 

독서에 대하여

2017년 대학교에 입학하면서 세운 다짐이 있다면, 대학교 졸업장을 받기 전까지 1000권의 책을 읽고 기록으로 남기는 것이었다. 물론 그때는 굉장히 막연한 목표였고, 새해가 밝기 전 매번 세우는 어느 집 삼촌의 금연 다짐 같은 정도의 목표였었다. 시간이 지나 목표를 세운지도 벌써 4년이 지났고, 현재까지 기록해둔 책은 대략 650권 정도가 되었는데, 아직 졸업까지는 (최소) 3학기가 남았고, 내년 9월이나 되어야 복무가 만료된다는 점을 감안한다면 졸업장을 받기 전까지 1000권을 읽는 것이 불가능한 목표는 아닌 것 같다.

 

 

책을 읽어오면서 책들이 담고 있는 주제만큼이나 책을 읽는 방법도 다양해진 것 같다. 어떤 책들은 누군가를 기다리면서 가볍게 읽을 수 있는가 하면, 또 어떤 책들은 담고 있는 내용이 어려워서 독서등을 켜고 여기저기 주석을 찾아가며 읽어야 했다. 어떤 책들은 여느 책들과 다르지 않은 비슷한 결을 가지고 있어서 그런 비슷한 책들의 내용을 곱씹으면서 읽을 수 있는가 하면 어떤 책은 내 세계관을 완전히 뒤엎어 버려서 몇 달 동안 충격에 휩싸인 채 계속 동일한 책만 읽고 또 읽게 만들기도 한다.

 

 

이번 달은 꽤 오랜만에 내 기존 사고관을 흔들어놓는 충격적인 책을 만나서 다른 책들을 거의 읽지 못하고 이 책만 읽고 또 읽었다. "블랙 스완"의 저자 나심 탈레브의 "Antifragile"이라는 책이었는데 처음으로 번역본을 읽고 너무 충격을 받아서 원서를 구입해서 다시 한번 읽어보고 또 놓친 것이 없는지 다시 번역본을 읽고 다시 원서를 읽고 했다.

 

 

antifragile

 

 

 

회고록 특성상 책의 자세한 내용까지 언급하긴 힘들겠지만, 경제 시스템이나 사회구조와 같은 복잡계(Complex System)에 대한 새로운 시각을 통해 "안정적인 시스템"이 얼마나 위험한 것인지, 정확하게는 얼마나 변화에 "취약한"것인지를 드러내주는 책이었고 변화에 "취약한"것이 아니라 변화가 올 수록 그 변화를 통해 "더 강해지는" 시스템을 만들기 위해서는 어떤 지혜가 필요한지, 어떤 것들을 고민해야 하는지를 알려주는 책이었다.

 

 

왜 경제 시스템을 통제하려 하는 양적 완화와 같은 시도가 위험한지, 왜 대재앙은 "예측"할 수 없는 것인지 등에 대한 거시적인 통찰을 통해 인간의 삶에서 "어떻게 사는 것이 Antifragile(reverse of fragile)한 것인지"에 대해 고민하도록 만들었고, 특히 요즘 고민하고 있는 소프트웨어 아키텍처의 안정성의 측면에서 기술의 변화와 요구사항의 변경에 Antifragile 한 아키텍처를 설계하기 위해서는 어떤 것들을 고민해야 하는지에 대해 많은 생각을 할 수 있도록 도와주었다.(아직 성과는 없다)

 

 

워낙 광범위한 분야를 커버하는 책이다보니 이전에 읽었던 많은 책들이 도움이 되었던 것 같고, 커리큘럼의 이수를 위해 공부한 교과서적인 지식이 아니라 단순 호기심에서 시작해 근본 없이(?) 마구잡이로 공부했던 거시경제, 사회학, 역사에 대한 지식들이 이리 이어지고 저리 이어지는 말 그대로 지식들을 잇는(connecting the dots) 경험을 하면서 읽는 과정이 너무 재미있었다.

 

 

 

운동에 대하여

인정하고 싶지 않았지만 인간은 호르몬에 굉장히 많은 영향을 받는 동물이라는 것을 깨닫게 된 이후로부터 운동을 조금 적게, 하지만 더 많이 하게 되었다. 이전에는 뭔가 기록을 세우기 위해서, 페이스를 낮추기 위해서 악쓰고 운동을 했다면 요즘에는 호르몬을 분출(?) 하기 위해서 가볍게 운동을 하게 되는 것 같다. 머리가 멍하고 답답하다? -> 운동하러 간다. 잘 시간이 아닌데 졸리다? -> 운동하러 간다. 이런 식이다 

 

이런 흐름이 만들어지면서 아직까지는 상당히 만족스러운 성과를 내고 있다. 여름에서 가을로 넘어가면서 날씨가 갑자기 바뀌어 그런지 아침에 일어나면 그냥 기분이 안좋고 일하기 싫을 때가 있는데 그냥 세수도 안 하고 바로 헬스장으로 달려가서 한 30분만 으샤 으샤 운동하고 오면 갑자기 삶이 너무 즐겁고 뭔가 열심히 살고 싶은 생각이 드는 경우가 많다. 저녁에도 퇴근하고나서 지쳐서 아무것도 하기 싫을 때 바로 한강으로 달리기를 하러 가는데 아껴뒀던 플레이리스트를 들으면서 그냥 30분 정도만 뛰고 오면 자기 전까지 쌩쌩하게 책을 읽거나 공부를 할 수 있고 잠을 잘 자는데도 많은 도움이 된다.

 

물론 말 그대로 "리프레시"를 위한 운동이기 때문에 운동의 강도가 높지 않다. 다른사람들에게 "3대 몇"이라는 질문을 받으면 답변 못할 수준의 중량을 들고 있긴 하지만, 앞으로도 크게 늘릴 생각은 없다. 중량도 형편없고(헬스), 페이스도 형편없는 수준이지만(달리기) 이렇게 형편없는 수준으로 하고 있기 때문에 3달 가까이 아침 헬스 저녁 달리기의 패턴이 "지속가능"했다고 생각한다. 내가 정말 집중해야 하는 대상들에게 에너지를 조금 더 쏟고 싶은 생각이 있어서 운동은 이를 보조해주는 수단으로써의 기능을 유지할 정도의 강도로 평생 지속하려 한다.

 

 

 

프론트엔드(와 딥러닝)에 대하여

프론트엔드는 정말이지 "빠르다". 즉 변화와 변경이 굉장히 많은 분야다. 이 라이브러리 뜯어서 요리조리 익혀보고 난 후에 좀 이해했다 싶으면 금세 새로운 라이브러리가 나오고, 이 라이브러리로 프로젝트 하나 완성했다 싶으면 더 많은 기능을 포함시켜 메이저 버전이 하나 올라간 라이브러리가 나온다. 해마다 열리는 FEConf에서는 눈이 떡 벌어질 수준의 성과를 내는 사람들이 보이고, 불과 몇 년 전만 해도 그냥 백엔드에서 html 템플릿 정도만 문서로 전달해주었던 것 같은데 지금은 클라이언트의 GPU가속을 사용해서 간단한 딥러닝 모델도 돌린다.

 

 

프론트엔드를 처음 접하고 웹 개발을 하면서 이런 사실들에 도전도 많이 받고, 또 그만큼 좌절도 많이 해야 했다. 지금은 "비교적" 어리기 때문에 새로운 라이브러리나 새로운 기술들이 나올 때마다 바로바로 익혀보고, 토이 프로젝트도 해보고, 만들어보면서 빠른 "적응"이 가능하지만 내가 40대 50대가 되었을 때도 이렇게 할 수 있을까?, 다시 말해 내가 프론트엔드 개발을 "지속할 수 있을까?"에 대한 고민이 있었다.

 

 

물론 아직 완벽하게 스스로에게 답변을 한 것은 아니지만 이번에 Antifragile을 읽으면서 이런 고민들을 어느 정도 정리할 수 있었다. 프론트엔드가 그만큼 이전 방법들을 고수하지 않고, 특정 라이브러리나 프레임워크의 사용을 누군가가 개입해서 강요하지 않기 때문에 (아무리 구글에서 만든 라이브러리도 star가 적거나 영 시원찮으면 버림받는다) 개별 라이브러리들이나 프레임워크들은 Fragile 하지만 전체 System은 Antifragile 하다. 즉, 프론트엔드라는 분야 자체가 그만큼 다양한 분야로 확장이 가능하고 잦은 변동이나 백엔드, 클라이언트 사이드에서의 큰 변화에도 위험 없이 대응이 가능한 분야인 것이다. 일례로, 스마트폰이 발달하면서 앱 생태계로 넘어왔지만 웹은 "웹뷰"로 대응했고, 딥 러닝이 뜨면서 딥러닝에 대한 관심이 늘어나고 있지만 웹은 "Tensorflowjs", "Nodejs"와 같은 (Nodejs는 웹은 아니지만 웹을 구성하는 언어를 통해 서버사이드의 처리를 가능하게 하므로) 라이브러리들을 내놓기 시작하면서 또 능동적으로 대응하려 하고 있다.

 

 

프론트엔드라는 분야가 Antifragile하므로 필연적으로 프론트엔드 분야를 이루는 여러 구성 요소들(이를테면 라이브러리나 프레임워크들)은  Fragile하다. 이말은 React도 언젠가는 다른 라이브러리도 대체될 수 있을 것이며, Redux도, Recoil도 언젠가는 대체될 수 있다는 것이다(대체된다는 것 자체가 프론트엔드 생태계가 Antifragile하다는 것을 증명한다). 그렇기 때문에 프론트엔드 분야를 오래 지속하기 위해서는 라이브러리와 프레임워크를 "잡음"으로, 웹을 이루는 큰 흐름의 변화(이를테면 웹뷰로의 전환, 아키텍쳐와 추상화, 딥러닝 시스템으로의 전환등)를 "유의미한 신호"로 간주하고 "잡음"으로부터 "유의미한 신호"들을 분리해 내야 한다는 생각이 들었다.

 

 

물론 여기서의 잡음은 불필요한 것이 아니지만, 잡음에만 매몰되어 유의미한 신호들을 놓친다면, 프론트엔드 분야는 Antifragile하므로 변화의 흐름들 앞에서 더욱 단단해져가고 그 범위를 확장시켜 가겠지만, 이 신호를 놓치고 잡음에 집중하는 개발자는(개인적으로는 "라이브러리"에 집중하고 "당장 눈앞에 보이는 구현에 집중"하는, 일명 "찍어내는 개발"에만 능숙한 개발자가 여기에 속한다고 생각한다.) 변화에 Fragile해지기 때문에 큰 흐름의 변화가 왔을 때 이를 견뎌내지 못할 가능성이 높다. 

 

 

그렇다면 "나는 어떤 개발자가 되어야 하는가?"

 

 

나는 "Antifragile한 프론트엔드 개발자가 될 것이다"라고 대답할 것이다. 이에 대해 "Antifragile한 프론트엔드 개발자란 어떤 것인가?"라고 되묻는다면, "웹을 통해 표현하고자 하는 무엇인가가 있다고 했을 때, 그것을 잘 표현하기 위한 여러 수단들로부터 자유로운 개발자"라고 대답해야 할 것 같다. 결국 이를 위해서는 Fragile한 여러 시도들을 해야 할 것이다. 당연히 이 라이브러리도 사용해보고 저 라이브러리도 사용해보겠지만, "무엇을 위해" 이 라이브러리가 "어떻게" 만들어졌는지를 고민하고 앞으로도 이걸 계속 사용할 수 있을지를 고민해야 후에 이 라이브러리가 "잡음"이 되어 다른 것들로 대체되었을 때도 내게 남는 것이 있을 것이며, 극단적으로 웹을 표현하기 위해 더 이상 HTML, CSS, JS가 필요하지 않더라도 나는 웹 개발자로서 살아남을 수 있는 것이 아닌가 생각한다. (결론적으로 아주아주 쉽게 말해서 내가 생각하는 웹 개발자는 리액트 개발자가 아니라는 이야기다. 현재는 웹 개발자는 많은 경우 리액트 개발자여야 하지만, 리액트가 없어져도 웹 개발자는 웹을 개발할 수 있다. 반면 리액트 개발자는 리액트가 대체되면 큰 충격을 받거나 직장을 잃는다.)

 

 

 

 

반응형

'Developer History' 카테고리의 다른 글

개발일지 (1월 회고)  (1) 2022.02.12
개발일지 (11 & 12월 회고)  (1) 2022.01.01
개발일지 (9월 회고)  (2) 2021.09.26
개발일지 (4 & 5월 회고)  (0) 2021.05.31
개발일지 (3월 회고)  (1) 2021.03.29