2025 회고글

2025년도에 나에게 있었던 일들을 되돌아보며...

 

서론: 나의 첫 인턴 생활

2025년 6월 23일, 나는 회사의 조직문화 문제를 해결하는 B2B SaaS 스타트업의 멤버로 입사를 하게 되었다. 직군은 Product Engineer였고 Product 전반에 기여하며 제품의 기획-개발-배포-운영까지 전부 담당하는 역할의 직군이었다. 입사 전까지 혼자 프론트개발만 해오던 나에게 ①백엔드, 인프라 등을 다루는 기술적인 성장과 ②소프트 스킬에 대한 성장, ③내 입김이 바로 제품에 닿는다는 기대감, 이 세가지 요소가 매력적이라 생각되어 지원했고 합격하여 인턴생활을 할 수 있었다. 입사전 내가 나에게 기대했던 모습은 고객들의 문제를 해결하기 위해 주도적으로 의견을 내고 제품에 반영하고 기여하며 더 많은 고객사를 확보해 매출을 올려보는 것이었다. 지금와서 생각해보면 가장 어려운 것을 시도하지 않았나 싶다. 돌이켜보면, ①결과적으로 주도적으로 의견을 내는 것, ②제품에 반영하고 기여하는 것, ③매출을 올릴 수 있는 서비스로 만드는 것 이 세 가지 전부 내가 생각한만큼 잘해내지 못한 것 같다. 어쩌면 스스로를 너무 과대평가했는지도 모른다. 

 

낯선 것들과의 만남

입사하자마자 온보딩 기간 거의 없이 바로 프로젝트에 투입되었다. 처음 만들게 된 건 AI회의록 기능이었다. 세부적인 구현 내용은 여기에 쓰진 않겠지만 쓰인 기술들을 단순 나열해보면 NextJS, Express, AWS Lambda, 외부 STT API, Azure OpenAI API 이렇게 5가지가 쓰였다. 나는 프론트엔드 개발만 주로 했기 때문에 백엔드+인프라에 관해서 잘 알지 못하고 있었다. 따라서 처음에는 기능의 파이프라인을 잘 만들기 위해 노력을 했다.

특히 AWS Lambda와 같은 인프라는 프론트엔드 개발을 할 때는 거의 다뤄본 적이 없어서 매우 낯설었다. 함수 배포, 환경 변수 설정, 권한 관리 등 하나하나가 새로운 개념이었다. 거기에 외부 STT 서비스의 API를 연동하는 과정에서는 더 큰 어려움을 겪었다. 외부 서비스 특성상 네트워크 지연, Gateway 타임아웃 등 내가 컨트롤할 수 없는 변수들이 많았고, 이를 적절히 핸들링하는 것이 쉽지 않았다. 에러가 발생했을 때 그것이 내 코드 문제인지, 인프라 설정 문제인지, 아니면 유저의 특정 행동 때문인지 알 수 없었기에 막막했다.

가장 기억에 남는 문제는 회의록을 요약하는 Azure OpenAI API가 내부에서 동작하는 Lambda 함수가 API Gateway의 29초 타임아웃 제한을 초과하는 경우였다. 긴 회의록일수록 AI 프롬프트 처리 시간이 길어졌고, 29초를 넘어가면 사용자에게는 에러가 반환되었다. Lambda 함수 자체는 계속 실행되고 있는데 API Gateway에서 연결이 끊겨버리는 상황이었다. 그 당시까지만해도 AWS API Gateway가 29초 타임아웃을 가지고 있는지 몰랐기 때문에 해결 방법을 찾는데 시간이 다소 소요되었다. 해결 방법을 찾아봤을 때 AWS SQS를 활용한 비동기 처리 방식이 있었는데, 당시 상황에서는 큐 시스템을 새로 구축하고 폴링 로직을 추가하는 것이 너무 복잡하다고 판단했다. 대신 회의록 요약 처리를 Lambda가 아닌 Express 서버로 가져와서 처리하는 방식으로 문제를 해결했다. 이 과정에서 AWS 인프라의 제약사항과 특성을 하나씩 배워나갔다. 처음에는 모든 것이 낯설고 막막했지만, 문제를 하나씩 해결하면서 백엔드와 인프라에 대한 이해도가 조금씩 높아졌다. 프론트엔드만 다뤘던 내가 API Gateway, Lambda, 외부 서비스 연동까지 직접 구현하고 배포할 수 있게 된 것 자체가 큰 성장임을 체감했다.

 

제품을 만든다는 것

사용자들에게 서비스되는 제품을 만든다는 것이 이렇게 어려운 일인지 몰랐다. Product Engineer로써 기획부터 배포까지, 전체 사이클을 경험했다. 이 때 기획단계에서 주도적으로 의견을 내는 것에 대한 어려움을 겪었다. 핑계처럼 들릴 수도 있지만 회사의 비즈니스를 내가 깊이 공감하고 알지 못하면 주도적으로 일하기 어렵다는 것을 깨달았다. 내가 생각한 "주도적"이란 고객의 pain point를 찾아내서 서비스를 기획하고 배포하여 서비스할 수 있음인데 "주도적"이 되려면 무엇보다 서비스가 무엇을 해결하는 서비스인지 정말 구체적으로 잘 알고 있어야했다. 하지만 나는 조직문화에 대해서 하나도 모르고 있었다. 처음 입사한 회사가 이번 회사이기도 하고 5인 정도의 작은 스타트업이었기 때문에 다니던 회사에서도 고객들이 겪고 있는 문제를 체감할 수 없었다.

제품 전반을 파악하고 주도적으로 의견을 낼 수 있게 되기 위해 나는 몇 가지 노력을 했다. HR 커뮤니티(기고만장, 체인지)와 같은 곳에 가입해서 눈팅하며 실제로 회사의 HR들의 현재 과제는 무엇인지 파악하려고 노력했고 내가 입사하기 전에 있었던 고객들과의 메시지 히스토리를 읽어보며 제품의 히스토리를 파악했다.

그리고 무엇보다 중요했던 것은 실제 사용자들의 피드백을 직접 받아보는 경험이었다. 내가 만든 기능에 대해 고객이 "이 부분이 불편해요", "이렇게 바꿔주시면 안 될까요?"라고 말하는 것을 들으면서 많은 것을 배웠다. 개발자로서 나는 항상 예쁜 코드를 쓰기 위해 고민해왔다. 클린 코드, 효율적인 알고리즘, 재사용 가능한 컴포넌트 설계 등을 중요하게 생각했다. 하지만 좋은 제품을 만드는 것은 좋은 코드를 만드는 것과 크게 상관이 없었다. 아무리 코드가 아름답게 작성되어 있어도 사용자가 원하는 기능이 없거나, 사용하기 불편하면 그것은 좋은 제품이 아니었다. 반대로 코드가 다소 지저분하더라도 사용자의 문제를 정확히 해결해주면 그것이 더 가치 있는 제품이었다. 이러한 깨달음은 내가 엔지니어로서 무엇에 집중해야 하는지에 대한 관점을 완전히 바꿔놓았다.

+) 어쩌면 스타트업이고 빠른 실험을 통해 고객을 확보해야 되었기 때문에 이런 사고과정이 있었을지 모른다. 

 

스타트업이라는 환경

5인 규모의 초기 스타트업은 내가 상상했던 것보다 훨씬 빠르게 움직였다. 대기업이나 중견기업에서는 몇 주가 걸릴 의사결정이 여기서는 하루 만에, 때로는 몇 시간 만에 이루어졌다. "이 기능 만들어볼까요?"라는 질문이 오전 회의에서 나오면, 오후에는 이미 개발이 시작되고 다음 주에는 배포되는 식이었다. 처음에는 이 속도가 당황스러웠다. 충분한 검토와 계획 없이 진행하는 것 같아 불안했다. 하지만 시간이 지나면서 이것이 스타트업의 생존 방식임을 이해하게 되었다. 완벽한 계획보다 빠른 실행과 수정이 더 중요했다.

작은 조직이었기 때문에 빠른 개발이 매출에 바로 반영될만한 경험도 할 수 있었다. 200인 규모의 회사가 우리의 고객이 되고 싶다고 연락이 왔고 이들이 원하는 새로운 기능이 있었다. 이는 바로 매출로 크게 직결되는 부분이라 현재 없는 기능임에도 불구하고 다음주에 릴리즈될 기능이라고 안내하고 2-3일만에 기획-개발-QA까지 완료했어야했다. 밤을 새고 개발을 했고 2-3일만에 1차적으로 MVP를 뽑아낼 수 있었다. 하지만 아쉽게도 고객의 사정 때문에 딜이 무산되었지만 나로서는 정말 빠른 사이클을 경험할 수 있었다.

팀원들과의 협업도 독특했다. 공식적인 회의보다는 수시로 자리에서 일어나 이야기를 나누는 방식으로 일했다. "이 부분 어떻게 처리할까요?" 하고 물으면 바로 옆자리에서 함께 화면을 보며 해결책을 찾았다. 각자의 역할이 명확하게 구분되어 있기보다는 필요에 따라 서로의 영역을 넘나들며 일했다. 나도 프론트엔드뿐만 아니라 백엔드, 인프라까지 손대게 된 것도 이런 환경 덕분이었다. 처음에는 모든 것을 다 해야 한다는 부담이 있었지만, 나중에는 이것이 가장 빠르게 성장할 수 있는 환경이라는 것을 깨달았다.

 

6개월이 지나고

6개월 전 입사할 때의 나는 프론트엔드 개발만 할 줄 아는, 좁은 영역에 갇혀 있던 개발자였다. 코드를 잘 작성하는 것이 좋은 개발자의 조건이라고 생각했고, 사용자나 비즈니스에 대한 고민은 다른 누군가의 몫이라고 여겼다. 하지만 지금의 나는 제품 전체를 바라볼 수 있게 되었다. 프론트엔드부터 백엔드, 인프라, 그리고 기획까지 전체 파이프라인을 이해할 수 있다. 또, 소프트스킬에 있어서 아직 완벽하진 않지만 타인에게 내 상황을 공유하기 위한 필요조건이 무엇인지도 알게 되었다. 인턴 과정을 통해 단순히 주어진 작업을 구현하는 것을 넘어서, 왜 이 기능이 필요한지, 사용자에게 어떤 가치를 줄 수 있는지 고민하게 되었다.

가장 크게 성장했다고 느끼는 부분은 기술적인 역량보다 문제 해결 능력이다. AWS Lambda의 타임아웃 문제를 마주했을 때, 처음에는 막막했지만 결국 가장 좋은 해결책을 찾아냈다. 에러 로그를 읽고, 문서를 찾아보고, 여러 선택지를 비교하며 최선의 방법을 선택하는 과정을 경험했다. 또한 좋은 코드와 좋은 제품의 차이를 이해하게 된 것도 큰 성장이었다. 사용자 피드백을 직접 받아보며 개발자로서의 관점을 넓힐 수 있었다.

하지만 아쉬운 점도 많았다. 특히 초반에 비즈니스와 고객에 대한 이해가 부족했던 것이 아쉽다. 더 일찍 고객의 목소리를 듣고 HR 커뮤니티를 탐색했더라면, 더 주도적으로 제품에 기여할 수 있었을 것 같다. 또한 때로는 빠른 실행에만 집중하다 보니 코드의 품질이나 유지보수성을 놓친 부분도 있었다. 때문에 QA기간에 QA가 아닌 기능 개발을 하는 나도 발견할 수 있었다. 앞으로는 속도와 품질 사이의 균형을 더 잘 맞추고 싶다. 그리고 무엇보다 제품과 사용자에 대한 깊은 이해를 바탕으로 진짜 일을 하는 엔지니어가 되고 싶다.

 

2026년을 향해

이 6개월의 경험은 내가 어떤 개발자가 되고 싶은지에 대한 방향을 제시해주었다. 단순히 코드를 잘 쓰는 개발자가 아니라, 제품을 이해하고 사용자의 문제를 해결할 수 있는 개발자. 기술 스택에 갇히지 않고 필요한 것을 배워가며 전체 파이프라인을 책임질 수 있는 개발자. 이것이 내가 앞으로 나아가야 할 방향이라는 확신을 얻었다. 또, 빠른 시일 내에 내가 체득한 것들을 나만 가지고 있지 않고 내가 애정하는 Greedy(교내 동아리) 친구들에게 나의 관점을 공유하며 나눌 수 있는 시간이 되었으면 한다.

2026년에는 캡스톤 디자인이라는 큰 전공필수 수업이 남아있는데 이 수업에서 내가 체득하고 배운 것들을 적용해서 팀을 이끌어나가 좋은 제품을 만들어보고 싶다. 특히 최근에는 로봇 분야에 대한 관심이 생겼다. Three.js와 ROS/ROS2 센서 데이터를 활용해 로봇의 움직임을 웹에서 비주얼라이즈하는 것에 대한 욕망이 생겼다. 로봇 개발자들이 복잡한 센서 데이터를 더 직관적으로 이해하고 디버깅할 수 있도록 돕는 웹 기반 도구를 만드는 것, 이것이 내가 다음에 해결해보고 싶은 문제다. 프론트엔드 기술과 로봇 공학이 만나는 지점에서 의미 있는 제품을 만들어보고 싶다.