방송대 오픈소스기반데이터분석 4강: 데이터 유형 판별과 수집 방법 선택
매주 정리된 매출표, 실시간으로 변하는 서비스 응답, 웹페이지의 상품 정보는 모두 데이터지만 같은 방식으로 모을 수 없다. 이 글은 수집 목적과 품질 기준을 먼저 세우고, 정형·반정형·비정형을 판별한 뒤 파일·API·웹 스크래핑 가운데 적절한 방법을 고르는 의사결정 절차를 제시한다.
수집은 모으기가 아니라 분석 가능한 상태를 설계하는 일이다
데이터 수집은 단순히 많은 정보를 저장하는 행위가 아니다. 분석 목적에 적합한 유효한 데이터를 찾고, 적절한 획득 방법을 선택하고, 정확성을 유지할 형식과 주기를 결정해 분석 가능한 상태로 준비하는 과정이다. 따라서 “어디에서 가져올까?”보다 앞서 “무슨 결정을 위해 어떤 정보가 필요한가?”를 물어야 한다.
예를 들어 매장 운영자가 다음 달 재고량을 정하려 한다면 제품명만 모아서는 부족하다. 판매 시점·수량·반품 여부·재고 상태가 필요하고, 서로 다른 매장에서 같은 제품 코드를 쓰는지도 확인해야 한다. 목적이 정해져야 필요한 항목, 기간, 수집 주기와 허용 가능한 오류를 결정할 수 있다.
판단 핵심: 수집 대상을 먼저 정하지 말고 의사결정 질문을 먼저 적는다. 그 질문에 답하는 데 필요한 필드와 기간을 정한 뒤 소스·방법·형식·주기를 선택해야 불필요한 양을 줄이고 품질을 관리할 수 있다.
좋은 데이터는 양보다 여섯 품질 질문을 통과해야 한다
많은 데이터를 모아도 값이 틀리거나 필요한 항목이 비어 있고, 서로 다른 규칙으로 기록되었다면 신뢰할 수 있는 결과를 얻기 어렵다. 강의는 좋은 데이터의 조건으로 정확성·완전성·일관성·유효성·적시성·상호운용성을 제시한다.
| 품질 기준 | 점검 질문 | 실패 사례 | 수집 단계의 대응 |
|---|---|---|---|
| 정확성 | 값이 실제 상태를 올바르게 나타내는가? | 실제 가격은 12,000원인데 120,000원으로 기록 | 원천 값 대조와 범위 검사 |
| 완전성 | 분석에 필요한 항목이 빠지지 않았는가? | 거래 시각이 여러 행에서 누락 | 필수 필드와 결측 허용 기준 지정 |
| 일관성 | 소스와 시점이 달라도 같은 규칙을 쓰는가? | 날짜가 YYYY-MM-DD와 MM/DD/YYYY로 혼재 | 단위·코드·날짜 형식 표준화 |
| 유효성 | 정한 형식과 허용 범위를 만족하는가? | 만족도 점수 범위가 1~5인데 9가 입력 | 스키마와 값 제약 검증 |
| 적시성 | 의사결정에 필요한 시점에 갱신되는가? | 실시간 재고 판단에 지난달 파일 사용 | 수집 주기와 지연 허용치 결정 |
| 상호운용성 | 다른 시스템에서도 의미를 잃지 않고 쓸 수 있는가? | 부서마다 제품 식별자가 달라 결합 불가 | 공통 코드와 교환 형식 사용 |
정확성과 일관성은 같은 말이 아니다. 모든 행이 같은 잘못된 단위를 사용하면 일관성은 있어도 정확하지 않을 수 있다. 반대로 개별 값이 실제와 맞더라도 날짜 표현이 제각각이면 결합·정렬 과정에서 일관성 문제가 생긴다.
정형·반정형·비정형은 스키마의 강도로 구분한다
데이터 유형은 파일 확장자만 보고 결정하지 않는다. 분석 전에 구조가 얼마나 엄격하게 정해져 있는지를 살펴야 한다. 정형 데이터는 고정된 스키마가 강하고, 반정형 데이터는 태그·키-값·계층 같은 구조 표지가 있지만 스키마 변경이 비교적 쉽다. 비정형 데이터는 미리 정해진 스키마가 거의 없고 내용과 형태가 자유롭다.
| 판정 축 | 정형 데이터 | 반정형 데이터 | 비정형 데이터 |
|---|---|---|---|
| 구조 | 행·열과 고정 스키마 | 태그·키-값·계층 구조 | 요소 관계가 미리 고정되지 않음 |
| 대표 형태 | 관계형 데이터베이스 테이블, 표 형식 자료 | JSON, XML, 로그, 구조를 가진 메시지 | 자유 문서, 이미지, 음성·영상 |
| 강점 | 저장·검색·변환·분석이 체계적 | 유연성과 확장성이 높고 복잡한 관계 표현 가능 | 풍부한 정보와 맥락을 담을 수 있음 |
| 추가 작업 | 예상 밖 유형을 넣으려면 스키마 변경 필요 | 구조 파악과 정제 필요 | 내용에서 특징과 관계를 추출하는 고도 분석 필요 |
이메일은 어느 한 유형으로만 고정되지 않는다
강의자료에서 이메일은 다양한 형태의 예로 등장한다. 이 경계 사례는 분류 기준을 보여 준다. 발신자·수신자·제목·날짜처럼 일정한 헤더 필드는 반정형 요소이고, 자유롭게 쓴 본문이나 첨부 이미지는 비정형 요소다. 따라서 데이터 묶음 전체에 이름표 하나만 붙이기보다 분석할 부분의 구조를 기준으로 판단해야 한다.
유형 판별 순서: 행·열의 고정 스키마가 있는가? 없다면 태그·키-값·계층처럼 반복되는 구조 표지가 있는가? 그것도 없다면 비정형으로 보고 내용 추출과 정제 비용을 예상한다.
수집 방법은 소스·권한·양·실시간성으로 결정한다
파일·데이터베이스·API·웹 스크래핑은 서로 경쟁하는 단일 정답이 아니다. 데이터 소스가 어떤 형태인지, 접근 권한이 있는지, 한 번에 얼마나 많이 가져오는지, 얼마나 빨리 갱신되어야 하는지를 조합해 선택한다.
| 상황 | 우선 고려할 방법 | 선택 근거 | 추가 확인 |
|---|---|---|---|
| 담당자가 매주 CSV를 전달하고 일괄 분석 | 파일 기반 수집 | 명확한 파일 단위와 배치 주기 | 열 이름·인코딩·타입 일관성 |
| 조직 내부 테이블을 권한에 따라 반복 조회 | 데이터베이스 연결 | 구조화된 데이터의 검색·관리 | 접근 권한과 쿼리 부하 |
| 서비스가 공식 요청 규칙과 응답 형식을 제공 | API | 자동화된 접근과 명시적 인터페이스 | 인증·호출 제한·응답 형식 |
| 공식 API 없이 공개 웹페이지의 특정 항목 필요 | 웹 스크래핑 검토 | 페이지 구조에서 필요한 값을 추출 | 사이트 정책·권한·정적/동적 여부 |
예를 들어 일회성 설문 분석에 이미 완성된 CSV가 있다면 실시간 API를 새로 만들 이유가 없다. 반대로 가격이 계속 바뀌고 제공자가 공식 API를 운영한다면 사람이 매번 파일을 내려받는 방식은 적시성과 자동화 측면에서 불리하다.
파일 형식은 구조·편집·교환 목적의 균형으로 고른다
파일 기반 수집은 일회성 분석과 배치 처리에 적합하며 CSV·Excel·JSON·XML·HTML·TXT·LOG 등 다양한 형식을 다룬다. 특정 형식이 언제나 우월한 것은 아니므로 표현할 구조와 후속 작업을 함께 본다.
| 형식 | 강점 | 제약 | 선택하기 좋은 경우 |
|---|---|---|---|
| CSV | 단순하고 범용성이 높으며 여러 프로그램과 호환 | 복잡한 계층과 바이너리 표현이 어렵고 타입 정보가 없음 | 정형 자료의 일회성 분석·배치 처리 |
| Excel | 시각적 편집, 수식과 차트 지원 | 프로그래밍 처리가 복잡하고 용량이 커질 수 있음 | 사람의 검토·편집이 많은 비즈니스 자료 |
| JSON | 계층 구조와 웹 API 교환에 적합하고 읽기 쉬움 | 중첩이 깊으면 복잡하고 CSV보다 용량이 커질 수 있음 | 웹 API·설정·문서형 데이터 교환 |
| XML | 구조화 표현과 스키마 검증 | 파싱 부담이 있고 JSON보다 문법이 복잡 | 구조 검증이 필요한 웹 서비스·설정 |
| HTML | 브라우저 표현과 링크 구조 | 분석 대상 외 표시 요소와 노이즈가 많음 | 웹페이지에서 구조를 찾아 추출 |
| TXT | 단순하고 호환성이 높음 | 구조와 메타데이터가 부족 | 자유 텍스트·간단한 로그 |
| LOG | 시간순 사건과 디버깅·시스템 추적 정보 | 형식 불일치와 노이즈 때문에 정규화 필요 | 모니터링·오류 분석 |
확장자와 데이터 유형은 일대일 대응이 아니다. JSON은 보통 반정형이지만 키와 구조를 엄격히 통제하면 분석 과정에서는 정형에 가깝게 다룰 수 있다. TXT도 구분자를 일정하게 사용하면 구조를 추출할 수 있다. 실제 판정은 내용의 스키마와 구조 표지를 확인한다.
API 수집은 요청 규칙과 응답 구조를 계약처럼 읽는다
API(Application Programming Interface)는 소프트웨어 사이의 상호작용을 가능하게 하는 미리 정의된 규칙과 명령의 집합이다. 데이터 제공자가 API를 열어 두면 사용자는 화면을 직접 읽는 대신 정해진 요청을 보내고 구조화된 응답을 받을 수 있다.
REST API의 기본 흐름
- 클라이언트가 필요한 데이터와 동작을 요청한다.
- 요청은 HTTP/HTTPS를 통해 서버에 전달된다.
- 서버가 요청을 처리한다.
- 서버는 JSON·XML·HTML 같은 형식으로 결과를 응답한다.
강의에서는 요청 동작의 예로 GET·POST·PUT·DEL을 제시한다. 이 이름을 외우는 것만으로는 부족하다. 실제 수집에서는 어떤 요청이 조회인지, 인증 정보가 필요한지, 응답이 성공·실패를 어떻게 나타내는지, 반환 구조가 예상과 같은지를 함께 확인해야 한다.
통신 방식은 필요한 상호작용으로 비교한다
| 방식 | 상호작용 | 연결·질의 특징 | 적합한 요구 | 주의점 |
|---|---|---|---|---|
| HTTP/HTTPS | 요청 후 응답 | 각 요청 단위의 통신 | 일반적인 REST API와 웹 통신 | 빈번한 실시간 갱신에는 반복 요청이 늘 수 있음 |
| WebSocket | 양방향 데이터 교환 | 연결을 수립한 뒤 지속 유지 | 시세·채팅·알림처럼 실시간 이벤트 전달 | 연결 상태와 구현 복잡도를 관리해야 함 |
| GraphQL | 쿼리로 필요한 필드를 선택 | 요청마다 필요한 데이터 구조를 명시 | 복잡한 화면에서 과도한 응답을 줄이고 싶은 경우 | 질의 설계와 캐시 처리가 어려울 수 있음 |
선택 기준: 단순 조회·응답이면 HTTP 기반 API, 서버와 지속적으로 양방향 이벤트를 주고받아야 하면 WebSocket, 한 엔드포인트에서 필요한 필드 조합을 세밀하게 요청해야 하면 GraphQL을 우선 검토한다.
웹 스크래핑은 추출 대상과 허용 범위를 함께 확인한다
웹 스크래핑은 프로그램으로 웹사이트에서 필요한 데이터를 자동 추출·수집하는 기술이다. 자동으로 페이지를 방문하고 링크를 따라가며 웹 구조를 탐색하는 웹 크롤링과 초점이 다르다. 크롤링이 발견과 이동에 가깝다면 스크래핑은 특정 페이지에서 필요한 값을 뽑는 데 가깝다.
스크래핑을 시작하기 전에는 다음 항목을 순서대로 확인한다.
- 공식 API나 내려받을 수 있는 파일이 이미 제공되는지 확인한다.
- 웹사이트 정책과 접근 권한이 자동 수집을 허용하는지 확인한다.
- 페이지에서 필요한 데이터가 위치한 구조를 분석한다.
- 정적 페이지인지, 화면 실행 뒤 내용이 만들어지는 동적 페이지인지 구분한다.
- 데이터 추출 규칙과 오류·변경 감지 방법을 정한다.
강의자료는 파이썬에서 활용할 수 있는 도구 예로 requests, BeautifulSoup, Selenium, lxml을 소개한다. 도구 이름보다 중요한 것은 대상 페이지의 제공 방식과 정책에 맞는 방법을 고르는 것이다. 페이지 구조는 바뀔 수 있으므로 수집 결과가 비어 있거나 열 위치가 달라지는 실패도 탐지해야 한다.
오개념 교정: 브라우저에서 보이는 정보라고 해서 자동 수집이 곧바로 허용되거나 안정적인 것은 아니다. 공개 여부, 사이트 정책, 접근 권한, 정적·동적 구조, 변경 가능성을 별도로 확인해야 한다.
수집 계획은 목적에서 품질 검증까지 역순으로 점검한다
새 과제에서 곧바로 라이브러리나 파일 확장자를 고르지 말고 다음 판단표를 사용한다.
- 목적: 어떤 의사결정 또는 분석 질문에 답할 것인가?
- 필요 데이터: 어떤 필드·기간·단위·주기가 필요한가?
- 유형: 고정 스키마, 구조 표지, 자유 내용 중 어디에 가까운가?
- 접근 조건: 소스와 권한, 데이터 양, 실시간 요구는 무엇인가?
- 방법: 파일·데이터베이스·API·스크래핑 가운데 무엇이 조건을 만족하는가?
- 품질 검증: 정확성·완전성·일관성·유효성·적시성·상호운용성을 어떻게 확인할 것인가?
예를 들어 공개 서비스의 실시간 알림을 분석하려는데 한 달에 한 번 수동으로 CSV를 내려받는다면 적시성이 목적과 충돌한다. 반대로 1회성 과거 자료 분석에 지속 연결 방식을 구축하면 요구보다 복잡한 방법을 선택한 셈이다. 수집 기술의 우열이 아니라 분석 요구와의 적합성이 판단 기준이다.
핵심 개념 정리
- 데이터 수집은 분석 질문에 맞는 데이터를 식별하고 품질을 유지할 형태와 주기로 획득하는 과정이다.
- 정확성·완전성·일관성·유효성·적시성·상호운용성은 서로 다른 실패를 찾는 품질 기준이다.
- 정형·반정형·비정형은 확장자보다 스키마의 강도와 구조 표지의 존재로 판별한다.
- 파일·데이터베이스·API·웹 스크래핑은 소스·권한·양·실시간성에 맞춰 선택한다.
- 파일 형식은 계층 구조, 사람의 편집, 시스템 교환, 후속 분석의 요구를 함께 고려한다.
- 웹 수집은 기술적 가능성뿐 아니라 공식 제공 수단, 정책, 권한과 페이지 변경 가능성을 확인한다.
수집 문제를 만나면 도구 이름보다 먼저 분석 목적과 품질 조건을 적는다. 이어서 스키마 강도로 데이터 유형을 판별하고, 소스·권한·양·실시간성으로 수집 방법을 좁힌다. 마지막으로 선택한 형식과 주기가 여섯 품질 기준을 만족하는지 되돌아보면, 많이 모으는 수집이 아니라 신뢰할 수 있는 분석을 준비하는 수집 계획을 만들 수 있다.
예상문제 10선
1. 데이터 수집의 의미를 가장 적절하게 설명한 것은?
정답입니다.
오답입니다. 답안을 다시 선택해 보세요.
정답 및 해설 보기
정답: ②
- ① 오답: 목적 없는 대량 저장은 필요한 품질과 비용을 통제하지 못하므로 수집 설계가 아니다.
- ② 정답: 유효 데이터 탐색, 방법 선택, 정확성을 유지할 형식과 주기 결정까지 포함한다.
- ③ 오답: 통계 계산은 수집 이후 분석 단계이며 수집 자체의 정의보다 범위가 다르다.
- ④ 오답: 데이터 유형을 바꾸는 것이 수집의 필수 목적은 아니다.
2. 정확성과 일관성의 차이를 보여 주는 사례는?
정답입니다.
오답입니다. 답안을 다시 선택해 보세요.
정답 및 해설 보기
정답: ④
- ① 오답: 정확성과 일관성을 모두 만족하는 정상 사례라 차이를 드러내지 않는다.
- ② 오답: 필요한 값의 누락은 완전성 문제다.
- ③ 오답: 필요한 시점보다 늦은 데이터는 적시성 문제다.
- ④ 정답: 표현 규칙은 같아 일관되지만 실제 상태와 달라 정확하지 않을 수 있음을 보여 준다.
3. 발신자·날짜 헤더와 자유 본문·첨부 이미지를 가진 이메일을 분석할 때 가장 타당한 판단은?
정답입니다.
오답입니다. 답안을 다시 선택해 보세요.
정답 및 해설 보기
정답: ①
- ① 정답: 분석 대상 부분의 구조 표지와 자유도를 구분하면 복합 데이터의 유형을 정확히 판단할 수 있다.
- ② 오답: 확장자보다 실제 스키마와 내용 구조를 확인해야 하며 이메일은 고정 테이블이 아니다.
- ③ 오답: 비정형 첨부가 있어도 발신자·날짜 같은 헤더 구조는 유지된다.
- ④ 오답: 일부 구조화 필드가 자유 본문까지 행·열 구조로 만들지는 않는다.
4. 반정형 데이터의 특징으로 옳은 것은?
정답입니다.
오답입니다. 답안을 다시 선택해 보세요.
정답 및 해설 보기
정답: ③
- ① 오답: 구조 표지가 거의 없는 설명은 비정형 데이터에 더 가깝다.
- ② 오답: 엄격한 행·열 스키마는 정형 데이터의 특징이다.
- ③ 정답: 일정 수준의 구조와 스키마 유연성을 함께 갖는 것이 중간적 성격이다.
- ④ 오답: 분석 전에 구조 파악과 정제가 추가로 필요할 수 있다.
5. 담당자가 매주 같은 열의 CSV를 전달하며 월말에 한 번 분석한다. 우선 선택할 수집 방식은?
정답입니다.
오답입니다. 답안을 다시 선택해 보세요.
정답 및 해설 보기
정답: ①
- ① 정답: 이미 파일 단위로 제공되고 분석 주기도 배치이므로 가장 단순한 적합 방법이다.
- ② 오답: 월말 분석에 지속 실시간 연결은 요구보다 복잡하다.
- ③ 오답: 데이터 소스가 CSV 파일로 명확하므로 웹 탐색이 필요하지 않다.
- ④ 오답: 입력이 정형 CSV인데 비정형 이미지 분석을 선택하면 소스 유형과 맞지 않는다.
6. CSV와 JSON을 비교한 설명으로 가장 적절한 것은?
정답입니다.
오답입니다. 답안을 다시 선택해 보세요.
정답 및 해설 보기
정답: ④
- ① 오답: 계층 구조는 JSON의 강점이고 CSV는 단순한 행·열에 적합하다.
- ② 오답: 강의에서는 두 형식 모두 바이너리 데이터 직접 저장에 제약이 있다고 설명한다.
- ③ 오답: JSON은 중첩이 깊으면 복잡해지고 CSV보다 용량이 커질 수 있다.
- ④ 정답: 두 형식의 구조 표현 능력과 대표 용도를 올바르게 연결했다.
7. REST API를 이용한 데이터 수집의 기본 흐름으로 적절한 것은?
정답입니다.
오답입니다. 답안을 다시 선택해 보세요.
정답 및 해설 보기
정답: ②
- ① 오답: 요청이 응답보다 먼저이며 미리 정의된 규칙을 삭제하지 않는다.
- ② 정답: 클라이언트가 요청하고 서버가 처리한 결과를 구조화된 형식으로 반환하는 흐름이다.
- ③ 오답: 파일 편집과 웹 크롤링은 REST 요청·응답의 필수 단계가 아니다.
- ④ 오답: API 수집은 서버 응답을 받아 검증·활용하는 과정이며 응답을 무시하지 않는다.
8. 실시간 채팅 메시지를 서버와 지속적으로 주고받아야 할 때 우선 검토할 방식은?
정답입니다.
오답입니다. 답안을 다시 선택해 보세요.
정답 및 해설 보기
정답: ③
- ① 오답: 월 단위 배치는 실시간 메시지 전달 요구를 만족하지 못한다.
- ② 오답: 정적 파일 추출은 지속적인 양방향 이벤트 교환 방식이 아니다.
- ③ 정답: 지속 연결과 양방향 통신 특성이 채팅 같은 실시간 이벤트에 적합하다.
- ④ 오답: 수동 파일 편집은 자동 실시간 통신을 제공하지 않는다.
9. 웹페이지에 보이는 정보는 바로 자동 수집해도 된다는 판단의 문제점은?
정답입니다.
오답입니다. 답안을 다시 선택해 보세요.
정답 및 해설 보기
정답: ④
- ① 오답: 웹페이지 안에도 표 같은 구조가 있을 수 있지만 질문의 핵심은 허용 범위 판단이다.
- ② 오답: API의 실시간성은 제공 방식에 따라 달라지며 공개 정보 수집 허용과 직접 연결되지 않는다.
- ③ 오답: 두 기술의 초점 혼동도 오류지만 공개 여부와 허용 여부를 동일시한 핵심 문제를 충분히 설명하지 못한다.
- ④ 정답: 정책·권한·정적/동적 구조와 변경 가능성을 별도로 확인해야 한다.
10. 수집 계획을 세우는 순서로 가장 적절한 것은?
정답입니다.
오답입니다. 답안을 다시 선택해 보세요.
정답 및 해설 보기
정답: ②
- ① 오답: 목적 없이 도구와 양을 먼저 정하면 필요한 데이터와 품질을 통제할 수 없다.
- ② 정답: 목적에서 요구를 도출하고 조건에 맞는 방법을 선택한 뒤 품질을 확인하는 순서다.
- ③ 오답: 형식과 연결 방식은 목적·소스·실시간 요구를 확인한 뒤 결정해야 하며 정책을 무시할 수 없다.
- ④ 오답: 스크래핑은 여러 후보 중 하나이고 실행 전에 목적과 권한을 먼저 확인해야 한다.
참고 자료와 작성 기준
이 글은 해당 차시 강의자료를 바탕으로 학습 목적에 맞게 재구성한 비공식 학습자료입니다. 유형 판별, 수집 방법 선택 사례와 문제 해설은 학습자의 이해를 돕도록 구성하고 검토했습니다.
- 작성·편집: 올에이클래스 학습연구팀
- 주요 근거: 한국방송통신대학교 컴퓨터과학과 「오픈소스기반데이터분석」 4강 ‘데이터 수집’ 강의록
- 보충 자료: 별도 외부 자료를 사용하지 않음
- 편집 원칙: 올에이클래스 편집 정책
- 최종 내용 검토: 2026-08-30
댓글
댓글 쓰기