insight00-15 님의 블로그

외부 API 연동 안정화 체크리스트 : Instagram API 사례로 정리

insight00-15 — Mon, 27 Apr 2026 23:34:37 +0900

최근에 Instagram API 연동을 필요로 하는 프로젝트를 진행하면서 Instagram API 연동 with Instagram Login 이라는 글을 썼다. 단순 구현을 하면서 점차 기술적으로 고민이 들었던 부분들을 리서치 하고 기록해보려고한다.

# Instagram API 연동, “기능 구현” 다음에 보이기 시작한 운영 관점의 고민들

처음에는 단순했다.

Instagram API를 붙이고, 필요한 데이터를 받아와서 DB에 저장하면 기능은 완성이라고 생각했다.

그런데 시간이 지나고 다시 코드를 보니, 이건 “동작하는 기능”일 뿐이지 아직 “안정적으로 운영할 수 있는 기능”은 아니었다.

외부 API를 호출하는 순간부터 내 애플리케이션은 더 이상 내부 로직만 신경 쓰면 되는 구조가 아니고, 지연, 실패, 중복 호출, 데이터 최신화 지연, DB 자원 점유, 관측 불가 같은 문제를 같이 안고 간다는 걸 뒤늦게 체감했다.

이번 글은 누군가를 가르치기 위한 정답 정리라기보다, 내가 Instagram API 연동을 운영 관점에서 다시 보면서 어떤 부분을 고민하게 되었는지 남겨두는 기록에 가깝다.

———

## 왜 이 고민을 하게 됐는가

지금 내 프로젝트는 Instagram API를 연동해서 데이터를 조회하고, 필요한 값은 DB에 저장하는 흐름까지는 구현된 상태다.

하지만 당시에는 MVP 기한이 정해져있었기에 기능 구현이 우선이었고, 외부 API 호출에서 흔히 필요한 안정화 요소들은 거의 고려하지 않았다.

예를 들면 이런 것들이다.

- 타임아웃

- 실패 분류

- 재시도 여부

- 멱등성

- DB 트랜잭션과 외부 호출 분리

- 로깅/모니터링

처음에는 이런 고민들이 MSA 환경에서나 필요한 얘기라고 막연하게 생각했는데, 자료를 찾아보면서 그건 아니라는 걸 알게 됐다.

MSA는 이런 문제가 더 자주, 더 크게 드러나는 환경일 뿐이고, 사실 모놀리식이어도 외부 API를 호출하는 순간부터는 이미 분산 시스템의 일부 문제를 안고 가게 된다.

즉, 내 프로젝트가 MSA가 아니더라도 외부 API를 호출하고 있다면, 안정적인 운영을 위해 위 항목들을 생각해야 하는 건 자연스러운거다.

———

## 1. Instagram 인사이트 데이터는 실시간이 아니다

가장 먼저 눈에 띈 건 인사이트 데이터의 최신화 시점이었다.

처음 메모할 때는 “Instagram 인사이트 지표는 최대 48시간이 걸린다”라고 적어뒀다.

이 표현은 방향은 맞지만, 조금 더 조심스럽게 쓰는 게 좋다. 현재 확인 가능한 자료들을 보면, Instagram 인사이트 데이터는 실시간이 아니며 일부 지표는 최대 48시간 정도 지연될 수 있다고 이해하는 게 더 적절하다.

이게 왜 중요하냐면, 같은 요청을 다시 보냈는데 데이터가 전과 똑같이 돌아왔다고 해서 곧바로 우리 시스템이 잘못됐다고 단정할 수 없기 때문이다. Instagram 쪽 집계 자체가 아직 갱신되지 않았을 가능성도 충분히 있다.

즉, 인사이트 데이터는 내부 DB 조회처럼 “지금 요청했으니 지금 시점의 최신 데이터가 오겠지”라고 생각하면 안 된다. 이 특성을 이해하지 못하면, 정상적인 지연을 장애처럼 오해하거나 반대로 실제 문제를 놓칠 수도 있다.

### 참고 링크

- Meta Docs: Instagram Media Insights Reference (https://developers.facebook.com/docs/instagram-platform/reference/instagram-media/insights

———

## 2. Instagram API는 호출량 제한도 고려해야 한다

Instagram API를 붙일 때 흔히 놓치기 쉬운 부분 중 하나가 호출량 제한이다. 처음에는 단순히 “요청만 보내면 응답을 주는 API”처럼 생각하기 쉽지만, Meta Graph API 계열은 호출량이 무한정 허용되는 구조가 아니다. 호출량이 많아지면 rate limiting이나 throttling이 걸릴 수 있고, 이 경우 일부 요청은 실패하거나 지연될 수 있다.

여기서 중요한 건 호출 제한이 단순히 “분당 몇 번”처럼 고정된 숫자 하나로 끝나지 않는다는 점이다. Meta 문서를 보면 제한은 앱 수준, 사용자/토큰 수준, 그리고 비즈니스 사용 방식에 따라 다르게 적용될 수 있다. 즉 개발자는 “우리 서비스는 하루에 이 정도만 호출하니까 괜찮겠지”라고 막연히 생각하기보다, 실제 운영 중에 어느 시점부터 usage가 높아지는지를 관측할 수 있어야 한다.

이게 왜 중요하냐면, 처음에는 트래픽이 적어서 문제가 없더라도 기능이 늘어나고 동기화 대상이 많아지면 같은 API를 호출하는 횟수가 빠르게 증가 할 수 있기 때문이다. 특히 인사이트 조회나 미디어 목록 조회처럼 여러 계정, 여러 콘텐츠를 순회하는 구조라면 요청 수가 생각보다 쉽게 커진다. 이런 구조에서 호출량 제한을 고려하지 않으면, 운영 중 특정 시점에 갑자기 일부 요청이 막히거나 응답이 불안정해질 수 있다.

즉 Instagram API 연동은 “응답이 오는가”만 볼 게 아니라, “얼마나 자주 호출하고 있고, 그 호출량이 제한에 가까워지고 있는가”도 같이 봐야 한다. 이 특성을 이해하지 못하면, 평소에는 잘 동작하다가 트래픽이 몰리거나 수집 범위가 커졌을 때 예상하지 못한 장애를 맞을 수 있다.

### 참고 링크

- Meta Docs: Graph API Rate Limiting (https://developers.facebook.com/docs/graph-api/overview/rate-limiting#platform-rate-limits)

———

## 3. 외부 API는 성공/실패 두 가지로만 나눌 수 없다

외부 API 연동을 다시 보면서 가장 크게 느낀 건, 네트워크 요청은 생각보다 애매한 상황이 많다는 점이었다.

예를 들어 timeout이 발생했다고 하자.

이때 가능한 경우는 여러 가지다.

- 요청이 Instagram 서버에 아예 도달하지 않았을 수도 있다.

- 요청은 도달했지만 처리 중이었을 수도 있다.

- 이미 처리는 끝났는데 응답만 받지 못했을 수도 있다.

이런 상황을 그냥 전부 “실패”라고 처리해버리면, 실제로는 이미 처리된 요청을 또 보내게 되거나, 중복 저장 같은 문제로 이어질 수 있다.

그래서 외부 API를 다룰 때는 단순히 성공/실패만 보는 게 아니라, 경우에 따라서는 알 수 없음(unknown) 상태까지 생각해야 한다는 점이 인상적이었다.

이 관점은 카카오페이 글을 보면서 더 명확해졌다.

결제 같은 민감한 도메인은 더 극단적이지만, 핵심은 똑같다. 외부 시스템과 통신할 때는 “응답이 안 왔다 = 처리 안 됐다”로 단정하면 안 된다.

다만 내 프로젝트는 결제처럼 외부 시스템의 상태를 직접 바꾸는 요청이 아니라, 아직은 조회 API 중심의 구조다.

그래서 취소 API나 보상 트랜잭션까지 당장 필요한 상황은 아니지만, 그래도 실패 분류 자체는 반드시 필요하다고 느꼈다.

### 참고 링크

- 카카오페이: MSA 환경에서 네트워크 예외를 잘 다루는 방법 (https://tech.kakaopay.com/post/msa-transaction/)

- AWS Builders’ Library: Timeouts, retries, and backoff with jitter (https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)

———

## 4. 느린 외부 API는 결국 우리 서비스 전체를 느리게 만든다

Instagram 서버가 완전히 죽는 경우만 문제가 되는 건 아니다.

오히려 실무에서는 “죽지는 않았는데 엄청 느린 상태”가 더 골치 아플 수도 있다.

이럴 때 타임아웃이 없으면, 우리 서버는 외부 API 응답을 하염없이 기다리게 된다.

요청 처리 스레드는 계속 묶이고, 응답 시간은 길어지고, 같은 요청이 쌓이면 전체 서비스가 느려질 수 있다.

게다가 그 호출 구간 안에 DB 트랜잭션까지 같이 들어 있으면 문제가 더 커진다.

외부 API가 느린 동안 DB 커넥션까지 계속 잡고 있게 되고, 요청이 많아지면 커넥션 풀 고갈 같은 2차 장애로 번질 수 있다.

그래서 타임아웃은 단순히 “조금 기다리다 포기하는 옵션”이 아니라, 외부 시스템 지연이 우리 시스템 전체 자원 고갈로 전파되지 않게 막는 보호 장치에 가깝다.

### 참고 링크

- AWS Builders’ Library: Timeouts, retries, and backoff with jitter (https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)

———

## 5. 재시도는 무조건 넣는다고 좋은 게 아니다

처음에는 외부 API가 실패하면 “그냥 한 번 더 호출하면 되지 않을까?”라고 생각하기 쉽다.

그런데 자료를 보다 보니, 재시도는 생각보다 훨씬 조심스럽게 다뤄야 하는 영역이었다.

재시도는 일시적인 네트워크 오류나 순간적인 장애에는 도움이 될 수 있다.

하지만 모든 예외에 무조건 재시도를 걸어버리면 오히려 장애 상황에서 요청을 더 몰아넣는 형태가 된다.

이른바 retry storm 같은 안티패턴이다.

예를 들어 Instagram 서버가 이미 느리거나 불안정한 상태인데, 우리 서버가 같은 요청을 여러 번 다시 보내기 시작하면 상대 서버도 더 힘들어지고, 우리 쪽 스레드와 응답 시간도 더 악화될 수 있다.

그래서 재시도는 “실패하면 다시”가 아니라, “어떤 실패에 한해, 몇 번까지, 어떤 간격으로 다시 시도할 것인가”를 정해서 써야 한다.

### 참고 링크

- Azure Architecture: Retry Storm antipattern (https://learn.microsoft.com/ko-kr/azure/architecture/antipatterns/retry-storm/)

———

## 6. 멱등성은 “조회”보다 “저장/동기화”에서 더 중요하다

내가 처음 메모할 때는 “인사이트 지표는 언제 최신화될지 모르니까, 계속 받아와도 이게 맞는 최신 데이터인지 모른다. 그러면 멱등성을 어떻게 유지해야 하지?”라고 적어뒀다.

이 고민의 방향은 맞았지만, 표현은 조금 더 정확히 다듬는 게 좋겠다고 느꼈다.

멱등성은 보통 조회 요청 자체보다, 그 조회 결과를 저장하고 동기화하는 작업 쪽에서 더 중요하다.

즉, 중요한 질문은 이런 쪽이다.

- 같은 인사이트 데이터를 여러 번 받아와도 DB 상태가 꼬이지 않는가

- 같은 동기화 작업이 중복 실행돼도 최종 결과가 동일한가

- 사용자가 버튼을 여러 번 누르거나 배치가 중복 실행돼도 중복 저장이 발생하지 않는가

인사이트 데이터처럼 최신화 시점이 불명확한 경우에는, 같은 데이터가 반복해서 들어오는 것이 정상일 수도 있다.

그래서 이럴수록 “같은 요청이 여러 번 왔다” 자체보다 “그 결과를 저장하는 로직이 중복에 안전한가”를 보는 게 더 중요하다.

그리고 이 지점에서 로깅/모니터링과도 연결된다.

똑같은 데이터가 들어왔을 때, 그게 Instagram 집계 지연 때문인지, 우리 동기화 로직의 중복 실행 때문인지 구분하려면 호출 이력과 저장 이력이 보여야 하기 때문이다.

### 참고 링크

- 카카오페이: MSA 환경에서 네트워크 예외를 잘 다루는 방법 (https://tech.kakaopay.com/post/msa-transaction/)

———

## 7. DB 트랜잭션과 외부 API 호출은 분리하는 편이 안전하다

이번에 찾아본 내용 중 가장 실무적으로 바로 와닿았던 건, 외부 API 호출과 DB 트랜잭션을 가능한 한 분리하라는 이야기였다.

처음에는 “어차피 외부 응답을 보고 DB 처리할 건데, 결국 연결된 거 아닌가?” 싶었는데, 핵심은 외부 API 결과를 참고하느냐가 아니라, DB 트랜잭션을 언제 시작하느냐였다.

예를 들어 이런 구조가 있다고 하자.

- 외부 API 호출

- 응답 대기

- 응답 결과를 바탕으로 DB 조회/저장

이 흐름 자체는 자연스럽다.

문제는 이 전체가 하나의 @Transactional 메서드 안에 들어 있을 때다.

그렇게 되면 메서드 진입 순간 트랜잭션이 열리고, 외부 API가 3초 걸리면 그 3초 동안 DB 트랜잭션도 살아 있을 수 있다.

결과적으로 DB 커넥션이 불필요하게 오래 점유되고, 트래픽이 커지면 커넥션 풀 고갈 위험이 생긴다.

그래서 더 안전한 구조는:

- 외부 API 호출은 트랜잭션 없이 먼저 수행하고

- 그 응답 결과를 받은 뒤에

- 필요한 DB 작업만 짧게 트랜잭션으로 묶는 방식이다

이렇게 하면 외부 시스템의 지연이 DB 자원 점유로 전파되는 걸 줄일 수 있다.

### 참고 링크

- 카카오페이: 주니어 서버 개발자가 유저향 서비스를 개발하며 마주쳤던 이슈와 해결 방안 (https://tech.kakaopay.com/post/troubleshooting-logs-as-a-junior-developer/)

———

## 8. 로깅과 모니터링은 “문제를 고치는 장치”가 아니라 “문제를 보이게 하는 장치”다

처음에는 타임아웃, 재시도, 트랜잭션 분리 같은 기술적인 해결책에 더 눈이 갔다.

그런데 정작 운영 관점에서 더 중요한 건, 지금 어떤 문제가 발생하고 있는지 관측할 수 있느냐였다.

외부 API 연동은 문제가 생겨도 원인이 바로 드러나지 않는다.

- 우리 서버 문제인지

- Instagram API 문제인지

- 단순 지연인지

- 같은 데이터가 반복해서 들어오는 이유가 최신화 지연인지, 저장 로직 문제인지

이런 걸 구분하려면 결국 로그와 메트릭, 그리고 필요하다면 헬스 체크 지표가 있어야 한다.

특히 인사이트 데이터처럼 “정상인데 늦을 수 있는” 연동은 더 그렇다.

데이터가 갱신되지 않았다는 사실 자체가 장애는 아닐 수 있으므로, 호출 시각, 응답 시간, 상태 코드, 예외 유형, 저장된 데이터의 기준 시각같은 정보가 함께 보여야 원인을 해석할 수 있다.

즉 단순히 “성공했는가 / 실패했는가”만 보는 것이 아니라, 외부 의존성이 지금 얼마나 느린지, 실패율이 높아지고 있는지, 우리 애플리케이션이 그 영향을 받고 있는지까지 볼 수 있어야 한다.

이 부분은 Health Endpoint Monitoring pattern을 보면서 더 정리가 됐다.

운영에서는 단순히 애플리케이션이 살아 있는지만 보는 게 아니라, 그 애플리케이션이 의존하고 있는 구성요소들까지 함께 봐야 한다. 내 프로젝트로 치면, 서버 프로세스가 살아 있는 것만으로는 충분하지 않고, Instagram API 호출이 정상적으로 이뤄지는지, 외부 API 응답 시간이 급격히 느려지지는 않았는지, 실패가 특정 구간에서 몰리고 있지는 않은지까지 같이 봐야 의미가 있다.

그래서 로깅/모니터링은 장애를 직접 막아주는 기능이라기보다, 문제를 더 빨리 발견하고, 원인을 좁히고, 대응할 수 있게 해주는 기반이라고 이해하게 됐다.

결국 외부 API 연동에서 중요한 건 “장애가 났을 때 고치는 능력”만이 아니라, 장애 징후를 먼저 볼 수 있는 능력이라는 생각이 들었다.

### 참고 링크

- Azure Architecture: Health Endpoint Monitoring pattern

(https://learn.microsoft.com/en-us/azure/architecture/patterns/health-endpoint-monitoring)

———

## 지금 시점에서 내가 우선적으로 점검할 항목

모든 안정화 패턴을 한 번에 다 넣는 건 현실적이지 않다. 프로젝트를 진행하면서, 이제 2차 MVP에 들어갈 기능들도 구현해야돼서 시간도 없을테고 구현 난이도가 있을거같아 조사하면서도 어떻게, 어디서부터 해야될지 막막했다.

결론은, 2차 MVP 기능 구현을 우선으로 하면서 안정화 작업을 후순위로 조금씩 해나가면 좋을거같다.

안정화 작업에 들어가게된다면, 지금 내 프로젝트 상황에서는 아래 다섯 가지를 먼저 정리하는 게 맞다고 보고 있다.

- 타임아웃

- 외부 API 지연이 전체 서비스 자원 고갈로 이어지지 않게 하기 위해

- 실패 분류

- 일시적 실패와 영구 실패를 구분하기 위해

- 재시도 여부

- 무조건 재시도하지 않고, 특정 조건에만 제한적으로 적용하기 위해

- DB 트랜잭션과 외부 호출 분리

- 외부 응답 대기 시간이 DB 커넥션 점유 시간까지 길어지지 않게 하기 위해

- 로깅/모니터링

- 문제를 빨리 감지하고 원인을 좁히고 정책의 효과를 검증하기 위해

반대로, 벌크헤드, 서킷 브레이커, 이중화 같은 항목은 지금 당장 필수라기보다, 트래픽 규모와 장애 영향도를 보면서 다음 단계에서 검토할 수 있는 주제라고 생각한다.

———

이번에 정리하면서 느낀 건, 외부 API 연동은 “호출해서 값 받아오기”에서 끝나는 문제가 아니라는 점이었다. 오히려 그 다음부터가 진짜 시작이었다.

Instagram API를 붙여서 기능이 돌아가는 것과, 장애와 지연을 견디면서 안정적으로 운영할 수 있는 것은 완전히 다른 문제였다.

지금 내 프로젝트는 아직 후자 쪽으로 가는 과정에 있고, 이 글은 그 과정에서 내가 어떤 포인트를 먼저 봐야 하는지 정리한 기록이다.

Instagram API 연동 with Instagram Login

insight00-15 — Mon, 20 Apr 2026 21:30:06 +0900

Spring Boot에서 Instagram OAuth 연동하고 게시물 인사이트 조회하기

https://developers.facebook.com/docs/instagram-platform?locale=ko_KR

Instagram 플랫폼 - 문서 - Meta for Developers

Instagram Platform The Instagram Platform from Meta provides tools to help your app user's interact with Instagram users. Instagram API with Business Login for Instagram The Instagram API with Instagram Login allows users of your app to access data in thei

developers.facebook.com

이번 프로젝트에서는 뮤지션이 음악 홍보 페이지를 만들고, Instagram 게시물을 통해 발생한 성과를 확인하는 기능을 구현하고 있다.

이번 작업의 목표는 다음이었다.

Instagram OAuth로 뮤지션 가입/로그인

-> long-lived access token 저장

-> Instagram 게시물 목록 조회

-> 게시물별 공유수, 프로필 방문수 조회

———

1. 왜 Instagram OAuth를 로그인으로 사용했나

처음에는 일반 회원가입 후 Instagram을 연동하는 방식을 생각했다.

이메일 회원가입

-> 로그인

-> Instagram 연동

하지만 현재 MVP의 핵심 사용자는 뮤지션이고, 뮤지션은 Instagram 계정이 있어야 서비스를 제대로 사용할 수 있다. 그래서 별도 회원가입을 먼저 만들기보다, Instagram OAuth 자체를 가입/로그인 수단으로 사용했다.

최종 흐름은 이렇게 잡았다.

Instagram OAuth 성공

-> Instagram 계정 정보 조회

-> DB에 해당 Instagram 계정이 없으면 Musician으로 저장

-> OAuth에서 발급받은 long-lived access token 등 인스타와 연동할때 필요한 정보들 DB에 instagram_connection으로 저장

-> 이미 있으면 기존 Musician 재사용 + token 갱신

———

2. 초기 Instagram OAuth redirect uri 세팅

개발 환경에서는 ngrok을 사용했다.

ngrok은 로컬에서 실행 중인 서버를 외부에서 접근 가능한 HTTPS 주소로 노출해주는 터널링 도구다.
로컬 서버 주소인 localhost:8080만으로는 Instagram OAuth redirect 테스트가 불안정했고, http로는 redirect URI를 등록이 되지않는 문제가 있어서 ngrok을 사용하였다.

Spring Boot: http://localhost:8080

ngrok: https://xxxx.ngrok-free.dev -> http://localhost:8080

Meta Developer App에는 아래 redirect URI를 등록했다.

https://xxxx.ngrok-free.dev/instagram/oauth/callback

Meta Developer App에서 redirect URI를 등록하면 제공해주는 OAuth 로그인 URL 링크를 타고 들어가서 인스타로 연동을 해주면, https://xxxx.ngrok...callback 링크로 redirect를 한 뒤 acceses token을 발급받는데 중요한 code 번호를 보내준다.

내가 사용한 OAuth 로그인 URL은 다음 형태다.

https://www.instagram.com/oauth/authorize

?force_reauth=true

&client_id={CLIENT_ID}

&redirect_uri={REDIRECT_URI}

&response_type=code

&scope=instagram_business_basic%2Cinstagram_business_manage_insights

이번 기능에 필요한 scope는 두 개만 사용했다.

instagram_business_basic

instagram_business_manage_insights

———

3. 구현한 API

3.1 Instagram OAuth Callback

GET /instagram/oauth/callback?code=...

역할:

Instagram에서 받은 authorization code 처리

short-lived token 발급

long-lived token으로 교환

Instagram /me 조회

뮤지션 자동 생성 또는 기존 연결 갱신

성공 응답:

{

"success": true,

"data": {

"musicianId": 1,

"instagramAccountId": "17841464237580902",

"instagramUsername": "robbi_developer"

"message": "Instagram 로그인이 완료되었습니다."

}

테스트 결과 첫 로그인 시에는 musician과 instagram_connection이 생성되었고, 같은 계정으로 다시 로그인하면 row가 새로 생기지 않고 token 관련 값만 갱신되었다.

———

3.2 Instagram 게시물 + 인사이트 조회

GET /api/musicians/me/instagram/media

현재는 인증 기능이 없기 때문에 임시로 헤더를 사용했다.

X-Musician-Id: 1

역할:

저장된 Instagram access token 조회

Instagram /me/media 호출

각 게시물별 shares, profile_visits 조회

프론트에 게시물 목록과 지표 반환

테스트 curl:

curl -s "http://localhost:8080/api/musicians/me/instagram/media" \

-H "X-Musician-Id: 1" \

| python -m json.tool

응답 예시:

{

"success": true,

"data": [

{

"mediaId": "18198936793355701",

"mediaType": "IMAGE",

"permalink": "https://www.instagram.com/p/DXT5H-MEcv6/",

"timestamp": "2026-04-19T11:02:07+0000",

"shareCount": 1,

"profileVisitCount": 7

}

"message": "Instagram 게시물을 조회했습니다."

}

mediaUrl 같은 긴 필드는 실제 응답에는 포함되지만, 블로그에서는 생략했다.

———

4. DB 구조

이번 작업에서 핵심이 되는 테이블은 instagram_connection이다.

역할은 다음과 같다.

우리 서비스의 Musician

<-> Instagram 계정

<-> Instagram long-lived access token

주요 컬럼:

musician_id

instagram_account_id

instagram_username

access_token

token_expires_at

connected_at

updated_at

현재는 access token을 평문으로 저장했다.

개발 단계에서는 빠르게 검증하기 위해 이렇게 했지만, 운영 전에는 반드시 암호화 저장이 필요하다.

비밀번호: 해시 저장

access token: 복호화 가능한 암호화 저장

———

5. 구현 중 겪은 문제

5.1 redirect URI 문제

로컬 localhost만으로는 Instagram OAuth redirect 테스트가 번거로웠다.

그래서 ngrok을 사용해서 HTTPS 주소를 만들고, 그 주소를 Meta App의 redirect URI로 등록했다.

https://xxxx.ngrok-free.dev/instagram/oauth/callback

이렇게 하니 Instagram OAuth redirect를 안정적으로 테스트할 수 있었다.

———

5.2 permissions 파싱 문제

Instagram token API 응답의 permissions를 처음에는 문자열로 생각했다.

하지만 실제 응답은 배열이었다.

"permissions": [

"instagram_business_basic",

"instagram_business_manage_insights"

]

그래서 DTO에서는 List<String>으로 받도록 수정했다.

———

5.3 같은 계정 재로그인 처리

OAuth는 여러 번 로그인할 수 있기 때문에, 같은 Instagram 계정으로 다시 로그인했을 때 row가 중복 생성되면 안 된다.

그래서 instagram_account_id를 unique 기준으로 사용했다.

첫 로그인: Musician + InstagramConnection 생성

재로그인: 기존 InstagramConnection token 갱신

———

6. 테스트 순서

6.1 ngrok 실행

ngrok http 8080

6.2 Spring Boot 실행

필요한 환경변수:

DB_URL=...

DB_USERNAME=...

DB_PASSWORD=...

INSTAGRAM_CLIENT_ID=...

INSTAGRAM_CLIENT_SECRET=...

INSTAGRAM_REDIRECT_URI=https://xxxx.ngrok-free.dev/instagram/oauth/callback

6.3 Instagram OAuth 로그인

open

"https://www.instagram.com/oauth/authorize?force_reauth=true&client_id={CLIENT_ID}&redirect_uri=https://xxxx.ngrok-free.dev/instagram/oauth/callback&response_type=code&scope=instagram_business_basic%2Cinstagram_business_manage_insights"

6.4 DB 확인

SELECT * FROM musician;

SELECT

instagram_connection_id,

musician_id,

instagram_account_id,

instagram_username,

token_expires_at,

connected_at,

updated_at

FROM instagram_connection;

6.5 게시물 조회 확인

curl -s "http://localhost:8080/api/musicians/me/instagram/media" \

-H "X-Musician-Id: 1" \

| python -m json.tool

———

7. 현재 한계

현재는 아직 JWT/세션 인증이 없다.

그래서 임시로 X-Musician-Id 헤더를 사용하고 있다.

X-Musician-Id: 1

운영에서는 이 방식은 사용할 수 없다. 사용자가 다른 뮤지션 ID를 임의로 넣을 수 있기 때문이다.

나중에는 JWT에서 musicianId를 꺼내는 방식으로 바꿔야 한다.

또한 long-lived token은 약 60일 동안 유효하므로, 운영에서는 만료 전에 refresh하는 배치가 필요하다.

———

8. 다음 작업

다음으로 구현할 API는 다음이다.

PATCH /api/music-promotions/{promotionId}/instagram-media

이 API는 우리 서비스의 음악 홍보 객체와 Instagram 게시물을 연결한다.

필요한 이유는 다음과 같다.

music_promotion은 우리 DB에 있음

Instagram media는 Instagram API에서 조회됨

하지만 어떤 게시물이 어떤 홍보와 연결된 것인지는 백엔드가 자동으로 알 수 없음

그래서 뮤지션이 게시물 목록에서 하나를 선택하면, 해당 게시물의 mediaId를 music_promotion과 연결해야 한다.

이후에는 다음 흐름이 가능해진다.

promotionId

-> 연결된 instagramMediaId 조회

-> 해당 media의 shares/profile_visits 조회

-> promotion_tracking_click에서 클릭수 조회

-> 화면에서 홍보 성과 요약 표시

[개발 도서] 개발자는 글을 못 쓴다고요? - 커밋 메시지 작성하기

insight00-15 — Sun, 19 Apr 2026 12:34:07 +0900

https://product.kyobobook.co.kr/detail/S000218400404

개발자는 글을 못 쓴다고요? | 전정은 - 교보문고

개발자는 글을 못 쓴다고요? | 문서는 실력이고, 글은 또 하나의 코드입니다개발자는 오늘도 글을 씁니다. 커밋 메시지부터 리드미, 릴리스 노트, 기술 블로그까지 일의 많은 순간에 글이 필요합

product.kyobobook.co.kr

p.12

- 훌륭한 개발자가 되려면 뛰어난 소프트웨어 개발 능력뿐만 아니라 원활한 소통 능력도 필요합니다.

p.29

- 글 잘 쓰는 개발자가 되려면 쓰지 않는 습관과 코드로 소통한다는 생각의 굴레에서 벗어나야 합니다.

- 우선 단번에 좋은 글을 써내겠다는 희망을 버리세요. 그런 생각을 하면 오히려 글쓰기가 힘들고 어렵게 느껴져 시작하기 힘듭니다.

p.44

- 내가 커밋한 코드를 왜 커밋했는지, 왜 그렇게 구현했는지 시간이 어느 정도 지나면 나도, 또 내 코드를 보는 이도 알 수 없습니다. 기록이 없다면 말입니다. 시간이 지난 후에도 기록이 유의미하도록 기록을 잘 쓰고 잘 남겨야 합니다.

- 기록을 잘 찾을 수도 있어야 합니다.

- 커밋 메시지를 작성할때는 검색도 고려해야 합니다.

p.46

- 커밋 메시지 제목(이하 제목)이 너무 길다면 그 커밋에는 너무 많은 걸 담았다 생각하고 커밋을 분리해야 합니다.

- 한 커밋에 담기는 파일들은 전부 동일한 목적을 달성하는 변경 사항을 담은 파일들이어야 합니다.

- 커밋 범위를 잘 구성하면 제목을 수월하게 쓸 수 있는것은 물론, 혹여나 롤백rollback해야 할 상황이 발생했을 때 도움이 됩니다.

- 깃헙에서 제목과 본문을 구분해 표시하는 커밋 방법은 있습니다. (첫 줄 입력 후 따옴표를 닫지 않고 엔터를 치면 줄바꿈이 됩니다.)

git commit -m "feat: 메인 페이지 UI 개선 --> <제목>
<본문 내용>
- 헤더 디자인 수정
- 푸터 링크 추가"

p.49

- 리뷰어 입장에서 개발자가 무엇을 달성하려고 코드를 작성했는지 알고 리뷰하는것과 전혀 모른 채 리뷰하는 것은 다르지 않을까요? 목적을 확실하게 알면 커밋된 코드가 실제로 그 목적을 달성하는지 여부를 판단하는 데 도움을 얻을 수도 있습니다.

p.50

- 많은 오픈소스 저장소에는 CONTRIBUTING.md 파일이 있습니다. 파일을 보면 지켜야 할 코딩 스타일과 더불어 커밋이나 풀 리퀘스트를 올리는 방법 등을 안내합니다.

- 커밋 메시지 제목이나 풀 리퀘스트 제목을 영어로 쓸 때는 동상 명령형으로 시작하는 것을 추천합니다.

- '하다'라는 동작을 '해라', '하게' 등의 형태로 표현하는 것이 동사 명령형입니다.

(예시. 커밋메세지: added an object(x), add an object(0))

p.54

- 커밋 메세지의 목적어를 꾸미는 다양한 방식

공식 1: 해라 (어떤) 무엇을
제목  : Add (absent) students

공식 2: 해라 무엇을 (어떤)
제목  : Add students (who are not listed in the roll)

- 커밋 메세지의 언제라는 정보를 추가할 수 있는 방식

공식 1: 2주마다 학생을 출석 시스템에 등록하는 코드 커밋
제목  : Add students to the attendance system every two weeks

공식 2: 출석 시스템이 준비 상태가 되면 학생을 추가하는 코드 커밋
제목  : Add students when the attendance system is ready

p.56

- 제목에 쓸 만한 동사

기능 분류: 동사
----------------------------------------------------------------------------------
추가    : add, create, generate, include, introduce, issue, post, put, save, store
----------------------------------------------------------------------------------
변경    : bump,change,configure,edit,fix,modify,rename,replace,set,update,upgrade
----------------------------------------------------------------------------------
삭제    : cancel, delete, eject, eliminate, erase, exclude, hide, remove, reset
----------------------------------------------------------------------------------
그 외   : alert,align,allocate,allow,alternate,delimit,display,divide,draw,enable,
		 enter,fix,follow,free,get,handle,initialize,improve,notify,order,process,
         provide,read,refactor,retrieve,return,rewrite,search,separate,show,sum,stop
         strip,support,terminate,use,watch,wait,write
----------------------------------------------------------------------------------

p.57

- 커밋한 후 수개월 혹은 수년이 지난 후에도 이 커밋이 무엇을 위해 커밋된 것인지 바로 파악할 수 있도록 상세하게 작성하세요.

- 내가 어떤 코드를 추가했고 바꿨는지는 git diff로, 코드 변경 전후를 비교하면 바로 알 수 있습니다.

- 커밋에 담긴 코드를 언급하는 대신 코드가 수행하는. 기능 관점이나 내가 한 작업을 설명하는 제목을 작성하세요.

* 내가 추가한 코드가 하는일. (ex. "Find students by name" )

* 내가 추가한 코드 때문에 뭘 할 수 있게 됐는가? (ex. "Enable finding students by name")

* 이전에는 이름으로 학생을 찾을 수 없었는데 내가 올린 커밋이 병합되면 가능해진다는 것을 알림.

* 내가 코드를 추가해서 전과 뭐가 달라졌는가? (ex. "Add the name filter for searching students")

* 학생을 조회하는 기능은 이미 있었으나, 기존 기능에 부가 기능을 추가한 것을 알림.

p.62

- 커밋 제목을 줄이려고 아무리 노력해도 짧아지지 않을 때는 유의어를 써보세요. (https://www.thesaurus.com)

p.64

- 단어 풀 만들기. 우리 팀에서는 '변경'이란 의미를 표현할 때 'edit'나 'modify'가 아닌 'change'를 쓴다고 명시해두는 거죠.

p.64~67

커밋 메세지 본문 쓰기

- 커밋한 이유를 알려주세요

* 커밋한 이유, 커밋하게 된 계기를 적어야 합니다.

- 외부 자원을 명시해주세요

* 새롭게 이용하게 된 외부 라이브러리나 패키지가 있다면 기재해주세요.

- 선택한 이유를 알려주세요

* 커밋에 반영된 선택을 한 이유를 본문에 남겨주세요.

* 코드 리뷰어도 왜 이렇게 하지 않았냐고 질문하지 않을 수 있습니다.나중에 관련 작업을 할 때도 유용한 정보가 됩니다.

- 관련 자료를 첨부해주세요

* 커밋 메시지에도 정보 자체를 상세히 남기길 권합니다. 자료에 있는 글을 '복붙'을 하더라도요.

Github Actions로 개선하는 코드 리뷰 문화

insight00-15 — Thu, 16 Apr 2026 20:29:48 +0900

https://toss.tech/article/25431 Github Actions로 개선하는 코드 리뷰 문화

김성일, 토스페이먼츠 Server Developer

코드 리뷰 문화의 가장 중요한 조건
- 피드백의 속도
- PR 코멘트로 이루어지는 대화의 양
Github Actions
- GitHub에서 제공해주는 자동화 툴
- 특정 이벤트를 기반으로 워크플로우를 실행
Github Actions의 장점
- 기능 구현과 유지보수가 간편
- 사용자가 많아서 접근성이 좋음
GitHub Actions 커스텀
- https://github.com/actions/toolkit에서 GitHub이 제공한 SDK를 통해 JavaScript / TypeScript로 actions 커스텀 가능

토스페이먼츠에서 적용한 GitHub Actions

리뷰어 지정하기
- 토스페이먼츠에서는 이 GitHub Actions를 사용해 랜덤으로 PR 리뷰어를 지정해주는 자동화 시스템을 구축했다.
  - 결과: 한두 명만이 알고있었던 맥락(코드)들도 팀 내 여럿에게 공유되어 운영 이슈 대응 시간 90% 단축.
리뷰어에게 알림 보내기
- 슬랙봇을 사용해, PR 리뷰어로 선정되었을때 슬랙 알림이 갈 수 있도록 설정. 이메일로 알림을 보냈을때는 메일을 자주 확인하지 않는 사람들이 알아차리기 어려운 이슈가 있었음.
오늘 안에 리뷰할 수 있게 하기
- GitHub Actions에는 cron표현식을 사용해 워크플로우 스케줄링 할 수 있는 이벤트 기능이 있다.
- 토스페이먼츠에서 적용한 워크플로우
  - 월-금 오후 2시마다 레포지토리에 Open 상태로 되어있는 PR 리뷰 상태 체크
  - 리뷰 되어있지않은 PR들을 모아 팀 슬랙 채널로 전송

[개발] "백엔드 개발자" 오픈형 멘토링: 백엔드 - 손권남 멘토

insight00-15 — Tue, 14 Apr 2026 21:44:49 +0900

백엔드 개발자- 손권남, 우아한형제들 기술이사. https://2024.woowacon.com/sessions/737/

개발을 잘하는것보단 그냥 일 잘하는 사람
경청이 중요
회의에서 똑같은 말을 하는 사람들이있음
- 같은 말인데 서로 다른 의미로 이해하고 소통하기때문
- 같은 용어를 쓰는게 중요(해당 업계에서 쓰는 단어나 뜻, 의미 등을 잘 알고 쓰면 좋을듯)
- 경청이 중요한 이유가 여기. 저 사람이 무슨 말을 하고 있는건지 경청
서버, 데이터베이스, 기본을 잘 알고 다뤄야한다. 도메인 경험 중요.
기획자의 기획서를 완벽하지 않다고 비판하기전에 알아서 잘 파악하고, 무결하지가 않다는것을 인정하고, 기획자의 언어, 의도를 잘 파악해서 하면 됨. 모든것은 완벽하지않는다.
KPT(Keep-유지, Problem-문제, Try-시도), 개발자 성장 치트키.
- **Keep (유지할 것):** 현재 만족하고 있는 부분, 계속 이어갔으면 하는 잘한 점.
- **Problem (문제점):** 프로젝트 과정 중 겪은 어려움, 아쉬웠던 점, 개선이 필요한 부분.
- **Try (시도할 것):** Problem에 대한 해결책이나 앞으로 시도해보고 싶은 구체적인 아이디어.
없는문제를 억지를 만들지말고, 실제로 있는 문제를 잘 해결해라.
어려운 과제가 나올때, 해내야겠다, 어렵겠지만 해봐야겠다 이런 태도를 가지는게 중요
- 안 풀어본 문제도 도전해낼 실력이 뒷받침이 되어야한다.
기술을 잘하면서도, 사람들 관리를 잘 하는 사람은 많지않다.
현업에서는, strategy pattern, 일종의 템플릿 콜백 패턴을 흔하게 사용. kiss(Keep It Simple, Stupid) pattern.
서비스를 만들때는, 어떠한 디자인 패턴을 쓰고싶어, 어떤 기술을 쓰고싶어, 이러한 이유들 때문에 필요없는 코드들을 만들지마라.
sql 안티패턴 책을 보면 데이터설계때 좋은 책임.
개발자 머피의법칙 블로그 글을 쓰심.
실시간 데이터 처리하는데 흔하게 쓰이는 기술 → cache + non-blocking i/o 아니면 그냥 비동기 처리

k6, Prometheus, Grafana를 사용한 부하 테스트 환경 구성하기(with Docker-compose)

insight00-15 — Fri, 3 Apr 2026 14:22:22 +0900

부하 테스트는 시스템에 예상되는 최대 사용자수나 데이터 처리량을 시물레이션하여, 시스템의 응답 시간, 처리 속도(TPS), 안정성 등을 측정하고 병목 현상을 파악하는 성능 테스트이다.

▶ 부하 테스트 툴

K6: API에 가상 사용자를 만들어 부하를 주고 성능과 안정성을 검증하는 부하 테스트 도구
Prometheus: 애플리케이션과 인프라의 메트릭을 주기적으로 수집하고 저장하는 모니터링 시스템
Grafana: Prometheus 같은 데이터소스의 메트릭을 그래프와 대시보드로 시각화하는 도구
Spring API + Actuator: Spring Boot 앱 상태, 메트릭 상태 지표 제공(JVM, CPU, HTTP 요청 수 메모리 등)
Micrometer: Spring Boot 앱 메트릭을 수집하고 Prometheus 같은 모니터링 시스템과 연결해주는 계측 라이브러리
docker-compose: 여러 컨테이너 서비스를 한 번에 실행할 수 있게 해주는 도구

▶ 테스트 환경 폴더 경로 설계

일단 이런식으로 나중에 쓸 docker-compose.yml 파일과 같은 경로에 폴더 경로들을 구성한다.

▶ 기본 설정 구성

(1). application.yml 설정

management:
  endpoints:
    web:
      exposure:
        include: "prometheus"  
metrics:
  export:
    prometheus:
      enabled: true

(2). build.gralde 의존성 추가

implementation("org.springframework.boot:spring-boot-starter-actuator:3.4.3")
implementation("io.micrometer:micrometer-registry-prometheus:1.14.5")

(3). 실행 확인(브라우저/터미널)
-브라우저-

http://localhost:8080/actuator/prometheus

-터미널-

curl http://localhost:8080/actuator/prometheus

이런식으로 아래 문구처럼 뜬다면 Actuator와 Micrometer 설정은 끝나고 Prometheus는 결과를 수집할 준비가 되었다는 뜻.

▶ 도커 이미지 기반 Prometheus + Grafana 연동

(1). docker-compose.yml 설정

services:
  prometheus:
    image: prom/prometheus:v2.47.0
    container_name: test-monitoring-prometheus
    ports:
      - "9090:9090"
    command:
      - --web.enable-remote-write-receiver
      - --enable-feature=native-histograms
      - --config.file=/etc/prometheus/prometheus.yml
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
    extra_hosts:
      - "host.docker.internal:host-gateway"

  grafana:
    image: grafana/grafana:10.1.2
    container_name: test-monitoring-grafana
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=admin
    volumes:
      - ./grafana-provisioning:/etc/grafana/provisioning:ro
      - ./grafana-dashboard:/dashboard:ro
    depends_on:
      - prometheus

  k6:
    image: grafana/k6:latest
    container_name: test-monitoring-k6
    volumes:
      - ./k6-scripts:/scripts:ro
    environment:
      - K6_PROMETHEUS_RW_SERVER_URL=http://prometheus:9090/api/v1/write
      - K6_PROMETHEUS_RW_TREND_AS_NATIVE_HISTOGRAM=true
      - BASE_URL=http://host.docker.internal:8080
      - PERFORMANCE_ID=1
      - MEMBER_ID=1
    extra_hosts:
      - "host.docker.internal:host-gateway"
    depends_on:
      - prometheus

이때, "host.docker.internal:host-gateway"이런 라인이 보일텐데, 어느 블로그에선 localhost를 쓰는 경우도 있고, host.docker.internal을 쓰는 경우도있다. 지금 같은 경우엔, 로컬PC안에서 Spring Boot 앱이 실행중이고 K6, Prometheus는 docker를 쓰는 환경이기때문에, host.docker.internal을 써야 K6나 Prometheus같이 도커 컨테이너가 로컬PC에서 실행중인 앱에 호스트 IP를 통해서 붙을 수가 있다.

쉽게 말해서, host.docker.internal은 도커 컨테이너 안에서 로컬 호스트 컴퓨터에 접속하기 위해 사용하는 주소이다.
https://grafana.com/docs/grafana/latest/datasources/prometheus/configure/

(2). prometheus.yml 설정

global:
  scrape_interval: 5s

scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets: ["prometheus:9090"]

  - job_name: spring-boot-app
    metrics_path: /actuator/prometheus
    static_configs:
      - targets: ["host.docker.internal:8080"]

(3). /grafana-dashboard/k6.json 설정

k6.json 파일 같은 경우엔 아래 링크에서 우측 하단의 Download JSON 버튼을 통해서 붙여넣어주면 된다.

https://grafana.com/grafana/dashboards/18030-k6-prometheus-native-histograms/

k6 Prometheus (Native Histograms) | Grafana Labs

Grafana 12.4 is here — faster and easier data visualization, Git Sync for observability as code updates, and more.

grafana.com

(4). /grafana-provisioning/dashboards/dashboards.yml 설정

apiVersion: 1

providers:
  - name: "k6 Stress Test"
    orgId: 1
    folder: ""
    type: file
    disableDeletion: false
    updateIntervalSeconds: 10
    options:
      path: /dashboard
      foldersFromFilesStructure: true

(5). /grafana-provisioning/datasources/prometheus.yml 설정

apiVersion: 1

datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://prometheus:9090

지금까지 prometheus.yml 파일 두개를 만들었을텐데, 전에 2번 단계에서 만들었던 prometheus.yml파일은 어디를 수집할지, 몇 초 마다 할지, 이런 Prometheus의 서버 설정에 대한 수정이였다면, 여기서는 나중에 Grafana가 Prometheus에 대한 데이터를 받을때 필요한 어떤 Prometheus서버인지 url은 뭔지, grafana datasource 설정 파일이다.

(6). /k6-scripts/stress.js 설정

이때 부하 테스트 스크립트는 따로 생성해주면 된다.

(7). docker-compose 실행

docker compose up -d

▶ Grafana 대시보드 생성 및 테스트 실행 결과

(1). 대시보드 확인

http://localhost:3000

이 url 을 통해서 Grafana사이트를 접속후에 로그인을 해준다(id: admin, pw: admin). 왼쪽 창에 대시보드를 들어가면, 이미 생성되어있는 대시보드가 있을것이다.

(2). 테스트 실행 및 결과 확인

docker compose run --rm k6 run -o experimental-prometheus-rw /scripts/<테스트파일_이름>.js

이 커맨드로 부하 테스트를 진행해주고, 다시 Grafana들어가서 대시보드를 새로고침해주면 결과 값들이 보일것이다.

▶ 참고 자료

https://grafana.com/docs/grafana/latest/setup-grafana/installation/docker/

Run Grafana Docker image | Grafana documentation

CautionStarting with Grafana release 12.4.0 , the grafana/grafana-oss Docker Hub repository will no longer be updated. Instead, we encourage you to use the grafana/grafana Docker Hub repository. These two repositories have the same Grafana OSS docker image

grafana.com

https://grafana.com/docs/k6/latest/results-output/real-time/prometheus-remote-write/

Prometheus remote write | Grafana k6 documentation

User-centered observability: load testing, real user monitoring, and synthetics Learn how to use load testing, synthetic monitoring, and real user monitoring (RUM) to understand end users' experience of your apps. Watch on demand.

grafana.com

https://one-armed-boy.tistory.com/entry/k6-Prometheus-Grafana-자동-환경-구성하기-with-Docker-compose

부하테스트를 위해 k6 + Prometheus + Grafana 자동 환경 구성하기 (with Docker-compose)

k6를 통하면 부하테스트를 js 기반 스크립트로 손쉽게 작성이 가능하다. 다만 k6는 단순 테스트 만을 수행해주기 때문에 추가적인 시각화 구성을 진행해야 할 필요가 있다. 이를 위해 구글링을 해

one-armed-boy.tistory.com

insight00-15 님의 블로그

외부 API 연동 안정화 체크리스트 : Instagram API 사례로 정리

최근에 Instagram API 연동을 필요로 하는 프로젝트를 진행하면서 Instagram API 연동 with Instagram Login 이라는 글을 썼다. 단순 구현을 하면서 점차 기술적으로 고민이 들었던 부분들을 리서치 하고 기록해보려고한다.

# Instagram API 연동, “기능 구현” 다음에 보이기 시작한 운영 관점의 고민들

Instagram API 연동 with Instagram Login

Spring Boot에서 Instagram OAuth 연동하고 게시물 인사이트 조회하기

[개발 도서] 개발자는 글을 못 쓴다고요? - 커밋 메시지 작성하기

Github Actions로 개선하는 코드 리뷰 문화

https://toss.tech/article/25431 Github Actions로 개선하는 코드 리뷰 문화

토스페이먼츠에서 적용한 GitHub Actions

[개발] "백엔드 개발자" 오픈형 멘토링: 백엔드 - 손권남 멘토

k6, Prometheus, Grafana를 사용한 부하 테스트 환경 구성하기(with Docker-compose)

▶ 부하 테스트 툴

▶ 테스트 환경 폴더 경로 설계

▶ 기본 설정 구성

(1). application.yml 설정

(2). build.gralde 의존성 추가

(3). 실행 확인(브라우저/터미널)-브라우저-

▶ 도커 이미지 기반 Prometheus + Grafana 연동

(1). docker-compose.yml 설정

(2). prometheus.yml 설정

(3). /grafana-dashboard/k6.json 설정

(4). /grafana-provisioning/dashboards/dashboards.yml 설정

(5). /grafana-provisioning/datasources/prometheus.yml 설정

(6). /k6-scripts/stress.js 설정

(7). docker-compose 실행

▶ Grafana 대시보드 생성 및 테스트 실행 결과

(1). 대시보드 확인

(2). 테스트 실행 및 결과 확인

▶ 참고 자료

(3). 실행 확인(브라우저/터미널)
-브라우저-