경기 기후 바이브코딩 해커톤 후기

경기 기후 바이브코딩 해커톤 후기

경기 기후 바이브코딩 해커톤

12월 13일, 경기 기후 바이브코딩 해커톤을 팀원 한 명과 2인 팀으로 참여했습니다.

장소는 경기도의회 중회의실이였습니다.

이 해커톤은 경기기후플랫폼의 기후(공간) 데이터를 바탕으로,

아이디어 기획부터 서비스 구현까지 단 시간 안에 완성하는 해커톤이었습니다.

짧은 시간이었지만, 공공 데이터와 생성형 AI를 활용해  실제 서비스를 기획해봤던 의미 있는 경험이었습니다.

 

프로젝트 소개 – WildSafe

https://github.com/LouiIII3/WildSafe

GitHub - LouiIII3/WildSafe: 경기도 생태통로 분석 시스템 - 로드킬/버드스트라이크 저감 추천

 

저희 팀은 야생동물 교통사고(로드킬)와 버드스트라이크 위험을 줄이기 위한 생태 안전 분석 웹 서비스 WildSafe를 개발했습니다.

경기기후플랫폼에서 제공하는 공간 데이터로 생태통로 설치 우선 지점과 서식지 전환이 필요한 위험 지역을 도출하고, 분석 결과를 지도 기반으로 시각화 하였습니다.

활용 데이터 및 API

여기에서는 제공해주는 api를 활용할수 있었는데요. 처음 보는 용어도 많았습니다.

용어에 대해 공부하다보니, 데이터들은 WFS와 WMS로 데이터 방식으로 제공 되고 있었고 두개의 방식이 달랐습니다. 

WFS는 데이터를 가져와서 계산 및 분석하는 용도 였고
WMS는 이미 만들어진 지도를 이미지로 보여주는 용도 였습니다.

이에 따라 저희는 WFS를 활용하여 지도에 지점을 띄울 생각이었습니다.

 

• rgn_lv1_core_rgn : Lv1 지역 핵심 지역
• min_cst_path_lv1 : Lv1 최소 비용 경로
• wildlife_protection_area : 야생동식물보호구역
• spggcee:rst_bird_dvsty : 조류종 다양성

 

진행 과정

이번 해커톤은 Claude Code를 활용한 바이브코딩 방식으로 진행되었습니다.
자연어로 서비스 요구사항을 설명하면 AI가 코드를 생성하고, 이에 맞춰 기능을 완성해 나가는 구조였습니다.

실제로 진행해보니, 요구사항을 얼마나 구체적으로 정의하느냐가 프로젝트의 품질을 크게 좌우한다는 점을 깨닫게 되었습니다.
프롬프트를  작성할떄 모호하게 하면  결과 역시 불분명해졌고, 출력 형태와 목적을 명확히 제시할수록 원하는 결과에 가까워졌습니다.

 

좋았던 점

1. 공공 데이터의 실질적 활용 경험

경기기후플랫폼의 데이터는 단순 참고용이 아니라, 실제 정책과 행정 판단에 활용 가능한 수준의 공간 데이터였습니다.
최소비용경로, 핵심 서식지, 보호구역, 조류종 다양성 데이터를 조합하며, 개별 데이터가 아닌 데이터 간 관계를 해석하고 의미 있는 결과로 연결하는 경험을 할 수 있었습니다.

 

2. 생성형 AI 활용 방식에 대한 인식 변화

이번 해커톤을 통해 프롬프트 설계 또한 하나의 기술 역량이라는 점을 분명히 인식하게 되었습니다.
원하는 출력 구조, 분석 기준, 설명 방식 등을 명확히 정의할수록 결과물의 완성도가 높아졌고, 요구사항이 모호할수록 결과도 흐려졌습니다.

 

3. 2인 팀 협업의 효율성

소규모 팀으로 참여하면서 의사결정 속도가 빠르고, 기획과 구현을 유연하게 조율할 수 있었습니다.
역할은 나뉘어 있었지만, 전체 흐름을 함께 이해하며 프로젝트를 진행할 수 있었던 점이 인상 깊었습니다.

 

 

아쉬웠던 점

1. 데이터 활용과 결과 전달 방식의 한계

이번 해커톤에서는 수상에는 이르지 못했지만, 그 과정에서 데이터 활용의 깊이와 결과를 전달하는 방식에서 부족했던 부분을 객관적으로 돌아볼 수 있는 계기가 되었습니다.

다양한 공간 데이터를 활용해 분석을 시도했으나, 제한된 시간 안에서 분석 결과를 보다 직관적이고 설득력 있게 전달하는 구조를 충분히 다듬지 못한 점이 아쉬움으로 남았습니다.

2. 생성형 AI 활용 과정에서의 운영적 한계

Claude Code를 활용한 바이브코딩 방식은 생각보다 간단했지만,

실제 해커톤 환경에서는 토큰 실행 횟수와 계정 상태를 수시로 확인해야 할 필요성을 느끼게 되었습니다.

해커톤 도중 토큰 만료 이슈로 인해 주최 측에서 계정을 여러 차례 재생성해야 했고, 이로 인해 작업 흐름이 일시적으로 지연되는 상황도 발생했습니다. (30분정도 지연....)
이를 통해 생성형 AI를 적용할 경우, 기술 자체뿐만 아니라 토큰 관리와 같은 운영 요소도 중요하다는 점을 체감했습니다.

또한 향후에는 웹 환경뿐만 아니라 VS Code와 직접 연동된 형태로 AI를 활용한다면 유지보수와 수정 작업이 훨씬 효율적일 것이라는 생각도 하게 되었습니다.

 

3. 데이터 제공 방식 확인 과정에서의 어려움

해커톤 안내 자료에서는 제공된 데이터들이 WMS와 WFS 방식 모두 활용 가능하다고 설명되어 있었고,
실제로 대부분의 데이터는 두 방식 모두 문제없이 사용할 수 있었습니다.
다만 조류종 다양성 데이터(spggcee:rst_bird_dvsty)의 경우,
다른 데이터들과 달리 WMS만 제공되고 WFS는 지원되지 않는 데이터라는 점을 진행 중에 확인하게 되었습니다.

처음에는 호출 방식이나 설정 문제로 판단해 여러 차례 확인했으나,
결과적으로 해당 데이터는 WFS API 자체가 제공되지 않는 레이어였습니다.
이 차이를 파악하는 데 예상보다 시간이 소요되었습니다.

또한 해커톤 특성상 프로젝트 내용과 직접적으로 관련된 질문은 형평성 문제로 현장에서 자유롭게 질의하기 어려워,
스스로 문서를 확인하고 테스트를 반복하며 원인을 파악해야 했던 점이 다소 답답하게 느껴졌던거 같습니다.

이 경험을 통해 공간 데이터를 활용할 때는
각 데이터별 실제 활용 가능 방식(WMS/WFS)을 사전에 명확히 확인하는 것도 중요하다 라는 것을 깨닫게 되었습니다.

 

배운 점

이번 해커톤을 통해 가장 크게 느낀 점은 다음과 같습니다.

기술 구현보다 문제 정의와 요구사항을 얼마나 구체적으로 설정하는지가 결과물의 품질을 결정한다는 점입니다.

더불어,

• WFS는 분석용, WMS는 시각화용으로 구분해 활용하는 공간 데이터 API 사용 방식
• 공공 데이터를 단순한 지도 표시가 아닌 의사결정을 지원하는 결과물로 재구성하는 관점
• 생성형 AI 활용 시 프롬프트 설계뿐 아니라 토큰 관리와 실행 환경 등 운영 측면까지 고려해야 한다는 점

을 실질적으로 학습할 수 있었습니다.

 

마무리

비록 수상하지는 못했지만, 공간 데이터를 활용해 정책적 활용 가능성을 가진 서비스를 기획해본 경험은 충분히 의미 있는 시간이었습니다.

특히 생성형 AI를 활용한 개발 과정에서, AI를 활용하기 위해 필요한 조건과 한계를 함께 이해하게 되었습니다.

다음에 또 유사한 해커톤이나 프로젝트에 참여하게 된다면,
핵심 기능 중심의 구조 설계와 함께 운영 환경까지 고려한 AI 활용 방식으로 접근해보고자 합니다.

감사합니다~