Signals공공 데이터공공 영업B2G

정부 사이트 30개의 기술 스택이 전부 달랐다: 한국 공공데이터 인프라의 현실 | Signals EP.2

클라이원트 CLIWANT클라이원트 CLIWANT
6분 읽기
정부 사이트 30개의 기술 스택이 전부 달랐다: 한국 공공데이터 인프라의 현실 | Signals EP.2

시리즈: 공공데이터에서 영업 시그널을 자동으로 발굴하기까지, 1편 읽기

"정부 사이트는 다 비슷비슷하게 생겼다"는 착각

밖에서 보면 정부 웹사이트가 거기서 거기인 것 같다. 파란색 상단바, 왼쪽 사이드 메뉴, 게시판형 레이아웃. 겉모습은 비슷할 수 있다.

하지만 실제로 30개 넘는 사이트를 수집 대상으로 삼고 각각의 내부 구조를 분석하기 시작하면, 한국 공공데이터 인프라가 '인프라'라고 부르기 민망할 정도로 파편화되어 있다는 걸 금방 깨닫게 된다.

같은 정부인데 기술 스택이 전부 다르다

과기부 사이트의 게시판과 환경부 사이트의 게시판은 완전히 다른 세계다. 한쪽은 전통적인 서버 사이드 렌더링으로 HTML 테이블을 보여주고, 다른 한쪽은 JavaScript가 비동기로 데이터를 불러와서 화면에 그리는 방식이다.

같은 기관 안에서도 게시판마다 구조가 다른 경우까지 있다. 사업공고 게시판은 한 구조인데, 보도자료 게시판은 레이아웃이 완전히 다르다. 심지어 URL 파라미터 이름까지 다르다. 하나는 page=1, 다른 하나는 pageIndex=0.

30개 사이트에서 발견한 4가지 구조 유형

  1. 정적 HTML 테이블, 가장 흔한 레거시 구조. 2000년대에 만든 사이트 대부분이 이 형태
  2. 서버사이드 렌더링, 요청하면 완성된 HTML을 돌려주는 방식. 비교적 다루기 수월하다
  3. REST API 기반, 화면과 데이터가 분리된 구조. 공식 API는 아니고 내부적으로만 JSON을 주고받는 구조
  4. JavaScript 동적 렌더링, 페이지 로드 후 스크립트가 데이터를 불러오는 방식. 단순 HTTP 요청으로는 빈 페이지만 받아온다

자동화 관점에서 이 네 가지는 완전히 다른 수집 전략을 요구한다. 하나의 범용 수집기로 30개 사이트를 커버한다는 건 불가능에 가깝고, 결국 소스별로 맞춤형 로직을 짜야 했다.

예고 없이 바뀌는 사이트, 깨지는 수집

정부 사이트의 가장 큰 리스크는 변경 공지 없이 구조가 바뀐다는 것이다.

실제 경험 하나. 어떤 공공기관의 URL 체계가 어느 날 갑자기 .do에서 .act로 전면 변경됐다. 아무런 사전 고지도 없이. 어제까지 잘 돌아가던 수집이 하루아침에 전부 실패했고, 원인을 찾는 데만 반나절이 걸렸다.

이런 일은 예외 상황이 아니다. 도메인 변경, SSL 인증서 만료, 게시판 개편이 수시로 벌어진다. 특히 "정부 사이트니까 안정적이겠지"라는 기대는 첫 달에 깨졌다.

정부 사이트 나이대별 불안정성 패턴

  • 구축 후 1~2년: 비교적 안정적. 구조 변경이 거의 없다
  • 3~4년차: 도메인 리뉴얼이나 SSL 이슈가 슬슬 보이기 시작
  • 5년 이상: 과거 게시물의 URL이 하나둘 죽기 시작하고, 첨부파일 서버가 내려가기도

어떤 기관은 2015년에 게시된 공지 약 2만 5천 건의 첨부파일 URL이 전부 404였다. 데이터가 '있었다'는 흔적만 남아 있고, 실체는 사라진 상태.

공공데이터포털에 정작 필요한 게 없다

공공데이터포털(data.go.kr)은 좋은 플랫폼이다. 진심으로 그렇게 생각한다.

하지만 "영업 시그널"에 필요한 데이터는 거기에 없다.

공공데이터포털이 제공하는 건 주로 통계, 지리 정보, 인허가 같은 정형화된 데이터다. 각 부처의 사업공고, R&D 과제 공모, 예산 편성 자료 같은 비정형 게시판 데이터, 정작 영업에 가장 필요한 것들은 API로 제공되지 않는다.

결국 부처별로 직접 들어가서 게시판을 긁어오는 수밖에 없다. 30개 사이트, 100개 이상의 게시판. 통합된 인터페이스 같은 건 존재하지 않는다.

"까보기 전에는 모른다"는 말이 맞더라

몇 가지 재미있는 발견들.

어떤 사이트는 겉으로는 평범한 HTML 게시판인데, 네트워크 트래픽을 열어보니 숨겨진 JSON API가 있었다. 공식적으로 API를 제공하는 건 아닌데, 내부적으로 프론트엔드와 백엔드가 JSON으로 통신하고 있었다. 이걸 발견하면 HTML 파싱보다 훨씬 깔끔하게 데이터를 가져올 수 있다.

반대 경우도 있다. 깔끔해 보이는 현대적 사이트가, 실제로는 인라인 JavaScript에 데이터를 하드코딩해서 끼워넣고 있더라. jQuery로 테이블을 그리는 코드가 페이지 소스에 그대로 박혀 있었다.

한 기관은 SSL 인증서가 만료된 채로 수년째 운영 중이었다. 브라우저에서 "안전하지 않음" 경고가 뜨지만 기관 내부에서는 다들 무시하고 쓰고 있고, 수집 시스템에서는 이런 사이트를 위한 예외 처리를 별도로 넣어야 했다.

요약하면

한국 정부 웹 인프라는 통합되어 있지 않고, 표준화되어 있지 않으며, 안정적이지도 않다.

그런데 여기에 우리가 필요한 데이터가 있다. 이 모순이 이 프로젝트의 출발점이자 가장 큰 난관이었다.

다음 에피소드에서는 이렇게 가져온 데이터에서 날짜 하나, 예산 한 줄 뽑는 게 왜 그렇게 어려웠는지 이야기한다.

SIGNALS

공고가 뜨기 전, 시그널을 먼저 잡고 싶다면

30개 공공 데이터 소스에서 영업 시그널을 자동 발굴하는 Signals. 1:1 상담을 받아보세요.

상담 신청하기 →
클라이원트 CLIWANT

클라이원트 CLIWANT

AI 입찰 분석 솔루션 – OpenAI 협업 스타트업

공공조달 입찰 기회를 놓치고 계신가요?

클라이원트와 함께 입찰 기회를 먼저 포착하고 성공 확률을 높이세요.

무료로 시작하기

클라이원트 상담

응답 대기중

불러오는 중...

클라이원트 상담

응답 대기중

불러오는 중...