나도 배열을 쓰는 경우는 그리 많이 발생하지 않는 듯하다. 거의 대부분 List Collection 종류 사용하고, 웹 기반으로 개발할 경우 프레임워크 기반 코드들이 많은데 프레임워크에서 Collection 기반으로 구현되어 있는 경우가 많아서 Collection을 쓰는 경우가 일반적인 듯하다.

정말 배열을 썼을 경우 유용한 경우가 아니라면 Collection 사용해도 성능상에 큰 이슈는 없을 듯하다. 그리고 Collection의 경우 다양한 api도 지원하고 있어서 굳이 배열을 고집할 필요는 없지 않을까?

단, 좀 더 low api를 구현하는 경우에는 배열 사용하는 것이 좋을 듯하다. String 내부를 봐도 그렇고 JDK api 내부를 보면 수 많은 곳에서 배열을 사용하고 있는데 이미 추상화가 잘되어 있기 때문에 우리들의 경우에는 배열을 쓰지 않고도 충분히 개발이 가능한 상태이지 않을까?

나도 이와 관련해 깊이 있게 고민해 보지 않아서 명확한 답변을 주기는 힘들 듯하다. 그때 그때 상황에 맞춰 잘 쓰자라는 식상한 답변 밖에는..ㅋㅋ

@자바지기 답변감사해용 형 ㅋ 위 주제는 사실 게임 클라이언트 개발자 친구랑 얘기하다 나온 얘기였어요. return value 가 명확한 로직에 list collection이 남발되는게 너무 못마땅하다는거였죠. 클라이언트 코드에서 data에 대한 불확신이 서는건 네이밍만 잘 정의해줘도 된다면서 순수배열사용은 불필요한 라이브러리를 참조할 필요가 없고 괜히 메모리만 낭비하는걸 방지한다는거였죠. 전 상대적으로 list collection을 자주 쓰던 차라 유지보수 측면에 대해 얘기했었는데 나중에 생각해보니 서버프로그래머 입장에 있다보니 database 에서 얻어오는 n개의 row와 null 처리, 데이터 가공때문에 리스트 자료구조를 더욱 선호하게 되었고 무척 가볍고 빠른 배열은 어느샌가 사용자체를 멀리하게 된 것 같아요. 형 말씀따라 프레임워크를 쓸 경우에 list collection이 많이 쓰이는데 그 부분도 한 몫 하죠.ㅋ 저도 결국 형의 식상한 답변밖에 그 친구에게 못했었는데 한번즈음은 자기 코드를 보고 반성할 필요가 있지 않나 싶어요. 어쩌다 적다보니 스스로 질문하고 반성하고 이러고 있네요 ㅡㅡ;

@kimmunsu ^_^ 목적이 달라서 그런게 아닐까 싶습니다.

서버프로그램 하는 쪽 입장에서 보면

나중에 명확히 데이터가 증가하거나 감소할 수도 있는데

이걸 배열로 만들어놓구 System.copy 를 돌리게끔 하는 코드를 만난다면

더 속상하지 않을까엽? ^_^

사실, 어떤 것을 쓰냐는 개발환경 - 저 수준 코드 - 또는 상황에 따라 선택될 듯 합니다. 물론, 위에 유지보수도 영향을 줄 수 있습니다.

저는 개인적으로 이렇게 답변 드릴 수 있을 것 같네요. " list는 일반 쌩짜 배열 보다 더 rich interface를 제공하고 있고 내 개발환경 jdk6을 쓸 정도고 고사양 서버(저 수준 폰이 아닌. 그렇다고 이게 기준은 아니지만 ㅡ.ㅡa)에서 개발하고 있으니 생짜 배열보다는 list를 씁니다. " 라고 할 수 있을 것 같습니다.~

그리고, 배열이 필요할 때는 배열을 써요.~ 선호하지는 않구요 ^^

@nayasis @newoverguy 말씀 감사합니다. ㅎㅎ 어떤 환경에서, 어떤 상황에서의 문제해결에 따라 구분해서 사용함으로 답이 내려지네요 ㅋ 친구의 푸념을 듣는 것도 있었지만 실제 작성되는 코드들이 생짜배열을 전혀 고려하지 않고 작성되는 데에 대한 염려차원에서도 고민해본 질문이었어요. ㅋ 아주 간혹이지만... 배열에 대한 개념이 부족하여 잘못된 코드작성도 본 경우가 있기도 하구요 ㅋ. 예를 들어 data의 갯수가 증가함에 있어 패턴이 존재한다면 list 선언시에 그 패턴을 찾아내어 capacity를 패턴에 맞추어 늘려가도록 선언해야 하는게 바른 코드라고 생각하는데, 이는 배열에 대한 개념이 없을 경우에 이해시키기가 무척 힘들더군요;; 물론 저의 코드레벨 이해도가 부족하거나 이해시키는 능력의 부족도 있었겠지만요^^;