[KB IT’s Your Life 7기] 백엔드개발을 위한 자바프로그래밍 후기 | 자바 1편

 

 

안녕하세요.

Today I Learned

 

백엔드 개발을 위한 자바프로그래밍 교육 후기

 

벌써 자바를 배우고 있다니 정말 시간이 빠르게 지나는거 같네요. 

자바(Java)는 현재 실무에서 가장 널리 사용되는 언어 중 하나로, 

특히 백엔드 개발에서 압도적인 점유율을 자랑합니다. 

객체지향 프로그래밍의 핵심 개념들이 언어 자체에 깊이 녹아 있어, 

자바를 제대로 배우는 것은 단순히 문법을 익히는 것이 아니라 

소프트웨어 설계의 사고방식을 기르는 과정이기도 합니다.

저는 현재 IntelliJ IDEA를 사용해 자바를 공부하고 있습니다. 

오늘은 클래스와 메모리 구조부터 람다식과 스레드까지 핵심 개념들을 정리해보겠습니다.

 

 

클래스(Class)와 메모리 구조

 

 

자바를 처음 배울 때 가장 먼저 마주치는 개념이 바로 클래스(Class)입니다.

클래스는 한 마디로 객체를 만들기 위한 설계도입니다. 설계도 자체에는 데이터가 없습니다.

new 키워드를 통해 객체를 생성하는 순간, 비로소 메모리에 실체가 만들어집니다.

클래스는 크게 세 가지로 구성됩니다.

• 필드(Field): 객체가 가지는 데이터
• 생성자(Constructor): 객체 생성 시 초기화를 담당
• 메소드(Method): 객체가 할 수 있는 동작

new로 객체를 만들면 Heap 영역에 실제 데이터가 저장되고, Stack 영역에는 그 주소를 가리키는 변수(참조값)가 올라갑니다. 위 슬라이드의 s1, s2처럼 변수는 스택에, 실제 Student 객체는 힙에 존재하는 구조입니다.

여기서 한 가지 중요한 패턴이 등장합니다. 바로 싱글톤(Singleton) 패턴입니다.

일반적으로 new를 쓰면 객체가 여러 개 생성될 수 있습니다. 하지만 로그 관리나 DB 연결처럼 시스템 전체에서 딱 하나만 존재해야 하는

객체가 필요할 때가 있습니다. 이를 위해 생성자를 private으로 막고, static 필드로 단 하나의 인스턴스를 관리하며, getInstance()라는 메소드를 통해서만 접근하게 합니다.

 

 

 

접근 제한자 & 캡슐화

자바에는 접근 제한자(Access Modifier)라는 개념이 있습니다. 클래스, 필드, 메소드에 누가 접근할 수 있는지를 제어하는 키워드입니다.

default는 아무것도 쓰지 않은 상태입니다. 같은 패키지 안에서만 접근 가능합니다.

 

이 접근 제한자를 활용한 핵심 원칙이 바로캡슐화(Encapsulation)입니다.

필드를 private으로 숨기고, 외부에서는 반드시 public Getter/Setter를 통해서만 접근하게 만드는 구조입니다.

처음에는 왜 이렇게 해야하는지 몰랐지만!

나중에는 당연하다 생각이 될 정도로 중요한 기술?이었습니다.

 

 

상속과 다형성

 

 

자바에서 중요한 개념은 상속과 다형성인데, 이것은 이전에 배운 프론트에서도 있던 개념입니다!

상속(Inheritance)은 부모 클래스의 필드와 메소드를 자식 클래스가 물려받는 것입니다.

extends 키워드를 사용하며, 자바는 단일 상속만 지원합니다.

상속에서 꼭 알아야 할 규칙이 두 가지 있습니다.

• super(): 자식 생성자의 첫 줄에서 부모 생성자를 호출합니다.
• @Override: 부모의 메소드를 자식이 재정의할 때 사용합니다. 접근 제한자를 더 좁게 바꾸는 것은 불가능합니다.

다형성이란 아래와 같은 형태로 이루어져있습니다.

부모타입 변수 = new 자식객체();

부모 타입 변수로 자식 객체를 담을 수 있고,

메소드를 호출하면 실행 시점(Runtime)에 실제 자식 객체의 오버라이딩된 메소드가 실행됩니다.

이것이 동적 바인딩(Dynamic Binding)입니다.

 

 

이 덕분에 새로운 자식 클래스가 추가되어도 기존 호출부 코드를 전혀 수정하지 않아도 됩니다.

시스템이 확장에 열려 있는 구조가 되는 것입니다.

한 가지 주의할 점은 instanceof입니다. 부모 타입 변수를 자식 타입으로 강제 형변환(다운캐스팅)하기 전에

반드시 instanceof로 실제 타입을 확인해야 ClassCastException을 방지할 수 있습니다.

추상클래스와 인터페이스

 

 

처음 자바를 배울 때 가장 헷갈리는 부분 중 하나입니다.

둘 다 직접 객체를 만들 수 없고, 상속/구현을 강제한다는 점은 같지만 목적이 다릅니다.

 

 

클로드한테 물어보니 이 특징을 이렇게 비유를 해주더라구요!

• 추상 클래스: "너는 동물이야. 공통된 특성을 물려줄게." → is-a 관계
• 인터페이스: "너는 날 수 있어야 해. 어떻게 날지는 네가 정해." → can-do 관계

그리고 Java 17에서 추가된 Sealed 인터페이스도 알아두면 좋습니다. permits 키워드로 어떤 클래스만 이 인터페이스를 구현할 수 있는지 직접 지정할 수 있습니다. 상속 계층을 더 엄격하게 통제하는 현대적인 방식입니다. (수업은 java 17로 진행해서 우선은 이정도만,,)

예외처리 방법

자바의 예외 체계는 최상위 Throwable에서 시작합니다.

• Error: JVM 레벨의 심각한 문제(OutOfMemoryError 등). 개발자가 처리할 수 없습니다.
• Exception: 개발자가 처리할 수 있는 예외.
  • Checked Exception: 컴파일러가 강제로 확인합니다. IOException처럼 반드시 try-catch 또는 throws가 필요합니다.
  • Unchecked Exception(RuntimeException): 실행 중 발생하는 개발자 실수. NullPointerException이 대표적입니다.

예외 처리의 흐름은 try → catch → finally 순서입니다.

try 블록에서 코드를 실행하다가 오류가 발생하면 catch로 넘어가고, finally는 예외 발생 여부와 상관없이 무조건 실행됩니다.

그래서 DB 연결이나 파일 스트림처럼 반드시 닫아줘야 하는 리소스를 해제하는 용도로 주로 씁니다.

 

 

처음 자바를 배울 때 저도 그랬는데, 예외가 발생하면 일단 그 자리에서 try-catch로 감싸버리는 경우가 많습니다.

일단 에러는 안 나지만, 코드가 길어질수록 비즈니스 로직 사이사이에 예외 처리 코드가 끼어들면서

가독성이 급격히 떨어지는 문제가 생깁니다.

 

 

이럴 때 사용하는 것이 throws입니다. 예외를 그 자리에서 처리하는 게 아니라 호출한 상위 계층으로 떠넘기는 방식입니다.

이렇게 하면 비즈니스 로직은 본연의 기능에만 집중할 수 있고, 예외 처리는 한 곳에서 모아서 관리할 수 있습니다.

 

 

지금 단계에서는 이 개념이 크게 와닿지 않을 수도 있는데,

나중에 Spring을 배우다 보면 @ControllerAdvice라는 전역 예외 핸들러를 만나게 됩니다.

모든 예외를 한 클래스에서 일괄 처리하는 구조인데, 바로 이 throws의 철학이 실무 레벨로 구현된 형태입니다.

지금 이 개념을 제대로 이해해두면 나중에 훨씬 자연스럽게 받아들일 수 있습니다.

 

 

다음주에 깃 후기와함께 나머지 자바 교육도 정리하여 올리겠습니다!

 

오늘은 여기까지!