다른 서비스를 내 앱에 이어붙이려다, 벽 하나를 만났다 🧩

돈독에 종목 검색 기능을 붙이면서, 검색 결과를 누르면 그 종목의 재무제표를 요약한 카드가 뜨게 만들고 싶었어요.

문제는 재무제표 데이터를 처음부터 제가 다 짜서 갖고 있지 않다는 거였습니다. 이미 제가 따로 만들어둔 파이썬 프로젝트가 전자공시(DART) 데이터를 긁어다 정리해주고 있었거든요. 돈독은 다른 스택으로 짜여 있고요.

한 프로젝트 안에 두 스택을 억지로 욱여넣을 수는 없으니, 결국 “이 둘을 어떻게 이어붙일까”부터 풀어야 했습니다.

왜 이게 필요했나

돈독의 원칙은 “흩어진 자산을 한 화면에”인데, 여기서 흩어진 건 계좌뿐만이 아니었어요. 제가 만든 도구들도 서로 다른 스택으로 흩어져 있었습니다.

재무제표 계산 코드를 돈독 안으로 통째로 옮겨오는 방법도 있었지만, 그러면 두 프로젝트가 영영 한 몸처럼 엉켜서 어느 한쪽만 따로 고치기 어려워집니다. 그래서 다른 길을 택했어요. 기존 코드는 그대로 두고, 그걸 부르는 작은 창구 하나만 새로 만들자고요.

그래서, 코드를 통째로 서비스 하나로 뜯어냈다 🔌

재무제표 계산이 들어있는 프로젝트 앞에 작은 창구를 하나 세웠습니다. 돈독은 그 창구에 “이 종목 정보 줘”라고 부탁만 하고, 돌아온 답을 그대로 카드에 뿌립니다. 계산은 원래 있던 코드가 그대로 하고요.

두 프로젝트는 코드를 공유하지 않아요. 묻고 답하는 통로 하나로만 이어집니다. 그래서 재무제표 쪽을 고쳐도 돈독을 다시 배포할 필요가 없고, 반대도 마찬가지입니다.

접근 범위도 처음부터 좁게 잡았어요. 아직 검증 중인 기능이라 제가 정해둔 이메일 목록에 있는 사람에게만 카드가 보이고, 목록에 없으면 기본적으로 안 보이게 막아뒀습니다. 판단이 애매하면 보여주는 쪽이 아니라 막는 쪽으로 기울게요.

걸렸던 것, 하나 — 응답이 매번 다른 모양으로 왔다

연결은 됐는데, 돌아오는 답의 모양이 물어볼 때마다 달랐습니다. 사람 눈에는 둘 다 “표”인데, 코드 입장에선 서로 다른 물건이라 그대로는 못 씁니다.

돈독 쪽에서 “이번엔 어떤 모양이지”를 매번 따지게 하면, 재무제표 쪽이 조금만 바뀌어도 돈독이 같이 깨집니다. 그래서 모양을 맞추는 자리를 한 곳으로 정했어요. 창구 안에서 무엇이 들어오든 반드시 같은 형태로 바꿔서 내보내기로요.

걸렸던 것, 둘 — 첫 호출이 수십 초 걸렸다

DART 원본 데이터를 처음 불러올 때, 응답이 오기까지 수십 초가 걸렸습니다. 화면에 아무 반응이 없으면 사용자는 그냥 앱이 멈췄다고 생각하고 나가버리거든요.

여기서도 원칙을 하나 세웠어요. 같은 종목을 다시 볼 땐 아까 받아둔 답을 재활용해서 바로 보여주고, 처음 조회하는 동안엔 “불러오는 중”이라는 걸 화면에 분명히 보여주자고요.

---

서로 다른 두 프로젝트를 잇는 건, 코드를 합치는 게 아니라 창구 하나를 명확히 정하는 일이었다.

프롬프트로 따라 하기

같은 스택끼리만 일하는 분이라면 이 얘기가 안 와닿을 수도 있어요. 하지만 “내가 이미 만들어둔 도구를, 지금 만드는 다른 프로젝트에서도 쓰고 싶다”는 상황은 생각보다 자주 옵니다. 순서대로 프롬프트를 드릴게요.

1. 기존 코드에 창구 하나 세우기

프로젝트 스택이 다르면 코드를 억지로 합칠 게 아니라, 기존 코드 앞에 작은 창구를 하나 세우는 게 낫습니다.

프롬프트

나는 <스택 A>로 짠 앱이 있고, 따로 <스택 B>로 짠 기존 코드(라이브러리·스크립트)가 있어.
이 기존 코드를 내 앱에서 바로 부르기 어려우니, 감싸는 작은 API 서버로 만들어줘.

- 엔드포인트는 최소 하나만: 입력을 받아 기존 코드를 호출하고, 결과를 JSON으로 돌려주면 돼.
- 포트는 <포트번호>로 로컬에서 먼저 띄워서 확인하고 싶어.
- 바로 짜지 말고, 먼저 기존 코드의 함수 시그니처를 읽고 어떤 입력·출력을 감쌀지 설명해줘.

✅ 이렇게 되면 성공 — 내 컴퓨터에서 그 주소를 열었을 때 데이터가 돌아옵니다.

⚠️ 막히면 — 응답이 비거나 에러라면 “이 함수를 직접 호출했을 때 실제로 뭐가 나오는지 먼저 출력해봐”라고 물어보세요.

2. 뒤섞인 반환 타입을 한 구조로 통일하기

이게 제가 제일 크게 걸린 지점입니다. 호출 상황마다 응답 형태가 달랐어요.

프롬프트

방금 만든 서버에서, 기존 코드가 호출 상황에 따라 dict으로 나올 때도 있고
다른 형태(예: 데이터프레임 객체)로 나올 때도 있어. 내 앱은 일관된 JSON만 받고 싶어.

- 먼저 실제 반환값 몇 가지 형태를 출력해서 보여줘.
- 그다음 형태별로 표준 JSON 구조 하나로 변환하는 코드를 짜줘.
- 값이 없거나 예상 밖 형태가 오면 조용히 넘어가지 말고, 에러를 명확히 던지게 해줘.

✅ 이렇게 되면 성공 — 어떤 입력이 와도 같은 모양으로 돌아옵니다.

⚠️ 막히면 — “이 케이스는 왜 표준 구조에 안 맞는지, 원본 값부터 보여줘”라고 되물어보세요.

3. 처음 한 번만 느리게 (받아둔 답 재활용)

프롬프트

이 API의 첫 호출이 수십 초씩 걸려. 같은 요청이 반복되면 캐시로 빠르게 응답하고,
처음 불러오는 동안엔 화면에 "불러오는 중" 상태를 명확히 보여주고 싶어.

- 캐시는 메모리든 파일이든 간단한 걸로 시작해줘. 유효기간(TTL)도 같이 정해줘.
- 캐시된 데이터가 오래됐을 때 사용자가 알아챌 방법도 같이 제안해줘.
- 첫 호출과 캐시 응답, 둘 다 걸리는 시간을 로그로 남겨줘.

✅ 이렇게 되면 성공 — 같은 요청은 두 번째부터 체감상 바로 응답합니다.

⚠️ 막히면 — “받아둔 답을 얼마나 오래 써도 되는지 판단 기준을 알려줘”라고 물어보세요. 데이터가 얼마나 자주 바뀌는지에 따라 답이 달라집니다.

아직 못 넘은 벽

이 구조로 로컬에서는 잘 돌아갑니다. 그런데 실제 서비스 환경에 올리려니 새로운 문제가 나왔어요.

이 창구를 제 사설망 안에서만 띄워뒀는데, 돈독이 배포된 환경에서는 이 사설망 주소로 들어오지 못합니다. 로컬에서는 완벽했던 연결이, 배포 환경에서는 애초에 시작조차 안 되는 거예요.

지금은 이 창구를 24시간 켜둔 서버 쪽으로 옮기고, 거기서 배포 환경이 접근할 수 있는 경로를 새로 뚫는 방법을 보고 있습니다. 아직 정리가 안 끝나서, 이번 글에서는 여기까지만 적어둡니다.

배운 것

두 프로젝트를 잇는 일은 코드를 합치는 게 아니라, 창구 하나를 명확히 정하는 일이었어요. 그 창구 안에서 모양을 통일하고, 느린 구간엔 받아둔 답을 재활용하고, 접근 범위는 좁게 잡는 것. 여기까지는 확실히 배웠습니다.

그리고 로컬에서 되는 것과 실제로 쓸 수 있는 것 사이엔 여전히 거리가 있다는 것도요. 이 벽을 넘는 이야기는, 넘고 나서 다음 빌드로그에서 이어가겠습니다.

오늘도 한 걸음. 🐴