배달의 민족 문제에서 효율적인 탐색 방법에 대해 질문드립니다

하늘소녀님 좋은 질문 감사합니다!! "언제 어떤 방식을 써야 하나"를 고민하는 게 바로 좋은 개발자가 되는 과정입니다1. 시간복잡도 차이 - 숫자로 보면 확실해요작성하신 방식은 order not in menus에서 리스트를 직접 탐색하는 거예요. 파이썬 내부적으로 리스트의 in 연산은 O(N)이에요. 반면 set의 in 연산은 O(1)입니다.구체적으로 보면, 메뉴가 5개이고 주문이 3개일 때 여러분 방식은 최악의 경우 5 × 3 = 15번 비교해요. set을 쓰면 5번(set 변환) + 3번(검색) = 8번이고요. 이 정도면 차이가 거의 안 느껴집니다.그런데 메뉴가 1,000개이고 주문이 100개라면? 여러분 방식은 100,000번 비교하는데, set 방식은 1,100번만 하면 돼요. 거의 100배 차이가 나죠. 메뉴 10,000개에 주문 1,000개면? 10,000,000번 vs 11,000번으로 거의 1,000배 차이입니다2. 현실적인 기준 - 이렇게 판단하세요데이터가 10개 이하면 솔직히 아무거나 써도 됩니다. 사람이 체감할 만큼의 차이가 안 나거든요. 10~100개 정도면 여러분 방식도 괜찮아요. 밀리초 단위 차이라서 대부분 상황에서 문제없어요.그런데 100개 이상부터는 set을 쓰는 게 좋아요. 특히 검색을 여러 번 반복한다면요. 1,000개 이상이면 무조건 set이나 다른 효율적인 자료구조를 써야 해요.중요한 건 "몇 번 검색하느냐"예요. 한 번만 검색한다면 리스트든 set이든 큰 차이 없어요. 그런데 반복문 안에서 계속 검색한다면, 검색 횟수만큼 시간복잡도 차이가 곱해지거든요. 이 문제처럼 주문마다 메뉴를 검색하는 상황이면 set이 훨씬 유리해요.3. 실제 서비스 코드에서는실무에서는 이렇게 판단해요. 먼저 데이터 규모의 최댓값을 봐요. "현재는 100개지만 나중에 10,000개가 될 수 있나?" 이런 질문을 던지는 거죠. 확장 가능성이 있으면 처음부터 효율적으로 짜는 게 맞습니다 (근데 또 코드 리뷰 관점에서는 확장 가능성이 없더라도 간단한 코드면 최대한 효율적인게 보기 좋습니다 ㅎㅎㅎ)그다음엔 얼마나 자주 실행되는 코드인지 봐요. 1분에 한 번 실행되는 배치 작업이면 좀 느려도 괜찮아요. 그런데 사용자가 버튼 누를 때마다 실행되는 API라면? 0.1초 차이도 중요하거든요.배달의민족 같은 실제 서비스에서 메뉴 검색은 정말 자주 일어나요. 사용자가 주문할 때마다, 장바구니 담을 때마다 검색하니까요. 그래서 처음부터 set이나 해시맵을 쓰는 게 정석이에요. 이렇게 "왜 이 방식이 더 좋은지" 고민하는 자세가 정말 훌륭해요. 계속 이런 식으로 생각하면서 코드를 짜다 보면, 어느 순간 상황에 따라 최적의 자료구조를 자연스럽게 선택하게 될 거예요!

문제에 어떤 알고리즘을 적용할지 빠르게 결정하는 팁이 있을까요?

잉여인간님 좋은 질문 감사합니다!! 실전에서 빠르게 알고리즘을 선택하는 능력은 문제를 많이 풀면서 생기는 감각이지만, 강의 자료에서 강조하는 체계적인 접근법을 바탕으로 실전 팁을 드릴게요. 1. 입력값과 제약조건이 가장 강력한 힌트예요"문제의 특성과 입력값, 출력값들을 보면서 힌트를 찾는" 게 핵심이에요. 제약조건을 보면 어떤 알고리즘을 써야 하는지 답이 나오는 경우들이 종종 있습니다입력 크기가 N ≤ 100이면 O(N³)도 괜찮아요. 완전탐색이나 브루트포스로 접근해도 충분합니다. N ≤ 1,000이면 O(N²) 정도까지는 안전해요. 버블정렬이나 선택정렬처럼 이중 반복문을 쓸 수 있죠.그런데 N ≤ 100,000이면 이야기가 달라져요. O(N log N) 이하로 풀어야 하니까 정렬이나 이분탐색을 떠올려야 해요. N ≤ 1,000,000이면 O(N) 또는 O(N log N)이 필수예요. 해시나 투 포인터 같은 선형 알고리즘을 생각해야 합니다시간 제한도 중요한데, 보통 1초에 1억 번 연산 정도를 기준으로 생각하면 돼요. 이게 바로 강의에서 배운 시간복잡도를 실전에 적용하는 방법이에요. 2. 문제를 구조화하는 훈련이 정말 중요해요4단계 접근법을 머릿속에서 빠르게 돌려보는 연습을 하는 걸 추천드립니다!먼저 자료구조를 정해요. "이 데이터는 순서가 중요한가? 중복이 있나? 빠른 검색이 필요한가?" 이런 질문을 던지면서요. 순서가 중요하고 인덱스 접근이 필요하면 배열, 빠른 검색이 필요하면 해시, 최댓값/최솟값을 계속 뽑아야 하면 힙을 떠올리는 식입니다그다음엔 패턴을 파악해요. 강의에서 말한 것처럼 "예시를 3개 정도 손으로 써보면서" 규칙성을 찾아보는 거예요. 이 과정이 정말 중요한데, 실전에서는 문제를 읽자마자 예제 입출력을 따라가면서 "아, 이런 식으로 변하는구나"를 캐치해야 해요. 3. 문제 유형별 시그널 포착하기특정 단어나 문장이 나오면 거의 자동으로 알고리즘이 연결돼야 해요. "어떤 류의 조건들에는 어떤 식의 해결법이 쓰이더라"는 경험치입니다."최단 거리", "최소 비용"이라는 단어가 나오면 BFS나 DP를 떠올려야 해요. "모든 경우의 수"나 "가능한 모든 방법"이 나오면 완전탐색이나 DFS/백트래킹이죠. "연속된 부분"이나 "구간"이 나오면 투 포인터나 슬라이딩 윈도우를 생각해야 해요."정렬된 배열에서"라는 말이 나오면 거의 무조건 이분탐색이에요. "빈도수", "등장 횟수"가 나오면 해시를 먼저 고려하고요. "최적의 선택"이나 "탐욕적으로"라는 표현이 보이면 그리디 알고리즘을 떠올려야 합니다4. 문제 분석의 실전 루틴실전에서는 이렇게 접근해보세요. 문제를 읽으면서 동시에 이 사고 과정을 거치는 거예요.먼저 1분 안에 입력 크기와 시간 제한을 확인하고 대략적인 시간복잡도 범위를 잡아요. 그다음 문제에서 요구하는 게 뭔지 한 문장으로 정리해요. "N개 원소 중 조건을 만족하는 최댓값 찾기" 이런 식으로요.그리고 예제 입출력을 직접 따라가면서 패턴을 찾아보세요. 이때 강의에서 말한 것처럼 "잘 모르겠으면 예시를 3개 정도 손으로 써보면서" 하는 게 진짜 효과적이에요. 이 과정에서 "아, 이거 정렬하면 되겠네" 또는 "아, 이거 그래프 탐색이구나" 같은 깨달음이 와요.마지막으로 비슷한 문제를 풀어본 적이 있는지 떠올려보세요. 강의 자료에서 강조했듯이 "절대적인 노출량"이 여기서 빛을 발하거든요. 같은 유형을 5-10문제 정도 풀어봤다면, 비슷한 냄새가 나는 순간 "어? 이거 저번에 풀었던 그 방식으로 하면 되겠네"가 바로 떠올라요.제일 중요한 건 조급해하지 않는 거예요. 강의에서도 말했듯이 "최소 10-20분은 문제를 자세하게 이해하고" 접근해야 해요. 처음 5분은 문제 이해와 입력 분석에, 다음 5분은 접근 방법 고민에, 그다음에 구현을 시작하는 식으로요.그리고 한 가지 접근이 막히면 다른 관점에서 봐요. "이걸 거꾸로 생각하면?" "예외 케이스부터 처리하면?" 이런 식으로 시각을 바꾸면 해결책이 보일 때가 많아요. 이렇게 고민하시는 거 보면 분명 좋은 결과 있으실 겁니다 같이 빠이팅해보시져!!

코테 준비

김마루님 정말 좋은 고민을 하고 계시네요! 많은 분들이 똑같은 고민을 하는데, 사실 이 질문 자체가 이미 학습에 대해 진지하게 생각하고 계시다는 것 같아 응원합니다!! 1. DP와 N-queen이 어려운 건 당연합니다구현 문제는 몰라도 풀 수 있지만 DP나 N-queen은 접해보지 않으면 어렵다고 느끼신 거, 정말 정상적인 반응이에요. 왜냐면 이 문제들은 특정한 사고방식과 패턴을 알아야 접근 자체가 가능한 유형이거든요.구현 문제는 문제에서 요구하는 대로 순서대로 코드로 옮기면 되는 경우가 많아요. 그런데 DP는 "이 문제를 작은 문제로 쪼갤 수 있는가", "이전에 계산한 값을 재사용할 수 있는가"라는 관점으로 문제를 바라봐야 하고, N-queen은 백트래킹이라는 완전히 다른 탐색 전략을 알아야 해요. 처음 보면 어떻게 접근해야 할지 막막한 게 당연합니다. 2. 두 접근법의 장단점 - 현실적으로 보면하루에 한 유형씩 제대로 이해하는 방법은 넓고 얕게 배우는 방식이에요. 여러 유형을 빠르게 접해볼 수 있다는 장점이 있지만, 각 유형에 대한 깊이가 부족할 수 있어요. 특히 DP처럼 여러 번 풀어봐야 패턴이 보이는 유형은 하루만 공부하고 넘어가면 나중에 다시 막막해질 가능성이 높아요.한 유형만 쭉 풀어서 마스터하는 방법은 깊고 좁게 배우는 방식이에요. 해당 유형에 대한 확실한 자신감을 얻을 수 있지만, 실제 코테에서는 여러 유형이 골고루 나오기 때문에 다른 유형을 나중에 봤을 때 시간이 부족할 수 있어요.그런데 말씀하신 것처럼 "구현, DFS, BFS, DP 유형이 코테에 많이 보인다"는 게 핵심이에요. 이 말은 이 유형들에 더 많은 시간을 투자해야 한다는 뜻이거든요. 3. 제안드리는 절충안 - 전략적으로 접근하기현실적으로 효과적인 방법을 제안드리자면, 유형의 중요도와 난이도를 고려한 전략적 접근을 추천드립니다출제 빈도가 높은 핵심 유형인 구현, DFS/BFS, DP는 집중적으로 파고드세요. 이 유형들은 3-5일 정도 시간을 투자해서 최소 10-15문제씩은 풀어보는 게 좋아요. 특히 DP는 처음엔 정말 막막하지만, 비슷한 문제를 5개 정도 풀고 나면 "아, 이런 느낌이구나"하는 순간이 와요.출제 빈도가 중간인 유형들은 기본 개념을 확실히 잡고 대표 문제 3-5개 정도 풀어보세요. 그리디, 이분탐색, 투 포인터 같은 유형들이 여기 해당해요.출제 빈도가 낮은 특수한 유형들은 나중에 시간 여유가 있을 때 보는 게 현명해요. 일단 코테를 통과하는 게 목표라면, 나올 확률이 높은 것부터 확실하게 잡는 게 전략적으로 맞거든요. 4. 구체적인 학습 루틴 제안이번 주엔 이렇게 시작해보세요. 월요일부터 수요일까지는 DFS/BFS 집중 기간으로 정하고, 하루에 2-3문제씩 푸세요. 강의 자료에서 제시한 4단계 방법을 따라가면서요. 자료구조를 정하고, 패턴을 파악하고, 코드로 구현하고, 리팩토링하는 과정이요.막히는 문제가 있으면 30분에서 1시간 정도 고민해보고, 정말 안 되면 해설을 보세요. 그런데 여기서 중요한 건, 해설을 본 후에 바로 답안을 베끼는 게 아니라 해설의 접근 방식을 이해한 다음, 화면을 끄고 처음부터 다시 구현해보는 거예요. 이 과정이 정말 중요해요.목요일부터 금요일은 DP에 집중하되, 같은 방식으로 진행하세요. DP는 처음엔 진짜 어려운데, 피보나치나 계단 오르기 같은 기본 문제부터 시작해서 점진적으로 난이도를 높여가면 돼요.주말엔 이번 주에 푼 문제들 중에서 특히 어려웠던 문제 2-3개를 다시 풀어보세요. 일주일 전에 풀었던 문제를 다시 풀어보면 "아, 이게 이렇게 풀리는 거였지"하면서 확실히 내 것이 되는 느낌을 받을 거예요.강의 자료에서 강조했던 것처럼, 결국 답은 "질 높은 양치기"예요. 단순히 문제를 많이 푸는 게 아니라, 각 문제를 풀 때 "이런 류의 조건들에는 어떤 식의 해결법이 쓰이더라"는 경험치를 쌓는 게 중요해요.교재 내에 첨부되어있는 코드 구현력을 높이는 체계적인 훈련 방법 페이지도 참고해보시면서 한번 연습해보시길 추천드리겠습니다 같이 빠이팅해보시져!!

코테 준비

김마루님 정말 좋은 고민을 하고 계시네요! 많은 분들이 똑같은 고민을 하는데, 사실 이 질문 자체가 이미 학습에 대해 진지하게 생각하고 계시다는 것 같아 응원합니다!! 1. DP와 N-queen이 어려운 건 당연합니다구현 문제는 몰라도 풀 수 있지만 DP나 N-queen은 접해보지 않으면 어렵다고 느끼신 거, 정말 정상적인 반응이에요. 왜냐면 이 문제들은 특정한 사고방식과 패턴을 알아야 접근 자체가 가능한 유형이거든요.구현 문제는 문제에서 요구하는 대로 순서대로 코드로 옮기면 되는 경우가 많아요. 그런데 DP는 "이 문제를 작은 문제로 쪼갤 수 있는가", "이전에 계산한 값을 재사용할 수 있는가"라는 관점으로 문제를 바라봐야 하고, N-queen은 백트래킹이라는 완전히 다른 탐색 전략을 알아야 해요. 처음 보면 어떻게 접근해야 할지 막막한 게 당연합니다. 2. 두 접근법의 장단점 - 현실적으로 보면하루에 한 유형씩 제대로 이해하는 방법은 넓고 얕게 배우는 방식이에요. 여러 유형을 빠르게 접해볼 수 있다는 장점이 있지만, 각 유형에 대한 깊이가 부족할 수 있어요. 특히 DP처럼 여러 번 풀어봐야 패턴이 보이는 유형은 하루만 공부하고 넘어가면 나중에 다시 막막해질 가능성이 높아요.한 유형만 쭉 풀어서 마스터하는 방법은 깊고 좁게 배우는 방식이에요. 해당 유형에 대한 확실한 자신감을 얻을 수 있지만, 실제 코테에서는 여러 유형이 골고루 나오기 때문에 다른 유형을 나중에 봤을 때 시간이 부족할 수 있어요.그런데 말씀하신 것처럼 "구현, DFS, BFS, DP 유형이 코테에 많이 보인다"는 게 핵심이에요. 이 말은 이 유형들에 더 많은 시간을 투자해야 한다는 뜻이거든요. 3. 제안드리는 절충안 - 전략적으로 접근하기현실적으로 효과적인 방법을 제안드리자면, 유형의 중요도와 난이도를 고려한 전략적 접근을 추천드립니다출제 빈도가 높은 핵심 유형인 구현, DFS/BFS, DP는 집중적으로 파고드세요. 이 유형들은 3-5일 정도 시간을 투자해서 최소 10-15문제씩은 풀어보는 게 좋아요. 특히 DP는 처음엔 정말 막막하지만, 비슷한 문제를 5개 정도 풀고 나면 "아, 이런 느낌이구나"하는 순간이 와요.출제 빈도가 중간인 유형들은 기본 개념을 확실히 잡고 대표 문제 3-5개 정도 풀어보세요. 그리디, 이분탐색, 투 포인터 같은 유형들이 여기 해당해요.출제 빈도가 낮은 특수한 유형들은 나중에 시간 여유가 있을 때 보는 게 현명해요. 일단 코테를 통과하는 게 목표라면, 나올 확률이 높은 것부터 확실하게 잡는 게 전략적으로 맞거든요. 4. 구체적인 학습 루틴 제안이번 주엔 이렇게 시작해보세요. 월요일부터 수요일까지는 DFS/BFS 집중 기간으로 정하고, 하루에 2-3문제씩 푸세요. 강의 자료에서 제시한 4단계 방법을 따라가면서요. 자료구조를 정하고, 패턴을 파악하고, 코드로 구현하고, 리팩토링하는 과정이요.막히는 문제가 있으면 30분에서 1시간 정도 고민해보고, 정말 안 되면 해설을 보세요. 그런데 여기서 중요한 건, 해설을 본 후에 바로 답안을 베끼는 게 아니라 해설의 접근 방식을 이해한 다음, 화면을 끄고 처음부터 다시 구현해보는 거예요. 이 과정이 정말 중요해요.목요일부터 금요일은 DP에 집중하되, 같은 방식으로 진행하세요. DP는 처음엔 진짜 어려운데, 피보나치나 계단 오르기 같은 기본 문제부터 시작해서 점진적으로 난이도를 높여가면 돼요.주말엔 이번 주에 푼 문제들 중에서 특히 어려웠던 문제 2-3개를 다시 풀어보세요. 일주일 전에 풀었던 문제를 다시 풀어보면 "아, 이게 이렇게 풀리는 거였지"하면서 확실히 내 것이 되는 느낌을 받을 거예요.결국 답은 "질 높은 양치기"예요. 단순히 문제를 많이 푸는 게 아니라, 각 문제를 풀 때 "이런 류의 조건들에는 어떤 식의 해결법이 쓰이더라"는 경험치를 쌓는 게 중요해요.교재 내에 첨부되어있는 코드 구현력을 높이는 체계적인 훈련 방법 페이지도 참고해보시면서 한번 연습해보시길 추천드리겠습니다 같이 빠이팅해보시져!!

코테 준비생

안녕하세요 혜나님 넘넘 좋은 질문입니다!! 기초 알고리즘이 완벽하지 않다고 느끼는 건 정말 자연스러운 과정입니다. 사실 완벽하게 이해했다고 느끼는 순간이 오기보다는, 문제를 풀면서 점점 익숙해지는 거거든요. 1. 문제 선택 전략 - 이렇게 시작해보세요강의 자료에서 추천하는 방식을 실전에 맞게 풀어드리면, 일단 개념을 배웠다고 해서 바로 어려운 문제로 가지 마세요. 대신 배운 개념을 직접 활용할 수 있는 단계별 접근을 추천드려요.먼저 각 개념별로 3-5개씩 쉬운 문제를 푸는 게 좋아요. 예를 들어 재귀를 배웠다면, 팩토리얼 같은 정말 기본적인 문제부터 시작하는 거죠. BFS를 배웠다면 가장 단순한 미로 탐색 문제부터요. 왜냐면 개념이 어떻게 실제로 쓰이는지 체감하는 게 먼저거든요.그다음엔 같은 개념을 쓰되 살짝 변형된 문제들로 넘어가세요. 이 단계에서 "아, 이런 식으로도 쓰이는구나"라는 경험치가 쌓여요. 강의 자료에서 말한 것처럼, 특정 구현보다는 "이런 류의 조건들에는 어떤 식의 해결법이 쓰이더라"는 감각을 키우는 거죠.2. 일일 루틴 - 현실적으로 지속 가능하게매일 루틴은 사람마다 다르지만, 강의에서 강조한 방식을 바탕으로 제안드리면하루에 1-2시간 정도 시간을 정해두고, 한 문제를 제대로 파고드는 게 여러 문제를 대충 푸는 것보다 낫습니다. 문제를 만났을 때 강의 자료에서 제시한 4단계 접근법을 따라가 보세요.첫째, 자료구조부터 정하는 거예요. 이 문제의 데이터는 어떤 특성이 있고, 어떤 자료구조로 저장하면 좋을지 생각해보세요. 둘째, 패턴을 파악해요. 예시를 3개 정도 손으로 써보면서 규칙성을 찾아보는 거죠. 셋째, 그 패턴을 코드로 만들어요. 일단 구현하는 게 목표니까 완벽한 코드가 아니어도 괜찮아요. 넷째, 작동하는 코드가 나왔다면 리팩토링하면서 중복을 제거하고 가독성을 높여보세요.가장 중요한 건 막혔을 때의 대처인데요. 강의 자료에 나온 것처럼 길게는 30분까지 고민해보되, 정말 안 되면 해설을 보는 게 맞아요. 이미 충분히 고민했으니까요. 그런데 해설을 볼 때가 더 중요해요. 내가 막혔던 부분이 어디였는지 기록하고, 해설에서는 어떤 식으로 풀었는지 고민한 다음, 답을 보지 않고 처음부터 다시 작성해보세요. 이 과정을 반복하면 정말 실력이 늘어요.결국 답은 "질 높은 양치기"예요. 단순히 많이 푸는 게 아니라, 위에서 말한 4단계를 거치면서 숙성된 경험치를 쌓는 거죠.처음엔 하루에 한 문제도 벅차게 느껴질 수 있어요. 그런데 계속하다 보면 비슷한 패턴의 문제들이 보이기 시작해요. "어? 이거 저번에 풀었던 그 방식이랑 비슷한데?"라는 순간이 오면, 그게 바로 경험치가 쌓인 거에요!! 교재에 있는 코드 구현력을 높이는 체계적인 훈련 방법 문서를 참고해서 복습해보시는 것도 추천드리겠습니다 같이 빠이팅해보시져!!

이력서 작성에 대한 질문

Nicou님 좋은 질문 해주셔서 감사합니다.신입 이력서 준비하시는군요. 실제 서류 통과하는 이력서들 보면서 느낀 점들 같이 정리해드릴게요.프로젝트 설명 분량은 얼마나 하는게 좋을까우선 신입 기준으로 프로젝트 하나당 3-4줄 정도가 적당합니다. 많아야 5줄까지요.핵심은 말씀해주신대로 A-B-C 패턴입니다!A(문제): 어떤 상황이었나B(해결): 뭘 어떻게 했나C(결과): 수치로 어떻게 개선됐나배운 점은 이력서에 쓰지 마세요. 면접 준비용으로만 따로 정리하세요. 왜냐하면이력서는 "결과"를 보여주는 문서배운 점은 "과정"이라 공간 낭비면접에서 물어보면 그때 답변하면 됩니다! 예시:너무 긴 설명: "상품 조회 API의 성능이 느려서 사용자 경험이 좋지 않았습니다. 이를 개선하기 위해 DB 쿼리를 분석했고, 인덱스가 없다는 것을 발견했습니다. 적절한 인덱스를 추가하여 성능을 개선했습니다. 이 과정에서 DB 최적화의 중요성을 배웠습니다."적절한 분량: "상품 조회 API 응답시간 5초 문제 발견. slow query log 분석하여 인덱스 누락 확인 후 복합 인덱스 추가. 평균 응답시간 85% 단축 (5s → 0.7s), 피크타임 서버 부하 40% 감소."3줄인데 문제-해결-결과가 다 들어있다면 좋은 이력서입니다. 2. 리팩토링 기간 구분은?하나로 묶되, 개선 과정을 강조하세요. 이렇게 구성하는 걸 추천드립니다프로젝트 제목: "재고 관리 시스템 (2024.03 - 2024.06, 이후 성능 개선 진행)"설명: "초기 구현 후 부하 테스트에서 동시성 문제 발견. 비관적 락 적용으로 재고 불일치 100% 해결. 이후 Redis 캐싱 추가로 조회 API 응답시간 70% 단축."이렇게 쓰면프로젝트를 완성한 후 개선한 것처럼 보임"문제 발견 → 해결"의 성장 스토리가 됨지속적으로 개선하는 태도가 보임 3. 신입 이력서에서 눈길 끄는 요소서류 리뷰하면서 "오, 이 사람 괜찮네"라고 생각했던 케이스들이에요문제 해결 과정이 보이는 경우가 좋습니다단순 기능 나열이 아니라 "문제 상황 → 분석 → 해결 → 결과" 흐름이 보이는 이력서. 예를 들어"게시판 CRUD 구현" (평범함) (X)"게시글 목록 조회 시 N+1 문제로 10초 소요. fetch join으로 단일 쿼리 변환하여 1.2초로 단축" (O) 기술 선택 이유가 명확한 경우도 매우 좋습니다"Redis 캐싱을 적용했습니다" (X)"조회 빈도가 높고(초당 50회) 변경이 적은 상품 데이터 특성상 Redis 캐싱 적용. TTL 5분 설정으로 DB 부하 60% 감소" (O)왜 이 기술을 썼는지, 비즈니스 맥락과 연결해서 설명하면 "생각하는 개발자"로 보입니다.지금 프로젝트 리팩토링하시는 거 정말 좋은 방향입니다. 개선 과정을 잘 기록하고, 수치로 정리해서 차별화된 이력서 만들어보세요. 화이팅해보시져!!

트랜잭션 격리성 설계도 어필포인트로 가져갈 수 있을까요?

bang2451님! 좋은 질문 해주셔서 감사합니다.이 고민 정말 많이 하시는데요 격리성 레벨 설계는 좋은 어필 포인트가 될 수 있지만, 조건부입니다.면접관이 듣고 싶은 건 이거예요"이론을 알게 됐어요" (X)"문제를 겪고, 이론으로 해결했어요" (O)예를 들어서 다음과 같습니다"트랜잭션 격리 레벨을 학습하여 READ_COMMITTED와 REPEATABLE_READ의 차이를 이해하고 적절히 적용했습니다."→ 이건 그냥 공부했다는 얘기예요. 면접관 입장에서는 "그래서 뭐?"가 나옵니다. "재고 차감 로직에서 동시 주문 시 초과 판매 발생. 트랜잭션만으로는 동시성 제어가 안 된다는 걸 확인 후, 비관적 락(@Lock(PESSIMISTIC_WRITE))으로 해결. 100건 동시 주문 테스트에서 재고 불일치 0건 달성."→ 문제 상황 + 분석 + 해결 + 수치가 다 있습니다. 즉, 실제 문제와 연결해야 합니다격리 레벨 설계가 의미있으려면 이런 실제 상황이 있어야 해요케이스 1: 재고 동시성 문제케이스 2: 포인트 차감 동시성 사용자가 동시에 여러 곳에서 포인트 사용할 때 잔액 부족인데도 차감되는 문제케이스 3: 좌석 예매 중복 같은 좌석을 여러 사람이 동시에 예매하는 문제이런 실제 겪은 문제가 있어야 격리 레벨 설계가 의미있는 어필 포인트가 됩니다. 따라서, "단순 구현 → 시스템 안정성 설계"로 성장 과정을 보여주려면 이렇게 구성해보세요.프로젝트 초기 (단순 구현) "재고 관리 기능을 @Transactional만 사용해 구현. 단일 사용자 테스트에서는 문제없이 동작."문제 발견 "부하 테스트(K6, 100명 동시 주문) 중 재고 100개 상품에 100건 주문했는데 실제 DB에는 재고 5개가 남아있는 문제 발견. 로그 분석 결과 Over-selling 발생 확인."원인 분석 "@Transactional의 격리 레벨이 READ_COMMITTED여서 다른 트랜잭션이 커밋 전 값을 읽을 수 있었음. 재고 조회와 차감 사이 타이밍에서 동시성 문제 발생."해결 "비관적 락으로 재고 조회 시점에 행 단위 락 획득하도록 변경. 동시 주문 테스트에서 재고 불일치 100% 해결."학습 및 적용 "이 경험을 바탕으로 다른 도메인(좌석 예매, 포인트 차감)에도 동시성 고려한 설계 적용. 격리 레벨과 락 전략을 비즈니스 특성에 맞게 선택하는 기준 수립." 단순히 "격리 레벨 공부했어요"는 의미 없고, "문제 겪고 해결했어요"가 진짜 어필 포인트입니다.지금 실무에서 동시성 문제를 겪고 있다면 정말 좋은 기회예요. 문제 상황 잘 기록해두고, 해결 과정을 수치와 함께 정리해보세요. 전체적으로 넘 좋은 사고의 흐름입니다 앞으로 더 잘 하실거에요!!

실무 레거시코드에 낙관적 락, 비관적 락 적용 시도

Jin K 님 좋은 질문 해주셔서 감사합니다.레거시 코드 보면서 강의 내용이랑 바로 연결해서 생각해보셨네요. 이런 고민이 진짜 중요합니다!!! 현업에서 문제 해결을 하시면 너무너무 좋은 이력이 될 것 같습니다. 1. 현재 방식의 문제점지금 코드 흐름 보면 전형적인 race condition 위험이 있어요:시간 사용자A 사용자B ---------------------------------------- t1 작업중 확인(없음) t2 작업중 확인(없음) t3 작업중 INSERT t4 작업중 INSERT (중복!) t5 신청 처리 t6 신청 처리 (동시 처리!) SELECT와 INSERT 사이에 틈이 있어서 두 사람이 동시에 "작업중 없음"을 확인하고 둘 다 INSERT할 수 있습니다.2. 비관적 락이 맞는 접근네, 맞습니다. 담당자가 접수 버튼 누르는 순간 그 신청건은 그 사람이 처리해야 하니까요. 다른 사람은 기다려야 하는 상황이죠. 충돌이 예상되고, 재시도보다는 순서대로 처리하는 게 자연스러운 케이스입니다.3. Oracle에서 구현 방법SELECT FOR UPDATE를 쓰면 됩니다: SELECT * FROM APPLICATION_TABLE WHERE APPLICATION_ID = #{applicationId} AND STATUS = 'PENDING' FOR UPDATE WAIT 3 FOR UPDATE WAIT 3이 적절할 것 같아요. 3초 기다려도 안 되면 "다른 담당자가 처리 중입니다" 메시지 보여주는 거죠.4. 작업확인용 테이블이 필요한가?신청건 자체에 락을 걸면 불필요해질 수 있어요:-- 신청건에 직접 락 SELECT * FROM APPLICATION WHERE ID = 123 AND STATUS = 'PENDING' FOR UPDATE WAIT 3; -- 처리중으로 변경 UPDATE APPLICATION SET STATUS = 'PROCESSING', PROCESSOR_ID = 'USER01' WHERE ID = 123; -- 처리 로직... COMMIT; -- 락 해제 다만 담당자가 여러 건을 동시에 처리하는 특별한 로직이 있다면 확인이 필요합니다. 공공SI 레거시는 조심스럽죠. 이렇게 접근해보세요Step 1: 상세 분석작업확인용 테이블의 정확한 용도 파악Unique 제약조건 있는지 확인실제로 동시 접수 가능성이 있는지현재 방식으로 문제 발생한 적 있는지Step 2: 개발환경에서 테스트-- 세션 1 BEGIN; SELECT * FROM APPLICATION WHERE ID = 123 FOR UPDATE WAIT 3; -- 10초 대기 COMMIT; -- 세션 2 (동시 실행) BEGIN; SELECT * FROM APPLICATION WHERE ID = 123 FOR UPDATE WAIT 3; -- 타임아웃 확인 COMMIT; Step 3: 점진적 적용새 기능에만 먼저 적용모니터링하면서 검증검증되면 기존 기능에 적용최종적으로 "공공SI 신청 접수 프로세스의 race condition 가능성 분석 및 개선. 기존 별도 테이블 기반 체크 방식을 Oracle SELECT FOR UPDATE를 활용한 DB 레벨 락으로 전환. 동시 접수 발생 건수 월 평균 X건 → 0건 감소, 트랜잭션 범위 최소화로 성능 영향 없이 데이터 정합성 확보."레거시 코드를 안전하게 개선하는 경험은 실무에서 정말 중요합니다. 조심스럽게 접근하되 차근차근 적용해보세요!

수치화 관련 질문

고양이님 좋은 질문 해주셔서 감사합니다.이 질문은 정말 많은 주니어 분들이 실제로 겪는 고민이에요. 면접관 입장도 이해가 가지만, 실무 현실도 분명히 있거든요. 하나씩 같이 파헤쳐 봅시다!실무에서는 이런 단계로 진행돼요프로젝트 초기 (MVP 단계) 이 시점에는 솔직히 말하면 "일단 동작하는 것"이 우선입니다. 왜냐하면 서비스가 실제로 유저를 받을지, 어떤 부분이 병목이 될지 아무도 모르거든요. 트래픽이 하루 100명도 안 오는데 동시 접속 1만명 대비 설계를 한다? 이건 오버 엔지니어링이죠.서비스 성장 단계 (실제 부하 발생) 유저가 늘면서 "어? 이 부분 느린데?"가 나타나기 시작합니다. 이때부터가 진짜 최적화 타이밍이에요. 실제 데이터와 트래픽 패턴을 보고 병목 지점을 찾아서 개선하는 거죠.그래서 7초 → 2초 개선이 전혀 이상한게 아닙니다. 오히려 "우리 서비스가 성장하면서 병목을 발견하고, 데이터 기반으로 개선했다"는 스토리거든요.그래서 면접관이 정말 묻고 싶은 건 이거 같습니다"문제를 발견하는 능력이 있나?""왜 이 방법을 선택했는지 논리가 있나?""다음에는 어떻게 할 건가?""왜 미리 안 했어?"가 아니라 "어떻게 생각하는 사람인가?"를 보는 거죠. 그래서 다음과 같이 흐름을 준비해가시면, 충분히 좋은 대답을 하실 수 있을 것 같습니다상황 설명 "초기에는 서비스 검증이 우선이어서 기본적인 구현에 집중했습니다. 당시 트래픽은 하루 평균 X명 수준이었고, 응답 속도도 크게 문제가 되지 않았어요."문제 발견 "그런데 X월부터 일 방문자가 Y명으로 증가하면서, 특정 API의 응답시간이 평균 7초까지 늘어나는 걸 모니터링에서 발견했습니다. 특히 오후 2-3시 피크 타임에 문제가 심각했어요."분석 과정 "slow query log를 분석해보니 WHERE 절에 사용되는 컬럼에 인덱스가 없어서 풀 테이블 스캔이 발생하고 있었습니다. 10만 건 데이터를 매번 전체 검색하고 있었던 거죠."개선 및 결과 "해당 컬럼에 인덱스를 추가하고, 실행 계획을 확인해서 index scan으로 변경됐는걸 확인했습니다. 결과적으로 평균 응답시간이 2초로 개선됐고, 피크 타임에도 안정적인 서비스가 가능해졌어요."배운 점 "이 경험을 통해 서비스 초기부터 모니터링 환경을 구축하는 게 중요하다는 걸 배웠습니다. 다음 프로젝트에서는 Spring Actuator + Prometheus를 초기부터 세팅해서 쿼리 성능을 실시간으로 추적했고, 덕분에 비슷한 이슈를 사전에 발견할 수 있었습니다."이런 식으로 답변하면 "반성하고 성장하는 개발자"로 보여요.그럼 실제 프로젝트에서 이런 경험을 쌓아보시고, 면접에서 당당하게 말할 수 있는 스토리를 만들어보세요. 좋은 질문 감사합니다!!

러버블 크레디트가 끝나면

안녕하세요 kim seungwon 님!아쉽지만 새로운 계정을 만들 경우 기존 프로젝트와 연결되지는 않습니다 ;_;해당 프로젝트를 더 이어서 발전시켜보고 싶으시면 2주차에 cursor 와 연동시켜서 작업해보시길 추천드립니다!!