We Challenged 10 Engineers to Fix India''s Government Websites

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

We Challenged 10 Engineers to Fix India’s Government Websites를 중심으로, 공공서비스 개선의 출발점은 이용자가 막히는 순간이다. 13,694건의 지원에서 최종 10팀을 선정한 경연은 사기 신고, 헌혈자 연를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

1. 공공서비스 개선의 출발점은 이용자가 막히는 순간이다. 13,694건의 지원에서 최종 10팀을 선정한 경연은 사기 신고, 헌혈자 연결, 민원, 비자, 토지 검증 등 생활 속 불편을 다뤘다. 심사에서는 유용성, 수혜자 수, 생활에 미치는 영향과 즉시 구현 가능성을 중시했다.
2. 긴급 서비스는 필요한 사람에게 빠르게 연결하는 것이 핵심이다. 사이버 사기 신고안은 음성 전사와 신고·은행 연락·진행 추적으로 초기 대응 부담을 줄였다. 혈액 서비스는 위치와 혈액형, 헌혈 자격을 바탕으로 응답 가능한 헌혈자를 연결하고 WhatsApp으로 요청을 전달했다. Blood Boys가 1위를 차지했다.
3. 공공정보 공개는 최신성과 후속 행동이 뒷받침돼야 효과를 낸다. Nagric은 담당 공무원과 입찰·계약 정보를 연결해 책임을 확인하게 했다. 다만 벵갈루루 연락처의 유효성이 확인되지 않았고, 실제 조치 여부를 추적하는 기능도 추가 과제로 남았다.
4. 비자와 토지 서비스는 통합 화면의 편의성과 실제 처리 능력 사이에 간극이 있다. 비자 개선안은 자격 확인과 가족 신청 관리를 앞당겼지만 공식 발급 시스템과 연결되지 않은 UI다. Naksha는 지도와 지적도를 연결했으나 현재 구현 지역은 우다이푸르이며, 원천 기록 접근과 소유권·소송 검증이 제약이다.
5. AI 안내와 대행은 다음 행동을 분명하게 만들 때 가치가 커진다. Ketu는 기업 신고 절차와 양식 입력을 안내하고, Rail Setu는 같은 열차의 구간별 좌석 조합과 음성 예약을 제안했다. 반면 세금 안내의 기존 서비스 대비 차별성, 서비스 연계 도구의 사용자 검증, 브라우저 AI의 개인정보 불안은 해결해야 할 문제로 제기됐다.

🧩 배경과 문제 정의

• 인도 공공서비스 웹사이트의 복잡한 화면, 접근하기 어려운 정보, 불안정한 신청 절차가 시민과 방문객의 이용을 막는다. 개발자 경연은 이러한 문제를 실제 서비스 설계로 개선하는 데 초점을 둔다.
• 사이버 사기 신고와 긴급 혈액 확보는 대응 속도가 중요하지만, 기존 시스템은 필요한 정보를 찾고 관계자에게 전달하는 과정에서 마찰을 만든다.
• 지방정부 사업, 비자 신청, 토지 검증에서도 흩어진 정보를 통합하는 것만으로는 충분하지 않다. 정보의 최신성, 실제 업무 연동, 이용 동기, 후속 조치까지 확보해야 개선 효과를 낼 수 있다.

🕒 시간순 섹션별 상세정리

1. 공공서비스 개선을 위한 개발자 경연

• 13,694건의 지원에서 250명으로 후보를 줄이고 최종 참가 10팀을 선정했다. 공공서비스 이용에서 겪은 불편을 해결할 개발자에게 무대와 인센티브를 제공하는 것이 경연의 출발점이다 [00:58]
• 참가자는 10분 동안 제안을 발표하고 심사위원과 2분간 질의응답을 진행한다. 우승자에게는 샌프란시스코 여행 기회도 제공된다 [02:03]

2. 음성 기반 사이버 사기 신고와 초기 대응

• 은행 직원을 사칭한 전화에 OTP를 알려준 고령 피해자 사례는 복잡한 사이버 범죄 신고 화면의 접근성 문제를 드러낸다. 음성 메시지를 Whisper API와 GPT 4.0으로 처리해 피해 경위를 전사하는 방식으로 입력 부담을 줄인다 [03:24]
• 은행에 이메일을 보내는 기능과 FIR 신고 기능을 간단한 클릭으로 연결한다. 범죄 발생부터 신고까지의 한 시간을 피해금 회수 가능성이 가장 높은 ‘골든아워’로 보고 초기 대응 속도를 높이는 데 집중한다 [03:55]

3. 신고 서비스의 확장성과 실제 이용 가능성

• 대규모 도입에는 경찰 시스템과의 연계, 담당자의 책임 추적, 관료적 절차가 걸림돌로 남는다. 12개 언어를 지원하도록 만들었지만 지역별 방언과 예외 상황에 대한 대응도 확장 과제다 [05:11]
• 고령 피해자가 가족에게 도움을 요청하는 현실 때문에 대상 시장과 이용 동기가 약할 수 있다는 우려가 나온다. 가족의 도움을 받을 수 없는 상황을 위한 WhatsApp 봇과, 피해금 회수액의 10%를 받는 대행 서비스 구상이 대안으로 드러난다 [05:54]

4. 긴급 혈액 수요와 접근하기 어려운 헌혈자 정보

• 정부의 혈액 플랫폼에는 등록 헌혈자 280만 명이 있지만, 긴급 상황에서 이들에게 접근하기 어렵다는 문제가 제기된다. 개선안은 필요한 순간에 응답 가능하고 헌혈 자격과 혈액형이 맞는 사람을 연결하는 데 초점을 둔다 [08:12]
• ‘지금 혈액 찾기’에서 환자의 혈액형과 위치를 받아 가까운 혈액은행을 찾는다. 인도 지역의 12%가 가장 가까운 혈액은행에서 100km 넘게 떨어져 있다는 수치를 근거로, 이동이 어려우면 주변 헌혈자 검색으로 전환하도록 설계했다 [09:10]

5. 환자 요청과 헌혈자 응답을 연결하는 흐름

• 환자의 나이·성별·필요 혈액량을 입력하면 호환 혈액형을 포함한 요청 메시지를 자동으로 만든다. 요청을 보낸 뒤에는 도움을 수락한 헌혈자가 화면에 나타나는 흐름을 구현했다 [09:37]
• 헌혈자는 WhatsApp 요청을 수락하거나 무시할 수 있고, 간단한 자격 확인을 거친 뒤 연락처를 교환한다. 최근 3개월 내 헌혈 사실을 서비스에 기록한 사람에게는 요청 알림을 보내지 않는다 [10:18]

6. 헌혈 공급 확대의 인센티브와 낮은 이용 빈도

• 연간 혈액 수집량은 약 1,100만 단위, 수요는 약 1,600만 단위로 드러난다. 이미 도움을 주려는 사람은 있지만 요청이 흩어져 있어 환자와 연결하는 조직적인 경로가 부족하다는 것이 해결하려는 문제다 [11:17]
• 자발적인 참여만으로 대규모 확장이 가능한지를 두고 의견이 갈린다. 인도에서 헌혈 대가 지급이 법적으로 허용되지 않는다는 지적에 따라, 다른 헌혈자를 초대하면 소액 또는 비금전 보상을 주는 추천 프로그램이 검토된다 [12:14]

7. 지역 문제를 담당자와 공공사업 기록에 연결

• Nagric은 벵갈루루의 도로 파손과 쓰레기 문제를 출발점으로, 위치별 담당 공무원과 정부 연락처를 모은다. 정부 웹사이트에서 수집한 데이터를 사용하며 도로 유지보수 담당 연락처 여섯 개를 보여준다 [14:59]
• 담당자에게 연락해도 조치가 없을 가능성을 고려해 상급 공무원 정보도 제공한다. 해당 지역의 입찰 공고, 계약업체, 사업 금액, 책임자 연락처를 연결해 구체적인 사업 단위로 책임을 확인할 수 있게 한다 [15:57]

8. 도시 전체의 사업비 공개와 책임성 강화

• 수집 범위는 2026년 데이터로 제한된다. 벵갈루루의 여러 기관이 추진한 입찰 규모는 5,000크로어 이상이며, 그중 1,100크로어는 이미 발주·배정된 금액으로 드러난다 [16:25]
• 벵갈루루 메트로 사례에서는 83크로어 규모의 사업과 계약업체·연락처를 확인한다. 서비스 자체가 도시를 고치지는 못하지만 시민의 정보 접근성을 높여 책임성과 더 나은 행정을 촉진할 수 있다는 전망이다 [17:06]

9. 연락처 공개가 실제 조치로 이어지는지에 대한 의문

• 담당자 정보만으로는 문제 해결 여부를 확인하기 어렵다. 공사 완료율 추적, 미응답 시 민원 제출, 후속 조치 확인까지 연결해야 실제 행동을 유도할 수 있다는 요구가 나온다 [17:38]
• 개발자는 기존 커뮤니티의 민원 게시물이 방치되는 문제 때문에 게시판 기능보다 정부 이메일과 전화번호를 우선했다. 수백 명이 담당자에게 전화하면 빠른 조치를 끌어낼 수 있다고 주장하지만, 실제 응답 여부에 대한 검증이 요구된다 [18:30]

10. 현장 증거로 공공사업 집행을 확인하는 제안

• 방대한 공공정보를 쉽게 이해하고 행동으로 연결하려면 정보 정리와 접근성 개선이 필요하다. AI를 활용해 정보 해석과 실행 경로를 단순화하는 방안이 제안된다 [19:10]
• 주민이 올린 현장 자료를 GPS 위치로 해당 입찰과 연결하고 공사 완료 여부를 표시하는 확장안이 나온다. 연말에 세금이 실제 사업으로 집행된 비율과 미조치 비율을 확인하면 시민과 정부 모두에게 평가 지표가 될 수 있다 [20:03]

11. 비자 신청의 오류와 반복 입력 부담

• 기존 e비자 사이트에서는 작성 중 충돌로 진행 내용이 사라지거나, 계좌에서 돈이 빠져나가도 결제가 반영되지 않는 문제가 제기된다. 약 30분이면 될 양식 작성에 3~4일이 걸린다는 사례가 드러난다 [21:18]
• e입국카드·별도 입국 관련 플랫폼·e비자에서 비슷한 절차를 반복해야 한다. 첫 화면에서도 국적별 도착비자 가능 여부, 비용, 처리 기간을 쉽게 찾기 어려워 인지 부담이 커진다 [21:44]

12. 국적과 비자 종류에 맞춘 안내

• 개선안은 다국어 메뉴와 신청 진입점을 정리하고, 비자 종류별 필요 서류의 형식·용량·크기를 안내한다. 사용자가 신청 전에 준비 조건을 확인할 수 있게 한다 [22:21]
• 일본 국적 입력 사례에서는 도착비자가 가능한 공항 여섯 곳을 안내하고, 다른 공항으로 입국하려면 e비자를 선택하도록 분기한다. 공항에서 필요한 서류 목록은 이메일로 받을 수 있게 한다 [22:52]

13. 자격 확인을 앞당기고 가족 신청을 통합

• 파키스탄 관련 가족·재산 이력과 군·준군사조직·경찰 등 복무 이력을 먼저 확인한다. 기존 사이트에서는 여러 페이지를 작성한 뒤에야 질문이 나오고, 시연에서는 ‘예’를 선택하면 신청 자격이 없다는 점을 명확히 알기 어렵다는 문제가 제기된다 [23:28]
• 가족 신청은 여러 계정과 신청 ID 대신 하나의 초안과 대시보드에서 관리하도록 설계했다. 비자·입국카드·관련 패스·건강신고를 모으고, 여권 이미지나 PDF에서 정보를 자동 입력하거나 휴대전화 NFC로 여권을 읽는 흐름을 제시한다 [24:03]

14. 비자 개선안의 구현 한계와 국가 이미지

• 현재 결과물은 공식 API와 연결된 서비스가 아니라 UI 화면이다. 비용 등은 정부가 공개한 PDF에서 가져왔으며, 실제 비자 발급까지 완료할 수 있는 연동은 확보되지 않았다. 관심을 보인 여행사에 맞춰 수정하는 경로가 거론된다 [24:40]
• 여권이나 개인 정보를 바탕으로 필요한 절차를 안내하는 음성 인터페이스가 추가 제안된다. 개발 동기는 시장 규모보다 외국인 친구가 신청에 3~4일을 쓰고 결국 대신 작성해 줘야 했던 경험에 있다 [25:45]

15. 흩어진 토지 기록과 지적도의 접근성 문제

• 토지 문서 위조 사례는 매도인이 실제 소유자인지 정부 기록으로 확인해야 할 필요성을 드러낸다. 기존 지적도는 경계와 필지 번호만으로 실제 위치를 파악하기 어렵고, 관련 정보는 여러 포털에 흩어져 있으며 계정 생성과 OTP 수신도 장애가 된다 [27:51]
• Naksha는 익숙한 Google Maps에서 위치를 찾고 해당 지적도에 연결하는 방식으로 접근성을 높인다. 지도상의 실제 위치와 공식 필지 경계를 함께 확인하는 것이 핵심이다 [28:07]

16. 토지 구매 전 검증과 현재 적용 범위

• 소유자·필지 번호·합법적인 수도 및 전기 연결 여부·소유 이력을 한곳에서 확인하도록 구성했다. 부동산 가치와 수익 가능성은 가용 정보를 이용해 향후 제공할 수 있는 항목으로 제시되며, 후보 토지별 신원·토지 세입 기록·경계·권리 이전 이력 등의 점검 과정을 추적한다 [28:51]
• 현재 지도 연결은 우다이푸르에만 구현돼 있다. 카르나타카에도 관련 정부 사이트가 있지만 벵갈루루 지원이 완료된 상태는 아니다 [29:04]

17. 토지 거래 이력을 결합한 투명한 부동산 지도

• 미국의 Zillow와 두바이 부동산 서비스처럼 매매·임대 이력을 제공하는 사례가 비교 기준이다. 관련 토지 변경 기록인 mutation records를 활용하면 소유자와 거래 이력을 지도에 연결할 수 있다는 구상이다 [30:22]
• 인도의 거래대금에 비공식 금액이 상당할 것이라는 가정 때문에 공개 기록이 실제 가격 전부를 보여주지 못할 가능성이 있다. 그래도 소유자 이력, 2013·2015·2018년 매매가격, 임대수익을 모으면 정부 활용 여부와 별개로 부동산 사업의 기회가 될 수 있다 [31:03]

18. 토지 서비스의 핵심 제약은 기록 접근과 권리 검증

• OTP와 이중 인증 때문에 원천 데이터와의 연결은 아직 완성되지 않았다. 현재 구상은 로그인 후 데이터를 스크래핑해 넣는 방식이다 [31:40]
• 토지의 소송 여부, 소유권자, 특정 이용자에 대한 제한을 확인해야 한다. 일부 기록은 디지털화됐지만 상당 부분이 종이에 남아 있어, 정확한 데이터의 공개 여부가 서비스 유용성을 좌우한다 [32:25]

19. 수상 기준은 생활에 미치는 영향과 즉시 구현 가능성

• 3위 경쟁에서는 세 팀이 근소한 차이를 보였고 동점 판단도 필요했다. 최종적으로 Saman이 3위, Team Aditi가 2위를 차지했으며, 1위와 2위 사이에도 의견 차이가 있었다 [34:50]
• 유용성, 실행 가능성, 혜택을 받는 사람의 수, 생활에 미치는 영향이 주요 기준이었다. 많은 작업을 거쳐 6개월 뒤 구현하는 방안보다 당장 구현할 수 있는 해결책을 중시했고, Blood Boys가 1위를 차지했다 [35:35]

20. 브라우저 AI 안내의 편의성과 개인정보 불안

• 브라우저에 상주하는 AI 도우미는 사용자의 언어로 대화하고 화면을 보며 적절한 정부 포털·제도와 이용 절차를 안내한다. 정부 서비스를 직접 변경하지 않고 그 위에서 안내하며, 프로필 정보는 사용자에게 남겨두는 설계다 [38:14]
• Aadhaar 번호 같은 개인정보에 AI가 접근한다고 느끼면 사용자가 불안해질 수 있다. 이미 복잡한 정부 웹사이트에 AI 안내를 더하는 것이 오히려 복잡성을 한 겹 추가할 수 있다는 반론이다 [38:45]

21. Ketu는 필요한 기업 신고 탐색과 양식 작성을 연결한다

• 필요한 양식, 첨부 서류, 서명자를 파악하지 못해 밤 11시에 진행하던 100크로르 규모 거래가 자정까지 성사되지 못한 경험이 출발점이다. Ketu는 담보부 사업 대출 이후 무엇을 해야 하는지 같은 질문에서 다음 절차를 찾는다 [39:49]
• MCA 등 신뢰할 수 있는 자료를 색인하는 것만으로는 문제의 절반만 해결된다. 문서의 어느 정보를 양식의 어느 항목에 넣을지 안내하고 용량 조건 위반도 알려주되, 신고 판단과 통제권은 사용자에게 남긴다 [40:24]

22. 세금 안내 도구는 명확한 다음 행동과 차별성이 필요하다

• 세무 업무를 맡긴 회계사가 연락에 응하지 않는 동안 GST 관련 통지가 쌓인 경험에서 My Next Filing이 출발했다. 도구는 다음에 할 일, 납부액, 납부 방법과 기한을 정리하고 선납세액과 납부 시점을 제시한다 [41:58]
• 이미 같은 문제를 더 자세하고 나은 디자인으로 해결하는 회사들이 있다는 반론이 나온다. 일반 AI에 개인 정보나 문서를 제공해 납부액과 클릭할 위치를 묻는 방식으로도 비슷한 안내를 얻을 수 있다는 지적이다 [42:21]

23. 정부 서비스 연결은 반복 제출을 줄이지만 사용자 검증이 부족하다

• 전국에 15,000개가 넘는 서비스가 있어도 시민이 같은 데이터와 서류를 기관 사이에서 직접 운반한다. 서비스 연계 도구는 주택 구매를 입력하면 관련 등록과 재산세 절차를 연결하고, 한 번 제출한 문서에서 추출한 정보를 여러 서비스에 재사용하는 구상이다 [43:17]
• 실제로 문제를 겪는 다른 이용자에게 도구를 보여주거나 의견을 구한 적은 없으며, 제작자의 개인 경험이 근거였다. 절차를 연결하는 설계와 별개로 실제 사용자 검증이 부족하다 [43:30]

24. Rail Setu는 좌석 조합과 대행으로 철도 예약 부담을 줄인다

• 세계에서 네 번째로 큰 철도망을 가진 인도에서도, 치료를 위해 벵갈루루로 이동해야 하는 고령자가 매진과 대기 명단에 막힐 수 있다. Rail Setu는 출발지·목적지·날짜·좌석 등급·여행자 유형을 음성으로 받아 편안함 점수가 높은 여정을 선택하고, 마지막 결제는 사용자가 승인하는 방식이다 [44:54]
• 시연의 해결 방식은 열차나 플랫폼을 갈아타는 대신 같은 열차 안에서 좌석을 몇 차례 바꾸는 것이다. 전체 구간은 대기 상태로 보이던 열차에서도 이런 좌석 조합으로 목적지까지 이동할 수 있다는 설명이다 [45:11]

🧾 결론

• 좋은 공공서비스 설계는 정보 탐색부터 신청, 담당자 연결, 진행 확인까지 이용자의 과업을 이어준다.
• 공식 데이터를 모았다는 사실만으로 정확성과 작동 여부가 보장되지는 않는다. 연락처의 최신성, 기록 접근, 업무 시스템 연동을 각각 확인해야 한다.
• 별도 앱 설치보다 모바일 웹과 WhatsApp처럼 익숙한 접점이 적합한 사례가 있다. 특히 이용 빈도가 낮거나 긴급한 서비스에서 이런 설계가 주목받았다.
• 경연의 평가 기준은 당장 실행할 수 있고 생활에 영향을 주는 해결책에 무게를 뒀다. 시연의 편의성을 실제 이용 성과로 검증하는 과정이 다음 과제다.

📈 투자·시사 포인트

• 사업성을 검토할 때는 화면 완성도와 함께 공식 시스템 접근, 데이터 갱신, 처리 완료 여부를 살펴야 한다. 비자 UI와 토지 기록 서비스는 이 조건의 중요성을 보여준다.
• 신고 대행, 여행사 활용, 부동산 기록 통합 등 사업 경로가 제안됐지만 수익성과 수요가 입증된 것은 아니다. 이용 동기와 기존 서비스 대비 추가 가치를 확인필요가 있다.
• AI 서비스의 경쟁력은 자료 검색을 넘어 어떤 서류를 준비하고 어느 항목에 입력하며 다음에 무엇을 해야 하는지 연결하는 데서 찾을 수 있다.
• 공공정보 플랫폼의 성과 지표는 공개한 연락처나 문서 수뿐 아니라 응답, 처리 완료, 현장 확인까지 포함하도록 설계필요가 있다.

⚠️ 불확실하거나 확인이 필요한 부분

• 사이버 신고의 경찰 시스템 연계와 상담원 전달은 실제 운영 성과가 확인되지 않았다. 시연·시뮬레이션만으로 피해금 회수 효과를 판단하기 어렵다.
• 등록 헌혈자 280만 명, 혈액 수급 규모, 혈액은행까지의 거리 수치는 영상에서 제시된 근거다. 원자료의 기준 시점과 산정 방식은 별도 확인이 필요하며, 추천 보상의 허용 범위도 확인해야 한다.
• Nagric의 벵갈루루 연락처는 행정구역 재조정 이전 자료이며 유효성이 검증되지 않았다. 비자 개선안은 공식 API와 연결되지 않았고, Naksha의 원천 데이터 연결도 미완성이다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 각 서비스에서 구현된 기능, 시뮬레이션한 기능, 향후 제안을 구분하고 실제 처리 완료까지 가능한 범위를 확인한다.
• 연락처·비자 요건·토지 기록의 공식 출처와 갱신 시점을 확인하고, 대표 사례로 실제 연결 및 조회 가능 여부를 점검한다.
• 고령 피해자, 환자·헌혈자, 비자 신청자 등 실제 대상 이용자에게 도구를 보여주고 기존 방식 대비 시간과 중도 포기 지점을 비교한다.
• 신고 접수, 헌혈 요청 수락, 민원 조치, 신청 완료처럼 서비스별 최종 결과를 정하고 후속 상태를 추적한다.

❓ 열린 질문

• 정부 시스템과 직접 연동하기 어려운 상황에서도 안내와 후속 추적만으로 얼마나 큰 개선 효과를 낼 수 있을까?
• 헌혈처럼 이용 빈도가 낮은 서비스는 자발적 참여와 추천 프로그램으로 충분한 응답자를 유지할 수 있을까?
• 담당자와 공공사업 정보를 공개하는 것이 실제 응답과 공사 완료로 이어지려면 어떤 추적 체계가 필요할까?