서울 디자인 소사이어티, 디자이너 커뮤니티

서울디자인소사이어티티

서울디자인소사이어티 (SDS)

서울디자인소사이어티는 성장과 공유가 필요한 미대생과 주니어 디자이너들을 위한 집단 지성 네트워크 / 커뮤니티 서비스입니다.

프로젝트 개요

• 개발시기: 2023년
• 주요 사용 언어: Flutter, Dart (앱), Python + Flask (백엔드)
• 결과물: 안드로이드 및 iOS 앱
• 기여도: 100% (기획, 설계, 개발, 테스트, 유지보수)

배경

최초 서비스의 기획은 디자인 분야의 Stack Overflow와 같은 Q&A 커뮤니티를 만들고자 시작되었습니다.
거듭된 회의와 논의를 거치고, 실제 MVP를 개발하면서 처음 기획 의도와 달리 디자이너 대상 특히 피드백과 조언, 그리고 고민 상담이 필요한 주니어 디자이너들을 대상으로 한 커뮤니티로 방향을 전환하게 되었습니다.
프로토타입 서비스를 바탕으로 유저들의 피드백을 받고, 내부 개발 과정에서도 계속적으로 기획이 변경되었고, 결국 미대생 또는 취업을 준비하고 있는 예비 디자이너들을 대상으로 한 안건 (디자인 시안 등) 과 피드백 (시니어 및 경력 디자이너의 답변)을 중심으로 한 커뮤니티로 최종 방향을 잡게 되었습니다.

서비스 특징

긴 온보딩 과정

서비스는 기본적으로 커뮤니티입니다. 이 서비스를 이용하기 위해서는 긴 온보딩 과정을 거쳐야 합니다. 글(안건)을 작성하는 것 뿐만아니라, 글을 조회하기 위해서는 이 온보딩 과정을 거쳐야 합니다.
온보딩 과정은 자신의 소속을 최대한 상세하게 입력해야 하며, 사용자 구분은 외부에 공개되지 않은 핸드폰 번호를 기반으로 이루어집니다. 핸드폰을 통해 본인 인증을 반드시 거쳐야 합니다.
이런 긴 온보딩 과정은 추후 서비스 개선 및 고객 만족도 향상을 위해 매우 중요한 데이터를 제공해 줄 수 있으며, 기획 당시 해외 서비스들이 매우 길고 복잡한 온보딩 과정을 거치게 하는 것이 일종의 트렌드 처럼 여겨지기도 했습니다.
실제로 서비스 운영과정에서 고객 유형 별 만족도나 특징 분석 등에 사용자들의 온보딩 과정에서 제공한 정보가 매우 유용하게 사용되었습니다.

온보딩 과정

안건과 피드백

• 안건: 안건은 디자인 시안, 포트폴리오, 디자인과 관련된 어떠한 이미지나 미디어 혹은 유머 짤 등 사용자가 올리는 글입니다. 안건에 이미지는 필수가 아니지만 더 좋은 피드백 (답변/댓글)을 받기 위해서는 권장되는 부분입니다. 각 안건은 추천을 받을 수 있습니다.
• 피드백: 피드백은 안건에 대한 일종의 답변/댓글입니다. 한 사용자는 하나의 안건에 하나의 피드백만 줄 수 있습니다. 피드백도 안건과 마찬가지로 추천을 받을 수 있습니다. 피드백에 하위에 다시 댓글을 달 수 도 있습니다.

앱 화면

기술

기술 스택

기본적인 기술 스택은 아래와 같습니다.

• Flutter + Dart: 안드로이드 및 iOS 앱
• Nginx + Python + Flask: 백엔드 서비스
• postgreSQL: 데이터베이스

Flutter는 안드로이드와 iOS 앱을 동시에 개발할 수 있는 크로스 플램폿 프레임워크입니다. 하나의 코드로 안드로이드, iOS, 웹, 데스크톱 앱 모두를 개발할 수 있는 장점이 있으며, 꽤 준수한 성능을 보여줍니다. React Native와 자주 비교되는 프레임워크이며, Google이 개발하고 앱 개발 시 추천하고 있기 때문에 해당 프로젝트에서 선택하게 되었습니다.
많은 기업에서 Flutter를 차용하고 있으며, 점차 그 저변이 늘어나고 있는 추세입니다.

postgreSQL은 MySQL과 함께 많이 사용되는 오픈소스 데이터베이스로, MySQL과 매우 유사한 쿼리 문법을 지원합니다. 안전성과 성능이 우수하여 해당 프로젝트에서 사용하게 되었습니다. MongoDB와 같은 NoSQL 데이터베이스도 고려했으나, 데이터의 구조가 명확하고 관계형 데이터베이스로 충분히 처리할 수 있는 데이터 구조이기 때문에 postgreSQL을 선택하게 되었습니다.

유니버셜 링크와 딥링크

유니버셜 링크와 딥링크는 웹 주소 링크를 이용해 앱의 특정 화면으로 이동할 수 있는 기능입니다. 이 기능을 통해 외부 SNS나 타사 웹사이트에서 웹 URL만 기재해 놓으면 누구든지 쉽게 앱의 특정 화면으로 이동 시킬 수 있습니다.
예를 들어, 앱 내에서 각 안건은 각각 고유의 URL 주소가 할당되어 있으며, 이 URL을 공유하면, 어디에서든 쉽게 해당 안건으로 이동할 수 있습니다. 앱 내부에서도 이 URL을 통해 특정 화면으로 이동됩니다.

애플

아래는 애플 관련 유니버셜 링크와 관련하여 개발 과정에서 남겨 놓았던 회고록입니다.

하지만, 언제나 그렇듯 iOS에서 제공하는 Universal Link는 문제점이 많습니다. iOS서 유니버셜 링크를 사용하는 경우, 카카오톡이나 일반 Webview기반에서는 해당 링크가 앱을 trigger하지 않고 그냥 웹으로 랜딩시켜 버린다.
iOS 사파리 브라우저에서도 만일 사용자가 직접 Url을 입력해도 앱이 아닌 웹 주소로 이동시켜 버린다. 만일 브라우저에서 동일한 도메인에 머물러 있다면 해당 링크를 클릭해도 유니버셜 링크는 동작하지 않는다.

만일 이를 해결하고자 전통적인 URL Scheme을 사용하게 되면, 사파리 브라우저에서는 보안 경고 메시지를 띄운다. 문제를 정리하면 다음과 같다.

Universal Link가 동작하지 않는다 -> 웹으로 이동 -> 랜딩 페이지에서는 앱이 자동으로 안뜬다. URL Scheme은 경고를 띄우고, 기존의 Universal Link는 아예 안먹는다.

그렇다면, Universal link는 왜 만든것인가? 타사 앱이나 기본 내장 앱, 혹은 다른 웹사이트에서 유니버셜 링크는 사용자가 직접 클릭하면 동작한다.
이것이 무슨 일인가?
자, 그럼 유니버셜 링크가 동작하지 않아서 랜딩 페이지로 왔다고 치자. 완전히 다른 웹사이트로 다시 사용자를 이동시켜 본다.
이 완전히 다른 웹사이트에서 다시 유니버셜 링크 앵커 태그를 만들어서 페이지 로딩 후, 자동으로 클릭되게 만들어 보자.

이 역시 안된다. 왜냐하면, 최초의 Trigger에서 사용자의 인터랙션이 없었기 때문이다.
이제, 유니버셜 링크가 동작하지 않는 카톡에서 직접 링크를 만들어 클릭을 해본다. 역시 동작 하지 않는다. 앱이 아닌 웹페이지로 빠지게 된다.
그럼, 미리 만들어 놓은 Tricky 웹사이트로 이동시킨다. 다시 유니버셜 링크를 생성해서 자동으로 클릭시켜 준다.

앱이 뜬다.

다시, Fallback 상황도 고려해야 한다. 그렇지 않다면 무한 루프에 빠진다.
미리 만들어 놓은 Tricky 웹사이트에서 유니버셜 링크에 추가 파라미터를 달아줘서 이를 인지하면 더 진행 시키지 않도록 한다.
앱이 안뜨고 웹으로 랜딩되면 추가 파라미터 존재 유무를 보고 tricky 웹사이트로 다시 안돌아가게하고 동작을 멈춘다.

이런 상황때문에, 유료로 딥링크를 지원 해주는 서비스들이 생겨났고, 그들은 위의 회고에 적어 놓은 전략과 유사한 방식을 차용하는 것으로 보입니다. 유료인 이유는 적어도 2개 이상의 도메인을 필요로 하기 때문일 것입니다.

당연하게도, 구글의 딥링크는 거의 모든 상황에서 완벽하게 동작합니다. URL 하나만으로 도메인 인증만 되면 앱의 설치 유무에 따라 자동으로 앱을 띄우거나 마켓으로 랜딩시켜 줍니다. (갓구글)

마무리

국내에 디자이너를 위한 전문 커뮤니티 서비스가 현재까지도 많이 없는 상태입니다. 해당 서비스는 실제로 디자인 페스티벌 행사에서 소개되어 동시 접속자 수를 수백명까지도 기록한 바 있습니다.
동시에 여러 사용자가 온보딩하고 안건을 올리며, 피드백을 주고받는 과정도 서버가 안정적으로 처리할 수 있게 최적화되어 있어서 순조롭게 진행되었습니다.

현재 해당 서비스는 별도의 오프라인 행사 위주로 이전되었고, 앱은 Apple App Store에만 남아 있습니다.

아래 주소를 통해 보다 자세한 내용을 확인할 수 있습니다.

• 서울디자인소사이어티 앱

• 서울디자인소아이어티 사이트