2023 뉴스빅데이터 해커톤 공공부문 본선 진출 · 예선 10팀 선정
BIGKinds 지역 뉴스와 생성형 AI를 연결한 주민조례 발안 보조 서비스 조례 줄래?를 FastAPI 웹 프로토타입으로 구현하고, 2023년 11월 22일 본선에서 시연·발표했습니다.
왜 이 프로젝트를 시작했는가
이 프로젝트는 시기상으로도 경험상으로도 제가 처음 완성한 개발 프로젝트에 가깝습니다. 당시에는 하나의 웹서비스를 어떤 순서로 만들고, 프론트엔드와 백엔드가 어떻게 나뉘어 데이터를 주고받는지도 제대로 알지 못했습니다. 필요한 기능을 하나씩 찾아 직접 실행하며 코드를 완성해 갔습니다.
또한, 2023년 ChatGPT를 비롯한 생성형 AI가 빠르게 주목받는 상황에서, 대화형 AI를 사용하는 데 그치지 않고 뉴스 빅데이터를 실제 입력으로 연결하면 어떤 공공서비스를 만들 수 있을지 궁금했습니다.
무엇보다 첫 해커톤을 통해 제한된 시간 안에 아이디어를 실제 결과물로 만드는 과정을 경험해 보고 싶었습니다. 정치외교학·미디어커뮤니케이션학·컴퓨터공학 등 서로 다른 전공의 팀원들과 문제를 정의하고 역할을 나누며, 각자의 관점을 하나의 서비스로 조율하는 팀 프로젝트에 도전한 것도 중요한 동기였습니다.
PROJECT OVERVIEW
항목 | 내용 |
기간 | 2023.10.23–2023.11.22 · 본선 진출 후 5일간 프로토타입 집중 구현 |
수행 형태 | 정치외교학·미디어커뮤니케이션학·컴퓨터공학 전공자 4인 팀 |
문제 | 지역 현안을 발견하고 주민조례 아이디어로 구체화하며 다른 주민의 의견을 확인하기까지의 높은 진입장벽 |
데이터·대상·환경 | BIGKinds 지역 뉴스 검색·기사 조회 데이터 · FastAPI·Jinja2 기반 웹 프로토타입 |
분석·구현 범위 | 규칙 기반 개인화, 뉴스 검색·조회, 기사 기반 생성형 AI 조례 아이디어, 뉴스 피드와 주민 반응 화면 |
결과 | 공공부문 예선 10팀 선정 · 본선 진출 · 2023.11.22 시연 및 발표 |
2023_News_BigData_Hackathon
foxirain
핵심 질문 — 시민이 매일 접하는 지역 뉴스를 주민조례 발안의 출발점으로 만들고, 생성형 AI를 이용해 현안을 실행 가능한 아이디어로 구체화할 수 있을까?
Project Flow
단계 | 판단 기준 | 산출물·구현 결과 |
1. 문제 정의 | 시민이 주민조례를 제안할 때 어디에서 가장 먼저 막히는가 | 지역 현안 발견 → 조례 아이디어 → 주민 의견 수렴의 서비스 흐름 |
2. 개인화 조건 구성 | 제한된 기간 안에 사용자와 가까운 뉴스를 어떻게 선택할 것인가 | 프로필 입력을 관심 분야와 지역 언론사에 연결하는 규칙 |
3. 뉴스 데이터 연결 | 아이디어가 어떤 지역 현안에서 출발했는지 추적할 수 있는가 | BIGKinds 뉴스 검색·기사 조회 결과 |
4. AI 아이디어 생성 | 기사 내용과 서비스 목적을 응답 조건에 반영할 수 있는가 | 기사 기반 관련 산업과 주민조례 아이디어 |
5. 프로토타입 검증 | 5일 안에 사용자 입력부터 결과 화면까지 시연 가능한가 | FastAPI 웹 프로토타입과 본선 시연·발표 |
ROLE
Full-Stack Developer · AI/Data Integration Developer- 담당 역할: 컴퓨터공학 전공자로서 팀의 정책·미디어 기획을 실제로 시연할 수 있는 웹 프로토타입으로 구현했습니다.
- 백엔드·데이터 연동: FastAPI 서버와 화면 라우팅, BIGKinds 뉴스 검색·기사 조회 API, 기사 내용을 이용한 생성형 AI 조례 제안 흐름을 구현했습니다.
- 개인화·화면 구현: 사용자 정보에 따른 관심 분야·지역 언론사 선택 로직과 개인화 뉴스·AI 조례 결과 화면을 구현하고, 사용자 정보·지역 광장·토론 화면 개발에 참여했습니다.
- 협업 범위: 정치외교학·미디어커뮤니케이션학 전공 팀원들과 문제 정의와 서비스 흐름을 함께 설계했습니다. 팀원들의 정책·미디어 관점을 기능과 화면으로 구체화하고, 시민이 이해하고 사용할 수 있는 흐름인지 함께 검토했습니다.
TECH STACK
Python · FastAPI · Jinja2 · HTML · CSS · JavaScript · BIGKinds API · OpenAI API · GitMY WORK
1. 주민조례 제안의 진입장벽을 서비스 흐름으로 바꾸기
주민이 조례안을 제안하기까지의 과정을 네 가지 문제로 나누었습니다.
- 자신이 거주하는 지역의 현안을 꾸준히 파악하기 어렵습니다.
- 뉴스에서 문제를 발견해도 조례로 해결할 수 있는 사안인지 판단하기 어렵습니다.
- 문제의식을 조례 형태로 정리하려면 제도와 문서 작성 지식이 필요합니다.
- 정식 청구 전에 다른 주민의 공감과 의견을 확인할 공간이 부족합니다.
저희 팀은 이 문제를 개인화된 지역 뉴스 탐색 → 기사 기반 조례 아이디어 → 주민 반응과 토론 → 정식 청구 검토의 흐름으로 변환했습니다. 생성형 AI를 단독 기능으로 두지 않고, 뉴스라는 출처가 있는 지역 현안에서 아이디어가 시작되도록 설계한 것이 핵심이었습니다.
2. 규칙 기반 개인화와 BIGKinds 뉴스 탐색 구현
사용자가 연령·성별·직업·거주지역을 입력하면 사전에 정의한 규칙으로 관심 분야와 지역 언론사를 선택했습니다. 이 조건을 BIGKinds 검색 파라미터로 변환해 사용자와 가까운 지역 뉴스를 조회하고, 선택한 기사의 본문과 핵심 정보를 다음 단계의 입력으로 전달했습니다.
입력·처리 | 구현 내용 | 판단 |
사용자 프로필 | 연령·성별·직업·거주지역 입력 | 초기 프로토타입에서 사용할 최소 개인화 조건 정의 |
규칙 기반 매핑 | 입력값을 관심 분야와 지역 언론사에 연결 | 학습 데이터 없이 5일 안에 동작 가능한 방식 선택 |
뉴스 검색·조회 | 조건을 BIGKinds API 파라미터로 변환 | 일반 뉴스가 아니라 사용자와 가까운 지역 현안 탐색 |
기사 선택 | 기사 내용과 핵심 정보를 AI 입력으로 전달 | 생성 결과가 어떤 뉴스에서 출발했는지 연결 |
이 방식은 실제 이용 데이터를 학습한 추천 모델이 아니라 사전에 작성한 규칙에 기반합니다. 따라서 개인화 품질이나 사용자별 추천 성능을 검증한 결과로 표현하지 않았습니다.
3. 뉴스 데이터를 생성형 AI 조례 아이디어로 연결
같은 기사를 전달해도 질문의 역할·조건·출력 형식에 따라 생성 결과가 달라졌습니다. 기사 요약만 전달했을 때와 역할 및 요구사항을 구체화했을 때의 결과를 비교하며, 관련 산업과 주민조례 아이디어를 얻기 위한 프롬프트를 반복해서 조정했습니다.
이 과정을 통해 API를 단순히 데이터를 가져오는 기능이 아니라, 한 시스템의 응답을 다른 시스템의 입력으로 바꾸는 연결 지점으로 이해했습니다. BIGKinds의 JSON 응답이 생성형 AI의 입력이 되고, 처리 결과가 다시 웹 화면에 표시되는 전체 데이터 흐름을 처음 구현했습니다.
다만 프롬프트별 품질을 관련성·사실성·실현 가능성으로 정량 평가하지는 못했으며, 생성된 문장에 대한 법률적 타당성 검토 구조도 구현하지 못했습니다.
4. 프론트엔드와 백엔드를 하나의 시연 흐름으로 연결
Figma로 화면과 사용자 이동 흐름을 설계하고, HTML·CSS·JavaScript와 Jinja2로 입력 및 결과 화면을 구성했습니다. FastAPI에서는 사용자 입력을 받아 개인화 조건을 만들고 외부 API를 호출한 뒤, 처리 결과를 프론트엔드에 전달했습니다.
구성 | 담당 기능 | 확인한 개념 |
main.py | FastAPI 실행, 화면 라우팅, 사용자 입력과 데이터 전달 | 백엔드 서버, 엔드포인트, 요청·응답 |
bigkinds.py | 뉴스 조회, 관심 분야 선택, 생성형 AI 호출 | 외부 API, JSON 데이터, 프롬프트 구성 |
user_info.html | 사용자 정보 입력과 서버 전송 | 폼 입력, JavaScript fetch, 프론트엔드–백엔드 연결 |
article2.html | 개인화 뉴스와 AI 조례 결과 표시 | HTML·CSS·JavaScript를 이용한 동적 화면 구성 |
처음에는 프론트엔드와 백엔드의 차이도 명확히 알지 못했지만, 이 구현을 통해 화면은 사용자와 만나는 영역을, 서버는 입력 처리와 외부 서비스 연결을 담당하며 두 영역이 HTTP 요청과 응답으로 하나의 서비스가 된다는 점을 이해했습니다.
5. 5일 안에 검증할 범위와 이후 과제를 구분
본선 진출 후 5일이라는 제한 안에서 운영 가능한 완성 서비스보다 핵심 가설과 사용자 흐름을 보여주는 프로토타입을 우선했습니다.
구분 | 범위 |
실제 구현 | 사용자 정보 입력, 규칙 기반 관심 분야·지역 언론사 선택, BIGKinds 뉴스 검색·조회, 기사 기반 AI 조례 아이디어 생성, 뉴스 피드 화면 |
프로토타입·부분 구현 | 좋아요·싫어요, 댓글, 지역 광장, 토론 화면 |
기획 단계 | 사용자 인증, 데이터베이스 저장, 전문가·입법자문관 검토, 주민e직접 연계, 별도 AI 모델 학습 |
사용자 정보와 뉴스 결과를 서버 전역 상태에 임시로 보관했기 때문에 재시작 시 데이터가 사라지고, 여러 사용자의 기록을 구분하거나 반응과 댓글을 지속적으로 저장할 수 없었습니다. 이 한계를 통해 화면과 API뿐 아니라 데이터 저장과 사용자별 상태 관리가 운영 서비스의 핵심이라는 점을 배웠습니다.
RESULTS
- 본선 진출: 2023 뉴스빅데이터 해커톤 공공부문 예선 심사를 통과한 10개 팀 중 하나로 선정되었습니다.
- 시연·발표: 본선 진출 후 5일 동안 핵심 흐름을 구현해 2023년 11월 22일 본선에서 웹 프로토타입을 시연하고 발표했습니다.
- 구현 결과: 사용자 입력 → 규칙 기반 개인화 → BIGKinds 뉴스 검색·조회 → 기사 기반 AI 조례 아이디어 → 결과 화면의 데이터 흐름을 연결했습니다.
- 서비스 제안: 지역 뉴스를 단순 콘텐츠가 아니라 주민조례 아이디어의 근거 데이터로 활용하고, 생성형 AI를 현안 발견과 시민 참여 사이의 보조 도구로 배치했습니다.
- 한계: 생성 품질의 정량 평가, 법률적 타당성 검토, 추천 성능 평가, 인증·DB·다중 사용자 처리는 진행하지 못했습니다.
배운 점과 다음 단계
가장 아쉬웠던 점은 개발 과정이 체계적이지 못했다는 것입니다. 짧은 기간 안에 기능을 완성하는 데 집중하다 보니 역할과 책임, 개발 순서, 완료 기준을 명확하게 나누지 못했습니다. 다음 팀 프로젝트에서는 초기에 담당 영역과 협업 방식을 구체적으로 정하고, 각자의 작업을 안정적으로 합칠 수 있는 개발 체계를 만들고 싶습니다. 이러한 아쉬움은 역할을 더 명확히 나누고 데이터베이스를 포함한 웹서비스 개발 과정을 보다 체계적으로 경험해 보기 위해 다음 프로젝트인 GamjaWeb을 시작하는 계기가 되었습니다.
본선에서 여러 지역의 대학생들이 준비한 서비스와 발표를 보며 제가 알고 있던 범위가 좁았다는 사실을 실감했습니다. 저희 팀이 프롬프트 엔지니어링을 중심으로 준비한 반면, 다른 팀들은 파인튜닝까지 기술적 선택지로 다루고 있었습니다. 말 그대로 ‘우물 안 개구리’였다는 느낌과 함께, 새로운 기술을 꾸준히 따라가고 실제 프로젝트에 적용하는 노력이 필요하다는 자극을 받았습니다.
심사위원들의 날카로운 질문이 주는 압박감도 처음 경험했습니다. 발표자료를 어떻게 구성해야 하는지, 예상 질문을 어떻게 준비해야 하는지, 압박이 있는 질의응답에서도 핵심을 지키며 답하려면 무엇이 필요한지를 현장에서 몸소 배웠습니다.
수상하지는 못했지만, 잘하는 팀은 단순히 기능을 구현하는 데서 끝나지 않는다는 것을 알게 되었습니다. 기술의 흐름을 따라가며 선택의 근거를 만들고, 결과를 설득력 있게 발표하며, 질문 앞에서 자신들의 판단을 침착하게 설명할 수 있어야 한다는 점을 배웠습니다.