이번에 Toss에서 Frontend Assistant로 일할 수 있는 기회를 얻었습니다.
3개월 동안 DEUS 팀에 소속되어 일하며 정말 많은 것을 보고 배우는 소중한 시간을 보냈습니다.
이 경험을 통해 느끼고 배운 것들을 정리해두고자 이렇게 기록을 남기려 합니다.

🚀 빠르게 성장하는 팀 속에서

제가 DEUS 팀에 합류했을 때는 약 8명 정도의 팀원이 있었습니다.
그중 두 분은 곧 휴직을 하시면서 실제로 함께 일하는 인원은 더 줄어든 상태였죠.

하지만 시간이 지나 퇴사할 즈음엔 팀원이 15명으로 늘어나면서,
불과 3개월 사이에 팀 규모가 거의 두 배로 성장했습니다.
그 과정에서 조직이 커질 때 자연스럽게 생기는 여러 문제들을 가까이서 볼 수 있었습니다.

---

🧭 온보딩 체계의 부재와 공통 언어의 필요성

가장 먼저 느꼈던 문제는 온보딩 체계의 부재였습니다.
당시 팀은 빠르게 인원이 늘어나고 있었지만, 새로 합류한 구성원이 팀의 서비스나 코드 구조를 이해할 수 있는 명확한 가이드가 없었습니다.

문서를 찾으려 해도 최신화되지 않았거나, 사람마다 다른 설명을 들을 때도 있었죠.
결국 같은 개념을 두고도 팀원마다 다르게 표현하거나, 용어 해석이 달라 의사소통에 혼선이 생기곤 했습니다.

이 문제를 해결하기 위해 팀에서는 자연스럽게 논의가 시작되었습니다.
“우리가 쓰는 용어를 한 번 정리해보자”, “처음 들어오는 사람도 빠르게 이해할 수 있는 온보딩 문서를 만들자” 같은 의견들이 오갔고,
이를 바탕으로 실제로 온보딩 문서와 도메인 언어 정리 문서가 만들어졌습니다.

문서를 단순히 작성하는 데서 끝나지 않고,
팀 내에서 “이 용어는 이렇게 쓰자”, “이 프로세스는 이렇게 이해하면 된다”는 식으로 피드백을 주고받으며
점차 팀의 공통 언어와 기준이 자리 잡기 시작했습니다.

이 과정을 지켜보면서, 빠르게 성장하는 조직일수록
‘문서를 만드는 것’보다 ‘팀이 같은 언어로 말할 수 있게 만드는 것’이 더 중요하다는 걸 배웠습니다.
온보딩 문서는 단순한 정보의 나열이 아니라,
새로운 구성원이 “이 팀의 사고방식과 맥락”을 이해할 수 있게 해주는 첫 접점이라는 점도 느꼈습니다.

---

🧩 작업의 맥락을 잃지 않기 위한 노력

또 하나 기억에 남는 부분은 개발 프로세스를 정립해 나가는 과정이었습니다.
팀 규모가 빠르게 커지면서 작업량이 늘어나자,
품질과 일관성도 중요했지만 무엇보다 “작업의 맥락을 잃지 않는 것”이 큰 과제가 되었습니다.

시간이 지나면 “이 작업은 왜 시작된 거지?”, “누가 어떤 논의 끝에 이렇게 결정한 거였지?” 같은 질문이
쉽게 생기곤 했거든요.

우리는 이런 문제를 해결하기 위해 Linear을 적극적으로 활용했습니다.
단순히 할 일을 나열하기보다 ‘왜 이 일을 하게 되었는지’,
그리고 ‘어떤 대화 속에서 결정되었는지’를 남기려는 시도를 했습니다.

모든 이슈를 기록할 때 배경과 목적, 완료 조건을 함께 적고,
논의가 오갔던 맥락을 코멘트로 남기며
나중에 돌아보더라도 팀의 사고 흐름을 따라갈 수 있도록 정리했습니다.

이런 방식이 자리 잡으면서 팀 내 소통도 훨씬 투명해졌습니다.
서로가 어떤 생각으로 일하고 있는지 이해하기 쉬워졌고,
새로 합류한 사람도 과거의 의사결정 과정을 자연스럽게 학습할 수 있었습니다.

결국 우리는 단순히 일을 관리하는 체계를 만든 것이 아니라,
“생각의 흐름까지 공유되는 개발 문화”를 만들어가고 있었다고 느꼈습니다.

---

🛠 함께 성장하는 개발 문화, 함께하는 DEUS Engineering

또 한 가지 인상 깊었던 점은 팀이 스스로 문제를 발견하고 개선해나가는 문화였습니다.
개발자들 사이에서 공유할 내용이나 맞춰봐야 할 부분이 생기면,
그때그때 채팅으로 이야기하고 끝내는 대신,
매주 월요일마다 한 시간씩 ‘함께하는 DEUS Engineering’라는 시간을 따로 마련했습니다.

이 시간에는 기능 개발을 잠시 멈추고,
개발자들이 한자리에 모여 최근 겪은 불편함이나 개선 아이디어를 자유롭게 이야기했습니다.
예를 들어, 코드 리뷰 방식이나 코드 컨벤션, 배포 프로세스 같은
팀 전체에 영향을 주는 주제들을 다루었고, 논의가 끝나면 바로 실험적으로 적용해보기도 했습니다.

흥미로웠던 점은 이 시간이 ‘회의’라기보다는 함께 일하는 방식을 만들어가는 워크숍에 가까웠다는 것입니다.
누군가의 지시로 정해지는 게 아니라,
모두가 동등하게 의견을 내고 결정하는 과정을 통해
팀이 점점 하나의 방향성을 공유하게 되었죠.

---

🎯 Deus에서 프론트엔드로 뛰어든 나의 여정

토스 전사 디자이너가 사용하는 사내 디자인 툴 DEUS의 프론트엔드 개발과 사용자 경험 개선을 담당하며,
프로덕트의 안정성, 사용성, 일관성을 높이는 다양한 기능 개선, 버그 해결, 디자인 시스템 리팩토링을 진행했습니다.

🧩 DDS(Deus Design System)작업 경험과 배움

Deus 플랫폼의 디자인 시스템은 DDS 1.0 버전을 기반으로 운영되고 있었지만,
커스터마이징 요구 증가와 하드코딩된 스타일 덮어쓰기로 인해
컴포넌트 구조가 파편화되고 유지보수가 어려운 상태였습니다.

또한 명확한 관리 주체와 체계적인 유지 프로세스가 부재하여,
디자인 변경 시 각 팀이 개별적으로 수정하는 비효율이 발생하기도 했습니다.

이 문제를 해결하기 위해, 저는 다음과 같은 작업을 수행했습니다.
• 기존 UI 구조를 전면 분석하고 14개 주요 DDS 컴포넌트를 개선 및 신규 설계
• DDS 2.0 버전과 커스텀 디자인 요소 통합을 통해 중복 스타일과 하드코딩 요소 제거
• Storybook 기반 미리보기 환경 구축으로 UI를 시각적으로 확인·테스트 가능하게 함
• 각 컴포넌트별 Props, 예제 코드, 가이드라인 문서화로 누구나 쉽게 재사용할 수 있는 환경 조성

이 과정을 통해 디자인 자산의 파편화를 해소하고, 디자인 시스템 유지·관리 프로세스를 체계화하여 일관된 UI 개발 환경을 마련할 수 있었습니다.

그러나 되돌아보면, DDS 작업이 너무 어려웠고 다른 개발자들과 충분히 합의하지 않고 혼자 진행한 부분이 아쉬움으로 남았습니다. 이에 대해 커피챗에서 조언을 받았는데,

DDS 작업은 단순히 컴포넌트를 만드는 게 아니라 팀 전체의 ‘언어’와 ‘약속’을 만드는 일이므로 원래 어려운 작업입니다.
합의가 부족해 문제가 생긴다는 점을 스스로 포착했다는 것 자체가 긍정적인 신호라고 볼 수 있습니다.

하지만 이 경험 덕분에 팀과 협업하는 방식과 개선 포인트를 직접 체감하며 배울 수 있는 소중한 기회가 되었고,
작업의 난이도와 어려움은 자연스러운 것이며, 혼자 시도해보는 과정조차 성장의 중요한 발판이 될 수 있음을 깨달았습니다.

---

🐛 수많은 버그를 해결하면서 얻은 배움

Deus 플랫폼에서 프론트엔드 개발을 하면서, 도메인과 코드 구조가 낯설어 작은 UI 버그부터 구조적인 상태 관리 문제까지 다양한 버그를 겪었습니다.

처음에는 단순히 화면이 깨지거나 기능이 동작하지 않는 문제를 빠르게 해결하는 데만 집중했습니다.
예를 들어, 로딩 화면에서 다크모드가 제대로 적용되지 않는 문제를 처리할 때, 처음엔 “화면 색만 바꿔주면 되겠지”라고 생각하며 단기적으로 패치했습니다.
하지만 곧 다른 화면이나 상태 관리 로직에서 문제가 재발하면서, 근본적인 구조와 상호작용을 이해하지 못하면 비슷한 버그가 반복될 수밖에 없다는 것을 깨달았습니다.

또한, 상태 관리 구조나 컴포넌트 간 의존 관계를 제대로 파악하지 못한 채 고치다 보니,
한 버그를 고치는 과정에서 다른 화면에서 새로운 버그가 발생하기도 했습니다.
이런 경험은 “단기적으로 고치고 끝내는 방식”이 장기적으로는 문제를 키울 수 있다는 사실을 직접 체감하게 만들었습니다.

커피챗을 통해 조언을 받으면서, 문제를 바라보는 깊이를 세 단계로 나누어 생각하는 방법을 배우게 되었습니다.
• 레벨 1️⃣: 결과 중심 – 눈에 보이는 변화만 확인하며 문제를 빠르게 처리하는 단계
• 레벨 2️⃣: 구조 이해 – 코드의 역할과 상호작용을 이해하며 근본 원인을 찾는 단계
• 레벨 3️⃣: 근본 원인 고민 – 코드 구조 자체가 최선인지, 아키텍처 개선 가능성을 검토하는 단계

실제로 ‘다크모드 분리 작업’이 좋은 예시였습니다. 처음에는 단순히 로딩 화면 색상을 바꾸는 요구였지만,
상태 관리 구조 자체의 문제를 발견하고 근본적으로 개선함으로써, 같은 버그가 반복되지 않도록 조치할 수 있었습니다.

이 경험을 통해, 버그를 단순히 고치는 데 그치지 않고 근본 원인을 이해하고 구조를 점검하는 사고가 얼마나 중요한지 배우게 되었고,
커피챗을 통해 얻은 조언 덕분에 앞으로는 문제를 좀 더 깊이 있게 분석하고 구조적으로 해결할 수 있는 시야를 갖추게 되었습니다.

---

💬 팀 내 협업과 소통에서 배운 것

Deus 팀에서 일하면서 가장 많이 부딪힌 과제 중 하나는 디자이너 등 비개발자와의 소통이었습니다.
초반에는 기술적 용어와 개발자 중심의 사고 방식 때문에, 상대방이 이해하기 어렵다는 피드백을 종종 받았습니다.
“너무 개발자 중심으로만 얘기해서 이해하기 어렵고, 어떻게 해야 할지 모르겠다”는 말이 기억에 남습니다.

커피챗을 통해 조언을 받으면서 깨달은 중요한 포인트는, 좋은 개발자란 기술만 잘하는 사람이 아니라, 상대가 이해할 수 있게 전달하는 사람이라는 것입니다.

1️⃣ 맥락 중심으로 쉽게 설명하기

상대방을 무시하는 게 아니라, 상대가 지금 어떤 상황인지 ‘맥락’만 이해하면 된다는 생각으로 설명하는 방법입니다.
예를 들어, “DB가 꼬여서 API가 어쩌고…“라고 말하는 대신,
“지금 약간 교통사고가 난 상황이에요”처럼 쉽고 극단적인 비유를 사용하면 핵심 상황을 바로 전달할 수 있습니다.

2️⃣ 선택지를 제공하기

문제를 길게 설명하기보다, 상대방이 결정할 수 있는 선택지를 제시하는 것이 대화를 훨씬 생산적으로 만듭니다.
• 나쁜 예: “지금 의존성 문제가 있고 리팩토링 범위가 어쩌고…” (그래서 어떻게 하길 원하는 건가?)
• 좋은 예: “대략 이런 상황입니다. A 방법은 3일, B 방법은 하루지만 일부 기능을 포기해야 합니다. 어떻게 할까요?”

이처럼 선택지를 주면 상대방은 판단만 하면 되므로, 이야기가 빠르게 다음 단계로 진행됩니다.

추가로, 커피챗에서 배운 중요한 교훈 중 하나는 ‘상황에 맞는 소통 방식’을 구분하는 것입니다.
• 개발자끼리 모여 일할 때는 전문 용어를 써도 소통이 가능하지만,
• 디자이너, PO 등과 협업할 때는 누구나 이해할 수 있는 언어로 설명하는 능력이 훨씬 중요합니다.

결국, 현업에서 잘하는 개발자를 가르는 기준은 기술이 아니라 커뮤니케이션 능력이라는 사실을 몸소 느낄 수 있었습니다.
이 경험 덕분에, 기술적 지식과 더불어 누구에게나 명확하게 의사 전달하는 습관을 갖추는 것이 얼마나 중요한지 배웠습니다.

---

✨ 돌아보며, 앞으로의 다짐

커리어를 본격적으로 시작하기에 앞서, Deus 팀에서의 3개월은 제게 큰 충격과 배움을 준 시간이었습니다.
단순히 개발 실력뿐만 아니라, 팀이 성장하는 과정에서 무엇이 중요한지, 효과적인 소통 방식이 무엇인지 직접 경험하며 배울 수 있었습니다.

특히 커피챗에서 동료분께 “앞으로 어떤 개발자가 되고 싶냐”는 질문을 받았을 때, 선뜻 답하지 못했던 순간이 기억납니다.
그때 비로소, 제가 앞으로 어떤 방향으로 성장해야 할지, 어떤 개발자가 되고 싶은지 진지하게 고민해봐야겠다는 생각이 들었습니다.
앞으로 다시 취업 준비를 하면서는, 다른 분들의 이야기와 조언도 들어보고, 다양한 경험을 쌓아보면서 조금씩 저만의 방향을 구체화해가고 싶습니다.

마지막으로, 처음부터 끝까지 함께 해주신 Deus 팀원 분들께 깊은 감사의 마음을 전하고 싶습니다.
덕분에 많은 것을 보고 배우며 성장할 수 있었고, 이 경험은 앞으로 제 커리어에 큰 밑거름이 될 것입니다.