국내에서 열리는 오프라인 컨퍼런스에 처음으로 참석하게 되었습니다. 본격적으로 개발자(?)의 영역에 들어선 이후 해보고 싶은것 중 하나였던 오프라인 컨퍼런스 참여를 드디어 하게되었습니다. 평소 개발자 커뮤니티의 장점 중 하나는 “공유하는것”이라고 생각해왔는데 실제로 참가해보니 왜 공유가 필요하고 장점이 무엇인지에 대해 피부로 느낄 수 있었습니다. 평일에 진행되었지만 다행히도 회사의 지원을 받아 참가할 수 있게 되었습니다.
행사 위치는 삼성역 소재 서울 파라나스 호텔 2층, 5층에서 진행되었습니다. 설레는 마음을 갖고 행사장에 들어서자 예상보다 많은 사람들이 있었습니다. 현장등록 선착순 1200명에게 서울파라나스 호텔에서 점심식사가 제공되었는데 예상보다 많은 인원이 몰려 순식간에 끝났습니다.
행사장 내부에는 다양한 부스들로 구성이 되어있었습니다. 먼저 등록 및 명찰을 배부받고 행사장을 본격적으로 둘러보았습니다. 게임참여 공간, 스티커 및 굿즈, 포토존, 후원기업 홍보관 등 다양한 공간으로 나누어져있었습니다. 라운지에서 별도로 진행하는 라운지 토크 세션도 준비되어 있었습니다.
게임참여 공간, 스티커 및 굿즈, 포토존, 후원기업 홍보관 등 다양한 공간으로 나누어져있었습니다. 라운지에서 별도로 진행하는 라운지 토크 세션도 준비되어 있었습니다.
세션
컨퍼런스의 꽃이라 할 수 있는 세션에도 참여하였습니다. 비록 제한된 시간에 구체적인 내용까지 공유가 되지 않았지만 평소 관심있었던 주제에 대한 구체적 사례들과 다른 기업에서 업무하는 방식, 평소에 알지 못했던 주제들을 듣고 알 수 있게되어 뜻 깊은 시간이었습니다.
session 1. 거대한 서비스 쪼개서 마이크로 프런트엔드 만들기 - 이웅재님 NHN Dooray
https://forward.nhn.com/2022/sessions/2
마이크로 프론트엔드 도입의 필요성
해당 세션은 Dooray 프로젝트 리뉴얼을 진행을 맡으며 기존에 만들어진 모놀리식(Monolithic) 방식의 프로젝트에 마이크로 프론트엔드 도입을 하는 과정에 대한 세션이였습니다. 당시 이웅재님의 팀이 직면한 몇가지 문제 대해 말씀하셨습니다. 기존 프로젝트는 많은 도메인으로 이루어져 있었고 모놀리식 방식으로 프로젝트가 구성되어 있었기 때문에 개발자 모두가 모든 도메인들에 대한 지식을 갖고 개발하는 것이 어렵다는 점과 또 그런 다양한 도메인들이 모놀리식 방식으로 구성되어 있기때문에 테스트, 빌드, QA, 배포 등의 과정을 진행 하는데 시간적, 기술적 비용의 측면에서 문제가 있음을 말씀해주셨습니다.
이런 상황에서 마이크로 프론트 엔드를 도입함으로써 각 도메인의 테스트, 빌드, 배포 등의 일련의 과정을 독립적으로 수행하고 각 도메인의 코드 조각들의 경계를 명확히 하는 것을 통해 런타임을 통합하여 앞서 말한 비용의 문제점 등을 해결할 수 있었다고 합니다.
인상이 깊었던 점은 마이크로 프론트 엔드를 도입에 구체적인 동기가 수반되어야 한다는 점이였습니다. 마이크로 프론트엔드가 비교적 새로운 개념이고 이곳 저곳에서 사용하니 유행에 따라 사용하는 것이 아니라 정확하게 처한 문제가 무엇이고 처한 그 문제를 직접적으로 해결할 수 있는 방안이 무엇인지 고민을 한 결과라는 것입니다. 구체적으로 서비스의 규모가 커져 복잡도의 증가를 통제할 수 없는 상황이거나 팀 또는 구성원에게 자율성과 독립성을 부여하고 싶은 경우가 될 것입니다. 또 도입한 것으로 끝나는 것이 아니라 운영하면서 나오는 요소들을 지속적으로 발전시켜야 하는 것이 뒷받침 되어야한다고 말씀하시며 그 이후의 상황도 대처하는 것이 중요하다고 말씀하셨습니다.
평소 어떤 기술이나 아키텍처를 도입하거나 코드를 작성하는 과정에서 명확한 근거없이 습관적으로 또는 비교적 신기술이기 때문에 적용하고 작성한 적이 있었습니다. 이러한 상황을 돌아보는 계기가 되었고 업무를 하면서 개발하는 서비스의 규모가 지나치게 커질 경우 마이크로 프론트 엔드를 도입하여 그 필요성을 느껴보고 싶다고 생각하게 되었습니다.
책임과 경계를 명확히 하는 것
구체적으로 마이크로 프론트 엔드를 어떻게 구성했는지에 대한 내용도 좋았지만 해당 세션에서 좋았던 점은 도입한 이후의 회고 부분이였습니다. 바로 “책임과 경계를 명확히 하는 것”인데요, 이 세션의 주제인 마이크로 프론트엔드를 도입 또한 “책임과 경계의 명확성”을 전제를 조건으로 진행되며 개발뿐 아니라 각 팀, 구성원들의 책임과 경계를 명확히 하는 것 또한 업무를 해나가는데 있어서 중요하다는 것을 강조하셨습니다.
session 2. 구글 사례로 짚어보는 디자인 시스템의 진화 - 이정영님 Google
https://forward.nhn.com/2022/sessions/9
이 세션 또한 평소 관심있는 주제로한 세션이였습니다. 구글의 디자인 시스템을 주제로한 세션이였는데요, 참가했던 세션중 가장 흥미로웠습니다. 이정영님이 라인, 네이버를 거쳐가며 또 현재 구글에서 만들었던 디자인 시스템의 변화 과정에 대해 말씀해주셨습니다.
왜 디자인 시스템을 도입해야 하는가?
디자인 시스템은 어떻게 보면 실제로 도입되어도 겉으로 잘 드러나지 않고 쏟은 노력이 충분히 보상받지 못하는 느낌을 주는 작업이라는 말에 어느정도 공감을 하였습니다. 또한 디자인 시스템을 만든다고 해도 모든 경우를 대비할 수 없고 예외사항 또는 커스터마이징 해야하는 상황이 펼쳐져 디자인 시스템의 효용성에 대해 의문이 들기도 한다고 합니다. 하지만 이럼에도 디자인 시스템은 필요한 필수적 요소라 언급하시며 그 이유중 첫번 째는 공통된 가이드라인을 만들지 않는다면 개인의 선호도에 의해 비슷하지만 다른 디자인적 요소들이 기하급수적으로 생겨나는 것을 막을 방법이 없기 때문이라고 말합니다. 또한 디자인 시스템의 가치는 Efficiency(효율성), Usability(사용성), Product Identity(제품 정체성)에 있음을 강조하셨습니다. 협업의 관점에서 일관된 용어를 사용하게 되기 때문에 업무의 혼란을 감소시키고 효율성 및 생산성을 증가시키며 일관성을 통해 더욱 짜임새 있는 사용자 경험을 선사하게 되고 또한 디자인 시스템이 도입이 된다면 그 자체가 회사의 브랜딩이 되며 곧 정체성으로 이어진다고 하신 말씀에 크게 공감하였습니다.
디자인 시스템의 진화
디자인 시스템은 포토샵등을 통한 단순히 통일된 디자인 가이드를 제공하는 것에서 스케치를 통한 클라우드 라이브러리를 통한 일관성 개선, 그 이후 피그마를 사용한 코드와 디자인의 동기화하는 과정으로 변화하고 있다고 말합니다. 다음 단계로 전사적 단계인 디자인 토큰이라는 단계로 진화해 나가고 있다고 하셨는데 디자인 시스템의 발전과 변화를 알 수 있게 되었습니다.
디자인 시스템을 언제 도입해야 할까?
팀이 점점 커지면서 통일된 기준이 모호해지는 경우, UX 조직의 규모가 커지고 그 역할을 확장해야하는 경우, 전체적인 제품의 디자인을 개선을 앞두고 있는 경우에 도입을 권장한다고 말합니다.
개발자가 디자인 시스템에 참여하는 방법
정영님은 실제로 구글에서 일하면서 동료 프론트엔드 엔지니어가 일관되지 않은 디자인에 대해 임의로 디자인 기준을 세우고 배포하게 되어 디자인 시스템에 대한 협업이 이루어진 경험을 언급하면서 동료 개발자의 적극적인 자세로 디자인 시스템의 도입이 진행되었다고 말씀하셨습니다. 디자인 시스템은 디자이너의 주도로 진행되기도 하지만 개발자의 적극적인 자세를 통해 진행되기도 한다며 적극적 참여가 필요하다고 말씀하셨습니다. 평소 개발을 하면서 개발 외에도 사업, 디자인, 사용자 측면의 사용성 개선등 자신이 속한 사업의 전반을 두루 알아야할 필요가 있다고 느껴왔는데 해당 내용을 말씀해주셔서 많은 공감이 되었습니다.
마무리
컨퍼런스를 마치고 나오는 양손에는 여기저기서 받은 굿즈 및 상품들로 가득했습니다. 한 가지 아쉬운 점이 있다면 컨퍼런스를 혼자 참가했다는 것입니다. 좀 더 적극적으로 즐기지 못한 것 같은 아쉬움이 들었습니다.
기대를 가지고 참여한 컨퍼런스였던 만큼 느끼는 바가 많았고 업무를 하는데 있어서 큰 자극제가 되었습니다. 언젠가 앞의 이와 같은 무대에서 개발하며 고민했었던 문제를 발표하고 공유하는 날을 상상하기도 하였습니다. 다양한 문제들을 마주하고 해결해 나가며 얻은 인사이트를 공유하는 경험 또한 큰 재산이 될 것이라 생각하였습니다.
'ETC' 카테고리의 다른 글
| [디자인패턴]싱글톤 패턴 (0) | 2022.11.30 |
|---|
