들어가기 앞서...
세상 모든 일이 그렇듯, 무조건 옳거나 그른 것은 없다. 굳이 꼽자면 물리 법칙 정도일까? 하지만 그마저도 언제든 새로운 발견으로 뒤집힐 수 있다.
회고를 시작하며 뜬금없이 이런 이야기를 꺼내는 이유는, 이 글이 나만의 주관적인 경험과 생각일 뿐 절대적인 진리가 아니기 때문이다. 내가 겪은 상황과 감정이 지금은 맞아 보일지 몰라도, 다른 관점에서는 틀릴 수도, 혹은 애초에 잘못된 전제일 수도 있다.
지난해 작성했던 포트폴리오 글이 감사하게도 많은 관심을 받았다. 깃허브 레퍼런스로 활용되기도 하고, 취업 준비를 하던 지인들에게 도움이 되었다는 연락도 받았다. 뿌듯함과 동시에 '혹시 내 글이 누군가에게 잘못된 가이드를 주진 않았을까?' 하는 책임감도 무겁게 느꼈다. 정보를 공유하는 사람으로서 팩트 체크와 내용의 정확성에 신중을 기해야 하지만, 나 역시 실수할 수 있는 사람이니까.
그러니 이 회고록 또한 주니어 개발자가 고민하고 성장했던 2025년의 기록 정도로 가볍게 읽어주었으면 한다. 이 글이 정답이 되기보다는, 각자만의 정답을 찾아가는 과정에 작은 참고가 되기를 바란다.
요즘 몰입하고 있는 것 : 디자인 시스템 라이브러리
최근 나의 가장 큰 화두는 디자인 시스템 개발이다. 회사와 개인 사이드 프로젝트 양쪽에서 디자인 시스템을 구축하며 UI 재사용성을 높이는 작업에 한창이다. 흥미로운 점은 두 환경에서 디자인 시스템을 도입하게 된 계기가 다르다는 것이다.
회사에서는 통합을 위해 시작했다. 다양한 스타일링 라이브러리가 뒤섞이면서 발생하는 CSS 충돌과 우선순위 문제는 심각한 골칫거리였다. 이를 해결하기 위해 라이브러리 차원에서 스타일을 격리하고, 우선순위를 강제하여 기존 프로젝트의 CSS 간섭을 막는 것이 주된 목적이었다.
반면 사이드 프로젝트에서는 확장성을 위해 시작했다. 여러 프로젝트에 걸쳐 일관된 브랜드 경험을 제공하고, 개발 생산성을 극대화하기 위함이다. 지금은 사용자 페이지만 있지만, 추후 관리자 페이지를 만들거나 모노레포로 확장할 때 디자인 시스템이 강력한 무기가 될 것이다. 컴포넌트를 조립하기만 하면 되니, 단순 반복 작업은 줄고 핵심 로직에 집중할 수 있게 되니까.
진행 상황과 난관
현재 두 프로젝트 모두 스토리북(Storybook)과 JSDoc 문서화를 마치고, 핵심 컴포넌트를 점진적으로 교체하는 단계에 와 있다. 별도의 대규모 리팩토링 일정을 잡기보다는, 새로운 기능을 개발하거나 유지보수할 때마다 자연스럽게 교체해 나가는 전략을 취하고 있다.
물론 고민도 있다. 바로 접근 권한 문제다. 디자인 시스템은 엄연한 회사의 자산이기에 비공개(Private)로 관리하는 것이 일반적이다. 하지만 이를 위해서는 별도의 패키지 저장소 비용이나 복잡한 토큰 관리 같은 오버헤드가 발생한다. 편하게 개발하자고 시작한 일이 오히려 관리 비용을 늘리는 역설적인 상황이 된 것이다.
앞으로의 방향: Public vs Private
나는 이 부분에서 조금 더 열린 접근이 필요하다고 생각한다. 최근 토스, 당근, Wix, Salesforce 등 유수의 기업들이 디자인 시스템을 외부에 공개하고 있다. 이는 단순히 기술력을 과시하는 것을 넘어, 보안 비용 절감과 개발 생산성 향상이라는 실리적인 이득을 준다. 어차피 클라이언트 코드는 리버스 엔지니어링으로 분석이 가능한데, 굳이 꽁꽁 숨겨두는 것이 능사일까?
현재 팀에 "npm에 퍼블릭으로 배포하는게 어떤가?" 하는 이야기가 나와서 적극적으로 의견에 동조하고 있다. 퍼블릭 라이브러리로 관리될 때 얻을 수 있는 이점인 자동화된 배포 프로세스 구축과 시각적 회귀 테스트 도입 등을 통해 디자인 시스템의 완성도를 한 단계 더 높이고 싶다.
SI에서 서비스 회사로: '개발자의 무덤' 탈출기
남들과는 다를 줄 알았던 착각
"SI는 개발자의 무덤이다."
취업 준비 시절 귀에 딱지가 앉도록 들었던 말이다. 하지만 당시의 나는 이 말을 애써 외면했다. SI 회사와 서비스 회사에 모두 합격했을 때, 나는 연봉과 위치, 워라밸 등 조건이 더 좋았던 SI 회사를 선택했다.
'환경이 문제라면 내가 극복하면 되지 않을까? 퇴근 후에 공부하면 되잖아.'
그때의 나는 내가 남들보다 의지가 강한 사람이라고, 환경을 이겨낼 수 있는 사람이라고 믿었다. 입사 초기에는 실제로 배울 것도 많았고, 내 선택이 틀리지 않았다고 생각했다.
현실의 벽, 그리고 불합리
하지만 그 믿음이 깨지는 데는 그리 오랜 시간이 걸리지 않았다. 잦은 야근과 주말 출근이 일상이 되면서, 퇴근 후 자기계발은 고사하고 체력을 회복하는 것조차 버거운 나날이 이어졌다. 하루 8시간 넘게 앉아서 고도화된 정신 노동을 하는 것은 생각보다 엄청난 체력을 요하는 일이었다. 여기에 '빨리 만들어내라'는 압박감과 끊임없이 터지는 버그들은 여유를 빼앗기에 충분했다.
SI가 무덤이라 불리는 이유는 단순히 일이 힘들어서가 아니었다. 성장할 수 있는 물리적인 시간과 여유를 박탈당하기 때문이었다.
그럼에도 불구하고, 해냈다
하지만 나는 무덤 속에 눕는 대신, 삽을 들고 파헤쳐 나오기를 택했다. 지친 몸을 이끌고 집에 돌아와 매일 3시간씩 사이드 프로젝트와 공부를 병행했다. 프로젝트 마감 후 주어진 소중한 연차도 휴식이 아닌 이직 준비에 쏟아부었다.
그 결과, 2025년 4월부터 11월까지 7개월간 사이드 프로젝트 3개를 완성하고, 주력 기술 스택을 Flutter에서 Web(React)으로 전환하는 데 성공했다. 그리고 마침내, SI가 아닌 자체 서비스를 운영하는 회사로 이직하게 되었다.
새로운 시작: 서비스 회사에서의 2개월
배움의 깊이가 다르다
서비스 회사로 이직한 지 이제 고작 2개월이 지났지만, 느끼는 바가 크다. 가장 큰 변화는 피드백의 밀도다. 코드 리뷰를 통해 동료 개발자분들의 노하우를 흡수하고 있고, 실제 사용자들과 QA 팀으로부터 들어오는 디테일한 피드백은 개발자로서 시야를 넓혀주고 있다. 단순히 기능 구현을 넘어 사용자 경험과 코드 품질을 고민하게 된 것이다.
명확해진 목적
SI 시절의 개발 목적은 단 하나, "클라이언트가 원하는 것을, 최대한 빨리"였다. 속도가 최우선 가치였기에 코드의 품질이나 유지보수성은 뒷전이 될 수밖에 없었다.
하지만 지금은 다르다. 모든 업무에는 명확한 목적이 선행된다. 최근 겪은 일화가 있다. 기록하는 것을 좋아하는 나는 습관처럼 업무 내용을 문서화하여 공유했다. 그런데 CTO님으로부터 "이 문서의 목적이 무엇인가?"라는 피드백을 받았다.
"의도가 좋다고 해서 무조건 해야 하는 것은 아닙니다.
이 문서가 팀원들에게 실질적인 도움이 되나요?
AI보다 더 나은 가치를 제공하나요?"
내가 작성한 문서들은 플랫폼(Confluence)의 접근성 문제로 인해 잘 읽히지도 않았고, 내용 또한 핵심적인 인사이트보다는 단순 나열에 가까웠다. 목적 없는 열심은 때로는 시간 낭비가 될 수 있다는 것을 뼈저리게 느꼈다.
이처럼 상황에 맞게 목적을 재정의하고, 그 목적을 달성하기 위해 가장 효율적인 방법을 찾아가는 과정. 이것이 바로 내가 서비스 회사에서 배우고 있는 가장 값진 경험이다.
마치며
글의 서두에서 "옳고 그름은 없다"고 했다. 내 경험상 SI는 분명 힘든 환경이었지만, 그곳을 진짜 무덤으로 만들지, 아니면 더 높이 뛰어오를 도약대로 만들지는 결국 '나 자신'에게 달려 있었다. 나는 그 안에서 한계를 느꼈기에 이직이라는 변화를 택했고, 그 선택 덕분에 지금은 속도 대신 '깊이'와 '목적'을 배우고 있다.
물론 서비스 회사라고 해서 모든 것이 정답은 아닐 것이다. 이곳에서도 나는 문서화의 목적을 지적받았듯, 또 다른 시행착오를 겪으며 깨지고 부딪히고 있다. 하지만 분명한 건, 이러한 고민과 시도 속에서 어제보다 조금 더 나은 개발자가 되어가고 있다는 사실이다.
이 글을 읽는 여러분이 지금 어디에 있든, 그곳이 SI든 서비스 회사든, 혹은 취업을 준비하는 책상이든 중요하지 않다. 중요한 건 현재의 환경에서 무엇을 목적으로, 어떻게 움직이고 있느냐인 것 같다.
나의 투박한 2025년 회고가, 각자의 자리에서 치열하게 고민하는 분들에게 작은 위로와 도움이 되었으면 좋겠다.
'회고' 카테고리의 다른 글
| 2025년 상반기 개발회고 (2) | 2025.07.21 |
|---|---|
| 하지톤 회고 (0) | 2024.08.02 |
| 1D1S 시즌2 한 달 회고 (0) | 2024.02.02 |
| 1D1S 시즌2 2주차 회고 (0) | 2024.02.01 |
| 1D1S 시즌1 회고와 피드백 (0) | 2024.02.01 |