토스 Front-End Diving Club 후기

정(JJeong)·2025년 3월 5일

Conference 행사후기

toss company

약 한 달전 지인분의 초대로 toss에서 진행하는 FE diving club에 참여할 수 있었다.
역삼역에 내려 당시 거센 바람을 뚫고 총총 걷다보면 마주하는 toss 배너,,

지인분의 레퍼 체크를 했었던 만큼 여기에 다니시는 걸 보니 감회가 새롭고 부럽고 다양한 감정이었다.

행사 입장

복잡한 UI, 우아하게 풀어내기

"네? 이 디자인을 구현하라고요?"

위 내용이 이번 다이빙 클럽의 주제이다. 프론트라면 모두가 맞닥드리는 어려움. 이걸 내가 어떻게 구현하지?에 대한 주제. 흥미롭지 않을 수가 없다. 부푼 마음으로 입장..!

직장인 분들이 참여하는 행사이기 때문에 퇴근 시간 이후 운영되었고, 장소는 토스의 사무실에 위치한 컨퍼런스 섹션(?) 같은 곳에서 진행되었다.

남의 회사인 만큼 사진은 못찍었지만 입장하고 나서 신원확인 후 이름표를 받은 뒤 들어가면 내부 2층 계단을 통해 올라갈 수 있었다.

아마 전체 미팅 or 휴게 공간인 듯 싶은 넓은 공간이었다. 아니면 이번 행사를 위해 따로 공간 배치를 했을 수도 있고.

지인분께 여쭤봤지만 지인 분은 다른 건물을 쓰셔서 여기는 잘 모르신다고ㅎㅎ

여담으로 당시 바로 저녁시간이어서 행사에서 저녁이 제공 됐는데, 스폰서로 Crying Cheese Burger가 후원을 했다고 한다.

식어서 아쉬웠지만 맛있었고, 버거집 직원분들이 탈까지 쓰고 나눠주셔서 참 노고가 많으시단 생각이 들었다..!

그리고 그 밖의 스티커와 레고 피규어 굿즈들ㅎㅎ

Ice Breaking

조선정이 따로 있진 않았고 그냥 랜덤하게 테이블에 앉으면 됐다. 각 테이블엔 토스 직원 분들이 한 분씩 자리해 계셨고 리드를 해주시는 것 같았다.

우리 쪽 분은 토스 증권쪽 분이었다. 가볍게 식사를 하면서 앉은 분들과 통성명과 대화를 나눴다.
다양한 도메인의 분들이 계셨는데 특히 기억에 남는건 두 분이었다.

한 분은 바이오산업 쪽에 계신 분인데 아무래도 내 전공이 생명과학 쪽이라 관심이 갔다. 취업 방향을 바이오기업의 IT도 고려하지 않은게 아니니까.

그리고 한 분은 내 바로 옆에 계신 분이었는데 제일 놀랐던 분,, 왜냐하면 인프런에서 강의를 운영 중이신 정재남님이었다.
네이버에 계신 분이시면서 강의를 진행하고 계신데, 난 사실 처음에 알아보지 못했다.
근데 위에 언급한 분이 먼저 알아보시고 이름을 언급하시길래, '어? 익숙한 이름인데 혹시 나도?'하고 인프런에 들어가보니 나도 강의를 들었던 적이 있다.

뭔가 유명인을 만난듯한 신기한 느낌, 예전 테오님 만났을 때 같은 느낌이었다.
혹시나 프론트엔드 쪽이고 위 강의가 관심있다면 들어보길 추천한다. (하는김에 홍보)

먹는 도중 차차 사람들이 더 오셨고, 다들 I인 모임이었지만 가볍게 나마 인사를 나눴다.

그리고 본격 발표 시작.

FE diving club 발표 세션

발표 섹션은 두 개로 진행되었고, 사이에 QnA와 기타 토의 시간이 있었다.
첫번째 발표 시작.

1) Multi Step Form - 중앙 집권에서 자율 조직으로

발표 메모

UI 구성

이전 단계 버튼: 유효성 검사 x

다음 단계 버튼: 현 단계 유효성 검사

제출 버튼: 전 단계 검사
Payload 구성 -> step에 맞는 payload 업데이트 -> 버튼 관련 유효성 검사

문제점

payload와 step의 구성이 다르다면 변환이 필요

해결 제시

모든 step의 구성 = Payload Form

각 step은 자신 값만 변경 -> payload는 변경 x

첫 발표는 토스 코어팀의 박종호님이 진행해주셨다.

주제는 Multi Step Form을 어떻게 구성할 것인가. 과연 프론트엔드라면 제법 스트레스 받는 부분이 Form 만들기이다.

이 부분에 대해서 기존 방식의 불편함을 먼저 제시한다.
Payload를 구성 후 각 스텝을 따로 꾸린다면 각 스텝에서 경우에 따라, 아니 거의 모든 경우 payload에 맞춰 가공이 필요하다.
또한 이에 따라 payload의 새로운 업데이트가 진행되고, 이는 리렌더링을 초래할 수 있다.

이러한 변환 요구가 필요해지는 문제를 해결하려면 어떻게 할까?
bottom-up방식 도입을 적용한 것이다. payload는 각 step의 합이라고 산정을 한 뒤 각 step은 독립적으로 존재하며 payload는 제출 전 구성된다.
이러면 각 step의 변화는 각 state의 변화에만 반영되고 payload는 스텝을 넘어갈 때마다 업데이트 될 필요가 없다.

듣고 나니 호오.. 나도 항상 전체 form type에 대한 생각을 먼저 꾸리고 분할할 step을 구성한 뒤 step을 넘어갈 때마다 유효성체크 후 전체에 대한 업데이트를 고려했던 것 같다.
들고 가는 건 전체 form양식이지만 각 step에선 따로 체크 후 양식값에 업데이트 하는 느낌? 뭔가 이걸 당연하게 생각했던 것.

근데 각 부분의 합은 전체라는 식으로 명제를 뒤집어 생각하니 확실히 업데이트가 줄긴 하겠다고 생각이 든다.
과연 다른 분들은 이번 섹션을 어떻게 들었을까?

섬미팅 토론

처음엔 다들 발표를 들은 소감과 함께 개인 경험을 나눴다. 다른 분들도 form을 다루는 경우가 많지는 않았지만 사용한 라이브러리나 어려움 등을 나눴다.

그런데 그때 대지를 가르는 듯한 의견.

왜 자체 HTML form을 활용하지 않을까?
form 구현의 비용을 줄이기 위한 접근이 아닐까
- 생각보다 자체 커스텀 폼을 짜는게 어렵지 않다.

정재남님의 의견이었다. 개인적으로 라이브러리 사용을 지양하고 자체 form 태그와 api를 활용해서 작성하신다고 한다.
라이브러리 사용에 대해 꽤나 강력히 반대 의견을 어필하셔서 나 포함 다른 분들은 항상 사용해온 입장이다 보니(ㅎㅎ) 라이브러리 사용시 설계 및 적용 비용의 감소에 대해 반대로 어필드려 봤는데,
위에 적어둔 대로 생각보다 첫 form API 자체 적용이 어렵지 않다는 것. 오히려 한 번 짜두면 더 고효율을 보여준다는 것이었다.

그래서 다들 처음엔 라이브러리를 쓰면 빠르고 좋지 않나?하는 갸우뚱한 입장에서 어느 정도 설득이 되었다.
예전엔 크로스브라우징 문제, 지원 API의 부족 문제 등이 있었지만 지금은 HTML5에서 충분히 커버를 해냈다는 것.

생각해보면 "나도 비용 투자를 하고싶지 않단 핑계로 자체적인 기능을 파보는 것에서 회피하고 있던게 아닌가?"하는 생각이 들었다.

뭔가 뒤통수를 한 대 맞은 느낌이랄까?

깊게 자체 기능을 파봐야겠다.

기타) 내 호기심 질문

FSD의 도입을 최근에 해보려 했는데 실패했다, FSD 도입은 어떻게 하는 게 좋은가?
- OOO는 무엇이다 보다는 OOO는 무엇을 위한 것이다로 접근하며 layer를 나눈다.

2) 토스 증권 PC 그리드 레이아웃 제작기

토스 증권 PC화면을 보면 각 패널을 끄거나 커스텀 할 수 있음, 이에 대한 얘기

발표 섹션2

발표 메모

직접 구현 vs 라이브러리 커스텀

레이아웃 라이브러리를 사용하지 않음
why? 요구사항을 모두 만족하는 라이브러리가 없었기 때문
=> 요구 사항이 높아질수록 직접 구현의 리소스가 더 적게 든다.

설계 고민

이동과 크기 조절을 어떻게 할 것인가?

이진 트리 방식의 구조 설계 도입 !

Node의 구성

축과 비율을 전달하면 된다.

panel node / split node

파이프 라인 구성

트리 구성 -> 좌표 구성 -> css적용

두번째 발표는 토스 증권팀의 방건영님이 진행해주셨다.

첫번째 발표는 경험적으로 맞닿은 적이 있어서 좋았다면, 두번째 발표는 꽤 신선하고 충격적이어서 좋았다. '와,, 저렇게 생각할 수 있구나' 하는 느낌.

일단 주제는 이름 그대로 레이아웃 제작기인데 요구사항을 모두 말씀해주실 순 없었지만 대략적으로만 들어도 꽤나 많았다.

레이아웃에 위젯 추가 삭제가 가능할 것
드래그 이동이 가능할 것
자동으로 비율이 맞춰 질 것

즉, 이런 요구사항을 다 만족하는 레이아웃을 만들어야 하는 것.
그래서 처음 위 태스크를 받고서 라이브러리를 써서 커스텀을 할 지, 직접 구현을 할 지 고민을 하셨다고 한다.

그러다 택한 방향은, 직접 구현하기..! 개발자라면 다들 마음으론 직접 구현하고 싶어도 여러 여건 때문에 쉽사리 도전하지 못하는 부분이기도 한데 이런 결정을 내린 이유가 무엇이냐?

러닝 그래프

당장 라이브러리를 쓰면 초기 도입엔 리소스가 적게 들지 모르지만 요구사항이 크면 클수록 결국 라이브러리 이해도 필요성 등으로 인해 리소스를 많이 잡아먹게 될 것이란 것.
그치.. 결국 커스텀을 하려면 해당 라이브러리 이해도가 있어야 하는데 남의 코드를 보고 이해한다는 것이 여간 시간을 많이 잡아먹는게 아니다. 게다가 시간을 붓는다고 무조건적으로 이해가 가능하다는 것도 아니고.

그리고 결국 다른 라이브러리의 의존하는 것이니 기술 부채로 인한 이후 리팩토링 시 추가 리소스가 소모될 가능성도 있다.

이러한 이유로 직접 구현을 택하셨던 것. 그래 그건 좋다. 근데 어떻게?
이게 신박하다. 이진 트리의 적용이 해답이었다는 것.

노드를 먼저 panel과 split으로 나눈다.
panel에서는 비율을, split에서는 축을 전달한다.
그러면 첫 시작 root노드에서 해당 값으로 점차 나누게 되면 레이아웃 비율 구성이 완성된다.

말은 간단하지만 이런 아이디어를 도출해냈다는게 참 대단했다. 어찌보면 솔직히 약간 벽을 느끼기도 했다.

하지만 이런 아이디어를 잘 흡수해 나도 배워나가야지..!!

여하튼 그렇게 아이디어 구상 후에는 구현까지 오래 걸리지 않으셨고, 현재는 완성된 결과가 토스 증권 PC버전에 도입되어 있다. (+ 다른 팀원들이 투입되어 유지 보수 중)

질문 사항

아이디어는 어떻게 얻었는가? 다른 곳에서 아이디어를 얻었는지, 자체적인 아이디어인지?
- 다른 라이브러리를 많이 써보면서 장단점 파악
  - 새로운 바퀴를 만들지 말란 말처럼 본인이 좋아하는 말이 "거인의 어깨 위에 서라"
- 레퍼런스 공부 당연히 했다..!
아이디어를 떠올린 기간과 작업 기간 산정
- 감..ㅎㅎ
오픈소스 계획/문서화
- not yet
  - 라이브러리 공개가 잘되는 토스이니 만큼 다들 기대하고 있지만 아직..ㅠ

마치며

좋은 인연 덕에 좋은 컨퍼런스에 참여할 수 있었다. 역시 개발자는 소통이 필수인 것 같다.
혼자 메달리는 끈기도 중요하지만, 이런 곳에 참여할 때마다 여러 인사이트를 얻을 수 있다는 것이 참 좋다.

여기에 자극을 받는 건 덤이다.
특히 이번 행사는 토스 주관이니 만큼 꽤 유망 기업들의 개발자분들이 많았다. 당장 내 테이블만 해도 네이버 정재남님에, 카카오 엔터프라이즈에 다니시는 분도 계셨고 말이다.

이런 분들과 인연을 맺는 것도 의미가 깊다.
개인적으론 처음에 언급했던 바이오 기업에 다니시는 분이 따로 본인 기업에 지원해보라며 제안을 주시기도 했다. 아마 내 전공이 이 분야인 게 몫을 했을 것이다.
근데 그걸 떠나서 이런 곳에 참여하지 못했다면 얻지 못할 기회였겠지.

행사 이후엔 다들 링크드인 맞팔을 하며 인사를 하고 헤어졌다.
그리고 난 이번에 초대해주신 지인분과 추가 티타임을 가지며 hold되어 있던 Mincho프로젝트에 대해서 얘기도 나누었고.