DSA에 과도하게 몰입하기보다 핵심 개념과 시간 복잡도를 이해하고, 실제 현장에서 큰 가치를 주는 테스트 작성 능력을 키우라고 조언한다. 무엇을 배우고 무엇은 굳이 배우지 않아도 되는지, 그리고 테스트가 커리어와 면접에서 왜 차별화되는지 설명한다.
사람들은 DSA를 배우는 데 시간을 덜 쓰고, 테스트를 배우는 데 더 많이 써야 한다.
나는 새로 배우는 사람들이 “DSA”에 대해 자주 묻는 걸 본다. 자료구조와 알고리즘은 물론 중요하다. 넓게 보자면 모든 프로그램을 이루는 두 가지 재료니까. 하지만 내 생각에, “DSA”를 하나의 추상적 학문 분야로 과도하게 강조하는 경향이 있다.
사람들이 DSA에 집중하는 이유는 이해한다. 배울 거리가 구체적이고, 그걸로 당신을 시험하는 웹사이트들이 있고, 무엇보다 취업 면접에서 DSA 코딩 문제가 자주 등장하기 때문이다.
다른 의견으로 넘어가기 전에, 취업에 도움이 되는 일이라면 무엇이든 좋은 일이라는 점은 분명히 하자. 만약 leetcode를 갈아 넣는 게 자리를 얻는 데 도움이 된다면, 그렇게 하라.
하지만 나는 신입 개발자를 뽑는 회사들이 연결 리스트를 뒤집거나 트리를 균형 잡으라고 묻지 않기를 바란다. 미리 암기해둘 수 있는 기법을 묻는 건 당신이 실제로 얼마나 잘 일할 수 있는지를 알려주지 못한다. 그런 면접의 표면적인 목적은 당신이 해법을 얼마나 잘 찾아가는지를 보려는 것이고, 그런 경우 암기는 오히려 취지를 무너뜨린다.
새로운 학습자들이 DSA에 대해 이해하지 못하는 점은, 실제 소프트웨어 엔지니어링에서는 “DSA”가 가르치는 류의 알고리즘을 구현할 일이 거의 없다는 것이다. 물론 이런 퍼즐 몇 개를 풀어보고 해결 방식을 보는 건 도움이 될 수 있다. 하지만 실제 코드를 쓰는 일은 그런 종류의 코드를 쓰는 일이 아니다.
현장에서 일하는 소프트웨어 엔지니어가 자료구조와 알고리즘에 관해 알아야 할 것은 다음과 같다:
다음은 배우지 않아도 되는 것들이다:
물론 어떤 엔지니어들은 해시 테이블이나 정렬 알고리즘 같은 것을 직접 구현해야 한다. 우리는 그런 엔지니어들을 사랑한다. 그들이 선반에서 바로 꺼내 쓸 수 있는 라이브러리를 써주기 때문에 우리 스스로 구현하지 않아도 된다.
가끔은 내가 “알고리즘” 같다고 느껴지는 것을 구현한 적도 있다(예: 부정확한 부동소수 찾기). 하지만 그건 내 데이터에 대한 다른 관점을 고려하고, 시간 복잡도를 살펴보고, 제곱 시간(O(n^2)) 동작을 피하기 위해 연산의 위치를 바꿔보는 문제에 더 가까웠다. 교과서를 펼쳐서 내 문제를 해결해 줄 유명한 알고리즘을 찾는 일이 아니었다.
다시 말하지만: 취업에 도움이 된다면 DSA를 깊이 파고들어라. 다만 일을 하면서 그걸 거의 쓰지 않더라도 실망하지는 마라.
커리어를 준비하고, 면접에서도 돋보이고 싶다면, 테스트를 쓰는 법을 배워라:
DSA는 줄이고, 테스트는 늘려라.
