[2025 WINTER DEV] 에코노베이션 동아리방 현황 확인 어플리케이션 ‘WhozIn’, 규잘팀

프로젝트 소개


규잘 대표사진

굼인: 안녕하세요. WhozIn 서비스를 개발하는 규잘팀입니다.

우리 에코노베이션 동아리방은 지식의 선순환이 가장 활발하게 이루어지는 장이며, 동시에 일상 속에서 동아리 회원 간 친목이 이루어지는 중요한 공간입니다. 하지만 회원 수에 비해 동아리방 공간이 꽤 협소하여 동아리방에 왔다가 자리가 없어 되돌아가거나 오기 전에 다른 회원들에게 ‘동방에 자리 많아?’, ‘누구누구 있어?’ 라고 묻는 일이 흔했습니다.

이러한 상황이 반복됨에 따라 많은 회원들이 팀 회의나 멘토링을 동아리방 대신 도서관 등에서 진행하거나 동아리방을 잘 이용하지 않게 되었습니다. 동아리방의 가치를 알고, 또 회장단으로서 회원들이 동방에 자주 나와 다른 회원들과 친해지며 활발하게 동아리 활동을 하길 바라고 있던 저는 이러한 현실이 정말 안타까웠습니다. 동아리방이 매일 붐비는 건 아니고 가끔은 한 두명도 없을 때도 있기에 효율적으로 공간을 활용하지 못하고 있기도 했죠. 이러한 문제를 공감하고 있는 26기 팀원들과 마음을 모아 동아리방에 ‘누구 있어?’ 즉 ‘WhozIn?’을 만들게 되었습니다.

WhozIn은 에코노베이션 동아리방 현황을 실시간으로 확인할 수 있는 어플리케이션으로, 주요 기능은 동아리방에 누가, 얼마나 있는지를 확인하는 것입니다. 화면 최상단에서 현재 동아리방에 있는 인원 수를 알려주고 그 아래 리스트 형식으로 회원이 현재 동아리방에 있는지, 있다면 몇 시간째 머물고 있는지 볼 수 있습니다.

주요 기능 외에도 다양한 기능을 개발 중에 있습니다.

TF나 회장단과 같은 활동에 참여했거나 한 학기, 1년 동안 동아리방을 가장 많이 이용한 사람에게 이를 증명하는 뱃지를 이름 옆에 달아드립니다. 다양한 디자인의 뱃지를 하나씩 모으면서 회원들이 동아리 활동의 성취감과 소소한 재미를 얻길 바랍니다. 또 동아리방을 이용하다보면 학생증을 두고와 동아리방에 있는 사람들에게 문을 열어달라고 부탁하거나 함께 저녁식사를 할 인원을 찾아본 경험이 있으실텐데요. 슬랙이나 카톡 대신, 동아리방에 있는게 분명한 회원들에게만 푸쉬알림을 보내는 ‘외치기’ 기능도 준비 중입니다. 이러한 기능들을 통해 동아리방 현황 확인을 넘어 회원들이 동아리방을 사용하는 데에 즐거움을 느끼고 동아리를 더욱 활성화 하고자 노력하는 후즈인팀의 목표가 이뤄지길 바랍니다!



팀원 소개

규잘 규민 규잘 석호 규잘 영우 규잘 종민
FE/DE    규민 BE    석호 BE    영우 BE    종민


인터뷰

Q. Winter Dev 프로젝트에서 개발자로 참여한 경험을 설명해 주세요. 어떤 역할을 맡았고, 주요 기술 스택은 어떻게 구성되었나요?

A. 규잘팀의 기술 스택은 아래와 같습니다.

  • BE
    • 라즈베리파이 OS
    • Spring Boot (멀티모듈) + MySQL + JPA + JDBC
  • FE
    • React
    • PWA
    • Styled-Components
    • Figma / Illustrator

벨민: 저는 후즈인 서비스에서 동아리 방에 누가 있는지 판별하고 얼마나 접속 했는지 조회하는 기능을 맡았는데요. 실제로 구현해보니 처음에 생각했던 것과 달리 무척 복잡했습니다. 먼저 동아리 방에 있는지 없는지 판단하는 로직을 말씀드리겠습니다.

사용자는 후즈인을 이용하기 위해서는 회원가입 이후에 기기를 등록하는 과정을 거쳐야 합니다. 기기를 등록하는 과정은 기기마다 고유한 주소인 MAC 주소와 주인을 매핑하는 과정입니다. 기기 등록을 하는 이유는 다음과 같습니다.

후즈인에서는 동아리 방 내부에서 발생하는 와이파이 패킷들의 로그들을 데이터베이스에 저장하는데, 이 로그에는 노트북의 MAC 주소가 적혀있습니다. MAC 주소는 기기마다 가지고 있는 고유한 주소로, MAC 주소의 주인을 매핑한 이후에는 MAC 주소만으로 누구인지 알 수 있습니다. 이제 기기등록이 완료되고, 로그들이 수집되면 스프링부트 서버는 주기적으로 수집된 로그들을 분석해서 등록된 MAC 주소가, 로그들에 있는지 검사합니다. 로그를 분석했을 때, 등록된 MAC 주소가 포함된다면 이 기기의 주인은 동아리 방에 재실해 있다는 뜻이며 이 기기의 주인인 사용자는 동아리 방에 재실 중이라고 표시됩니다.

위에 작성한 내용은 기능 구현을 시작할 때 생각했던 로직입니다. 1차적으로 구현이 완료된 후 테스트를 해보았을 때 생각보다 예외 상황이 많이 발생한 것을 보고 이후에 로직을 수정했습니다. 기능 명세 및 요구 사항을 어떻게 설정하느냐에 따라서 예외 상황이 달라지겠지만, 저의 경우에는 아래의 요구 사항을 만족해야 하다보니 처음에 생각했던 로직을 바꿔야하는 경우가 있었습니다.

  • 연속 접속 시간 : 동아리 방에 한 번 재실했을 때부터, 동아리 방에 재실하지 않을 때까지의 시간
  • 하루 접속 시간 : 하루 동안 동아리 방에 얼마나 재실했는지를 나타내는 시간
  • 전체 누적 접속 시간 : 마지막으로 동아리 방에 전체적으로 얼마나 재실했는지 나타내는 시간

이 세 가지 시간을 계산하고, 다음날로 넘어가는 자정이 되는 순간에 동아리 방에 재실해 있으면 하루 접속 시간을 초기화 해줘야 하기 때문에 처음에 작성했던 코드를 많이 수정했습니다. 이 기능을 구현하면서 완벽하지는 않지만 어느 정도 관심사의 분리를 진행했고 실제로 적용해볼 수 있어서 좋았습니다. 동방에 재실했는지 판별하는 로직에 대해서 추가적으로 궁금하신 분이 있으시다면 연락주시면 알려드리겠습니다!


Q. 프로젝트를 하면서 어떤 문제를 겪었나요?

A. 석오: 후즈인은 와이파이와 밀접한 관련이 있는 프로젝트입니다. 기획 초기엔 컴퓨터 네트워크에 대한 이해도가 깊지 않았기 때문에 막연히 될 것이라고만 생각했습니다. 하지만 데브가 끝나기 전까지 요구사항에 대한 한계점이 꾸준히 나왔고, 이러한 기술적인 한계를 극복하기 위해 간단한 설계를 포기하거나, 기획을 변경하는 등의 일이 잦았습니다.


Q. 프로젝트를 하기 전 후 달라진 점이 있다면?

A. 벨민: 저는 지금까지 개발을 해오면서, 기능 구현을 중심으로 개발을 진행해왔었습니다. 하지만 이번 프로젝트에서 멀티 모듈을 접하고, 협업을 해오면서 기능 구현이 전부가 아님을 알게되고 개발을 할 때 마음가짐에 대해서 스스로 되돌아볼 수 있었습니다. 애플리케이션을 만드는 이유는, 현실의 문제점을 소프트웨어로 해결하기 위함입니다. 만약 기능 구현에만 초점을 두고 애플리케이션의 안정성 및 무결성을 생각하지 않는다면 나중에 예외 상황이 발생하였을 때 일을 두 번해야 하는 상황이 발생할 것입니다. 이는 곧 시간적 비용과 노동력이 한 번 더 소모됨을 의미합니다. 애플리케이션의 상태가 안정되고 무결한 상태여야 서비스의 사용자들도 편하고 개발자도 초기의 비용이 들지만 추후에 손쉽게 유지보수를 할 수 있을 것입니다. 개발을 할 때는 항상 내가 맡은 기능에 대해서 사이드 이펙트는 없는지 예외 상황은 없는지 등을 생각해야 합니다. 더 나아가서 프로젝트 초기에 애플리케이션 전체적 정상적인 상태인지 확인할 수 있는 수단 및 예외가 발생했을 때 확인할 수 있는 수단을 마련한다면 개발자는 이후에 에러 분석 및 트러블 슈팅에 리소스를 크게 들지 않고 유지보수를 할 수 있을 것입니다.


Q. 프로젝트를 시작하는 팀에게 전해줄 꿀팁을 말해주세요!

A. 앵우: 에코노 프로젝트를 하면서 성공과 실패에는 신경 쓰지 말고 새로운 시도와 도전을 해보셨으면 좋겠습니다! 각자 공부하면서 가졌던 고민이나 인상 깊었던 것들이 있을 것이라고 생각해요. 그걸 나중에 현업에서 경험하는 것으로 미루지 말고 프로젝트를 통해서 경험해 보는 시간을 가질 수 있으면 좋을 것 같아요. 동아리 환경 상 하고자 하는 것에 같이 이야기를 나눌 수 있는 사람들도 있고 어떠한 기술에 대해서 도전하는 과정 속에서 분명 다른 많은 것들을 공부할 수 있게 되어서 시야가 넓어지게 될 거예요! 만약 본인이 어떤 성장을 할 수 있는지 잘 모르겠다면 에코노베이션 깃허브에서 선배들의 소스코드를 참고하거나 자신만의 레퍼런스를 참고할 수도 있을 것 같고 주변에 현재 이런 고민이 있는데 어떤 걸 공부해 보면 좋을까요? 이렇게 질문해 보는 것도 좋을 것 같아요~ ㅎㅎ 이거는 꼭 개발자나 다른 분야뿐만 아니라 무언가를 하기 전에 내가 어떤 것들을 얻어가고 싶은지 충분히 고민해보시면 좋을 것 같습니다. 그리고 이러한 개인의 목표들을 하나의 팀에 잘 녹여내야 해요! 저는 끝까지 포기하지 않고 마무리만 잘하면 해냈다고  생각하거든요. 그래서 모두 주저하지 않으셨으면 좋겠습니다!


Q. 프로젝트 개발 중 어려움을 겪은 경험이 있나요? 어떻게 해결했으며, 그 과정에서 얻은 교훈은 무엇인가요?

A. 석오: 후즈인은 동아리 방의 재실 인원을 알아내는 서비스입니다. 이를 알아내기 위해선 출입증을 통해 기록을 관리하는 것이 가장 간단하다고 생각하지만, 모든 회원에게 들어올때마다 카드를 찍도록 강제할만큼 재실 인원을 알아내는 것이 가치있다고 생각하진 않습니다. 그렇다면 회원이 동아리방에 왔을때 자동으로 알 수 있어야 하는데요, 처음엔 RFID, 블루투스 비콘을 생각했습니다. RFID는 회원들이 무조건 칩을 들고 다녀야 한다는 단점이 있고, 블루투스 비콘은 회원이 백그라운드에서도 위치 정보를 허용하도록 해야 합니다. 따라서 후즈인은 와이파이에 연결한 기기를 통해 구현하기로 했습니다.

기본 원리

먼저, 와이파이에 연결된 기기는 아이피와 해당 와이파이에 대한 맥 주소를 가집니다. 이때 와이파이 관리자 API를 사용하면 접속 중인 기기들의 내부 아이피, 맥을 가져올 수 있습니다. (이 방법은 한계점이 있습니다) 그렇다면 후즈인은 어떤 기기가 어떤 회원의 것인지 알아야 하는데요, 아이피는 재할당 시 변경될 가능성이 높기 때문에 웬만해선 변경되지 않는 맥을 사용하기로 하였습니다.

이를 위해 후즈인은 사용자의 맥을 알아내야 합니다. 사용자가 직접 입력하기엔 UX가 떨어지며, 잘못 입력할 가능성이 있기 때문에 후즈인이 자동으로 알아낼 수 있는 방법을 모색해야 했습니다.

먼저 아이피나 맥은 모든 환경의 응용 애플리케이션이 일관적인 방법으로 알아낼 수 있는 정보가 아니기 때문에 사용자의 기기에서 쉽게 알아낼 수는 없었습니다. 하지만 서버에서 요청에 대한 아이피를 알아낼 수는 있는데, 내부 ip를 알아야 관리자 api에서 얻어낸 맥 주소를 알 수 있기 때문에 서버는 사용자가 연결할 와이파이에 연결되어 있어야 합니다. 따라서 간단한 서버를 위한 라즈베리파이를 구성하고, 사용자가 요청을 보내면 맥주소를 알아내는 api를 만들었습니다.

사실 사용할 수 있는 와이파이는 여러 개이다.

지금까지는 와이파이가 1개이며 동아리에서 관리하는 와이파이라는 가정이었습니다. 사실 와이파이는 학교에서 제공하는 JNU, eduroam, 그리고 에코노 와이파이인 ECONO까지 총 3개입니다. 이것이 문제되는 이유는, 먼저 맥 주소는 대부분의 운영체제에서 기본적으로 randomized Mac 을 적용합니다. 이는 기기가 자신이 가진 네트워크 인터페이스 카드의 맥 주소를 사용하지 않고 가상 맥 주소를 사용하는 것인데요, 와이파이마다 다른 맥주소를 적용하게 됩니다. 그렇다면 사용자의 모든 맥 주소를 알아내기 위해 사용자는 3개의 와이파이에 연결하는 불편한 과정을 거치게 되지만, 어쩔 수 없는 기획 변경이 필요하였습니다.

두 번째 문제는 JNU, eduroam은 학교의 와이파이이기 때문에 와이파이 관리자 api를 사용할 수 없다는 것입니다. 기기 정보 리스트를 얻기 위해 다른 방법이 필요했는데, 기기가 와이파이에 연결할 때 발생하는 MDNS 프로토콜을 이용하였습니다. mdns는 네트워크에 연결된 장치들이 DNS 서버 없이도 서로의 이름과 아이피를 알아낼 수 있도록 발생하는 프로토콜로 한 서브넷에서만 동작하지만 동아리 방 근처의 라우터에선 mDNS 리피팅이나 멀티캐스트 라우팅 기능을 지원하기 때문에 서로 다른 서브넷에 연결된 기기들의 mdns 패킷을 라즈베리파이 서버가 모두 받을 수 있었습니다. 이 mdns 패킷에는 mac도 담겨있기 때문에 관리자 api의 대안이 될 수 있었습니다.

Mixed Content

사용자가 후즈인 서비스에 들어가서 라즈베라파이로 로컬 ip로 요청하면 라즈베리파이는 요청의 로컬 아이피를 통해 맥 주소를 반환한다고 했습니다. 그리고 후즈인 서비스를 제공하는 메인 서버는 https로 서빙되고 있었고, 라즈베리파이 서버는 http였습니다. 하지만 오늘 날 대부분의 브라우저는 https→http요청을 금지하고 있었기 때문에 Mixed Content 정책에 의해 요청이 불가하였습니다.

이를 해결하기 위해 4가지 방법을 시도해보았습니다.

  1. 메인 서버를 http로 변경

    임시방편에 가깝지만, 데브가 얼마 남지 않은만큼 시도해볼만한 가치가 있었습니다.

    하지만 http → http로 요청하여 Mixed Content 정책에 걸리지 않게 되자 이제 PNA CORS가 발생하게 되었습니다.

    이 예외를 간단하게 설명하면 공인 아이피에서 내부 아이피로, 내부 아이피에서 로컬 호스트로 요청하지 못하게 막는 브라우저의 정책인데요, 외부에 공개되지 않는 서버들에 요청을 보내서 해킹하는 것을 방지하기 위해 만들어진 정책입니다.

    이는 https→https 요청일 경우 발생하지 않습니다.

  2. 라즈베리파이 서버도 https로 서빙

    1번의 한계점으로 인해 라즈베리파이 서버도 https로 서빙하고자 했기때문에 우선 ssl 인증서를 발급 받아야 합니다.

    브라우저는 자체 서명된 ssl이 아닌 공인 ssl인증서를 요구합니다.

    따라서 공인 ssl 인증서를 발급 받으려면 도메인이나 아이피(주로 도메인)가 글로벌 dns에 등록이 되어있어야 하는데요, 이때 로컬 아이피는 등록할 수 없기 때문에 https로 서빙이 불가능했습니다.

  3. 로컬 DNS 구성

    먼저 naver.com과 같은 사이트에 들어가려고 하면 대략적으로 아래와 같은 절차를 거치게 됩니다.

    1. 내 컴퓨터에 해당 도메인으로 캐시된 아이피가 있는지 확인
    2. 없으면 와이파이가 제공하는 DNS 서버로부터 아이피를 찾음
    3. 없으면 공용 dns 서버로 가서 아이피를 찾음

    위 정보를 토대로, 2번 문제를 해결할 아래의 방법을 알아냈습니다.

    1. 먼저 whozin.com으로 공인 ssl을 발급 받습니다.
    2. 로컬 네트워크에 dns 서버를 구성하며, whozin.com의 하위 도메인인 rasp.whozin.com 도메인이 192.168.0.9(라즈베리파이)를 가르키도록 저장합니다.
    3. 사용자의 브라우저가 rasp.whozin.com으로 요청하면 우리 dns서버로부터 192.168.0.9를 받게됩니다. (사용자가 우리가 구성한 dns 서버를 이용할 수 있도록 선수 작업이 필요하지만 생략하겠습니다.)
    4. 그리고 사용자의 브라우저는 라즈베리파이 서버와 핸드셰이킹을 하며 발급 받아놓은 공인 ssl를 받아옵니다. 상위 도메인으로 ssl을 발급 받은거라 로컬 네트워크의 도메인에서도 유효하게 사용할 수 있습니다.

    이제 공인 ssl이 있으니 내부를 https로 요청 가능해집니다.

    하지만 이 방법은 복잡하기 때문에 구현하지 않았습니다.

  4. 기기 등록 페이지를 http로 서빙 로컬 아이피로 요청하는 것은 기기 등록 페이지에서만 이루어집니다. 따라서 기기 등록 페이지만 라즈베리파이 서버에서 http로 서빙하였으며, mixed content policy를 준수하고, pna CORS를 해결할 수 있었습니다.

결론

위와 같은 문제들 이외에도 많은 기술적인 문제들이 발생했었고, 그럴 때마다 요구사항을 변경하고 싶은 생각이 많이 들었습니다. 하지만 실사용을 위해 최대한 기획을 변경하지 않으려고 노력하고, 원활한 유지보수를 위해 여러 대안을 찾아보았기 때문에 후즈인의 핵심 가치가 변하지 않고 여기까지 올 수 있었던 것 같습니다. 충분히 고려하는 것이 정말 중요하다고 느꼈습니다.


Q. 본인 팀만의 특별한 협업 방식이 있나요? 있다면 소개해주세요.

A. 앵우: 규잘팀의 그라운드룰 중에서 좋다고 생각한 것 2가지를 공유해 드리겠습니다.

  1. 다 같이 논의를 해야 하는 부분은 반드시 슬랙이나, 카톡을 통해서 이야기를 한다.
    • 의도는 프론트/백엔드 두 분야가 있는 만큼 서로 진행 상황에 있어서 알고 있는 것에 대한 간극을 최소화하기 위해 두었습니다.
    • 이 룰 덕분에 팀원 4명 모두 소통에 있어서 항상 함께 적극적으로 이루어질 수 있었던 것 같고 덕분에 프로젝트를 하면서 서로 협의되지 않은 부분으로 인한 갈등은 없었습니다.
    • 그리고 어느 협업이든 이 룰이 있으면 소외되는 사람이 없어 좋은 것 같아요. 저는 다른 곳에서 협업을 하면서 의도치 않게 일부 팀원과만 진행에 대해서 이야기를 나누다가 다른 팀원에게는 함께 의논되지 않은 부분이 생겼었는데 그때 이 룰이 생각나면서 아차싶더라구요.
  2. 팀 내부 사정은 외부로 발설하지 않기.
    • 팀 내 신뢰도가 쌓이고 서로 보듬어주며 더 돈독해질 수 있었던 것 같아요!

그리고 프로젝트 진행 과정을 정말 꼼꼼하게 문서화를 했는데요. 후즈인 프로젝트가 실사용 프로젝트인 만큼 누군가 이어서 하거나 유지 보수할 수 있음을 고려하고 초기에 오픈소스화도 생각하였기 때문에 확장성 을 정말 많이 고려하였습니다. 그래서 이 프로젝트를 진행하기 위해 알아야 할 배경지식, 팀 컨벤션 등을 노션에 잘 정리해놓았고 후즈인 1기가 프로젝트를 하면서 겪었던 문제와 해결 과정 그리고 앞으로 해결이 필요한 문제들을 정말 꼼꼼히 기록하였습니다. 이거는 정말 저희 팀이 노력하고 고생했다고 생각해서 팀원들을 칭찬해 주고 싶어요!

마지막으로 프로젝트를 하면서 기술적 문제를 많이 맞닥뜨렸던 만큼 문제를 두고 팀원들과 함께 고민하는 시간이 정말 많았는데요! 이 과정 속에서 논리적인 근거를 두고 생각을 말하고 서로 의견을 존중할 뿐만 아니라 자신이 알고 있는 것과 공부하는 것을 나누며 지식의 선순환이 일어나는 느낌을 받았습니다! 그리고 문제 해결의 답이나 합의점을 찾을 때까지 오랫동안 끈기 있게 회의 시간을 가지는 것도 멋졌던 것 같아요!

아 그리고 정말 마지막으로 노션을 사용하면서 팀원의 칸에 각자의 페이지를 만들어 공부한 거나 작업 일지를 정리하였는데 프로젝트를 하면서 다른 노션 페이지를 사용하지 않아도 되고 서로 공유할 수도 있어서 좋았습니다. 그리고 귀엽습니다..

규잘팀 노션 페이지


Q. 프로젝트의 주요 목표와 성과는 무엇이었고, 이를 달성하기 위해 어떤 전략을 사용했나요?

A. 굼인: 기획자 질문이긴 하지만 프론트엔드와 디자인 면에서도 답변할 수 있을 것 같습니다. WhozIn을 만들 때 제가 가장 많이 고려한 건 앱의 접근성입니다. WhozIn 기획은 실시간 현황을 보여주는 서비스입니다. 그렇기에 실시간으로 간편하게 정보를 확인할 수 있어야하며, 높은 정확도에서 비롯한 정보의 신뢰성이 중요합니다.

동아리방에 가기 전 몇 명 있는지만 빠르게 확인하고 싶은데 핸드폰으로 들어갔더니 UI가 영 보기 불편하거나, 동아리방에 5명 있다고 해서 자리가 넉넉할 것이라 생각하고 왔더니 실제로는 10명 이상 있다면… 굉장히 곤란할 뿐 아니라 후즈인의 정보를 신뢰하지 못하게 되며 결국은 후즈인을 사용할 이유가 없어지겠죠. 후즈인을 사용하지 않는 회원은 우리가 제공하는 정보에 집계되지 않고 그 정보는 정확도가 떨어지는 악순환이 반복될 수 있습니다. 거의 모든 회원이 후즈인을 실사용해야 서비스의 기획 의도에 맞게 됩니다.

빠르고 간편하게 사용하기엔 앱만한 게 없지만, 회원들이 사용하는 기기의 다양한 OS를 모두 커버하려면 각 운영체제에 맞는 언어들을 배우고 각기 다른 개발을 해야 합니다. 자바스크립트(React)를 유일하게 사용하던 저에겐 거의 불가능에 가까웠습니다. 빠르게 실사용자를 모으고 운영을 하기에는 앱스토어와 플레이스토어에 앱을 등록하는 것 역시 큰 장벽이었습니다.

그래서 제가 선택한 것은 PWA 개발입니다. PWA이란 Progressive Web App의 줄임말로, 점진적으로 네이티브 앱의 형태로 발달하는 웹앱입니다. 웹과 앱의 장점을 모두 갖고 있는 웹앱이라고 할 수 있어요. 별도 설치 없이 주소로 접속할 수 있지만 홈화면에 추가를 해놓으면 앱과 같이 아이콘을 눌러 바로 접속할 수 있습니다. 웹이니 만큼 별도의 업데이트 없이도 항상 최신 서비스를 사용할 수 있으며 어느 OS든 사용할 수 있는 높은 호환성도 큰 장점입니다. 웹앱의 한계였던 푸쉬 알림도 이제는 거의 자유롭게 구현 가능하고요. 보통의 웹 개발과 똑같지만 간단한 설정만 추가하면 완성이 되고, 복잡한 기능이나 무거운 데이터가 없으니 서비스가 돌아가는 데에 무리도 없어 PWA는 저희 프로젝트에 가장 적합한 방식이라고 생각합니다.

위에서 백엔드 개발자 분들이 서비스의 핵심 로직을 잘 설명해주었는데요, 더욱 정확한 정보를 얻기 위해서는 한 회원이 사용하는 다양한 기기와 3개의 와이파이에 대응하는 n*3개의 MAC 주소를 수집해야합니다. 초기 기획에서는 등록 단계에서 MAC 주소를 회원들이 직접 입력하게 하는 방식을 고려했으나 여러분도 알다시피 구성이 복잡하고 길어서 직접 보면서 치기엔 꽤 번거롭습니다. 어디서 MAC 주소를 확인할 수 있는지도 익숙하지 않을 수 있고요. 등록이 쉽고 간단해야 정확한 정보 수집을 기대할 수 있는데 서비스 사용의 가장 초기 단계부터 사용자로 하여금 번거롭다, 어렵다라는 생각이 들게 한다면 좋은 서비스라고 하긴 어려울 것입니다. 혹은 중간에 이탈 우려도 있고요.

후즈인 프로토타입

위 화면은 현재 기기등록 단계의 UI입니다. MAC 주소를 별도로 입력하는 창이 보이지 않죠? 백엔드 석호님의 노력 끝에 와이파이 연결만으로도 자동으로 MAC 주소를 받아올 수 있게 되었습니다. (물론 자동으로 받아오는 게 오래 걸린다면 사용자가 직접 입력할 수도 있습니다.) 개발진에게 가장 핵심이 되는 정보이자 서비스의 토대가 되는 데이터를 수집하는 과정을 최대한 쉽게 만들어 사용자에게 부담을 덜어냄과 동시에 중요한 데이터를 여백없이 얻어내고자 기획한 결과였습니다.

실사용자가 중요한 서비스인 만큼 베타 버전을 빠르게 배포하여 VOC를 수집하고, 이를 통해 서비스를 발전시켜 나가고자 하였으나, DEV 준비 그리고 이후 각자의 일정 때문에 배포 일정이 조금 밀리게 되었습니다. 🥲

팀원들과 회의를 통해 Term 2 개발에 박차를 가하고 있고, 동방 현황 조회라는 핵심 기능과 카카오 로그인을 통한 간소화된 회원가입 절차가 준비된 베타 버전을 최대한 빠른 시일 내에 오픈할 예정입니다. 또한 피드백을 반영하고 부가 기능까지 지원하는 정식 서비스도 29기 신입회원들이 들어오기 전 마무리 해 볼 생각입니다.

개발하면서 팀원들끼리 ‘이거 아무도 안 쓰면 어떡하지’ 라는 걱정을 자주 하곤 했습니다만, 정말 감사하게도 많은 에코노 회원분들께서 후즈인 서비스에 관심을 갖고 실사용 의지를 보여주셔서 힘을 얻고있습니다. 앞으로도 WhozIn에 많은 관심 부탁드립니다!



정성스러운 인터뷰 답변 감사합니다! 지금까지 에코노베이션 동아리방 현황 확인 서비스를 개발한 규잘팀의 인터뷰였습니다. 앞으로도 WhozIn이 에코노베이션의 동아리방 문화에 긍정적인 영향을 미치길 기대합니다 🙌 🩷