Author: dvadmin

  • 웨어러블 앱 개발 가이드 | 갤럭시 워치·백엔드 연동 구조 설계

    웨어러블 앱 개발 가이드 | 갤럭시 워치·백엔드 연동 구조 설계

    한국전자통신연구원(ETRI) 프로젝트로 삼성 갤럭시 워치4 데이터 수집 앱을 개발했습니다. 연구 목적으로 만든 앱이지만, WearOS 개발의 핵심 도전들은 상용 헬스케어 앱에도 그대로 적용됩니다.


    WearOS 앱이 일반 모바일 앱과 다른 점

    스마트워치는 스마트폰을 작게 만든 것이 아닙니다. 하드웨어 제약이 완전히 다릅니다.

    • 화면이 작다: 480×480px 수준. 스크롤 대신 스와이프. 텍스트 최소화
    • 배터리가 작다: 일반 앱처럼 개발하면 하루도 못 갑니다
    • 연산 능력이 제한적: 무거운 처리는 스마트폰이나 클라우드에 위임해야
    • 항상 착용: 백그라운드에서 지속적으로 데이터를 수집해야 하는 경우가 많음

    이 모든 제약을 고려한 설계가 WearOS 앱 개발의 핵심입니다.


    ETRI 프로젝트: 무엇을 만들었나

    연구 목적으로 사용자의 신체 데이터를 장기간 수집하는 앱입니다.

    수집 데이터:

    • 걸음 수, 이동 거리, 속력 (위치 데이터)
    • 심박수 (건강 데이터)
    • 가속도, 자이로 (자세 데이터)

    조건:

    • 포그라운드(앱 켜진 상태)와 백그라운드(앱 꺼진 상태) 모두에서 지속 수집
    • 분 단위로 클라우드 데이터베이스에 자동 전송
    • 관리자가 실시간으로 수집 현황 조회

    이 요구사항을 만족시키는 것이 생각보다 훨씬 어려웠습니다.


    핵심 도전 1 — 백그라운드 센서 수집

    WearOS에서 앱이 백그라운드로 전환되면 센서 접근이 제한됩니다. 배터리 절약을 위한 시스템 정책 때문입니다.

    이를 극복하기 위해:

    • Foreground Service: 알림 표시 상태로 앱이 항상 실행 중임을 시스템에 알림
    • WorkManager: 주기적인 데이터 전송 스케줄링
    • Wake Lock: 화면이 꺼져도 CPU가 계속 작동하도록 (배터리 소모 주의)

    이 세 가지를 조합해 백그라운드에서도 안정적으로 센서 데이터를 수집했습니다.


    핵심 도전 2 — 배터리 최적화

    백그라운드에서 GPS, 심박수 센서를 계속 켜두면 배터리가 반나절도 못 버팁니다.

    최적화 접근:

    • GPS 수집 주기 조절: 초 단위가 아닌 분 단위로 위치 업데이트
    • 센서 배치(Batching): 센서 데이터를 개별 전송이 아닌 배치로 모아서 한 번에 처리
    • 적응형 데이터 수집: 사용자가 움직이지 않을 때 수집 빈도 낮추기
    • 클라우드 전송 최적화: Wi-Fi 연결 시에만 대량 전송, 블루투스로 폰을 경유

    결과적으로 하루 종일 착용해도 배터리 50% 이상 유지되는 수준을 달성했습니다.


    핵심 도전 3 — 스마트폰-워치-클라우드 3단 연동

    데이터 흐름: 갤럭시 워치4 → 갤럭시 폰 → 클라우드

    워치가 직접 인터넷에 연결하는 것보다, 블루투스로 페어링된 스마트폰을 통해 클라우드에 업로드하는 방식이 배터리 효율이 좋습니다.

    이를 위한 설계:

    • 워치 앱과 폰 앱이 블루투스로 실시간 통신 (Wearable Data Layer API)
    • 폰 앱이 워치에서 받은 데이터를 클라우드에 업로드
    • 워치 단독으로도 LTE 연결 시 직접 업로드 가능하도록 폴백 구현

    핵심 도전 4 — 실시간 관리자 모니터링

    연구자들이 실시간으로 피험자의 데이터를 확인할 수 있어야 했습니다.

    • 피험자별 실시간 데이터 대시보드
    • 데이터 수집 상태 확인 (정상/비정상)
    • 특정 시간대 데이터 조회 및 CSV 내보내기

    Firebase Realtime Database를 활용해 분 단위로 업데이트되는 실시간 대시보드를 구현했습니다.


    WearOS 앱 개발 시 기술 스택 선택

    언어: Kotlin (Android/WearOS 공식 언어)

    센서 API: Samsung Health Sensor SDK — 갤럭시 워치 특화 센서에 접근하기 위해 필수

    네트워크: Retrofit + Firebase. 분 단위 업로드에는 Retrofit, 실시간 대시보드에는 Firebase Realtime Database

    백그라운드 처리: Android WorkManager + Foreground Service 조합


    헬스케어 상용 앱에 적용할 때 추가 고려사항

    ETRI 프로젝트는 연구 목적이라 규제에서 비교적 자유로웠습니다. 상용 헬스케어 앱이라면 추가로 고려해야 합니다.

    개인정보: 심박수, 위치 같은 민감 정보는 더 엄격한 동의와 보안이 필요합니다.

    앱스토어 심사: 건강 데이터를 수집하는 앱은 구글 플레이 스토어와 갤럭시 스토어에서 별도 심사를 받습니다. 승인 기준을 사전에 확인해야 합니다.

    Samsung Health 연동: 상용 앱이라면 삼성 헬스 앱과 연동해 기존 건강 데이터를 활용할 수 있습니다. 이 경우 Samsung Health SDK 개발자 등록과 심사 과정이 필요합니다.


    마치며

    WearOS 앱 개발은 일반 모바일 앱 대비 제약이 많지만, 그만큼 “항상 몸에 붙어있는 기기”라는 강력한 강점이 있습니다.

    헬스케어, 피트니스, 산업 안전(위험 지역 작업자 모니터링) 등 지속적인 신체 데이터가 필요한 서비스에서 웨어러블은 스마트폰을 대체할 수 없는 포지션을 가집니다. 배터리와 화면 제약을 잘 설계하면, 그 가치는 충분히 실현됩니다.

  • LMS 플랫폼 개발 가이드 | 솔루션 vs 커스텀 개발 선택 기준

    LMS 플랫폼 개발 가이드 | 솔루션 vs 커스텀 개발 선택 기준

    “LMS 도입하려는데, 직접 개발하는 게 나을까요, 솔루션 쓰는 게 나을까요?” — 에듀테크 프로젝트를 논의할 때 자주 받는 질문입니다. 디비컨설팅은 디비스쿨, C-Training, SPEP, 가천대학교 학사관리 시스템 등 다수의 학습 관련 플랫폼을 개발한 경험이 있습니다. 두 방식을 모두 경험한 입장에서 정리합니다.

    먼저 용어 정리

    기성 솔루션(SaaS LMS): Moodle, Teachable, 이클래스 같이 이미 만들어진 LMS를 월 구독 또는 라이선스 방식으로 쓰는 것.

    커스텀 개발: 처음부터 자체적으로 LMS를 만드는 것. 디자인, 기능, DB 구조 모두 원하는 대로 설계.

    기성 솔루션이 맞는 경우

    솔루션이 유리한 상황이 있습니다.

    ① 빠르게 시작해야 할 때: 3~6개월 안에 서비스를 런칭해야 하는 상황이라면 솔루션이 압도적으로 유리합니다. 커스텀 개발은 기획만 해도 몇 달이 걸립니다.

    ② 표준적인 기능만 필요할 때: 강의 업로드, 수강생 관리, 퀴즈, 수료증 발급 — 이 정도면 대부분의 솔루션이 충분히 커버합니다.

    ③ 초기 스타트업이라 예산이 제한적일 때: 월 몇십만 원으로 시작할 수 있는 솔루션 대비, 커스텀 개발은 초기 투자 비용이 수천만 원에서 수억 원까지 올라갈 수 있습니다.

    ④ IT 개발팀이 없을 때: 솔루션은 운영에 개발자가 필요 없습니다. 커스텀 개발 후 유지보수를 위해 개발팀이 없다면, 지속 운영이 어려워집니다.

    커스텀 개발이 맞는 경우

    반면 커스텀 개발을 선택해야 할 상황도 있습니다.

    ① 기성 솔루션이 지원하지 않는 특수 기능이 있을 때: 예를 들어, 디비스쿨처럼 AI 기반 맞춤 학습, 메신저 기반 클래스룸, 다국어 교재 연동 같은 기능은 솔루션으로 구현이 불가능합니다.

    ② 다른 시스템과 깊은 연동이 필요할 때: ERP, HR 시스템, 사내 SSO(통합 로그인), 외부 결제 시스템 등과 긴밀하게 연동해야 한다면 솔루션의 API 한계에 부딪힙니다.

    ③ 데이터 소유권과 보안이 중요할 때: SaaS 솔루션에 올라간 데이터는 해당 회사 서버에 있습니다. 민감한 교육 데이터(임원 교육, 직무 역량 평가 등)를 외부 서버에 두고 싶지 않다면 직접 개발이 맞습니다.

    ④ 수십만 명 이상의 대규모 서비스를 계획할 때: 대규모 트래픽에서 솔루션은 한계를 드러냅니다. 또 사용자 수에 비례해 솔루션 비용이 올라가면, 어느 시점부터는 직접 개발이 더 경제적입니다.

    ⑤ 브랜딩과 UX가 핵심 경쟁력일 때: 솔루션은 결국 비슷하게 생겼습니다. 서비스 자체의 UI/UX가 차별점이 되어야 한다면, 커스텀이 필요합니다.

    비용 현실적으로 보기

    많은 분들이 “커스텀 개발이 비싸니까 솔루션 쓰겠다”고 생각합니다. 단기적으로는 맞는 판단일 수 있습니다. 하지만 5년 이상의 관점에서 보면 달라집니다.

    항목기성 솔루션커스텀 개발
    초기 비용낮음 (월 구독)높음 (개발비)
    5년 누적 비용구독료가 쌓임유지보수만 발생
    기능 커스터마이징제한적무제한
    데이터 소유권솔루션 업체 서버직접 소유
    서비스 종료 리스크있음없음

    특히 솔루션 업체가 서비스를 종료하거나 요금 정책을 바꿀 때의 리스크를 간과하는 경우가 많습니다.

    중간 선택지: 오픈소스 기반 커스터마이징

    Moodle처럼 오픈소스 LMS를 기반으로 커스터마이징하는 방식도 있습니다. 초기 비용을 낮추면서 어느 정도의 자유도를 확보할 수 있습니다.

    다만 오픈소스 커스터마이징은 “원래 없던 기능을 새로 만드는 것”보다 어려울 수 있습니다. 기존 코드 구조를 이해하고 그 안에서 작업해야 하기 때문입니다.

    결론

    정답은 없습니다. 현재 단계, 예산, 필요한 기능, 장기 계획에 따라 달라집니다.

    • MVP 수준으로 빠르게 검증하고 싶다 → 솔루션
    • 특수 기능이 있거나, 대규모 서비스를 목표로 한다 → 커스텀 개발
    • 그 사이 어딘가에 있다 → 전문가와 함께 요구사항을 먼저 정리하세요

    디비컨설팅은 양쪽 모두 경험이 있습니다. 어떤 선택이 맞는지 모르겠다면, 요구사항 분석 단계부터 함께 논의해드릴 수 있습니다.

  • 리조트·호텔 앱 개발 가이드 | 반드시 확인해야 할 7가지 핵심 체크포인트

    리조트·호텔 앱 개발 가이드 | 반드시 확인해야 할 7가지 핵심 체크포인트

    GS E&C가 운영하는 강촌·제주 엘리시안 리조트의 웹&앱 리뉴얼 프로젝트를 진행했습니다. ‘스마트 리조트 구축사업’이라는 이름답게, 단순 리뉴얼을 넘어 리조트 운영 자체를 디지털로 전환하는 프로젝트였습니다. 그 과정에서 정리한 리조트·호텔 앱 개발의 핵심을 공유합니다.

    리조트·호텔 앱, 왜 어려운가

    리조트 앱은 일반 쇼핑몰 앱보다 훨씬 복잡합니다. 다루는 서비스 종류가 많고, 각 서비스가 서로 연결되어 있기 때문입니다.

    숙박 예약, 골프장 예약, 스키장 예약, 레스토랑 예약, 스파 예약 — 이 모든 것이 하나의 앱에 들어가야 하고, 각각의 예약이 하나의 포인트 시스템(GS POINT)과 연동되어야 합니다. 개발 전에 이 복잡성을 제대로 이해하지 못하면, 프로젝트가 중반부터 삐걱거립니다.

    체크포인트 1 — 비대면 체크인 구현 방식

    리조트 앱의 가장 핵심 기능입니다. 고객이 프론트 데스크에 줄 서지 않고, 앱에서 체크인을 완료하는 것입니다.

    설계 시 고려해야 할 것들:

    • 투숙객 본인 인증 방법 (카드 번호 확인, 신분증 스캔 등)
    • 객실 키 발급 방식 (앱 내 디지털 키, 픽업 포인트 등)
    • 체크인 가능 시간 설정 및 알림
    • 얼리 체크인/레이트 체크아웃 처리

    엘리시안 프로젝트에서는 특히 다양한 예외 케이스(단체 예약, 패키지 상품, 환불 건 등)를 어떻게 처리할지 초기 기획 단계에서 촘촘하게 정의하는 과정이 중요했습니다.

    체크포인트 2 — 블루투스 도어락 연동

    블루투스를 활용한 스마트 도어락은 리조트 앱의 차별화 포인트입니다. 고객이 앱을 열고 버튼을 누르면 객실 문이 열리는 방식입니다.

    핵심 이슈:

    • iOS/Android 양쪽에서 블루투스 통신 안정성 확보
    • 배터리 절약 (백그라운드에서 블루투스를 항상 켜두면 배터리 소모가 큼)
    • 연결 실패 시 대안 수단 (키카드 병행 운용)
    • 도어락 펌웨어 업데이트 방식

    하드웨어 업체와의 초기 협의에서 SDK(소프트웨어 개발 도구)의 안정성과 문서화 수준을 반드시 확인해야 합니다. 나중에 “지원이 안 된다”는 말을 듣게 되면 일정이 크게 틀어집니다.

    체크포인트 3 — 스마트 오더 (인앱 서비스 주문)

    리조트 내 레스토랑, 룸서비스, 풀 바 등에서 앱으로 주문하고 결제까지 완료하는 기능입니다.

    설계 포인트:

    • 위치 기반 메뉴 노출 (현재 있는 시설의 메뉴만 보여주기)
    • 주문 상태 실시간 업데이트 (접수→준비중→완료)
    • 테이블 번호/위치 연동
    • 현장 직원 앱(주문 받는 쪽)과의 연동

    엘리시안 프로젝트에서 이 기능을 구현하면서 가장 복잡했던 부분은 “다양한 주문 취소/변경 케이스 처리”였습니다. 고객이 음식을 주문했다가 조리 시작 후 취소하는 경우, 부분 변경하는 경우 등 예외 상황을 꼼꼼하게 설계해야 합니다.

    체크포인트 4 — 포인트/멤버십 시스템 연동

    리조트 그룹사 전체의 포인트 시스템(GS POINT 등)과 연동하는 것은 기술적으로 까다로운 작업입니다.

    주의할 점:

    • 외부 포인트 시스템 API의 응답 속도와 안정성
    • 포인트 적립/차감 실패 시 롤백 처리
    • 포인트와 현금 결제 혼합 사용 케이스
    • 포인트 유효기간 및 만료 알림

    이 부분은 서드파티 시스템 의존도가 높아, 초기에 API 문서와 테스트 환경을 충분히 확보한 뒤 개발을 시작해야 합니다.

    체크포인트 5 — 맞춤형 홈 화면 구성

    앱을 열었을 때 “지금 나에게 필요한 것”이 바로 보여야 합니다.

    • 체크인 예정 고객: 체크인 버튼이 가장 크게
    • 투숙 중 고객: 룸서비스, 시설 예약, 체크아웃 버튼
    • 퇴숙 후 고객: 다음 예약 유도, 리뷰 요청

    맥락에 따른 UI 변화를 어떻게 구현할지가 리조트 앱 UX 설계의 핵심입니다.

    체크포인트 6 — 관리자 대시보드

    현장 직원과 관리자가 사용하는 어드민 시스템도 앱 못지않게 중요합니다.

    • 예약 현황 통합 관리 (전 시설)
    • 실시간 체크인/체크아웃 현황
    • 스마트 오더 접수 및 처리
    • 고객 컴플레인 접수 및 처리
    • 매출/이용 통계 리포트

    어드민이 편리해야 현장 직원들이 앱을 제대로 활용하고, 그래야 고객 경험이 살아납니다.

    체크포인트 7 — 오프라인 상황 대비

    리조트 특성상 신호가 약한 지역이 있습니다. 야외 수영장, 지하 주차장, 산 중턱의 슬로프 등. 네트워크 연결이 불안정한 환경에서도 핵심 기능이 동작해야 합니다.

    블루투스 도어락처럼 오프라인에서도 작동해야 하는 기능은 설계 단계부터 이 시나리오를 고려해야 합니다.

    마치며

    리조트 앱은 “잘 만든 앱”이 직접적으로 비즈니스 성과로 연결됩니다. 비대면 체크인으로 프론트 데스크 부담이 줄고, 스마트 오더로 F&B 매출이 오르고, 앱 기반 예약으로 직접 판매 비율이 높아집니다.

    엘리시안 리조트 프로젝트가 성공적으로 마무리된 것도 이 전체 그림을 처음부터 함께 그렸기 때문입니다. 기술적 구현이 목적이 아니라, “리조트 운영이 얼마나 좋아지는가”를 목표로 개발했습니다.

  • 구인구직 앱, 지금 만들면 망하는 이유 — 차별화 전략 없이 시작하면 안 됩니다

    구인구직 앱, 지금 만들면 망하는 이유 — 차별화 전략 없이 시작하면 안 됩니다

    잡코리아, 사람인, 원티드. 구인구직 시장은 이미 강자들이 자리를 잡고 있습니다. 그럼에도 새로운 채용 플랫폼을 만들어야 한다면, 어떻게 차별화할 수 있을까요? 디비컨설팅이 개발한 구인구직 통합 플랫폼 앱 사례를 바탕으로 설명합니다.

    기존 플랫폼의 한계

    잡코리아와 사람인은 공고 중심입니다. 구직자가 공고를 찾아 지원하는 구조. 검색과 필터링이 핵심입니다.

    원티드는 여기에 추천 알고리즘과 커뮤니티를 더했습니다. “나에게 맞는 회사”를 추천해준다는 포지셔닝이 차별점이었습니다.

    그 이후의 차별화 포인트는 어디에 있을까요?

    차별화 전략 1 — 위치 기반 매칭

    “내 근처에 있는 일자리”에 대한 니즈는 분명히 존재합니다. 특히 일용직, 파트타임, 단기 근무를 찾는 경우에는 위치가 가장 중요한 요소입니다.

    구현 포인트:

    • 현재 위치 기반 반경 설정 (예: 3km 이내)
    • 지도 위에서 공고 확인
    • 이동 시간 기반 검색 (지하철 20분 이내 등)
    • 위치 변경 설정 (출퇴근 가능 지역 복수 지정)

    이 기능을 위해 위치 API(Google Maps, 카카오맵 등) 연동이 필수이고, 백그라운드에서 위치를 추적하는 것은 배터리 문제와 개인정보 이슈가 있어 “검색 시 위치 확인” 방식이 현실적입니다.

    차별화 전략 2 — AI 추천 알고리즘

    단순 키워드 검색이 아닌, 사용자의 이력서·경력·관심사·행동 패턴을 분석해 “딱 맞는 공고”를 추천합니다.

    추천의 근거가 되는 데이터:

    • 프로필에 입력한 직무, 경력, 기술
    • 이전에 클릭하고 지원한 공고들
    • 저장한 공고들
    • 체류 시간 (어떤 공고를 오래 봤나)

    중요한 것은 추천 결과의 설명 가능성입니다. “왜 이 공고를 추천했는지”를 사용자에게 보여주는 것이 신뢰를 높입니다. “당신의 Python 경력 3년과 백엔드 관심사에 매칭됩니다” 같은 식으로.

    차별화 전략 3 — 구직자-구인자 상호 평가

    기존 플랫폼은 “구직자가 회사를 평가”하는 구조 (잡플래닛, 블라인드)가 분리되어 있습니다.

    통합 플랫폼에서 양방향 평가를 구현했습니다:

    • 구직자 → 회사: 면접 경험, 근무 환경, 급여 적정성
    • 회사 → 구직자: 면접 태도, 연락 성실도, 직무 적합도

    이 데이터가 쌓이면 “신뢰할 수 있는 구직자”와 “좋은 직장”을 구별하는 기준이 됩니다. 에어비앤비의 호스트-게스트 상호 평가와 유사한 개념입니다.

    차별화 전략 4 — 근로 행정 통합

    채용 후 프로세스까지 플랫폼에서 해결합니다.

    • 근로계약서 전자 서명: 종이 없이 앱에서 계약 체결
    • 사직서 처리: 전자 제출
    • 헤드헌팅 기능: 스카우트 제안 수신 및 관리

    이 기능들은 플랫폼의 “스티키니스”를 높입니다. 채용 이후에도 계속 쓸 이유가 생기기 때문입니다.

    핵심 UX 포인트

    홈 화면 설계: 처음 앱을 열었을 때 무엇을 보여줄 것인가가 핵심입니다. 잡코리아는 검색창, 원티드는 추천 공고, 저희 앱은 위치 기반 공고 + AI 추천을 병렬 노출하는 탭 구조를 택했습니다.

    빠른 지원 플로우: 이력서가 등록된 상태에서 공고에 원클릭 지원이 가능해야 합니다. 지원 과정이 복잡하면 이탈률이 높아집니다.

    알림 최적화: “새 공고”, “면접 요청”, “합격/불합격” 알림이 적시에 오는 것이 중요합니다. 너무 많으면 끄게 됩니다.

    관리자 기능

    채용 담당자 입장에서 필요한 것들:

    • 공고 등록 및 관리
    • 지원자 리스트 및 상태 관리 (서류검토/면접/합격/불합격)
    • 지원자 메시지 발송
    • 채용 통계 (공고별 지원자 수, 전환율 등)

    특히 “지원자 상태 관리”는 칸반 보드(Trello 스타일) 형태로 구현하면 직관적입니다.

    마치며

    구인구직 플랫폼은 “양면 시장(Two-sided Market)” 문제를 가지고 있습니다. 구직자가 많아야 구인 기업이 오고, 구인 기업이 많아야 구직자가 옵니다. 닭이 먼저냐 달걀이 먼저냐의 문제입니다.

    초기 사용자를 어떻게 모을 것인가, 어느 쪽을 먼저 채울 것인가 — 이 전략이 기능 설계만큼 중요합니다. 특정 지역이나 특정 직군에 집중해서 버티컬 마켓을 먼저 장악하는 전략이 가장 현실적입니다.

  • 인도 개발팀 협업, 정말 괜찮을까? | 12년 운영한 IT 회사의 현실 답변

    인도 개발팀 협업, 정말 괜찮을까? | 12년 운영한 IT 회사의 현실 답변

    “인도 개발팀이요? 말이 안 통하지 않나요?” — 영업 미팅에서 가장 많이 받는 질문입니다.

    2013년, 구민규 대표는 인도 콜카타에서 6개월을 지내면서 인도법인을 설립했습니다. 현지 개발자들과 밥을 먹고, 회의를 하고, 가끔 싸우기도 하면서 지금의 인도팀 핵심 멤버들을 만났습니다. 그로부터 12년이 지났고, 그 팀은 지금도 함께 일하고 있습니다.

    인도 개발팀과의 협업에 대해 가장 자주 받는 질문들을 솔직하게 정리해봤습니다.

    Q1. 인도 직원과 직접 소통해야 하나요?

    한국 PM이 듀얼 모니터로 프로젝트 관리 툴을 운영하며 인도 개발팀을 체계적으로 관리하는 한국 오피스 환경
    디비컨설팅의 한국 PM이 클라이언트와 인도 개발팀 사이의 전담 소통 창구를 맡습니다. 클라이언트 입장에서는 국내 개발사와 일하는 것과 동일한 경험입니다.

    아닙니다. 디비컨설팅은 한국 법인 기업이고, 클라이언트 입장에서는 국내 개발 외주사와 일하는 것과 다르지 않습니다. 모든 커뮤니케이션은 한국 PM팀이 담당합니다.

    구조는 이렇습니다.

    • 클라이언트 ↔ 한국 PM : 한국어로 실시간 소통 (카카오톡, 화상미팅, 전화)
    • 한국 PM ↔ 인도 개발팀 : 영어로 직접 소통 (Slack, Jira, 화상미팅)

    해외파 PM과 영어가 모국어 수준인 인도 개발팀이 직접 붙으니 번역 손실이 없습니다. 기존의 “한국어 → 어설픈 번역 → 영어” 과정에서 생기는 오해가 없다는 게 핵심입니다.

    Q2. 품질이 국내 개발사보다 떨어지지 않나요?

    오히려 반대의 경우가 많습니다. 이유는 세 가지입니다.

    첫째, 인도는 IT 인재 풀이 압도적으로 큽니다. 매년 12만 명 이상의 IT 전문 인력이 배출되는 세계 5위 경제대국입니다. 구글, 마이크로소프트, 아마존의 CEO가 인도인이라는 사실은 괜한 얘기가 아닙니다.

    둘째, 저희 인도팀은 ‘구인’한 팀이 아닙니다. 2013년 창업 때부터 함께한 멤버들이 중심입니다. 12년간 같은 프로세스, 같은 문화로 일해온 팀입니다. 프리랜서를 긁어모아 꾸린 팀과는 결이 다릅니다.

    셋째, 고급 개발자 비율이 높습니다. 국내에선 실력 있는 개발자를 고용하는 게 점점 어려워지고 있습니다. 비용 때문에 초급 개발자로 채우는 악순환이 반복되죠. 인도팀은 실리콘밸리에서 주목받는 AI 기능을 실제 프로젝트에 바로 적용할 수 있는 수준의 시니어 개발자들로 구성되어 있습니다.

    Q3. 기획과 디자인도 해외에서 하나요?

    기획과 디자인은 한국팀이 담당합니다.

    한국 PM과 기획자가 클라이언트와 밀착 소통하며 요구사항을 구체화합니다. 다른 개발사가 주 1~2회 미팅을 진행할 때, 저희는 화상미팅·전화·카카오톡을 수시로 활용해 클라이언트의 의도를 최대한 정확히 파악합니다.

    디자인은 한국 감성을 잘 아는 국내 디자이너와, 최신 트렌드와 개발자와의 협업 경험이 많은 인도 디자이너가 시너지를 냅니다. 결과물이 “글로벌 느낌”과 “한국 감성” 사이 어딘가 어색하게 걸치는 문제를 방지하는 구조입니다.

    Q4. 프로젝트 책임은 한국에서 지나요?

    모든 프로젝트는 한국팀 임원진과 PM이 직접 관리합니다.

    해외 외주 개발의 가장 큰 문제는 “결과물에 대한 책임 소재가 불분명해진다”는 점입니다. 일회성 재외주에 불과한 경우, 오류가 생겼을 때 아무도 책임지지 않습니다.

    저희는 다릅니다. 모든 프로젝트를 자회사 내에서 100% 진행합니다. 납품 전 QA 전문팀이 앱과 웹사이트의 모든 시나리오를 문서화해서 체크합니다. 법인 설립 이래 프로젝트 성공률 100% 를 유지하고 있는 이유이기도 합니다.

    Q5. 시간대 차이는 문제가 없나요?

    인도와 한국의 시간 차이는 3시간 30분입니다. 오전 9시에 출근한 한국 PM이 업무를 정리해서 넘기면, 인도팀은 오전 5시 30분부터 받아서 시작합니다. 이 시간 차이가 오히려 장점이 되기도 합니다. 한국팀이 퇴근한 이후에도 인도팀이 개발을 이어가는 구조가 만들어지기 때문입니다.

    물론 긴급 사항이 있을 때는 화상 미팅으로 실시간 대응합니다. 12년간 이 구조로 운영해온 팀이라 어색함이 없습니다.

    정리하며

    인도 개발에 대한 편견 대부분은 “제대로 된 운영 시스템 없이 해외 개발자를 쓴” 경험에서 나옵니다. 언어가 다른 프리랜서를 플랫폼에서 섭외해서 일을 맡기는 것과, 12년간 함께 구축한 한국-인도 통합팀으로 운영하는 것은 완전히 다른 이야기입니다.

    저희의 강점은 단순히 “싸다”가 아닙니다. 동일한 퀄리티를 더 합리적인 비용으로 제공할 수 있는 구조를 만든 것입니다. 삼성물산, GS건설, 하나투어 같은 대기업들이 파트너십을 이어가는 이유가 여기 있습니다.

  • AI 피부 분석·의료 데이터 어노테이션 | 헬스케어 앱 개발 핵심 포인트

    AI 피부 분석·의료 데이터 어노테이션 | 헬스케어 앱 개발 핵심 포인트

    AR Cosmetics AI 피부 분석 앱, Xanacloud 의료 영상 어노테이션 플랫폼. 두 프로젝트 모두 헬스케어와 AI가 만나는 지점에 있습니다. 일반 앱 개발과 어떻게 다른지, 무엇을 더 신경 써야 하는지 정리합니다.

    헬스케어 IT가 일반 앱 개발과 다른 이유

    첫째, 데이터의 민감도가 높습니다. 피부 상태, 초음파 영상, 건강 기록 — 이것들은 일반 사용자 데이터와 차원이 다릅니다. 개인정보 보호법은 물론, 의료 데이터 관련 규제를 별도로 검토해야 합니다.

    둘째, 정확도가 생명입니다. 피부 분석 앱이 잘못된 결과를 내면 사용자가 당황하는 수준이지만, 의료 데이터 분석이 틀리면 실제 의사 결정에 영향을 줄 수 있습니다. AI 정확도 검증 프로세스가 일반 앱보다 훨씬 엄격해야 합니다.

    셋째, 규제 환경이 복잡합니다. 의료기기 소프트웨어(SaMD) 여부, 개인정보 처리 방식, 의료인-환자 관계에서의 앱 역할 등 법적 검토가 개발 초기부터 필요합니다.

    AR Cosmetics — AI 피부 분석 앱

    핵심 기술: 페이스 스캐닝 API

    얼굴을 촬영하면 피부 상태를 분석합니다. 잡티, 주름, 피부결, 유분 지수, 홍조, 다크서클, 탄력, 피부톤, 모공 — 이 항목들을 수치로 보여줍니다.

    이를 위해 AI 피부 스캐닝 API를 연동했습니다. 자체 AI를 개발하는 것은 대규모 학습 데이터와 ML 팀이 필요하므로, 검증된 서드파티 API를 활용하는 것이 현실적입니다.

    구현 시 핵심 포인트

    카메라 접근 권한과 사용자 동의: iOS, Android 모두에서 카메라 접근 권한 요청과 데이터 사용 동의를 명확히 받아야 합니다. 특히 얼굴 데이터는 민감 정보로 분류되므로 개인정보처리방침에 명시적으로 포함해야 합니다.

    분석 결과 시각화: 수치만 보여주면 사용자가 의미를 이해하기 어렵습니다. 점수를 게이지나 그래프로 시각화하고, “평균 대비 어떤 수준인가”를 쉽게 이해할 수 있게 해야 합니다.

    언어 처리: 피부과 용어를 일반 사용자도 이해할 수 있는 언어로 풀어쓰는 것이 UX의 핵심이었습니다.

    간편 로그인: 네이버, 카카오, 애플 ID를 통한 소셜 로그인으로 진입 장벽을 낮췄습니다.

    Xanacloud — 의료 영상 어노테이션 플랫폼

    어노테이션이란?

    AI 의료 진단 모델을 학습시키려면 “정답 데이터”가 필요합니다. 초음파 영상에서 “이 부분이 갑상선”, “이 부분이 종양”이라고 표시하는 작업이 어노테이션(Annotation)입니다. 이 작업을 전문 의료진이 효율적으로 할 수 있도록 지원하는 플랫폼을 만든 것입니다.

    플랫폼 구조

    관리자(Xanacloud): 카테고리와 의료 영상 이미지를 업로드하고, 프로젝트를 구성해 특정 의료진(작업자)에게 배정합니다.

    작업자(의료진): 배정받은 이미지를 플랫폼에서 직접 어노테이션 작업합니다. 영역을 선택하고, 카테고리를 태깅합니다.

    결과물 검수 및 다운로드: 작업 완료된 이미지를 확인하고, AI 학습에 사용할 수 있는 형태로 다운로드합니다.

    핵심 기술 과제

    이미지 처리 성능: 의료 영상은 일반 사진보다 해상도가 높고 파일이 큽니다. 웹에서 이 이미지를 빠르게 로드하고, 매끄럽게 확대/축소/이동하는 것이 UX의 핵심이었습니다.

    정밀한 영역 선택 도구: 픽셀 단위의 정확한 영역 선택이 필요합니다. 브러시, 폴리곤, 사각형 등 다양한 선택 도구를 지원해야 합니다.

    작업 이력 관리: 어노테이션 작업의 수정/취소 이력, 작업자별 진행률 추적이 필요합니다.

    데이터 보안: 의료 영상은 환자 정보를 담고 있을 수 있습니다. 데이터 접근 권한을 엄격히 관리하고, 전송 암호화를 적용해야 합니다.

    헬스케어 앱 개발 시 체크리스트

    기획 단계

    • 의료기기 소프트웨어(SaMD) 해당 여부 법적 검토
    • 개인정보 처리 방침 초안 작성 (법률 검토 포함)
    • 사용자 동의 프로세스 설계

    개발 단계

    • 데이터 암호화 (전송 중, 저장 시)
    • 접근 권한 최소화 원칙 적용
    • 민감 데이터 로깅 방지

    출시 전 검토

    • 개인정보보호위원회 신고 여부 확인
    • 앱스토어 심사 기준 사전 확인 (헬스케어 앱은 별도 기준 적용)
    • 의사 등 전문가 자문 (의료적 내용 정확성 검토)

    마치며

    헬스케어와 AI의 결합은 앞으로 더 빠르게 확산될 것입니다. 피부 분석부터 시작한 AR Cosmetics가 향후 성분 맞춤 제품 추천, 피부 변화 트래킹으로 발전할 수 있는 것처럼, Xanacloud의 어노테이션 플랫폼이 AI 진단 정확도를 높이는 데 직접 기여하는 것처럼.

    이 분야에서 중요한 건 “기술이 얼마나 뛰어난가”와 “사용자가 얼마나 신뢰할 수 있는가” 두 가지입니다. 두 번째가 없으면 첫 번째는 의미가 없습니다.

  • 커뮤니티 플랫폼 개발, 독서·취미 모임 앱의 핵심 기능은 무엇인가

    커뮤니티 플랫폼 개발, 독서·취미 모임 앱의 핵심 기능은 무엇인가

    캠핑 SNS ‘들살이’, 매일 밤 9시 책모임 앱 ‘ㅊㅊㅊ’, 교보생명 사내벤처 독서 플랫폼 ‘글펍’. 세 가지 서로 다른 커뮤니티 앱을 개발하면서 발견한 공통 패턴이 있습니다. 취미 기반 커뮤니티 앱을 기획 중이라면 이 글이 도움이 될 겁니다.

    커뮤니티 앱이 어려운 진짜 이유

    기술적으로 어려운 게 아닙니다. 피드, 댓글, 좋아요는 이제 흔한 기능입니다.

    진짜 어려운 건 “사람들이 실제로 쓰게 만드는 것” 입니다. 커뮤니티는 초기 사용자 수가 임계점을 넘어야 자생적으로 돌아갑니다. 그 임계점에 도달하기 전까지 어떻게 앱을 살아있게 만드느냐가 커뮤니티 앱의 핵심 설계 과제입니다.

    세 가지 커뮤니티 앱 비교

    들살이ㅊㅊㅊ글펍
    테마캠핑 SNS독서 모임독서/글쓰기
    매칭 방식자유 팔로우랜덤 매칭신청 기반
    핵심 인터랙션포스팅, 장소 공유음성 통화글 작성, 댓글
    운영 주체사용자 자율시스템(자동화)매니저 있음

    세 앱이 같은 “커뮤니티”라는 카테고리에 있지만, 설계 방향이 완전히 다릅니다.

    핵심 기능 1 — 매칭 메커니즘

    커뮤니티 앱에서 사용자가 “누구와 연결되는가”는 앱의 성격을 결정합니다.

    자유 팔로우형 (들살이): 사용자가 원하는 사람을 팔로우합니다. 인스타그램과 유사한 구조로, 초기 팔로우 씨드 유저 확보가 중요합니다. 콘텐츠 피드 알고리즘(어떤 게시글을 위에 보여줄 것인가)이 앱 경험을 좌우합니다.

    랜덤 매칭형 (ㅊㅊㅊ): 매일 밤 9시, 시스템이 자동으로 사용자를 매칭합니다. 이 구조는 사용자가 많지 않아도 “오늘 밤의 모임”이 보장된다는 강점이 있습니다. 매칭 알고리즘(어떤 기준으로 매칭하는가)이 앱의 핵심 기술입니다.

    신청 기반 (글펍): 모임이 개설되면 사용자가 신청합니다. 진입 장벽이 있어 참여자의 질을 높이고, 매니저가 있어 운영이 안정적입니다.

    어떤 매칭 방식이 맞는지는 “우리 서비스의 핵심 가치가 무엇인가”에서 출발해야 합니다.

    핵심 기능 2 — 실시간 커뮤니케이션

    취미 기반 커뮤니티에서 실시간 소통 기능은 앱 활성화의 핵심입니다.

    텍스트 채팅: 기본 중의 기본. 들살이와 글펍 모두 포함.

    음성 통화 (ㅊㅊㅊ): 아고라(Agora) API를 사용해 실시간 음성 통화 기능을 구현했습니다. 독서 모임의 특성상 텍스트보다 음성이 훨씬 자연스러운 대화 경험을 만듭니다. 음성 품질, 딜레이, 네트워크 불안정 시 처리 방식이 구현의 핵심입니다.

    실시간 알림: 이벤트 발생 시 즉각적인 알림이 필요합니다. 댓글, 좋아요, 새 팔로워, 모임 시작 알림 등. Firebase 기반 푸시 알림을 활용하되, 알림이 과도하면 오히려 사용자가 이탈합니다. 알림 설정을 세밀하게 제어할 수 있어야 합니다.

    핵심 기능 3 — 콘텐츠와 데이터 관리

    커뮤니티 앱은 사용자가 생성하는 콘텐츠가 자산입니다.

    들살이의 경우: 캠핑 장소, 장비 사진, 여행 후기 등 미디어 중심 콘텐츠. 이미지 업로드 최적화, 카카오맵 API 연동(장소 검색), 상품 DB화가 핵심이었습니다.

    ㅊㅊㅊ의 경우: 모임에서 쌓인 데이터(투표, 성향 체크)가 사용자 프로필에 대시보드로 노출됩니다. 이 데이터가 쌓일수록 앱 경험이 개인화되는 구조입니다.

    글펍의 경우: 글과 댓글이 핵심 콘텐츠. 차수별로 다른 주제, 매니저 글, 멤버 글, 후기 — 이를 체계적으로 구조화하는 DB 설계가 중요했습니다.

    핵심 기능 4 — 사용자 프로필과 신뢰 시스템

    커뮤니티에서 “이 사람이 어떤 사람인가”를 알 수 있는 것이 참여를 높입니다.

    닉네임, 프로필 이미지, 관심사 태그는 기본입니다. 여기에 더해:

    • 활동 이력: 참여한 모임, 작성한 글, 공유한 장소 등
    • 평판 시스템: ㅊㅊㅊ처럼 모임 후 상대방 성향 체크
    • 레벨/배지 시스템: 활동에 따른 보상으로 지속 참여 유도

    사용자가 “이 앱에서 나의 역사”가 쌓인다고 느낄 때 이탈률이 낮아집니다.

    핵심 기능 5 — 관리자 도구

    커뮤니티는 방치하면 죽습니다. 관리자가 개입할 수 있는 도구가 있어야 합니다.

    • 콘텐츠 신고 처리 시스템
    • 사용자 제재 (경고, 정지, 영구 차단)
    • 커뮤니티 분위기를 위한 큐카드/가이드라인 관리 (ㅊㅊㅊ)
    • 활성화 이벤트 운영 도구
    • 통계 대시보드 (DAU, 게시글 수, 모임 완료율 등)

    커뮤니티 앱 기획 시 먼저 답해야 할 질문들

    개발 시작 전에 이것들을 먼저 정의하세요.

    1. 우리 커뮤니티의 핵심 액션은 무엇인가? (글 쓰기, 모임 참여, 장소 공유 등)
    2. 사용자가 처음 가입했을 때 무엇을 해야 하는가? (온보딩 플로우)
    3. 콘텐츠가 없을 때 어떻게 앱을 채울 것인가? (닭이 먼저냐 달걀이 먼저냐 문제)
    4. 어떻게 사용자를 매일 오게 만들 것인가? (리텐션 전략)
    5. 운영 리소스가 얼마나 있는가? (자동화 vs 사람 운영)

    마치며

    세 가지 커뮤니티 앱을 통해 배운 가장 큰 교훈은 이것입니다. “기능이 많다고 커뮤니티가 활성화되지 않는다.”

    ㅊㅊㅊ는 기능이 단순합니다. 매일 밤 9시에 랜덤으로 매칭되어 음성 통화로 책 이야기를 나눈다 — 이것이 전부입니다. 그러나 이 단순한 메커니즘이 매일 사용자를 앱으로 불러오는 힘이 있습니다.

    좋은 커뮤니티 앱은 기능 목록이 아니라, 사람들이 다시 오고 싶은 경험을 설계하는 것입니다.

  • 공장 자동화 서비스 거래 플랫폼 — LS Electric 테크스퀘어로 배운 복잡한 B2B 매칭 로직

    공장 자동화 서비스 거래 플랫폼 — LS Electric 테크스퀘어로 배운 복잡한 B2B 매칭 로직

    717개 수요 기업과 81개 공급 기업을 연결하는 플랫폼. LS Electric 테크스퀘어 프로젝트는 디비컨설팅이 개발한 가장 복잡한 B2B 매칭 시스템 중 하나입니다. 스마트 팩토리 분야의 플랫폼 비즈니스를 어떻게 구현했는지 공유합니다.

    공장 자동화 서비스 시장의 특성

    스마트 팩토리, 공장 자동화는 기술적으로 복잡하고 비용이 큰 영역입니다. 수요 기업(자동화가 필요한 제조사)과 공급 기업(자동화 솔루션 제공사) 사이에 정보 비대칭이 큽니다.

    “어떤 자동화 솔루션이 우리 공장에 맞는지 모르겠다”는 수요 기업과 “우리 솔루션이 필요한 공장을 찾기 어렵다”는 공급 기업 사이를 연결하는 것이 테크스퀘어의 역할입니다.

    플랫폼의 핵심 구조

    수요 기업: 자동화가 필요한 공정, 현재 문제, 예산 등을 입력합니다. 이 정보를 기반으로 적합한 솔루션과 공급 기업을 추천받습니다.

    공급 기업: 자신들의 솔루션, 적용 사례, 역량을 등록합니다. 매칭된 수요 기업에게 제안을 보내고 상담을 진행합니다.

    관리자(LS Electric): 큐레이터와 멘토를 통해 매칭 프로세스를 지원하고, 보고서 작성을 돕습니다.

    기술적 핵심 1 — 수백 개의 보고서를 조합하는 알고리즘

    수요 기업이 설문에 답변을 입력하면, 시스템이 자동으로 그 답변에 맞는 보고서를 조합해 제공합니다.

    예를 들어 “식품 제조업 / 포장 공정 / 인력 3명 교체 목표 / 예산 2억 이하”라는 답변에 해당하는 보고서 구간들을 찾아서 하나의 문서로 합칩니다.

    이를 위해 보고서를 모듈화하고, 각 모듈에 조건 태그를 달아야 합니다. 보고서 관리 자체가 하나의 CMS(콘텐츠 관리 시스템)가 됩니다.

    기술적 핵심 2 — 복잡한 매칭 로직을 직관적 UX로

    수요-공급 매칭 알고리즘은 여러 변수를 동시에 고려합니다:

    • 공정 유형 (용접/조립/검사/포장 등)
    • 업종
    • 공장 규모
    • 예산 범위
    • 지역 (현장 방문 가능성)
    • 기존 설비와의 호환성

    이 복잡성을 사용자가 느끼지 않도록 숨기는 것이 UX 설계의 핵심이었습니다. 수요 기업은 간단한 설문을 채우고, 결과는 명확한 추천 리스트로 받습니다.

    기술적 핵심 3 — 이메일/문자 관리 시스템

    매칭 이후 커뮤니케이션을 플랫폼 안에서 관리합니다.

    • 매칭 알림 자동 발송
    • 상담 예약 확인 및 리마인더
    • 제안서 접수 알림
    • 일정별 이벤트 알림

    이 모든 것을 관리자가 직접 보내지 않고 시스템이 자동화합니다. 이메일 발송 서버(SendGrid, AWS SES 등)와 문자 발송 API 연동이 필요합니다.

    기술적 핵심 4 — 메뉴 추가와 재정렬 기능

    테크스퀘어는 서비스가 확장되면서 지속적으로 메뉴와 콘텐츠가 추가될 것을 전제로 설계됐습니다.

    관리자가 개발자 도움 없이:

    • 새 카테고리/메뉴를 추가하고
    • 순서를 바꾸고
    • 임시로 비활성화할 수 있어야 합니다.

    이를 위한 드래그앤드롭 기반의 메뉴 관리 CMS를 구축했습니다.

    B2B 매칭 플랫폼 설계 원칙

    신뢰가 먼저다: B2B 거래에서 플랫폼의 역할은 “광고를 태우는 것”이 아니라 “믿을 수 있는 파트너를 연결하는 것”입니다. 공급 기업의 레퍼런스 검증, 적용 사례 콘텐츠가 신뢰의 근거가 됩니다.

    긴 판매 사이클에 맞게 설계하라: 스마트 팩토리 도입 결정은 빠르면 수개월, 길면 1년 이상 걸립니다. 잠재 고객을 장기간 관리하고 육성(nurturing)하는 CRM 기능이 플랫폼에 통합되어야 합니다.

    정보의 비대칭을 줄여라: 수요 기업이 “이 기술이 우리한테 맞는지 모르겠다”는 상태에서 구매 결정을 내리기 어렵습니다. 업종별 자동화 가이드, 도입 사례, ROI 계산기 같은 교육 콘텐츠가 전환을 높입니다.

    마치며

    LS Electric 테크스퀘어 프로젝트는 규모와 복잡성 면에서 도전적인 프로젝트였습니다. 717개 기업, 복잡한 매칭 로직, 자동화된 보고서 조합 — 이 모든 것을 사용자가 “간단하게” 느끼도록 만드는 것이 목표였습니다.

    스마트 팩토리는 제조업의 미래입니다. 이 시장에서 플랫폼 비즈니스를 하려는 기업이 있다면, 기술적 완성도만큼이나 “어떻게 시장 참여자들의 신뢰를 얻을 것인가”에 집중하기를 권합니다.

  • 스마트 빌딩 앱 개발 | 핵심 기능과 설계 전략 – 센트로폴리스·센터필드 사례

    스마트 빌딩 앱 개발 | 핵심 기능과 설계 전략 – 센트로폴리스·센터필드 사례

    강남 테헤란로에 위치한 프라임 오피스 빌딩, 센트로폴리스센터필드. 두 프로젝트 모두 K.awards를 수상한 디비컨설팅의 대표 포트폴리오입니다. 그 개발 과정에서 배운 스마트 빌딩 앱의 핵심을 정리합니다.

    스마트 빌딩 앱이란?

    단순히 “건물 소개 페이지”가 아닙니다. 스마트 빌딩 앱은 입주사와 방문객의 모든 건물 경험을 디지털로 연결합니다. 시설 예약, 방문객 관리, 민원 접수, 엘리베이터 자동 호출까지 — 기존에 사람이 처리하던 업무를 앱 하나로 통합하는 것입니다.

    국내 프라임 오피스 시장에서 이 수요는 빠르게 증가하고 있습니다. 입주사들이 “스마트 시스템이 있는 건물”을 선택 기준으로 보기 시작했기 때문입니다.

    핵심 기능 1 — QR 기반 출입 통제

    스마트 빌딩 앱의 가장 기본이자 가장 중요한 기능입니다. 방문객이 건물에 입장하는 과정을 생각해보세요.

    기존 방식: 로비 데스크에서 신분증 확인 → 방문증 수령 → 목적지 층 이동

    스마트 빌딩 방식: 앱에서 QR 코드 발급 → QR 스캔으로 스피드게이트 통과 → 엘리베이터 자동 호출

    센터필드 프로젝트에서 저희가 구현한 시스템입니다. 하드웨어 업체와의 협업이 필수인데, API 연동 방식과 보안 요구사항을 초기에 명확히 정의하지 않으면 개발 중반에 큰 변수가 생깁니다. 이 부분을 놓치는 프로젝트가 생각보다 많습니다.

    핵심 기능 2 — 시설 예약 시스템

    피트니스 센터, 회의실, 라운지, 루프탑 — 건물 내 공용 시설을 앱으로 예약합니다. 단순해 보이지만 설계가 까다롭습니다.

    고려해야 할 것들:

    • 입주사별 예약 가능 횟수/시간 제한
    • 실시간 예약 현황 반영
    • 취소 및 환불 정책
    • 관리자 대시보드 (예약 현황, 통계)

    센트로폴리스에서는 실시간 혼잡도 측정 기능도 추가했습니다. 특정 시설이 얼마나 붐비는지 사전에 확인하고 갈 수 있도록 한 것입니다.

    핵심 기능 3 — 방문객 예약 및 관리

    입주사 임직원이 외부 방문객을 사전 등록하는 기능입니다. 방문객은 등록된 이메일/SMS로 QR 코드를 받고, 당일 로비에서 그것만으로 입장합니다.

    관리자 입장에서는 “어떤 방문객이 언제, 어디로 방문했는지” 기록이 남습니다. 보안이 중요한 건물일수록 이 기능의 중요도가 높아집니다.

    핵심 기능 4 — 민원 접수 및 건물 관리

    냉난방 연장, 소등 연장, 시설 불편사항 신고 — 기존에는 관리 데스크에 전화하거나 직접 방문해야 했던 것들을 앱에서 처리합니다.

    입주사 입장에서는 편리하고, 건물 관리팀 입장에서는 모든 민원이 기록으로 남아 체계적 관리가 가능합니다. 요청 상태 확인(접수→처리중→완료)도 앱에서 실시간으로 볼 수 있어야 합니다.

    핵심 기능 5 — 커뮤니티 기능

    이 부분은 건물 성격에 따라 차이가 있습니다. 입주사가 많은 대형 오피스 빌딩이라면, 입주사 간 정보 공유나 공지사항 전달 채널로 활용할 수 있습니다.

    센트로폴리스처럼 입주사 수가 많고 커뮤니티가 활발한 경우, 이 기능이 앱의 활성화에 직접적인 영향을 줍니다.

    개발 전에 반드시 확인해야 할 것들

    스마트 빌딩 앱 개발을 시작하기 전, 아래 다섯 가지를 먼저 정의하세요.

    1. 연동할 하드웨어가 무엇인가 (스피드게이트, 엘리베이터, CCTV, 주차 시스템 등)
    2. 기존 건물 관리 시스템(BMS, ERP)과 연동이 필요한가
    3. 입주사별 권한 구조를 어떻게 가져갈 것인가
    4. 보안 요구사항 수준은 어느 정도인가 (금융기관, 법무법인 입주 건물 등은 특히 엄격)
    5. 관리자 대시보드의 역할 범위

    이 다섯 가지가 불명확한 상태로 개발이 시작되면, 중간에 방향이 바뀌면서 일정과 비용이 불어납니다.

    마치며

    센트로폴리스센터필드 프로젝트는 모두 K.awards 2023 UI/UX 우수상을 수상했습니다. 기능의 완성도와 사용자 경험, 두 가지를 모두 잡은 결과였습니다.

    스마트 빌딩 앱은 “만들었다”로 끝나지 않습니다. 입주사들이 매일 쓰는 서비스가 되어야 하고, 그러려면 UX가 직관적이어야 하며, 출시 후 안정적인 유지보수가 뒷받침되어야 합니다. 이 전체 사이클을 함께 고민할 파트너를 선택하는 것이 프로젝트 성공의 첫 번째 조건입니다.

  • 앱 개발 외주, 왜 초급 개발자 문제가 반복될까? | 외주 구조의 진짜 문제

    앱 개발 외주, 왜 초급 개발자 문제가 반복될까? | 외주 구조의 진짜 문제

    “견적 받았는데 생각보다 비싸서 다른 곳에 맡겼어요. 근데 결과물이 너무 별로라…” — 개발 외주를 경험한 분들에게 자주 듣는 이야기입니다.

    왜 이런 일이 반복될까요? 단순히 “나쁜 개발사를 골랐기 때문”이 아닙니다. 국내 IT 외주 시장 자체에 구조적인 문제가 있습니다.

    국내 개발자 시장의 현실

    지금 국내 개발자 시장은 수요가 공급을 훨씬 초과하고 있습니다. 괜찮은 개발자는 대기업이나 스타트업으로 빠져나가고, 외주 시장에 남는 풀은 점점 얕아지고 있습니다.

    이 상황에서 외주 업체들이 선택하는 방법은 대부분 같습니다. 비용을 낮추기 위해 초급 개발자를 고용합니다. 단가가 낮으니 더 많은 프로젝트를 수주할 수 있고, 수익도 맞출 수 있습니다.

    문제는 초급 개발자에게 기획 검토, 설계, 개발, QA를 한꺼번에 맡기면 어떻게 되느냐입니다.

    초급 개발자 중심 외주의 3가지 리스크

    1. 아키텍처 설계가 부실합니다

    초급 개발자는 코드는 짤 수 있지만, “이 서비스가 나중에 어떻게 확장될지”를 고려한 설계를 하기 어렵습니다. 처음엔 잘 돌아가는 것처럼 보여도, 유저가 늘거나 기능을 추가하려 할 때 전체를 다시 짜야 하는 상황이 생깁니다.

    2. QA가 허술합니다

    많은 업체에서 QA를 별도 팀이 아닌 개발자가 직접 진행합니다. 자기가 만든 걸 자기가 테스트하면 놓치는 케이스가 많을 수밖에 없습니다. 출시 후 버그 신고가 쏟아지는 건 이 때문입니다.

    3. 책임질 사람이 없습니다

    많은 외주사가 핵심 개발을 프리랜서나 재외주로 해결합니다. 원청-외주-재외주 구조가 되면, 문제가 생겼을 때 “그건 제가 한 게 아닌데요”가 됩니다. 클라이언트는 어디에 물어봐야 할지 모르는 상황에 놓입니다.

    “싼 곳에 맡겼다가 비싼 값 치른다”는 말의 의미

    처음 견적이 싸더라도, 이후에 발생하는 비용을 합산하면 이야기가 달라집니다.

    • 출시 후 버그 수정 비용
    • 기능 추가 시 “전체 재개발이 필요합니다” 통보
    • 개발사와의 분쟁, 소송 비용
    • 서비스 중단으로 인한 기회비용

    이 모든 것을 고려하면, 처음부터 제대로 된 팀에 맡기는 게 훨씬 저렴합니다.

    그렇다면 올바른 개발사 선택 기준은?

    견적 금액보다 먼저 확인해야 할 것들이 있습니다.

    ① 개발팀이 정직원인가, 프리랜서 중심인가

    프리랜서 중심의 팀은 프로젝트가 끝나면 흩어집니다. 이후 유지보수나 추가 개발을 위해 연락했을 때 “담당자가 바뀌었습니다”가 되는 경우가 많습니다. 모든 개발자가 정직원인 팀은 팀워크와 커뮤니케이션 퀄리티가 다릅니다.

    ② 전담 PM이 있는가

    개발자가 PM 역할을 겸하는 구조는 위험합니다. 기술적 구현에 집중해야 할 사람이 일정 관리, 클라이언트 소통까지 담당하면 어느 것도 제대로 되지 않습니다.

    ③ QA 전문팀이 별도로 있는가

    개발팀과 QA팀이 분리된 구조인지 확인하세요. 개발자가 직접 테스트하는 것과 QA 전문가가 모든 시나리오를 문서화해서 체크하는 건 결과물의 완성도가 다릅니다.

    ④ 포트폴리오와 레퍼런스를 실제로 확인하라

    “~와 비슷한 프로젝트를 해봤습니다”가 아니라, 실제 서비스가 운영 중인 레퍼런스를 요청하세요. 직접 앱을 다운받아 써보는 것이 가장 빠릅니다.

    ⑤ 납품 이후 유지보수 계획을 물어라

    많은 외주사가 납품 후에는 연락이 뜸해집니다. “납품 후 어떻게 대응하느냐”를 계약 전에 명확히 해두세요.

    디비컨설팅이 다른 이유

    저희는 2021~2022년 2년 동안 100개 이상의 프로젝트를 100명의 IT 전문가와 함께 100% 완료율로 마쳤습니다. 이게 가능한 건 운이 좋아서가 아닙니다.

    모든 직원이 정직원이고, PM팀과 QA팀이 별도로 있으며, 인도 자회사의 고급 개발자들과 12년간 맞춰온 호흡이 있기 때문입니다.

    개발 외주를 고민 중이시라면, 견적 비교 전에 위 다섯 가지를 먼저 확인해보세요.