7 min to read
양재에서의 3개월 인턴을 회고하며
멋진 회사에서 많은 것을 배운 이야기를 정리합니다
배경과 회사 개요
저의 블로그에는 2025년 하반기의 구직 과정에서 겪었던 생각들을 여러 글로 정리해 두었습니다.
당시에는 구직자의 입장에서 경험을 기록했다면, 이번 글은 그 이후 실제로 일을 하면서 얻게 된 생각들을 정리하는 글입니다.
특히 이번 글은 이전에 작성했던 도메인에 대한 생각이라는 글에서 언급했던 회사에서 약 3개월간 인턴으로 일하며 겪었던 경험을 중심으로 정리해 보려 합니다. 그 기간 동안 저는 AI 시각화 서비스의 백오피스 프론트엔드를 담당하며 여러 작업을 경험했고, 동시에 지금까지의 개발 경험과는 다른 종류의 코드 리뷰 문화와 협업 방식을 접할 수 있었습니다.
짧다면 짧은 기간이었지만, 개발자로서의 사고방식이나 코드에 대한 관점이 바뀌는 계기가 되었던 시간이었다고 생각합니다.
이 글에서 다루는 경험의 배경이 되는 회사와 제가 맡았던 역할을 간략히 정리하면 다음과 같습니다.
앞서 언급한 회사에서 약 3개월 동안 인턴으로 근무하며 AI 시각화 서비스의 백오피스 프론트엔드를 담당했습니다.
- 웹 접근성 개선 (Form 구조 등의 시맨틱 웹, 색 대비 개선)
- DX개선을 위한 선언형 유틸 패턴 내재화
- Release Note 작성을 위한 에디터 구현
같은 것을 해당 회사에서 경험할 수 있었습니다.
이 경험 동안 지식 전달을 목적으로 하는 코드 리뷰 문화나, 지금까지의 저의 개발 생활에서 겪어보지 못했던 새로운 경험 등을 하였고, 기억이 휘발되기 전에 블로그 포스트의 형태로 그 경험을 기록해 보고자 합니다.
경험한 것
처음 마주한 ‘함께 유지보수 가능한 코드’와 정석적 코드리뷰
이 회사에 합류하기 전까지 저는, 실제로 현장에 내놓은 제품의 코드를 작성하고, 이후 유지보수도 했었지만, 어디까지나 저 혼자서 진행하였기에, 어렴풋이 클린 코드 같은 것이 중요하다고 알려져있다 라고만 인지하고 있었을 뿐, 직접적인 체감은 하지 못하고 있었습니다.
반면 해당 회사에서는 새로운 팀원을 적극적으로 모집하는 곳이었기 때문에, 단순히 ‘돌아간다’ 라는 이유 만으로 타인이 이해하기 힘든 코드를 팀 코드베이스에 넣을 수 없는 곳 이었습니다.
현재의 팀원, 그리고 온보딩될 신규 팀원이 이해할 수 있도록, FSD 아키텍처의 컨셉을 일부 차용한 아키텍처 컨벤션을 활용하였고, 적극적 코드 리뷰 문화가 있었습니다. 단순히 LGTM만 하는 곳이 아니고, 코드 리뷰 관련 사내 세미나를 개발팀원 전원을 대상으로 할 정도로, 꽤나 코드리뷰에 진심이었던 곳 이었습니다.
처음 코드 리뷰를 받았을 때는 꽤나 충격이었습니다. 이때까지 FE 코드에 대해서 몇가지 사소한 개선점 같은것을 듣거나, 아니면 아예 제가 모르는 특정 도구나 문법 등의 사용법 등에 대해서 코멘트를 받아봤지, 잘 해왔다라고 생각했던 리액트 코드 작성에 대해서 피드백을 받은 경험이 거의 없었기 때문인 것 같습니다.
처음에는 자아 정체성이 흔들리는것 같은 느낌까지 받았습니다. 저는 ‘생각한 것을 빠르게 구현해 내는 프론트엔드 개발자’라는 정체성을 가지고 있었는데, 흔들린 느낌이었지요. 처음엔 ‘분명히 멀쩡히 돌아가는 코드인데 왜 그렇게 각박하게 대하지’ 라는 생각도 하였으나, 시간이 지나고, 감정이 아닌 논리적 사고로 되짚어 봤을 때, 그런 강도높은 코드리뷰가 합리적인 도출물로 보이기 시작했습니다. 시간이 지나고 감정이 아닌 논리로 다시 생각해 보니, 그 코드 리뷰가 왜 필요했는지 떠오르는 경험들이 있었거든요.
학부 동아리 시절 만들었던 토이 프로젝트를 떠올려 보면, 변경 사항이 생길 때마다 꽤 골치 아픈 상황을 겪곤 했습니다. 예를 들어 새로운 피처가 추가되거나, 프론트엔드에서 직접 호출하던 외부 API가 변경되거나, 공통 로직 함수의 시그니처가 수정되는 경우가 있었습니다. 이런 변경 앞에서 단순히 shared나 lib 같은 폴더에 모여 있던 유틸 코드들은 예상하지 못한 범위까지 영향을 주곤 했고, 결국 문제를 해결하기는 했지만 다음 변경을 두려워하게 되는 바람직하지 않은 상황을 겪었습니다.
이후 현실 세계에 배포되는 코드 등에 대해서는 제가 이해할 수 있는 꽤나 임의적인 ‘자체 기준’을 머리에 내장한 채로 작업을 진행하였기에, 스스로 예측은 할 수 있었지만, 말 그대로 ‘내 머리속’을 벗어나면 다른 사람이 이해하기 난해하여, 코드베이스가 다시 작성이 되었다라는 후일담 같은것을 들을 수 있었습니다.
해당 문제를 예방하기 위해서, 어떤 역할을 담당하는지에 따라서 코드들을 배치하는 FSD 기반 자체 아키텍처를 통해 문제를 해결하는구나 라는 현실의 문제해결 장면을 볼 수 있었습니다.
이미 배포된 서비스를 수정하기 - 달리는 차의 바퀴를 교환하기
유튜브에서 웹툰 작가 진돌이 ‘연재란 무엇인가’에 대해 설명하는 영상을 본 적이 있습니다. 스토리가 있는 작품을 연재하다 보면 서사를 진행하는 과정에서 여러 문제들이 발생하고, 기존의 이야기와 충돌하지 않도록 조정하면서도 동시에 새로운 전개를 이어가야 한다는 내용이었습니다.
실제 배포되어 운영되고 있는 서비스를 개발하는 일도 이와 크게 다르지 않다는 것을 이 회사에서 느꼈습니다. 이미 사용자에게 익숙해진 UI와 기능이 존재하는 상태에서, 새로운 요구사항을 반영하면서도 기존 사용자 경험을 크게 해치지 않아야 하기 때문입니다.
제가 맡았던 웹 접근성 개선 작업에서도 비슷한 상황을 마주했습니다. 특정 색상 조합이 WCAG 색 대비 기준을 만족하지 않았지만, 이미 서비스에서 사용되고 있던 브랜드 색상을 완전히 바꾸는 것은 현실적으로 어려운 상황이었습니다. 결국 기존 디자인을 크게 해치지 않으면서도 접근성 기준을 만족할 수 있는 절충안을 찾아야 했습니다.
표면적으로는 단순히 색상과 관련된 작업처럼 보일 수 있지만, 이 경험을 통해 ‘이미 달리고 있는 서비스 위에서 수정을 진행한다’는 것이 토이 프로젝트의 수정과는 전혀 다른 문제라는 것을 실감하게 되었습니다. 이 경험이 인상 깊어 별도의 글(관련 글)로 정리하기도 했습니다.
결국 운영 중인 서비스의 개발은 말 그대로 달리는 자동차 위에서 바퀴를 교체하는 일과 비슷했습니다. 기존 사용자 경험을 유지하면서도 문제를 해결해야 한다는 점에서, 토이 프로젝트와는 다른 종류의 책임감과 판단이 필요하다는 것을 처음으로 체감한 경험이었습니다.
변경이 올바르게 되었는지 ‘확실하게’ 확인하기
UI 변경과 같이 눈에 보이는 변화는 비교적 확인하기 쉽습니다. 그러나 내부 유틸 함수와 같은 로직 변경은 그렇지 않습니다. 개발 중이라면 console.log 등을 활용해 동작을 확인할 수 있지만, 실제 배포 코드에 디버깅용 로그를 남기는 것은 바람직하지 않습니다.
제가 담당했던 작업 중에는 외부 의존성을 제거하고 내부 유틸로 내재화하는 작업과, 기존 유틸 코드의 구현 방식을 변경하는 작업이 포함되어 있었습니다. 이러한 변경 사항이 staging과 production 환경에 실제로 올바르게 반영되었는지를 확인할 필요가 있었습니다.
이를 위해 실제 네트워크에서 내려받은 번들링된 코드를 직접 확인했습니다. 번들 코드 안에서 특정 에러 메시지나 문자열을 단서로 검색해, 제가 변경한 로직이 실제 배포 결과물에 반영되어 있는지 확인하는 방식이었습니다.
이 경험을 통해, 변경 사항을 추적하기 위한 의도적인 시그니처나 문자열을 코드에 남겨 두는 사례가 왜 존재하는지 실제로 이해할 수 있었습니다. 단순히 구현을 완료하는 것뿐 아니라, 배포된 결과물까지 검증하는 과정 또한 개발 작업의 중요한 일부라는 것을 체감한 경험이었습니다.
큰 태스크는 나누어 접근하기 - Divide and conquer
Release Note 작성을 위한 에디터를 구현하는 비교적 큰 규모의 작업을 맡은 적이 있었습니다. 처음에는 특정 서비스의 기능을 벤치마킹하여 유사하게 구현하는 방향으로 접근했습니다. 그러다 보니 세부 동작까지 깊게 파고들게 되었고, 실제 서비스의 요구사항과 맞지 않는 부분들도 함께 분석하느라 시간이 예상보다 많이 소모되었습니다.
이 경험을 통해 큰 작업을 한 번에 해결하려 하기보다, 작은 단위로 나누어 검증하며 진행하는 방식이 더 효율적이라는 것을 체감하게 되었습니다. 이후에는 작업을 기능 단위로 나누어 진행했습니다. 예를 들어 에디터 구현 작업을 다음과 같은 단계로 나누어 접근했습니다.
- Release Note 데이터 구조 설계
- 기본 에디터 컴포넌트 구성
- Release Note 작성 기본 플로우 설계 및 구현
- 미리보기 및 렌더링 로직 구현
- 실제 서비스에서 사용하는 데이터와 연결
각 단계가 완료될 때마다 리뷰를 요청하고 방향이 맞는지 빠르게 검증했습니다. 만약 방향이 맞지 않다면 큰 구조를 다시 뒤엎기 전에 작은 단위에서 수정할 수 있었기 때문에, 결과적으로 더 빠르고 안정적으로 작업을 진행할 수 있었습니다.
이 경험을 통해 ‘큰 태스크일수록 더 작은 단위로 쪼개어 검증하면서 진행해야 한다’는 단순하지만 중요한 원칙을 체감하게 되었습니다.
문제에 대한 논의가 우선이 되어야 한다
인턴 기간 동안 저는 구조적인 코드를 잘 작성하지 못한다는 압박감 때문에, 무언가를 더 적극적으로 개선해야 한다는 생각에 스스로를 몰아붙이곤 했습니다. 그러던 중 mock 관련 코드에서 eslint warning이 발생한 일을 계기로, ‘문제를 해결한다’는 것의 의미를 다시 생각하게 되었습니다.
당시 warning의 원인은 _로 시작하는 placeholder용 변수에 대해서도 사용되지 않은 변수 경고가 발생하는 것이었습니다. 저는 이것을 팀 차원에서 해결할 문제라고 판단해 태스크를 만들고 PR을 발제했습니다. 하지만 돌아온 피드백은 예상과 달랐습니다. 팀 컨벤션에 대한 변경이라면 먼저 논의가 필요하고, 현재 방식도 정해진 규칙 안에서 충분히 관리 가능하기 때문에 이것 자체를 큰 문제로 보지 않는다는 의견이었습니다.
이후 저는 사명감에 가까운 마음으로, husky를 확장해 팀 컨벤션에 직접 영향을 주는 파일 변경이 있을 때 논의 여부를 확인하는 프롬프트를 추가하면 좋겠다고 생각했습니다. 그래서 관련 태스크를 만들고 동료와 논의를 시도했지만, 여기서도 비슷한 피드백을 받았습니다. ‘정말 해결해야 하는 문제인지’가 먼저 정의되지 않은 상태에서 구현부터 진행하는 것은, 의도와 별개로 시간 낭비가 될 수 있다는 것이었습니다.
이 경험은 꽤 충격적이었습니다. 좋은 의도로 시작한 개선이 반드시 좋은 결과로 이어지는 것은 아니라는 사실을, 직접적인 피드백으로 체감했기 때문입니다. 특히 무엇인가를 고치고 만들기 전에, 그것이 정말 문제인지, 그리고 반드시 코드로 해결해야 하는지부터 합의하는 과정이 왜 중요한지 처음으로 실감하게 되었습니다.
돌아보면 이 경험은 기술적인 문제 해결보다도, 팀에서 문제를 다루는 순서에 대한 인식을 바꾼 계기였습니다. 해결책을 빨리 제시하는 것보다 먼저 필요한 것은 문제 정의와 공감대 형성이라는 점을 배웠고, 이후에는 무언가를 개선하고 싶을 때에도 먼저 ‘이것이 정말 문제인가’를 확인하는 습관을 의식하게 되었습니다.
마무리 - 크게 배운 3개월의 기간
돌아보면 이 인턴 기간 동안 제가 가장 크게 체감한 것은 ‘서비스 코드는 돌아가기만 하면 되는 것이 아니라, 함께 유지보수할 수 있어야 한다’는 아주 기본적인 사실이었습니다. 이전에도 클린 코드나 아키텍처에 대한 이야기는 들어본 적이 있었지만, 그것이 왜 중요한지에 대해서는 실제 체감이 없었습니다.
하지만 코드 리뷰 문화, 이미 운영 중인 서비스를 수정하는 경험, 변경 사항을 검증하는 과정 등을 겪으며 그 중요성을 처음으로 현실적인 문제로 받아들이게 되었습니다.
지금 생각해 보면 꽤 당연한 이야기일지도 모릅니다. 하지만 개발자로서 그 ‘당연한 이야기’를 실제 경험으로 이해하게 된 첫 번째 순간이었다는 점에서 이 3개월은 꽤 의미 있는 시간이었다고 생각합니다.
