개발에 관한 몇가지 생각.

1. 유지보수는 언어가 하는게 아니라 사람이 하는 겁니다. 사람이 엉터리면 아무리 좋은 걸 가져다 줘도 제대로 못쓰는 것이고, 사람이 대단하면 엉터리같은 걸 가져다 줘도 나름 잘합니다.

2. 자바 아니어도 상관없습니다. 그런 직업을 구할 수만 있다면요. 구할 수 없다면 구할 수 있는 일자리를 할 수 밖에요. 밥은 먹고 살아야하잖아요.

3. 프레임웍은 노가다를 없애기 위해 나온겁니다. 노가다가 즐겁다면 할 말 없지만, 프레임웍을 쓰더라도 직접 코딩할 일은 많지않나요?

4. 어떤 툴이나 라이브러리를 쓰던지 이론적인 기반이 없으면 결국 삽질을 하게되어있습니다. 미래에는 강력한 언어의 등장으로 프로그래밍은 쉬워지겠지만, 훨씬 더 전문적인 지식을 갖추지 않고서는 살아남기 힘들겁니다. 개발자는 그냥 코드만 적어대는 직업이 아니라 "어떤 문제를 해결하기 위한" 소프트웨어를 만드는 직업이니까요. 문제 해결하려면 아는게 있어야 해결하죠.
------------------------------
How many legs does a dog have?

자바 아니어도 상관 없을 듯 합니다. 전 개인적으로 자바를 좋아하지 않습니다만, 일단
자바는 SUN에서 밀고 있는 코딩 스타일도 있고, javadoc을 비롯한 것들 때문에 적어도
완전 엉망 수준은 아닌 경우가 많더군요. 그리고 사람들마다 코드도 덜 다른 편인 것
같습니다.

물론 꼭 자바라서 그런 건 아니지만, 다른 언어 쓰는 사람들에게 doxygen 등의 툴을
써야 한다는 것을 설득하는 것과 자바 쓰는 사람에게 javadoc을 써야 한다는 것을
설득하는 것은 난이도가 다르더군요.

블로그: http://turtleforward.blogspot.com

제 나름대로의 답변?을 달아본다면...

1. 자바 진정 유지 보수에 강하다고 생각하십니까?
유지보수에 강하고 아니고를 결정하는 것은 언어가 아니라 얼마나 clean code인가, 그리고 주변 환경적인 지원이 얼마나 좋은가인 것 같습니다. 나름 자바, 파이썬, 루비, 자바스크립트가 각각 메이저 언어로 사용되는 프로젝트를 해봤고 인수인계를 받아보기도, 해보기도, 유지보수를 떠 맡아 보기도 했는데 언어가 유지보수성에 미치는 영향은 1% 내외라고 감히 말씀드릴 수 있을 것 같습니다. 자바가 인력 풀이 넓다는 장점이 있긴 하나 상대적으로 파이썬/루비 류의 고급 언어들은 더 쉽게 배울 수 있고 자바에 비해 노이즈가 적은 코드를 만들어 내기 때문에 원 설계자의 의도에 좀더 빨리 접근할 수 있죠.

하지만, 현실을 기준으로 이야기한다면 자바, 유지 보수에 최악의 언어가 아닌가 싶습니다. 다른 사람이 만든 자바 프로젝트가 코드만 달랑 넘어왔을 때 자신 있게 유지보수할 수 있다고 말할 수 있는 자바 개발자, 과연 얼마나 될까요? 수많은 프레임웍을 뚫고 들어가서 진실-_-에 접근하기까지가 얼마나 힘든지 느끼고 있는 자바 개발자들이 이미 많을 것입니다. 뭐 하나 고치려면 대체 몇 개의 파일을 뒤적거려야 하는 건지 말이죠.

이에 비해 스파게티 코드로 엄청난 욕을 집어 먹고 있는 PHP. 가장 많은 웹 오픈소스 프로젝트를 갖고 있고 이들은 다양한 형태로 파생되고 있습니다. 유지보수에 어려운 언어라면 이게 가능한 걸까요?

파이썬의 Django와 Ruby on Rails를 꽤 많이 써봤는데 자바의 여타 프레임웍에 비해 훨씬 단순하고 유지보수하기 쉬운 것 같습니다.

결국 유지보수와 개발은 별개의 문제가 아닙니다. 개발하기 쉬운 것이 유지보수하기 쉽습니다.

2.오직 자바여야 하나?
퍼포먼스가 언어만 놓고 보면, 아니 서블릿 스펙까지만 놓고 보면 자바가 단연 좋은 것은 맞습니다. 하지만 그 무거운 프레임웍들을 얹고도 자바가 퍼포먼스가 좋은 것은 아닙니다. 스프링에 하이버네이트 쓰면서 AOP 좀 쓰기 시작하면 퍼포먼스는 Rails에 근접합니다-_- 그래서 mod_php나 mod_python에 올라간 애플리케이션들이 J2EE 컨테이너에 올라간 자바 애플리케이션의 퍼포먼스를 압도하는 경우가 왕왕 나오죠.

그리고 성능이란 게 런타임도 중요하지만 개발 타임도 중요합니다. 근데 서블릿 엔진에 프레임웍 많이 얹으면 뜨는데만 1분 가까이 걸리기도 하더군요. django는 온갖 복잡한 로직 다 얹어도 0.5초만에 리로드되는데 말입니다.

자바면 좋은 경우는 분명히 있지만 오직 자바여야 하는 이유는 없습니다.

3. 직접 코딩하는것이 나쁜가?
이건 case by case인 것 같습니다. 자바 개발자들은 어떤 상황에 부딪혔을 때 그 상황을 해결할 수 있는 라이브러리가 있는지를 찾고 설치하고 익히는데 많은 시간을 보냅니다. 그 시간에 직접 개발하면 쉽게 해버릴 수 있는 문제도 많은데 말입니다. 하지만 때때로 직접 코딩하는 것보다 갖다 쓰는 게 편할 때도 많긴 하고 이게 자바의 중요한 장점이기도 하죠.

근데 만약 그렇게 생각하는 이유가 "내부를 알아야 하기 때문에"라면 공감하기 어렵습니다. 중요한 건 고객이 원하는 것을 얼마나 빨리 해줄 수 있느냐지 얼마나 밑바닥을 잘 아느냐가 아니죠. 로우레벨을 아무리 빠삭하게 알고 있다 하더라도 고객이 원하는 것을 만들지 못한다면 개발자로서는 좋은 점수를 줄 수 없다고 봅니다.

4. 미래의 개발자의 모습은 어떨꺼라고 생각하십니까?
오히려 툴이 어느 지점까지 해결해줄 수 있는가를 알고 싶어하시는 것 같습니다. 전 툴의 미래가 밝다고 보는 편입니다. 언젠가는 정말 프로그래밍을 배우지 않은 사람도 자기가 원하는 프로그램을 스스로 만들어낼 수 있는 툴이 나올지도 모릅니다. 하지만, 가까운 미래는 아닌 것 같습니다. 그리고 그런 툴이 나오더라도 그런 툴로 개발을 하는 사람은 여전히 필요할 것이고 그것이 개발자를 코더로 만드는 상황이라기보다는 개발자가 기술적인 디테일에 신경쓰지 않고 비즈니스 로직에 집중할 수 있게 해주는 긍정적인 변화일 것이라고 봅니다. 그런 상황이 되면 컴퓨터에 대한 지식보다 시장의 요구를 이해하는 능력과 문제를 해결하는 창의력이 더 중요해지는 시대가 될 것입니다. 아니, 이미 어느 정도 그런 시대가 되어가고 있는지도 모릅니다.

제가 봐왔던 SI의 큰 프로젝트들의 방법론을 보면 완벽한 업무분석과 설계이후 치밀한 일정관리를 해야만 하는식으로 진행하는듯 한데요. 보통 UML기반의 개발방법론이라고 하는데 말만 끼워다 맞췄지 실체는 어떠하냐.. 전부 노가다 코딩들만 하고 앉아있음.(프레임워크 이해력 부족) 오전에 받은 클래스다이어그램이 내일 오후에 다시 변경되서 날라옴.(이번주는 계속 야근) 유스케이스(혹은 시나리오)는 코더들이 보는게 아닌 고객이 보는 문서.(줘봐야 아무도 그걸이해하고 코딩에 참고하지 않음) 품질관리팀이나 직무를 수행 할 사람은 커녕 코더 한사람 구하기도 어려운 자금사정. 프로젝트 종반전이되면 전부 제각각 라이브러리를 만들어서 쓰고 앉아있음. 거의 대부분 계약직들이다보니 마무리해야 할 중요한 시점에 잡코리아 들락날락.

너무 적나라하게 적은듯 하지만 겪어보면 이보다 더 심합니다. 결국 언어의 선택이 잘못되었다라고 할 순 없겠습니다. 안될수밖에 없겠죠. 저도 스트레스 참 많이 받았지만 지금은 무덤덤해졌습니다.

솔직히 자바가 유지보수에 강하다고 보지 않습니다.

SUN의 영업전략과 내,외주개발업체의 차세대 개발명분 그리고 너도나도 따라가기식이 한몪하고 있다고봅니다.