스프링과 스프링부트(Spring Boot)ㅣ정의, 특징, 사용 이유, 생성 방법

인사이트

스프링과 스프링부트(Spring Boot)ㅣ정의, 특징, 사용 이유, 생성 방법

2022년 11월 23일

스프링은 Java 백엔드 개발에 있어 떼어놓을 수 없는 프레임워크입니다. 지금부터 Java 백엔드의 핵심 기술이 되는 스프링 프레임워크와 스프링 부트가 무엇인지, 나아가 스프링 부트를 활용하여 프로젝트를 생성하는 기초적인 방법에 대해 알아봅시다.

스프링 스프링부트

스프링(Spring)이란? 🌱

무언가의 정체를 파악하는 데에 있어 정의를 이해하는 것보다 효과적인 방법은 없습니다. 정의라는 것 자체가 어떤 대상에 대해, 해당 대상을 알고 있는 다수가 동의하는 해당 대상에 대한 대표적이고 요약적인 설명이기 때문입니다. 이러한 관점에서, 아래 스프링의 정의를 살펴봅시다.

스프링 정의

엔터프라이즈용 Java 애플리케이션 개발을 편하게 할 수 있게 해주는 오픈소스 경량급 애플리케이션 프레임워크

스프링 프레임워크

위 정의는 스프링이 무엇인지를 잘 드러내줍니다. 하나씩 뜯어보면서 위 정의를 조금 더 깊게 이해해봅시다.

엔터프라이즈용 Java 애플리케이션 개발을
편하게 할 수 있게 해주는

기업에서 운영하는 웹 서비스에는 비즈니스 로직이라는 것이 있습니다. 비즈니스 로직이란, 기업이 제공하는 서비스를 코드로 구현한 것으로, 사용자의 요구사항을 해결하기 위한 실질적인 코드들을 의미합니다. 스프링이 등장하기 이전에는 비즈니스 로직을 구현하기 위해 기술 자체에 대한 공부를 추가적으로 해야만 했습니다. 비즈니스 로직을 구현하는 기술 자체가 복잡하고 어려웠기 때문입니다.

그러나, 스프링은 이전 기술에 비해 사용 방법이 상대적으로 덜 복잡합니다. 따라서, 개발 초기에 기본적인 설정과 적용시킬 기술들만 잘 선택을 해준다면, 기술보다는 애플리케이션의 로직 자체에 더 집중하여 비즈니스 로직을 구현할 수 있습니다.

오픈소스

스프링은 모든 사용자에게 무료로 열려 있습니다. 즉, 어떤 개인 및 기업도 스프링을 사용하여 웹 애플리케이션을 개발을 할 수 있으며, 필요하다면 스프링의 코드를 일부 수정하여 사용하여도 무관합니다. 이처럼 오픈소스로 프로젝트를 공개해 놓으면 여러 사람이 프로젝트의 코드를 사용해봄으로써 다양한 검증 과정을 거칠 수 있다는 장점이 있습니다.

하지만, 뚜렷하게 정해진 인원이 프로젝트의 개발과 관리를 맡는 것이 아니기 때문에, 프로젝트의 개발과 개선이 안정적이지 못하다는 단점 또한 가질 수밖에 없습니다. 기업에서 사용하는 프레임워크는 반드시 안정적이어야 합니다. 프레임워크의 불안정성은 서비스 제공의 불안정성으로 이어지고, 결국 기업의 수익 감소로 이어질 수 있기 때문입니다.

그러나, 스프링은 오픈소스 프레임워크이지만, 안정적인 개발과 개선이 보장됩니다. 현재 스프링은 오픈소스로 배포되어 누구나 이용할 수 있지만, 스프링소스(SpringSource)라는 IT기업에서 관리하고 있으며, 스프링의 소스 코드를 수정하거나 개선하는 일에는 스프링소스의 한정적인 인원만 참여할 수 있습니다.

경량급

스프링은 수십개의 세부 모듈 및 수십만줄의 방대한 코드로 이루어진 프레임워크입니다. 그럼에도 불구하고 어떻게 스프링을 정의할 때에 경량급이라는 수식어를 사용할 수 있는 것일까요? 스프링을 정의함에 있어 경량급이라 함은 기존에 스프링 대신 사용하던 기술들과 비교하여, 스프링을 사용했을 때에 개발자가 작성해야 할 코드가 상대적으로 단순하다는 것을 표현하기 위함입니다.

스프링이 등장하기 이전에는 EJB(Enterprise Java Bean)라는 기술이 주로 사용되었습니다. EJB 또한 EJB 이전에 사용되던 기술의 단점을 보완하여 이전 기술을 대체하기 위해 등장했지만, 그럼에도 여전히 불필요하게 복잡한 코드를 작성해야만 했습니다. 이에 따라, 많이 개발자들이 불필요한 코드들을 어떻게 걷어낼지, 어떻게 코드의 복잡성을 줄일 수 있을지 고민했고, 그 결과 탄생한 것이 스프링입니다.

따라서, 스프링을 정의함에 있어 경량급 애플리케이션 프레임워크라 함은, 스프링을 사용함으로써 기존 기술을 사용할 때에 불가피하게 작성해야만 했던 불필요하게 복잡한 코드를 제거하여 코드의 복잡성을 낮출 수 있음을 의미합니다.

애플리케이션 프레임워크

애플리케이션 프레임워크가 무엇인지 이해하기 위해서는 프레임워크에 대해서 알아야 합니다.

여러분이 자동차를 만든다고 가정해봅시다. 이 때, 처음부터 끝까지 자동차의 모든 것을 손수 만드는 것보다는, 자동차 회사에서 자동차의 차체를 사와서 차체에 각 부품을 만들어 붙이는 것이 훨씬 더 편리할 것입니다. 즉, 자동차 회사에서는 미리 자동차의 차체를 만들어뒀고, 여러분은 그것을 가져다가 사용하기만 하면 되는 것입니다. 여기에서 자동차의 차체에 해당되는 것이 바로 프레임워크입니다. 웹 개발에 있어 프레임워크란, 어떠한 목적을 쉽게 달성할 수 있도록 해당 목적과 관련된 코드의 뼈대를 미리 만들어둔 것을 의미합니다.

그렇다면 애플리케이션 프레임워크는 무슨 의미일까요? 일반적으로 프레임워크는 특정 업무 분야 혹은 하나의 기술에 집중합니다. 즉, 어떠한 특화된 목적을 편리하게 달성할 수 있게 하기 위해 만들어집니다. 반면, 애플리케이션 프레임워크는 특정 업무 분야 및 특정 기술이 아니라, 애플리케이션 개발에 필요한 모든 과정에 집중합니다. 다시 말해, 애플리케이션 프레임워크는 애플리케이션을 개발하는 데에 있어 필요한 모든 업무 분야 및 모든 기술과 관련된 코드들의 뼈대를 제공합니다.

스프링의 특징

그렇다면 스프링 프레임워크의 특징에 대해 살펴보도록 하겠습니다.

POJO 프로그래밍을 지향

스프링의 가장 큰 특징은 POJO 프로그래밍을 지향한다는 것입니다. 여기에서 POJO란, Plain Old Java Object, 즉 순수 Java만을 통해서 생성한 객체를 의미합니다. POJO가 무엇인지 조금 더 깊게 이해하기 위해서는 POJO의 JO보다는 PO에 집중해야 합니다. 순수 Java 만을 통해서 객체를 만든다는 것이 어떤 의미를 가지는 것일까요?

순수 Java 만을 사용한다는 것은 Java 및 Java의 스펙에 정의된 기술만 사용한다는 의미입니다. 즉, 어떤 객체가 외부의 라이브러리나 외부의 모듈을 가져와서 사용하고 있다면, 그 객체는 POJO라고 할 수 없습니다. POJO는 말 그대로, 다른 기술을 사용하지 않는 순수한 Java만을 사용하여 만든 객체인 것입니다.

스프링 프레임워크

그렇다면, POJO는 왜 중요한 것이고, 어떤 이유에서 POJO 프로그래밍이라는 패러다임까지 만들어지게 된 것일까요? 외부 라이브러리를 import하여 라이브러리의 메서드를 사용하고 있는 객체가 있다고 가정해봅시다. 이 객체는 순수 Java 외에 외부 기술을 사용하고 있으므로, POJO가 아닙니다. 이 때, 이 객체가 사용하고 있는 기술이 Deprecated되거나, 개선된 신 기술이 등장하여 기존 기술과 관련된 코드를 모두 고쳐야 하는 상황이 발생하면 해당 기술을 사용하고 있는 모든 객체들의 코드를 전부 바꿔주어야만 합니다. 이는 해당 객체가 외부 모듈에 직접적으로 의존하고 있기 때문에 자연스럽게 발생하는 문제입니다.

반면, POJO는 순수 Java만을 사용하여 만든 객체이므로 특정 기술이나 환경에 종속되지 않습니다. 따라서, 외부 기술이나 규약의 변화에 얽매이지 않아, 보다 유연하게 변화와 확장에 대처할 수 있습니다. 이러한 POJO를 사용하여 비즈니스 로직을 구현하면 객체지향 설계를 제한없이 적용할 수 있으며, 코드가 단순해져 테스트와 디버깅 또한 쉬워집니다. 이처럼 비즈니스 로직을 구현하는 데에 POJO를 적극적으로 활용하는 프로그래밍 패러다임을 POJO 프로그래밍이라고 합니다.

앞서, 스프링의 가장 큰 특징은 POJO 프로그래밍을 지향하는 것이라고 했습니다. 이제부터는 POJO 프로그래밍을 위해 스프링이 지원하는 기술IoC/DI, AOP, PSA에 대해서 알아봅시다.

스프링 스프링부트

IoC / DI (Inversion of Control / Dependency Injection, 제어의 역전 / 의존성 주입)

Java 애플리케이션의 동작 흐름에서 중요한 것은 무엇일까요? 아무래도 Java는 객체지향 언어이므로, 객체들 간의 관계를 적절히 맺어주는 것이 중요한 요소일 것입니다. 객체들 간에 관계를 맺어준다는 것은 거창한 것이 아닙니다. A 인스턴스가 B 인스턴스의 메서드를 호출하고 있다면 A는 B와 의존 관계를 맺은 것이 되며, 이 둘의 관계를 “A가 B에 의존하는 관계”라고 표현할 수 있습니다. A가 B의 기능을 가져다가 사용하고 있으니까요.

스프링 스프링부트

위의 A와 B의 의존 관계는 개발자에 의해 만들어집니다. 개발자가 직접 new 키워드를 사용하여 인스턴스를 생성하는 코드를 작성했기 때문입니다. 그런데, 위처럼 코드를 작성할 때에 필연적으로 발생하는 문제가 있습니다. 만약, A가 사용할 객체를 B가 아니라, 새롭게 C를 정의해서 사용하고자 한다면 어떻게 해야 할까요? 당연하게도, A의 코드를 아래와 같이 변경할 수밖에 없을 것입니다.

스프링 스프링부트

위 예제에서는 기존에 B를 사용하던 객체가 A 하나뿐이므로 간단하게 바꿔주면 되지만, 만약 기존에 B를 사용하던 객체가 A 뿐만 아니라, 수십 또는 수백개가 있다면 모든 객체의 코드를 수정해주어야 합니다. 실무에서 코드를 이런 방식으로 작성해두었다면 야근을 피하기는 힘들 것 같습니다.

하지만, 야근 걱정은 하지 않으셔도 됩니다. 스프링을 사용하면 위처럼 변화가 발생한 상황에 최소한의 수정만으로 변화를 유연하게 수용할 수 있습니다. 스프링을 사용하여 좀 더 변화에 유연하게 대응할 수 있는 코드를 작성하려면 아래와 같이 코드를 수정해주어야 합니다. (1) ~ (5)의 설명을 순서대로 읽으면서 어떤 부분이 어떻게 바뀌었는지 파악해보세요.

스프링 스프링부트

위 예제에서 A는 자신이 사용할 객체를 스스로 생성하지 않고, 생성자를 통해 외부로부터 받아오고 있습니다. 즉, A는 자신이 사용할 객체를 알지 못하며, 그저 i에 할당된 인스턴스에 example()이라는 메서드가 존재한다는 것만 알고 있습니다.

그렇다면 누군가 A가 사용할 객체를 결정하고 생성해서 A가 인스턴스화될 때 인자로 전달해주어야만 합니다. 그래야 A는 B의 것이든, C의 것이든 example() 메서드를 호출할 수 있을 것이기 때문입니다. 그 누군가가 무엇일까요?

그 누군가가 바로 바로 스프링입니다. 스프링을 사용하면 애플리케이션의 로직 외부에서 A가 사용할 객체를 별도로 설정할 수 있습니다. 개발자가 설정 클래스 파일에 A가 사용할 객체를 C로 설정해두면, 애플리케이션이 동작하면서 스프링이 설정 클래스 파일을 해석하고, 개발자가 설정해둔대로 C 객체를 생성하여 A의 생성자의 인자로 C를 전달해줍니다.

이처럼 개발자가 아닌 스프링이 A가 사용할 객체를 생성하여 의존 관계를 맺어주는 것을 IoC(Inversion of Control, 제어의 역전)라고 하며, 그 과정에서 C를 A의 생성자를 통해 주입해주는 것을 DI(Dependency Injection, 의존성 주입)라고 합니다.

AOP (Aspect Oriented Programming, 관심 지향 프로그래밍)

애플리케이션을 개발할 때에 구현해야 하는 기능들은 크게 공통 관심 사항핵심 관심 사항으로 분류할 수 있습니다. 먼저, 핵심 관심 사항은 애플리케이션의 핵심 기능과 관련된 관심 사항으로, 커피 주문 애플리케이션을 예로 든다면 메뉴 등록하기, 주문하기, 주문 변경하기 등이 있을 것입니다.

반면, 공통 관심 사항은 모든 핵심 관심 사항에 공통적으로 적용되는 관심 사항들을 의미합니다. 예를 들어, 메뉴 등록하기, 주문하기, 주문 변경하기 등 모든 핵심 관심 사항에는 로깅이나 보안 등과 관련된 기능들이 공통적으로 적용되어야만 합니다.

이 때, 핵심 관심 사항과 공통 관심 사항이 코드에 아래와 같이 함께 모여 있으면 필연적으로 공통 관심 사항과 관련된 코드가 중복될 수밖에 없습니다. 이처럼 코드가 중복되어져 있는 경우, 공통 관심 사항을 수행하는 로직이 변경되면 모든 중복 코드를 찾아서 일일이 수정해주어야만 합니다.

위의 예제에서 발생하는 코드의 중복이라는 문제를 해결하기 위해서는 공통 관심 사항과 관련된 기능들을 별도의 객체로 분리해낸 다음, 분리해낸 객체의 메서드를 통해 공통 관심 사항을 구현한 코드를 실행시킬 수 있도록 해야 합니다. 이처럼, 애플리케이션 전반에 걸쳐 적용되는 공통 기능을 비즈니스 로직으로부터 분리해내는 것을 AOP(Aspect Oriented Programming, 관심 지향 프로그래밍)라고 합니다.

PSA (Portable Service Abstraction, 일관된 서비스 추상화)

스프링은 Java 백엔드 개발에 있어 핵심적인 역할을 수행하는 프레임워크이며, 백엔드 개발에서 데이터베이스는 떼어놓기 어렵습니다. 웹 서버는 데이터베이스와 소통하며 웹 클라이언트의 요청을 처리해야 하기 때문입니다. 데이터베이스의 종류는 MySQL, Oracle, Maria DB, Mongo DB 등 실로 다양합니다.

만약, 여러분이 MySQL을 사용하여 개발을 완료했는데, Maria DB로 데이터베이스를 바꿔야 하는 상황을 가정해봅시다. 이 때, 각 데이터베이스마다 사용 방법이 다르다면 어떨것 같나요? 아마 기존에 작성한 코드를 전부 지우고 새로 작성해야 하거나, 기존 데이터베이스와 새로운 데이터베이스 간에 사용 방법이 다른 코드를 모두 찾아서 일일이 수정해주어야 할 것입니다.

그러나, 스프링을 사용하면 동일한 사용방법을 유지한 채로 데이터베이스를 바꿀 수 있습니다. 이는 스프링이 데이터베이스 서비스를 추상화한 인터페이스를 제공해주기 때문에 가능합니다. 즉, 스프링은 Java를 사용하여 데이터베이스에 접근하는 방법을 규정한 인터페이스를 제공하고 있으며, 이를 JDBC(Java DataBase Connectivity)라고 합니다.

각 데이터베이스를 만든 회사들은 자신의 데이터베이스에 접근하는 드라이버를 Java 코드의 형태로 배포하는데, 이 드라이버에 해당하는 Java 코드의 클래스가 JDBC를 구현합니다. 따라서, JDBC를 기반으로 하여 데이터베이스 접근 코드를 작성해두면, 이후에 데이터베이스를 바꾸어도 기존에 작성한 데이터베이스 접근 로직을 그대로 사용할 수 있습니다.

이러한 JDBC처럼 특정 기술과 관련된 서비스를 추상화하여 일관된 방식으로 사용될 수 있도록 한 것을 PSA(Portable Service Abstraction, 일관된 서비스 추상화)라고 합니다.

스프링 스프링부트

스프링부트(Spring Boot)란?

스프링은 기존 기술의 복잡성을 크게 줄인 프레임워크이지만, 그럼에도 불구하고 스프링을 사용하기 위해서는 여러 가지의 사항들을 설정해주어야 합니다.

스프링부트 프레임워크

아래는 스프링으로 개발을 할 때에 설정해주어야 하는 설정 정보를 담고 있는 파일인데, 한 눈에 보기가 매우 어렵고 복잡해보이지 않나요?

스프링 스프링부트

하지만 걱정할 필요 없습니다. 스프링 부트가 있기 때문입니다. 스프링 부트를 사용하면 위의 복잡한 설정 정보를 아래와 같이 간략하게 줄일 수 있습니다.

설정 내용이 대폭 줄어들지 않았나요? 이처럼 설정 정보를 간략화할 수 있는 이유는 스프링 부트가 기존의 복잡한 설정을 대신 해주고 있기 때문입니다. 즉, 스프링 부트는 스프링으로 애플리케이션을 만들 때에 필요한 설정을 간편하게 처리해주는 별도의 프레임워크입니다. 스프링 부트를 사용하면 기존에 어려운 초기 설정에 쏟아야 했을 시간과 노력을 절약하여 비즈니스 로직을 구현하는데에 집중할 수 있습니다.

스프링 부트를 사용하면 초기 설정을 간편하게 할 수 있는 것 외에도 몇 가지 장점이 있습니다. 기존에는 배포를 할 때에 별도의 외장 웹 서버를 설치하고, 프로젝트를 War 파일로 빌드하여 배포를 진행했는데, 이러한 방식은 처리 속도가 느리며 번거롭다는 단점을 가집니다. 반면, 스프링 부트는 자체적인 웹 서버를 내장하고 있어, 빠르고 간편하게 배포를 진행할 수 있습니다. 또한, 스프링 부트를 사용하면 독립적으로 실행 가능한 Jar 파일로 프로젝트를 빌드할 수 있어, 클라우드 서비스 및 도커와 같은 가상화 환경에 빠르게 배포할 수 있습니다.

스프링부트 시작하기

이제부터는 스프링 부트를 활용하여 샘플 프로젝트를 생성해보겠습니다. 샘플 프로젝트를 만들고, 실행시켜보기 위해서는 아래의 조건의 충족되어져야 합니다.

  1. JDK(Java Development Kit)가 설치되어져 있어야 합니다.
  2. 환경 변수로 JAVA_HOME이 설정되어져 있어야 합니다.
  3. IntelliJ가 설치되어져 있어야 합니다.

위의 조건을 모두 확인하셨다면 이제 본격적으로 샘플 프로젝트를 만들어봅시다. 스프링 부트를 활용하여 샘플 프로젝트를 만드는 방법은 다양합니다. 여기에서는 그 중 가장 간단한 방법인 Spring Initializr를 활용해서 샘플 프로젝트를 만들어보겠습니다.

1. https://start.spring.io/에 접속한 후, 아래와 같이 내용을 입력해주세요.

스프링 스프링부트

(1) Project : 빌드 툴을 선택합니다.

(2) Language : 프로젝트에 사용하고자 하는 프로그래밍 언어를 선택합니다.

(3) Spring Boot : 스프링 부트의 버전을 선택합니다. 버전 이름 뒤에 아무 것도 붙지 않은 버전 중, 가장 최신 버전을 선택합니다.

  • SNAPSHOT : 아직 개발이 완료되지 않은 버전을 의미합니다.
  • M(Milestone) : 개발은 완료되었으나, 아직 기능들을 개선하는 중 또는 버그를 수정하고 있는 버전을 의미합니다.
  • RC(Release Candidate) : 기능 개선과 버그 수정이 완료되었으나, 최종적으로 릴리즈되지는 않은 버전을 의미합니다.

(4) Project Metadata : 프로젝트의 정보를 입력합니다.

  • Group : 프로젝트를 만드는 그룹의 이름으로, 보통 기업의 도메인 명을 역순으로 입력합니다. 여기에서는 com.codestates로 입력하겠습니다.
  • Artifact : 빌드 결과물의 이름입니다.
  • Name : 프로젝트의 이름입니다.
  • Description : 프로젝트에 대한 간략한 설명을 입력합니다.
  • Package name : 프로젝트에 생성할 패키지를 설정합니다.
  • Packaging : 배포를 위해 프로젝트를 압축하는 방법을 선택합니다.
  • Java : 여러분의 PC에 설치된 JDK의 버전을 선택하면 됩니다.

(5) Dependencies : 프로젝트를 통해 만들 애플리케이션의 동작에 필요한 라이브러리들을 선택합니다.

  • Spring Web만 추가해봅시다. Spring Web을 Dependencies에 추가하면 스프링 기반의 웹 애플리케이션을 개발하는 데에 필요한 라이브러리들이 자동으로 설정됩니다.

2. 화면 하단에 GENERATE를 누릅니다.

GENERATE를 누르면 설정한 내용을 바탕으로 프로젝트가 생성되고, 파일이 다운로드됩니다.

스프링 스프링부트

3. 다운로드한 파일의 압축을 해제해준 다음, 인텔리제이에서 프로젝트를 엽니다.

파일을 열면 의존성 라이브러리들이 자동으로 다운로드됩니다. 다운로드가 완료될 때까지 잠시 기다려주세요. 다운로드가 완료되면 src/main/java 패키지 내에 위에서 설정한 com.codestates 패키지가 만들어져 있습니다. 그 안에 있는 DemoApplication 클래스를 선택해봅시다.

4. DemoApplication 클래스의 main() 메서드를 실행시켜봅시다.

DemoApplication 클래스에는 프로젝트를 실행시킬 수 있는 main() 메서드가 정의되어져 있습니다. 좌측의 초록색 화살표를 눌러 main() 메서드를 실행해봅시다.

스프링 스프링부트

main() 메서드를 실행하면 아래에서 볼 수 있는 것처럼 Started DemoApplication in x.xxx seconds가 출력됩니다. 이는 애플리케이션이 정상적으로 실행된 것을 의미합니다.

스프링 스프링부트

또한, 아래와 같이 실행 아이콘이 계속 돌고 있는 것을 확인할 수 있는데, 이는 스프링 부트를 통해 생성한 프로젝트의 내장 WAS가 실행중임을 의미합니다.

자바 기초부터 스프링 프레임워크까지
백엔드 개발 부트캠프에서

지금까지 스프링과 스프링 부트가 무엇인지, 그리고 스프링 부트를 사용하여 프로젝트를 생성하는 방법까지 살펴보았습니다. 앞서 설명드렸던 내용을 한번 더 정리해보면 다음과 같습니다.

  • 스프링은 엔터프라이즈용 Java 애플리케이션 개발을 편하게 할 수 있게 해주는 오픈소스 경량급 애플리케이션 프레임워크다.
  • 스프링은 POJO 프로그래밍을 지향하는 특징을 가지며, 그를 위해 IoC/DI, AOP, PSA를 지원한다.
  • IoC는 객체 간의 의존 관계를 개발자가 아닌 스프링이 맺어주는 것을 의미한다.
  • DI는 의존 객체를 특정 클래스에서 직접 생성하는 것이 아니라, 외부로부터 주입해주는 것을 의미한다.
  • AOP는 애플리케이션 전반에 걸쳐 공통적으로 적용되는 코드들을 비즈니스 로직으로부터 분리해내는 것을 의미한다.
  • PSA는 특정 기술과 관련된 서비스들을 추상화하여 일관된 방식으로 사용할 수 있도록 한 것을 의미한다.
  • 스프링 부트는 스프링 애플리케이션을 만들 때에 필요한 초기 설정을 간편하게 해주는 프레임워크다.
  • Spring Initializr를 사용하면 스프링 프로젝트를 편리하게 생성할 수 있다.

코드스테이츠 백엔드 개발 부트캠프는 안정적인 웹 서비스를 효율적으로 구축하는 백엔드 개발자 양성 과정으로 자바, 스프링, 데이터베이스 등 백엔드 전반에 대한 기초 지식을 쌓아 배운 내용을 바탕으로 실전 프로젝트까지 진행하는 커리큘럼으로 설계되어 있습니다. 프론트엔드 개발 과정의 수강생과 협업하며 실무에 가까운 프로젝트를 진행할 수도 있죠.

조영현 Educational Software Engineer (Back-End)


👩‍💻 개발자 커리어의 시작,
코드스테이츠 부트캠프가 더 궁금하다면?

목록 보기

추천글