백엔드 개발자를 시작할 때 알아야 할 5가지 flow

 

인사이드아웃이란 영화를 본 적이 있나요? 인사이드아웃은 머릿속의 의인화된 다섯 가지 감정 세포들이 주인이자 새로운 경험에 혼란스러운 초등학생 라일리를 위하는 방향으로 저마다 이끌어가며 해결해 나가고 성장하는 이야기입니다.

 

 

라일리는 새로운 경험을 할 때마다 머릿속에 새로운 섬이 생기고 기존의 섬들은 무너지기도 합니다. 각각의 섬들은 라일리가 공부를하고 관심을 가질수록 더 커지고 발달합니다. 

 

지금은 제 머릿 속에도 이런 몇 가지 섬이 생긴 것 같습니다. 

그러나 갓 학생 티를 벗고 개발자로 일을 시작했을 때는 굉장히 헤매었었는데요.

 

저를 혼란스럽게 한 근원적인 질문이 있었습니다. 

 

이게 어디에 써야 하는 거지?

 

알아야 할 것들도 많고 여러 설명을 듣긴 하는데 "어디"에 쓰는 건지를 모르니 목적을 모르게 되고 큰 그림이 그려지지 않으니 머릿속에서 정리가 잘되지 않았습니다. 또 이런 부분은 기존 개발자분들에게는 너무나 당연해서 알고 있을 거라 가정하고 이야기하는 경우가 많습니다. 저도 시간이 지나고 경험을 하다 보니 머릿속에 섬들이 생기고 더 쉽게 배울 수 있었던 것 같습니다.

 

개발자는 프로그램이란 제품을 만들기 위해 기본적으로 알아야 하는 프로세스와 플로우가 있습니다. 간단하고 필수적인 큰 틀과 흐름에서 시작해 여러 문제점을 개선하기 위해 많은 기술과 개념들이 들어가 있습니다. 이런 프로세스를 자각하고 기술들을 프로세스와 플로우 내에 분류할 수 있으면 새로운 걸 받아들이기가 쉬워집니다. 제가 추천하는 기본적인 플로우이자 머릿 속 섬들은 다음과 같습니다. 

 

1. 유저→ 서버: 유저 서비스 
2. 요구사항 → 코드: 개발과 협업
3. 코드 → 제품: 배포
4. 원천 데이터 소스 → 데이터베이스: 데이터 파이프라인
5. 서버 로그, 지표 수집 → 통합: 모니터링 시스템

 

대표적인 5개로 분류하고 Keyword로 플로우에서 알아야 하는 기술과 개념을 분류해서 적어보겠습니다.

 

1. 유저 → 서버: 유저 서비스

keyword

 

• 네트워크 통신: 서버-클라이언트, Rest, gRPC, socket 등
• 인터넷 네트워크: CDN, DNS
• 인증: Gateway, Reverse Proxy, Https(tls), 쿠키, 세션, Oauth, Jwt 등  
• 네트워크보안: 망분리, 방화벽, 보안정책, ACL
• 스토리지: S3, Nas, Cache(Redis) 
• 클라이언트: 프런트엔드 동작, 브라우저 동작 이해

쉽게 생각해 유저가 서비스를 사용하는 과정을 나타낸 플로우입니다. 

사용자 입장에선 앱을 썼을 때 뒤에서 일어나는 일에 대해 알 필요가 없습니다. 빠르고 쾌적하면 되는 거죠. 그러나 개발을 하려면 뒤에서 일어나는 플로우를 정확히 알아야 합니다.

 

기초적인 클라이언트 - 서버 구조에서부터 시작해 MSA 환경과 API Gateway, 보안, 방화벽과 DNS, CDN, 캐시 등 그리고 포트포워딩과 서버 클러스터링을 넘어서 쉬운 기반 위에 많은 미들웨어와 옵션들, 기능들이 들어가 한없이 복잡하고 알아야 할 것들도 많습니다. 지금도 새로운 것들이 많이 생기고 공부해야 합니다. 이런 요소들이 추가된 건 유저에게 더 나은 서비스 환경을 제공하기 위해  여러 문제 상황을 해결하면서 추가된 경우가 많습니다. 

 

2. 요구사항 → 코드: 개발과 협업

 

keyword

 

• 개발 방법론: 에자일, TDD, BDD, Waterfall
• 기획-디자인 툴: figma, zeplin
• 이슈 및 프로젝트 추적, 업무 할당: jira, slack 
• 도메인 이해, 소프트웨어 설계:
• 버전관리, 코드버전관리(VCS): git, branch 전략 
• QA

기획서를 읽고 소프트웨어를 정의하고 여러 명이서 제품을 만드는 과정입니다. 

회사에선 혼자가 아닌 여러 명이 개발하는 방법을 배우게 됩니다.

• 기획자, 디자이너와 같은 비개발자와 요구사항을 이해하고 소통하는 것
• 클라이언트 개발자와 통신하며 동작 플로우를 맞추는 것
• 서버 개발자끼리의 코드를 병합하고 업무를 분배하는 것도 여기에 포함합니다.

개인이 개발하다가 회사에서 다른 파트의 여럿이 개발에 참여하게 되어 제일 낯선 부분이기도 합니다. 회사마다 문화가 달라 문화를 이해하고 각자 프로세스를 배워갈 필요가 있습니다. 결국 일하는 법을 배우는 것 같습니다. 일단 일을 배우고 새로운 문화를 도입하는 것입니다.

업무들을 티켓으로 정리하며 일정관리를 하게 해 주는 jira나 기획서에 대한 내용을 공유하는 figma 등의 프로그램도 쓰게 됩니다.

클라이언트 개발자분들이 사용할 수 있도록 기능을 API 형태로 만들어야 합니다. 또 Swagger 같은 문서를 작성해 공유하는 법도 알아야 합니다.

서버개발자는 서로 코딩한 코드들을 문제없이 합치는 branch 전략도 알아야 합니다. 

TDD나 애자일 같은 개발방법론도 큰 그림에서 여기에 포함됩니다. 

 

3. 코드 → 제품: 배포 파이프라인

keyword

• Docker, Kubernetes
• CI/CD: jenkins, argoCD, github Action
• Saas, Iaas: terraform, cloudplatform, Ansible 
• Repository: git repository, github, gitlab, bitbucket, Docker, image repository, harbor, dockerhub, helm

코딩만 한다고 제품이 완성되는 게 아닙니다. 코딩으로 만들어진 결과물을 체계적으로 확인하고 패키징 해서 라이브환경에서 실행을 시켜야 합니다. 이를 배포 과정이라고 얘기합니다.

 

여기서 패키징과정을 CI / 패키징 한 파일을 운영서버에 전달해 실행하는 과정을 CD라고 합니다. 

 

이 과정은 공통화된 스크립트와 파이프라인으로 안정적으로 진행되어야 빠르게 기능을 추가하고 문제를 해결할 수 있습니다.

 

개발한 기능이 다른 분들이 만든 부분과 호환이 되는지도 확인을 해야 하고 확인해야 할 것들이 많습니다.

내 컴퓨터에서 잘 되던 게 라이브 환경에서 제대로 안 될 수도 있습니다.

회사마다 보안설정과 부하분산, 리소스 관리가 되어있는 배포서버도 있을 수 있습니다. 내 소스를 테스트 과정을 거쳐 배포 서버에 업데이트하는 프로세스도 알고 있어야 합니다. 

 

4. 원천 데이터 소스 → 데이터베이스: 데이터 파이프라인

keyword

 

• ELT vs ETL
• 배치, 스케쥴러 (cronjob)
• 추출: 크롤링
• 변환: Logstash, fluentd, 카프카
• 적재: 하둡, Spark, Elasticsearch, NoSQL, RDBS

회사의 가치는 데이터에서 옵니다. 어떤 데이터를 어떻게 잘 가공해서 효율적으로 구조화해 클라이언트한테 제공하는 게 핵심입니다.

데이터를 얻기 위해 원천 데이터를 가지고 있는 회사에 돈을 주고 계약해서 받아올 수도 있고 크롤링 시스템을 만들어서 웹상에서 긁어오는 경우도 있고 오픈 데이터를 이용할 수도 유저들로부터 데이터를 가져올 수도 있다. (회사에서는 대부분 계약을 통해 데이터를 가져오는 경우가 많습니다.)

이 데이터를 실시간으로 빠르게 저장하고 불러오는 시스템을 구축하는 걸 데이터 파이프라인이라고 합니다. AI나 빅데이터 시대가 되면서 이 시스템에 대해 많이 발전하고 있습니다.

 

 

5. 서버 로그, 지표 수집 → 통합: 모니터링 시스템(+시각화)

keyword 

 

• 로그: Logging, Metric, acuator
• Tracing system: Trace id, slueth, zipkin, pinpoint 
• 서비스메시: 트래픽관리, 관찰가능성(observability), istio 
• 적재: 시계열 데이터, Prometheus, InfluxDB, Elasticsearch, Data dog
• 시각화, 알림 : Grafana, Webhook, slack, kiali

 서버는 여러 이슈들로 인해 불안정해질 수 있습니다. 그런 상황을 최대한 빠르게 인지할 수 있어야 합니다. 그렇게 하기 위해선 서버에서 로그나 서버 상태(metric)를 기록하고 이를 주기적으로 수집해야하며 중앙화된 모니터링 시스템이나 웹훅을 통한 메신저 알림을 통해 빠르게 알려줄수 있어야합니다. 

 이런 데이터는 주기적인 시간의 흐름을 저장하는 데이터로 시계열 데이터라고 합니다. 이런 데이터 저장에 특화된 InfluxDB나 Prometheus 같은 데이터베이스에 저장을 하고 이에 잘 연동되는 Grafana 같은 시각화툴 같은 걸 알면 좋습니다. 메신저로 많이 쓰이는 slack이나 teams 에도 웹훅을 가지고 있어서 에러 상황에 대한 로그를 감지해서 메신저로 바로 알려주기도 합니다. 

 이런 로그 데이터는 추후에 유저 반응이나 리텐션의 지표로도 활용할 수 있어서 4번의 데이터랑도 비슷한 결입니다. 

 

저도 최근에 팀을 옮기면서 새로운 팀의 시스템에 적응을 해야 합니다. 저는 제 머릿속에 생긴 5가지 섬에서 새로 배우는 것들을 분류하며 배운 것들을 빠르게 이해하려고 합니다. 새로운 걸 이해하는 좋은 방법은 비슷한 것끼리 연결해 보는 것입니다. 처음 듣는 개념들도 어느 flow에 속하는 개념인지를 생각하면서 듣고 정리해 보시면 많이 도움이 되실 거예요.