다양한 스펙의 다양한 Open API로부터 데이터 받아올 수 있는 범용 프로그램을 만들고 있다.

설계부터 구현까지는 AI가 하고, 나는 "이런 경우도 대응해줘"라는 식으로 스크립트의 일반화를 주도했다.

다음과 같이 일반화 과정을 거쳤다. 수학적 일반화를 상상하면서 비슷하게 해보려고 했다.

1/ 데이터 받아서 csv로 저장하기

2/ Aurora DB에 저장하기 (테이블 및 컬럼 자동 생성)

여기까지는 단일 파이썬 파일로 해결했다.

이 시점에서 "수학적 일반화"를 AI에게 설명하고, 그러한 작업을 해나가자고 제안했다.

그러자 데이터 스펙을 정의하는 yaml 파일과, 거기서 설정값을 읽어오는 config 파일, ETL pipeline 역할 하는 data_fetcher 파일로 구분됐다.

3/ 재시도 횟수 및 간격 설정

4/ 실패 지점 확인 가능한 로깅

여기서부터 일반화의 핵심이 등장한다. URL 파라미터 타입이 다양한데, 어떤 종류라도 만들(prepare) 수 있게 해야 했다. 경험해보니 처음에 생각지 못한 형태가 많았다. 우선 뻔한 것은:

5/ string_array: e.g. ["지역1", "지역2", "지역3", ..., "지역N"]

생각하지 못했던 건 이런 것이다. 많은 경우 remote API는 pagination이 돼 있었으므로...

6/ pagination: e.g. [1, 2, 3, 4, ...]

게다가 어떤 경우에는 시작연월과 종료연월을 범위로 지정해야 했다. 따라서:

7/ pair_array: e.g. [{"startYymm": 200101, "endYymm": 200112}, {"startYymm": 200201, "endYymm": 200212}, ..., {...}]

그리고 데이터 범위를 코드로 지정해야 하는 경우가 많았다. (10100, 10200, ...) 이 경우는:

8/ numeric_range: e.g. start: 10000, end: 10900, step: 100

여기서 끝이 아니었다. 10년치 데이터를 받았는데 중간에 컬럼명이 바뀌는 경우가 있었다. 이 경우 처음에는 DB에 해당 컬럼이 없다며 에러가 났지만 새로운 컬럼을 발견하면 즉시 추가하도록 변경했다.

이 외에도 nested data가 있는 경우 flatten하는 로직이 필요했고, 어떤 경우에는 연도마다 url이 별도로 있는 경우도 있었다. 즉 파라미터는 그대로 두고 url만 바뀌는 경우다. 이 때는 데이터를 그냥 저장하면 연도 구분이 안 되므로, 연도 컬럼을 추가해야 했다. 그래서 요청 변수 또한 원할 경우(flag가 있으면) 함께 저장하는 로직을 추가했다.

끝으로 서버에서 실행할 수 있도록 GitHub Actions 워크플로우를 추가해, 깃헙 모바일이나 웹에서 트리거만 해주면 서버에서 ETL 작업을 돌려놓을 수 있게 되었다. 그리고 작업이 끝나면 메일도 보내준다.

이렇게 기능을 하나씩 덧붙이다 보니, 어느새 내 실력으로 이해하기 어려운 코드베이스가 되었다. 하지만 그 기능은 강력하다. 어떤 Open API라 하더라도, 요청 스펙을 잘 보고 yaml로 정리하면 데이터를 받아서 DB에 적재해준다.

이 작업 자체가 어려운 건 아니다. 사람이 하더라도 할 수 있을 것이다. 하지만 챙길 게 많아서, 시간이 오래 걸렸을 것이다. 아무리 시니어 엔지니어라고 해도. 가령 AI는 로깅의 레벨과 포맷을 잘 설정해두어서, 데이터가 어디까지 조회되었고 어디서 왜 중단됐는지 한 눈에 알아보기 쉽게 돼 있다. 사람이 못하는 게 아니라, 귀찮아서 안 하게 되는 일들이다. 그러면서도 작업 효율에는 큰 영향을 미치는 요소다.

그리고 새로운 데이터 형식을 발견하고 추가할 때마다 인지 부하가 없다. "영향 받는 코드 모두 찾아서 상응하게 변경해줘"라고 하면 그렇게 해준다. 그리고 "이번 작업으로 인해 이제까지 동작하던 기능이 동작 않게 되면 안 되므로, backward compatibility 신경써줘"라고 하면 그렇게 해준다.

AI가 코드를 시니어 엔지니어보다도 더 잘 짜므로, 이제는 설명 자료를 남기는 게 중요해졌다. 그래서 아래 같은 요청이 중요하다.

"이쯤에서 코드를 한 번 리팩터링하고 정리해줘"

"오버엔지니어링 의심되는 곳을 찾아서 단순화해줘"

"네가 변경한 코드의 diff와 그 이유를 MD 파일로 남겨줘"

"나같은 초보자가 오랜 시간 후에 코드를 보더라도 맥락을 이해할 수 있도록 적재적소에 코멘트를 달아줘"

"이 파일에 대해서 line by line으로 친절하게 syntax, advanced technique, 함수 호출 관계도, API contract 설명하는 MD 파일 남겨줘"

AI 컴패니언이 없었다면 나 혼자 할 수도 없을 뿐더러, 하더라도 열 배 정도의 시간이 걸렸을 일이다. 이제 중요한 건 무엇을, 왜, 어떻게 부탁해야 하는지 고민하는 '사고력'이다.