gemini2k 님의 블로그

좋은 공간데이터가 공개되어 있어도, 막상 내 지도에 올리려면 몇 단계를 거쳐야 한다. 형식과 좌표계가 제각각이라, 받자마자 바로 겹쳐지는 일은 드물다.형식을 확인한다공간데이터는 여러 형식으로 배포된다. 점·선·면을 담는 형식이 있고, 위치를 표 형태로 담은 것도 있다. 어떤 형식인지에 따라 여는 방법이 다르므로, 내려받기 전에 형식부터 본다. 압축 안에 여러 파일이 한 묶음으로 들어 있는 형식도 있어, 일부만 빠지면 열리지 않는다.좌표계를 맞춘다앞서 다룬 좌표계 문제가 여기서도 나온다. 받은 데이터의 좌표계가 내 지도와 다르면 위치가 어긋난다. 데이터에 좌표계 정보가 함께 들어 있는지 확인하고, 다르면 같은 기준으로 변환한 뒤 겹친다.인코딩과 속성을 본다한글 속성이 깨져 보이는 일이 흔하다. 인코딩이 맞..

버퍼와 중첩으로 입지를 고르는 법GIS가 단순한 지도 그리기와 다른 점은, 위치들 사이의 관계를 계산할 수 있다는 데 있다. 새 시설을 어디에 둘지 같은 질문에 감이 아니라 근거로 답하게 해 준다.버퍼 — 일정 거리 안을 본다어떤 지점에서 반경 몇 미터 안에 무엇이 있는지를 보는 것이 버퍼 분석이다. 기존 시설 주변 일정 거리를 원으로 둘러, 그 안과 밖을 나눈다. 예를 들어 기존 시설에서 일정 거리 안은 이미 서비스가 닿는 곳으로 보고, 그 밖을 후보로 추린다.중첩 — 여러 조건을 겹친다버퍼만으로는 부족하다. 거리뿐 아니라 수요가 많은 곳, 피해야 할 구역 같은 조건이 함께 있기 때문이다. 여러 조건을 각각 영역으로 그린 뒤 겹쳐서, 모든 조건을 만족하는 영역만 남기는 것이 중첩 분석이다. 조건이 늘수..

지역별 수치를 색의 농담으로 보여 주는 지도를 단계구분도라 부른다. 한눈에 들어와서 보고서에 자주 쓰는데, 같은 데이터라도 색을 어떻게 나누느냐에 따라 전혀 다른 인상을 준다.구간을 어떻게 나누느냐가 인상을 바꾼다값을 몇 개의 구간으로 나눠 색을 입히는데, 그 경계를 어디에 두느냐가 핵심이다. 같은 간격으로 자를 때, 값의 개수가 고르도록 자를 때, 자연스러운 끊김을 찾아 자를 때 결과가 달라진다. 어떤 방식은 차이를 부풀리고, 어떤 방식은 평평하게 보이게 한다. 의도가 없어도 오해를 부른다.건수보다 비율을 의심한다인구가 많은 지역은 무엇을 세든 숫자가 크게 마련이다. 민원 건수를 그대로 색칠하면 사람 많은 곳이 늘 진하게 나온다. 인구나 면적으로 나눈 비율을 함께 보지 않으면, "사람이 많다"를 "문제..

행정 데이터에는 대부분 주소가 들어 있다. 그런데 주소는 그대로 지도에 찍히지 않는다. 위치를 좌표로 바꾸는 과정이 필요하고, 이걸 지오코딩이라 부른다. 여기서 첫 함정을 만난다.변환이 다 되는 게 아니다주소가 멀쩡해 보여도 변환에 실패하는 경우가 적지 않다. 도로명주소와 지번주소가 섞여 있거나, 옛 지명이 남아 있거나, 띄어쓰기와 오타가 있거나, 건물명만 적혀 있을 때 그렇다. 변환기가 모르는 주소는 좌표를 못 받고 조용히 빠진다.실패율을 먼저 확인한다가장 위험한 건 변환된 것만 지도에 찍고 만족하는 일이다. 절반만 변환됐는데 그 절반만 보고 "여기에 몰려 있다"고 판단하면, 못 찍힌 절반이 통째로 사라진 그림을 보는 셈이다. 그래서 나는 변환 직후 "몇 건 중 몇 건이 좌표를 받았는지"부터 센다.실패..

지도 데이터를 처음 다룰 때 가장 자주 막히는 곳이 좌표계다. 분명히 같은 위치인데 데이터마다 숫자가 전혀 달라서 한참을 헤맸다. 좌표계를 모르면, 점이 엉뚱한 바다 한가운데 찍히는 일이 생긴다.## 위경도와 평면좌표는 다른 언어다위경도는 지구를 둥근 그대로 두고 위치를 각도로 표현한다. 우리가 흔히 보는 37.5, 127.0 같은 숫자다. 반면 평면좌표는 둥근 지구를 평평한 종이에 펼친 뒤 미터 단위로 위치를 적는 방식이다. 우리나라 지도에서 자주 쓰는 중부원점 계열이 여기에 속한다. 둘은 같은 장소를 다른 언어로 말하는 셈이라, 그대로 섞으면 통하지 않는다.## 무엇으로 받았는지부터 확인한다데이터를 받으면 좌표값의 생김새부터 본다. 소수점이 붙은 두세 자리 숫자라면 위경도일 가능성이 높고, 수십만 단..

감리를 앞두고 산출물을 두툼하게 만드는 데 힘을 쏟는 경우를 본다. 그런데 분량이 많다고 좋은 산출물은 아니다. 정작 중요한 건 "이 결과가 어디서 왔는지" 따라갈 수 있느냐다.## 분량은 품질의 증거가 아니다설계서가 수백 쪽이어도 요구사항과 연결되지 않으면 점검할 수가 없다. 반대로 간결해도 어떤 요구에서 비롯된 설계인지가 분명하면 검토가 빠르다. 채워 넣은 분량보다, 앞뒤가 이어지는지가 신뢰를 만든다.## 추적성이 핵심이다좋은 산출물은 요구사항부터 설계, 구현, 시험까지 한 줄로 이어진다. 어떤 요구가 어느 설계로, 어떤 기능으로, 어떤 시험으로 확인됐는지 따라갈 수 있어야 한다. 이 연결이 끊긴 지점이 대개 누락이나 오류가 숨는 곳이다.## 실제 시스템과 일치하는가문서는 그럴듯한데 실제 화면과 다른..

감리가 한 번에 모든 걸 본다고 생각하면 부담이 크다. 실제로는 사업의 흐름을 따라 단계마다 보는 초점이 다르다. 어느 단계에서 무엇을 점검하는지 알면 준비가 한결 수월하다.## 요구 정의 단계 — 방향이 맞나초반에는 무엇을 만들 것인지가 분명한지를 본다. 요구사항이 구체적인지, 빠진 것은 없는지, 서로 충돌하는 요구는 없는지. 여기서 방향이 어긋나면 뒤가 다 흔들리므로 가장 공들여 보는 지점이다.## 설계 단계 — 요구를 제대로 옮겼나다음에는 정의한 요구가 설계로 제대로 이어졌는지를 본다. 화면, 데이터 구조, 기능이 요구사항과 짝이 맞는지 추적한다. 요구에는 있는데 설계에 빠진 것, 요구에 없는데 설계에 들어간 것을 찾는다.## 종료 단계 — 만든 대로 동작하나마무리에서는 실제로 요구한 대로 동작하는..

# 요구사항 정의서가 부실하면 생기는 일정보화 사업에서 가장 앞에 놓이는 문서가 요구사항 정의서다. 이 문서가 흔들리면, 뒤에 오는 설계와 개발이 아무리 성실해도 엉뚱한 곳에 도착한다. 첫 단추 이야기가 괜히 나오는 게 아니다.## 모호함은 뒤로 갈수록 커진다정의서에 "직관적인 화면"이라고만 적혀 있으면, 개발자는 자기 식으로 해석한다. 발주자가 머릿속에 그린 것과 다른 결과가 나오고, 그제야 "이게 아닌데"가 시작된다. 앞에서 한 줄로 끝낸 모호함이, 뒤에서는 화면 전체를 다시 만드는 일이 된다.## 검증할 수 있게 적는다좋은 요구사항은 나중에 "됐다/안 됐다"를 판단할 수 있게 쓰여 있다. "빠르게 처리"보다 "조회 결과가 몇 초 안에 나온다"처럼, 확인 가능한 형태로 적으면 시험 단계에서 다툴 일이..

감리는 개발자만 받는 평가라고 생각하기 쉽지만, 지적사항의 상당수는 발주자가 미리 준비하면 줄어든다. 무엇을 만들어 달라고 했는지가 흐릿하면, 그 위에서 만든 결과도 흐릴 수밖에 없다.## 요구사항을 분명히 적어 둔다가장 흔한 문제의 출발점은 모호한 요구사항이다. "사용하기 편하게"처럼 사람마다 다르게 읽는 표현은 나중에 분쟁의 씨앗이 된다. 무엇을, 어떤 조건에서, 어떻게 동작해야 하는지를 구체적으로 적어 두면 만드는 쪽도 점검하는 쪽도 같은 기준을 본다.## 변경은 기록으로 남긴다사업을 진행하다 보면 요구가 바뀐다. 그 자체는 자연스럽지만, 말로만 바꾸고 문서에 남기지 않으면 나중에 "그렇게 합의한 적 없다"는 다툼이 생긴다. 변경 이력을 남겨 두면 감리에서도 흐름을 설명할 수 있다.## 산출물을 미..

"감리를 받는다"고 하면 시험을 치르는 것처럼 긴장하는 사람이 많다. 잘잘못을 따지러 오는 사람으로 여기기 때문이다. 막상 겪어 보면 감리는 점수를 매기는 일이라기보다, 시스템이 제대로 만들어지고 있는지 제3자의 눈으로 점검해 주는 일에 가깝다.## 발주자와 개발자 사이의 제3자사업을 맡긴 쪽과 만드는 쪽은 각자의 입장이 있다. 그 사이에서 독립적인 시각으로 "요구한 대로 만들어지고 있는가", "품질에 문제는 없는가"를 점검하는 것이 감리다. 어느 한쪽 편이 아니라는 점이 핵심이다.## 끝나고 보는 게 아니라 도중에 본다감리는 사업이 다 끝난 뒤 결과만 보는 것이 아니다. 요구사항을 정의하는 단계, 설계하는 단계, 마무리하는 단계처럼 중간중간 들여다본다. 일찍 발견할수록 고치는 비용이 적기 때문이다. 다..