두 대의 서버로 분산된 로그를 실시간으로 추적하는 방법

딥링크 클릭 시 무한 로딩 이슈를 추적하면서, 서버가 2대로 분산된 환경에서 로그를 어떻게 실시간으로 파악할 것인가를 정리한 글이다.

1. Jenkins 서버 접속

현재 서비스 환경에서는 외부에서 서버에 직접 접근하지 않고, Jenkins 서버에 1차 접속한 뒤 내부 서버로 이동하는 구조로 되어 있다.

이 접속 이후부터는 Jenkins 서버 내부에서 각 환경(STG / PRD) 서버로 이동한다.

ssh -p 10022 -i ~/.ssh/example_rsa user@xxx.xxx.xxx.xxx

 

2. alias 로 서버 접속 단축하기

운영/스테이징/프로덕션 서버가 많을수록 alias 는 거의 필수다.

alias ssh.stg.admin.1='ssh user@10.1.2.12 -p 10022'
alias ssh.stg.admin.2='ssh user@10.1.4.12 -p 10022'
alias ssh.prd.main.1='ssh user@10.2.2.11 -p 10022'
alias ssh.prd.main.2='ssh user@10.2.4.11 -p 10022'

이후에는 아래처럼 바로 접속 가능하다.

ssh.stg.admin.1

alias 는 보통 ~/.bashrc 또는 ~/.bash_profile 에 정의되어 있다.

 

3. 로그 위치로 이동

cd logs
ls

예시 로그 파일:

• admin-web.log
• admin-web.log.20260122

 

4. 기본적인 로그 확인 방법 (한 서버)

tail -f admin-web.log

단일 서버라면 이 방식으로도 충분하다.

 

5. 문제 상황: 서버가 2대로 나뉘어 있는 경우

이번 이슈의 핵심은 아래였다.

• 딥링크 클릭 시 무한 로딩 발생
• 프론트에서는 요청을 보내고 있음
• 서버 로그를 보면 어떤 요청은 서버 1, 어떤 요청은 서버 2로 분산됨
• tail -f 를 하나씩 보면 흐름이 끊겨서 판단이 어려움

👉 결국 “이 요청이 어디까지 갔는지”를 한 눈에 보기 어려운 상태

 

6. 해결 ① : 두 서버 로그를 동시에 보기 (멀티 tail)

방법 A. 터미널을 두 개 띄우는 방법 (가장 단순)

• 터미널 1: ssh.stg.admin.1
• 터미널 2: ssh.stg.admin.2

각각에서:

tail -f admin-web.log

👉 빠르지만 요청 흐름을 머릿속으로 합쳐야 하는 단점이 있다.

 

7. 해결 ② : 요청 키 기준으로 필터링 (추천)

무한 로딩 이슈에서는 보통 아래 중 하나는 로그에 남는다.

• requestId / traceId
• userId
• 특정 API path

예시: 특정 API 호출만 보기

tail -f admin-web.log | grep "/deeplink"

예시: requestId 기준

tail -f admin-web.log | grep "REQ-1234"

👉 서버가 달라도 같은 키로 필터링하면 흐름이 보이기 시작한다.

 

8. 해결 ③ : 두 서버 로그를 한 화면에서 합쳐서 보기

로컬에서 두 서버 로그를 동시에 보기 (SSH + tail)

ssh user@server1 "tail -f /logs/admin-web.log" & \\
ssh user@server2 "tail -f /logs/admin-web.log"

또는 prefix 를 붙여서 구분하면 더 좋다.

ssh user@server1 "tail -f /logs/admin-web.log | sed 's/^/[S1] /'" & \\
ssh user@server2 "tail -f /logs/admin-web.log | sed 's/^/[S2] /'"

출력 예시:

[S1] /api/deeplink/start
[S2] /api/auth/check
[S1] /api/deeplink/resolve

👉 이 방식이 서버 분산 이슈 파악에 가장 직관적이었다.

 

9. 로그 관련 유튜브를 보고 추가로 정리한 핵심 포인트

 

위 이슈를 정리하면서 로그 관련 유튜브(Logging Best Practices)를 함께 참고했다.

https://www.youtube.com/watch?v=I2mWnh66Bkg

 

영상에서 다뤘던 내용 중, 이번 "두 대의 서버로 분산된 로그 추적" 문제와 직접적으로 연결되는 포인트 위주로 정리해보면 아래와 같다.

1) 로그는 사람이 읽는 텍스트가 아니라, "시스템이 분석하는 데이터"다

단순 문자열 로그는 사람이 눈으로 보기엔 편할 수 있지만,

• 서버가 여러 대로 나뉘는 순간
• 로그 양이 많아지는 순간

👉 흐름을 따라가기가 급격히 어려워진다.

그래서 영상에서는 구조화 로그(Structured Logging) 를 기본으로 가져가야 한다고 강조한다.

{
  "timestamp": "2026-01-24T12:34:56Z",
  "level": "INFO",
  "service": "admin-web",
  "requestId": "abc123",
  "path": "/api/deeplink",
  "status": 200
}

이런 형태라면:

• 서버 1 / 서버 2 로그를 합쳐도
• requestId 기준으로 필터링이 가능하고
• 동일 요청의 시작~종료 흐름을 추적할 수 있다.

이번 딥링크 무한 로딩 이슈에서도, 이런 구조로 로그가 되어있었다면 "어디까지 호출됐는지"를 판단하기 편리할 것 같다는 생각이 들었다.

 

2) timestamp + requestId(traceId)는 분산 환경의 최소 조건

영상에서 반복적으로 강조하는 포인트 중 하나는:

로그에는 반드시 시간과 요청을 식별할 수 있는 ID가 있어야 한다

이다.

이번 케이스에서도:

• 서버 1에는 첫 요청 로그만 남고
• 서버 2에는 이후 API 로그만 남아

단순히 tail -f 로 보면 중간이 끊긴 것처럼 보이는 상황이 발생했다.

👉 이 문제는 로그가 부족해서가 아니라,

👉 로그를 연결할 공통 키가 없어서 생긴 문제에 가깝다.

 

3) 로그 레벨은 많을수록 좋은 게 아니다

영상에서는 로그 레벨을 과도하게 쪼개는 것에 대해서도 경고한다.

운영 환경 기준으로는 보통:

• INFO: 정상 흐름
• WARN: 이상 징후 (하지만 서비스는 동작)
• ERROR: 실제 장애

정도로만 명확히 나눠도 충분하다.

DEBUG 로그가 과도하면:

• tail -f 에서는 노이즈가 되고
• 오히려 중요한 흐름을 가리는 결과가 된다.

이번 이슈에서도 중요한 건:

• "딥링크 요청이 들어왔는가"
• "다음 API로 이어졌는가"
• "어디서 끊겼는가"
• 였지, 모든 내부 상태 값은 아니었다.

 

4) tail 은 임시 해법이고, 정답은 로그를 "모으는 것"

영상에서 가장 공감됐던 부분은 이 문장이다.

tail 로 로그를 보는 건 결국 한계가 있다

이번 경험에서도:

• 서버 2대
• 로드밸런싱
• 상태 의존 로직

이 조합이 되자, 로그를 한 화면에서 보지 않으면 판단이 거의 불가능해졌다.

그래서 실무에서는:

• ELK
• Loki + Grafana
• OpenTelemetry + Trace 도구

같은 중앙 로그 / 트레이싱 시스템을 사용하는가 보다..

 

5) 이번 이슈에서 얻은 개인적인 결론

• 사실 이전까지는 로그를 "이슈가 생기면 확인하는 출력물" 정도로만 인식하고 있었던 것 같다. 하지만 이번 딥링크 무한 로딩 이슈를 겪으면서, 로그는 운영 환경에서 시스템의 흐름을 이해하기 위한 중요한 설계 요소라는 점을 체감하게 되었다.
• 특히 서버가 여러 대로 분산된 환경에서는, 로그를 어떻게 남기느냐에 따라 이슈를 빠르게 파악할 수 있는지, 아니면 감으로 추측해야 하는지가 크게 갈린다는 것을 알게 되었다.
• 로그 관련 유튜브를 보면서도 느낀 점은, 단순히 명령어를 잘 아는 것보다
  • 어떤 정보를 로그로 남겨야 하는지
  • 나중에 이 로그를 어떻게 연결해서 볼 것인지를 미리 고민하는 것이 훨씬 중요하다는 점이었다.
• 아직은 로그 설계나 트레이싱에 대해 부족한 부분이 많지만, 이번 경험을 계기로 다른 개발자분들께 질문도 해보고, 실제 운영 환경에서 로그를 더 의식적으로 보면서 운영 관점의 시야를 넓혀가야겠다고 느꼈다.