Log.info(”Now, Here BE 난중일기”)

들어가며

세상에 좋은 프로젝트는 많지만, 실제로 쓰이는 프로젝트가 더 유의미하다고 판단하기에 유저가 실제로 사용하는 프로젝트를 만들기 위해서 Now, Here 프로젝트를 기획했습니다.

이번 서비스 운영 기간인 10월 1일 ~ 10월 10일 간 평균 DAU 76명, 최대 DAU 281명을 기록하는 등 마케팅에 돈을 들이지 않았음에도 많은 유저 분들이 사용하였고, 감사하게도 다양한 피드백을 받을 수 있었습니다.

해당 프로젝트의 백엔드를 개발하면서, 단순히 API만 만드는 것이 아니라 많은 트래픽을 감당하기 위해서 어떤 고민들을 하고 구현했는지, 단순히 매칭을 연결해주는 것이 아니라 유저들을 어떻게 연결하려고 생각했는지, 실제로 서비스를 운영하면서 일반적인 사이드 프로젝트를 만들었을 때는 다른 어떤 고민들을 했는지 설명하겠습니다.

해당 내용과 관련해서 각각 글 한 개 이상의 내용이라, 자세한 내용은 블로그 글을 첨부하거나, 해당 관련된 개발자의 이메일을 첨부할테니 연락주세요!

DB 아키텍처 설계

이번 프로젝트의 아키텍처를 설계하면서 참고한 이론은 CAP이론입니다.

CAP이론이란 아래의 세 가지 특성 중에서 세 가지를 동시에 만족할 수 없다는 이론입니다.

• Consistency (일관성):

  • 모든 노드에서 데이터를 읽을 때, 항상 동일한 최신 데이터를 반환하는 특성

• Availability (가용성):

  • 시스템이 언제나 응답할 수 있는 상태를 유지하는 특성

• Partition Tolerance (네트워크 분할 내성):

  • 네트워크가 분할되더라도(노드 간에 연결이 끊어지거나 통신 장애가 발생하더라도) 시스템이 계속해서 동작할 수 있는 특성

저희 팀의 경우, 분산 시스템을 통해서 로드 밸런싱 및 가용성 측면에 집중해 구현하기로 계획했습니다. 그래서 데이터베이스를 M -S 아키텍처로 설게하여 M 서버가 끊어지더라도 S 서버를 M 서버로 승격 시켜 유저들 입장에선 차이를 느끼지 못하도록, 고가용성을 보장했습니다.

또한 CUD 연산은 마스터 서버로, R 연산은 슬레이브 서버로 나누어서 평소에도 로드 밸런싱을 하여, 서버 자체의 성능 또한 향상 시키고 확장성을 보장하였습니다.

성능 테스트 및 최적화

저희는 또한 성능 테스트를 통해서 병목 지점을 찾고, 이를 최적화하는 경험을 해보았습니다.

이 내용은 무척 길기에, 자세한 내용이 궁금하시다면 아래의 블로그를 참고하시기 바랍니다.

https://jun10920.tistory.com/40

위 블로그 글들의 내용을 요약하자면

• 성능 목표 잡기

• HikariCP의 연결 최대 풀 설정

• Caffeine 캐시 설정 및 적용

• 인덱싱 및 트랜잭션 관리 최적화

• 하드웨어 리소스 업그레이드

과정을 통해서 SW와 HW 관점에서 최적화를 진행하였고, 목표였던 TTFB를 3초 안으로 줄이는데 성공했습니다.

SW 관점에서 최적화를 했을 때도, 전체 TTFB(응답속도)를 약 40%퍼센트 이상 개선하는데 성공했지만 하드웨어 리소스를 업그레이드 하니 약 99%가 개선되면서, 역시 돈이 짱이구나…하는 생각은 했습니다만 그래도 부족한 자원 속에서 착즙하는 이 경험은 백엔드 개발자로서 굉장히 뜻깊은 경험이었습니다.

실시간 유저 활동 기반 매칭 알고리즘

과거에 다른 프로젝트에서 FOF(친구의 친구를 조회해서 추천)알고리즘을 통해 유저들끼리 매칭하는 로직을 작성한 적이 있습니다.

하지만 이번 프로젝트에서는 FOF보다 좀 더 고도화된, 유저들의 피드백을 직접적으로 반영하는 알고리즘을 구현하고 싶었습니다.

그래서 처음에는 네이버 폼으로 주변인들과 개발 커뮤니티를 통해 설문 조사를 하여 약 8~90명의 데이터를 얻었습니다.

하지만 각 성별 당 MBTI 16개(총 32개의 경우의 수)로 따졌을 때, 각 경우마다 약 3개 정도의 데이터 밖에 얻지 못하였기에 신뢰성이 낮다고 판단했습니다.

그래서 다음에 고안한 것은, 실시간으로 유저들이 매칭되는 것을 반영하여 가중치를 조정하면 원래 목표했던 바를 이룰 수 있다고 생각했습니다.

그래서 실시간으로 유저들이 매칭 되는 것을 반영하여 동적 가중치 조정법을 통해서 반영했고, 하루에 한 번 이 데이터들을 스케줄러를 통해 저장하고, 데이터를 분석하여 관리자 입장에서 인사이트를 얻을 수 있게 자동화 했습니다.

• 실시간으로 유저들이 매칭 되는 것을 동적 가중치 조정법을 통해서 반영

• 하루에 한 번 이 데이터들을 스케줄러를 통해 저장

• 데이터를 분석하여 관리자 입장에서 인사이트를 얻을 수 있게 자동화
  

이 과정 또한 더 자세한 내용은 아래의 블로그 링크에 있으니 궁금하시다면 확인 하시기 바랍니다.

https://jun10920.tistory.com/38

최소 비용으로 인프라 구축 도전

저희가 세운 가장 중요한 목표는 “운영”입니다. 운영을 실제로 해봐야 사용자의 니즈를 알기 쉽다고 생각했습니다. 특히, 처음 서비스를 운영해 보는 입장에서 운영하기 위해 갖춰야 할 기본적인 역량을 얻고 싶었습니다.

서비스를 실제로 운영하려면, 가장 기본인 운영 인프라 환경이 필요합니다. 이전에 Cloudtype이라는 서비스를 이용해서 개발 서버를 쉽게 배포해 본 경험이 있으나, 프리티어의 경우 제한된 하드웨어 리소스와 특정 시간에 인스턴스가 자동으로 꺼지는 큰 단점이 있었습니다. (물론 무료라서 너무 잘 쓰고 있습니다. 호호호) 또한 단점과 별개로, 서비스 운영 시 적어도 vue application, spring application, postgresql이 실행될 공간이 필요했기 때문에 인프라 구축은 필수적이었습니다.

이번 기회로 처음 운영 인프라를 구축해 볼 수 있었는데요. 초보자인 제 시점에서는 비용과 성능을 가장 먼저 고려했습니다. 그 중 특히 비용을 더 중요하게 생각했습니다.

나우히어 팀 사비를 털어 모은 프로젝트 예산이 있지만, 대부분이 SMS 전송 비용으로 사용되어야 했기 때문에 인프라를 구축하고 운영하는 비용을 줄여야 했습니다. 또한, 이전에 인프라를 구축해본 경험이 없어서 서비스 요구 사항에 적합한 리소스 사양을 산정하는 것이 어려웠습니다. 따라서, 무료 티어에서 제공하는 기본 리소스를 우선적으로 활용하여 인프라를 구축하고, 이후 필요한 요구 사항이 생기면 점진적으로 조정해 나가자는 목표를 세웠습니다.

무료 서비스를 담백(?)하게 제공하는 클라우드 서비스를 찾는 것이 최우선이었습니다. 아래는 제가 생각하기에 참 담백한 프리티어 서비스입니다. (오라클 클라우드)

상시 무료라는 것은 평생 무료라는 것이겠죠.

학습용으로도 최고이지만, 저희처럼 프로토타입을 빠르게 배포하고 성능 요구사항을 산정하는 것에도 적합하다고 생각했습니다.

유일한 단점은 AWS 보다 참고할 레퍼런스(블로그 글, youtube 영상 등)가 부족한 게 아닐까 싶습니다. 일단 제일 잘하는 맨땅의 헤딩을 시도했습니다. 스스로 많이 부족하다고 느낀 과정이었습니다.

now-here.site 도메인을 구매해서 DNS 서버를 Cloudflare로 이전하고, DNS 레코드를 지정해야 하는데, 레코드 개념도 몰라서 학습하느라 간단한 아키텍처도 구축이 오래 걸렸습니다. 가능하면 구축하는 과정에서 필요한 지식을 배우고 가려고 했습니다. DNS resolving 과정이나, private/public subnet을 왜 나눠야 하는지, bastion 서버가 필요한 이유, NAT 게이트웨이를 통한 외부 API 호출 방식 등 궁금한 게 정말 많았어요. (여전히..)

그래서 인프라를 구성하며 한 번에 이해하기 어려운 것들을 도구를 이용해 정리하려고 노력했습니다. (개인적으로는 흐름에 따라 동작을 한 눈에 볼 수 있을 때 이해하기가 수월한 거 같아요 )

아래 그림은 ‘나우히어’ 인프라 아키텍처보다는 초안 스케치에 가까운데, 머릿속에서 뒤엉킨 것들을 시각화하면서 정리하려는 시도라고 봐주시면 좋을 것 같아요.

다음은 위의 스케치를 보고, 구축하면서 어떤 고민들을 했는지 간략하게 설명하겠습니다.

1. GitHub Actions & Docker 활용한 CI/CD

• GitHub Actions

  • Github 코드 베이스와 쉽게 통합시킬 수 있는 환경이자 무료입니다. (최고)

  • CI/CD 파이프라인을 자동화함으로써, 반복적인 배포 과정을 줄이고 실수를 최소화할 수 있을거라고 생각했습니다.

  • secret key를 쉽게 관리하지만, 런타임에 주입하면서 안전성을 확보하려고 했습니다.

• Docker

  • 도커 이미지는 환경의 일관성을 보장해주기 때문에 코드와 의존성을 이미지로 빌드해 쉽게 배포할 수 있을거라고 생각했습니다. (하지만 러닝 커브는 높았습니다…)

  • 버전 관리하는데 크게 도움이 될거라고 생각했습니다.

  • 빌드/배포 환경을 미리 이미지화해서 파이프라인에서 사용하면, 배포 시간을 크게 단축시킬거라고 생각했고, 실제로 Vue 빌드/배포 시간을 50% 단축할 수 있었습니다.

2. Oracle Cloud Infrastructure (OCI) 선택

• Oracle Cloud

  • 상시 무료 티어를 제공하여, 비용을 절감하면서도 필요한 기본 인프라를 갖출 수 있었습니다.

  • 프리티어인데도 불구하고, Object Storage, Container Registry, VM 인스턴스 등 여러 리소스를 통합적으로 관리할 수 있습니다.

3. Cloudflare 사용한 DNS 및 CDN

• Cloudflare

  • CDN 기능을 통해 정적 리소스를 빠르게 전달하고, Edge Location에 캐싱하여 불필요한 네트워크 요청을 줄일 수 있다고 판단했습니다.

  • DNS 관리와 함께 프록시 설정을 통해 서버로의 트래픽을 효율적으로 전달할 수 있을거라고 생각했습니다.

  • Worker를 이용하면 부적절한 접근에 대한 에러 페이지를 Cloudflare 단에서 처리할 수 있습니다. 서버에 도달하기 전에 오류를 차단하고, 사용자에게 적절한 에러 메시지를 빠르게 제공하려고 고민했습니다.

4. 로드 밸런서와 라운드 로빈 전략

• 로드 밸런서를 통해 트래픽을 각 서버에 고르게 분산하고, 라운드 로빈 방식을 적용하여 고가용성을 유지하고 서버 간 부하를 균등하게 분산할 수 있다고 생각했습니다. (다만, 저희처럼 인 메모리에 캐싱해둔 데이터가 있다면 동기화 문제를 고민해야 합니다.)

• 이를 통해 서비스가 다운되지 않고, 무중단 배포가 가능한 구조를 만드려고 했습니다.
  

5. Object Storage로 정적 파일 호스팅

• 정적 파일(HTML, CSS, JavaScript 등)을 Object Storage에 호스팅하여, 비용을 절감하면서도 빠르고 안정적인 파일 전송을 구현할 수 있습니다.

• Cloudflare와 연동하여 CDN으로 전달함으로써 시너지 효과를 낼 수 있다고 생각했습니다.
  

이번 도전기는 정말 새로운 경험이었고, 배우는 게 많았습니다. 처음부터 끝까지 배워가며 하나씩 직접 해보는 과정이 쉽지는 않았지만, 어려움을 극복할 때마다 어느 정도 성장하고 있다고 믿습니다!

기본적인 아키텍처와 CI/CD 파이프라인을 설정하고 나니, 배포 속도는 물론이고 운영 편의성도 크게 향상된 게 느껴집니다. 특히, 제가 두서없이 시도했던 것들이 팀원들에게는 자동화된 형태로 결과를 보여줄 수 있다는 점이 가장 보람찼던 것 같네요.

앞으로도 서비스 성능 요구사항에 맞춰 개선해야 할 점들이 많이 남아있지만, 팀원들과 함께 지속적으로 배워가며 발전해 나가고 싶습니다.

나우히어 프로젝트에서 인프라 구축과 CI/CD 자동화에 처음 도전한 이 경험이, 다른 사람들에게도 새로운 도전을 위한 동기부여가 되었으면 좋겠습니다~

마무리하며

앞으로도 서비스를 운영하면서, 유저 피드백과 서비스 요구사항에 따라 능동적으로 개선해 나갈 계획입니다. 현재 운영 중인 피드백을 반영해 더 나은 서비스를 만들고, 다음 운영에서는 한층 발전된 나우히어를 선보이는 것이 목표입니다 :)

10월 31일까지 나우히어를 한 번 사용해보시고, 소중한 피드백을 남겨주시면 정말 감사하겠습니다!
Now, Here (now-here.site)

나우히어 FE 개발자, 도대체 무슨 고민을 했을까? 😲😲

앱? 웹?

나우히어팀이 가장 먼저 고민했던 것은 서비스 플랫폼의 형태입니다.

특정 기간 동안에만 사용할 수 있는 단발성 서비스인만큼 접근이 간편해야 하고, 특정 장소마다 이벤트가 분류되는 경우가 있어 현장에 부착된 QR 코드로 서비스에 접속할 수 있도록 해야 했습니다.

따라서, 별도의 설치가 필요없는 '웹' 플랫폼을 선택했습니다.

또한 사용자에게 가장 친숙한 모바일 UX/UI를 중심으로 화면을 설계했습니다.

개발 스택

개발 스택을 결정하면서 가장 중요하게 생각한 것은 딱 두 가지입니다.

1. 4주 안에 빠르게 개발 가능한가?

2. 앱처럼 보이는 모바일 웹을 구현할 수 있는가?

이 두 가지 기준으로 생각했을 때 바로 떠오른 것은 Vue 프레임워크였습니다.

Vue의 장점

1. SPA 프레임워크로, 화면 깜빡임을 최소화하고 부드러운 사용자 경험 제공할 수 있다.

2. React보다 러닝 커브가 낮아 빠르게 개발할 수 있다.

개발 스택의 중요한 기준 두 가지를 곧바로 충족시킨 Vue... 선택하지 않을 수 없었습니다.

협업은 어떻게 할까?

나우히어 프론트엔드 팀은 저를 포함한 두 명으로 이루어져 있습니다.

저는 Vue, React 등 SPA 개발 경험이 조금 있는 주니어 개발자.

다른 한 분은 UX/UI 디자이너지만 프론트엔드 개발에 도전하는 학생.

아기자기한 경력을 가진 두 사람이지만 어떻게 해야 협업을 잘 할 수 있을지 고민해보았습니다.

우선, 가장 일반적인 형상 관리 플랫폼인 Github를 사용하기로 했습니다.

그리고 개발 프로세스에 대해 아래와 같이 규칙을 세웠습니다.

1. 개발 이슈 작성

2. 개발 브랜치 생성 (이슈 번호 포함)

3. 각 브랜치에서 작업 수행

4. 로컬 테스트 진행

5. 상용 브랜치에 PR

6. 코드 리뷰 후 Merge

7. 상용 테스트

최초에는 개발 브랜치를 따로 두고 개발 서버도 운용하자는 이야기가 있었는데, 프로젝트 규모와 일정을 생각하면 기능 브랜치, 상용 브랜치로만 운용하는 것이 더 합리적인 것으로 보였습니다.

(개발 프로세스 확립을 위해 열심히 토론한 내용)

추후 서비스 규모가 확대되면 개발 브랜치 및 서버를 운용하는 것으로...ㅎㅎ

코드 아키텍처

이번 프로젝트를 통해 얻고자 했던 핵심 경험 중 하나, 코드 아키텍처입니다.

스타트업 SI 업체, 학생 프로젝트, 대기업 내부 프로젝트 등 다양한 코드 아키텍처를 겪어보면서

어떤 게 좋은 코드 아키텍처일까? 라는 고민을 하게 되었습니다.

이미 형성되어 있는 코드 아키텍처를 바꾸기엔 쉽지 않으니 이번 프로젝트를 통해서 새로운 코드 아키텍처에 도전해보자! 라는 생각이 있었습니다.

그래서 도입한 것은 클린 아키텍처입니다.

Entity, Usecase, Repository, Store를 사용하여 책임을 분리하고 추후 유지보수가 용이하도록 코드를 짰습니다.

예를 들어 member info에 대한 Entity를 정의하고 해당 도메인과 관련된 비즈니스 로직은 usecase에 작성했습니다.

그리고 http 요청과 응답과 관련된 로직은 Repository에 작성하고,

각 로직을 호출하여 최종 응답을 return하는 곳은 store로 정의했습니다.

위와 같이 특정 도메인(member)에 대해 Entity를 형성하고 관련 비즈니스 로직을 책임에 맞게 분리하니 개발하면서도 정리가 된 듯한 느낌이 들었습니다.

물론 아직 부족한 점들도 많겠지만, 실제로 부딪혀가며 개선해가는 과정을 가지려고 합니다 ㅎㅎ

향후 계획?

현재는 프로덕트를 런칭한지 일주일 정도 지났는데요.

생각보다 사용자 수가 많고 피드백도 많이 들어와서 할 일이 아주 많아졌습니다. (그래서 더욱 재밌습니다.)

유저 피드백을 바탕으로 애자일하게 기능을 꾸준히 개선 중이고, 기능 개선과 더불어 프론트엔드 코드 아키텍처에 관련하여 끊임없이 고민하고자 합니다.

이번 서비스는 한 달 동안 운영되기 때문에, 이번 운영 피드백을 바탕으로 더 나은 서비스를 만들어 두 번째 운영을 새롭게 오픈하는 게 저희 나우히어 팀의 목표입니다 :)

가을 축제 기간동안 운영되는 나우히어! 한 번씩 사용해보시고 피드백해주시면 정말 감사하겠습니다!

(실제 매칭되는 열 분께 베스킨라빈스 파인트도 드려요...)

이벤트 기반 소개팅 서비스, 나우히어의 디자인은 어떻게 탄생했을까요?

안녕하세요!

이벤트 기반 소개팅 서비스를 개발하고 있는 '나우히어' 팀입니다. 😊

이전 글에서는 서비스와 기획에 대헤 소개했습니다.

이번에는 디자인을 보여드리면서, 고민한 부분들에 대해서 얘기해드리려고 합니다.

💡 로고

로고를 디자인하기에 앞서, 본 서비스의 기획에 대한 분석을 진행했습니다.

이벤트가 있는 특정 위치에서만 QR을 통해 접속할 수 있고, 그곳에서 만난 사람들 간에 인연을

연결시켜준다는 것이 저희 서비스의 가장 큰 매력이자 차별성이라고 결정했습니다!

이러한 특징을 살리기 위해, 사용자가 “위치”라는 특징을 쉽게 이해시키는 것이 로고를 디자인할 때 중점이었습니다.

이에 대한 해결책으로 선택한 것이 “아이콘”이었습니다.

위치 아이콘을 응용하면, 서비스의 특징을 효과적으로 표현하면서,

적절히 응용하는 경우. “하트”의 형태 또한 표현할 수 있는 적절한 소재라고 생각했습니다.

초기 로고의 디자인의 경우, 위치 아이콘을 겹쳐 “하트”의 형태를 구현하였지만, 전후면 간의 대비가 부족하여, 위치와 하트라는 두 가지의 의미를 효과적으로 부각하지 못하였습니다.

전면에 위치한 아이콘에 외곽선을 추가하고, 색의 차이를 두어 부각하는 방식을 택했습니다.

추가로, 하트 형태의 외곽선에 색을 추가하여 명확하게 전달될 수 있도록 했습니다.

💡 웹앱 구성의 UI

전체적인 UI를 구성하는 데 있어서, 유저의 사용 과정이 적절히 반영될 수 있도록 하였습니다.

유저는 다양한 장소의 이벤트에 부착된 QR 코드를 통해 본 서비스에 접속하게 됩니다.

이 때, 다운로드와 같은 번거로움이 없이 편하게 사용할 수 있도록 웹 앱으로 기획되었습니다.

QR 코드를 통해 서비스에 접속하는 점에서, 사용자는 모바일 디바이스를 통해 사용하게 됩니다.

그렇기에, UI의 구성이 모바일에 대응하고, 적절히 사용할 수 있는 방향으로 UI를 구성하였습니다.

터치를 통해 서비스를 사용하기 때문에, 버튼을 비롯해 상호 작용하는 컴포넌트의 크기를

기존의 웹보다 크게 설계하여 사용에 용이하도록 하였습니다.

데스크탑에 비해 작은 화면을 사용하기 때문에, 텍스트의 가독성과 배치가 중요하다고 생각했습니다.

텍스트가 가지고 있는 정보 간의 중요도를 세분화한 뒤, 중요도에 따라 크기와 위치를 배정하여

가독성을 확보하였습니다.

💡 회원가입

유저 피로도와 모바일의 입력 방식을 고려하여, 해당 파트를 디자인하였습니다.

회원가입을 적절히 분배하지 않는다면, 자칫 사용자가 회원가입이 오래 걸린다는 인상을 주어,

이로 인해 가입에 대한 피로도와 거부감을 발생시킬 수 있다고 판단하였습니다.

회원가입의 정보에 따라 과정을 세분화하는 작업을 우선적으로 진행했습니다.

각 단계에 대해 사용자가 명확히 인식할 수 있도록 하고, 완료라는 작은 보상을 제공하여, 피로도를 개선하는 방향으로 진행하였습니다.

물리적 입력을 하는 데스크탑과 달리, 모바일은 가상 키보드를 사용하여 입력을 진행하게 됩니다.

이러한 점에서, 유연한 레이아웃을 구성해야 가상 키보드로 인한 UI 변형을 막을 수 있다고 판단하였습니다.

각 단계를 간소화하여, 하단에 적절한 여백을 두는 방향으로 해결하였습니다.

💡 홈

홈 화면은 서비스의 활성화에 기여하는 중요 컴포넌트를 배치하는 방향으로 진행했습니다.

1. 이벤트 마감 시간 헤더

쇼핑몰의 세일 팝업이 마감 시, 손해를 본다는 심리를 이용해 구매 욕구를 증진시키듯,

사용자로 하여금 이벤트의 마감을 상기시키고, 보다 적극적인 활동을 이끌어낼 수 있다고 판단하여 배치하였습니다.

2. 오늘의 카드

MBTI 점수 등을 통해 사용자에게 타 사용자를 추천하는 배너 역할을 하며, 이를 통해 매칭 서비스로 자연스럽게 유도하는 역할을 합니다.

3. 하트 내역

사용자에게 현재 주고 받은 하트를 상기시켜, 서비스 활동을 촉진시키기 위한 의도로 배치하였습니다.

4. 매칭현황

타 사용자 간의 매칭을 노출시켜, 서비스 활성도를 어필하고 사용자 또한 매칭되도록 자극하여

활성화시키고자 하는 목적으로 배치하였습니다.

5. 의견 남기기

본 서비스의 현재 목적은 서비스를 통해 유저를 받아보고, 피드백을 통해 서비스를 개선시키는

것이기에 사용자가 쉽게 피드백을 남길 수 있도록 메인 화면에 배치하였습니다.

💡 아바타 & 카드

해당 주제에 있어서 "타 사용자를 어떻게 표현하는 것이 효과적인가"에 대해 많은 고민을 하였습니다.

익명을 전제하는 본 서비스의 특성에 따라, 사용자 간 제공되는 정보가

"닉네임 / 나이 / 성별 / MBTI / 자기소개" 로 제한적입니다.

각 사용자에게 주어지는 정보가 제한된 상황에서, 해당 정보를 전달하는 매개체의 중요성이

타 서비스보다 상대적으로 높은 상황이라고 판단하였습니다.

또한, 모바일의 제한된 화면에서 정보를 효과적으로 전달하기 위해서 집약된 표현이 필요하였습니다.

이를 해결하기 위해 각 성별과 MBTI에 대응하는 아바타를 만드는 것으로 진행하였습니다.

각 MBTI의 특징을 효과적으로 보여줄 수 있고, 긍정적인 인상을 만들기에 효과적이라 생각하였습니다.

또한, 아바타를 포함한 사용자의 정보를 카드의 형식으로 표현하였습니다.

작은 공간에 많은 정보를 담는 상황에서 사용자에게 낯선 레이아웃은 정보를 읽을 때 피로도를

유발할 수 있다고 생각합니다.

그렇기에 익숙한 레이아웃을 사용하는 것이 많은 정보를 집약적으로 전달하기에 적절한 방법이 될 수 있다 생각하여 진행하게 되었습니다.

💡 마치며

이러한 고민들을 담아, 본 서비스의 디자인을 진행하게 되었습니다!

곧 출시되는 서비스인 만큼 참여해보신 뒤, 많은 피드백을 주시면 감사할 것 같습니다! 감사합니다!

축제에서 “Now,Here”를 통해 특별한 인연을 만나보세요! 🎉

🌟 나우히어, 축제에서 새로운 인연을 만나보세요! 🌟

🚀 나우히어팀의 시작

안녕하세요!

이벤트 기반 소개팅 서비스를 개발하고 있는 '나우히어' 팀입니다. 😊

저희는 대학 축제에서 진행되던 '번호팅'에서 아이디어를 얻어 시작하게 되었어요.

번호팅이란 참가자들이 서로의 번호를 랜덤으로 주고받으며 새로운 사람과 연결되는 신개념(?) 소개팅인데요, 이 아이디어를 조금 더 발전시켜 축제에서만 즐길 수 있는 특별한 매칭 서비스를 만들면 어떨까 고민하게 되었습니다.

처음에는 ‘블링커(BLIND + LINKER)’라는 이름으로 시작했어요. 낯선 사람들을 연결해준다는 의미였죠. 하지만, 축제라는 한정된 시간 동안만 이루어지는 이벤트성을 강조하기 위해, 서비스 이름을 ‘나우히어(Now, Here)’로 변경하게 되었습니다. 지금, 이 순간, 바로 여기서 특별한 인연을 만나볼 수 있다는 의미를 담고 있답니다.

💡 기획 배경: 인덱스 관계와 나우히어

'인덱스 관계'라는 말을 들어보셨나요? 이는 사람을 목적에 맞춰 효율적으로 선별하고 관계를 형성하는 방식을 말합니다. 요즘 사람들은 자만추(자연스러운 만남 추구)보다 인만추(인위적인 만남 추구)를 더 선호하는 경향이 있습니다. 자신과 잘 맞는 사람을 빠르고 효율적으로 찾기 위해 체계적인 방식을 택하고 있는거죠.

나우히어는 이런 트렌드에 맞춰 MBTI 기반의 케미 점수를 제공합니다. 이를 통해 사용자는 자신과 성향이 맞는 이성을 쉽게 찾을 수 있어요. 축제라는 한정된 시간 안에서 의미 있는 인연을 맺도록 설계된 서비스로, 선택적이고 효율적인 만남을 원하는 현대인들에게 최적화된 솔루션입니다.

🎯 나우히어의 주요 특징:

• 축제 기간 한정 서비스: 축제가 끝나면 계정도 함께 사라집니다.

• 간단한 가입 절차: 나이, 성별, MBTI 등 간단한 정보만 입력하면 바로 매칭이 시작됩니다.

• MBTI 기반 매칭: 나와 성향이 잘 맞는 이성을 추천받을 수 있습니다.

• 무제한 매칭 시도: 원하는 사람이 나올 때까지 계속해서 매칭을 시도 할 수 있습니다.

👫 나우히어팀을 소개합니다!

저희 팀은 기획, 개발, 디자인 등 다양한 인력들이 모여 나우히어 서비스를 만들고 있어요.

• 백엔드 팀: 서비스가 안정적으로 운영되도록 관리하고, 데이터를 처리합니다.
  (1) 박준형 팀원 깃허브 :

  (2) 박준형 팀원 블로그 :

  (3) 박준형 팀원 링크드인 : https://www.linkedin.com/in/%EC%A4%80%ED%98%95-%EB%B0%95-1025952a9/?trk=opento_sprofile_topcard
  (4) 서희준 팀원 깃허브 :

• 프론트엔드 팀: 사용자가 쉽게 서비스를 이용할 수 있도록 화면을 디자인하고 개발합니다.

• 디자인 팀: 서비스에 적절한 UI와 UX를 구성하여 디자인을 진행합니다.

  

• 기획 및 홍보 팀: 서비스의 방향을 정하고, 사용자들에게 나우히어를 알리는 마케팅 전략을 세웁니다.

  

  
  

🎉 앞으로의 계획

저희는 9월 말에서 10월 초에 열리는 대학 축제에서 '나우히어' MVP를 선보일 예정입니다. 이번 버전은 핵심 기능에 중점을 두고 있으며, 사용자들의 피드백을 반영해 점차 발전시킬 계획입니다 🚀

축제에서 '나우히어'를 통해 특별한 인연을 만나보세요! 🎉