'주니어 백엔드 개발자가 반드시 알아야 할 실무 지식'을 읽고 떠오른 내 생각들

책 : 주니어 백엔드 개발자가 반드시 알아야 할 실무 지식 (최범균 저)

이 책에 대한 간단한 소감은 ‘읽은 책 소감 - 주니어 백엔드 개발자가 반드시 알아야 할 실무 지식’에 있다.

기술 서적을 읽을 때 보통 스터디를 진행하면서 챕터별로 따로 정리해서 글을 썼었다. 처음 책을 구매할땐 목차만 보고 3일이면 읽을 거라 생각했지만, 생각보다 깊이 있는 내용에 매 장마다 내 생각을 정리하기 위해 손이 자꾸 노션으로 가게 되었고, 결국 10일 이상이 걸렸다. 읽으면서 드는 생각을 정리하다 보니 어느새 80페이지가 넘는 기록이 쌓였다.

이 글은 그 과정에서 챕터별로 맛있던 부분을 정리한 것 중 일부를 적어둔 글이다. 기존에 몰랐던 부분도 있었고, 기존에 직관적으로 그렇게 했으나 이번에 재확인 할 수 있었던것도 있었다. 알고 있더라도 바라보는 시각적으로 좋았던 점들도 있었다. 사실 그냥 내가 느낀대로 두서없이 써놓은 것이다보니, 이 글을 읽는 분들께 크게 도움이 될만한 내용은 아니다. 이 책을 다 읽으신 후에, 본인의 생각과 제 생각을 비교해서 보면 재밌을 것 같은 정도의 글이다.

느려진 서비스, 어디부터 봐야 할까

일반적으로 스케일업보다 스케일아웃을 선호하고 먼저 생각했었다. 근데 책에서 ‘DB에서 성능 문제가 발생한거였는데 처리량 늘린다고 서버를 스케일아웃하면 더 안좋다’ 라는 부분이 있었다. 말이야 당연한거였지만, 그동안 DB 때문에 문제된적이 없다보니 그동안 DB를 전혀 생각을 안하고 있었다. 그동안 운이 좋았다는 생각이 들었다.
‘긴 시간동안 무응답 상태로 유지되는 것보다 빠르게 에러를 반환하는 것이 더 낫다’는 내용이 여러번 등장한다. 즉, 읽기 타임아웃을 너무 길게 유지하는것에 대한 문제점이 책에 나온다. 이건 책을 읽는 도중 바로 관련 상황을 보게되어서 재밌었다. 2025-05-16 오전 11시부터 인프런에서 특정 강의에 대해 90% 할인쿠폰을 선착순으로 1000명 발행했다. 난 당연히 그걸 받으려고 기다렸는데, 서버가 터졌다. 여기서 재밌던점은, 오전 11시쯤 타임아웃은 분명 10초 이상이었다. 회복될 기미가 보이지 않던 인프런 서버는 그러다가 11시 5분쯤엔 거의 0.1초 정도로 타임아웃을 설정한걸로 보인다. 그리고, 난 11시 6분쯤 쿠폰을 받는데 성공했다. 책을 읽기전엔 그런 부분에 눈에 안보였을 것 같은데, 책을 읽음으로써 시야가 넓어진 것 같다.
평소 트래픽이 순간적으로 급증하는 패턴에 대해, 미리 생성해서 캐싱해두는 팁도 좋았다. 실제로 지도 관련 서비스에서 그렇게 해봤었지만, 트래픽 급증에 대해 생각하고 한건 아니었다. 애초에 무거운 서비스라 그랬다. 평소 트래픽을 관찰해서 순간적으로 급증하기 전에 미리 생성해서 캐싱해주자는 부분이 좀 더 시야를 넓힐 수 있어서 좋았다.

성능을 좌우하는 DB 설계와 쿼리

3장에서 내가 그동안 생각하고 있지 않았던 내용이 많았다. DB 공부 좀 해야겠다.
보통 DB에서 인덱스 걸 때, 선택도가 높은 칼럼을 선택하라고 한다. 예를들어서 ‘성별’ 칼럼에 인덱스를 거는건 딱히 의미 없다. 책에서는 실무적으론 도움이 되는 경우도 있다고 얘기해줘서 좋았다. 예를들어 status 같은게 있고, ‘대기중’, ‘처리중’, ‘완료’ 이런 상태값을 가지는 경우 ‘완료’가 대부분이니 이론적으론 선택도가 낮아도 완료가 아닌 상태를 뽑는데는 인덱스 걸기 좋다는 얘기였다.
또 실무적으로 도움이 될 부분이, 예약자명으로 조회 가능한 요구사항이 있다고 할 때 풀 스캔 방지를 위해 이름에 인덱스를 걸 수 있다. 하지만 요구사항을 ‘특정 일자에 예약한 예약자명’으로 변경할 수 있다면 따로 인덱스를 안걸어도 되는 경우가 있다는 점이었다. 이런식으로 실무적으로 많이 얘기해주셔서 좋았다.
그 외에도, 타입이 서로 다른 칼럼 조인 시 명시적으로 형변환해서 인덱스를 타도록 만들어주는 부분도 좋았고, 데이터 많은 테이블에 새로운 칼럼을 추가하는 경우 온라인 DDL에 대한 설명도 좋았다.
외부 연동 시, 예를 들어 ‘환영메일 발송’에 실패했다고 가입 자체가 실패하도록 롤백되는게 맞냐는 부분도 좋았는데, 실제로 이전에 프로젝트 하면서 직관적으로 이렇게 처리한 부분이 있었기 때문이다. 그 때, 어차피 우리 도메인 로직과 관련없는 외부 연동 부분이라서 실패 시 별도로 무시하도록 처리해두었었는데 그게 생각나서 재밌었다.

외부 연동이 문제일 때 살펴봐야 할 것들

연결 타임아웃은 3~5초, 읽기 타임아웃은 5~30초로 설정 후에 이후 추이를 보면서 조정하라는 부분도 좋았다. 어찌보면 별거 아니고, 인터넷에서 검색해도 나올만한 내용이지만 실력 좋은 개발자님의 이런 실질적인 팁은 확실히 이후 의사결정에 reference가 되어줘서 좋아한다.
벌크헤드 패턴 소개도 좋았다. 이것도 이전에 ‘벌크헤드 패턴’이라고 알고 쓴건 아니지만, 꽤 자주 사용한 방식이라 그런게 생각나서 좋았다. 예를들어 대용량 파일 전송하는 부분에 벌크헤드 패턴 형태로 구현해서 영향이 끼치지 않도록 구현했었다.
DB연동과 외부 연동을 함께 진행해야할 때, 오류 발생 시 케이스별로 어떤식으로 처리하는게 좋을지 써두신 점이 좋았다. 확실히 책 제목값 한다고 생각이 들었다.
외부 API 연동 시 연결 타임아웃으로 트랜잭션을 롤백했는데, 실제론 외부 시스템에서 성공하는 경우가 당연히 존재한다. 이 때 저자님이 이런 방법도 있다고 소개해주셨는데, 확실히 이론을 따진 책에선 나오기 힘든 내용같아서 재밌었다. 뭐였냐면, 예를들어 ‘결제’ API를 부른 뒤에 타임아웃 난 경우 일정 시간 지난 후 ‘취소’ API를 호출하라는 내용이었다. 취소할게 있다면(=타임아웃 이후 외부API에선 실제로 결제가 되었다면) 알아서 취소가 될테고, 없다면 오류나고 끝이다. 아무튼 이후 별도 처리할 부분은 없어진다.

비동기 연동, 언제 어떻게 써야 할까

외부 연동 결과가 다음 로직 진행을 위해 꼭 필요한게 아니라면 비동기를 고려해보라고 얘기하면서, “학습을 완료한 학생에게 포인트 지급” 등 몇몇가지 실무적인 예시를 들어준게 좋았다. 확실히 고수 개발자의 경험이나 실무적인 팁 같은게 지금의 나에겐 더 재밌는거같다.
이후 비동기 방식에 대해, 별도 스레드로 실행하기, 메시징 방식, 배치 전송, CDC 같이 방식을 나눠서 설명해준 부분도 좋았다. 어떤 상황에 어떤걸 고려할지 판단하기 좋은 내용이었다.
“기술을 선택할 때는 개인의 호기심이나 취향보다는 조직의 역량과 지속 가능성을 고려해야한다”는 부분도 좋았다. 이건 내 경험이기도 해서 상당히 찔리기도 했다. 물론 결과적으로 실제 운영 시 효과적으로 장애전파를 막게된 경험도 있고(운영팀은 싫어했지만), 아직 효과를 못보인 부분도(운영팀은 또 싫어했지만) 있다 ㅋㅋ
트랜잭션 아웃박스 패턴 설명도 좋았다. 특히 이론에서 끝나지 않고 저자분이 일반적으로 사용하는 테이블 기본 틀을 보여주시는 점도 좋았다. 확실히 이런 고수분의 경험담은 어디가서 보기 힘들어서 항상 재밌다.
배치 전송 방식 설명에서 ‘큰손 고객에게는 DB에 직접 데이터를 넣어주는 개발까지 해주는 곳도 있다.’ 라는 부분도 재밌었다. 역시 경험이 있기 때문이다 ㅋㅋ. 파일 전송 이후 파일 백업이나 중복처리 방지, 재전송에 대한 부분은 신기하게도 내가 이전에 직관적으로 처리한 부분과 동일해서 재밌었다.
CDC(Change Data Capture) 방식은 읽으면서 DB에 숨겨진 로직이 생기는게 아닐까 걱정하며 봤다. 어쨌든 상황에 따라 쓸 수도 있으니 선택지가 늘어났다고 생각하며 읽었다. 책에서도 아무래도 레거시 시스템을 건드리기 힘들 때 고려해보라고 써있었다.

동시성, 데이터가 꼬이기 전에 잡아야 한다

일반적으로 동기는 블로킹이고, 비동기는 논블로킹이다. 책에서 동기, 비동기 관련 내용이 나오면서 갑자기 궁금해져서 동기+논블로킹, 비동기+블로킹 조합에 대해 좀 생각을 해봤었다. 어찌보면 딱히 쓸데는 없지만 이런거 생각해보는것도 재밌는것같다.
자바 클래스 내에 필드값 두고 뭔가 저장하는 형태에 대한 위험성 부분도 책에 나온다. 이건 나도 경험이 있는데, 팀원이 Controller 내에서 private String clientId 이런식으로 넣고 쓰는 코드 PR이 올라온걸 봤었다. 깜짝 놀라서 왜 문제가 되는지 바로 설명드렸었다. 사실 누군가 모를꺼라 생각 자체를 못했던 것 같다. 혹시 다른분들도 모를까 싶어서 바로 사내 세미나를 했던 기억이 난다.
이전에 대규모 파일 전송 관련해서, 하위 기관별로 한 번에 1개씩만 처리되도록 큐잉 시스템을 넣어본적이 있었다. 이 책을 보다보니 그 때 락 걸어서 해결했어도 됬겠네 싶긴 했다. 근데 다시 생각해보니 그럼 하위 기관 입장에선 “작업이 추가되었습니다. 순차적으로 처리됩니다.” 같은 일단 성공 메시지를 받는게 아니라, 락 걸린동안 대기해야할테니 내가 한것도 괜찮았겠네 싶다.
읽기 쓰기 잠금 관련해서 ReentrantReadWriteLock 사용한 예시 코드도 있어서 좋았다.
비관적, 낙관적 락이 사실 용어적으로 헷갈렸다. 이번 기회에 ‘실패할 확률이 높아서 비관적이니 선점하고 비관적 락 걸자!’, ‘실패할 확률이 낮아서 낙관적이니 낙관적 락 걸자!’ 이런식으로 확실히 뇌리에 남게 기억된 것 같다.
전반적으로 이 챕터에서 반성을 제일 많이했는데, 내가 락에 대해 별로 생각을 안한 적이 많았다는 점이다. 물론 내가 개발한 시스템이 대부분 락을 크게 신경안써도 되는 구조긴 했지만, ‘몰랐지만 괜찮았다’랑 ‘알기때문에 회피했다’는 좀 다르다. 난 ‘잘 몰랐지만 회피했다’ 부류라 반성했다.
실무적으로 교착상태 해결 방안을 제시해준 부분도 좋았다. 또 라이브락 회피도 함께 잘 설명되어 있었다.

IO 병목, 어떻게 해결하지

단순히 플랫폼 스레드는 메모리를 많이 먹는다. 이런식으로 얘기하지 않고, 플랫폼 스레드는 수백kb에서 수mb, 가상스레드는 수백바이트에서 수kb~수십kb 이런식으로 구체적으로 적어준 점이 좋았다.
책에 나온 가상스레드 관련해서는 추가로 찾아보며 내 생각을 블로그에 별도 글로 썼다. ‘자바, 스프링부트 가상스레드 도입과 관련한 짧은 개인 정리’
성능 문제가 없는데 성능을 높이겠다며 복잡하게 구현하지 말자라고 얘기해준 부분이 좋았다. YAGNI 원칙!
‘팀이나 개인이 문제 해결에 도움이 될 기술을 여유 있게 학습해두자. 그런 준비가 중요한 순간에 큰 힘이 된다’ 라고 표현한 부분도 좋았다. 기존 내 생각도 동일한데, 사실 알고리즘 같은 경우 많인 경우에 DB나 라이브러리 수준 이상으로 생각이 필요한 구간이 잘 없다. 하지만 1년에 그래도 못해도 1~2번 정도 알고리즘 지식이 필요한 경우가 분명 있다. 이 때, 애초에 지식이 없으면 방법 자체를 생각할 수 없고 몇 주 걸릴일이, 이미 지식이 있다면 10분도 안걸리는 경우가 많다.

실무에서 꼭 필요한 보안 지식

단방향 ‘암호화’는 암호화가 아니라 해싱이라는 부분을 이번에 완벽히 이해해서 좋았다.
bcrypt 관련되서 이전에 아무래도 궁금했는데 안찾아보다가, 이번에 bcrypt 관련 내용이 나와서 bcrypt 동작 원리에 대해 이해하게 되서 이것도 좋았다.
책을 보다가 이전에 사내에서 방화벽 inbound 설정에 대해 CIDR가 ‘/0’ 으로 되있는걸 본적이 있었다. 이게 갑자기 생각났다. 참고로 123.123.123/0 이렇게 설정하면 전체 오픈이다!
시스템 뿐 아니라 개발자 pc 자체에 대한 개인 보안 내용도 책에 나와서 좋았다. 내 경우 관련된 내용을 블로그에 써둔적이 있다. ‘귀찮지만 확실한 랜섬웨어 예방’

최소한 알고 있어야 할 서버 지식

리눅스의 계정, 그룹 관한 기본지식을 적어준게 좋았다. 또 실무적으론 보통 한 서버에 개발자용 계정을 여러 개 생성해서 사용하는 경우가 드물기 때문에, 그룹 수준으로 권한 관리한 경우가 거의 없었다는 저자분의 경험담도 좋았다.
9장은 사실상 리눅스 명령어 설명 위주라 크게 생각할 부분은 없었다. 흔히 별 생각없이 사용하는 nohup이나 2>&1 이런 부분에 대해 설명해준 부분은 확실히 도움되었다.
서버가 여러대인 상황에서 미세하게 틀어진 시간때문에 결제가 실패한 경우에 대한 필자의 경험담도 흥미로웠다. 15초 내로 요청이 와야하는데 시간이 미세하게 들어져 있고, 여러 서버로 요청이 가다보니 발생한 일이라고 했는데, 확실히 그런 경우 엄청 찾기 힘들겠다고 생각했다.

모르면 답답해지는 네트워크 기초

보통 로드밸런서에서 부하를 분산하는데, DNS 서버단에서도 로드밸런서처럼 서로 다른 IP를 알려주는 방식으로 부하 분산을 한다는 부분은 재밌었다.
네트워크 부분은 개인적으론 너무 기본 설명만 하신 것 같다고 느꼈다. 그래도 키워드 받고 추가로 공부하기엔 좋아보였다.

자주 쓰는 서버 구조와 설계 패턴

11장은 MVC 패턴, 계층형 아키텍쳐, DDD, MSA, 이벤트 기반 아키텍쳐, CQRS에 대한 설명이었다. 나도 애초에 관심이 많던 부분이라 사실 추가적인 궁금증이 생긴 부분은 없었다.
확실히 DDD 책으로 유명하신 저자분이다보니, 뭔가 DDD쪽 설명이 좀 더 퀄리티가 좋은 느낌이었다 ㅋㅋ 짧게 쓰셨던데 많이 참으신게 느껴진다.
개인적으로 좋아하는 아키텍쳐라서 클린 아키텍쳐나 헥사고날 관련해 설명이 안나온건 좀 아쉬웠다.

부록 - 성능 테스트, NoSQL, 분산잠금 구현 코드 관련

성능 테스트에서 ‘에러율’ 부분을 보다가 이전 경험이 생각나서 재밌었다. 내가 만든 서비스에서 한 하위기관이 특정 API가 간혹 에러난다고 했다. 구조상 우리쪽에서 처리하는 부분도 있지만, 일정 부분은 하위 기관에 API로 쏴서 물어봐야 하는 경우(고객 확인 등)도 있었다. 내 경우 에러 발생 시 엔드포인트 단위로 쳐내서, 이분탐색 느낌으로 에러나는 범위를 좁혀나간다. 이 때 하위 기관쪽의 에러로 생각되어 그쪽 API 확인해보라고 얘기했었다. 근데 상대방이 확인도 제대로 안하고 “우리 문제 없어요” 식으로 나오길래 짜증나서 확률과 통계로 얘기해준적이 있었다. 대충 “N면체 주사위가 있는데, 이걸 10번 던졌더니 전부 동일한 수가 떴어요. 이게 확률이 어떻게 될까요?” 이런식의 얘기였고, 다행히 이과셨는지 잘 이해해주셨다.
성능 테스트쪽 관련해서, 주의 사항 써두신게 좋았다. 예를들어 Nginx에다가 DDos 막는 설정해놓고 성능 테스트하는경우 등에 대한 주의 사항이었다.
NoSQL 설명에서 제일 기억에 남는건, NoSQL이 예전엔 ‘Non-SQL’ 로 쓰였으나, 요즘은 ‘Not Only SQL’ 이란 의미로 확장됬다고 설명한 부분이다. 즉, RDBMS를 대체하는게 아니라 필요에 따라 함께 사용하도록 발전했다는 시각이었다.
DB를 이용해 분산 잠금 구현한 코드도 부록에 들어가있는데, 이전에 관련해서 노션에 적어둔 락 형태와 비교하며 읽어보니 재밌었다.

실력도 연차도 주니어지만, 그래도 프로젝트들을 몇 개 경험한 입장에서 이 책을 보다보니 내 경험과 연결해가며 읽는게 참 재밌는 시간이었다. 이후엔 개별 지식에 대해 더 공부해서 블로그 글을 써보던지 해야겠다. 어찌보면 얕고 넓은 책이지만, 고수 개발자의 경험담과 실무 얘기가 추가되니 오히려 충분히 깊은 책이 된 것 같다. 사실 일반적으로 뭘 모르는지 몰라서 끝까지 모르는거지, 키워드만 주어지면 이후론 관심의 문제이다. 이 책은 키워드를 잘 던져주는 책이다.

저작자표시 비영리 (새창열림)