문턱에서

꽤 많은 것이 추워졌다. 먼저 경제가 추워졌다. 정치, 사회도 추워 보인다. 그리고 날씨가 추워졌다. 신입으로 회사에 입사한지 11개월째다 . 곧 1년차가 된다. 생각해보면 참 많은 일이 있었고 많은 문제를 해결했다. 또 해결 했다고 생각했던 것이 실수였고 많은 문제를 낳았다.( 해치웠나?) 그것은 꼭 개발만의 문제가 아닌 삶의 전반에 흩어져있는 모든 것이다. 취업하면 반드시 해결될 것 같았던 문제들은 여전하다. 꼭 처음 입사 했을 때, 작성한 코드 같이 '그때 내가 왜 이렇게 행동 했을까?'하는 것이 떠오른다. 환경이 변하면 인간 관계가많이 넓어질 수도 있지 않을까 했지만 여전히 인간 관계는 좁고 좋지 않다. 돈을 벌면 취미 새로운 취미를 가질수 있지 않을까 했지만 나가는 돈이 많아 여전히 책 읽기와 영화가 그 자리를 차지하고 있다. 스트레스 때문에 병원 신세를 지기도 하고 허리가 너무 아파서 안하던 근력 운동을 꾸 준히 하고 있다. 매일 하던 달리기는 여러가지 핑계를대며 뒤로 계속 미루고있다. 피우던 담배를 끊으려고 부단히 노력하고있다. 비싼 옷도 한 번 사 보고 못하던 소개팅도 하고이것 저것 외적 요인을 통해 삶의 변화를 일으키고 싶어서 에너지를 엄청나게 썼지만 효과는 많이 없다 .

요즘은 계속 '으아 개발이 재미있기는 하지만 적성에 안맞는 것 같아!'라고 비명을 지르고 있다. 마치 이상한 나라의 엘리스가 된 느낌이다 . 업무 특성상 내 기억력은 절대로 믿으면 안 된다는 지독한 특징을 가지고있다. 버튼 색상이 마음에안들어도 UI가 너무 이상해 보여도 애 니메이션을 넣고 싶어도 모든 것은 반드시 협의를 거쳐야한다. 사실 기획서에 "사용자 경고 메시지를 0.8초간 양 옆으로 뒤흔든다."라고 쓰 여있는 것은 아니라서 가끔은 재해석이 가능한 선에서 애니메이션을 넣기도 한다. 디자이너의 반응이 좋으면 너무 좋은데 가끔은 빠꾸(?)당 해서 시무룩 한 채로 빼기도 한다. 분명 같은 회의실에서 같은 이야기를 했는데 여러가지 결과가 나온적도 있고, 협의 된 대로 API를 넘겨 받지 못해서 커뮤니케이션에 엄청난 비용을 쓴 적도 있다. 눈이 찢어질 듯 아파서(나는 화이트 모드를 쓴다.) 안과를 갔는데 이것 저것 검 사를 해보더니 의사가 '깨끗합니다. 제 소견으론 정상이에요.'라고 말했다. 그러고 나서 다음날 회사에 나갔는데 신기 하게 눈이 아프지 않았다. 어제까지는 개발 하기 싫다고 동료들과 술 마시면서 너스레를 떨었는데 다음 날 회사에 가니 코딩이 재미있던 적도있다. 처음 회사 왔을 때 어느 코드를 보고 '제거 해야 할 레거시'로 생각했는데 지금와서 입사 초에 작성한 코드를 보니 내 코 드가 제거 해야 할 레거시가 되어 있었다. 치명적인 실수를 해서 정말 큰일 날 뻔한 적도 있었고 몇 개월 전에 작성했던 코드가 아무 문제 없이
운영되다가 갑자기 문제가 되서 사고가 나기도 했다. 의견 대립으로 다른 사람과 싸우기도 했다. 돌이켜 보면 지난 11개월은 감각의 영역에서만 살 던 내가 규칙과 논리의 영역으로 넘어가는 그 문턱의 이야기였다.

시간 여행

배민 기획자의 일을 읽었다. 책의 내용 중에 주소 이야기가 나오는데 그 도메인에서 가장 중요한 요소는 공간이라는 생각을 했다. '그럼 브이디 크럭스의 도메인에서 가장 중요한 개념은 무엇일까' 고민해봤다. 나는 몇 가지 경험 그리고 DB로부터 받는 데이터를 보면서 포스, 키오스크, 테이블 오더 등 시간이라는 개념이 많이 중요하다고 생각했다. 시간을 어떻게 다룰 것이냐에 따라 UX/UI가 달라진다.

시간을 달리는 사장님

사장님이 시간을 달릴 수 있는지 알게되기 전까진 DB에 시간이 어떻게 저장되는지 궁금해한 적은 없었다. 사장님이 시간을 달릴 수 있다는 것은 하루가 24시간으로 구분되지 않는 다는 것을 의미한다. 예를 들어 '크럭스 포차'라는 뉴트로 술집이 있다고 생각해보자. 가게 사장님 현수는 보통 개점 시간을 오후 5시-7시 사이에 한다. 그럼 그 가게의 하루는 12월 1일 오후 5시-7시 사이에 시작된다. 그리고 12월 2일 새벽 3시에 마감을 한다고 하면 통상적인 시간 구분에선 하루를 넘기고 난뒤에 장사가 끝난 것이지만 가게는 '그 날(12 월 1일)' 장사가 끝난 것으 로 기록 된다. DB에는 createdAt은 UTC 로 저장되기 때문에 어제와 오늘로 저장되지만 개점과 마감은 사장님이 하루를 시작 한 시간으로 저장 되기 때문에 12월 1일 오픈, 마감으로 저장된다. 하지만 사장님 중에는 개점을 하고 장사를 하다가 12월 2일이 되면 마감을 하고 다시 재개 점을 하는 사람도있다. 어떤 사람은 12월 1일 오후 5시지만 개점 후 마감을 바로 하고 12월 2일에 건너가서 장사를 시작하는 사람도 있다. 어떤 경우에는 12월 1일 장사가 마무리 되어서 마감(12월 2일)을 했는데 갑자기 12월 1일로 돌아가야 하는 일도 생긴다. 하지만 여기에서 결 제 데이터는 매장 오픈과 마감과 무관하다. 결제 데이터는 시간을 달리면 안된다.(그럼 큰일난다.) 그래서 여긴 통상적인 24시간이 하루다. 하지만 매출 레포트를 생성할 때 기준 시간은 매장 오픈에 엮여있다. 그래서 누군가 '매출 데이터가 조회가 되지 않아요.'라고 이야기하면 리포트를 생성하기 위한 매출 데이터인지 아니면 정말 실재로 결제가 되지 않는 것인지 알 수는 없다.

통상적인 24시간에 살던 내가 시간을 달리는 사장님을 이해하기 어려웠다. 정확하게 말하면 시간을 달리는 기능을 제공하는 키오스크가 이상했다. 누군가 미래에서 타임 머신을 놓고 갔는데 나는 그게 타임 머신인지 모르고 유지 보수를 해야하는 개발자가 된 기분이었다 . 처음에 설명은 간단하다고 생각이 들었다. 하지만 시간을 다루는 것은 나에게 너무 어려운 일이었다. 팀장님을 붙잡고 몇 일을 씨름한 뒤, 겨우 몇 줄 코드를 적어 넣었다.

자동 마감

자동 마감 기능도 정말 중요한 기능인데 이건 사장님이 있는데 없을 때(무인 매장) 많이 사용한다. 또는 24 시간 체계에서 하루를 넘기는 장사를 하는 가게나, 24시간 운영을 하는 곳에서 사용한다. 자동 마감은 테스트 하기 좀 까다롭다. 나도 시간을 달려야하기 때문이다. 이럴 때는 컴퓨터의 시스템 시간을 조작해서 과거로 갔다가 다시 미래로 갔다가 하는 식으로 일을 한다. 처음에는 시간 여행을 가능하게 해주는 키 오스크가 미웠는데 이번엔 시간 여행을 가능하게 해주는 컴퓨터에 감사하게 되었다. 자동 마감이 00시 00분에 반드시 동작하는 것을 보장하지 않기 때문에 자동 마감이 제대로 되는 것을 보기 위해서는 몇 분을 앉아서 기다려야한다. 몇 분이 지났는데 자동 마감에 문제가있 으면 로그를 보면서 이유를 찾아서 또 수정하고 다시 실행하는 식으로 테스트를 해야한다. 그리고 난 다음에 Build를 해서 기기에서 테스트를 한다. QA 테스트를 통과 했다해도 현장 상황에 따라 어떤 버그가 발생할지 예측할 수 없기 때문에 시간과 관련된 업무를 한 뒤에는 배포 이후에도 마음이 편하지않다.

내가 결정하는 것이 이유가 될 수 있는가.

'내가 결정한 것이 이유가 될 수 있는가.'를 예, 아니오로 대답할 수 있는 것이 엔지니어링과 이전 경험간의 명확한 차이점이라고 생각한다. 내가 A를 구현한 이유를 B보다 A가 마음에 들기 때문이 아니라 디자인 시안에 A로 결정되어 있기 때문이다. 프론트엔드 엔지니어링은 결정된 기획을 논리적으로 결함이 없도록 사용자에게 보여지는 화면을 구현하는 역할이다. 엔지니어링의 이유는 그날 기분과 감정에 없다. 기획자의 기획서와 디자이너의 화면에 그 이유가 있을 뿐이다. 무엇을 왜 그렇게 구현했는지는 사람마다(코딩 스타일) 그리고 팀 마다(도메인) 조금씩 다르지만 그 UI가 거기 있어야하는 이유를 내가 결정할 수 없다. 그 지점이 엔지니어링과 다른 직군과의 차이가 아닐까?

프론트엔드 개발자는 뭐하는 사람일까?

산업의 관점에서 보면 프론트엔드 엔지니어링은 기획자와 디자이너의 표현을 사용자와 기계가 상호 작용할수 있도록 통역하는 일을 한다. 프 론트엔드 개발자는 사람과 기계 사이에 있다. 일단 기획자의 말(의도)을 잘 듣는 것이 매우 중요하다. 기획서를 보면서 이해가 안 가는 것은 반드시 질문 해야하고 '이거 기계에는 이렇게 말해야 할 것 같은데요?'라는 것을 짚어 주어야 한다. 코딩을 하면서는 기계의 말을 잘 들어야한다. 너는 왜 이렇게 동작하는가. 왜 이렇게 했을 때는 성능이 구린가. 너는 왜 에러를 뿜는가. 뭐가 불만인가. 직접적인 대화는 아니지만 (요즘은 GPT 때문에 직접적인 대화를 하는 것처럼 느껴진다.) 기계도 이해해주려고 노력 해야한다.(사실 이해가아니라 규칙에 따라 야한다.)

대화가 꼭 의도한 방향대로 간다면 너무 좋지만 가끔은 내가 의도한 것과 전혀 다른 곳으로 흘러 들어간다. 분명 난 프론트엔드 개발자 관점 에서 무언가를 이야기 했는데 내가 원하는 것 외 다른 부분이 크게 변하는 경우도 있다. 이런 경우를 의사소통의 실패로 봐야하는 건지를 모르 겠다. 의사 소통의 성공은 꼭 그때 당시 내가 원하는 것을 얻었냐 얻지 못했느냐로 판단하기 보다 그 대화를 통한 의사 결정이 프러덕트에 어 떤 영향을 주었고 그 결정이 매출 상승으로 이어졌는지가 가장 중요하지 않을까? 하지만 아직 이러한 경험은 전무하다. 사실 지금까진 개발이 끝나면 그냥 다음 프로젝트로 나가는데 만 집중했기 때문이다. 그러나 최근 '데이터로 말하는' 혹은 '데이터로 일하는' 개발자란 무엇일지 고민을 해본다.

처음에 회사에 왔을 때 기획서나 디자인 시안에 에러가 났을 때의 상황에 대해서 불명확하거나 정의 되어있지 않은 경우가 많았다. 사실 별 로 신경쓰고 있지 않았는데 PR에서 개선 사항으로 에러 처리를 해달라는 요청이 있었다. 그래서 에러 처리를 왜 안했지 하고보니 에러 메시 지에 대한 정의가 되어있지 않았다. 팀에게 물어봤을 때, 아직 그 부분은 기획 디자인 팀에서 잘 정의해주지 않는 경우가 대부분이라 일 단 프론트 역량으로 해결하는 경우가 많았다. 내가 판단했을 때는, 어느 상황에서 어떤 에러가 발생하는지 기획자가 잘 모르기 때문에 에러메 시지가 불명확하거나 없는게 아닐까하는 생각을 했다. 그래서 기획 디자이너에게 unauthrized, bad reqeust not found, internal server error가 왜 발생하고 이럴때 사용자에게 어떤 에러 메시지를 표출 할지를 예시로 적어 보여주었다. 기획자는 그것을 보고 해당 프로젝트에 맞 는 문구를 잘 내려주었고, 디자이너는 그것을 어떤 UI로 사용자에게 보여줄 것인지 정의해주었다.

시간이 지난 뒤 배포 회고 시간에 '에러 처리가 좀 정규화 되면 좋겠다.'라는 부푼 꿈을 이야기 해보았다. 사실 내 의도는 에러 메시지가 '기획을 통해서 내려왔으면 좋겠다.'였다. 하지만 소통의 방향이 어느 순간 내가 의도한것과 전혀 다른 방향으로 흘러가버렸다. 백엔드에서 에러 처리 방법을 바꾸자는 논의를 한참 듣다가 회의가 끝났다. 그 이후 '홍길동 에러'를 받게 되어 매우 당혹스럽지만 그래도 프론트와 서버 간 HTTP 통신 에러 메시지는 서버에서 대부분 처리해주고 있기 때문에 소정의 목적은 달성한게아닐까?

효과적인 프로젝트를 위한 3가지 기록 방법

Notion, JSDoc, PR with Jira

몇 개월 전에 입사하신 동료 P는 문서 정리, 의사 코드 작성, 타 팀과 의사 소통을 위한 프로세스 정리 등을 잘한다. 특히 기록을 정말 맛 있게 한다. 나도 입사 초기에는 기록을 했지만 회의를 녹음 해놓고 클로버로 풀어쓰는게 다였다. 함께 보기 위한 기록용이라기 보다 내가 보 기 위한 용도였다. 하지만 P의 문서는 '어떻게 진행되고 있구나 ', '이래서 이 프로젝트가 이렇게 됐구나.', '이런 기능은 이렇게 동작해야 하는 거구나'하는 것을 모두가 알기 쉽게 정리해놓는다. 뭔가 A가 있어야 할 자리에 A가 있다고 해야할까? 입사 전에 JSDoc을배우긴 했어도 JSDoc 을 기록하는 습관은 없었다. 그런데 P의 코드를 보면 '아, JSDoc은 이렇게 쓰는거구나'하는 생각이 들었다. PR 탬플릿도 이전엔 없었는데 형식화 되서 PR 쓰기도 엄청 편해지고 PR 승인 후 따로 QA 테스트 참고 사항을 쓸 필요 없이 PR을 그대로 옮기기만 하면 될 정도다.

나는 좋은 건 곧 잘 따라한다. 최근 진행했던 프로젝트를 Slack, Notion을 사용해서 함께 소통할 수 있는공간을 그대로 따라해봤다. 이전에 프로젝트를 했을 때보다 많은 개선사항이 있었는데 먼저 일정 공유를 팀 간에 데일리로 하게되니까 PM이 따로 물어보고 대답할 필요가 없었다. 그리고 일정 산정이란 걸 처음 해봤는데 처음엔 촉박한 일정이었지만 그래도 나름 일정이 여유롭게 산정될 수 있었다. 기획, 디자인과 소통 할때 변경사항은 반드시 기록해놓고 나중에 기억력에 의존해서 입 씨름을 할 필요 없어졌다. QA 팀으로 넘기 기 전에 개발팀 내부 테스트를 하면서 Pass, Fail로 모든 것을 다 기록해 놓았다. QA 테스트 중 똑같은 에러가 발생했는데 data 프로퍼티이 름이 다른 문제였다. 하지만 '에러로 정의된' 이름이 기록이 되어있어 바쁜 상황을 빠르게 타개할 수 있었다.(지라 티켓 할당을 변경함으로 써...ㅋ) 그밖에 B2B 케이스에 대해서 미리 정리해놨을 때, 다른 팀이 거기에 덧붙여야하는 일이 있었는데 미리 정리해두었던 문서를 공유 해주었다. 팀원은 맥락이 이해된 상태에서 질문을 했기 때문에 조금 더 일이 빠르고 원활하게 진척될 수 있었던 것 같다.

모든 사람들이 문서를 열람하고 작성할 수 있게 하는 것이고, 되도록 많은 사람이 빠르게 이해할 수 있도록 문장을 길거나 어렵게 쓰지 않 는 것이 중요한 것 같다. 규칙이나 템플릿을 미리 만들어 놓으면 효율이 배로 늘어난다. 이렇게 하면 문서를 처음부터 만들 필요 없이 생각을 해야 할 곳에서만 하게 되고 프로젝트의 진행 상황에 대해서 효과적으로 기록할 수 있다. 이 기록은 나중에 프로젝트 종료 후 다른 사람이 열 람 해야하는 문서로 아카이빙 할 때 많은 시간을 단축시켜준다.

JSDoc은 공용 훅이나 공용 컴포넌트를 다른 사람도 편하게 쓸 수 있도록 작성하는 것이 좋은 것 같다. 이게꼭 주석이라 무작정 피하기 보다 다른 사람에게 빠른 이해를 돕기 위해 작성한다고 생각하는 편이 좋은 것 같다. VSCode에서 훅에 대한 설명을 툴팁으로 바로 볼 수 있기 때문 에 내가 만들고 PR 이후 팀원이 사용할때 나에게 슬렉으로 질문을 퍼붓거나 코드를 이해하기 위해서 몇 분을 써야하는 것을 피할 수 있다고 생각한다.(최악은 훅을 안쓰고 비슷한 훅을 새로 만들어 버릴 수 도 있기 때문에...)

앞으로 하고 싶은 기록 방법

앞으로 나는 테스트 코드를 기록하고 싶다. 내가 이 기록 방법을 내년에 조금씩 해나가는 것을 목표로 하는이유가 하나 있다. 나는 정말 실 수가 많은 사람이기 때문이다. 한 브랜치에서 내가 작성한 코드도 가끔 잊어버려서 PR 후 에러가 발생하는 경우가 있었다. 넣지 말아야하는 데 넣었다던가 관련 로직이 변경되었는데 일부만 적용 한다던가 하는 식이다. 테스트 커버리지를 10%를 목표로 잡고 먼저 진행 해보려고 한다. 몇 십년동안 난 덤벙대는 사람이었다. 한순가 못고치고 앞으로도 못고친다. 하지만 이런 부분을 기계가 기억해주고 도와주면 덤벙대는 것을 고치진 못해도 사고를 예방 할 수 있다.

사고친 놈의 기억법(에필로그)

'제가 그런적 없는데요.'하면 어김없이 나였다. git 추적해보면 범인은 꼭 나다. 왜 이렇게 5개월 전 7개월전 고현수가 많은지... 참 많은 일 을 했구나 하는 생각 이전에 ' 내가 이렇게 했다고?' 하는 수치심이 생긴다. 습관성 기억 상실이 아닐까하는 생각에 소름이 돋는다. 그러나 git은 나라고 기록되어있다. git blame 이게 바로 기억 상실증이 밥먹듯 찾아오는 사고친 놈을 검거하는 방법이다.

다른 사람 코드 읽기

입사 초반에 코드 리뷰를 할 때 사실 코드를 읽기 어려웠다. 사이드 프로젝트를 하면서 다른 사람 코드를 읽어보긴 했지만 그냥 대부분 '참 잘 했어요' 도장 찍고 넘어가는 수준이었다. 다른 분은 내 코드를 엄청 잘 봐주는데 나는 그렇지 못하다는게 못내 아쉬웠다. 그래서 정식으로 리뷰를 해주자는 제안을 했다. '일단 읽어보기라도 하자!' 그래서 Approve 규칙이 만들어졌다. 여전히 다른 사람 코드는 읽어도 잘 모른다. 그래도 나름 할 수 있는 것을 하려고 노력중 이다.

동료 개발자가 리뷰를 남겨준 것을 동의하면(에러가 발생할 수 있는 건 동의고 뭐고) 일단 코드에 다 적용해보았다. 내가 생각해도 그렇게 하는게 좋다고 생각했기 때문이다. 그리고 리뷰 받았던 내용 중 동료 개발자가 나와 같은 실수를 했다면 코멘트를 남겼다. 잘한게 있거나 신 기한거 좋아보이는 것은 무조건 코멘트를 남겼다. 그리고 내 코드에 적용해보려고 노력한다. 코드를 쓰는 것도 중요하지만 동료의 코드를 보면서 성장할 수 있다고 생각하기 때문에 일단 꼼꼼하게 읽으려고 한다. 가끔 가독성 문제나 내 취향에 맞지 않는 것은 처음에는 '이건 좀...' 이 라는 태도로 리뷰를 남겼었는데 스크럼 때, 우리 팀이 컨벤션이 없는 상황에서 가독성 문제나 취향을 논하는 건 좀 아니지 않느냐는 피드백 이 있었다. 너무 맞는 말이라 그럼 컨벤션을 정해보자는 이야기로이어졌다. 처음에 모노레포 적용하면서 eslint도 함께 적용했는데(적용 안되어있는걸 적용하려면 피똥싼다.) import 안쓰는거 없애주거나 console.log 경고 안쓰는 변수 에러 처리, Funtion, Object로 타입 지정하지 않기 등의 룰을 넣었었다. 앞으로 컨벤션은 논의를 더 해봐야할 것 같다.

퇴근 길에 코드 읽기에 대한 어려움을 이야기했더니 프로그래머의 뇌라는 책을 추천해주셨 다. 읽으면서 실습해보고 주말에 라이브러리 마음에 드는거 찾아서 코드 읽다보면어느 순간 갑자기 코드 읽는 실력이 늘어날꺼라고 말해주 어서 그렇게 해볼 예정이다. 이제 나이브한 코드 리뷰는 지양하고 싶다.

잘했다. 그래도 딥 다이브가 필요해

이번 해 그래도 가장 잘한 건 사내 라이브러리 중 모달, AdvancedSearch 만들었던 일이다. 모달은 많이 쓰이고 있고 AdvancedSearch는 아직 미완이다. 내가 나 스스로를 칭찬하는 이유는 불편한 점을 개발자답게 기술로 해결하려고 노력했기 때문이다.

모달을 만들 때 주로 했던 생각은 '함수의 실행을 잠깐 멈췄다가 사용자의 행동 후에다시 시작하게 할 수없을까?'가 가장 주된 생각이었다. 자세한 건 모달을 만들면서 들었던 생각을 정리한 아티클에서 다루기로하자. 어쨌든 ContextAPI와 커링 그리고 고차함수를 사용해서 모달 한 개당 하나의 상태가 생겨나는 불합리함을 해결할 수 있었다. 그리고 모달을 응집도에 따라 뭉쳐놓을 수도 있었기 때문에 생각보다 괜찮은라 이브러리라고 생각된다.(아직 개선점이 있지만) 다행이 팀내에서 정착되어서 이곳 저곳에서 많이 쓰이고 있다.

AdvancedSearch는 아직 완성이라고 보기에는 어렵다. CCP(Compound Component Pattern)을 사용해서 구현을했지만 아직 AdvancedSearch는 그 저 껍데기에 불과하다. 상위에서 자녀들을 알지 못하기 때문에 개별적인 것을 엮어 놓은 것일 뿐이다. 그래도 HTML 기본 동작을 최대한 구현 하면서 React스럽게 동작하게 하려고 많은 노력을 기울였다. 하지만 아직 전역에서 이것을 사용하기에는 충분하지 않다는 생각이 든다.(또 다른 레거시를 양산할 것이다.) 잘했다. 하지만 딥 다이브가 필요해보인다. 프론트엔드 재미없다고 징징거렸는데 차라리 잘됐다. 징징거리기 전에 한번 이거 공부 해보고징징거리자.

어쩌면 미래는 별로 중요하지 않다.

회고를 쓰기 전까지는 앞으로의 미래를 어떻게 준비 해야할지 좀 막막했던 것 같다. 도메인에 대한 흥미나 이직에 대한 고민부터 사생활에 대 한 고민 등. 하지만 쓰고나니 '미래를 걱정해야할 만큼 미래가 중요한가 ?'하는 생각이 들었다. 내가 사는 시대는 미래가 그렇게 중요해보 이지 않는다. 변화가 너무 빠르다. 미래라고 부를 수 있는 것이있는지 모르겠다. 눈 깜박하면 현재가 되어있다.

처음 개발자 한다고 했을 때, 취업 시장이 과열 될 줄 내가 알았나? 코로나는 예측이나 했나? 코로나 이후 금리가 이렇게 미친듯이 오 를 줄 알았나? 아니 그전에 내가 취업 할 줄 사람들은 기대도 안했고 예측도 못했다. 나 스스로 내가 개발자가 될 것이라고 상상도 못했다. 처음 에 퇴사 할 때 다들 말도 안된다고 했다. 개발자 하지 말라고 말렸다. 그리고 취업이 되었을 때 한결같이 비명과 탄식 그리고 같이 놀던 백 수가 떠나는것에 대한 서운함에 대한 반응이 이어졌다. 미래는 아무도 모른다. 하지만 나는 내 미래가 어떻게 될 줄 안다. ThreeJS 잘하고 싶 다면서 주말에 잠만 퍼자는 내가 3D를 다룰 수는 없을 것이다. 스벨트 잘하고 싶다면서 찍먹하다 말면 스벨트는 그냥 찍먹이 될 뿐이다. 지금은 의사 소통 능력이 많이 없는데 잘하는 사람을 따라하다보면 그래도 의사소통에서 심한 장애는 없을 것 같다. 실수를 많이 하는데 기록 하는 습관을 쌓다보면 실수를 줄일 수 있을 것이다.

부품 꿈을 품고 자퇴했던 대학으로 다시 돌아왔을 때, 나는 더 이상 내 미래가 그렇게 중요하다고 생각하지 않았다. 하지만 일종의 사건 이후 그냥 매일 현재를 잘 사는 것에 초점을 맞춰 나갔다. 나는 어차피 과거와 미래의 틈에서 살아간다. 지나가는 매 초가 현재이자 과거이며 미래다. 고통의 문제도 행복도 결국 현재의 나에게 필요한 것이다. 내가 할꺼라고 말했던 무수히 많은 미래 중 유일하게 프론트엔드 개발자가 현재 되었다. 그러니까 힘들고 하기 싫다고 매일 침대 위에서 동동거리지 좀 말고 지금을 소중하게 생각하자.

마지막으로 내 미래가 중요하다고 생각하지 않았을 때, 시각 디자인 과제로 냈던 자기소개를 공유하고 이 글을 마친다.