프롤로그

작년 이야기

회사가 점차 어려워짐을 24년부터 슬슬 느끼고 있었다. 내가 기존에 개발해 오던 어드민 개발 프로젝트의 중요도는 차차 떨어지고, 회사는 크게 관심 없던 B 프로젝트를 다시 공략해 보려는 조짐이 보였다.

처음 B 프로젝트를 준비한다 했을 때, CTO님은 나와 동기 중 누구와 함께 B를 할지 고민이라고 했다. 나는 B 프로젝트를 크게 염두에 두고 있지 않았는데, 이유는 B 프로젝트를 진행하게 되면 개발이 아닌 운영 업무를 위주로 한다 했기 때문이다. 개발을 하게 된 지 1년이 안 됐을 때였는데, 개발이 아닌 운영을? 개발자로서의 길이 끊길 것 같았다.

다행히(?) 동기는 B 프로젝트에 흥미를 느껴 CTO님과 함께 진행하게 됐고, 나는 그 외의 나머지 프론트엔드 프로젝트 전반을 맡게 되었다.

주요하게 맡았던 어드민 사이트는, 어드민치고 디자인 시스템부터 Quill을 활용한 글 작성 등 다양한 기능이 많았고, 많은 것을 배운 프로젝트였다.

그렇게 많은 기능이 있었지만 마케팅의 부재인지, 명확한 방향성의 부재였을지 어드민의 중요도가 점차 떨어졌다. 그러는 와중에 C 프로젝트가 새로이 올라왔다. B 프로젝트에 동기가 갔고, C 프로젝트를 맡을 사람이 나뿐이었다.

C 프로젝트 - 혈액암 연구 통합 사이트

C 프로젝트는 혈액암 관련 연구를 하는 의사들을 돕는 프로젝트였다. 정부 연계 프로젝트였으며, 5개년 프로젝트로 기억한다.

병원에서의 연구는 하나의 병원에서만 진행되는 것이 아니다. 하나의 주제를 두고 다양한 병원에서 여러 실험자를 대상으로 실험하고 연구한다. 이렇게 비슷한 연구를 진행하는 병원들끼리 내용을 공유하려 할 때 제대로 공유가 안 되는 문제가 있었다. 왜 공유가 어려웠는지 살펴보니, 각 병원의 연구자들은 연구 결과를 본인이 알아보기 쉽게 정리해서 가지고 있었다. 가령, 다발골수종(Multiple myeloma)이라는 이름이 있을 때 이를 'Multiple myeloma'라고 적거나, 'mm'으로 적거나, 'multi myeloma'로 적는 식이었다. 이런 키 값이 한두 개 있으면 보고 맞추면 되겠지만, 이러한 키가 300개, 400개를 넘어서는 상황이었다.

CTO님이 이를 해결하는 방법을 구상하였고, 나는 이를 손쉽게 관리할 수 있는 페이지를 만드는 것이 일이었다.

C 프로젝트가 재미있었던 건, 스택 선정부터 디자인까지 프론트엔드 관련 모든 부분을 나에게 일임해 줬기 때문이다. (물론 Vue3를 선택한 건 약간의 윗선 압박이 있었다)

많은 레퍼런스를 참고하며 퍼블리싱하고, API를 호출하여 화면을 그렸으며, 반응형으로 구현하여 사용성을 높였다.

궁금한 건 여러 개 적어 놓고 한 번에 물어보고 답하며, 그에 맞게 수정하며 완성도를 높여갔다. 1차 개발 이후에는 실제 병원에 방문하여 의사 선생님과 대화하며 어떤 기능이 더 추가되길 원하시는지, 어디를 보완하면 좋겠는지에 대한 이야기도 나누며 2차 개발을 진행하였다.

계속 개발하며, 어떻게 하면 사용자가 쉽게 사용할 수 있을까 고민했다. 사용자의 입장에서 개발하려 노력했다. 특히 2차 프로젝트 마지막에 사용법을 자료실의 형태로 만들어 쉽게 보여줬던 페이지가 있었는데, 해당 페이지를 만들어 공유했을 때 CTO님께 잘했다며 칭찬받은 기억이 남는다.

C 프로젝트의 2차 개발이 마무리되고,  어드민의 다음 개발이 모호해졌을 때 D 프로젝트를 진행해 보는 게 어떻겠냐는 요구사항이 들어왔다.

D 프로젝트 - 사내 출퇴근 웹앱

D 프로젝트는 사내 출퇴근을 관리하는 웹앱 프로젝트였다.

기존에는 타 스타트업의 출퇴근 관리 앱을 사용 중이었는데, 이게 유료화되면서 비용을 줄일 겸 인적 자원으로 해결해 보자! 하는 프로젝트였다.

이 프로젝트의 재미는 크게 2가지였다.

1. 내가 정하는 기술 스택 - Shadcn, React 등등…
2. Airtable DB 사용

당시 Shadcn이 막 뜨고 있는 시기였다. Tailwind를 잘 사용하고 있던 나로서는, 디자인조차 정해져 있지 않은 D 프로젝트에 Shadcn은 깔끔한 기본 UI를 제공해 주었다.

Airtable은 대부분의 개발자에게 아직도 조금 낯설 것 같다.(아닌가?) 누구나 쉽게 다룰 수 있도록 만든 관계형 데이터베이스인 Airtable은 백엔드 없이도 DB를 구성하여 API를 사용할 수 있는 재미있는 서비스다. 이 서비스는 사내 다른 프로젝트에서 쓰고 있는 걸 몇 번 보곤 했는데, 마침 D 프로젝트에 붙어줄 백엔드 자원도 없고, DB 비슷하게 생각하며 구현할 수 있는 점이 마음에 들었다.

이때에도 참 부딪히며 많이 배웠다. ISO8601로 넘어오는 시간을 timestamp로 변경해야 했던 일, 위치 정보를 받아와 회사와 가까울 때 출근 등록이 되게 하기, 버튼 하나의 활성화나 어떤 버튼이 보일지에 대해서의 시나리오를 고민하면서 개발하는 것에도 재미를 느꼈다.

2주 안걸려서 기본적인 기능을 정의하고 개발한 후에, 다양한 디테일을 추가하였다.

마지막으로 CI 설정을 통해 자동배포까지 처리하며, 해당 프로젝트를 마무리하게 됐다.

회사에서 나오다 내보내졌다

그럼에도 회사는 수익을 낼 방법을 찾지 못했고, 결국 권고사직을 받게 되었다. 재직 중에는 빨리 이직하고 싶다는 생각을 했었는데, 막상 권고사직을 받아보니 기분이 참 씁쓸했다.

사람이 하나 둘 떠나며 곧 내 차례가 오겠구나 생각만 했다가, 실제로 나에게 닥치니 그 상황이 문득 꿈인가? 싶었다.

하지만 씁쓸함도 잠시, 이야기를 들은 다음 주부터는 미뤄왔던 공부를 더 하고 이력서와 포트폴리오를 잘 준비해서 이직해야지! 하는 묘한 자신감과 기대감이 커지기 시작했다.

구름톤

퇴사 후, 과거에 여러 번 지원했던 구름톤에 한 번 더 지원했다. 마침 13기가 오픈해서 빠르게 지원했고, 운 좋게도 합격할 수 있었다.

어렸을 때부터 제주도를 좋아했는데, 제주도에서 5일간 해커톤이라니? 정말 안 가고 못 배겨!

구름의 디자인 시스템을 공부하는 시간에 앞서 회사에서 만들었던 내 디자인 시스템이 너무 단순(?) 했다는 걸 깨달았다. 물론 디자인 시스템 전담 팀이 있는 규모 있는 회사의 디자인 시스템과 소규모 인원이 시간을 내어 만든 디자인 시스템 사이에는 당연히 차이가 있었을 것이다. 2~3시간 정도의 짧은 강의였지만, 디자인 시스템을 어떻게 사용하고 활용하는지에 대해 많이 배울 수 있었다.

다음 날, 각자 뭘 만들고 싶은지 PR을 한 후 랜덤으로 조를 짜게 됐다. 한 팀당 프론트 2명, 백엔드 1명, 디자이너 1명, 기획자 1명으로 총 5명이 한 팀을 이룬다. 마지막까지 한 명씩 짝이 맞지 않아 발을 동동 구르며 기다렸는데, 결국 맞춰졌다. 원하는 사람끼리 모인 조는 아니었지만, 이렇게 우연이 쌓인 우리 팀. 운명이 아니었을까?

조가 짜여지고 식사하며 어색했던 분위기를 한 껍질씩 벗겨냈고, 정말 말도 안 되게 금방 친해졌다. 숙소로 이동하는 버스 안에서도 한바탕 수다를 떨며 '참 우연히 모인 조 치고는 너무 잘 맞네..' 생각했다.

재미있는 다양한 일정 이후(너무 축약했나 ?), 해커톤이라는 이름답게 밤샘 코딩을 시작했다.

마지막 제출 시간인 오전 10시 5분 전까지 개발하고, 영상 편집하고, 기획자는 발표를 준비하고, 디자이너는 PPT를 만들었다. 불타오르는 열정으로 발표를 마치고 결과 발표의 순간이 왔다. 사실 큰 기대는 하지 않았다. 다른 조들의 아이디어와 설명도 너무 좋았고, 대상은 전혀 생각하지 않고 우수상 정도만 받아도 좋겠다고 생각했다.

— 우수상 00팀~

• 아, 우리 아니네. 혹시 최우수상...?

— 최우수상 00팀~~

• 아, 아쉽다~ 그래도 우리 팀이 제일 재밌게 잘했어. 다들 고생했어 ㅎㅎ

— 대상은 바로,, 박구영(우리) 팀!!!!

• ?????????!?!?!!?

대상이라니!? 진짜 0_0??? 이 표정이었음 우리 모두 ㅋㅋㅋㅋ 엄청 열심히 한 건 맞는데 대상은 진짜 생각도 못 했다가 대상이라는 큰, 가장 값진 결과까지 얻어가다니.

너무 뜻깊고 의미 있는 2월을 보낼 수 있었다.

이직

이력서, 포트폴리오를 찬찬히 작성하고, 여기저기 제출하게 됐다. 다행히도 몇몇 군데서 연락이 왔고, 하나 둘 면접을 보고 좋은 결과를 얻을 수 있었다.

입사했을때야 비로소 프론트가 나 혼자라는 걸 알았는데, 2~3달 뒤 Poc가 있다고 했고 이를 대응하기 위해 전반적인 프로젝트의 기능을 잘 동작하게 해달라는 게 이사님의 요구사항이었다.

현 회사에 왔을 때 가장 놀랐던 점은.. 제대로 돼 있는게 없다는 것이었다. 어떻게 이 상태로 1, 2년을 가져가고 있었지? 싶을 정도로, 심각했다. 전반적인 흐름이 있어야 할 것인데, 흐름이 자꾸 끊기고, 되는 게 없었다. 분명 다양한 회의와 시도의 흔적들은 많았는데, 그게 끝이었다. 바닥부터 바꿔야 했다.

디자인 시스템 걷어내기

가장 처음 시작했던 건 디자인 시스템 라이브러리를 걷어내는 일이었다. 새롭게 만들 생각은 커녕, 걷어내는 일이라니? 그렇다. npm으로 자체 디자인 시스템을 구축하여 변경 사항마다 다운로드받아 적용하는 식이었던 디자인 시스템은, 겉보기엔 훌륭했지만 많은 문제를 앉고 있었다.

디자인 시스템을 사용중, 변경이 필요하다면 디자인 시스템 라이브러리로 들어가 수정하고 테스트하고 다시 배포 후 실제 서비스에서 사용해야한다. 당연히 완벽한 라이브러리는 없다지만, 속도가 중요한 스타트업에서 이는 시간 소모가 엄청났다.

또, svg가 이상하게 잘린다거나, 사용방법이 단순한 듯 의외로 복잡한 ? 부분들이 있었고, 기존 프론트엔드 개발자들 모두 이 문제점에 대해 토로하고 있었다.

왜 앞서 고치지 않았을까? 이 역시 시간을 이야기하며, 그걸 복구하는데도 너무 오래걸린다는 내용에 윗선에서도 그냥 기능 개발을 우선적으로 하자. 가 돼 버렸던 것이다.

나는 현 상황에서 가장 빠르게 디자인 시스템 문제를 해결할 수 있는 방법은 디자인 시스템 라이브러리를 걷어내고 각 프로젝트에 두는 것이 우선이라 생각했다. Chakra UI, Emotion을 사용하고 있었는데, 이 라이브러리를 아예 tailwind로 변경하며 새롭게 시작하는 것엔 더 큰 시간과 리스크가 있을거라 생각했다. 하여, 디자인 시스템을 다 빼고 각 프로젝트마다 컴포넌트를 두어 개발하는 식으로 가져가겠다하니, 역시나 윗선에서 걱정스런 눈빛을 보냈다.

— 그게 한달만에 가능해요? 아니 앞선 친구들도 그거 다 분리하는거 아예 못한다고 그랬던건데..

— 괜히 건드렸다가 다른 부분 못하지 말고, 그건 추후에 작업하고 일단 기능 개발을 먼저 하시죠?

하지만 나는 이런 기본적인 것부터 잘 돼야, 그 다음 작업을 할 수 있겠다 생각하여 이를 어필했고, 한 달안에 성공하겠다 약속했다.

그리고 해결했다.

간단하게 (?) 디자인 시스템 라이브러리에 구현된 버튼부터 헤더등 여러 컴포넌트를 각 프로젝트에 옮기는 것이었다.

내부 구현 자체가 이해하기 힘들거나 말이 안되는 부분들 모두 수정하였고, Chakra UI를 더욱 활용하여, 기존에는 없던 theme에서의 다양한 기준을 확립했다. 잘리는 svg와 같은 이상 현상을 없앴고, 공통화되지 않은 부분또한 공통화하여 디자인 시스템 라이브러리를 쓰지 않고도 더욱 체계적인 디자인 시스템을 갖추게 됐다.

물론, 최고는 아니지만 최선의 선택이었다고 생각한다. 디자인 시스템이란 건 프론트엔드 개발자 혼자서 만들 수 있는게 아니라, 디자이너와 끊임없이 소통하며 만들어야 한다. 여전히 개선의 여지가 남아있고, 이 또한 좋은 성장의 원천이 될 것이라, 지속적으로 개선중에 있다.

AI, 3D

ai, 3d와 가까워지고 있다.

LLM ai 개발자와 3D ai 개발자와 함께 개발하면서, 기존보다 더 다양하게 활용하고 있다.

기존 CRUD api를 넘어서, 스트리밍 형태의 LLM api를 받아 화면에 그려주고, Gaussian splatting 을 통해 만들어진 3D 파일을 화면에 그려주는 일을 하고 있다.

이러한 3D 파일 위 거리 측정 같은 기능들도 추가하여, 회사가 나아가는 방향에 맞춰가고 있다.

생각치도 못한 3D 작업이지만, 이를 구현하는 작업도 프론트엔드 개발자 입장으로서 나름의 유니크함이 아닐까?

알잘딱깔센

회사에 있는 디자이너분은 신입으로 들어와, 따로 배움을 받을 일이 없었다. 그러다보니 이전에 있던 디자이너의 작업을 참고하여 작업하거나, 개발자와 어떻게하면 더 나은 디자인이 될 지에 대한 고민을 하고 있다는 것을 알았다.

앞서, 이전 회사에는 잘하는 디자이너 친구가 있어 나도 첫 회사에서 디자이너와 함께 일하는 것에 대해 많이 배웠다고 생각했고, 정답은 아니지만 이전에 일했던 방식에 대해 여러가지 도움을 주었다.

이전 회사의 디자이너 친구와 따로 만나 요즘에는 어떤 방식으로 개발자와 소통하며 일하는지를 물어보고, 디자인의 버전관리, 거기의 개발자는 어떻게 디자인을 더 쉽게 활용하는지에 대해 묻고 다음날 우리 회사 디자이너와 토론했던 기억도 있다.

디자이너가 놓치거나 생각하지 않았던 부분 또한 먼저 작업하고, 작업 후 디자이너에게 따로 설명하기도 했다. 가령, A 동작을 했을 때 어떤 식으로 화면이 바뀌어야하거나, 에러처리를 하거나, 메시지를 띄우는 등 사소하지만 디테일에 대한 부분들이다.

또, 회사의 어드민 사이트 같은 경우 디자이너가 신경 쓰지 않고 개인적으로 작업을 하는 경우가 많은데, 이때는 기능과 디자인 모두 스스로 생각하여 작업하기도 했다.

최근에는 OCR을 통해 나온 건축 도면의 텍스트 값이 원하는 텍스트 결과로 나오지 않았을 때 이것의 위치를 옮기고, 수정하고, 삭제하는 페이지가 필요했었던 적이 있는데, 이를 스스로 발견하고 어드민 사이트에 빠르게 구현 후 백엔드와 함께 API 연결하여 기능의 완성도를 높인 기억이 있다.

이러한 일들이 있을때면 디자이너 친구는 ‘승훈님은 역시 알잘딱이시네요~’ 라며 내 어깨를 한껏 높여주었다. 이제는 이러한 일들이 거의 줄어들며, 디자이너 친구도 성장하고 있구나를 느낀다.

함께 성장의 중요함은 개발자끼리만이 아니라, 모든 회사 동료들의 성장이 아닐까 싶다.

모두에게 다정한 사람

이 될 순 없다. 하지만, 그런 사람으로 비춰지기 위해 최선을 다한다. 그게 사회생활 아닐까?

회사에는 많은 인턴이 왔다 떠나갔다. 프론트, 백엔드, AI 가릴 것 없이 많은 인턴이 있었다. 걔 중 당연하게도 프론트로 들어왔던 친구들에게는 되도록 많은 업무를 함께 해보려 노력했다.

인턴 친구들의 역량도 매~~~우 뛰어났기에, 나 또한 많은 것을 배우고 함께 성장했다.

위 사진은 백엔드와 AI 인턴들이 써준 글이다.

ㅋㅋ 다들 입에 발린 말일 수 있지만, 어쨌든 타 팀에서도 나를 좋게 봐주었다는 것, 회사 생활 잘하고 있다는거겠지

항해 플러스 7기

항해 플러스는 벨로그에서 한, 두번씩 봤던 것 같다. 처음엔 오, 항해에서 처음엔 비전공자들 끌어다 신입 만들려하더니 이제 그 신입들 돈 빼먹을 방법을 찾아냈구만 ? 생각했다.

그런데, 글을 읽을때마다 다들 듣길 잘했다며 어디 돈받고 쓰는 사람만치 쓰는게 아닌가? 얼마나 좋은건지 감도 안올 지경이라 커리큘럼을 스윽 살펴봤는데, 헉.. 진짜 내가 모르는데 알고 싶은 내용만 커리큘럼에 모여 있는 것이다. 테스트코드부터 자바스크립트로 SPA 구현하기, 성능최적화 등등.. 나만의 강점이 부족하다 생각하고 어떤 공부를 해야할 지 막막한 시기에 눈에 띈 것도 한 몫 한 것 같다.

목표

처음 목표는 당연하게도 ‘모든 과제 통과하기’였다. 한 주마다 발제 내용을 듣고 기본, 심화과제를 해결하면 되는, 어떻게보면 간단한 일이었다. 하지만 당연하게도, 간단하지 않았다.

첫 주부터 처음 맞닥뜨린 테스트 코드는, 이해하고 써보는 데 절대적인 시간이 부족했다. 이게 정말 직장 다니면서 할 수 있는 게 맞나..? 생각이 들기도 했다.

이후, 과제를 제출하는 금요일 오전 10시 전까지, 목요일은 거의 매주 밤을 새게 됐다..

앞서 말했던 것처럼, 고민하고 시도해보지 않았던 심화된 프론트엔드를 공부한다는 것은 벅찼지만 너무나 도움되는 일이었다. 다 이해하진 못했지만, 어떤 키워드가 있는지, 어떤 것들이 중요한지에 대해 배웠고 이를 회사 업무에도 적용해보려 애쓰고 있다.

최근, 간단한 랜딩 페이지 작업이 있었다. 이 간단한 페이지, 그냥 AI에 물어보면 금방 끝내겠는데? 싶었다가, AI를 활용해서 배웠던 많은 기술들을 적용해보자! 하여 시도했다.

1. FSD 폴더 구조를 통해 순행 참조를 이루어 각 상태와 컴포넌트의 역할을 명확하게 분리했고,
2. E2E 테스트로 모달이 열렸을 때 오류 메시지와 전송했을 때 동작하는 것에 대해 테스트를 작성했다.
3. 또, 최적화를 위해 ffmpeg를 통한 영상 최적화와 이미지의 lazy loading 등을 적용하였다.

배운 것을 간단한 프로젝트에 적용해보며 감을 잃지 않으려 했고, 이제는 이를 실제 프로젝트에 하나, 둘 적용해 볼 예정이다.

네트워킹

다양한 키워드를 얻고, 공부의 방향성을 잡아가는 것도 좋았지만 더욱 의미있었던 건 역시 사람이다. 50여 명의 프론트엔드 개발자를 한 자리에서 만나기가 어디 쉬운가. 오픈카톡방이나 온라인에서야 여럿 있지만, 이렇게 함께 고민하고, 성장욕구 넘치는 사람들을 만난건 정말 최고의 자산이라고 생각한다.

과제를 위해 밤을 샐 때도 혼자가 아닌, 팀과 함께 밤을 새고 함께 고민했던 10주. 내 2025년을 더욱 뜻깊게 만들어주었다!

수료 이후에도 여러 스터디를 개설하여 열심히 하는 사람들을 보며 자극받는다. 나도, 뭐든 열심히 해야지!

고민

많은 기술적 성장과 더불어, 고민 또한 함께 커졌다. 바로, ‘남과의 비교’다.

나는 원체 남과의 비교를 싫어하고, 그러한 생각이 들때면 그 생각이 듦을 알고, 다른 생각을 하려 애쓰곤 한다. 그러나 이번 10주간의 항해 플러스 과정을 겪으며, 세상에는 너무 잘하고, 열심히 최선을 다하는 사람이 이렇게 많구나.. 어떻게 저만큼 하지? 저 사람은 회사 안다니나? 전부 AI로 작업했나? 등등.. 그 사람의 노력까지 평가절하 하려는 생각도 했다.

결국에는 개발자가 나랑 정말 맞나? 라는 생각까지 하게 됐다. AI의 비정상적인 발전 속도, 너무나 개발에 진심인 사람, 취미조차 개발인 사람 등을 보며 스스로 많이 위축된다.

5년, 10년이 지나고나면 대부분의 실력은 비슷해지겠지. 그치만 나는 걔들 중 1프로, 아니 10프로, 아니 30프로 안에 들 수 있는 사람일까? 이러면 결국 또 비교이고, 이 생각의 굴레를 벗어나려 글을 쓰는 지금도 꽤나 애쓰는 중이다.

정답은 없다. 하지만, 후회없는 선택을 하고 싶다.

마치며

큰 일 말고도, 작게는 여러 일이 있었지만 다 적지 못하는 게 아쉽다.

언제나, 지금처럼 작은 일에도 행복을 느낄 수 있는 사람이고 싶다.

2026년에는 또 어떤 일로 풍성한 1년을 보낼 지, 두려우면서도 기대된다 !