본문 바로가기

전체 글

 (55)
독서를 하고 나서 말을 더 못해졌다. 누군가에게 들었다. 독서를 하면 생각이 정리되고, 그 덕에 말도 더 조리 있게 할 수 있게 된다고.그런데 나만 유별난 건지, 나는 독서를 하고 나면 말이 오히려 더 안 나온다. 막상 말을 하려 하면 머릿속에서 비슷한 의미의 단어들이 둥둥 떠다닌다. 이 상황에 딱 맞는 단어를 고르느라 시간을 허비하다가 결국 어버버하게 된다.가끔은 평소에 잘 쓰지 않던 어려운 단어가 떠오르기도 한다. 그런데 그걸 그대로 말하면 상대가 재수 없어 할까 봐, 더 쉬운 대체어를 찾다가 또 한 번 혀가 꼬인다.생각이 없는 것도 문제지만, 생각이 너무 많은 것도 문제다.Gemini에게 고민 상담을 해보니, 책을 통해 새로 들어온 단어들을 내 것으로 만드는 과정에서 생기는 시행착오일 거라고 했다.구글이 거짓말을 하진 않겠지. 한 번 ..
ETF 서비스 개발기 6: 태그와 검색, 캐시로 탐색 경험 다듬기 진격의 ETF - 입문자를 위한 ETF 가이드프로젝트 후반부에는 새로운 기능을 많이 추가하는 것보다, 이미 수집해둔 ETF 데이터를 더 잘 탐색할 수 있게 만드는 쪽에 집중하게 됐다. 데이터를 모으고 보여주는 것만으로는 서비스가 완성되지 않는다. 사용자가 관심 있는 기준으로 찾기 쉽고, 응답이 빠르고, 예외 케이스에서도 안정적으로 동작해야 비로소 서비스다운 완성도가 나온다.태그 기능이 필요했던 이유ETF는 이름만 봐도 어느 정도 테마를 짐작할 수 있지만, 실제로는 사용자가 관심 있는 주제 기준으로 묶어보는 기능이 있으면 탐색이 훨씬 쉬워진다. 예를 들어 반도체, 미국지수, 2차전지, AI, 배당, 채권처럼 사용자 관점의 분류가 있으면, 단순 종목 나열보다 훨씬 빠르게 원하는 ETF 군을 찾을 수 있다.그..
ETF 서비스 개발기 5: Docker, Nginx, GitHub Actions로 운영 환경 만들기 진격의 ETF - 입문자를 위한 ETF 가이드기능이 어느 정도 갖춰지고 나면 프로젝트의 관심사는 조금 달라진다. 로컬에서 잘 돌아가는 코드를 만드는 것보다, 실제 환경에서 반복 가능하게 배포하고 안정적으로 운영하는 일이 더 중요해진다. 이 프로젝트도 마찬가지였다. ETF 데이터를 수집하고 보여주는 흐름이 어느 정도 자리 잡은 뒤에는, 이제 이걸 어떻게 서비스처럼 운영할 것인지가 다음 문제였다.운영 관점에서 새로 보이기 시작한 문제로컬에서는 잘 돌아가지만 운영 환경에서는 그렇지 않은 문제가 많다.배포를 매번 수동으로 하면 실수가 쌓인다외부 공개를 하려면 HTTPS와 리버스 프록시가 필요하다장애가 나도 바로 감지하기 어렵다상태 확인이 안 되면 문제를 좁히기 어렵다결국 "기능 개발"과 "운영 가능한 서비스 만..
ETF 서비스 개발기 4: 리스트에서 탐색형 서비스로 확장하기 진격의 ETF - 입문자를 위한 ETF 가이드최근 ETF 목록만 보여주는 화면은 출발점으로는 괜찮았지만, 실제 서비스 관점에서는 금방 한계가 드러났다. 사용자는 단순히 "오늘 어떤 ETF가 있는가"만 궁금해하지 않는다. 특정 ETF의 흐름이 어떤지, 어떤 지수를 추종하는지, 최근에 어떤 맥락으로 움직였는지 같이 보고 싶어한다. 그래서 이 단계에서는 단순 리스트 조회를 넘어서, 종목을 더 깊게 볼 수 있는 탐색형 화면을 만드는 데 집중했다.상세 페이지가 필요했던 이유리스트는 비교에 적합하지만, 이해에는 한계가 있다. ETF는 이름과 등락률만으로는 충분하지 않다. 어떤 ETF인지 파악하려면 기본 정보와 최근 흐름이 함께 보여야 한다. 이 문제를 풀기 위해 상세 페이지 작업이 시작됐다.관련 커밋:2025-10..
ETF 서비스 개발기 3: 단순 API 조회에서 배치 수집 구조로 전환한 이유 진격의 ETF - 입문자를 위한 ETF 가이드초기에는 외부 API를 직접 호출해서 화면에 보여주는 구조만으로도 충분해 보였다. 실제로 기능 검증 단계에서는 그게 가장 빠른 방법이다. 하지만 조회 기능이 늘어나고, 과거 데이터 이력을 보고 싶어지고, 응답 속도를 안정적으로 유지하고 싶어지는 순간 구조적 한계가 분명해진다. 이 시점부터는 "보여주는 서비스"가 아니라 "수집하고 저장하는 서비스"로 바뀌어야 했다.이 글은 그 전환에 대한 이야기다. 단순 API 호출 프로젝트가 DB 적재와 스케줄러, Spring Batch를 갖춘 형태로 바뀌는 과정은 이 프로젝트 전체에서 가장 큰 구조 변화였다.왜 배치 구조가 필요했나외부 API 직접 조회 방식의 한계는 생각보다 빨리 드러났다.조회할 때마다 외부 API 상태에 ..
ETF 서비스 개발기 2: 공공데이터 API를 붙이며 만난 현실적인 문제들 진격의 ETF - 입문자를 위한 ETF 가이드프로젝트를 처음 시작할 때는 공공데이터 API만 연결하면 ETF 데이터를 쉽게 화면에 보여줄 수 있을 거라고 생각했다. 하지만 실제로는 데이터를 "받는 것"보다 "정상적으로 해석하고 원하는 형태로 가공하는 것"이 훨씬 까다로웠다. 특히 공공 API를 붙일 때 흔히 겪는 인코딩, URL 구성, 응답 형식 문제가 이 프로젝트에서도 그대로 나타났다.처음엔 단순히 API를 호출해 값을 출력하는 것만으로도 진도가 나가는 것처럼 보인다. 그런데 막상 화면에 붙이고, 검색을 넣고, 한글 이름으로 조회하기 시작하면 바로 문제가 드러난다. 이 단계는 프로젝트 초기에 생각했던 것보다 훨씬 중요했다. 이후에 DB 저장이나 배치 전환을 하게 되는 이유도 결국 여기서 드러났기 때문이..
ETF 서비스 개발기 1: 왜 이 프로젝트를 만들었나 진격의 ETF - 입문자를 위한 ETF 가이드ETF는 투자에 익숙하지 않은 사람도 비교적 쉽게 접근할 수 있는 상품이지만, 막상 데이터를 찾아보면 생각보다 흐름을 한눈에 보기 어렵다. 개별 ETF의 가격만 보는 것으로는 부족하고, 어떤 지수를 추종하는지, 최근 흐름이 어떤지, 비슷한 성격의 ETF를 함께 비교할 수 있는지가 중요하다. 이 프로젝트는 그런 불편함에서 시작했다. 단순히 ETF 데이터를 가져오는 데서 끝나는 것이 아니라, 직접 수집하고 저장하고 검색하는 서비스로 만들어보고 싶었다.처음부터 거대한 서비스를 만들 생각은 없었다. 오히려 반대로, 가능한 한 작은 단위부터 시작하는 쪽을 택했다. 공공데이터 API에서 ETF 데이터를 받아오고, 그 결과를 화면에 띄워보는 것. 이 최소 기능이 실제로 동..
면접 복기 제대로 답변 못한 내용을 까먹기 전에 바로 정리 들어간닷!!1. 왜 애플리케이션과 DB를 연결할 때 필요할 때마다 connection을 갖지 않고 connection pool을 쓰는지?- DB와 connection을 설정하는 것은 생각보다 많은 자원과 시간이 소요된다. 애플리케이션의 자원 효율성과 갑자기 몰리는 트래픽에 대비하기 위해 connection pool에서 이미 DB와 연결되어 있는 connection 중에 하나를 할당받아서 사용한다.차가 필요할 때 새 차를 주문해서 도착할 때까지 기다렸다가 사용하는 것과 쏘카를 이용하는 것의 차이라고 생각하면 쉽다.2. 로드밸런싱의 L4와 L7는 각각 어떤 경우에 사용하는가?- L4는 IP와 port를 기준으로 분리하기 때문에 대용량 트래픽 처리 등 빠른 분산..

티스토리툴바