Linux 3일차: 웹·DB·파일·DNS 서비스를 연결하다

<aside>

☁️ 클라우드웨이브 시리즈 · W02 · 3/5 · 예상 읽기 6~8분

</aside>

이 글에서 확인할 것

웹 요청과 DB의 경로를 그린다
DNS의 역할을 이해한다
연결 실패를 계층별로 나눈다

웹 서버와 DB가 따로 움직이는 것처럼 보였지만, 실제 요청은 이름 해석부터 저장소까지 여러 경계를 지난다.

핵심 개념

웹 서비스는 요청을 받고 DB는 구조화된 상태를 저장한다. 파일 저장소는 문서나 큰 객체를 담당하고 DNS는 이름과 주소를 연결한다. 이름이 해석되어도 포트가 닫힐 수 있고 웹이 응답해도 DB 연결은 실패할 수 있다.

확인 순서

이름 해석, 네트워크 연결, 웹 응답, 애플리케이션 로그, DB 설정, 파일 권한 순서로 확인한다. 계층을 섞지 않으면 어느 경계에서 실패했는지 빠르게 좁힐 수 있다.

curl -I <https://example.com>
ss -lnt
getent hosts example.com

흐름으로 연결하기

flowchart LR
 A["관찰"] --> B["원인 분리"]
 B --> C["안전한 변경"]
 C --> D["다시 확인"]

실무로 이어지는 질문

서비스별 책임과 실패 경계를 문서화한다. 테스트에는 example.com과 문서용 주소만 사용하고 실제 도메인·주소·계정은 기록하지 않는다.

헷갈렸던 점

DNS 변경이 즉시 전파된다고 생각했지만 캐시 때문에 시간이 걸릴 수 있다. 포트가 열렸다는 사실도 인증과 로직의 정상 여부를 보장하지 않는다.

여러 서비스를 설치할 때 분리해서 보는 기준

여러 서비스를 한 번에 설치하거나 실행할 때는 설치가 끝났다는 사실과 서비스가 실제로 동작한다는 사실을 분리해서 확인한다. 먼저 각 서비스가 요구하는 패키지와 실행 주체, 의존 관계를 나누어 보고 한 서비스의 실패를 다른 서비스의 문제로 섣불리 묶지 않는다. 다음으로 서비스별 포트와 연결 방향을 따로 기록해 동일한 포트 충돌이나 외부·내부 연결 문제를 구분한다. 마지막에는 서비스 단위별 로그를 시간 범위와 함께 읽어 설치 오류, 시작 실패, 요청 처리 오류를 분리한다. 의존성·포트·로그를 각각 확인하면 여러 변경이 동시에 일어날 때도 원인 범위를 좁힐 수 있다.