0. Intro
개발자로 일한 지 벌써 1년이 되었다. 복수전공으로 뭘 할지 고르다가 "컴퓨터를 좋아하니까 컴공 해볼까?"라는 생각으로 (사실 하드웨어와 컴퓨터 조립을 좋아했었지만) 시작했던 프로그래밍이었는데 어쩌다 보니 이 일로 먹고 살게 되었다. 개발자의 몸값이 떡상하고 정시 배치표 상 컴공이 의대 바로 아래에 있으며 컴공 복수전공 커트라인이 4.3 만점에 4점대를 가볍게 찍는 지금으로서는 "아 그냥 컴퓨터 좋아하니까 컴공 갔다고 ㅋㅋㅋ"라는 표현이 말도 안 되지만, 아무튼 그 땐 그랬다. 앞으로도 오랫동안 프로그래밍으로 먹고 살 생각이니만큼 개발자의 국룰이라는 회고라는 것을 해본다.
1. 처음 시작한 것들
사실 주니어 개발자가 으레 그렇듯 모든 것이 처음 해보는 것들 투성이었다. 팀에서 쓰는 거의 모든 기술이 처음 보는 것이거나 익숙치 않은 것들이었고, 심지어 FE 개발시켜준대서 들어갔더니 풀스택 팀이었다. 재택 근무도 처음이었고, 화상 회의도 처음이었으며 (사실 회의 자체가 처음이다), 기획자나 다른 개발자들과 협업하는 것도 처음이었다. 그래도 처음 하는 것 치고는 꽤 괜찮게 한 것 같다. 적어도 내 생각에는 그렇다. 그 이유는 몰?루.
1.1. 대규모 협업
올 해 처음 입사해서 일하기 전까지는 제대로 된 협업이란 걸 해 본 적이 없었다. 작년에 두 달 했던 인턴 때에는 대부분 한 이슈를 나 혼자 맡아서 처리했고, 디자이너 한 분이 "이거 이렇게 수정해주세요~"라고 말해주면 그냥 내가 적용해서 가져다주는 정도였다. 하지만 지금은 기획/디자인/마크업/앱개발 팀과 협업을 하고 있다. 솔직히 처음에는 "아니 사람들이 이렇게 많은데 이게 협업이 되나?", "어느 팀이 무슨 일을 하는 지, 어떤 기능은 누구 담당인지 어떻게 트래킹하지?" 싶었지만, 시간이 지나고 나니 되더라... 누가 개발자는 컴퓨터랑만 얘기하는 직업이라고 했냐 누구야 나와...
1.2. 재택근무
지금도 적응하기 어려운 게 재택근무인 것 같다. 일단 공간분리가 안 되니까 일이 끝나도 손에서 못 놓게 되고, 또 너무 편한 환경이라 집중하기 쉽지도 않다. 정확히 이 이유로 재수도 집에서 안하고 학원에 가서 한 건데, 똑같은 일이 또 벌어졌다. 그래도 개발자끼리 모이기만 하면 이 얘기가 꼭 나오는 걸 보니 나만 겪는 문제는 아닌 것 같다. 나 같은 경우 일을 시작하면 꼭 생활한복을 입고, 일이 끝나면 더 편한 옷으로 갈아입어서 일의 시작과 종료를 옷으로서 명확히 하고 있다. 이렇게 맺고 끊음이 확실해야 칼같이 퇴근할 수 있는 느낌이다. 왜 생활한복이냐면 멋있으니까 껄껄껄.
식사 문제도 쉽지 않은데, 출퇴근이었으면 그냥 점심저녁 회사에서 간단하게 해결할 수 있겠지만 재택근무는 그렇지 못하다. 차려먹으려면 시간이 모자라고, 간단하게 해결하려면 너무 부실하거나 밸런스가 안좋고, 배달로 때우려면 돈이 너무 많이 든다. 그런데 어쩌다가 샐러드 구독 서비스를 신청해서, 일주일에 한 번 5일치 샐러드를 배송받아서 점심에 닭가슴살이랑 같이 먹고 있는데 꽤나 편한 것 같다. 저녁은 여전히 문제지만 걱정거리를 두 개에서 한 개로 줄인 게 어디야? 물론 아침밥은 원래 안 먹는 놈이라... 미군식 아침 아니면 이제 안먹음 ㅅㄱ.
흑흑 재입대는 하기 싫은데 아침은 먹고 싶어요
1.3. 백엔드 개발
나는 분명히 프론트엔드로 입사했는데, 팀이 풀스택이라 하기 싫어도 어쩔 수 없이 백엔드를 만져야 하는 경우가 꽤나 있었다. MongoDB에 GraphQL을 올려서 클라이언트에서 쿼리를 호출하는 구조여서, 처음에는 호출 시에 GraphQL 필드를 넣고 빼면서 깔짝거려보다가 원하는 필드가 정의되어 있지 않으면 해당 필드를 resolve해보기도 하고 쿼리를 정의해보기도 하면서 점점 영역을 넓혀가다가 정신차려보니 어느 새 MongoDB 스키마를 설계하고 배치를 건드려보고 있었다.
내가 만든 걸 내 눈으로 볼 수 있는 게 좋아서 프론트엔드로 들어갔는데, 백엔드 개발도 생각보다 나쁘지 않았다. 물론 어디가서 "저 백엔드도 할 줄 알아요 ㅎㅎ"라고 말하려면 굉장히 많은 공부가 필요할 것 같다.
2. 발전시키고 있는 것들
2.1. React + Typescript
입사 전까지 리액트는 javascript로 class component로만 썼었는데, 팀에서는 typescript에 functional component를 쓰고 있었다. functional component를 통해 hook이라는 걸 통해 state를 관리하고 공통동작을 뽑아내며 비즈니스 로직을 모듈화해서 사용할 수 있게 되었다. 이 좋은 걸 왜 두고 class component를 쓰고 있었는지 의문이다.
이제 리액트에 충분히 익숙해져서 요구받은 스펙을 구현하는 데 큰 무리가 없게 되었으니, 리액트 코어를 공부해보면 좋을 것 같다!
2.2. Git
사실 git은 누가 가르쳐준다고 해서 빠르게 배우기는 어려운 것 같다. 혼자 하는 프로젝트에서는 영 쓸모가 크게 없기도 하고, 다른 사람들과 협업을 하면서 컨플릭트도 내 보고 브랜치를 날려보기도 하면서 배워야 그 필요성을 절감하게 되고, 배우는 추진력도 생기는 것 같다.
지금은 충분히 익숙해져서 작업 내용이 꼬이지도 않고, 꼬인다고 하더라도 충분히 혼자 힘으로 풀어낼 수 있게 되었다! develop 브랜치를 날리는 대형사고를 인턴 때 쳐 봤던 사람으로서 얼마나 다행인지 모른다.
2.3. 히스토리 파악
내가 짠 코드를 내가 읽는 것도 쉽지 않은데, 남이 오래 전에 짜둔 코드를 읽는 건 항상 어려운 것 같다. 팀에 들어오고 나서 내가 처음 보는 기술 스택이 적용 된 코드를 마주하려니, 첫 프로그래밍 수업 과제 스켈레톤을 보는 것 같은 현기증이 밀려왔다. 그렇다고 궁금한 게 생길 때 마다 팀원분들에게 물어보자니 열심히 일하는 사람들 붙잡고 시간 뺏는 것 같아서, 나 혼자 붙들고 나름의 노하우가 생길 때 까지 코드를 뜯어보니 나름의 노하우가 생긴 것 같다. 스펙이나 디자인 같은 건 보통 위키에 잘 정리되어 있는 경우가 많고 (잘 정리되어 있어서 얼마나 다행인지 모른다. 스펙이 만약 파편화되어있어서 여기저기에 널려있고, 같은 기능에 대한 스펙이 정보 출처마다 다르면... 많이 화날 것 같다), 과거 코드를 보면서 "어 이건 왜 이런 식으로 구현되어있지?"라는 생각이 들면 커밋 로그를 뜯어봐서 해당 코드가 포함된 PR이나 이슈를 보면 거기에 대부분 그 이유가 나와 있었다. 그래도 찾지 못하겠으면 그 때 가서 물어보는 식으로 히스토리 파악을 하니 "나 혼자 찾아보기"와 "팀원에게 물어보기"의 밸런스를 잡은 내 방식의 히스토리 파악법이 된 것 같다.
3. 아쉬웠던 것들
3.1. 공부의 부족
올해는 공부가 많이 부족했던 것 같다. 당장 일이 끝나면 최소 7시인데, 조금 쉬다가 밥을 해 먹고 설거지까지 끝내고 보면 벌써 9시이고, 그 쯤 되면 공부를 할 체력도 남아있지 않기 때문에 (또는 그렇다고 자기세뇌를 하기 때문에) 퍼질러지게 된다. 그렇다고 주말에 공부를 빡세게 하는 것도 아니라서... 내년에는 밥을 먹었으면 카페를 가던가, 아니면 아예 공부하는 장소를 분리해서 거기에서 공부를 하던가 해야 할 것 같다.
3.2. 의지의 부족
하루 종일 편안한 집에 박혀있으니, 운동을 하려고 해도 꾸준히 하지 못하고, 책을 읽으려 해도 오래 읽지 못한다. 사이드 프로젝트로 한다던 대학 시절 프로젝트도 커밋이 뜸하고, 친구들과 함께 하는 스터디도 늦게 제출하기가 다반사이니 대학은 어떻게 졸업했는지가 신기할 지경이다. 사실 공부의 부족도 의지의 부족으로 인한 결과같은데, 빈약한 의지력을 메꾸는 방법을 찾아보아야 할 것 같다.
3.2. 취미
변변한 취미가 없다! 기껏해야 게임이나 넷플릭스, 요리, 베이킹, 바이크랑 자전거 정도인데 조금 더 활동적이고 사람을 만날 수 있는 취미를 가졌으면 좋겠다. 지금 드는 생각으로는 활쏘기를 배워보고 싶다. 왜냐면 멋있으니까!
4. Outro
남의 돈을 받아먹는 것은 역시 어렵다는 만고의 진리를 다시 한 번 깨닫는 1년이었다. 최선을 다해 열심히 살았다고는 말할 수 없을 것 같지만, 사회초년생이자 주니어 개발자로서 썩 괜찮게 살았던 것 같다. 내년에는 조금 더 나은 인간이 될 수 있기를 기대한다.
5. Extra
5.1. Games Of The Year
5.1.1. Detroit: Become Human
사람의 몸과 똑같이 움직이는 안드로이드에 사람과 똑같이 사고하는 인공지능을 탑재한다면? 그 인공지능이 튜링 테스트를 통과해서 대화나 행동만으로는 사람인지 인공지능인지 알 수 없다면? 가전처럼 사용하던 인공지능이 자유와 인권을 요구한다면? 인공지능과 사람이 다르다면 어떻게 다르고, 같다면 왜 같은가?
컴퓨터 공학이나 과학으로 먹고 사는 사람이라면 꼭 한 번은 해봤으면 하는 게임이고, 인공지능으로 먹고 사는 사람이라면 이 게임을 하지 않는 것 만으로도 중범죄에 해당할 수 있는 갓-껨이다. 화려한 액션과 컨트롤을 필요로 하는 게임은 아니지만 여러 선택지에 따라 게임 스토리가 수십 가지 경우의 수로 달라지고, 엔딩도 스토리의 진행에 따라 수많은 엔딩을 볼 수 있다. 인공지능에게 자유를 주는 방향으로 게임을 전개할 수도 있고, 아니면 인공지능을 위험한 존재로 간주하고 절멸시켜버리는 엔딩을 볼 수도 있다. 물론 이런 선택지 게임이 그렇듯 순간의 판단미스나 게임 초반부의 잘못된 선택으로 인한 나비효과로 원하는 엔딩을 못 볼 수도 있다. 나온지 몇 년 된 게임이라 할인도 자주 하니까 할인할 때 구해서 해보도록 하자!
5.1.2. Total War: Three Kingdoms
대저 천하의 대세란 오랫동안 나뉘면 반드시 합하게 되고, 오랫동안 합하면 반드시 나뉘게 된다. (話說天下大勢 分久必合 合久必分)
- 나관중, 삼국지연의
학식이 있는 선비는 삼국지를 읽으면 책을 반드시 세 번 집어 던지는데, 첫 번째는 관운장이 졸(卒)하였을 때요, 두 번째는 유현덕이 졸하였을 때요, 세 번째는 제갈공명이 졸하였을 때이다. 예로부터 군자가 연의를 읽을 때에는, 역적 조적의 농간으로 한실의 권위가 떨어지고 결국 사마씨가 천하를 빼앗음으로 가슴이 찢어짐에 탄을 멈출 수 없는데, 이 게임이야말로 바로 그 가슴에 사이다를 부어주는 게임이다. 소열제께옵서 이루지 못하신 대업, 즉 천하통일과 한실 부흥의 꿈을 키보드와 마우스로 이룰 수 있는 것이다!
게임 자체는 턴제방식과 실시간 전술을 섞은 게임인데, 전체적인 게임 자체는 턴 방식으로 진행되지만 전투에 돌입하면 실시간으로 군병을 조종하여 싸우는 방식이다. 턴제방식이다 보니 중독성은 문명과 비슷하고, 전투 자체도 재미있어서 정신없이 하다 보면 "한 턴만 더..." 하면서 주말이 순식간에 삭제되어있는 경우가 흔하다. 꼭 시간이 넘쳐 흐를 때 플레이하도록 하자. 그렇지 않으면 일상이 망가질 수 있다. 어떻게 알았냐고? 나도 별로 알고 싶지 않았다.
