[바미] 만 3년 개발자의 회고

들어가기전에..

한 회사에서 신입으로 입사한 지 엊그제 같은데 벌써 만으로 3년이라는 시간이 지났다.

백엔드 개발자를 지원하여 입사하게 되었지만 처음엔 프론트엔드 개발부터 시작하여, 현재는 백엔드 개발을 하고 있다.

 

3년이라는 시간이 지나며 여러개의 큼지막한 프로젝트를 진행하였고, 블로그를 관리하며 개발 관련 된 부분들을 공부했던 것들을 정리하였지만 지금까지 있었던 일들을 되짚어 보아야 할 필요성을 느끼게 되어 지금 내가 잘했던 점, 아쉬웠던 점을 적어보려한다.

---

좋았던 점

여기에선 내가 지금까지 시간을 보내면서 잘했던 점, 좋았던 점을 써보려한다.

다양한 프로젝트 경험

지금까지 Node.js, Typescript, Javascript, Java, Go를 사용하여 프로젝트를 진행했던 경험이 있다.

Node.js와 Typescript, Javascript를 사용하여 회사 자체 홈페이지와 페이지내에서 전송한 Inquery, 이력서, 공고를 관리하는 어드민 페이지를 개발했다.

 

Javascript중에서도 pixi.js라는 라이브러리를 사용하여 트래이딩 플랫폼 개발에 참여했고,

이 플랫폼에서 발생하는 로그 수집 서버를 Go(Mux, Negroni, Sarama)를 사용하여 개발했고, 이 프로젝트를 진행하며 분산 메시징 시스템인 'Kafka'에 대해 공부할 수 있는 기회가 주어졌고 이를 바탕으로 구현하였다.

 

Java를 사용하여 BP(Business Process) Server와 FEP(Front End Processor) Sever를 유지보수를 하였다.

이 서버들은 회사에서 서비스중인 페이지의 데이터를 관리하는 서버라고 생각하면 되는데  FEP Server는 외부로부터, 타 서버로부터 데이터를 받아와 전체 데이터 중 필요한 부분만 가져와 BP Server에게 전송하는 역할을 하고 있고, BP Server는 FEP Server로 부터 받은 데이터를 Redis와 DataBase의 형식에 맞게 수정하여 전송, 저장하는 서버이다.

 

이 프로젝트를 통해 비관계형 데이터베이스 관리 시스템인 'Redis'를 알게 되었고, Redis의 기능 중 hset, publish기능을 사용하여 가장 마지막에 저장된 데이터를 클라이언트가 조회할 수 있도록 하였고, 실시간 데이터를 제공하였으며, 특정 조건에 도달하면 Telegram Bot에 알림을 보낼 수 있도록 기능도 추가하였다.

다양한 문제 직면

회사 홈페이지를 개발했을 때는 내가 신입시절 개발했던 페이지와 어드민 페이지를 리뉴얼하여 만든 페이지였다.

이를 리뉴얼하기 위해서는 기존에 어떤 의도로 개발이 되었는 지 파악해야 했었고, 새로 리뉴얼되는 기획에 맞추어야 했었다.

특히 기존에 개발했었던 개발자가 퇴사하게 되면서 해당 함수가 왜 필요한지, 코드를 가공하기 위해 파악하는 부분에 조금 어려웠다.

 

트래이딩 플랫폼을 개발하게 되면서 UI를 구현하고, 기능을 구현하는 부분을 맡았는데  Canvas환경에서 구현하는 것이다 보니

팝업형태의 UI가 많았는데 기존에 만들어진 UI 부분들이 통으로 구현되어 있어 해당 UI를 유지보수 하는데 큰 어려움을 겪었고,

이를 통해 어떤 UI를 구현할 때는 div 영역을  나누어 관리 하는 것이 굉장히 편하다라는 것을 경험했다. 

그리고 팝업 형태의 UI를 열고 닫거나, 어떤 버튼을 클릭하여 어떤 이벤트를 만들어낼 때, 어떤 목록 UI를 열고 닫을 때 DOM Nodes 부분이 늘어나는 것을 경험했다. 그러니까 메모리 누수가 생긴 것이다.

이 때 내가 해결했던 방법은 pixi.js 중 destroy()함수를 UI를 구성하는 최상단 부모 함수에 구현 하였고, UI를 닫는 이벤트 안에 부모의 destroy()함수를 호출하도록 하여 메모리 누수를 막았고, 버튼 이벤트 시 발생하는 메모리 누수는 익명함수가 원인이였기 때문에 익명함수를 사용하는 부분을 전부 수정하였다.

 

Java를 사용하여 BP Server와 FEP Server를 유지보수 할 때는 특히 BP Server에서 많은 문제를 직면하였는데

특정 거래소에서 밀리초 단위로 데이터가 들어왔고, 하루에 많게는 10만개 ~ 25만개의 데이터를 클라이언트 서버에 Redis를 활용해

전송해야 했고, DB에 1분 단위 데이터를 가공해야 했었다. 

하루에 10만개 ~ 25만개의 데이터가 들어왔기 때문에 BP Server에서 거래소 서버의 데이터를 제대로 가져오지 못했다. 예를 들면 03시 02분 01초의 데이터를 03시 02분 03초에 밀려서 가져오게 되었고, 이 때문에 1분 종가 데이터를 정확하게 저장하지 못하는 문제가 생겼다. 처음에는 거래소 서버 거래 체결시간과 현재 로컬 시간은 맞지 않기 때문에 이로 인해 생긴 것이라 생각했지만원인은 Hset을 담당하는 부분과 publish를 담당하는 부분이 하나로 이루어져서 생겼던 것이 이유였다. 그래서 Hset과 publish를 담당하는 구조를 따로따로 처리할 수 있도록 변경하였고, Redis 서버 메모리도 증축시켜 해결하였다.그리고 Java로 구현한 서버였기 때문에 여러 스레드 문제도 직면했다.

 

이외에도 많은 문제를 직면했는데 아래 링크에서 회사에서 겪었던 문제를 정리했다.

'프로그래밍(Web)/업무관련' 카테고리의 글 목록

다양한 부서와의 커뮤니케이션

들어가기 전 개발 언어를 모르는 직원들을 비판하는 게 아니라는 점을 알아줬으면 한다.

현재 다니고 있는 회사엔 어떤 프로젝트를 맡았냐에 따라 의사소통 하는 사람들, 부서들이 달라졌다.

 

주로 비개발자들과의 커뮤니케이션이 이루어졌었는데 회사 온 지 얼마 안된 신입 시절 기획을 담당하는 부서 직원과 질의를 메신저 또는 대면으로 이야기 할 때 나에게는 자연스러웠던 개발언어를 끼워가며 얘기했던 적이 있다.

그 때는 나름 '그래도 이 정도면 쉽게 이해했겠지?' 싶었지만 전혀 그렇지 않았다. 그 때 개발자와 비개발자의 소통 방법이 다르게 해야 한다는 것을 깨달았다. 그래서 쉽게 풀어서 이야기를 하거나 어떤 비유를 들어주거나 그림판에 그림을 그려 설명해주며 그들과 원활한 소통을 이뤘고, 개발하기 전에 조금이라도 이상한 부분들을 기획단계에서 조율한 뒤 개발 단계를 진행할 수 있었다.

 

주로 비개발자와의 소통이 잦다보니 개발자와의 소통을 비 개발자와 얘기하는 방법을 사용하는 습관이 생기게 되었다. 

그럴 때마다 '그걸 왜 그렇게 길게 말해?'라는 소리를 듣곤 했었다.

 

개발자와는 보통 어떤 문제가 생겨 해결책을 찾을 때, 개발에 유관한 잡담을 자주한다.

먼저 어떤 문제가 생기게 되었을 때 현재 구조는 이렇고, 이런 문제가 생겨 이런 부분을 사용하여 해결하려 하는데 이 방법도 맞지 않아 뾰족한 방법을 알고 있는지에 대해 물어보았고, 점심 때나 휴식시간을 이용하여 현재 내가 공부하고 있는 부분들을 공유했었다. 

 

회사에서 개발할 때 나 혼자만 개발하는 것이 아니기 때문에 미래의 나를 위해, 내가 작성한 코드를 수정할 사람을 위해 꼼꼼하게 주석처리하기도 한다. '주석 없이 이해할 수 있는 코드로 만들어라'는 말이 있지만 설령 그런 코드여도 1달 지나면 까먹기 마련이다.

 

개발은 혼자 하는 것이 아니라 다 같이 하는 것이기 때문에 소통하는 부분이 제일 중요하다 생각하기 때문에 코딩 다음으로 잘 하고 싶고, 잘하려 하는 것이 커뮤니케이션 능력이다.

 

혼자 진행하는 토이프로젝트

GitHub - ckdqja135/ChurchOppa: --First

무언가 갖춰진 프로젝트만 진행하다보니 내가 어떤 아키텍쳐를 꾸리거나 개발 환경을 셋팅하는 일을 하지 못했다.

이 것을 보완하기 위해 토이프로젝트를 진행했다. 그렇게 '교회오빠'라는 교회를 리뷰하는 서비스를 개발하게 되었는데

개발하다 보니 그 안에 데이터만 바꾸면 어떤 것이든 리뷰하는 플랫폼으로 만들게 되었다.

 

예를 들어 이 안에 식당 관련 데이터로 셋팅하면 식당을 리뷰하는 사이트가 되는 것이고, 회사 관련 데이터로 셋팅하면 회사를 리뷰하는 사이트가 되는 것이다. 이 사이트를 기획할 때 오마주했던 사이트는 '크레딧잡'이였다.

 

'교회오빠' 사이트를 개발하면서 처음 1주는 환경 셋팅하고, 난생 처음 해보는 UI 구조짜기에 많은 애를 먹었다.

그 후엔 코드 구조를 개편하는 데 3주 가까이 시간을 쏟았다. 처음에 그냥 주먹구구식으로 하다 보니 내가 기능을 추가할 때마다 많은 시간이 들었고, 상당히 불편했다.

 

그래서 회사에서 개발했던 개발 아키텍쳐를 참고하여 코드를 개션하는데 3주 가까운 시간을 쏟아냈고, 그 이후엔 개발 속도가 눈에 띄게 향상됐다. 그 때 깨달은 것 중에 코드보다 설계 단계가 제일 중요하다는 것을, 코드가 중요한 게 아니라는 교수님의 말을 그제서야 다시 뼈저리게 느꼈다. 

 

이 때부터 무언가를 개발할 때 설계부터 하는 습관이 생겼다.

 

그리고 이 안에 들어가 있는 코드 중에서 위치를 알려주는 지도 외에는 외부 API를 사용하지 않고 시간이 걸리더라도 직접 구현했다.

외부 API가 덕지덕지 붙어있는 다른 사람들의 결과물을 볼 때마다 '저렇게 쉽게 할 수 있는데 나 혼자 쉬운길을 어렵게 가고 있나?'라는 생각이 들었지만 이 프로젝트 만큼은 그러고 싶지 않았다.

 

그리고 나는 프론트 부분이 매우 약했다. 이 프로젝트에 시간을 제일 많이 허비한 부분이 프론트와 퍼블리싱 부분이였지만

기획 - UI - 프론트 - 백엔드 모두 내가 혼자 만들었다. 다른 사람 도움을 받을지언정 다른 사람 손을 타고 싶지 않았다.

그러다보니 의도치 않게 전체적인 UI를 보면 '누가봐도 이건 백엔드 개발자가 만들었네'라는 티를 내버린 프로젝트였다.

그럼에도 UI - 프론트를 혼자 개발할 수 있던 원동력은 실무에서 UI 개발과 프론트엔드 개발을 했기 때문이 아니였을까? 생각해본다.

블로그

원래 공부하고, 정리하는 것을 깃허브에 마크다운 형식의 틀에서 진행하였는데, 우연한 계기로 블로그를 하게 되었다.

그러다 보니 내가 까먹었던 것들은 빠르게 찾아볼 수 있었고, 내 언어로 정리하다 보니 다시 볼 때 잊은 부분을 다시 상기시킬 때도 도움이 되었다. 

 

블로그가 공부하기 시간대비 효율이 좋았다라고 느꼈다.

먼저 공부하고 싶은 부분을 찾아보고, 내 언어로 정리하는 과정에서 비슷한 부분을 여러번 반복하게 된다.

설령 이 부분이 까먹더라도 내 언어로 작성한 것이기 때문에 다시 상기 시키는데 많은 시간을 내지 않아도 된다.

 

블로그를 통해 글을 쓰는 부분 덕에 회사에 신입이 들어왔을 때 내가 하고 맡았던 프로젝트를 문서로 인수인계 해주는 데 큰 도움을 주었으며 내가 공부했던 것들을 공유하면서 그들에게 큰 도움이 되었을 때 그 뿌듯함은 이루 말할 수 없었다.

---

아쉬웠던 점

3년동안 오점없이 잘하고 싶었지만 그러지 못했다.

 

얉고 넓어진 개발언어

나에게 있어 가장 고민이 되는 부분이다. 어떤 사람은 장점이다.  어떤 사람은 단점이다. 라고 한다.

 

한 언어를 깊게 판 사람을 원하는 회사입장에서는 이 부분이 가장 큰 흠이 된다.

경력으로 이직 하려고 보니 이 부분이 많이 걸렸다. 내가 이력서를 낸 회사들은 한 언어만 깊게 판 사람을 원했다. 

예를 들어 2년 경력이라 하면 2년 동안 하나의 언어로만 개발한 사람을 원한 것이다.

 

이제는 주 언어를 Node로 자리잡고,  Node언어의 숙련도를 높히고 싶은데 지금 다니는 회사도 그럴 수 없는 환경이고, 

이런 회사로 이직하는 것조차 쉽지 않다.

 

일단 이 부분을 매꾸기 위해  '교회오빠'를 Node로 만들었으나 나 혼자 프로젝트를 진행하는 것만으로는 한계가 있다.

 

공부는 많이 했지만..

공부는 많이 했지만 한 것에 비해 큰 성장은 없었다.

지금까지 공부하면서 나는 몇가지를 간과했다.

1. 공부하고, 알아가는 데에만 만족해했다.
2. 어느순간부터 공부하는 목적을 잃어버린 상태에서 공부했다.
3. 공부만 하면 되는 줄 알았다.

먼저 나는 공부하는 것으로만 만족했다.

정확히는 '나는 평일에 퇴근하고 공부하는거니까 이 정도면 잘하고 있는거야'라고 착각했다.

하지만 '써먹지 않으면 아무 소용 없다.'라는 것을 뼈저리게 느꼈다.

 

두 번째로 어느순간부터 목적을 잃어버린 공부가 되었다.

회사에서 어느정도 연차가 쌓여 다음 회사로 넘어갈 시기가 되었고, 이직 준비로 공부를 하게 되었는데 

반복되는 탈락으로 어느센가 의무적으로 하게 되는 것이였다.

 

세 번째는 첫 번째부분과 일맥상통하다. 일과 공부만 하면 어느정도 경지에 오를 것이라는 안일함이 있었다.

하지만 일은 일이였고, 공부는 공부였다. 앞서 말했지만 써먹지 않으면 의미 없었다.

 

그럼에도 불구하고 사람의 성장은 수직 상승이 아니라 계단식 상승이기 때문에 이 부분들이 다음 계단을 오르위한 성장통이길 바라본다.

3년이면 나아질 줄 알았는데..

말 그대로 개발 경력 3년이면 상황이 나아 질 줄 알았다. 고연봉은 바라지도 않았다. 적어도 이직은 잘 될 줄 알았다.

하지만 더 높아진 이직 장벽, 경제 악화로 신규 프로젝트는 생겨나지 않아 얼어붙은 취업시장, 등의 문제로 가로막혔다.

 

Node로만 검색하게 되더라도 나온 회사들의 부류는 다음과 같았다.

1. 퇴사율이 심각한 회사.
2. 회사 평이 좋지 못한 회사.
3. 구로, 가산 등 집에서 먼 회사.
4. 만들어진지 얼마 되지 않은 회사.
5. 20인 미만 회사.
6. Node 외에 PHP, JSP로 개발하는 회사.
7. NFT, 코인 마켓, 성인 방송 플랫폼을 다루는 회사.
8. 9개월 전에 봤던 공고가 지금까지 이어진 회사.

이력서를 낼 만한 회사가 많지 않은 현실이다.

 

마치며..

3년 동안 있었던 일을 회고하며, 나에게 많은 일이 있었다는 걸 알게 되었다.

그 동안은 큰 거 하나에만 너무 몰두하지 않았나? 싶기도해서 큰 프로젝트가 아닌 작은 프로젝트들을 많이 만들어 보려한다.

어떻게든 성장을 멈추지 않을 것이다.

 

그리고 4년차가 되었을 때, 5년차가 되었을 때 지금의 나 보다는 훨씬 성장되어 있는 모습을 기대해본다.