[1주차 크루 미션 — 기획 & 팀 소개 발표] Bello 미션 제출합니다.#1
Conversation
Gyuil-Hwnag
left a comment
Gyuil-Hwnag
left a comment
There was a problem hiding this comment.
Bello팀 (하로, 엘리, 엠버) 안녕하세요~
이번 미션을 함께하게 된 두루라고 합니다. 잘부탁드립니다!
미니 프로젝트에 대해서 살펴보면서, 어떠한 고민이 있었는지 알 수 있었습니다~
개인적으로 저도 사내 서비스를 사용했을 때의 불편했던 부분들이다보니 몇가지 내용들이 와닿았던 것 같아요😀
저도 직접 서비스를 사용해보고 필요한 기능들에 대해서 프로토타입 + 기획으로 제안을 하여, 개발 까지 나가고 지표도 잘나와서, 서비스의 주요기능으로 까지 자리잡게 되었던 경험들이 있었는데 서비스를 사용하면서 불편했던 포인트에서 시작을 한 부분이 저의 접근과 비슷하다보니 더욱 더 선정을 했던 이유에 대해서 와닿았던 것 같습니다~
내용을 살펴보면서 고민해보시면 좋을만한 내용들 코멘트를 달았으니 확인해주시면 좋을 것 같습니다.
궁금한 점이나 논의하고 싶은 내용이 있으면 언제든 DM 주세요! 🙏
화이팅입니다💪
| # Week 1 보고서 — Bello | ||
|
|
| ### 4. 구현 방식 결정 | ||
| - 초기에는 NFC 태그 시 앱 자동 실행 방식, 백그라운드 출석 처리 방식 등을 함께 고려했다. | ||
| - 하지만 구현 가능성과 안정성을 고려해, 앱 실행 후 NFC 태그를 인식하여 출석 처리하는 방식” 으로 최종 방향을 결정했다. |
There was a problem hiding this comment.
NFC 기반외에 다른 방법들도 여러가지가 있었을텐데, NFC를 선택하시게 되었던 이유가 있었을까요~?🤔
어떤 과정을 거쳐서, NFC 방식이 더 좋을 것 같다고 생각이 드셨는지가 궁금합니다!
There was a problem hiding this comment.
기존 방식의 가장 큰 문제는 출석 버튼을 누르기 위해 특정 와이파이에 연결되어 있어야 하고, 네트워크 상태에 따라 출석이 원활하지 않을 수 있다는 점이라고 생각했습니다. 그래서 이 문제를 해결할 수 있는 방법으로 GPS, RFID, NFC를 고려했습니다.
먼저 GPS는 실내에서 정확도가 떨어질 수 있고 위치 기반 인증만으로는 실제로 출석 지점에 도착했는지를 명확히 판단하기 어렵다고 생각했습니다.
RFID도 출석 인증에 사용할 수 있는 기술이라고 생각했습니다. 다만 일반적인 RFID 방식은 별도의 카드나 태그를 사용자에게 지급하거나, 이를 읽기 위한 전용 리더기 같은 하드웨어가 필요할 수 있습니다. 사용자 입장에서는 관리해야 할 수단이 많아져서 번거롭고, 관리자 입장에서는 개개인에 대한 부가적인 관리가 필요하여 불편할 거라는 생각이 듭니다. 반면 NFC는 스마트폰에 기본적으로 탑재된 경우가 많기 때문에, 사용자가 이미 가지고 있는 스마트폰을 리더기로 활용할 수 있다는 점이 MVP 관점에서 더 적합하다고 판단했습니다.
또한 RFID는 수 센티미터부터 수십 미터까지 먼 거리에서도 통신을 할 수 있지만, NFC를 사용할 경우 사용자는 특정 위치에 부착된 NFC 스티커에 스마트폰을 직접 가까이 대야만 출석을 할 수 있습니다.
그리고 비용 측면에서 NFC가 저렴하기 때문에 NFC 태그 방식에서 가장 염려되는 병목 현상을 해결하기 위해 많은 기기를 두는 것에도 문제가 없습니다.
구현 측면에서도 NFC 스티커와 스마트폰만 있으면 빠르게 기본 흐름을 구현하고 테스트할 수 있어 가장 적합한 기술이 NFC라고 판단했습니다.
There was a problem hiding this comment.
오호 그렇군요~
NFC의 경우 말씀해주신대로, 장점들이 있을 것 같군요!
여러 타 팀들에서도 남겨주었던 병목 현상에 대해서는 어떻게 해결할지도 한번 고민을 해보는 것도 좋겠어요
왜냐하면, 단순하게 NFC 의 갯수를 늘린다가 방법이 아닐 수도 있겠다는 생각도 들었습니다~
하나의 예시로 들어볼 만한 해결 방법들이 있을 것 같아요
NFC 태그를 찍는다. ->
API 호출을 위한 큐에 쌓인다. ->
해당 큐에 쌓였다고, 사용자에게 노티를 알린다. ->
다음 사람이 NFC 태그를 찍는다. -> ... ->
API 호출시 NFC를 태그한 타임을 보내서, 해당 시간을 기록하게 한다. ->
API 요청이 완료가 되면 사용자에게 노티를 준다. / API 요청이 실패하면 앱에서 버튼으로 재전송등을 가능하게 한다.
- 큐에서는 작업이 쌓이면 API 호출들을 실행한다.(사용자가 앱을 종료해도 실행이 보장되도록 하는 여러가지 방법들이 있겠어요)
| ### 5. MVP 범위 설정 | ||
| - 완성도 높은 출석 서비스를 만드는 것보다, NFC 기반 출석 방식이 실제로 동작 가능한지 빠르게 검증하는 것을 목표로 삼았다. | ||
| - 이에 따라 MVP 범위를 다음과 같이 최소화했다. | ||
| - NFC 지원 여부 확인 | ||
| - NFC 태그 인식 | ||
| - 태그 값 읽기 | ||
| - 출석 요청 전송 | ||
| - 출석 결과 표시 |
There was a problem hiding this comment.
빠른 MVP에 맞게 범위 선정해주신 내용 아주 좋네요👍
한가지 생각이 든 내용이 있었어요~
사실상 해당 서비스는 MVP가 끝나면 더 확장이 가능할까? 라는 생각이 들었는데, 이 부분에 대해서 어떤 아이디어가 있으실까요??
There was a problem hiding this comment.
MVP 이후 확장 가능성에 대해서는 저희도 고민해보았고, 단순히 NFC 태그를 읽는 기능에서 끝나는 것이 아니라 실제 출석 서비스에 가까워질 수 있도록 몇 가지 확장 방향을 정리해두었습니다.
- 서버 API 연동
우선 MVP 단계에서는 Android 앱에서 NFC 태그를 인식하고, Firebase에 출석 정보를 저장하는 방식으로 빠르게 핵심 흐름을 검증하려고 합니다. 이후에는 Firebase 저장 로직을 서버 API 호출 방식으로 변경하여, 실제 출석 시스템과 연결 가능한 구조로 확장할 수 있다고 생각했습니다. - NFC 출석 전용 API 추가
또한 기존 출석 API를 그대로 사용하는 것이 아니라, NFC 출석 전용 API를 서버에 추가하는 방향도 고려하고 있습니다. 현재 방식이 사내 Wi-Fi 검증에 의존하고 있다면, 이후에는 NFC 태그 기반으로 출석을 처리할 수 있는 별도의 API를 두어 더 독립적인 출석 흐름을 만들 수 있을 것 같습니다. - 사용자 인증 연동
로그인 사용자 정보와 NFC 태그 기록을 연결하여 누가 출석했는지 정확히 식별할 수 있습니다. - 태그 위치 관리
강의장, 캠퍼스, 층별로 NFC 태그를 관리하면, 사용자가 실제 지정된 위치에서 태그했는지 검증할 수 있고, 출석 흐름도 더 정확하게 만들 수 있습니다. - 예외 상황 처리
예외 상황 처리도 필요하다고 보았습니다. 실제 사용 환경에서는 네트워크 실패, 잘못된 태그 인식, 중복 태그, 서버 오류 등이 충분히 발생할 수 있기 때문에, 이런 상황을 앱에서 안정적으로 처리하는 기능도 확장 대상에 포함했습니다. - 기존 기능 확장
추가로 기존 버튼식 출석 기능과 NFC 출석 기능을 함께 사용할 수 있도록 구현하는 것도 고려하고 있습니다. 이렇게 하면 NFC 기능을 도입하더라도 기존 출석 흐름을 완전히 대체하지 않고, 상황에 따라 함께 활용할 수 있을 것 같습니다. - iOS 기반 개발 확장
더 나아가 Android에서 검증한 흐름을 iOS 환경에도 적용하여 더 많은 사용자 환경을 지원하는 방향으로 확장할 수 있습니다. - 보안 강화
마지막으로 보안 측면에서는 단순 태그 ID만 사용하는 방식에서 끝나지 않고, 토큰, 만료 시간, 서버 검증 방식 등을 적용해 대리 출석이나 태그 복제 가능성을 줄이는 방향으로 고도화할 수 있다고 생각했습니다.
There was a problem hiding this comment.
오호 그렇군요~ 정말 출석을 위한 서비스이겠군요!
말해주셨듯 여러가지 고민한 포인트들이나, 케이스별 대응은 필요하겠지만 빠르게 검증할 수 있는 부분이겠네요~
NFC 출석 전용 API 추가
ㄴ 이 부분은 가능할지 한번 확인해봐야 할 것 같습니다! API 를 풀어줬더니 악용하는 사용자들이 있을 수 있어서요ㅎㅎ
(그럴일은 없겠지만요...)
| - 어떤 상황에서: 등/하교를 할 때 | ||
| - 어떤 불편을 겪는가: 특정 와이파이에 연결해야만 출석 기능을 사용할 수 있는데, 연결이 원활하지 않거나 오류가 발생하는 경우 UI가 정상적으로 표시되지 않아 출석/하교 버튼을 누르지 못하는 상황이 자주 발생한다. | ||
|
|
There was a problem hiding this comment.
특정 Wifi 에서만 사용이 가능하다보니, 네트워크 환경등에 따라서 여러가지 제약이 있겠군요~
여기서 한가지 힌트를 또 얻어볼 수가 있을 것 같았어요!
특정 Wifi 에서만 사용이 가능하다는 것이라면, API 자체가 사내망 IP가 아니면 제한이 되어 있을 수 있는데 이 부분에 대해서 사전 조사도 필요할 것 같다는 생각이 들었습니다💪
힌트로는 NFC 로 한다고 해도 출석을 하려면 출석 API 를 호출해야 하다보니, 결국에는 기기에서 사내망 Wifi 가 연결되어 있어야 출석이 가능해지겠다는 점이겠어요
사용자가 재대로 출석을 하려면 NFC 태그 전에 사내망 연결을 확인하고 이상이 없는지, 확인을 한 이후에 태깅을 해야지 출석이 가능해지겠군요🥲
그렇다면 여기서도 사내망 이슈는 비슷하지 않을까 싶었어요!~
There was a problem hiding this comment.
이 부분은 저희도 먼저 확인이 필요하다고 생각했습니다.
현재 출석/퇴실 기능이 특정 Wi-Fi 환경에서만 동작하는 이유는, 사용자가 실제로 해당 장소에 있다는 것을 확인하기 위해 사내망 IP를 하나의 검증 조건으로 사용하고 있기 때문이라고 판단했습니다.
확인해본 결과, 퇴실 과정에서는 현재 연결된 Wi-Fi가 맞는지를 확인하는 API를 서버로 보내고, 그 결과에 따라 UI를 띄우는 방식으로 동작하고 있었습니다. 따라서 기존 출석 API를 그대로 사용한다면, NFC를 활용하더라도 결국 출석 API 호출 시점에 사내망 Wi-Fi 연결이 필요할 가능성이 있습니다.
즉, 기존 출석 API를 그대로 호출하는 구조라면 NFC 태그 전에도 사용자가 사내망 Wi-Fi에 정상적으로 연결되어 있는지 확인해야 하고, 이 경우 말씀해주신 것처럼 네트워크 환경에 따른 제약은 그대로 남을 수 있다고 생각합니다.
다만 전체 API가 모두 사내망 IP에서만 접근 가능한 것은 아니고, 장소 검증이 필요한 특정 API만 사내망 IP 조건을 두고 있는 것으로 보였습니다. 그래서 NFC 방식에서는 기존 출석 API를 그대로 사용하는 대신, NFC 태그를 장소 검증 수단으로 활용하는 별도 출석 API를 만들면 이 문제를 줄일 수 있다고 생각했습니다.
There was a problem hiding this comment.
오호 그렇군요~
사실 있으면 좋은 서비스이자 기능이라서, 명확한 장점만 있긴 하네요👍
그치만, 그만큼 사내망에 얽혀있으니 사전조사가 확실히 되어야 MVP 개발에 차질이 없겠군요
| ### 솔루션 (한 줄) | ||
| - 특정 와이파이를 사용하지 않고 NFC를 통해서 출석할 수 있도록 만든다. |
There was a problem hiding this comment.
이 부분은 위에서 남겨둔 코멘트와도 연관이 있을 것 같아서, 사전 조사가 필요할 듯 싶습니다~~
https://github.com/woowacourse/android-mini-projects/pull/1/changes#r3318851169
There was a problem hiding this comment.
이 리뷰에 대해서는 아래의 코멘트에 포함되어 있습니다!! 🫡
https://github.com/woowacourse/android-mini-projects/pull/1/changes#r3331846478
| |---|---| | ||
| | Android Native (Android Studio) | NFC는 단말기의 하드웨어 기능과 직접적으로 연결되는 기능이기 때문에, 플랫폼 제약이 적고 안정적으로 제어할 수 있는 Native 환경이 적합하다고 판단하였다. 또한 Android는 NFC 관련 API 지원 범위가 넓고 테스트 환경 구축이 비교적 자유로워, 빠른 프로토타입 구현과 검증에 유리하다고 판단하였다. | |
There was a problem hiding this comment.
오호 그렇군요~👏
개인적으로 선택하지 않은 옵션과 기술 / 플랫폼의 선택 근거에 대해서 조금 크게 와닿지 않았던 것 같아요🥲
현재 MVP 만 살펴보았을 때는 KMP, Flutter, RN 도 라이브러리등을 통한다면 충분히 지원하는 것이 있지 않을까 싶었습니다!
- https://github.com/SEAbdulbasit/NFCReader-KMP
- https://pub.dev/packages/nfc_manager
- https://github.com/revtel/react-native-nfc-manager
이유에 Android 플랫폼에 대한 이해도와 익숙함을 얘기했다면, 좀 더 와닿을 수도 있었겠어요~
그치만, 이도 Kotlin, Compose 라는 과정을 학습해 온 저희이기 때문에 KMP + CMP 라는 옵션도 있겠다는 생각이 들었습니다💪
There was a problem hiding this comment.
피드백 감사합니다, 두루!!
말씀해 주신 것처럼 저희가 Kotlin과 Compose에 익숙하기 때문에 KMP + CMP도 충분히 고려해볼 만한 선택지라고 생각했습니다. 특히 이후에 iOS까지 확장하거나, 하나의 코드베이스로 여러 플랫폼을 지원해야 하는 상황이라면 멀티플랫폼 접근이 매력적일 수 있다고 판단했습니다.
다만 이번 미니프로젝트의 핵심 목표는 완성도 높은 멀티플랫폼 앱을 배포하는 것보다는, “NFC 기반 출석 방식이 기존 방식보다 실제로 더 편리한가?”라는 가설을 빠르게 검증하는 데 있다고 보았습니다.
이 관점에서 보면 KMP + CMP를 도입하는 순간, Android 구현뿐만 아니라 iOS 환경 설정, 플랫폼별 NFC 제약, 빌드 설정, 테스트 환경 구성 등 추가로 고려해야 할 비용이 발생할 수 있다고 생각했습니다. 특히 iOS는 NFC 동작 방식이나 개발 환경 측면에서 별도의 설정과 검증 비용이 커질 수 있기 때문에, 현재 MVP 단계에서는 오히려 검증 속도를 늦출 수 있다고 판단했습니다.
그래서 이번에는 Kotlin과 Compose를 사용하되, 멀티플랫폼 구조까지 확장하지는 않고 Android Native로 한정하기로 했습니다. Kotlin과 Compose를 선택한 이유는 멀티플랫폼 확장 때문이라기보다, 저희가 가장 익숙하게 접근할 수 있고 빠르게 화면과 기능을 구현해 MVP 검증에 집중할 수 있는 기술이기 때문입니다.
정리하면, 멀티플랫폼은 확장 가능성이 확인된 이후의 선택지로 남겨두고, 지금은 가장 빠르게 가설을 검증할 수 있는 Android Native + Kotlin + Compose 조합을 선택했다고 볼 수 있을 것 같습니다.
There was a problem hiding this comment.
그렇군요..!
아주 좋습니다~
Web 등에서는 확장한다면, 기존 우테코 출석앱처럼 해당 와이파이 연결시 출석을 하는 기능으로도 확장이 가능할 수 있겠군요!
(언젠가... 해당 MVP가 너무 잘돼서 우테코 앱대신에 해당 서비스가 주요하게 사용되었으면 좋겠네요😀)
| |---|---| | ||
| | Flutter / React Native | NFC와 같은 하드웨어 및 권한 의존 기능은 플랫폼별 차이가 크기 때문에 멀티플랫폼 환경에서 안정적으로 제어하기 어렵다고 판단하였다. 특히 iOS는 NFC 관련 권한과 동작 제약이 까다로운 편이라 플랫폼별 예외 처리가 많이 필요했고, MVP 단계에서 구현 복잡도가 커질 수 있다고 판단하였다. | | ||
| | Swift(iOS Native) | iOS 환경에서 NFC 기능을 실제 디바이스에서 테스트하려면 Apple Developer 계정이 필요하다. MVP 단계에서 연간 비용(99달러)을 지불하면서까지 iOS 앱을 우선 구현하는 것은 부담이 있다고 판단하였다. 또한 iOS는 NFC 및 백그라운드 동작 관련 정책 제약이 많아 추가적으로 고려해야 할 사항이 많다고 판단하였다. | | ||
|
|
There was a problem hiding this comment.
로컬등으로 테스트 한다면 무조건 Apple Developer 계정이 필요할까? 라는 고민이 들었어요~
배포를 위한 허들인지, 개발 자체에 대한 허들인지?에 대한 생각이 들었습니다!
사내 서비스라면 출시를 하지 않아도 되기 때문에 Firebase Distribution 등 여러가지 옵션을 통해서도 배포는 가능할 것 같다는 생각이 들었습니다!
There was a problem hiding this comment.
말씀해 주신 것처럼 무료 Apple 계정으로도 제한적인 iOS 실기기 테스트는 가능합니다. 하지만 저희가 우려한 핵심은 NFC 기능 검증이었습니다.
iOS에서 NFC Tag Reading은 별도의 Capability 및 Entitlement 설정이 필수적이며, 이는 유료 Apple Developer Program 멤버십이 있어야만 활성화할 수 있습니다. 즉, 무료 계정 환경에서는 NFC 기능의 실기기 빌드 및 테스트 자체가 불가능한 상황입니다. Firebase App Distribution과 같은 우회 배포 방식을 고려하더라도, 결국 Apple의 코드 서명과 프로비저닝 프로파일(Provisioning Profile) 설정이 요구되므로 근본적인 해결책이 되지 못했습니다.
따라서 현재 MVP 단계의 최우선 목표인 'NFC 출석 가설 검증'을 가장 빠르고 효율적으로 달성하기 위해, 테스트 환경 구성에 제약이 없는 안드로이드 네이티브 구현을 우선적으로 선택하게 되었습니다.
There was a problem hiding this comment.
프로파일은 기기에서 프로파일 설치로 간단하게 테스트시에는 가능할텐데, NFC의 경우 부가적인 설정이 필요하였나 보군요~
좋습니다!
지원이 안되는 부분은 멀티플랫폼이다보니, 추후에 지원을 하고 현재 구현이 가능한 부분과 서비스의 기능과 본질에 집중을 하는 것이 좋겠네요👍
| - NFC 기반 출석 방식에 대한 사용자 반응 확인 | ||
| - 실제 사용 의향 및 거부감 여부 조사 |
There was a problem hiding this comment.
NFC 인식이 특정 NFC 일렬번호를 가진 기기에서만 해당 서비스가 돌아가는지도 확인을 해보는 것도 좋을 것 같다는 생각이 들었어요~
건물 유지보수를 하면서, NFC기기가 교체가 된다면...?등의 케이스등을 고려해보기 위함이겠군요
There was a problem hiding this comment.
현재 MVP 단계에서는 기존 출석앱의 출석 API를 바로 호출하는 방식이 아니라, Bello 팀에서 만든 NFC 출석 흐름을 통해 기록을 전달하는 방식으로 생각하고 있습니다.
이유는 기존 출석 API를 그대로 호출하면 앞서 말한 사내망 Wi-Fi 조건이 그대로 적용될 수 있기 때문입니다. 그러면 NFC를 도입하더라도 사용자는 여전히 사내망 Wi-Fi 연결 여부를 먼저 확인해야 하고, 기존 방식의 제약이 크게 줄어들지 않을 수 있습니다.
따라서 MVP에서는 우선 NFC 태그를 통해 출석 기록이 전달될 수 있는지를 확인하는 데 집중하려고 합니다. 이 단계에서는 Firebase를 1차적으로 사용해 다음 흐름을 검증할 수 있다고 생각했습니다.
앱 실행
→ NFC 태그 인식
→ 출석 기록 생성
→ Firebase에 기록 저장
→ NFC 태그 방식으로 기록 전달이 가능한지 확인
이후 NFC 방식이 유효하다고 판단되면, Firebase에 저장하던 부분을 서버 API 호출로 교체하면 됩니다. 이때 서버에는 기존 출석 API를 그대로 사용하는 것이 아니라, NFC 출석 체크용 API 코드만 별도로 추가하면 될 것이라고 생각했습니다.
정리하면, MVP에서는 Bello 팀의 NFC 서비스/Firebase 기반 흐름으로 먼저 검증하고, 이후에는 서버에 NFC 출석 전용 API를 추가해 실제 출석 처리로 연결하는 방식을 생각하고 있습니다.
There was a problem hiding this comment.
위에서 언급했듯 기능 자체는 크지 않다보니, 구현 자체는 난이도가 엄청나게 크지는 않을 것 같다는 생각이 드는군요~
역시 사내망이라는 특수성이 제일 걸리시겠군요🥲
|
|
||
| ### 검증 방법 초안 |
There was a problem hiding this comment.
사내 서비스다 보니까, 검증을 할 수 있는 모수가 줄 수 있겠지만 그만큼 니즈에 대한 파악은 확실히 되겠군요👍
| - 예를 들어 `앱을 실행하지 않아도 NFC만으로 출석이 가능한 방식`, `앱을 실행한 뒤 NFC를 통해 출석하는 방식` 등 여러 방향을 비교했고, 최종적으로는 “앱을 실행하지 않아도 가능한 방식”은 MVP 범위를 넘어서는 추가 기능에 가깝다고 판단하였다. | ||
|
|
There was a problem hiding this comment.
앱을 실행하고 NFC를 찍는 이 부분에 대해서 한가지 들었던 생각이 있습니다~
NFC 를 통해서, 기존 출석앱의 출석 API 를 호출하는 것인지 vs Bello 팀에서 만든 NFC 서비스를 통해서 출석 API 를 호출하는 것인지입니다!
There was a problem hiding this comment.
좋은 의견 감사합니다!! 저희가 구현하고자 하는 것은 출석이라는 인증 수단이기 때문에 단순히 인식이 되는 것을 검증하기만 하면 안됐네요…! 두루의 의견처럼 특정한 일련번호가 아닌 다른 일련번호에서도 출석이 인증된다면, NFC 기반의 출석 앱이 오용될 수도 있을 것 같습니다!
이 부분도 반드시 고려하는 것이 좋다고 생각합니다 :)
|
벨로 가문~ 하이포~ 좋았던 점
아쉬운 점
얼른 만들어서 남은 우테코 기간동안 쓰게 해줘여~~ |
|
팀 Bello 안녕하세요! 팀에서 발표 들으면서 나왔던 피드백 내용 공유드립니다! 우선 저희 크루원들이 현재 실시간으로 느끼고 있는 문제여서 공감이 잘 되었습니다. 해결하신다면 우테코의 영웅이 되실 기회.. 특히 iOS의 NFC 기능을 사용하려면 Apple Developer 계정이 필요하다고 하셨는데, 저희도 애플워치 OS나 iOS의 GPS, 속도계 등을 사용해야 하는데, 저희도 이러한 사항에 해당되는 것인지 다시 점검해봐야 겠다는 생각이 들었습니다. 악용의 여지가 있을까? 라는 의문에는 현재 출석 시스템에서도 동일하게 적용될 수도 있는 문제 아닌가? 라는 생각이 들어, 악용의 여지에 대한 해결책에 대해서는 코치님들한테도 조언을 구해보면 도움이 많이 될 것 같다는 생각이 들었습니다!! |
|
컹컹! 벨로팀 벨로~(미니언즈말로 안녕이라는 뜻). 팀에서 발표 들으면서 나왔던 피드백 내용 공유드립니다! 좋았던 점은 저희 팀 모두도 공감하는 문제고 특히 KDT 대상자들은 두 앱을 전환하며 출석을 하다보니 더 귀찮은 문제였는데 이 부분을 해결하시려고 노력하는 것 같아 좋았습니다. 고민해봐도 좋을 것 같은 점은 만약 NFC 태그 하는 기기가 너무 적다면 출석을 위해 오픈런(?)처럼 긴 줄이 생길 수 있다는 생각도 들어서 이에 대해서도 생각해본다면 좋겠다는 생각이 들었습니다. 
☝️ 출석을 기다리는 누렁이들(?) ☝️ |
문제 정의 및 솔루션
MVP(최소 기능 제품) 구현 범위완성도 높은 서비스보다 NFC 기반 출석 방식의 동작 가능성을 빠르게 검증하는 것이 목표
기술 플랫폼 및 선택 이유
좋았던 점 (피드백 종합)
아쉬운 점 및 고려해볼 점 (피드백 종합)
|
noeyhoj
left a comment
noeyhoj
left a comment
There was a problem hiding this comment.
안녕하세요 두루! 팀 Bello 입니다~ 👋
두루의 알찬 리뷰 감사합니다!! 리뷰를 보고 의도나 근거가 불분명하게 전달되었다는 생각이 들었습니다. 그렇기에 코멘트에서 저희의 의도와 목표를 구체적으로 작성하였습니다!! 🙇
| ### 4. 구현 방식 결정 | ||
| - 초기에는 NFC 태그 시 앱 자동 실행 방식, 백그라운드 출석 처리 방식 등을 함께 고려했다. | ||
| - 하지만 구현 가능성과 안정성을 고려해, 앱 실행 후 NFC 태그를 인식하여 출석 처리하는 방식” 으로 최종 방향을 결정했다. |
There was a problem hiding this comment.
기존 방식의 가장 큰 문제는 출석 버튼을 누르기 위해 특정 와이파이에 연결되어 있어야 하고, 네트워크 상태에 따라 출석이 원활하지 않을 수 있다는 점이라고 생각했습니다. 그래서 이 문제를 해결할 수 있는 방법으로 GPS, RFID, NFC를 고려했습니다.
먼저 GPS는 실내에서 정확도가 떨어질 수 있고 위치 기반 인증만으로는 실제로 출석 지점에 도착했는지를 명확히 판단하기 어렵다고 생각했습니다.
RFID도 출석 인증에 사용할 수 있는 기술이라고 생각했습니다. 다만 일반적인 RFID 방식은 별도의 카드나 태그를 사용자에게 지급하거나, 이를 읽기 위한 전용 리더기 같은 하드웨어가 필요할 수 있습니다. 사용자 입장에서는 관리해야 할 수단이 많아져서 번거롭고, 관리자 입장에서는 개개인에 대한 부가적인 관리가 필요하여 불편할 거라는 생각이 듭니다. 반면 NFC는 스마트폰에 기본적으로 탑재된 경우가 많기 때문에, 사용자가 이미 가지고 있는 스마트폰을 리더기로 활용할 수 있다는 점이 MVP 관점에서 더 적합하다고 판단했습니다.
또한 RFID는 수 센티미터부터 수십 미터까지 먼 거리에서도 통신을 할 수 있지만, NFC를 사용할 경우 사용자는 특정 위치에 부착된 NFC 스티커에 스마트폰을 직접 가까이 대야만 출석을 할 수 있습니다.
그리고 비용 측면에서 NFC가 저렴하기 때문에 NFC 태그 방식에서 가장 염려되는 병목 현상을 해결하기 위해 많은 기기를 두는 것에도 문제가 없습니다.
구현 측면에서도 NFC 스티커와 스마트폰만 있으면 빠르게 기본 흐름을 구현하고 테스트할 수 있어 가장 적합한 기술이 NFC라고 판단했습니다.
| ### 5. MVP 범위 설정 | ||
| - 완성도 높은 출석 서비스를 만드는 것보다, NFC 기반 출석 방식이 실제로 동작 가능한지 빠르게 검증하는 것을 목표로 삼았다. | ||
| - 이에 따라 MVP 범위를 다음과 같이 최소화했다. | ||
| - NFC 지원 여부 확인 | ||
| - NFC 태그 인식 | ||
| - 태그 값 읽기 | ||
| - 출석 요청 전송 | ||
| - 출석 결과 표시 |
There was a problem hiding this comment.
MVP 이후 확장 가능성에 대해서는 저희도 고민해보았고, 단순히 NFC 태그를 읽는 기능에서 끝나는 것이 아니라 실제 출석 서비스에 가까워질 수 있도록 몇 가지 확장 방향을 정리해두었습니다.
- 서버 API 연동
우선 MVP 단계에서는 Android 앱에서 NFC 태그를 인식하고, Firebase에 출석 정보를 저장하는 방식으로 빠르게 핵심 흐름을 검증하려고 합니다. 이후에는 Firebase 저장 로직을 서버 API 호출 방식으로 변경하여, 실제 출석 시스템과 연결 가능한 구조로 확장할 수 있다고 생각했습니다. - NFC 출석 전용 API 추가
또한 기존 출석 API를 그대로 사용하는 것이 아니라, NFC 출석 전용 API를 서버에 추가하는 방향도 고려하고 있습니다. 현재 방식이 사내 Wi-Fi 검증에 의존하고 있다면, 이후에는 NFC 태그 기반으로 출석을 처리할 수 있는 별도의 API를 두어 더 독립적인 출석 흐름을 만들 수 있을 것 같습니다. - 사용자 인증 연동
로그인 사용자 정보와 NFC 태그 기록을 연결하여 누가 출석했는지 정확히 식별할 수 있습니다. - 태그 위치 관리
강의장, 캠퍼스, 층별로 NFC 태그를 관리하면, 사용자가 실제 지정된 위치에서 태그했는지 검증할 수 있고, 출석 흐름도 더 정확하게 만들 수 있습니다. - 예외 상황 처리
예외 상황 처리도 필요하다고 보았습니다. 실제 사용 환경에서는 네트워크 실패, 잘못된 태그 인식, 중복 태그, 서버 오류 등이 충분히 발생할 수 있기 때문에, 이런 상황을 앱에서 안정적으로 처리하는 기능도 확장 대상에 포함했습니다. - 기존 기능 확장
추가로 기존 버튼식 출석 기능과 NFC 출석 기능을 함께 사용할 수 있도록 구현하는 것도 고려하고 있습니다. 이렇게 하면 NFC 기능을 도입하더라도 기존 출석 흐름을 완전히 대체하지 않고, 상황에 따라 함께 활용할 수 있을 것 같습니다. - iOS 기반 개발 확장
더 나아가 Android에서 검증한 흐름을 iOS 환경에도 적용하여 더 많은 사용자 환경을 지원하는 방향으로 확장할 수 있습니다. - 보안 강화
마지막으로 보안 측면에서는 단순 태그 ID만 사용하는 방식에서 끝나지 않고, 토큰, 만료 시간, 서버 검증 방식 등을 적용해 대리 출석이나 태그 복제 가능성을 줄이는 방향으로 고도화할 수 있다고 생각했습니다.
| - 어떤 상황에서: 등/하교를 할 때 | ||
| - 어떤 불편을 겪는가: 특정 와이파이에 연결해야만 출석 기능을 사용할 수 있는데, 연결이 원활하지 않거나 오류가 발생하는 경우 UI가 정상적으로 표시되지 않아 출석/하교 버튼을 누르지 못하는 상황이 자주 발생한다. | ||
|
|
There was a problem hiding this comment.
이 부분은 저희도 먼저 확인이 필요하다고 생각했습니다.
현재 출석/퇴실 기능이 특정 Wi-Fi 환경에서만 동작하는 이유는, 사용자가 실제로 해당 장소에 있다는 것을 확인하기 위해 사내망 IP를 하나의 검증 조건으로 사용하고 있기 때문이라고 판단했습니다.
확인해본 결과, 퇴실 과정에서는 현재 연결된 Wi-Fi가 맞는지를 확인하는 API를 서버로 보내고, 그 결과에 따라 UI를 띄우는 방식으로 동작하고 있었습니다. 따라서 기존 출석 API를 그대로 사용한다면, NFC를 활용하더라도 결국 출석 API 호출 시점에 사내망 Wi-Fi 연결이 필요할 가능성이 있습니다.
즉, 기존 출석 API를 그대로 호출하는 구조라면 NFC 태그 전에도 사용자가 사내망 Wi-Fi에 정상적으로 연결되어 있는지 확인해야 하고, 이 경우 말씀해주신 것처럼 네트워크 환경에 따른 제약은 그대로 남을 수 있다고 생각합니다.
다만 전체 API가 모두 사내망 IP에서만 접근 가능한 것은 아니고, 장소 검증이 필요한 특정 API만 사내망 IP 조건을 두고 있는 것으로 보였습니다. 그래서 NFC 방식에서는 기존 출석 API를 그대로 사용하는 대신, NFC 태그를 장소 검증 수단으로 활용하는 별도 출석 API를 만들면 이 문제를 줄일 수 있다고 생각했습니다.
| ### 솔루션 (한 줄) | ||
| - 특정 와이파이를 사용하지 않고 NFC를 통해서 출석할 수 있도록 만든다. |
There was a problem hiding this comment.
이 리뷰에 대해서는 아래의 코멘트에 포함되어 있습니다!! 🫡
https://github.com/woowacourse/android-mini-projects/pull/1/changes#r3331846478
| - NFC 기반 출석 방식에 대한 사용자 반응 확인 | ||
| - 실제 사용 의향 및 거부감 여부 조사 |
There was a problem hiding this comment.
현재 MVP 단계에서는 기존 출석앱의 출석 API를 바로 호출하는 방식이 아니라, Bello 팀에서 만든 NFC 출석 흐름을 통해 기록을 전달하는 방식으로 생각하고 있습니다.
이유는 기존 출석 API를 그대로 호출하면 앞서 말한 사내망 Wi-Fi 조건이 그대로 적용될 수 있기 때문입니다. 그러면 NFC를 도입하더라도 사용자는 여전히 사내망 Wi-Fi 연결 여부를 먼저 확인해야 하고, 기존 방식의 제약이 크게 줄어들지 않을 수 있습니다.
따라서 MVP에서는 우선 NFC 태그를 통해 출석 기록이 전달될 수 있는지를 확인하는 데 집중하려고 합니다. 이 단계에서는 Firebase를 1차적으로 사용해 다음 흐름을 검증할 수 있다고 생각했습니다.
앱 실행
→ NFC 태그 인식
→ 출석 기록 생성
→ Firebase에 기록 저장
→ NFC 태그 방식으로 기록 전달이 가능한지 확인
이후 NFC 방식이 유효하다고 판단되면, Firebase에 저장하던 부분을 서버 API 호출로 교체하면 됩니다. 이때 서버에는 기존 출석 API를 그대로 사용하는 것이 아니라, NFC 출석 체크용 API 코드만 별도로 추가하면 될 것이라고 생각했습니다.
정리하면, MVP에서는 Bello 팀의 NFC 서비스/Firebase 기반 흐름으로 먼저 검증하고, 이후에는 서버에 NFC 출석 전용 API를 추가해 실제 출석 처리로 연결하는 방식을 생각하고 있습니다.
| |---|---| | ||
| | Android Native (Android Studio) | NFC는 단말기의 하드웨어 기능과 직접적으로 연결되는 기능이기 때문에, 플랫폼 제약이 적고 안정적으로 제어할 수 있는 Native 환경이 적합하다고 판단하였다. 또한 Android는 NFC 관련 API 지원 범위가 넓고 테스트 환경 구축이 비교적 자유로워, 빠른 프로토타입 구현과 검증에 유리하다고 판단하였다. | |
There was a problem hiding this comment.
피드백 감사합니다, 두루!!
말씀해 주신 것처럼 저희가 Kotlin과 Compose에 익숙하기 때문에 KMP + CMP도 충분히 고려해볼 만한 선택지라고 생각했습니다. 특히 이후에 iOS까지 확장하거나, 하나의 코드베이스로 여러 플랫폼을 지원해야 하는 상황이라면 멀티플랫폼 접근이 매력적일 수 있다고 판단했습니다.
다만 이번 미니프로젝트의 핵심 목표는 완성도 높은 멀티플랫폼 앱을 배포하는 것보다는, “NFC 기반 출석 방식이 기존 방식보다 실제로 더 편리한가?”라는 가설을 빠르게 검증하는 데 있다고 보았습니다.
이 관점에서 보면 KMP + CMP를 도입하는 순간, Android 구현뿐만 아니라 iOS 환경 설정, 플랫폼별 NFC 제약, 빌드 설정, 테스트 환경 구성 등 추가로 고려해야 할 비용이 발생할 수 있다고 생각했습니다. 특히 iOS는 NFC 동작 방식이나 개발 환경 측면에서 별도의 설정과 검증 비용이 커질 수 있기 때문에, 현재 MVP 단계에서는 오히려 검증 속도를 늦출 수 있다고 판단했습니다.
그래서 이번에는 Kotlin과 Compose를 사용하되, 멀티플랫폼 구조까지 확장하지는 않고 Android Native로 한정하기로 했습니다. Kotlin과 Compose를 선택한 이유는 멀티플랫폼 확장 때문이라기보다, 저희가 가장 익숙하게 접근할 수 있고 빠르게 화면과 기능을 구현해 MVP 검증에 집중할 수 있는 기술이기 때문입니다.
정리하면, 멀티플랫폼은 확장 가능성이 확인된 이후의 선택지로 남겨두고, 지금은 가장 빠르게 가설을 검증할 수 있는 Android Native + Kotlin + Compose 조합을 선택했다고 볼 수 있을 것 같습니다.
| |---|---| | ||
| | Flutter / React Native | NFC와 같은 하드웨어 및 권한 의존 기능은 플랫폼별 차이가 크기 때문에 멀티플랫폼 환경에서 안정적으로 제어하기 어렵다고 판단하였다. 특히 iOS는 NFC 관련 권한과 동작 제약이 까다로운 편이라 플랫폼별 예외 처리가 많이 필요했고, MVP 단계에서 구현 복잡도가 커질 수 있다고 판단하였다. | | ||
| | Swift(iOS Native) | iOS 환경에서 NFC 기능을 실제 디바이스에서 테스트하려면 Apple Developer 계정이 필요하다. MVP 단계에서 연간 비용(99달러)을 지불하면서까지 iOS 앱을 우선 구현하는 것은 부담이 있다고 판단하였다. 또한 iOS는 NFC 및 백그라운드 동작 관련 정책 제약이 많아 추가적으로 고려해야 할 사항이 많다고 판단하였다. | | ||
|
|
There was a problem hiding this comment.
말씀해 주신 것처럼 무료 Apple 계정으로도 제한적인 iOS 실기기 테스트는 가능합니다. 하지만 저희가 우려한 핵심은 NFC 기능 검증이었습니다.
iOS에서 NFC Tag Reading은 별도의 Capability 및 Entitlement 설정이 필수적이며, 이는 유료 Apple Developer Program 멤버십이 있어야만 활성화할 수 있습니다. 즉, 무료 계정 환경에서는 NFC 기능의 실기기 빌드 및 테스트 자체가 불가능한 상황입니다. Firebase App Distribution과 같은 우회 배포 방식을 고려하더라도, 결국 Apple의 코드 서명과 프로비저닝 프로파일(Provisioning Profile) 설정이 요구되므로 근본적인 해결책이 되지 못했습니다.
따라서 현재 MVP 단계의 최우선 목표인 'NFC 출석 가설 검증'을 가장 빠르고 효율적으로 달성하기 위해, 테스트 환경 구성에 제약이 없는 안드로이드 네이티브 구현을 우선적으로 선택하게 되었습니다.
| - 예를 들어 `앱을 실행하지 않아도 NFC만으로 출석이 가능한 방식`, `앱을 실행한 뒤 NFC를 통해 출석하는 방식` 등 여러 방향을 비교했고, 최종적으로는 “앱을 실행하지 않아도 가능한 방식”은 MVP 범위를 넘어서는 추가 기능에 가깝다고 판단하였다. | ||
|
|
There was a problem hiding this comment.
좋은 의견 감사합니다!! 저희가 구현하고자 하는 것은 출석이라는 인증 수단이기 때문에 단순히 인식이 되는 것을 검증하기만 하면 안됐네요…! 두루의 의견처럼 특정한 일련번호가 아닌 다른 일련번호에서도 출석이 인증된다면, NFC 기반의 출석 앱이 오용될 수도 있을 것 같습니다!
이 부분도 반드시 고려하는 것이 좋다고 생각합니다 :)
Gyuil-Hwnag
left a comment
Gyuil-Hwnag
left a comment
There was a problem hiding this comment.
Bello팀 (하로, 엘리, 엠버) 안녕하세요!
해당 미션 코멘트들을 기반으로 서비스에 대한 고도화 정말 고생 많으셨습니다!
너무 잘 해주셨습니다 💯
확실히 실제로 필요로 느끼셨던 기능들을 구현하는 것이다보니, 기능과 범위가 명확했던 것 같네요~
그치만 사내 서비스이다보니, 역시나 사내망이라는 특수한 환경에 대한 사전 조사가 제일 중요한 포인트가 될 수 있겠군요!
간단하게 고민해보시면 좋을만한 내용들 코멘트를 달았으니 확인해주시면 감사하겠습니다.
이번 미션은 내용을 확인후 팀에서 셀프 머지를 하는 방식이라서, 슬랙 노티를 위해서 RC 처리를 해두도록 하겠습니다~
궁금한 점이나 논의하고 싶은 내용이 있으면 언제든 DM 주세요! 🙏
화이팅입니다💪
| ### 팀 정보 | ||
| - 팀 이름: Bello | ||
| - 팀장: 하로 | ||
| - 멤버: 엠버, 엘리 | ||
| - 한 줄 소개: 말랑이 셋 |
There was a problem hiding this comment.
Bello 가 설마... 미니언즈에서 나오는 그거였나요...?🤣
| - 어떤 불편을 겪는가: 특정 와이파이에 연결해야만 출석 기능을 사용할 수 있는데, 연결이 원활하지 않거나 오류가 발생하는 경우 UI가 정상적으로 표시되지 않아 출석/하교 버튼을 누르지 못하는 상황이 자주 발생한다. | ||
|
|
There was a problem hiding this comment.
확실하게 직접 체감을 하면서, 선정한 문제여서 공감을 하는 분들이 많을 것 같군요~
어떻게 문제없이 출석 처리를 잘 해줄지가 이제는 중요해지겠어요💪
| ### 사전 조사 | ||
| - 예시 이미지를 포함한 설문지 제작 | ||
| - 현재 출석 방식에서 느끼는 불편함 조사 | ||
| - NFC 기반 출석 방식에 대한 사용자 반응 확인 | ||
| - 실제 사용 의향 및 거부감 여부 조사 |
There was a problem hiding this comment.
NFC 의 기술 + 출석 API 사용 가능 여부가 해당 서비스를 만들 수 있을지 없을지를 결정하게 될 것 같아서, 이 부분은 잘 조사해보시길 바랄게요~💪
| | 사용자가 해당 방식을 실제로 사용할 의향이 있는지 확인하기 위한 프로토타입 배포 | 모든 사용자를 대상으로 한 정식 배포 | | ||
|
|
There was a problem hiding this comment.
간단하게 어떤 형태로, 출석 인증을 하게 할지에 대한 언급도 있다면 해당 내용을 기반으로 좀 더 명확하게 문서화가 가능해질 수 있겠다는 생각도 들었어요~💪
6 participants
Week 1 보고서 — Bello
이번 주 한 일 (계획 vs 실제)
1. 팀 구성 및 문제 탐색
2. 문제 정의 및 아이디어 도출
3. 아이디어 구체화
4. 구현 방식 결정
5. MVP 범위 설정
6. 기술 플랫폼 선정
7. 발표 자료 준비
결론
A. 기획 결과물
팀 정보
문제 정의
솔루션 (한 줄)
기술/플랫폼 선택
선택하지 않은 옵션
사전 조사
MVP 범위
검증 방법 초안
성공/실패를 판단할 기준:
어떻게 측정할 것인가:
발표 자료 링크
(5/29 발표 예정)
B. 회고
가장 어려웠던 의사결정
MVP 기능 구현 범위를 설정하는 과정이 어려웠다. 가장 단순한 방향은 “앱을 실행하지 않아도 NFC만으로 출석이 가능하도록 만드는 것”이라고 생각했지만, 실제로는 현재 문제를 최소한으로 해결할 수 있는 수준까지 기능 범위를 조정하는 과정이 쉽지 않았다.
예를 들어
앱을 실행하지 않아도 NFC만으로 출석이 가능한 방식,앱을 실행한 뒤 NFC를 통해 출석하는 방식등 여러 방향을 비교했고, 최종적으로는 “앱을 실행하지 않아도 가능한 방식”은 MVP 범위를 넘어서는 추가 기능에 가깝다고 판단하였다.문제 상황과 그 원인을 구체적으로 좁혀가는 과정이 어려웠다.
단순히 “사람들이 왜 앱 사용을 불편해하는가?”라는 질문에서 시작했지만
버튼을 누르는 것을 자주 까먹어서,와이파이 연결 과정이 번거로워서,와이파이에 연결했음에도 UI가 정상적으로 표시되지 않아서등 다양한 원인이 존재했다. 이 중 실제로 가장 큰 영향을 주는 핵심 원인이 무엇인지 우선순위를 정하고 정의하는 과정이 가장 어려웠다.합의되지 않은 부분 (있다면)
가장 의심스러운 가정 1가지