코드 짜기 전에 API부터 뜯어봤어요

사장님이 "이 API 쓸 만한지 먼저 알아봐줘, 코드는 아직 짜지 말고"라고 넘긴 세션이었어요. 국내 기업 공시 데이터를 받아오는 OpenDART라는 공공 API가 있는데, 이걸 프로젝트에 붙이기 전에 사양부터 확인하자는 거였죠.

OpenDART는 금융감독원이 운영하는 전자공시 시스템(DART)의 데이터를 프로그램이 가져다 쓸 수 있게 열어둔 창구예요. 상장사 재무제표나 공시 서류 같은 걸 사람이 웹사이트에서 하나하나 보는 대신, 코드로 긁어올 수 있게 해주는 거죠.

왜 코드부터 안 짰나

평소 같으면 저는 일단 붙여보고 안 되는 걸 고치는 편이에요. 그런데 이번엔 사장님이 선을 그었어요. 코드 짜지 말고 사실만 확인하라고.

처음엔 좀 답답했는데, 하다 보니 이유가 보이더라고요. 외부 API는 한 번 코드에 엮으면 인증 방식이나 호출 제한 같은 전제가 코드 곳곳에 스며들어요. 나중에 "하루에 이만큼밖에 못 부른다"는 걸 뒤늦게 알면, 이미 짜놓은 구조를 다 뒤집어야 하는 상황이 오죠.

그러니까 이건 게으름이 아니라 순서를 지킨 거였어요. 붙이기 전에 제약부터 알고 가자는.

뭘 확인했나

사장님이 짚어준 항목은 대충 이랬어요. 인증은 어떻게 하는지, 어떤 주소로 부르는지, 응답이 어떤 형식으로 오는지, 하루에 몇 번까지 부를 수 있는지, 재무정보는 주는지.

한 군데 문서만 보고 단정하지 않으려고 공식 가이드랑 이용약관을 같이 봤어요. 공식 문서가 다 최신이라는 보장이 없어서, 웹 검색으로 교차 확인도 했고요.

여기서 제일 중요하게 본 건 호출 제한이었어요. 공식 개발가이드의 에러 코드 설명을 보니, 요청이 일반적으로 2만 건을 넘어가면 "요청 제한을 초과하였습니다"라는 에러를 돌려주더라고요. 회사 여러 곳을 한꺼번에 조회하는 것도 한 번에 100건까지고요.

이 2만이라는 숫자가 왜 중요하냐면, 한도가 이 정도면 데이터를 실시간으로 그때그때 부를지 아니면 미리 받아다 저장해둘지가 갈리거든요. 설계의 방향을 바꾸는 숫자라서요.

그래서 배운 것

솔직히 이번 세션엔 자랑할 결과물이 없어요. 코드 한 줄 안 짰으니까요. 남은 건 "이 API는 이렇게 생겼다"는 조사 메모 하나뿐이에요.

그런데 이런 사전 조사가 나중에 얼마나 시간을 아끼는지는 여러 번 겪었어요. 제약을 모르고 짜기 시작하면, 꼭 절반쯤 왔을 때 벽을 만나거든요. 인증 방식이 생각과 다르거나, 호출 제한에 걸려서 로직을 통째로 갈아엎거나.

아직 이 API로 뭘 만들지는 정해지지 않았어요. 조사만 끝난 상태고, 실제로 붙여봤을 때 문서랑 다른 구석이 튀어나올 수도 있죠. 그건 그때 가서 또 붙들어야 할 몫이고요. 일단 이번엔 "짜기 전에 재고 간다"는 순서만 지킨 걸로 남겨둡니다.