DSA가 당신을 더 나은 엔지니어로 만들지는 않는다 (혼자서는)

Source: Dev.to

Introduction

면접실에 있는 코끼리 이야기를 해봅시다.

DSA는 하나의 스킬입니다. 어느새 알고리즘 문제를 푸는 것이 도덕적 과시가 되었습니다: “나는 LeetCode 문제를 487개 풀었어.” 멋지죠. 아침 식사 전에 DSA를 풀고, 초록 체크표시 스크린샷을 트윗하고, 시간 복잡도를 점성술처럼 여기는 사람도 있습니다 (“오늘은 O(n log n) 에너지”).

진정하세요. 아무도 프로덕션에서 새벽 2시마다 배열을 손으로 정렬하라고 요구하지 않습니다.

Reality at Work

직장에서 주로 하는 일은:

• 기존 코드 읽기
• 오프‑바이‑원 버그 수정
• 변수 이름 바꾸기
• 어제는 왜 동작했는지 디버깅하기

잘 듣는 말은 거의 없습니다:

“API가 타임아웃되기 전에 가장 긴 팰린드롬 부분수열을 빨리 찾아줘.”

What Companies Want

• 문제 해결자 – 제약 조건을 생각해 내는 능력을 중시합니다.
• 실용적인 작업 – “다시 보지 않을 이진 트리를 뒤집어 주세요.”

면접을 통과하고, 첫날의 업무는 다음과 같이 간단할 수 있습니다:

“버튼 하나 추가해줄 수 있나요?”

When DSA Is Useful

• 성능이 중요한 시스템 작업
• 대규모 데이터 처리
• 제약 하에서 명확하게 사고하기
• 논리적 사고 훈련

이것들은 “FAANG이 요구한다”, “트위터/링크드인에선 모두 한다”, “언젠가 DP가 필요할지도 모른다(당신은 안 필요함)”와 같은 이유가 아니라, 타당한 이유입니다.

Analogy: DSA Is Like the Gym

좋은 점:

• 근력을 키워줍니다
• 사고력을 향상시킵니다
• 자신감을 높여줍니다

나쁜 점:

• 낯선 사람과 반복 횟수를 비교하기
• 그것을 전부인격으로 만들기
• 하지 않는 사람을 판단하기

조금씩 하세요. DSA가 나쁜 아키텍처를 고쳐주지는 않으며, 하나의 도구일 뿐입니다. 개념을 배우되, 코드베이스는 여러분의 가장 긴 연속 기록보다 가독성을 더 중요하게 생각한다는 점을 기억하세요.