문서를 편집하고 저장한 뒤 다시 열었을 때, 마지막으로 수정한 내용이 그대로 남아 있어야 한다. 편집 기능을 만들면서 가장 기본적으로 기대한 동작이었다. 처음에는 한 사람이 한 화면에서 문서를 수정하는 흐름을 중심으로 생각했다. 그런데 한 사용자가 같은 문서를 브라우

요즘은 일을 하다가 막히는 시간이 많이 줄었다. 처음 보는 오류가 나와도 상황을 설명하면 원인 후보가 바로 나온다. 낯선 코드도 파일 몇 개만 보여주면 구조를 정리해 준다. 구현 방향부터 수정할 코드까지 빠르게 받을 수 있다. 분명 편해졌다. 이전보다 할 수 있는

Kubernetes를 직접 구축하거나 운영해 본 경험은 없었다. 그런데 회사 프로젝트가 이미 Kubernetes 환경으로 구성되어 있었고, 기능을 개발하는 과정에서 기존 배포 구조를 읽고 일부 설정을 수정해야 했다. 처음에는 내가 맡은 기능 코드만 잘 작성하면 된다고

웹 서비스를 만들다 보면 어느 순간 이런 말을 듣는다. > "로컬에 직접 설치하지 말고 Docker로 띄우면 돼요." 처음에는 Docker가 가상 머신의 가벼운 버전쯤이라고 생각했다. 명령어 몇 개로 서버를 만드는 도구인가 싶기도 했다. 막상 공부해 보니 Docke

QGIS 실습 중에는 오류 문구가 원인보다 결과만 알려 주는 경우가 많았다. 교차 영역 분석 실패라고 떠도 실제 원인은 특정 폴리곤 하나의 자기 교차일 수 있었고, 필드를 추가할 수 없다는 메시지는 편집 모드나 Shapefile 형식 제한에서 시작되기도 했다. 그래서

QGIS 실습을 하면서 가장 많이 한 말은 “왜 아무것도 안 되지?”였다. 나중에 보니 큰 오류보다 현재 활성 레이어, 선택 도구, 인코딩처럼 작은 상태를 놓친 경우가 많았다. 이번 글에서는 실제로 헷갈렸던 지점을 질문과 답 형태로 다시 정리했다. 화면 이름은 QGI

QGIS를 처음 켰을 때 가장 힘들었던 건 버튼 위치보다 용어였다. 버퍼, 디졸브, 교차 영역처럼 이름만 봐서는 결과를 상상하기 어려운 도구가 계속 나왔다. 설명을 하나씩 외우면 금방 섞였고, 실제 작업 흐름 안에 놓고 보니 그제야 차이가 보였다. 이번 글은 건물·도

토지/건축 공간 데이터를 다루다 보면 PNU라는 19자리 문자열을 자주 만난다. 처음에는 주소를 숫자로 바꾼 코드라고 생각했지만, 실제로는 법정동 코드와 지번 구조를 결합해 필지를 식별하는 키였다. 이번 글에서는 PNU의 자릿수를 나눠 읽는 법과 데이터 조인에 사용할

PostGIS를 처음 접했을 때는 지도 도형을 PostgreSQL에 저장하는 확장 정도로 생각했다. 실제로는 “이 점이 어느 행정구역 안에 있는가”, “도로와 하천이 교차하는가”, “주변 500m 안에 무엇이 있는가”를 SQL로 묻는 도구에 가까웠다. 이번 글에서는

QGIS에서 파일 형식을 바꾸거나 래스터를 자를 때 버튼 몇 번이면 작업이 끝난다. 같은 작업을 반복하거나 서버에서 자동화하려고 보니 그 뒤에서 GDAL 도구가 움직이고 있었다. 이번 글에서는 GDAL이 무엇인지, QGIS와 어떤 관계인지, 자주 쓰는 명령을 어떤 기

GIS 데이터를 처음 받았을 때는 확장자부터 헷갈렸다. .shp 파일을 열려고 했더니 옆에 있는 .dbf와 .shx도 필요했고, .gpkg 하나에는 여러 레이어가 들어 있었다. 위성영상처럼 보이는 .tif는 일반 이미지와 달리 지도 위의 정확한 위치에 놓였다. 파일

좌표가 어긋났을 때 처음에는 +proj, +datum, +towgs84 같은 값을 복사해 넣으면 해결되는 줄 알았다. 하지만 좌표계 정의와 좌표 변환은 같은 일이 아니었고, 문자열 형식만 바꿔도 일부 정보가 사라질 수 있었다. 이번 글에서는 WKT와 PROJ 문자열의

GIS 파일을 처음 열었을 때 가장 당황스러웠던 것은 EPSG:4326, EPSG:3857, EPSG:5179 같은 숫자였다. 모두 좌표계 이름처럼 쓰이지만 역할은 꽤 다르다. 코드를 잘못 지정하면 데이터가 바다로 날아가고, 표시가 정상이어도 거리와 면적이 틀릴 수 있

처음 위도와 경도를 배울 때는 지구에 원래부터 그어진 절대 좌표라고 생각했다. 하지만 같은 장소도 어떤 지구 모델과 기준을 사용하느냐에 따라 좌표가 달라질 수 있다. 좌표는 숫자만으로 완성되지 않고 그 숫자를 해석하는 규칙까지 있어야 한다. 이 글에서는 지오이드와 타

지도 위에 점을 찍는 기능을 만들면 곧 GIS를 다루는 것이라고 생각했다. 그런데 자료를 찾아볼수록 지도는 결과를 보여 주는 화면일 뿐이었다. GIS에서 더 중요한 질문은 무엇을 어디에 저장하고, 위치를 기준으로 어떤 관계를 계산할 것인가였다. 이번 글에서는 GIS를

한 문단 요약 웹 서비스에 이미지와 동영상 업로드를 붙일 때 처음에는 파일을 API 서버가 받아 저장소로 넘기면 된다고 생각했다. 작은 이미지는 이 방식으로도 충분했지만 동영상이 커지자 서버 메모리, 네트워크 대역폭, 요청 시간, 실패 복구가 한꺼번에 문제가 됐다.

Sequel이란 언어의 시초표준 질의어로 채택되어 널리 쓰이는 관계형 질의언어관계대수나 관계해석은 확실한 이론적 배경을 제공하나 상용으로 쓰이기에는 어렵고 적절 X → SQL 사용DDL(데이터 정의(Definition) 언어)데이터 저장 구조를 명시테이블 스키마의 생성

정렬시켜야할 대상은 레코드(record) —> 행에 해당레코드는 필드(field) 로 구성 —> 열에 해당키필드로 레코드와 레코드를 구분모든 경우에 최적의 정렬 알고리즘은 X → 각 응용분야에 적합한 정렬 방법을 사용해야 함 구분 요소레코드 수레코드 크기Key의 특

💡그래프란? 정점(node) 와 그 정점을 연결하는 간선( edge)로 이루어진 자료구조 > 그래프 탐색의 종류 2가지 : DFS, BFS > 💡깊이 우선 탐색(DFS) 📌 개념 그래프의 시작 노드에서 출발하여 탐색할 한 쪽 분기를 정하여 최대깊이 까지

1978년 :로렌스 J. 엘리슨(현 회장)이 관계형 DBMS인 오라클 첫 번째 버전(Version 1)을 개발1979년 : 회사명을 RSI(Relational Software Inc.)로 바꾸고 첫 번째 상용 DBMS인 오라클 두 번째 버전(Version 2)을 개발1