전체 시스템 구조도 이해하기

Chapter 6. 회사 시스템 파악

"자, 이제 우리 서비스 전체 구조를 한번 볼까?"

모니터에 복잡한 다이어그램이 떴다. 네모 박스들, 화살표들, 알 수 없는 약어들. DB, API, Cache, Queue... 머리가 지끈거린다.

'이게... 뭐지? 하나도 모르겠는데...'

팀장님은 자연스럽게 설명을 이어간다. "여기가 프론트엔드고, 여기서 API 호출하면 백엔드로 가고, 그다음 DB 조회하고..." 알아들은 건 '프론트엔드'와 'DB' 정도. 나머지는 외계어다.

고개를 끄덕이며 "네, 네" 하지만 사실 하나도 모르겠다. 이걸 언제 다 이해하지?

괜찮다. 진짜 괜찮다.

나도 그랬고, 내 주변 동료들도 다 그랬다. 첫 주에 시스템 구조도를 보고 "아, 이제 이해했어요!"라고 말하는 사람은 거의 없다. 오히려 그게 정상이다.

구조도를 처음 봤을 때 황당함이란..

내 첫 회사 입사 3일 차였다. 온보딩 미팅에서 시니어 개발자가 화이트보드에 그림을 그렸다.

"우리 서비스는 이렇게 구성되어 있어요."

큰 네모 하나 그리고 '사용자'라고 쓴다. 화살표 하나 그어서 '웹 서버', 또 화살표 그어서 '앱 서버', 또 그어서 '데이터베이스'. 그 사이사이에 'CDN', '로드밸런서', '캐시 서버', '메시지 큐'...

20분 동안 설명을 들었는데, 솔직히 반도 이해 못 했다. 용어도 생소했고, 왜 이렇게 복잡하게 나눠놨는지도 모르겠고, 각 부분이 어떻게 연결되는지도 헷갈렸다.

그날 저녁, 노트에 기억나는 대로 다시 그려봤다. 엉망이었다. 뭐가 뭔지 모르겠어서, 그냥 박스만 몇 개 그리고 '여기 뭔가 있었음'이라고 썼다.

일주일 후, 같은 다이어그램을 다시 봤을 때 조금 더 보였다. '아, 사용자가 여기로 요청을 보내는구나', '이 부분이 데이터를 저장하는 거구나'. 한 달 후에는 대충 흐름이 보였다. 3개월 후에는 "아, 여기서 이렇게 처리하니까 이런 구조구나" 싶었다.

그러니까 지금 모르는 게 당연하다. 한 번에 이해하려고 하지 말자. 천천히, 조금씩 보면 된다.

시스템 구조도가 왜 중요할까?

'그냥 내 맡은 부분만 잘하면 되는 거 아니야?'

맞는 말이다. 당장 내일 할 일은 아마 아주 작은 기능 하나를 고치거나 추가하는 것일 거다. 전체 시스템 구조를 몰라도 그 일은 할 수 있다. 하지만 조금만 지나면 달라진다.

버그가 생겼을 때, "이 에러가 프론트엔드 문제인지, 백엔드 문제인지, DB 문제인지" 구분할 수 있어야 한다. 새 기능을 추가할 때, "어느 부분을 수정해야 하는지" 알아야 한다. 장애가 났을 때, "어디서부터 확인해야 하는지" 판단할 수 있어야 한다.

그리고 무엇보다, 회의 시간에 팀장님이나 선배들이 하는 말을 알아듣기 위해서다.

"여기 API 레이어에서 처리하는 게 나을까요, 아니면 DB 쿼리로 해결할까요?"

이런 말을 들었을 때, 최소한 무슨 얘기를 하는지는 알아야 한다. 대답을 못 해도 괜찮다. 하지만 질문 자체를 이해 못 하면 대화에 끼기 어렵다.

구조도를 처음 볼 때 집중할 것

시스템 구조도에는 엄청나게 많은 정보가 담겨 있다. 하지만 처음부터 다 이해하려고 하면 머리만 아프다.

초반에는 딱 세 가지만 해보자.

1. 사용자의 요청이 어떻게 흐르는가?

"사용자가 버튼을 클릭하면 어떻게 되지?" 이 질문 하나만 따라가 보자.

보통은 이런 흐름이다:

사용자가 웹 브라우저나 앱에서 버튼을 클릭한다

프론트엔드에서 서버로 요청을 보낸다

서버(백엔드)가 요청을 받아서 처리한다

필요하면 데이터베이스에서 정보를 가져온다

결과를 다시 프론트엔드로 보낸다

화면에 결과가 표시된다

이 기본 흐름만 알아도 절반은 이해한 거다.

다이어그램을 보면서 손가락으로 따라가 보자. "사용자 -> 프론트엔드 -> 백엔드 -> DB -> 백엔드 -> 프론트엔드 -> 사용자" 이 경로를 여러 번 그려보면 점점 익숙해진다.

2. 주요 컴포넌트가 무엇인가?

복잡한 다이어그램에도 보통 핵심은 3~5개 정도다.

대부분의 서비스는 이런 구조다:

프론트엔드: 사용자가 보는 화면 (웹 페이지, 모바일 앱)

백엔드: 실제 비즈니스 로직을 처리하는 서버

데이터베이스: 데이터를 저장하는 곳

외부 서비스: 결제, 이메일, 문자 발송 같은 외부 API

여기에 추가로:

캐시: 자주 쓰는 데이터를 임시로 저장해서 빠르게 응답

큐: 처리할 작업을 줄 세워서 순서대로 처리

파일 저장소: 이미지, 동영상 같은 파일을 보관

처음에는 "프론트엔드, 백엔드, 데이터베이스" 이 세 가지만 구분할 수 있으면 된다. 나머지는 천천히 배우면 된다.

3. 내가 담당할 부분이 어디인가?

"나는 여기서 어느 부분을 만질 거지?"

내가 백엔드 개발자라면 백엔드 부분에 동그라미 치자. 프론트엔드 개발자라면 프론트엔드 부분에. 전체를 다 알 필요는 없다. 내가 주로 작업할 영역만 집중해서 보면 된다.

그 영역 안에서:

어떤 기술을 쓰는지

어떤 파일들이 있는지

어떤 데이터를 주고받는지

이것만 파악하면 당장 일하는 데는 문제없다.

구조도를 이해하는 실전 방법

방법 1: 실제 서비스를 써보면서 따라가기

가장 효과적인 방법이다.

우리 회사 서비스를 직접 써보자. 회원가입부터 시작해서, 로그인하고, 주요 기능을 하나씩 클릭해 보자.

그리고 구조도를 옆에 놓고 생각해 보자.

"지금 내가 로그인 버튼을 눌렀다. 그럼 화면에서 서버로 요청이 간다. 서버는 DB에서 내 정보를 확인한다. 맞으면 로그인 성공."

이렇게 내가 하는 행동과 시스템 구조를 연결해서 생각하면 훨씬 이해가 쉽다.

방법 2: 선배에게 5분짜리 요약을 부탁하기

"전체 시스템 구조를 간단하게 설명해 주실 수 있을까요?"

대부분의 선배들은 기꺼이 설명해 준다. 단, 조건이 있다. 간단하게 부탁하는 거다.

"30분 동안 자세히 설명해 주세요"라고 하면 선배도 부담스럽다. 하지만 "5분 정도만 핵심만 간단히 설명해 주실 수 있을까요?"라고 하면 훨씬 편하다.

5분 설명을 듣고, 나중에 또 궁금한 게 생기면 그때 또 물어보면 된다. 한 번에 다 이해하려고 하지 말자.

센스있게 커피한잔으로 선배에게 감사에 표시는 잊지 말자.

방법 3: 문서를 찾아 읽기

대부분의 회사는 시스템 구조를 설명하는 문서가 있다.

보통 이런 곳에 있다:

사내 위키 (Notion, Confluence 등)

README 파일

온보딩 문서

기술 블로그

"시스템 아키텍처", "전체 구조", "기술 스택", "인프라 구성" 같은 키워드로 검색해 보자. 문서를 읽을 때는 한 번에 다 읽으려고 하지 말고, 필요한 부분만 발췌 독서하자. "아, 오늘은 프론트엔드와 백엔드가 어떻게 통신하는지만 알아보자" 이런 식으로 조금씩.

방법 4: 노트에 직접 그려보기

남이 그린 다이어그램을 백 번 보는 것보다, 내가 직접 한 번 그려보는 게 백배 낫다.

A4 용지 하나 꺼내서 내가 이해한 만큼만 그려보자. 틀려도 괜찮다. 처음부터 정확하게 그릴 수 있는 사람은 없다.

그리고 그걸 선배한테 보여주고 "제가 이해한 게 맞나요?" 물어보자. 선배가 "여기는 이렇게 되는 거고, 저기는 저렇게 되는 거야" 하고 고쳐줄 거다. 그 과정에서 훨씬 깊이 이해하게 된다.

내 경험상, 이렇게 직접 그려보고 피드백받는 게 가장 빠르게 배우는 방법이었다.

시스템 구조파악 노하우

모르는 용어는 바로바로 검색하기

회의 중에 모르는 용어가 나왔다. "CDN", "메시지 큐", "서비스 메시 "...

그 자리에서 고개 끄덕이지 말고, 나중에라도 꼭 검색해 보자. 모르는 용어가 쌓이면 나중에 더 어려워진다.

스마트폰 메모장에 적어뒀다가, 점심시간이나 퇴근 후에 하나씩 검색해 보면 된다.

비슷한 서비스의 구조를 찾아보기

우리 회사 서비스와 비슷한 다른 서비스의 기술 블로그를 찾아보자.

예를 들어 전자상거래 회사라면 다른 쇼핑몰의 기술 블로그를 보는 거다. SNS 서비스라면 다른 SNS의 아키텍처를 찾아보는 거다.

"아, 다른 회사도 이런 식으로 구성하는구나" 하고 비교하면서 보면 이해가 훨씬 쉽다.

완벽하게 이해하려고 하지 않기

1년 차에게 시스템 전체를 완벽하게 이해하라고 요구하는 회사는 없다.

선배들도 처음엔 몰랐다. 5년 차, 10년 차가 되어서야 전체를 파악하게 된 사람도 많다.

그러니까 조급해하지 말자. 지금은 "대충 이렇게 흘러가는구나" 정도만 알아도 충분하다.

질문할 때는 구체적으로

"시스템 구조를 모르겠어요"보다는 "프론트엔드에서 백엔드로 데이터를 보낼 때 어떤 방식을 쓰나요?"가 훨씬 좋은 질문이다.

구체적인 질문을 해야 구체적인 답을 들을 수 있다. 그리고 선배도 대답하기 편하다.

체크리스트: 시스템 구조 파악 진행 상황

입사 후 시간이 지나면서 아래 항목들을 하나씩 체크해 나가자. 첫 주에 다 할 필요 없다. 천천히.

1주 차

시스템 구조도 문서 찾아서 읽어보기

프론트엔드, 백엔드, 데이터베이스가 무엇인지 구분하기

우리 서비스를 직접 사용해 보기

1개월 차

사용자 요청이 어떻게 흐르는지 대략 이해하기

주요 컴포넌트(5개 정도) 이름과 역할 알기

내가 담당할 영역이 어디인지 파악하기

구조도를 내 손으로 직접 그려보기

3개월 차

API가 무엇인지, 어떻게 호출하는지 이해하기

데이터가 어디에 저장되는지 알기

로그를 보면서 데이터 흐름 추적해 보기

간단한 기능 하나를 처음부터 끝까지 따라가 보기

막막함을 넘어서

입사 첫 주에 시스템 구조도를 보면 막막하다. 박스도 많고, 화살표도 많고, 용어도 생소하다.

하지만 괜찮다.

나도 처음엔 그랬다. 내 옆자리 5년 차 선배도 1년 차 때는 그랬다고 한다. 팀장님도 신입 때는 그랬을 거다.

시스템 구조는 한 번에 이해하는 게 아니라, 매일 조금씩 익숙해지는 거다.

오늘은 프론트엔드와 백엔드를 구분했고, 내일은 API가 뭔지 알게 되고, 다음 주에는 데이터베이스 구조를 이해하고, 한 달 후에는 전체 흐름이 보이기 시작한다. 그러니까 조급해하지 말자.

지금은 "아, 대충 이런 식으로 되어 있구나" 정도만 알아도 충분하다. 나머지는 일하면서 자연스럽게 배우게 된다. 3개월 후, 다시 그 복잡했던 구조도를 보면 이렇게 생각하게 될 거다.

"어? 생각보다 간단한데?"

그때가 되면 당신은 이미 그 시스템의 일부가 되어 있을 것이다.