적합한 데이터 구조를 사용하는 습관: vector와 set

나는 여러 개의 특정한 데이터 여러 개를 묶어서 관리해야 할 때 습관적으로 vector를 많이 쓴다.

일단은 코딩하면서 생각 없이 vector<T>로 특정 타입의 데이터를 그룹화시키고, 점차 요구사항이 늘어남에 따라 해당 vector에 접근해서 특정 항목만추려내는 것 같은 새로운 기능을 함수로 만들어서 추가하곤 한다.

그렇게 코드를 확장해 가다가, 문득 특정 항목들을 모아 두는 vector에 값이 중복되어 들어가면 안 되는 요구사항을 발견했다. 원래부터 그런 요구사항이 있었는데, 미처 생각하지 못하고 일단 무작정 vector로 만들었다.

그래서 별 생각 없이 vector에 항목을 추가하는 함수에서 먼저 vector를 traverse하면서 새로 추가하려는 항목이 이미 존재하는지 확인하는 코드를 추가하려고 했다. loop를 만들다 보니, 갑자기 중복된 값을 허용하지 않는 데이터 구조인 set을 쓰면 굳이 이렇게 코딩할 필요가 없다는 것을 깨닫게 되었다. 즉, 데이터 구조로 set을 쓰고, 추가할 때 중복된 값의 존재 유무를 확인하는 코드를 추가할 필요도 없이 그냥 기존에 하던 대로 고민없이 추가하면 되는 것이었다.

내가 set 개념은 알고 있었지만, 평소에 잘 쓰지 않다 보니 이런 일이 생긴 것 같다. 고민 없이 너무 습관적으로 vector로 일단 만들고 보니 vector가 처리해 주지 못하는 이슈를 처리하기 위해서 나중에 코드를 추가로 보완해야 하는 상황이 된 것이다.

결국은 많이 써 보고, 조금만 더 데이터 구조의 적합성에 대한 고민을 해 본 다음에 코딩을 진행할 필요가 있다. 근본적으로 보자면, 요구사항을 도출하고 분석하는 단계에서 vector가 적합한지 미리 생각함으로써 설계 단계에서는 이미 적합한 데이터 구조가 결정되는 것이 이상적이다.

물론 내 경우에는 네트워크에서 라우팅 과정을 시뮬레이션으로 만들고, 그 과정에서 빈번하게 요구사항이 변화하기 때문에 어쩔 수는 없다. 하지만 적어도 어느 정도 선에서 완성해야 할 모양에 대한 그림이 나오면 그걸 완성하기 위한 요구사항 분석과 설계는 신경써서 함으로써, 나중에 안해도 될 코딩을 더 하거나 비효율적인 코드가 더해지는 상황은 예방하는 습관을 들여야 하겠다.