[JAVA] 자바 개발자로서 알아야 하는 것들[JAVA] 자바 개발자로서 알아야 하는 것들

Posted at 2020. 2. 18. 16:06 | Posted in JAVA
반응형




발췌 : 자바의 神 Vol.2 주요 API 응용편






Group01. 자바 언어로 개발하기 위해서 알아야 하는 것들





#01. 알고리즘



동일한 기능을 수행하는데, 어떤 프로그램은 1분이 걸리고, 어뜬 프로그램은 1초가 걸린다면 어떤 프로그램을 선택할 것인가?


당연히 후자를 선택할 것이다.


개발자로 먹고 살 계획이라면, 보다 효율적인 프로그램을 작성할 수 있는 알고리즘에 대한 공부를 반드시 해야 한다.





#02. 멀티쓰레드 관련 패턴들



서버가 최고의 성능을 발휘하도록 하기 위해서는 멀티쓰레드를 처리하는 각종 패턴들에 대한 공부를 하는것이 좋다.


요즘은 PC나 노트북도 멀티코어 기반으로 되어 있다.


그리고, 웹 기반으로 개발하게 될 경우에 멀티 쓰레드 상황에서 어떻게 처리해야 할지에 대한 개념을 잡고 있으면 도움이 된다.


게다가 정해진 시간에 보다 빠르고 많은 처리를 해야 한다면 하나의 쓰레드로 처리하는것보다


멀티 쓰레드로 처리하는 것이 훨씬 효율적이다.





#03. NIO 및 네트워킹에 대한 보다 자세한 내용



대부분 웹 기반 개발자들은 NIO나 네트워킹에 대해서 잘 알 필요가 없다.


왜냐하면 WAS가 다 알아서 대부분을 처리해 주기 때문이다.


하지만, 언제까지 웹 기반 프로그램을 작성한다는 보장이 없다.


어느 날 갑자기 서버간 통신을 하는 프로그램도 작성을 해야 할 수도 있고,


NIO 기반의 프로그램이나 네트워킹 프로그램을 분석해야 할 필요가 생길 수도 있다.


이때 이와 관련된 기반 지식을 갖고 있으면 많은 도움이 된다.





#04. 자바 메모리 관리와 가비지 컬렉터 ( Garbage Collector )



C 기반으로 개발하는 개발자와 JAVA 기반으로 개발하는 개발자의 가장 큰 차이가


메모리가 어떻게 할당되고 해제되는지를 아는지의 여부다.


자바 개발자는 메모리를 건드릴 필요가 없다.


하지만, 메모리가 어떻게 할당되고, 해제되는지, 어디에 생성되는지에 대해서는 알아 두면 아주 많은 도움이 된다.


게다가, 내가 만든 프로그램에서 메모리를 얼마나 임시로 생성했던가 해제하는지에 대한 것을 알고


개발하는 것과 모르고 개발하는 것은 차이가 있다.


따라서, 자바의 메모리 영역에는 어떤 것들이 있는지,


GC 방식에는 어떤 것들이 있는지를 알아두면 큰 도움이 된다.





#05. 리팩토링



메소드 하나의 최대 크기는 65Kbytes다.


C나 Cbobl 기반으로 개발을 많이 하신분들, 혹은 개발을 많이 안 해본 분들은 하나의 메소드가 최대 크기를 넘어가는 경우가 있다.


이렇게까지 심각한 메소드는 아니더라도, 코드를 작성하다 보면,


중복되는 부분이 반드시 발생하고, 나중에 유지보수성과 코드이 가독성을 위해서 메소드 및 클래스를 정제할 필요가 있다.


이러한 작업을 리팩토링이라고 한다.





#06. Eclipse나 IntelliJ와 같은 IDE 사용법



이클립스나 인텔리제이 같은 개발 툴( IDE )을 잘 다루는 것은 OS를 잘 다루는 것만큼 중요하다.


아무리 1억원 짜리 툴을 구매해서 사용한다고 하더라도, 제대로 사용하지 않으면 몇백 만원 짜리 툴을 사용하는 것보다 못하다.


이클립스는 무료로 제공되는 툴이며, 몇년 사이에 자바 개발자들에게 없으면 안 되는 툴로 자리매김 해왔다.


인텔리제의 경우 무료 버전이 커뮤니티 에디션과 유료버전인 얼티밋 에디션으로 나뉜다.

( 커뮤니티 에디션은 아파치 라이선스 2.0을 따른느 오픈소스로 배포되며 웹 개발을 비롯한 여러 기능들이 제한된다. )


얼티밋 기준 무료는 아니지만, 2017년 기준으로 46%로 가장 많이 사랑받는 개발툴이다.



개발툴의 기본적인 기능과 추가적인 플러그인을 통해서 개발하는 방법을 익히는 것은 매우 중요하며,


단축키를 외어 두는 것도 많은 도움이 된다.





#07. 적어도 한 가지 이상의 방법론



이 세상에는 방법론이 엄처나게 많다.


개발자 중에서는 방법으론을 싫어하는 분들도 있지만, 적어도 한 가지 이상의 방법론은 몸에 익혀두는 것이 좋다.


이렇게 익힌 방법론은 반드시 IT개발이 아닌 다른 분야에서도 활용할 수 있기 때문이다.



방법론은 개발할 때 개발자를 괴롭히고, 힘들게 하고, 문서( 산출물 )를 만들기 위한 것은 아니다.


프로그램이 제대로 작성될 수 있도록 하기위한 하나의 도구이다.





#08. JAVA 기반의 UI 기술



자바 기반의 UI 기술도 종류가 매우 많다. 웹 페이지도 어떻게 보면 UI 기반이다.


지금은 많이 사용하지는 않지만, Swing 기반의 UI를 배워 보는 것도 나쁘진 않다.

( IntelliJ IDEA는 자바와 스윙을 이용해서 제작되었다. )


하지만, UI가 너무 우울하다.


그래서, 이클립스 UI 기반이 되는 SWT라는 것이 있다.


 SWT는 Standard Widget Toolkit의 약자이며, 화면은 해당 OS의 기본 UI를 따른다.


관심이 있는 분들은 한번 사용해 보기 바란다.


자바 기반으로 환경을 만드는 기술은 한가지 정도 알아두는 것이 좋다.





#09. UML과 같은 모델링 언어



방법론과 일맥상통하는 말이지만, UML과 같은 모델링 언어를 알아두는 것도 기본이다.


UML은 Unified Modeling Language의 약자로 방법론이 아닌 모델링 언어다.


시대가 바뀌면서 UML이 많이 바뀌긴 했지만, UML의 뿌리는 바뀌지 않았다.


적어도 UML에서 이야기하는 


클래스( Class ) 다이어그램, 시퀀스( Sequence ) 다이어그램, 유즈 케이스( Use Case ) 다이어그램, 스테이트( State ) 다이어그램은


그릴 줄도 알고, 읽을 줄도 알아야만 한다. 그렇지 않으면, 개발을 못할 수도 있다.


왜냐하면, 선배들이 그려준 다이어그램을 보고 프로그램을 작성해야 하는데, 다이어그램을 읽지도 못하면 프로그램 개발도 못하기 때문이다.


그렇지만 각 다이어 그램을 읽는 방법은 사실 10분에서 한시간 정도면 금방 배울 수 있다.














Group02. 웹 개발자라면 알아야 하는 것들




#01. XML



대부분의 WAS나 프레임웍에서 사용하는 설정은 XML 파일이나 키 ~ 값 쌍으로 이루어진 properties 파일로 이루어진다.


간혹 어노테이션을 사용하는 경우도 있지만, 대부분 XML이나 properties 파일이 일반적이다.


개발을 하다보면 XML을 읽고, 활용하고, 심지어는 XML의 표준을 정의해야 하는 경우가 발생할 수 있다

( 분명히 이 경우 중 하나는 발생한다. )


게다가 안드로이드는 UI 레이아웃까지 XML로 선언하도록 되어 있다.


XML에 대해서 알지 못하면 개발을 모른다고 해도 과언이 아니다.


XML을 알게 되면 HTML도 같이 공부하면 좋다.





#02. JSP, Servlet에 대한 보다 자세한 내용



이제는 JSP와 Servlet으로 생짜배기 개발하는 서비스는 거의 없다.


이것 저것 덕지덕지 붙어 있는 생전 들어 보지도 못한 프레임웍 기반으로 개발하는 경우도 있고,


"스프링"이라는 프레임웍 기반에서 개발하는 경우도 많다.


그리고, 벤더에서 서버 및 툴을 팔기 위해서 광고하는 SOA 기반으로 개발하는 분들도 있을 것이다.


그런데, 이러한 대부분의 프레임웍에 대해서 이야기를 하려면 자바 기반의 웹 페에지를 구성하기 위한 기초인


JSP와 Servlet에 대해서 알아야만 한다.


JSP와 Servlet의 원리를 모르고 프레임웍에서 제공하는 기능을 사용하여 찍어내듯이 웹 페이지를 개발하면 안된다.





#03. 디자인 패턴



어떤 언어를 개발하더라도 디자인 패턴은 알아야 한다.


예를 들어 어떤 클래스는 해당 JVM에서 하나의 객체만 존재해야 한다면 생성자를 아무나 막 호출하게 해서는 안된다.


이러한 상황에서 사용하는 디자인 패턴은 싱글톤( singleton ) 이라고 한다.


그래서, 선배 개발자들에게 "싱글톤으로 개발했습니다." 라고 이야기만 하면 되는 것을


매우 복잡하게 설명하는 경우가 발생할 수가 있다.


이와 같이 디자인 패턴이라는 것은 하나의 클래스, 혹은 여러 클래스가 어떤 기능을 수행할 때


공통적인 특징을 가지게 되고, 유일한 이름을 갖도록 정의해 놓은 것이다.


디자인 패턴을 알아야 선배 개발자와 커뮤니케이션 하기에도 좋으니 꼭 공부해 두어야 한다.





#04. JDBC에 대한 보다 자세한 내용



아직까지는 데이터를 저장할 때에는 대부분 DB를 사용한다.


자바에서 DB에 데이터를 저장하기 위해서는 JDBC를 사용한다.


요즈음 iBais, MyBatis, Hibernate 등의 데이터 저장을 위한 프레임웍을 많이 사용하지만,


이러한 프레임으웍의 기반은 바로 JDBC이다.


데이터를 어떻게 다루는지 제대로 알기 위해서는 JDBC에 대해서 알고 있어야만 한다.





#05. Spring 프레임웍을 비롯한 각종 프레임웍



자바가 다른 언어와 크게 다른 점은 프레임웍이 지속적으로 발전하고 있다는 점이다.


다른 언어오 프레임웍이 있긴 하지만, 그 양이 자바에 비하면 그리 많지 않다.


특히 자바 기반의 오픈 소스는 프레임웍을 만들고, 공유하고, 피드백을 받아 보완되는 구조로 계속 발전하고 있다.


그 중에서 2010년대 초반에 Spring 프레임웍이 아주 강세다.



그 위에도 수많은 프레임웍이 존재하는데, 사용하던 것만 반복적으로 사용하려고 하지 말고


새로운 것이 나오면 사용해보고, 기존 것과 비교해서 어떤 장단점이 있는지를 파악하는 것은 매우 중요하다.





#06. JUnit 테스트 스크립트 작성 방법과 사용법



Junit이라는 테스트 프레임웍이 있다.


간단하게 말하면, 작성한 메소드를 수행하여 예외나 에러가 발생하는지를 확인하고 원하는 값이 리턴되는지를 확인하는 것을 쉽게 도와 주는 것이다.


예로 main( ) 메소드로 메소드가 제대로 수행되는지를 확인하는 것은 그리 좋은 방법이 아니다.


하지만, 자바라는 언어를 모르는 분들에게 JUnit 테스트 코드를 작성하여 메소드 수행 결과를 확인하라고 가리키는 것은


매우 어렵기 때문에 일반적으로 사용하는 main( ) 메소드를 사용하는 방법을 채택했다.



메소드 하나를 테스트할 때에는 JUnit으로 하나 main( ) 메소드를 사용하여 동일하게 1초가 소요될 수 있지만,


main( ) 메소드로 테스트를 수행하면서 나온 출력 결과를 일일이 눈으로 확인하는 것에는 한계가 있다.


그리고, 테스를 수행해야 하는 메소드가 많으면 많을 수록 JUnit로 테스트 하는것이 빛을 발한다.


따라서, 자바 개발자라면 JUnit을 꼭 배우고 알아두는 것이 좋다.





#07. GIT, Subversion, CVS 등 형상관리 툴 사용법



처음에 프로그램을 작성할 때에는 본인 PC에서만 작업하면 된다.


하지만, 보통 개발을 할 때에는 혼자 개발하지 않는다.


따라서, 각종 형상관리 툴을 사용하여 여러 사람과 협업하여 개발하는 방법을 알아야만 한다.


요즘 많이 사용하는 형상관리 툴은 GIT, Subversion, CVS등의 무료 툴을 많이 사용한다.





#08. Ant, Maven과 같은 빌드 툴 사용법



Ant는 XML기반으로 여러 작업을 선언하고, 실행할 수 있는 빌드 툴이다.


아주 간단한 예로, 이클립스를 사용하지 않을 때에는 javac로 컴파일하고 java로 실행하는


두 번의 단계를 거쳐야 하니만, Ant의 경우 한번의 명령 실행으로 이 두가지 작업을 실행 할 수 있다.


만일 해야한는 작업이 10개라도 Ant를 사용하면 한번의 명령으로 실행할 수 있다.



Maven은 Ant의 대안으로 만들어 졌고, 2010년대 이후 Ant보다는 Maven을 통합 빌드 툴로 더 많이 사용한다.


메이븐은 내가 사용할 라이브러리뿐만 아니라 해당 라이브러리가 작동하는데


필요한 다른 라이브러리까지 관리하여 네트워크를 통해 자동으로 다운받아주며,


필요한 라이브러리를 특정 문서( pom.xml )에 정의해 놓으면 네트워크를 통해서 라이브러리들을 자동으로 다운받아 준다.





#09. Hudson( Jenkins )과 같은 통합 빌드 툴 사용법



방금 살펴본 빌드 툴을 보다 쉽게 사용하는 방법이 Hudson과 같은 통합 빌드 툴이다.


영어로는 보통 CI( Continuous Integration )라고도 부른다.


이러한 통합 빌드 툴은 빌드만 자동으로 하는 것이 아니라.


각종 프레임웍과 연계하여 테스트, 커버리지 분석, 부하 측정 등 대부분의 작업을 자동으로 할 수 있다.


참고로 Hudson의 미래는 어떻게 될지 모르며, 이 툴을 만든 개발자가 나와서 만든 Jenkins라는 툴을 사용할 것을 권장한다.





#10. Apache와 같은 오픈 소스 프로젝트에 대한 지속적인 관심



www.apache.org라는 사이트를 접속해 보면 수 많은 오픈 소스 프로젝트들이 있는 것을 확인할 수 있다.


보통 개발자들은 이 오픈 소스의 사용법을 익히는 데에서 끝난다.


하지만, 한걸음 나아가서 오픈 소스의 코드들을 보라,


세계에서 내로라하는 똑똑한 개발자들이 만든 코드를 보면 분명 여러분들의 개발 능력이 향상도리 것이다.



참고로 앞서 설명한 Spring 프레임웍도 오픈 소스로 되어 있으며,


이 프레임웍의 메인 개발자는 스프링 컨퍼런스에서 최고 인기를 누린다고 한다.


여하튼 이러한 사람들이 만들어 놓은 코드들을 보면 많은 감탄을 할 것이다.



그리고 다른 사람이 작성한 코드를 보는 것만으로 만족하지 못하는 사람들은 직접


소스 커미터( Committer )가 되어 보기 바란다.

( 물론 영어는 기본이다. )



추가로, 예전에 어떤 식스템을 담당한다는 사람이 "오픈 소스를 사용하는 사람이 개발자라고 할 수 있습니까?"라고 해서


모 사이트에서 논란이 되었던 적이 있다. 


그 사람은 아마도 인터넷에 떠 도는 코드 템플릿과 오픈 소스를 구분하지 못하는 사람으로 보인다.


만약 여러분들이 이미 여러 분야에서 사용되고 있는 오픈 소르를 사용한다고 뭐라고 하는 사람이 있다면 그냥 쓱 한번 웃어주고 넘어가기 바란다.


우리나라 금융 및 공공기관에서 Apache의 자카르타 프로젝트에서 만들어진 Tomcat이라는 WAS를 사용하는 것을 그리 많이 보지 못했을 것이다.


하지만, 우리나라를 비롯한 전 세계의 유명 사이트들 중 자바를 사용하는 사이트는 대부분 Tomcat을 사용한다.


Tomcat 때문에, Tomcat에 문제가 있어 잘못된 사이트는 한 번도 보질 못했다.





#11. DB ( Data Base )



JDBC에 대해서 기술한 것처럼 아직까지는 DB가 대세다.


특히 금융권이나 공공기관에서 개발을 한다면 필수로 알아야만 한다.


SQL, Index 정도는 알아야만 한다.





#12. NoSQL DB



2010년대 초반에는 TV 광고에까지 클라우드라는 단어가 매우 많이 등장했다.


단순히 사용자 PC를 활용한 클라우드 서비스를 이야기하는것이 아니라,


자체 보유한 서버를 활용하는 클라우드를 이야기 하는 것이다.


수많은 사용자의 요청과 데이터를 처리하기 위해서는 클라우드 기반의 서비스가 필요한 것은 맞다.


하지만, 우리나라 만을 대상으로 한 서비스를 할 경우에는 거창하게 클라우드를 내세워서 할 만한 것은 그리 많지 않다.


이러한 클라우드 서비스의 밑 바탕에는 수많은 데이터를 저장할 수 있는 NoSQL DB와 매우 많은기술들이 필요하다.



NoSQL DB라는 것은 데이털르 저장할 수 있는 한계를 벗어나고, 수 많은 사용자의 데이터를 저장하는 저장소를 말한다.


NoSQL은 Not Only SQL이라는 말이며, SQL을 사용하지 않는다는 말은 아니다.


NoSQL에 대표적인 주자로는 Mongo DB, Redis, HBase, Memcached, CouchBase 등이 있다.















Group03. 그 외에 알아두면 좋은것들





#01. 파이썬( Python )과 같은 스크립트 언어



세상에는 만많은 스크립트 언어들이 존재한다.


그 중에서 많이 사용하는 것은 Python, Perl 등이 있다.


그리고, 이 중에서도 파이썬( Python )이 쉽고, 크게 떠오르고 있다.


간단하게 데이터를 처리할 일이 있을 경우 굳이 이클립스, 인텔리제이를 띄워서 자바 애플리케이션을 만드는 것보다는


편하기 때문에 알아두면 도움이 많이된다.





#02. JVM( Java Virtual Machine ) 위에서 사용할 수 있는 언어



JVM을 띄워서 사용하는 언어들이 매우 많다.


Python을 JVM 위에서 수행하는 Jython같은 것과,


안드로이드 개발에 있어 JAVA를 대체하고 있는 Kotlin과 같은 것들이 존재한다.


이러한 언어의 특징은 해당 언어가 JVM 위에서 돌아간다는 점이다.


이러한 언어가 탄생한 이유는 메모리 관리는 잘 만들어진 JVM에 맡기고,


주요 기능들을 편리하게 개발할 수 있도록 하기 위함이다.


이렇게 되면 자바보다 간단하고, 간편한 언어를 사용할 수 있다는 장점이 생긴다.


특히나 안드로이드 진영에서 Kotlin을 메인으로 JAVA의 완전한 대체가 이루어지고 있다.




#03. 모바일 앱 개발



2010년 초중반 서점에는 iOS와 Android와 관련 서적만 팔렸다고 해도 관언이 아니다.


지금은 당시만큼의 폭발적인 인기는 아니지만,


웹과 앱의 경계가 명확해 지면서 웹과 앱을 둘다 개발 할 수 있는 것은


분명한 개인의 경쟁력 강화에 도움이 된다.





#04. 성능



성능 테스트를 지접 돌려서 본인이 만든 애플리케이션의 성능까지 측정하는 개발자라면 매우 훌륭한 수준이다.


하지만, 그만큼 도달하기에는 힘든 경지이기도 하다.



성능 분야에 대해서 공부를 하려면, 알아야 하는 것이 매우 많다.


성능 분석 분야는 IT 업계의 종합 예술이라고 생가한다.


왜냐하면, 성능 분야는 측정만 해서 결과를 도출하는 것으로 끝나는 것이 아니기 떄문이다.


그런 일만 하면 그냥 틀을 사용하는 오퍼레이터만 될 뿐이다.


병목이 발생하면 그 원인을 찾아 주고, 해결 방안까지 제시해 주어야만 진정한 성능 업무를 한다고 할 수 있다.





#05. 테스트



테스트도 성능과 같이 쉬운 분야는 아니다.


하지만, 개발자라면 테스트를 할 줄 알아야 하고, 본인이 만든 코드에 대한 테스틀 하는 코드를 직접 작성도 해야만 한다.


위에도 그 내용이 있지만, 자바 개발자에거 JUnit은 친구가 되어야만 한다.


절대로 귀찮게 하는 적이 아닌다.


그리고, 공부할 기회가 된다면 TOD에 대해서 공부해 두면 많은 도움이 될 것이다.





#06. OS( 리눅스, 유닉스 )



게임과 같이 몇몇 특종 업종을 제외한 대부분의 기업에서는 유닉스 계열 및 리눅스 계열 서버로 운영을 한다.


따라서, 직접 만든 프로그램이 돌아가는 OS에 대한 지식을 갖는 것은 매우 중요하다.


왜냐하면, 서버의 커널에서 어떻게 프로그램이 수행되는 지에 대한 것을 알고 있는 것과 모르는 것은 천지 차이이기 떄문이다.


큰 관심을 없다고 할지라도 유닉스나 리눅스에서 사용하는 각종 명령어는 알아두는 것이 큰 도움이 된다.



추가로, vi, vim은 꼭 알아두는 것이다 좋다.


그렇지 않으면 서버에 터미널로 접속해서 바보된다.





#07. TCP / IP에 대한 개념과 네트워크



방금 OS에 대해서 이야기 했지만,


OS중에서 무엇보다 네트워크에 대한 지식을 갖추는 것은 큰 도움이 된다.


요즘은 대부분의 서비스와 프로그램이 네트워크를 통해서 데이터를 주고 받는다.


게다가 프로그램이 네트워크 때문에 문제가 발생하는 경우도 적지 않다.


때문에, 적어도 브라우저에서 요청을 하면 서버에 어떻게 연결이 되고, 데이터를 받고, 그 연결이 끊어지는지에 대한 지식은 갖고 있는 것이 좋다.


그냥 "서버 담당자가 보겠지", "네트워크 담당자가 알아서 하겠지" 라고 간과하는 것은 좋지않다.





#08. 시스템 구성 방법



어떤 서비스를 하기 위한 시스템을 구성할 때 시스템 구성도를 만들고,


실제 설정까지 하기는 번거롭고 귀찮은 작업일 수 있다.


하지만, 어떤 시스템이든지 시스템 구성도는 그려져 있다.



만약 운영하거나 개발하고 있는 시스템의 시스템 구성도가 없다면 그 시스템은 제대로 돌아갈 확률이 매우 적다.


여하튼, 시스템 구성도를 보고 서버가 어떻게 구성되었는지를 이해할 수 있는 수준은 되어야 한다.


더 나아가서 시트메 구성도에 있는 각 네트워크 장비들의 역할이 뭔지 알 수 있으면 더더욱 좋다.


아마도 그 정도 수준이 되면 해당 서비스가 처리할 수 있는 최대 네트워크 사용량도 알 수 있을 것이다.



시스템 구성도를 읽는 것을 배우는 것은 쉽다. 그리는 것은 매우 어렵다.


따라서, 전에 사용했던 시스템 구성도를 복사해서 대충 구성하거나,


서버 벤더에서 그려주는 그대로를 따르지 않는것이 좋다.








반응형
//