반응형
연구 코딩할 때마다 느끼는 점은, 왠지 나만 그런 것 같기도 하지만 ㅠㅠ 적합한 데이터 구조를 선택하는 것이 생각만큼 간단하지 않다는 것이다. 아니 좀더 정확하게 표현하면, 무엇이 적합한 데이터 구조인지는 뻔하지만, 그 구조가 어디서 어떻게 쓰일지를 미리 다 예측할 수 없어서 고민이다.

처음부터 몇 수 앞을 내다보고, 내가 구현한 실험환경이 어디까지 확장될 것인지를 염두에 둬서 요구사항 분석을 한다면 시행착오가 줄어들겠지만, 당장 실험결과를 빨리 그래프로 찍어내야 하는 마당에 장인정신(?)으로 이런 올라운드 플레이어 같은 제품을 천천히 제작할 수는 없는 노릇이다.

중간결론으로 얻은 것은... 결국 내 입장에서는 너무 지나치게 이런 선택의 문제가 조심스러워서 생각만 하느라 시간을 많이 허비한다는 것이다. 일단 방향이 아예 잘못되지 않았다면, 즉 통째로 뜯어고칠 위험을 최대한 줄였다면, 재빨리 구현해서 비효율적이더라도 돌아가는 코드를 먼저 얻는 것이 필요한 것 같다. 그 다음에 계속 고칠 것들은 버전업 한다는 생각으로 고쳐야 할 것 같다.

예를 들면 이렇다:

네트워크로 연결된 이웃노드의 실시간 상태정보를 저장하는 간단한 테이블 구조가 필요해서 처음에 ArrayList로 무작정 시작했다가, 중간쯤 구현해서 생각해 보니 무진장 자주 테이블 검색을 해야 되는데 그 때마다 O(N)의 검색시간을 소비하면 낭비일 것 같아서 O(1)로 줄어드는 Hashtable로 바꿨다.
그렇게 구현을 하다가, 이 테이블의 값을 실시간으로 로그 파일에 저장시키야 하는 요구사항이 추가되었다. 테이블은 매번 최신 값만 저장하고 있기 때문에 매 시간마다 테이블의 값들을 로그 파일에 한 줄씩 추가로 기록해야 하는데, 이 때 테이블에 항목이 추가된 시간 순서를 유지해야 한다.
처음에는 Hashtable에서 values() 메쏘드로 값들만 통째로 얻어 와서 나열하면 될 줄 알았는데, 생각해 보니 해쉬값에 따라 제멋대로 정렬돼서 나오기 때문에 시간 순서를 유지하지 않는 것에 잠시 멘붕...
결국 시간 순서대로 입력되는 새로운 키 값을 순서대로 저장하는 ArrayList를 하나 더 유지하고, 이걸 기준으로 Hashtable을 다시 탐색해서 파일에 기록하기로 했다.

문제는 위와 같은 테이블 구조가 한개만 있는 것이 아니라서 각 테이블 구조에 다 시간 순서의 ArrayList를 추가해야 되는 것...

처음부터 시간 순서대로 추가되는 키의 ArrayList와 Hashtable을 쌍으로 관리하도록 설계를 하고 이것을 상속받아서 다른 모든 테이블들을 구현했으면 좋았겠지만, 그러면 아직도 돌아가는 코드를 못 봤을지도 모르겠다.


마치 알파고가 바둑 게임에서 다음 수를 선택할 때, 계산할 시간이 충분한 경우와 제한적일 경우에 최적의 선택이 미묘하게 달라지는 것처럼 어쩌면 나도 경험이 부족하고 생각할 시간도 제한적인 상황에서 최선의 코딩 방향을 선택하는 것에 어쩔 수 없이 차이가 있음을 인정해야 할 것 같다.

이렇게 배워 가면서 점차 더 빠른 시간 안에 더 효율적으로 돌아가는 프로그램을 개발할 수 있게 되겠지. 꾸준히 연습하자.

반응형
블로그 이미지

Bryan_

,