[패스트캠퍼스 수강 후기] 자바 인강 100% 환급 챌린지 34회차 미션

오늘은 20강, 21강 리팩토링 도메인코드에 대해 공부해보았다.

 

약간 억지스러웠던 혈액형 등의 내용을 정리하고 도메인을 다듬는 내용.

 

 

 

이제 이 프로젝트를 반이나 했다는데,

아직도 내가 뭘 공부하고 있는지 개념이 잘 안서서 추가적으로 검색해보았다.

 

 

<추가공부>

리팩터링

출처: 위키백과

 

리팩터링(refactoring)은 소프트웨어 공학에서 '결과의 변경 없이 코드의 구조를 재조정함'을 뜻한다. 주로 가독성을 높이고 유지보수를 편하게 한다. 버그를 없애거나 새로운 기능을 추가하는 행위는 아니다. 사용자가 보는 외부 화면은 그대로 두면서 내부 논리나 구조를 바꾸고 개선하는 유지보수 행위이다.

마틴 파울러의 저서 《리팩토링》에 다양한 리팩터링 패턴들이 정리되어 있다. 그중 대표적인 것 몇 가지를 들자면, 필드 은닉, 메서드 추출, 타입 일반화, 메서드 이름 변경 등이 있다.

 

 

 

DB와 웹개발 개념정리

 

출처: blog.naver.com/siki0903/220712241379

 

* 데이터 베이스

- 데이터 베이스 : 데이터의 집합

- DBMS : 데이터 베이스를 효율적으로 관리해주는 시스템 (SQL Management Studio) 비쥬얼 스튜디오 같은거임

 

- 트랜젝션 : 작업이나 행위자체를 말하는거임, '새로운 학생데이터를 입력하고 학번을 중간에 삽입한다' 이런 일련의 작업과정 자체를 트랜젝션이라고 할수 있음.
이걸 DBMS에서 저장하고 관리해주는데 왜 해주냐면 이 트랜젝션을 통해서 복잡한 작업을 한방?에 처리하고 작업이 잘못되었을때 이걸 토대로 복구(Rollback)을 해주는거임

 

- 쿼리 : 디비에서 쓰는 명령어들의 집합인데 이걸 실행하면 트랙젝션이 생기는거임, 혹은 트랜젝션을 이용해서 쿼리에 해당하는 내용을 디비에 반영하는것임

 

- 스키마 : 데이터가 저장된 구조, 학번순으로 정렬된 학생들같은것들임, 컨피그 파일에서 약속된 문자열이나 네트워크에서 메시지 헤더랑 유사하다고 불수 있음.
디비에서는 테이블단위이고 스페셜키값이나 서브키값 등을 쓰기 때문에 더욱 복잡한?구조임 대충 이정도만 알아도 됨..나란놈 자기합리화란...

 

- 디비는 데이터를 저장만 하는게 아니고 효율적으로 관리하고 데이터의 '상태'를 제어할 수 있어야 하므로 (ex) 학생목록을 1학기때로 Rollback 등)
트랜젝션이나 쿼리, 스키마를 제공하고 사용하는것임.
사실 xml 파일같은것도 작은 디비라고 볼수 있음.

 

- 몽고DB : 기존에 DBMS를 통해서 쿼리를 날려서 사용하는 방식이 전통적인 MsSql 등이 였는데 최근에는 DB관리자(DBA)가 직접적으로 DB를 관리하기보단
응용프로그램이나 웹페이지에서 알아서 DB값을 갱신하고 접근하도록 해주도록 많이 쓰는편(관리자 전용 페이지나 프로그램이라던지)이기 때문에 등장한 DB.
복잡한 스키마나 테이블설계 없이 SetData GetData같이 바로 라이브러리처럼 사용할 수 있어서 개발이 편하다. 근데 네이밍 병맛임 몽고몽고몽고

 

 

 

* 웹개발

- HTML : 익스플로어나 크롬같은 웹브라우저에서 웹페이지를 표현하기 위한 문서로써(MFC 같은데서 UI 소스코드를 만들면 UI가 생기는것 같은거임) 자바스크립트로 작성하고
.htm 포맷으로 저장하면 웹브라우저가 그걸 읽어서 네이버 메인화면 같은 웹페이지를 띄워줌

 

- JSP : 예를들어 네이버메인.htm 파일을 열면 인터넷연결이 안되어 있어도 네이버메인페이지가 열릴거임. 왜냐면 그게 웹페이지 모양을 정의한 소스코드이고 그걸 웹브라우저라는
실행파일로 연거니까.
근데 네이버메인페이지를 보면 내가 로그인하면 로그인부분이 동적으로 로그인되었다고 바뀜. 네이버메인.htm 로는 웹페이지 하나만 표현해주는데 그걸 어떻게 동적으로 바꾼걸까?
그런걸 해주는게 JSP(자바서버페이지)임.
1. 클라이언트가 로그인을 하면 서버로 입력된 아이디랑 비번을 보냄
2. 서버가 맞는지 DB에다 쿼리같은걸 날려서 확인함
3, 맞다고 판단되면 기본 네이버메인.htm을 로그인성공한 상태의 네이버메인.htm으로 바까서 클라이언트에 보내줌
   (여기서 쓰는게 JSP임. 네이버메인.htm에다 Java코드를 삽입해서 클라에 보내줌. 한마디로 동적 웹페이지 생성기 같은거임. 왜냐면 네이버메인_로그인성공.htm 따위의
    HTML파일을 또 만들어놓을수는 없는 노릇이니까)
4. 클라이언트는 웹브라우저에서 네이버메인.htm를 업데이트 해줌

 

- 웹페이지에서 페이지의 변환 구조 : 네이버에서 로그인을 성공했다. 그리고 웹툰이 보고 싶어서 웹툰을 클릭하면 웹브라우저는 네이버메인.htm 이 아닌 네이버웹툰.htm을
보여주는데 그게 다 위에처럼 서버가 만들어 보내준걸 그대로 띄워주기만 한거다.
1. 클라이언트가 네이버웹툰 url을 보내서 웹툰페이지 요청
2. 서버에서 url에 해당하는 웹페이지를 보내줌
3. 웹툰 나옴

4. 오늘자 마음의소리 꿀잼
 
- Servlet과 JSP : 주저리주저리 설명한걸 요약해보면 '웹?에서 서버는 동적으로 웹페이지를 만들어야 한다'가 포인트임.
그걸 가능하게 해주는게 서블릿이랑 jsp임. 쉽게 말해 자바개발환경에서 웹페이지를 만들수 있게 해주는거임(C++개발환경에서 3D개발을 하게 해주는 다렉이 있는식임)
차이점은 서블릿은 자바소스에 HTML소스를 삽입하고 JSP는 반대임. 휴힘듬

 

- CSS : HTML로 웹페이지를 만드는게 그위에 버튼도 올라가고 스크롤바도 생기고 UI가 있잖슴?그 UI 들을 정의해놓은 시트임 ㅎㅎ UI 표준같은거임..,,

 

- NodeJS : HTML을 개발하는 자바스크립트로 서버사이드 작업도 가능하게 해주는 오픈소스 프레임워크

 

- 웹개발에서의 DB : 일단 서버가 동작하는데 필요한 텍스트 기반정보들을 저장한다. 클라이언트는 웹브라우저밖에 없고 웹페이지 자체가 UI이므로 DB에 직접접근할 필요가 음슴.
때문에 서버에 DB 가있으며 로그인하면 회원정보 DB에 쿼리를 날려서 확인하는 식으로 동작한다. 물론 즐겨찾기라던지 방문기록 쿠키등은 클라이언트에 저장하기도 하는데 그런건 DB라기보단 그냥 정보들임.
게시판에 파일을 업로드하는데 이런애들은 서버에 하드디스크에 저장댐ㅎㅎ DB에 파일을 쓰진 않으므로..파일을 쓰면 너무 느리겠지? 아무튼
네이버같은 대형 웹사이트는 서버에 올라가는 파일의 양이 엄청나고 DB도 엄청난데 그런건 어트케 관리하는진 모르겠듬..넘나 어려운것..,

*** 이게 DB 랑 웹개발의 기본 개념인데 이거 웹쪽은 스프링 부트스트랩 익스프레스 모듈 등 다양하게 프레임워크나 미들웨어가 있음.

 

 

 

 

왜 자바 Spring만 뽑나요? 꼭 배워야 하나요?

출처 : seolin.tistory.com/119

들어가며

취준생 시절 때부터도 쭉 간직해 온 의문이 있었습니다. 내로라하는 대기업들의 구직 공고를 보면, 항상 따라오는 조건들이 있었죠.

• Java 언어 사용이 능숙한 분
• Spring Framework 개발 경험이 있으신 분

Java를 배우긴 했지만, 백엔드에 사용해본 적은 없었기에 이 부분은 항상 지원에 걸림돌이 되곤 했습니다. 도대체 자바 스프링이 뭐하는 녀석이길래 이 기업 저 기업에서 다 찾을까요? 나름대로 정리한 내용을 글로 옮겨보기로 했습니다. 그리고 '그렇다면 Spring을 배워야만 할까?' 하는 고민에 빠지신 분들께 제 의견을 전달해보고자 합니다.

주의사항 : 필자는 백엔드 개발에 이제 막 뛰어든 초짜입니다. 백엔드의 유구한 역사에 대해서는 당연히 잘 모르며, 제가 추측한 이유들도 잘못된 부분이 있을 수 있음을 밀리 알려드립니다.

Spring이 뭔가요?

친구 : 아니, 스프링 띠요오옹(용수철) 아니었어?

백엔드에 입문하는 사람들에게 스프링이 가장 큰 장벽으로 다가오는 원인은 바로 장황함에 있다고 봅니다. 자료조사를 시작하는 순간부터 '의존성 주입(Dependency Injection)'과 '역전 제어(Inversion Of Control)' 등의 생소한 개념들이 다가오고, gradle 설정, application.properties 수정하기 등의 작업이 들어가면 정말 당혹감을 느끼지 않을 수가 없습니다. 실사용 전에 개념만 가지고도 책 한권 분량은 족히 뽑아낼 수 있습니다. 물론, 이러한 개념들이 바로 스프링이 백엔드 개발에서 주류이자 현역으로 남아있는 가장 큰 이유라고 봅니다만, 요즘 백엔드 입문은 node.js express같은 가벼운 프레임워크로 시작하는 게 기본이다 보니, 개발 입문자들에겐 큰 장벽처럼 느껴지기 마련입니다. 그러다 보면 '아니 자바 스프링이 뭐길래 이 편한 노드 익스프레스 놔두고 이것만 고집하는거야?' 라는 생각이 떠오르게 되는 것이죠.

간단하게 요약하자면 Spring 프레임워크는 Java Enterprise Edition(기업용 자바)의 한계점을 극복하기 위한 배경에서 등장한 프레임워크입니다. 자바가 초창기에 서버로 활용될 때에는 자바 EE를 사용했었는데, 자질구레한 문제점들이 있었고, 로드 존슨이라는 인물이 이를 개선하기 위해 제안한 것이 바로 스프링 프레임워크입니다. (그래서 이름도 겨울이 끝나고 '봄'이 왔다는 뜻에서 Spring이다.. 라고 알고 있습니다) 결론은, 현재 자바로 백엔드 개발 == 자바 스프링 or 자바 스프링부트 라고 봐도 무방합니다.

 

자바 EE와 스프링과의 관계를 자세히 설명한 글이 있어 여기에 링크합니다. (잘 몰라서 도망가는 거 아님.. ㅎㅎ.. ㅈㅅ.. ㅋㅋ!!)

왜 다들 Spring을 쓰나요?

1. 정적 타입 언어로서의 강점

앞서 말한, 자바 스프링의 라이벌(?)쯤 되는 존재로 node.js의 express를 언급을 했습니다. Python에는 Django와 Flask가 있죠. 익스프레스는 간편한데, 자바는 왜 이렇게 복잡하다고 느껴질까요? 여러가지 이유가 있겠지만 가장 큰 이유는 자바스크립트가 동적 타입 언어이기 때문입니다.

자바스크립트는 뭘 던져줘도 일단은 받고 봅니다

위의 짤은 정확히는 '동적 타이핑'과 100% 일치하는 짤은 아니지만, 어느정도 연관성이 있습니다. 아래같은 코드를 볼까요.

const arr1 = [1, 2, 3, 4];
const arr2 = ['1', '2', '3', '4'];

const reduceArr = arr => arr.reduce((left, right) => left + right);

reduceArr(arr1); // 10
reduceArr(arr2); // '1234'

reduceArr는 배열 안의 원소들을 전부 더해주는 함수입니다. 개발자는 모든 숫자를 더해주는 함수를 의도하고 만들었으니, arr1 같은 배열이 원소로 들어간다면 정상적으로 10이 출력이 됩니다. 그러나 실수로 arr2 같은 문자열 배열이 들어갈 경우엔 concat이 발생하여 '1234'가 되어버립니다. 자바스크립트에서는 이를 미연에 감지하고, 막을 방법이 없습니다.

반면에, 자바는 정적 타이핑을 사용하므로 어느 정도 커버가 가능합니다.

public int reduceArr(int[] arr) {
    int result = 0;
    for (int e : arr) {
        result += e;
    }
    return result;
}

final int[] arr1 = new int[4] { 1, 2, 3, 4 };
final String[] arr2 = new String[4] { "1", "2", "3", "4" };

System.out.println(reduceArr(arr1)); // 10
System.out.println(reduceArr(arr2)); // 말도 안되는 호출이므로 바로 빨간줄 그어짐

자바는 함수의 입력과 출력이 어떤 타입을 가져야만 하는지를 강제합니다. 그러므로 위의 사례같은 잘못된 호출을 최대한 막을 수 있습니다. 특히나, 이런 장점은 다른 사람들과 협업할 때, 혹은 오랜 시간 동안 작업할 때 부각이 됩니다. 10명이서 동시에 작업하는 프로젝트에서, 다른 사람이 작성한 모든 코드를 숙지하며 올바르게 사용할 수 있을까요? 혹은, 반년 전의 내가 작성한 코드를 현재의 내가 100% 다 기억한다는 보장이 있을까요? 이런 이유 때문에 규모 있는 서비스 개발에는 정적 타입 언어가 선호됩니다.

그러나 이는 스프링이 주류인 충분한 이유가 되지 못합니다. 왜냐하면, js 진영도 이 부분을 잘 알기에, TypeScript라는 언어를 내놓았기 때문이지요. 동적 타이핑에 대한 약점은 TypeScript의 사용으로 충분히 커버하고도 남습니다. "타이핑 때문에요? 자바스크립트도 충분히 잘 되는데요?"

2. 컴파일된 언어로서의 장점

자바가 js, 파이썬이 가진 공통점은 가상 머신(VM) 기반으로 작동된다는 점이고, 이 중에서 자바가 다른 언어들과 구별되는 가장 큰 특징은, 자바는 컴파일된다는 점입니다. 프로그래밍을 입문하면 배우는 사실이지만, 프로그래밍 언어는 사실 컴퓨터가 전혀 알아먹을 수 없는 외계어에 해당합니다. 컴퓨터는 '기계어'만 이해할 수 있으므로, 모종의 과정을 통해 컴퓨터에게 기계어를 넣어줘야만 합니다. 컴파일러는 "미리 번역해서 기계어로 만들어버리자"라는 개념이고, 인터프리터는 "한 줄 한 줄 읽어가면서 기계어로 통역(interpret)해주자"라는 개념(그래서 js와 파이썬은 자바와 다르게 REPL이 가능합니다.)입니다.

설명을 읽어봐도 느낄 수 있지만, 컴파일러가 인터프리터보다 압도적으로 빠릅니다. 특히나 컴파일 과정에서는 소스 코드를 먼저 읽어보는 과정에서, 문법 에러를 감지하기도 하고, 최적화를 수행하기도 합니다. '어, 이 코드... 다르게 바꾸면 똑같은 동작이지만 성능은 더 좋아지겠는데?' 하면서 바꿔치기하는 과정까지 들어가는 것이죠. 엄밀히 말하면 자바는 기계어가 아니라 JVM(자바 가상머신)이 이해하는 '바이트 코드'로 변환되므로 C, C++에 준하는 성능까지는 절대 나오지 않습니다. 그러나 그렇더라도 인터프리터 언어보다는 빠르다고 할 수 있죠.

 

...라고 설명했습니다만, 이 또한 자바가 주류인 이유로서는 부적합합니다. 왜냐하면, 파이썬, 노드 같은 언어들도 이제는 JIT 컴파일을 지원하므로 실행 전에 컴파일이 수행되게 할 수 있습니다. 맥에서 PyCharm을 사용해보면 .pyc 를 생성하는 것을 볼 수 있는데, 이는 파이썬 실행 전에 이미 한번 컴파일을 수행한다는 의미입니다. "컴파일이요? 요즘엔 다른 언어도 다 하는데요?"

3. Spring이 제공하는 걸출한 도구들

사실 1, 2번은 "자바를 왜 쓰냐"에 해당합니다만, 스프링 프레임워크의 특성도 짚고 넘어가야 할 것 같습니다. 스프링은 자바 EE를 개선하기 위한 움직임에서 나온 프레임워크라는 언급을 했었습니다. 그런 배경이 있는 만큼, 기업이 애플리케이션을 만들 때 필요한 도구는 거의 다 갖추고 있다고 봐도 무방합니다.

Spring Security

• 인증에 관한 라이브러리, 로그인과 회원 가입, 적정 유저의 접근 권한 등을 관리하며, 소셜로그인이라 불리는 OAuth도 지원합니다.
• node.js일 경우, passport라고 불리는 서드 파티를 받아서 사용해야 합니다.

Spring Jdbc

• DB 접속에 관한 라이브러리. DB 커넥터를 바꿔가면서 사용할 수 있습니다. 즉, mysql을 쓰다가 oracle DB로 변경할 일이 있더라도, 인터페이스는 변하지 않으므로 코드 변경점이 크지 않습니다.
• node.js일 경우, mysql을 사용하고 싶다면 mysql2 라는 서드파티 패키지를 사용해야 합니다. DB를 바꾸고 싶다면 아예 다른 패키지를 받아야 합니다.

Spring Actuator

• 해당 웹 서버의 헬스 체크(Health Check), 모니터링 등을 도와주는 라이브러리입니다.
• node.js에서는 이 경우 어떤 것을 주로 채택하는 지 잘 모르겠습니다.

그 외에도 Spring 생태계에서는 필요에 따라 쓸 수 있는 다양한 라이브러리가 있으며, 기업 차원에서 이 라이브러리에 기여하기도 합니다. Spring Cloud Netflix가 대표적 예입니다.

이 비교에서 node.js express가 안 좋다고 말하는 것이 아닙니다. node.js의 npm을 보면 정말 무수히 많은 서드 파티 라이브러리가 있습니다. 노드의 강점은 바로 이 풍부한 라이브러리 생태계입니다. npm의 주류 라이브러리들은 무수히 많은 컨트리뷰션으로 유지되고 있으므로 지원 중단을 걱정할 일은 없습니다.

 

그러나, Spring은 기업의, 대규모 서비스에서 사용되고 있음을 상기할 필요가 있습니다. "단 1초라도, 단 한 명이라도 장애를 겪어서는 안 된다"는 입장에서는, 아직 써보지 않은 제 3자의 라이브러리를 선정해 모험을 감수하는 것보다는 이미 수많은 기업이 사용함으로써 검증된 라이브러리를 사용하는 것이 더 합리적인 선택일 것입니다.

그러나 이 논리대로라면 전 세계에서 규모 좀 있다는 모든 기업이 다 Spring을 써야 정상입니다. 그러나 페이스북은 PHP를 개량하여 사용하고 있고, 드롭박스는 파이썬으로 돌아가고 있습니다. 트위치는 루비 온 레일즈(Ruby On Rails)로 돌아갑니다. 국내에서 이 위의 세 회사보다 더 많은 트래픽을 감당중인 회사가 얼마나 있을까요? 근본적인 이유는 바로 다음과 같습니다.

4. 개발자 구인의 용이성

사실, 어느 트래픽에 어느 언어를 써야만 한다는 정답은 없습니다. 실력 있는 개발자만 있으면 세상 그 어느 언어를 갖다 놔도 매우 잘 돌아가도록 할 수 있습니다. 자바 스프링이 타 언어들에 비해 안정성이 있다거나, 성능이 잘 나온다 등의 이유가 있더라도, 국룰처럼 항상 채택될 이유가 되진 않습니다. 국내 시장에서 자바 스프링이 자주 보이는 것은, 경력자 구하기가 용이하기 때문입니다.

결국 Kotlin도 JVM 기반입니다. 안드로이드는 지금도 '자바 진영'이라 부를 수 있습니다.

자바가 도처에서 적극 활용된 지는 꽤 오랜 시간이 지났습니다. 처음에는 "가상 머신 기반이라 속도가 너무 느리다"는 악평을 받았지만, 가상 머신 기반으로 작동한다는 장점이 잘 먹혀 들어가, 전세계에서 사랑받는 언어가 되었습니다. 가까운 예만 보더라도 안드로이드가 있죠. 현재는 Kotlin으로 전환 중이지만, 이 코틀린마저도 JVM 기반의 언어이므로 '자바 진영'으로 볼 수 있습니다.

모 국비지원 사이트. 얼핏 보기에도 자바가 많습니다.

한국 IT도 한 때 자바 열풍이 불어 적극 활용되었고, 당시 IT 인력 양성에서도 C++ 못지 않게 자바가 대세였다고 합니다. 여기에 쐐기를 박는 것이 전자정부프레임워크인데, 자바 스프링 기반으로 만들어진 이 전자정부 프레임워크 때문에 직간접적으로 공공기관과 관련된 일을 해야하는 회사들이 자바를 이용할 수밖에 없었습니다. (국내 IT 시장에서 흔히 알려진 대기업과, 잘 알려지지 않은 SI 기업 중 어느 쪽의 수가 더 많을지 상상해 봅시다.) 이런 여러가지의 흐름 덕에 IT 시장에서 자바 개발자의 수는 많아졌고, IT 사업이 점점 커지면서 기업들이 경력자를 많이 필요로 하게 되고, 그 결과 많은 경력자들이 애용하는 자바 스프링이 국내 IT 시장의 대감마님이 되었습니다.

다들 Spring만 쓰는 건 아닙니다.

본문에 길게 설명하긴 했지만, 결론은 "Spring을 꼭 써야만 해서 쓰고 있는 것은 아니다"는 것을 느끼실 수 있을 듯합니다. 스타트업 중에서 자바 스프링을 채택하는 곳은 드뭅니다. "빠른 시간 내에 어떻게든 결과물을 내야하는 상황"에서 자바는 썩 좋은 선택은 아닙니다. 동적 타입 언어는 다소 예측하지 못한 문제들을 낳을 지는 몰라도, 생산성에서는 다른 언어들과 차원이 다릅니다. 그래서 대기업이 아닌 기업들을 볼 경우에 파이썬 Django나 노드 Express를 쓰는 경우를 자주 볼 수 있습니다. 어떤 기업은 Spring 프레임워크의 한계를 느껴서 다른 언어로 전환하기도 합니다.

신입으로 들어가려면 Spring을 배워야 하나?

제 의견은, '그럴 필요 없다'입니다. 물론 미리 배워두면 입사 후 적응이 빠를 수는 있겠지만, Spring 자체에 목을 매달 필요는 없습니다. 프레임워크는 어디까지나 도구입니다. 백엔드 개발에서 중요한 본질은 "네트워크 개념을 얼마나 잘 이해하고, DB를 얼마나 잘 이해하고, 이를 어떻게 응용할 수 있는가"입니다. 이 부분만 잘 숙지가 되어있다면, 프레임워크는 그 다음 문제입니다. 지금 쓰고 있는 프레임워크가 언젠가는 사멸(?)할 지도 모른다는 생각으로 접근해야 합니다. 상상하기 어렵지만, 언젠가 자바 스프링이 저무는 때가 오더라도, 백엔드에 대한 핵심 개념을 잘 간직하고 있다면, 어렵지 않게 다른 프레임워크를 집어들 수 있겠죠.

그렇기 때문에 기업에서는 신입에 대해 특정 프레임워크의 숙달도를 크게 신경쓰지 않습니다. (거기에 연연하는 기업이라면 저는 차라리 가지 말라고 말씀드리고 싶습니다.) 기존에 연습하던 것들, 하고 있던 프로젝트를 고도화해서 백엔드 지식을 많이 쌓은 상태라면, 마땅히 면접보는 사람들은 '개념을 이 정도로 알고, 이런 경험까지 해봤다면, 입사해서 스프링으로 전환하는 것도 금방 하겠군' 이라고 예상을 하게 될 것입니다. 그러니 "기존에 하던 것을 버리고 스프링을 다시 배울까?"가 고민된다면, 전 차라리 "지금 하던 걸 더 깊게 파서 수준 높은 경험을 쌓으세요" 라고 말씀드리고 싶습니다.

마치며

국내 IT 시장에서의 Spring의 위상(?)은 제 오랜 시절 궁금증이기도 했고, 가장 큰 골칫거리이기도 했습니다. Spring 경험이 아예 없는 상태로 인턴을 들어갔고, 입사까지 하게 되면서 이 두려움을 떨쳐낼 수 있었는데, 저의 경험이 비슷한 백엔드 개발 입문자들에게 하나의 인사이트를 던져주는 계기가 되었으면 하는 마음에 이 글을 작성해보았습니다. Spring에 대한 저의 생각이 많이 왜곡되어 있을 수도 있습니다. 저는 이 업계에 발을 들인지 이제 반년을 넘겼으니까요. 잘못된 정보가 있다면 언제든지 정정해주시면 감사하겠습니다.

 

 

 

 

 

패스트캠퍼스 강의: https://bit.ly/3ilMbIO

Java 웹 개발 마스터 올인원 패키지 Online. | 패스트캠퍼스