Andy Lee

스포트라이트가 디자인 리소스를 아낄 수 있었던 방법

스포트라이트 테크 시리즈로 예전 글에서 어떻게 하면 엔지니어가 디자인영역에 대한 의사결정 및 리소스 활용에 도움을 줄 수 있을지 이야기 해보겠다고 했는데 드디어 관련해서 조금 적어봅니다.

결론부터 말하자면 핵심은 디자인 시스템입니다.

사실 요즘은 디자인 시스템을 적용하지 않는 회사가 거의 없을 정도로 여러가지 형태로 적용되어 활용되고 있습니다.

그래도 여전히 제 주변에는 디자인 시스템을 잘모르는 엔지니어 분들이 많습니다. 특히 프론트엔드에 집중하고 있는 엔지니어라면 디자인 시스템을 이해하는 것은 가히 필수라고 말씀드리고 싶습니다.

그럼 디자인 시스템은 무엇일까요?

디자인 시스템은 간단하게 설명하자면 디자인에 필요한 요소들에 대해서 디자인 토큰이라는 기본적인 요소별 특성 및 값들을 정의를 해서 모아놓은 것입니다. 물론 이러한 다자인 토큰을 정의하는 것의 이면에는 시스템별로 각각의 디자인 철학이 뒷받침 되게 됩니다.

디자인 시스템의 육하원칙 by Data Driven Design

흔히 구글의 Material design, 어도비의 Spectrum design, IBM의 Carbon design 등 유명한 디자인 시스템들의 이름을 들어보셨을 수도 있겠습니다.

혹은 엔지니어라면 리엑트 생태계의 MUI 라이브러리가 매우 익숙하실겁니다. MUI는 즉 Material UI로 Material 디자인 시스템의 디자인 정의를 기반으로 일부를 차용해 리액트 컴포넌트 라이브러리로 만든것입니다. (MUI의 실제 적용은 Material Design의 기본 디자인 토큰 정의와는 다소 다른 부분들이 좀 있습니다)

디자인 시스템을 이해하게 되면 흔히 프론트엔드에서 하게 되면 Theming에 대해서도 좀 더 잘 이해할 수 있게 됩니다. 그리고 무엇보다도 대부분의 디자인 시스템은 리스폰시브의 개념을 포함하고 있습니다. 따라서 개발자가 일일이 픽셀단위로 객체를 옮기고 하지 않아도 됩니다. 게다가 디자인 토큰의 개념이 확장하게 되면 Component Driven까지 생각할 수 있게 되고 일일이 객체를 커스터마이징 하지 않고 개발자는 규정된 틀에 맞게 요소들을 배치하고 UI의 기능적인 부분 구현에만 좀 더 치중할 수 있게 됩니다.

현재는 스포트라이트 또한 진행형이긴 합니다만 향후에는 스포트라이트의 브랜딩과도 연결해서 디자인 시스템을 운영하는 것을 목표로 하고 있습니다.

풀스택이거나 프론트엔드 엔지니어신가요? 디자인 시스템을 인지하고 계신가요? 아니라면 지금 바로 디자인 시스템을 좀 더 탐구해보시거나 팀내 디자이너와 디자인 시스템에 대해서 이야기 나누어 보세요. 이미 적용된 Theme 구조를 한층 더 디자인 맥락에 맞게 운영하실 수 있으실 겁니다. 그리고 무엇 보다도 디자이너와 엔지니어간 커뮤니케이션 비용의 줄어드는 것을 확인 하실 수 있으실 겁니다.

애자일은 죽었는가?

작년부터해서 최근까지 애자일이 죽었다던가 애자일에 대한 회의론이 많이 들려오는것 같네요. 이런 움직임이나 이야기가 최근들어 특히 많이 들려오는것은 여러가지 이유가 있겠지만 개인적으로는 다소 어그로성이 크거나 오해에서 발생했을 것으로 생각합니다.

제가 애자일을 공부하기 시작했던 2010년대 초반, 갓 취업전선에 뛰어들었던 사회초년생 시절을 떠올려보면 프로덕트에 대한 경험없이 애자일은 조금 이해하기 어려웠던 기억이 납니다. 실무 경험이 없던 저에겐 매우 추상적으로 다가왔고 그 이후에도 애자일이 무엇인가를 이해하는데에는 꽤 많은 시간이 걸렸었네요.

저만 그랬던것은 아니었는지 애자일이 무엇이냐에 대한 얘기가 계속 있어왔던 것 같습니다. 일부는 그냥 유행처럼 우리는 애자일을 한다고만 했던 분들도 기억납니다. 마치 많은 일을 빠르게 쳐내기 위한 마법의 단어처럼 쓰였던 것 같습니다. 그러한 분들이 막상 프로덕트를 만드는 과정에 대해서는 이해가 없다거나 애자일 자체가 아닌 방법론을 따르기 위해 일을 하는 경우도 종종 있었던 것 같네요. 이로인해 주변에서 회의적인 시각을 갖게 되는 분들도 생겼었습니다. 그래서인지 저도 애자일이라는 용어 자체에 부정적인 시각을 가지는 분들도 일견 이해는 갑니다.

근데 사실 알고보면 애자일은 Manifesto, 즉 무언가는 지향하고 무언가는 지양한다는 선언에 불과합니다. 방법론이기 보단 제품을 제공할때의 태도나 철학에 가까운 것이지요.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

이 어디에도 무엇을 정확히 어떻게 해야한다는 내용은 없습니다. 강제성도 없구요. 물론 흔히 프레임워크라고 불리우는 방법론 들이 있습니다. 프로젝트 관리 관점에서 SCRUM이라던가 개발팀의 실천적인 관점에서의 XP라던가 애자일과 관련된 여러가지 프레임워크 혹은 방법론이 존재합니다. 프레임워크는 빠르게 체계를 잡고 유용한 도구를 활용하기에는 분명 이점이 있습니다. 그렇지만 그 어떤 도구나 프로세스도 모든 문제에 대한 해결책이 될 수는 없겠지요.

여기서 제 우려가 시작됩니다.

애자일을 방법론으로 받아들이고 이것을 소용없다고 판단하는 순간. 그럼 워터폴을 다시 해야하느냐 혹은 그냥 주먹구구를 다시 해야하느냐는 식의 생각을 한다는 것입니다. 어떤 방법이 효율이 나쁘다고 해서 주먹구구로 돌아가는것은 정말 어리석을 뿐 더러, 워터폴과 같은 다른 방법을 찾는 것 또한 21세기 경영에서 고전경영으로 돌아가겠다는 얘기와 똑같습니다. 물론 고전경영이 더 효과적인 분야도 있겠죠. 그래서 워터폴도 여전히 효과적인 분야나 부분이 있습니다. (이 부분은 조금 논점에서 벗어나기에 기회되면 따로 다루어 보겠습니다.)

특히 프로덕트와 관계 없는 분들의 오해를 불러 일으키는 측면이 매우 걱정됩니다. 아시는 분들이야 이러한 맥락을 이해하고 애자일이 죽었다던가 하는 표현을 쓰겠지만 잘 모르시는 분들은 진짜 이러한 어프로치가 소용없나라는 생각을 하실 수도 있다는 것입니다.

게다가 이 성명서는 기술자들이 모여서 발표되고 시작되었습니다. 참여자 한분 한분 다들 전설적인 분들입니다마는 소프트웨어 엔니지어가 아니라면 사실 잘 모를 가능성이 높은 분들이지요.
그래서였을까요. 애자일이 구체화되어 오는 과정에서 비즈니스에 대한 논의는 조금 빠져있던 것 아닐까라는 생각도 조금은 듭니다. 어떻게 고객에게 제품을 잘 전달할까에 대한 고민만 좀 더 무게를 두었던 측면이 있었던 같습니다. 어떻게 비즈니스에 기여할까라는 측면은 조금 배제되었던게 아닌가 말이죠.
그래서 애자일을 새롭게 하려는 시도의 일환으로 애자일이 죽었다라던가 애자일2를 해야한다 라는식의 이야기를 하는 것 아닐까 조심스럽게 추측해봅니다.
여담으로 테스트 - 학습- 개선의 짧은 반복이라는 측면에서 보면 애자일은 린스타트업과도 매우 닮아 있습니다. 근데 린스타트업은 잘 도전받지 않는 데 비해서 (일부 있기는 하지만요.) 애자일은 뭔가 큰 도전에 직면한 듯 보입니다. 심지어 요즘은 마치 새로운 애자일의 춘추전국시대 같기도 합니다. 근데 정말 이런것들의 본질이 다른걸까요? 제가 느끼기엔 위의 성명에서 뭐하나 바뀐것은 없는 것 같습니다. 다만 비즈니스적인 관점을 좀 더 반영하기 위한 시도로 느껴집니다. 그리고 이것을 프로모팅해야 하겠지요. 뭐 아주 좋은 시도라고는 봅니다.

그래도 저는 조금 이러한 표현을 쓰는 것은 굉장히 조심스러울 필요가 있다고 생각합니다.
애자일이라는 본질은 여전히 유효하고 우리가 구석기 시대로 돌아갈 수 없듯, 많은 경우에 애자일은 여전히 매우 유용합니다. 혹시 소프트웨어 엔지니어나 프로덕트 관련 직무에 있으신 분이 아니시라면 혹 어디선가 볼 수 있는 애자일이 죽었다라는 글을 보고 오해하시는 일이 없으시길 바랍니다.

이렇게 애자일 관련 글을 적다보니 문득 저희 스포트라이트팀은 참 애자일이라는 용어를 굳이 끄내지 않고도 굉장히 애자일스럽게 잘 일하는 팀이구나 하는 생각이 듭니다. 아마 저희 비즈니스 사이드의 팀원들은 저 위의 애자일 선언을 본적이 없을 것 같습니다. 그럼에도 위의 선언과 같은 방식으로 비즈니스와 프로덕트팀이 조화롭게 일하고 있는 지금이 참 뿌듯하기 그지 없네요.

그렇습니다 용어는 중요하지 않습니다. 그러나 일하는 방식은 중요합니다. 애자일이라는 말을 쓰시기 싫으시다면 안쓰셔도 좋습니다. 팀과 비즈니스에 맞는 방식을 치열하게 찾으시기 바라겠습니다.

행여 애자일을 포기한다라고 하신다면 적어도 예전 방식을 답습하시는 일은 없기를, 자신들만의 새로운 방식을 만드시기를 바랍니다.

스포트라이트 테크 시리즈 (1)

최근 까지 접했던 개발과 프로덕트에 대한 여러가지 방법론들과 현재 스포트라이트팀에서의 경험들을 통해 어떻게 하면 초기 스타트업에서 효과적으로 제품을 고객에 전달할 수 있을 지에 대한 개인적인 고민들을 정리해 공유해보고자 합니다.

구체적인 내용들은 아직 정리하는 과정에 있기에 파편화된 형태로 조금씩 공유를 해야할 것 같구요. 내용 자체 또한 모든 경우에 적용할 수 있는 것은 절대 아닙니다. 때로는 일부 내용들이 다소 급진적으로 들릴지도 모르겠습니다.

이번에 다뤄보고자 하는 내용은 초기 스타트업에서의 기술 담당자의 역할과 기술 담당자가 어떤 방식으로 제품을 전달하는 것이 효율적인가에 대한 것입니다.

먼저 전제조건으로 초기 스타트업 중에서 아예 제로 베이스에서 비즈니스 빌딩을 하는 팀은 제외를 하겠습니다. 또한 하드웨어나 딥테크를 하는 경우를 제외하구요.
노코딩이나 다른 방법으로 어느정도 비즈니스 검증을 완료한 상태에서 본격적인 제품이 필요해진, 서비스 개발을 메인으로 하는 회사로 한정해서 이야기를 풀어보겠습니다.
아마 기술 담당자 단독이거나 소수의 개발팀원들로 제품팀이 구성되어 있는 상태이겠습니다.

최초 런칭까지는 개발팀은 단순히 개발에만 집중해서 MVP를 최대한 빠르게 제공하는 데 집중하기만 하면 될것입니다. 물론 세부적으로는 여러가지 과정이 있긴하지만 주된 업무는 제품 개발 그 자체 일 것이구요.
제품 출시 이후 실제 제품이 시장에 공개되고나면 비즈니스가 제품 위에서 오퍼레이션을 시작합니다. 그때부터는 다양한 개발 외의 업무가 기술 담당자에게 요구되기 시작합니다.

일차적으로 당연히 고객의 니즈나 비즈니스에 따른 추가적인 기능을 지속 개발해서 고객에서 제공할 의무가 있겠구요. 두번째로는 제품의 버그나 이슈를 관리하는 유지보수가 필요합니다. 기능을 좀 더 쾌적하게 하거나 사용성을 높이는 등 제품 최적화 및 개선 활동 또한 포함됩니다.
한편 고객이 기술적인 어려움을 겪게 되면 비기술 출신의 멤버들이 대응하는데 한계가 있을 수 있으므로 기술 지원 또한 직접 수행해야 할 수 있습니다.
이정도의 업무만 봐도 팀내 기술 담당자의 접점이 고객과 얼마나 가까운지는 확연해 보입니다.
게다가 초기 스타트업에서 기술 담당자는 제품을 만드는 사람들이기도 하면서 배달까지의 역할을 겸하는 사람들입니다. 제품을 배포하는 순간 본인 요리했던 것을 직접 배달하게 되는 것이나 마찬가지입니다. 직접 만들었기 때문에 잘 조리된 것을 배달하는 것인지 덜익은 것을 배달하는 것인지를 인식한 상태에서 배달 여부를 결정합니다. 따라서 이들은 제품 전달에 있어서도 고객과 매우 가깝고 또한 고객에 대한 영향력을 가지고 있습니다.

다음으로는 제품 전달 속도에 대해서 한번 생각해보겠습니다.
제품과 관련된 의사 결정들이 고객과 가까운 지점에서 이루어질 수록 제품전달이 빨라진다고 볼 수 있겠지요. 반대로 제품 전달 측면에서 고객의 접점과 먼쪽에서 의사결정이 이루어져서 전달되게 되면 다소 오래걸리는 것이 당연할 것이구요.
그렇다고 당장 제품을 전달하고 있는 기술 담당자가 다 결정할 수 있을까요? 당연히 아니겠지요. 가깝다고 모든 측면을 고려한 의사결정을 기술 담당자가 하는 것은 불가능하고 바람직하지도 않을 것입니다.
그러면 어떻게 하면 고객에게 가장 밀접해 있는 기술 담당자가 비즈니스 가치에 더욱 부합하는 형태의 제품을 더욱 빠르게 전달 할 수 있을까요?

결과적으로 제가 주장하고자 하는것은 초기 스타트업에서는 기술 담당자가 좀 더 다양한 영역으로 역할을 확장해주어야 한다는 것입니다. 그래서 다양한 영역에서의 부분적인 의사 결정에 대해서는 기술 담당자가 빠르게 판단하고 결정할 수 있어야 합니다. (이후로는 다양한 영역에서 역할이 확장된 개발자나 기술담당자를 프로덕트 엔지니어로 부르겠습니다.)

글을 조금이라도 덜 길게하기 위해서 이번글에서는 디자인 영역만을 예시로 들어보겠습니다.
일반적으로 UX디자인(화면디자인)을 받아서 개발을 하는 방식을 많이 떠올리실 것입니다. 그러나 UX/UI라는 영역이 고려되어 개발이 된지도 역사가 벌써 꽤 되었고 많은 부분이 정형화 되었습니다. 따라서 기술 담당자가 프론트엔드 지식 뿐만 아니라 디자인 영역에 대한 지식도 전문가 수준은 아니더라도 어느정도 수준을 갖추게 된다면 (특히 디자인 시스템적인 관점에서의 접근이 중요합니다.) 의외로 화면디자인의 꽤 많은 부분이 자체 판단으로 진행이 가능하게 됩니다. (프로덕트 엔지니어로서 디자인 시스템을 어떻게 바라봐야하는 지에 대한 내용은 차후 추가적으로 다루겠습니다.)
즉 디자인 관련 결정을 프로덕트 엔지니어가 직접함으로서 제품 전달 속도를 향상시킬수 있다는 것 입니다.
디자인 외에도 다양한 영역에서 기술 담당자의 역할을 확장시킬 수 있습니다. 마케팅 측면에서는 데이터와 관련된 엔지니어링 영역들이 있으며 비즈니스와 관련해서는 좀 더 도메인 지식을 갖추는 방식(DDD등의 방법론)으로 좀 더 적극적으로 기능에 관여하거나 적합한 로직을 도입하는데 도움을 줄 수 있습니다.

따라서 이러한 초기 스타트업 상황하에서는 프로덕트 엔지니어가 다양한 역할을 수행하며 부분별 의사 결정 권한을 갖는 것이 제품 전달의 속도를 높이는 열쇠일 것입니다.

Ubiquitous Language를 정리하기위해 Domain Driven Design관련 서적들을 오랜만에 다시 들여다 보고 있는데 다시금 보니 DDD 또한 여전히 엔지니어적인 시각 혹은 출발점에서 접근하고 있다는 생각이 듭니다.

DDD를 위해서는 도메인 전문가나 비즈니스 사이드의 분들의 좀 더 적극적인 참여가 요구되고 오히려 이들을 중간으로 데려와야하는 느낌도 듭니다. 그러한 노력을 해야하는데 비해 대부분의 DDD 서적이나 내용들이 DDD가 무엇이고 왜하는지 그리고 어떻게 하는지는 지에 대해 엔지니어에게만 설득하고 있다는 느낌이 들었습니다.

생각보다 많은 개념이나 패턴들이 명료하게 사례 하나하나를 뜯어보지 않으면 심지어 저조차도 명쾌하게 이해하기 어려운 부분이 많고 (물론 모자른 저의 경험과 실력도 한몫하겠습니다만)

DDD의 취지나 전반적인 접근 자체를 비엔지니어가 알아들을 수 있게 설명하는 부분은 거의 없거나 극히 미진한것 같습니다. (웹상에서는 이러한 내용을 잘 정리해주신 분들이 있긴 합니다만 비엔지니어 출신분들이 잘 찾아보지는 않을 것 같네요.)

따라서 DDD를 내용만 가지고 혹은 그 자료들만 가지고는 비엔지니어분들을 여기에 참여하도록 설득하는데는 한계가 있을 것 같고 Promoting하는 것에도 제약이 많을 것으로 예상됩니다.

DDD가 엔지니어 끼리만 하는 얘기를 넘어서서 Business Oriented 혹은 Business Driven에 도움되는 요소로 적용되려면, 좀 더 포괄적이고 비즈니스 Effective한 측면을 부각시킨 이야기가 필요하지 않을까라는 생각이 듭니다.

비엔지니어가 이해할 수 있는 용어와 사례로 정리되어야 하는 것은 당연할 것 같고 Development나 Design의 관점이 아닌 포괄적인 Business oriented Product delivery with right timing and resources 라는 개념으로 접근해보면 어떨까 싶습니다.

안녕하세요. Flip-ers의 Andy입니다.

인도네시아 현지를 대상으로한 관심사 기반 소모임 플랫폼 sarang을 개발중인 Andy(이상헌) 이라고 합니다.

커뮤니티 서비스를 만들어 가는데 있어 여러가지 정책, 장치들이 도움이 될 지. 그리고 양질의 콘텐츠를 유지하고 제공하기 위해 플랫폼에서 어떤 노력들을 할 수 있는지. 많은 조언 도움 받고 싶습니다.

그리고 서비스 개발과 관련해서도 이야기를 나눌 수 있으면 좋겠습니다.

잘 부탁드리겠습니다.

https://sarang.community