스터디 진행 일시
날짜 : 8월 8일 (금요일) 시간 : 오후 6시 ~ 9시 (3시간) 장소 : 강남 (오프라인)


🔧 금주 스터디 일정
  • 아이스 브레이킹
    • 간단한 자기소개
  • 슬랙 사용과 스터디 소통 문화 소개
  • 개발자에게 지표란 ?
    • 자신의 직무에서 어떤것이 성과 지표가 될수있을지 논의
  • 동시성 에러 해소 (준호님 세미나)


🌱 아이스 브레이킹
  • 새로운 스터디원 두 분이 합류하셨습니다.
    • 앱 개발자 한 분과 풀스택 개발자 한 분으로, 서로 간단히 자기소개를 나누고 스터디 문화를 소개하는 시간을 가졌습니다.
  • 스터디 소통 문화
    • 함께 공부하기 위해 모인 만큼, 서로 예의를 지키고 긍정적인 피드백을 지향합니다.
    • 의견은 자유롭게 나누되, 서로의 생각을 존중하는 분위기를 유지합니다.


🌻 개발자에게 지표란 ?
  • 개발자는 언제부터 ‘지표’를 의식하기 시작할까?
    • 보통 처음은 경력 1~3년 차, 이직을 준비하며 이력서에 자신의 업무 성과를 수치로 표현해야 할 때다.
    • 다른 경우는 남에게 무언가를 설명해야 할 때다. 예를 들어, “이 기능이 얼마나 개선됐는지”를 설명할 때처럼 성과를 구체적인 지표로 보여줘야 한다.
  • 결국 ‘지표’라는 것은 타인에게 내 성과를 전달하기 위한 것이라고 볼 수 있다.
  • 그렇다면 내 직무에서 어떤 것이 성과 지표가 될 수 있을까?
    • 장애 대응 시간 : 장애 발생 시 최초 인지부터 해결까지 걸린 평균 시간
    • 장애 발생 횟수 : 장애 건수를 월 단위 또는 분기 단위로 집계
    • 다운타임 : 시스템이 사용 불가능했던 총 시간
    • 테스트 커버리지 : 코드 중 테스트가 작성된 비율
  • 개발자 지표만 단순히 본다면 위 항목들이 맞지만, 사실 이외에도 더 다양한 지표가 있을 수 있다.
    • 배포 주기 : 배포 빈도가 짧을수록 기능 릴리즈와 버그 수정이 빠름
    • 긴급 장애 해결 시간 : 심각한 장애 발생 시 복구까지 걸린 시간
    • AWS와 같은 클라우드 비용 절감 : AWS, GCP, Azure 등 인프라 운영 비용 절감율
  • 1~3년 차 개발자에게는 단순히 개발 성과에 관한 지표만 보더라도 충분할 수 있다. 그러나 4년차 이상이 되면 배포 주기나 긴급 장애 해결 시간과 같이 서비스 안정성과 운영 효율을 반영하는 지표의 중요성이 커진다.
    • 이 시기부터는 단순히 기능을 만드는 것을 넘어서 서비스 품질 유지나 개선과 운영 효율성에 기여하는 능력이 경력 평가에 핵심이 되기 때문이다.
  • 그럼 이직할 때, 위 항목에서 면접관이 가장 중요하게 보는 지표는 무엇일까?
    • 그건 회사 by 회사겠지만, 스타트업의 경우라면 운영 지표나 매출에 얼마나 기여했는가를 더 중요하게 볼 수 있다.


🌈 시니어 개발자로 성장한다는 것
  • 요즘은 AI 기술이 빠르게 발전하면서, 백엔드 개발자가 프론트엔드 개발을 어느 정도 구현할 수 있고, 그 반대도 가능해졌다. 하지만 고연차가 될수록 단순히 기술 스택을 넓히는 것만으로는 차별화가 어렵다.
  • 회사 입장에서 시니어 개발자를 채용하는 것은 높은 연봉이라는 비용 부담이 크기 때문에, 그만큼 채용의 기대치도 높고 검증도 까다롭다.
  • 이제는 단순히 “개발을 잘하는 사람”이 아니라, 다음과 같은 역량이 더욱 중요하다.
    • 도메인에 대한 깊은 이해
      • 해당 산업, 서비스, 비즈니스 로직에 대한 폭넓고 깊은 이해를 통해 기술적 의사결정의 정확도를 높인다.
    • 인력 관리와 팀 리딩
      • 주니어 개발자 육성, 코드 리뷰, 업무 분배, 일정 조율 등 팀 전체 생산성을 높이는 리더십이 필요하다.


🔥 동시성 에러 해소

🙌 준호님의 세미나 🙌

아래와 같이 문제가 동시성 문제가 발생했을 때, 어떻게 해결할 수 있을까?


동시성-에러해소

유저가 화면에서 버튼을 한 번 클릭했지만, 동시에 API 2개가 호출되었다. 이 API 1과 API 2는 서로 다른 작업을 수행하지만, 공통적으로 A라는 작업을 먼저 실행한다.

A 작업: DB에서 1~30개의 row를 삭제  
A 작업 이후: API 1은 B 작업, API 2는 C 작업을 각각 진행

이때 동시성 문제가 발생한다. 왜냐하면 동시에 호출된 API가 동일한 1~30개의 데이터를 동시에 삭제하려고 시도하기 때문이다.


[문제] API 1과 API 2의 실행 결과는 ?

  1. 둘 중 하나는 성공하고 하나는 실패한다.
  2. 둘 다 실패한다.

정답은 1번, 둘 중 하나는 실패하고 하나는 성공한다.


[문제] 이 동시성 문제를 어떻게 해결할 수 있을까?
추가 조건 - A 작업은 개발 시간 상, 당장 분리할 수 없다고 가정한다.

이 경우 단순히 @Retryable 를 적용하여 재시도를 통해 해결할 수 있다. 하지만, 그렇다고 @Retryable 이 항상 좋은 선택은 아니다.


예를 들어 재시도 횟수를 3회로 설정했다면 다음과 같은 문제가 발생할 수 있다.

  • 재시도 할 때마다, 동일한 오류 로그가 여러 번 발생
  • 불필요하게 많은 로그는 디버깅을 어렵게 만들고 저장공간 낭비로 이어짐