토스 연말 별자리 기부 길드 회고

연말 별자리 기부란?

토스는 보통 연말에 기부 이벤트를 합니다. 2023년도에는 산타 기부 이벤트를 했고, 2024년에는 별자리 기부 이벤트를 했습니다. 별자리 기부 제품에서는 여러 별자리를 보여 주며 장애인 분들이 쓰는 접근성 기능을 소개합니다. 그리고 기부를 받는 제품입니다.

토스, 세계 장애인의 날 맞아 ‘나만의 별자리 찾기’ 이벤트 실시 - 금융이 알고 싶을 때, 토

---

길드란?

길드 (Guild)는 토스에 있는 조직 구조 중 1개입니다. 토스의 조직 구조는 에자일 구조에서 유래된 거 하지만 애자일 조직 구조와 100% 일치하지는 않습니다. 길드도 애자일 조직 구조의 원래 뜻과는 상당히 달라진 듯합니다. 제가 느끼기에 길드는 다른 회사에서 말하는 TF와 비슷한 느낌입니다.

특정 문제를 빨리 해결하기 위해서나 반복되지 않는 특정 이벤트를 하기 위해서는 팀을 꾸리기에는 상당히 부담스럽습니다. 이럴 때 토스에서는 다른 팀에 속해서 일을 하고 있는 사람들이 모여서 임시로 길드를 만듭니다. 보통은 일을 마치면 길드는 해산되지만 팀으로 승격되기도 합니다. 

별자리 기부 제품도 연말에만 하는 기부 이벤트이기 때문에 길드를 만들었습니다. 길드는 자유롭게 참여하기 때문에 사람을 구하기가 힘들기도 합니다. 저는 이런 토스의 길드 구조에 대해 들었을 때 부터 꼭 참여해 보고 싶었기 때문에 기회가 왔을 때 바로 참여했습니다.

---

느낀 점

🐜 1 - 나는 역시 대고객 제품이 좋아!

저는 본업을 정산 관련 어드민을 만드는 일을 하고 있는데요. 어드민 특성상 장애 민감도가 낮고 마감일이 느슨한 편입니다. 이런 환경에 있다가 오랜만에 정신없이 대고객 제품을 출시하고 혼자서 고민해서 서버 개발을 다 하니 굉장히 재밌었습니다.

뿐만 아니라 운영성 업무도 굉장히 많았는데 이런 업무도 재밌게 하는 제 자신의 모습을 관찰하면서 "아, 나는 역시 대고객 제품을 해야 하는 개발자구나!"라고 깨달았습니다. 

 

🐜 2 - 내가 1인분을 할 수 있는 개발자가 됐구나

사실 제가 맡은 역할과 개발해야 하는 스펙이 결코 크지 않고 처음부터 만드는 거기 때문에 굉장히 쉬운 편이였습니다. 하지만 그럼에도 여러 기능들을 이곳저곳 찾고 질문해 가면서 별 탈 없이 완성했을 때 굉장히 뿌듯했습니다. 

개발자가 되고 굉장히 당황했던 것 중에 하나가 개발만 잘 하면 되는 게 아니라 문제를 해결해야 한다는 거였습니다. 모든 환경이 잘 갖춰진 상태에서 개발을 하는 건 쉬운 편입니다. 하지만 환경을 갖춰 나가고 스펙을 조율해서 실질적인 문제를 해결하는 건 굉장히 어려웠습니다. 그래서 그런지 첫 팀에서는 굉장히 헤맸고 어려웠습니다.

토스에서의 첫 팀 회고 (🏠 주담대팀)

하지만 길드에서 잘 해내면서 1인분을 할 수 있는 개발자가 됐다는 것에 뿌듯했습니다. 여기서 만족하지 말고 2~3인분의 생산성을 낼 수 있는 개발자가 되기 위해 노력을 아끼지 않을 생각입니다!

---

배운 점: 데이터는 보수적으로 생각해 최대한 많이 저장하자

자세히 말씀 드릴 수는 없지만 처음 받은 스펙에서는 기부처가 랜덤으로 배정되는데 어떤 기부처가 배정되는지 따로 저장할 필요가 없었습니다. 그래서 굳이 저장할 필요가 있을까 싶어 DB에 저장하지 않았습니다.

하지만 스펙이 바뀌면서... 정말 카오스가 벌어졌습니다. 우선 저장하지 않은 기부처를 얻기 위해서는 다른 곳의 API를 호출해야 하는데 그 방식이 각 기부처에 해당하는 API Key로 찔러보고 오류가 나지 않으면 그 기부처라고 판명하는 일시적인 해결책이었습니다. 게다가 이렇게 기부처를 받아오면 기부처를 저장하고 있는 내역과 아닌 내역이 혼재돼 있어 이거에 대한 예외 처리도 해야 했습니다. 뿐만 아니라 이 Entity를 사용하는 모든 곳에 이런 처리를 해야 해서 굉장히 코드가 지저분했습니다.

이런 비슷한 경우가 1번 더 있었습니다. 이 모든 건 보수적으로 생각해 데이터를 다 저장했으면 일어나지 않았을 일 입니다. 처음에는 데이터를 다 저장하는 게 DB 공간의 낭비라 생각했지만 생각이 바꿔었습니다.

• 스펙이 계속 바뀌는 상황에서는 어떤 데이터가 필요한지 모르기 때문에 일단 다 저장하고 나중에 변화가 적어지면 그때 지우면 됩니다. 없는 데이터를 얻는 건 굉장히 힘들지만 있는 데이터를 지우는 건 쉽습니다.
• DB 공간의 비용보다 개발자 리소스가 훨씬 비쌉니다.

---

배운 점: 프론트는 항상 잘못될 수 있다

기본적으로 웹 개발자는 프론트에서 보낸 값을 믿을 수 없다는 생각을 가지고 있습니다. 프론트는 유저가 JS만 조금 조작하면 필수 값을 비워서 보낼 수도 있고, 여러 값들을 조작할 수도 있습니다. 그래서 프론트에서 하는 유효성 검사는 UI/UX를 위해서 하는 거고, 서버에서도 프론트에서 했더라도 유효성 검사를 다시 합니다.

저도 기능들을 구현하면서 이런 점들을 항상 생각하고 구현을 했지만 그럼에도 놓친 부분이 있었습니다. 프론트에서 API를 호출해서 값을 보고 막는가 하셔서 당연히 중복으로 요청이 오지 않을거라고 가정했고, 설령 오더라도 따닥 문제일거라 생각해 API 단위에서의 Lock만 걸어 뒀습니다.

그런데 나중에 DB에 쌓인 데이터를 보니 간헐적으로 중복된 데이터들이 많았습니다. 결국 모든 요구사항을 서버에서 막도록 하지 않고 프론트에서 막을 거라 가정하면 어떻게든 잘못될 수 있다고 다시 한번 느꼈습니다.

---

결론

실제 취직해서 일을 하면서 가장 좋은 건 여러 가지 업무를 하면서 나 자신에 대해 알아가고 업무적으로 뿐만 아니라 사람으로서도 성장한다는 겁니다. 저만 해도...

• 나는 기술을 좋아하는 개발자라기보다는 제품을 좋아하는 개발자구나 깨달았습니다.
• 내 흥미가 업무 성산성에도 영향을 미치는 걸 보면서 내가 좋아하는 일을 해야 하는구나 깨달았습니다.
• 내 업무에 대한 가시성을 높이기 위해 공유를 하면서 여러 장점이 있는 걸 보면서 일상생활에서도 문제가 생기면 회피하고 숨기기보다는 적극적으로 공유하고 해결하는 태도를 가지게 됐습니다.

그래서 이런 기회가 오면 기간이 너무 빠듯해서 힘들긴 했지만 당연히 또 할 생각입니다. 

---