kim_pinetree98.log

AWS-SAA 교육과정, 해커톤 후기(우리 1팀 상받았어요)

Sat, 29 Nov 2025 18:58:22 GMT

졸업생, 리눅스, AWS 경험이 있는 분 우선입니다.

졸업생이었던 나는 뭔가 쉽게? 된 느낌이였다. 아마 대부분 취업하거나 현생이 바빠 이런 기회를 굳이 찾아본 것 같진 않다.

시간표는 대략 이렇습니다.

첫날 아침 9시반까지 가야했고, 15, 16, 17일 연속으로 대면 교육이다.

춘천에서 아침에 출발..

역삼역까지 아침 9반까지 가야했어서, 아침 7시 16분 차를 탔다.

도착하고 기념 사진

24년 1월 AWS-ART 해커톤 이후 AWS 본사를 오랜만에 왔는데, 익숙하면서도 새로운 느낌이였다.

간식도 엄청 많이 준비해주신 강사님, 멘토님들 정말 감사합니다.

교육은 제대로 받아야죠(진짜 재밌고 강의력 좋은 nxtcloud 최민철 강사님)

AWS SAA 자격증에 대한 교육을 3일간 교육을 들었다.

강사님이 매우 재미있게 설명해주시고 우리의 눈높이에 맞춰서 잘 설명해주셨다. 강사님의 강의력이 너무 좋았어서 매우 만족스러운 교육이었다. 또, 교육받다가 강원대 3분이랑 친해졌는데, 2분은 같이 스터디도 하기로해서 기대된다.

대망의 해커톤!!(feat. 랜덤 팀)

역시 해커톤답게, 밤새는거였다. AI를 활용한 자율주제였어서 예전 AWS-ART 리빙랩 해커톤 때랑 다르게 사회문제 해결보다는 진짜 AI를 활용하면서도 수요가 있을만한게 우선이었다. 해커톤 전에, 남은 5일간 팀원들과 단톡도만들고, 슬랙에서 소통도 해가며 준비했다.

그래서 우리 아이디어는요..?

AWS-ART 리빙랩 해커톤때의 실패경험이 있어, 빠른 아이디어 결단에 대한 중요성을 알고있었다. 솔직히 해커톤 당일 전에 끝내고 싶었지만, 아이디어가 그렇게 많진않았다. 그래도 당을 9시 이전에 끝내리라 생각했고, 미리 만들어 온 조도 있다해서, 솔직히 경계되었다. 이번 만큼은 빠르게 진행하고 싶었다. 그래서 투표 결과,

사기예방 AI 서비스
AI기반 북마크 리마인드 서비스

둘중에 하나로 추려졌으나, 멘토님들의 무수한 피드백과, 팀원들과의 회의로 2번으로 정해졌다. 사실 1번이 내 아이디어였으나, 멘토님들이 대체되는 서비스와 전문성을 생각하라는 말에 과감히 버리기로 했다. 팀원들이 괜찮냐 했지만, 마이너스에서 시작 할 바에야 빠르게 버리는게 맞다는걸 실패 경험으로 깨달았기 때문에, 차라리 좋았다.

우리 서비스는요..(I believe...)

북마크를 많이 저장하지만, 정작 다시 찾아보는 경우는 거의 없는, 개발자(or 다양한 사람들)을 위한 AI 기반 서비스이다.

이 서비스는 검색 키워드만 입력해도, 과거에 저장했던 북마크 중 필요한 정보만 자동으로 찾아 바로 보여준다. 이 서비스가 팀원의 니즈도 있었지만, 멘토님이 이런 서비스가 나온다면 바로 쓰겠다고 하셔서, 평가도 좋았다.

기대 효과는?

1) 정보 과부하 속에서도 필요한 내용을 즉시 찾게 해주는 검색 효율 극대화. 2) 잊혀진 북마크를 다시 문맥 속에서 되살려 활용도를 높이는 지식 회상(Recall) 개선

정도가 있었다.

** 진짜 이걸 밤새 만들었다.**

밤새 개발하면서 하나의 오류에 2시간을 잡아먹었는데, 멘토님께 질문을 드리니, 5분만에 해결되었다. 역시.. 모를땐 여쭤보는게 Best 였다.

밤샘 개발 후 발표!(사실 정신없어서..좀 절었다.)

내가 발표를 했고, 나가서 재밌게 해보자는 마인드로, 나가서 질문도 던지고, 최대한 사람들과 의사소통하면서 발표했다. 또한, 강사님과 심사위원분들의 날카로운 질문과, 피드백에 대답을 최대한 침착하게 하려했다.

그래서 결과는요?

우리팀이 2등을 하면서, 최우수상을 받았다. 아이디어도 심사위원님들이 좋게 봐주셨고, 실제로 좋게 서비스된다면 써볼 의향도 있으시다고 하셨다. 아이디어 내준 팀원에게 감사하단 말을 여기에서도 전하고 싶다. 그리고 끝까지 노력해준 우리 팀원들에게 매우 감사하다고 말하고 싶다.

P.S. 💌

이 자리에 함께해주신 강사님과 멘토님들 정말 감사드립니다! 또한, 같이 해커톤에 출전하신 강원대, 강릉원주대 모든 분들 너무 고생많으셨습니다. SAA 자격증도 잘 따시길 기원합니다!

이펙티브 자바/ 아이템1. 생성자 대신 정적 팩터리 메서드를 고려하라.

Tue, 22 Apr 2025 17:16:38 GMT

아이템1. 생성자 대신 정적 팩터리 메서드를 고려하라.

클라이언트가 클래스의 인스턴스를 얻는 전통적인 수단은 public 생성자다.

예시

public class Car {
 private String brand;
 public Car(String brand) {
     this.brand = brand;
 }
}

// 사용
Car car = new Car("BMW");

하지만 클래스는 생성자와 별도로 정적 팩터리 메서드(static factory method)를 제공할 수 있다. → 그 클래스의 인스턴스를 반환하는 단순한 정적 메서드

예시

public class Car {
 private String brand;

 // private 생성자
 private Car(String brand) {
     this.brand = brand;
 }

 // 정적 팩터리 메서드
 public static Car createCar(String brand) {
     return new Car(brand);
 }
}

// 사용
Car car = Car.createCar("BMW");

클래스는 클라이언트에 public 생성자 대신(혹은 생성자와 함께) 정적 팩터리 메서드를 제공할 수 있다. 이 방식에는 장점과 단점 모두 존재.

장점

이름을 가질 수 있다.

정적 팩터리는 이름만 잘 지으면 반환될 객체의 특성을 쉽게 묘사할 수 있다. (생성자에 넘기는 매개변수와 생성자 자체만으로는 반환될 객체의 특성을 제대로 설명하지 못한다.) → 이름을 가질 수 있는 정적 팩터리 메서드에는 (하나의 시그니처로 생성자를 하나만 만들 수 있는) 이러한 제약이 없다.

 //생성자 제약 예시
 public class User {
     private String name;
     private boolean isAdmin;

     // 생성자: 일반 사용자와 관리자 구분
     public User(String name, boolean isAdmin) {
         this.name = name;
         this.isAdmin = isAdmin;
     }

     @Override
     public String toString() {
         return "User{name='" + name + "', isAdmin=" + isAdmin + "}";
     }

     public static void main(String[] args) {
         // 일반 사용자 생성
         User regularUser = new User("Alice", false);

         // 관리자 생성
         User adminUser = new User("Bob", true);

         System.out.println(regularUser); // 출력: User{name='Alice', isAdmin=false}
         System.out.println(adminUser);   // 출력: User{name='Bob', isAdmin=true}
     }
 }

 // 정적 팩터리 메서드에서 생성자의 한계 극복 예시
 public class User {
     private String name;
     private boolean isAdmin;

     // private 생성자
     private User(String name, boolean isAdmin) {
         this.name = name;
         this.isAdmin = isAdmin;
     }

     // 정적 팩터리 메서드: 일반 사용자 생성
     public static User createRegularUser(String name) {
         return new User(name, false);
     }

     // 정적 팩터리 메서드: 관리자 생성
     public static User createAdminUser(String name) {
         return new User(name, true);
     }

     @Override
     public String toString() {
         return "User{name='" + name + "', isAdmin=" + isAdmin + "}";
     }

     public static void main(String[] args) {
         // 정적 팩터리 메서드를 사용한 객체 생성
         User regularUser = User.createRegularUser("Alice");
         User adminUser = User.createAdminUser("Bob");

         System.out.println(regularUser); // 출력: User{name='Alice', isAdmin=false}
         System.out.println(adminUser);   // 출력: User{name='Bob', isAdmin=true}
     }
 }

차이점 요약

생성자의 제약
1. 동일한 시그니처를 가진 추가 생성자를 정의할 수 없음.
2. 매개변수(false, true)의 의미를 코드만으로 명확히 알기 어려움.
정적 팩터리 메서드의 장점
1. createRegularUser, createAdminUser처럼 이름으로 객체의 특성을 설명 가능.
2. 가독성이 높아지고, 반환되는 객체의 의미를 명확히 전달 가능.

호출될 때마다 인스턴스를 새로 생성하지는 않아도 된다.

불변 클래스는 인스턴스를 미리 만들어 놓거나 새로 생성한 인스턴스를 캐싱하여 재활용
1. 대표적 예인 Boolean.valueOf(boolean) 메서드 → 객체 생성X
```
 public static Boolean valueOf(boolean b){
     return b? Boolean.TRUE : Boolean.FALSE;
     }
     Integer
     String
     Double
     Long
```
2. 특히 생성 비용이 큰 객체가 자주 요청되는 상황이라면 성능이 상당히 끌어올려준다.

플라이웨이트(Flyweight Pattern) 패턴도 이와 비슷한 기법이라 할 수 있다.

플라이웨이트 패턴? → 객체의 개수를 줄여 메모리를 절약하기 위해 사용하는 구조적 디자인 패턴 공유 객체를 사용하여 동일하거나 비슷한 객체를 중복 생성하지 않고 재사용하도록 함.

장점
1. 메모리 사용량 감소
2. 객체 생성 비용 절감
단점
1. 코드 복잡성 증가: 상태를 내부와 외부로 나누고, 객체 공유를 관리해야 하므로 코드가 복잡해질 수 있음

import java.util.HashMap;
import java.util.Map;

// 플라이웨이트 인터페이스: 공유 객체의 공통 동작 정의
interface Flyweight {
 void display(int x, int y); // 외부 상태를 받아서 객체를 동작시킴
}

// ConcreteFlyweight: 공유 객체의 실제 구현
class Character implements Flyweight {
 private final char symbol;  // 내부 상태 (공유 가능한 고정 데이터)
 private final String font; // 내부 상태 (글꼴 정보)

 public Character(char symbol, String font) {
     this.symbol = symbol;
     this.font = font;
 }

 @Override
 public void display(int x, int y) {
     // 외부 상태(x, y 좌표)에 따라 달라지는 행동
     System.out.println("Character: " + symbol + ", Font: " + font + ", Position: (" + x + ", " + y + ")");
 }
}

// Flyweight Factory: 공유 객체를 관리하고 생성
class FlyweightFactory {
 private final Map flyweights = new HashMap<>();

 // Flyweight 객체를 반환 (필요하면 생성)
 public Flyweight getCharacter(char symbol, String font) {
     String key = symbol + font; // 공유 객체를 고유하게 구분할 키
     if (!flyweights.containsKey(key)) {
         // 객체가 없으면 새로 생성
         flyweights.put(key, new Character(symbol, font));
         System.out.println("Created new Flyweight: " + key);
     }
     return flyweights.get(key); // 기존 객체 반환
 }
}

// 클라이언트 코드
public class FlyweightPatternExample {
 public static void main(String[] args) {
     FlyweightFactory factory = new FlyweightFactory();

     // 'A' 문자 객체 생성 및 재사용
     Flyweight a1 = factory.getCharacter('A', "Arial");
     Flyweight a2 = factory.getCharacter('A', "Arial"); // 이미 생성된 객체 재사용

     // 'B' 문자 객체 생성
     Flyweight b = factory.getCharacter('B', "Arial");

     // 객체 동작 (외부 상태: x, y 좌표)
     a1.display(10, 20);  // 출력: Character: A, Font: Arial, Position: (10, 20)
     a2.display(30, 40);  // 출력: Character: A, Font: Arial, Position: (30, 40)
     b.display(50, 60);   // 출력: Character: B, Font: Arial, Position: (50, 60)

     // 동일 객체 재사용 여부 확인
     System.out.println(a1 == a2); // true (같은 객체를 공유)
 }
}

반복되는 요청에 같은 객체를 반환하는 식으로 정적 팩터리 방식의 클래스는 언제 어느 인스턴스를 살아 있게 할지를 철저히 통제할 수 있다.

이러한 클래스를 인스턴스 통제 클래스라고 함

사용 이유?

싱글턴으로 만들 수 있음
인스턴스화 불가로 만들 수 있음
불변 값클래스에서 동치(equal)인 인스턴스가 단 하나뿐임을 보장할 수 있음

import java.util.HashMap;
import java.util.Map;

// 인스턴스 통제 클래스: 정적 팩터리 메서드를 사용하여 객체를 통제
public class InstanceControlledClass {

 // 내부적으로 관리되는 Map (불변 값 클래스를 위한 예시)
 private static final Map instances = new HashMap<>();

 private final String value; // 불변 값 (내부 상태)

 // private 생성자: 외부에서 직접 객체 생성 불가
 private InstanceControlledClass(String value) {
     this.value = value;
 }

 // 정적 팩터리 메서드: 동일한 값의 인스턴스는 단 하나만 존재하도록 통제
 public static InstanceControlledClass getInstance(String value) {
     // 이미 존재하는 객체가 있으면 반환, 없으면 새로 생성
     instances.computeIfAbsent(value, InstanceControlledClass::new);
     return instances.get(value);
 }

 // 값 반환 메서드
 public String getValue() {
     return value;
 }

 @Override
 public String toString() {
     return "InstanceControlledClass{" + "value='" + value + '\'' + '}';
 }

 public static void main(String[] args) {
     // 동일한 값으로 객체 생성 요청
     InstanceControlledClass obj1 = InstanceControlledClass.getInstance("A");
     InstanceControlledClass obj2 = InstanceControlledClass.getInstance("A");
     InstanceControlledClass obj3 = InstanceControlledClass.getInstance("B");

     // 출력
     System.out.println(obj1); // InstanceControlledClass{value='A'}
     System.out.println(obj2); // InstanceControlledClass{value='A'}
     System.out.println(obj3); // InstanceControlledClass{value='B'}

     // 동일한 값 객체는 동일성을 보장
     System.out.println(obj1 == obj2); // true (동일 객체)
     System.out.println(obj1 == obj3); // false (다른 객체)
 }
}

반환 타임의 하위 타입 객체를 반환할 수 있는 능력이 있다.

반환할 객체의 클래스를 자유롭게 선택할 수 있는 유연성을 가짐

API를 만들때 이 유연성을 응용하면 구현 클래스를 공개하지 않고도 그 객체를 반환할 수 있어 API를 작게 유지 할 수 있다 → 인터페이스를 정적 팩터리 메서드의 반환 타임으로 사용하는 인터페이스 기반 프레임워크를 만드는 핵심 기술

 // 인터페이스: 공개 API의 일부
 interface Shape {
     void draw();
 }

 // 구현 클래스 1: 구체적인 구현 (Circle)
 class Circle implements Shape {
     private final double radius;

     public Circle(double radius) {
         this.radius = radius;
     }

     @Override
     public void draw() {
         System.out.println("Drawing a Circle with radius: " + radius);
     }
 }

 // 구현 클래스 2: 구체적인 구현 (Rectangle)
 class Rectangle implements Shape {
     private final double width;
     private final double height;

     public Rectangle(double width, double height) {
         this.width = width;
         this.height = height;
     }

     @Override
     public void draw() {
         System.out.println("Drawing a Rectangle with width: " + width + " and height: " + height);
     }
 }

 // 정적 팩터리 메서드 제공 클래스
 class ShapeFactory {
     // 정적 팩터리 메서드: 인터페이스 타입으로 객체를 반환
     public static Shape createCircle(double radius) {
         return new Circle(radius); // Circle 객체를 반환
     }

     public static Shape createRectangle(double width, double height) {
         return new Rectangle(width, height); // Rectangle 객체를 반환
     }
 }

 // 클라이언트 코드
 public class InterfaceBasedFactoryExample {
     public static void main(String[] args) {
         // Circle 객체 생성 (Shape 인터페이스 타입으로 반환됨)
         Shape circle = ShapeFactory.createCircle(5.0);

         // Rectangle 객체 생성 (Shape 인터페이스 타입으로 반환됨)
         Shape rectangle = ShapeFactory.createRectangle(10.0, 20.0);

         // 인터페이스를 통해 메서드 호출
         circle.draw();       // 출력: Drawing a Circle with radius: 5.0
         rectangle.draw();    // 출력: Drawing a Rectangle with width: 10.0 and height: 20.0
     }
 }

자바 8전에는 인터페이스에 정적 메서드를 선언할 수 없었다.

 // Java 8 이전: 유틸리티 클래스를 사용한 정적 메서드
 public class MathUtils {
     private MathUtils() {
         // 인스턴스화 방지
     }

     public static int add(int a, int b) {
         return a + b;
     }

     public static int multiply(int a, int b) {
         return a * b;
     }
 }

자바 8부터 인터페이스가 정적 메서드를 가질 수 없다는 제한이 풀렸다.

인스턴스화 불가 동반 클래스를 둘 이유가 별로 없다.
동반 클래스에 두었던 public 정적 멤버들 상당수를 그냥 인터페이스 자체에 두면 된다
정적 메서드를 구현하기 위한 코드 중 많은 부분은 여전히 별도의 package-private클래스에 두어야 할 수 있다.(자바 8에서도 public 정적 멤버만 허용하기 때문)

자바 9에서는 private 정적 메서드까지 허락하지만 정적 필드와 정적 멤버 클래스는 여전히 public이어야 한다.

// 인터페이스: 정적 메서드를 포함할 수 있음
public interface MathUtils {

 // Java 8: 인터페이스에 정적 메서드 선언 가능
 static int add(int a, int b) {
     return a + b;
 }

 static int multiply(int a, int b) {
     return a * b;
 }

 // Java 9: private 정적 메서드 (재사용을 위해)
 private static void validateInput(int a, int b) {
     if (a < 0 || b < 0) {
         throw new IllegalArgumentException("Inputs must be non-negative.");
     }
 }

 // Java 9: private 정적 메서드 호출 예제
 static int subtract(int a, int b) {
     validateInput(a, b); // private 정적 메서드 호출
     return a - b;
 }
}

// 클라이언트 코드
public class StaticMethodInInterfaceExample {
 public static void main(String[] args) {
     // Java 8: 인터페이스의 정적 메서드 호출
     int sum = MathUtils.add(5, 10);  // 15
     int product = MathUtils.multiply(5, 10); // 50

     // Java 9: private 정적 메서드를 사용하는 subtract
     int difference = MathUtils.subtract(15, 5); // 10

     // 출력
     System.out.println("Sum: " + sum);           // Sum: 15
     System.out.println("Product: " + product);   // Product: 50
     System.out.println("Difference: " + difference); // Difference: 10
 }
}

입력 매개변수에 따라 매번 다른 클래스의 객체를 반환할 수 있다.

반환 타임의 하위 타입이기만 하면 어떤 클래스의 객체를 반환하든 상관없다. → 다음 릴리스에서 또 다른 클래스의 객체를 반환해도 된다. ex) EnumSet 클래스는 public 생성자 없이 오직 정적 팩터리만 제공 OpenJDK에서는 원소(Enum 타입의 값 → 열거형 상수)의 수에 따라 두 가지 하위 클래스 중 하나의 인스턴스를 반환함

원소 64개 이하 → long 변수 하나로 관리(RegularEnumSet)

원소 65개 이상 → long 배열로 관리(JumboEnumSet)

클라이언트는 이 두 클래스의 존재를 모른다. 만약, 원소가 적을 때, RegularEnumSet을 사용할 이점이 없어진다면, 다음 릴리스 때는 이를 삭제해도 아무문제가 없다.

비슷하게 성능을 더 개선한 3,4 번째 클래스를 다음 릴리스에 추가 할 수 있다. → 클라이언트는 팩터리가 건네주는 객체가 어느 클래스의 인스턴스인지 알 수도 없고, 알 필요도 없다. EnumSet의 하위 클래스이기만 하면 된다.

import java.util.*;

// Enum 타입: 열거형 상수
enum Day {
 MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, SUNDAY
}

// EnumSet의 상위 클래스 (공개된 API)
abstract class CustomEnumSet> {
 // 정적 팩터리 메서드
 public static > CustomEnumSet of(EnumSet elements) {
     if (elements.size() <= 64) {
         return new RegularEnumSet<>(elements); // 64개 이하일 때
     } else {
         return new JumboEnumSet<>(elements);  // 65개 이상일 때
     }
 }

 // 추상 메서드: 하위 클래스에서 구현
 public abstract void displayElements();
}

// RegularEnumSet: 64개 이하의 원소를 효율적으로 관리
class RegularEnumSet> extends CustomEnumSet {
 private final EnumSet elements;

 RegularEnumSet(EnumSet elements) {
     this.elements = elements;
 }

 @Override
 public void displayElements() {
     System.out.println("RegularEnumSet: " + elements);
 }
}

// JumboEnumSet: 65개 이상의 원소를 관리
class JumboEnumSet> extends CustomEnumSet {
 private final EnumSet elements;

 JumboEnumSet(EnumSet elements) {
     this.elements = elements;
 }

 @Override
 public void displayElements() {
     System.out.println("JumboEnumSet: " + elements);
 }
}

// 클라이언트 코드
public class EnumSetExample {
 public static void main(String[] args) {
     // EnumSet 생성 (원소 64개 이하)
     EnumSet smallSet = EnumSet.of(Day.MONDAY, Day.TUESDAY, Day.WEDNESDAY);

     // EnumSet 생성 (원소 65개 이상을 위해 더미 데이터로 확장)
     EnumSet largeSet = EnumSet.allOf(Day.class);

     // 정적 팩터리 메서드로 CustomEnumSet 생성
     CustomEnumSet smallEnumSet = CustomEnumSet.of(smallSet);
     CustomEnumSet largeEnumSet = CustomEnumSet.of(largeSet);

     // 원소 출력
     smallEnumSet.displayElements(); // 출력: RegularEnumSet: [MONDAY, TUESDAY, WEDNESDAY]
     largeEnumSet.displayElements(); // 출력: JumboEnumSet: [MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, SUNDAY]
 }

 /*
 출력 결과
     RegularEnumSet: [MONDAY, TUESDAY, WEDNESDAY]
     JumboEnumSet: [MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, SUNDAY]
 */
}

정적 팩터리 메서드의 유연성
1. 입력 매개변수에 따라 다른 클래스 객체를 반환할 수 있음.
2. 반환 타입의 하위 클래스이기만 하면 어떤 클래스 객체를 반환하든 클라이언트 코드에는 영향을 주지 않음.
구현 세부사항 캡슐화
1. 클라이언트는 내부적으로 어떤 클래스가 사용되는지 알 필요가 없음.
2. 내부 구현이 변경되어도 클라이언트 코드는 수정할 필요가 없음.
미래 확장성
1. 새로운 요구사항이나 최적화가 필요할 때, 새로운 하위 클래스를 추가하거나 기존 클래스를 대체 가능.

정적 팩터리 메서드를 작성하는 시점에는 반환할 객체의 클래스가 존재하지 않아도 된다.
1. 서비스 제공자 프레임워크를 만드는 근간 ex) JDBC
  1. ‘서비스 제공자 프레임워크’에서의 ‘제공자’는 서비스의 구현체
  2. 이 구현체들을 클라이언트에 제공하는 역할을 프레임워크가 통제, 클라이언트를 구현체로부터 분리
  쉽게 설명한다면, JDBC가 “서비스 제공자 프레임워크”의 대표적 예시인 이유는 JDBC는 클라이언트가 직접 데이터베이스 드라이버를 알 필요 없이, 프레임워크가 적절한 드라이버를 찾아 연결을 만들어주기 때문이다.
  
  JDBC는 데이터베이스와 클라이언트를 연결하는 서비스 제공자 프레임워크.
  1. 프레임워크: DriverManager
    1. 클라이언트의 요청에 따라 적절한 데이터베이스 드라이버를 찾아서 연결을 제공한다
  2. 서비스 제공자: 데이터베이스 드라이버
    1. MySQL, PostgreSQL, H2 등 다양한 데이터베이스 드라이버가 서비스 제공자 역할을 한다.
  3. 클라이언트: 애플리케이션 개발자
    1. 클라이언트는 단순히 데이터베이스 URL, 사용자 이름, 비밀번호를 DriverManager에 전달하면, 적절한 드라이버가 선택되어 연결을 제공한다.
    2. 어떤 드라이버가 사용되는지는 몰라도 된다.
2. 서비스 제공자 프레임워크는 ‘3개의 핵심 컴포넌트’로 이루어짐
  1. 서비스 인터페이스
    1. 구현체의 동작을 정의 → 클라이언트가 사용할 공통 동작을 정의.
  2. 제공자 등록 API
    1. 제공자가 구현체를 등록할 때 사용하는 API
  3. 서비스 접근 API
    1. 클라이언트가 서비스의 인스턴스를 얻을 때 사용하는 서비스 접근 API
    클라이언트는 서비스 접근 API를 사용할 때 원하는 구현체의 조건을 명시할 수 있다.
    
    조건명시 x시, 기본 구현체 or 지원하는 구현체들을 하나씩 돌아가며 반환
    
    → 유연한 정적 팩터리의 실체
    
    3개의 핵심 컴포넌트와 더불어 종종 ‘서비스 제공자 인터페이스’라는 네 번째 컴포넌트가 쓰이기도 함. 역할: 서비스 인터페이스의 인스턴스를 생성하는 팩터리 객체를 설명해줌.
```
// 1. 서비스 인터페이스: 음악 스트리밍 서비스의 공통 동작 정의
interface MusicService {
 void play(String songName);
 void stop();
}

// 2. 제공자 구현체: Spotify 구현체
class SpotifyService implements MusicService {
 @Override
 public void play(String songName) {
     System.out.println("Playing '" + songName + "' on Spotify.");
 }

 @Override
 public void stop() {
     System.out.println("Stopping Spotify.");
 }
}

// 2. 제공자 구현체: YouTube Music 구현체
class YouTubeMusicService implements MusicService {
 @Override
 public void play(String songName) {
     System.out.println("Playing '" + songName + "' on YouTube Music.");
 }

 @Override
 public void stop() {
     System.out.println("Stopping YouTube Music.");
 }
}

// 3. 제공자 등록 API:
import java.util.HashMap;
import java.util.Map;

// 제공자 관리 및 등록
class MusicServiceRegistry {
 private static final Map providers = new HashMap<>();

 // 제공자 등록
 public static void registerProvider(String name, MusicService provider) {
     providers.put(name, provider);
 }

 // 서비스 접근 API
 public static MusicService getService(String name) {
     MusicService service = providers.get(name);
     if (service == null) {
         throw new IllegalArgumentException("No music service found with name: " + name);
     }
     return service;
 }

 // 기본 제공자 반환
 public static MusicService getDefaultService() {
     if (providers.isEmpty()) {
         throw new IllegalStateException("No music services registered.");
     }
     return providers.values().iterator().next();
 }
}

//4. 클라이언트 코드
public class MusicServiceExample {
 public static void main(String[] args) {
     // 제공자 등록
     MusicServiceRegistry.registerProvider("Spotify", new SpotifyService());
     MusicServiceRegistry.registerProvider("YouTubeMusic", new YouTubeMusicService());

     // 특정 제공자 사용
     MusicService spotify = MusicServiceRegistry.getService("Spotify");
     spotify.play("Shape of You"); // 출력: Playing 'Shape of You' on Spotify.
     spotify.stop();              // 출력: Stopping Spotify.

     // 기본 제공자 사용
     MusicService defaultService = MusicServiceRegistry.getDefaultService();
     defaultService.play("Bohemian Rhapsody"); // 출력: Playing 'Bohemian Rhapsody' on Spotify.
 }
}
```
  코드 설명
  1. 서비스 인터페이스
    1. MusicService는 모든 음악 스트리밍 서비스가 따라야 할 규칙(재생, 정지)을 정의
  2. 제공자 등록 API
    1. MusicServiceRegistry.registerProvider를 사용해 SpotifyService와 YouTubeMusicService를 등록함.
    2. 새로운 음악 서비스가 추가된다면 이 API를 통해 간단히 등록 가능하다.
  3. 서비스 접근 API
    1. getService("Spotify")를 사용하면 Spotify 서비스 구현체를 반환한다.
    2. 조건 없이 호출할 경우 getDefaultService를 통해 첫 번째 등록된 서비스를 반환한다.

단점
1. 상속을 하려면 public이나 protected 생성자가 필요하니 정적 팩터리 메서드만 제공하면 하위 클래스를 만들 수 없다
  1. 컬렉션 프레임워크의 유틸리티 구현 클래스들은 상속할 수 없다.
  2. 상속 보다 컴포지션 사용 하도록 유도하고 불변 타입으로 만들려면 이 제약을 지켜야한다.(장점으로 작용할 수 있음)
2. 정적 팩터리 메서드는 프로그래머가 찾기 어렵다.
  1. 생성자처럼 API 설명에 명확히 드러나지 않으니 사용자는 정적 팩터리 메서드 방식 클래스를 인스턴스화할 방법을 알아내야한다. → API 문서 잘 쓰기, 메서드 이름도 널리 알려진 규약을 따라 짓는 식으로 문제를 완화해줘야 한다.
    
    → 그래서 쓰는 정적 팩터리 메서드에서 흔히 사용하는 명명 방식:
  2. from
    1. 하나의 매개변수를 받아 해당 타입의 인스턴스를 반환.
    2. 예제: Date d = Date.from(instant);
  3. of
    1. 여러 매개변수를 받아 적합한 타입의 인스턴스를 반환.
    2. 예제: Set faceCards = EnumSet.of(JACK, QUEEN, KING);
  4. valueOf
    1. from과 유사하지만, 더 의미 있는 이름을 제공.
    2. 예제: BigInteger prime = BigInteger.valueOf(Integer.MAX_VALUE);
  5. instance 또는 getInstance
    1. 매개변수 유무와 상관없이 특정 인스턴스를 반환.
    2. 예제: StackWalker luke = StackWalker.getInstance(options);
  6. create 또는 newInstance
    1. 새 인스턴스를 생성해 반환.
    2. 예제: Object newArray = Array.newInstance(classObject, arrayLen);
  7. getType
    1. getInstance와 비슷하지만, 반환 객체의 타입을 명확히 설명.
    2. 예제: FileStore fs = Files.getFileStore(path);
  8. newType
    1. newInstance와 비슷하지만, 반환 객체의 타입을 명확히 설명.
    2. 예제: BufferedReader br = Files.newBufferedReader(path);
  9. type
    1. getType 또는 newType에서 “get”이나 “new”를 생략한 간단한 형태.
    2. 예제: List litany = Collections.list(legacyLitany);

핵심 정리:

정적 팩터리 메서드와 public 생성자는 각자의 쓰임새가 있으니 상대적인 장단점을 이해하고 사용할 것. 그렇지만, 정적 팩터리를 사용하는게 유리한 경우가 더많으므로 무작정 public 생성자를 제공하던 습관이 있다면 고치자.

🧑🏻‍💻3일이란 짧은 시간이 아쉬웠던, AWS_리빙랩 글로컬 해커톤 후기📋

Sun, 28 Jan 2024 18:14:36 GMT

1. 10명뽑는데 그 10명안에 들기 🏃

열심히 자소서를 쓴 덕분에 LINC사업단에서도 알아주셨는지 운좋게 많은 사람들을 뚫고 선발이 되었다. 그래도 선정된만큼 사전OT도 열심히 듣고 수업도 열심히 들었다.

2. AWS 온라인 사전강의 듣기. 🖥️

7시간 반 짜리 코스라지만, 필기하면서, 잘 모르는 내용을 검색해보면서 하려니 20시간 가까이 이 수업을 들은것 같다. 그래도 열심히 들은 덕분에 멘토님들께서 수업을 할때, 조금이나마 알아들을 수 있었다.

3. 나인트리 호텔(판교)에서 시작 🚌

다 들은 다음날, 판교로 출발을 했다. 학교에서 출발했는데 2시간 남짓 걸렸던것 같다. 그래도 정말 많은 학교들이 와있었다. 강원대, 경상국립대, 서울과학기술대, 연암공과대, 인천대 연합으로 진행된 해커톤이라서, 60명의 인원이 있었다. 그래도 앞에서 들어야 잘보이고, 잘 듣겠지라는 생각으로 두번째 좌석에 앉았다. 같이 선정된 친구가 없어서 혼자 갔는데, 옆에 앉은 경상국립대 친구가 이야기를 걸어줘서 한층 마음이 편했고, 내 기준 오른쪽에도 그 친구의 경상국립대 친구들이 있었는데, 말을 걸어주고, 나만의 생각일진 모르겠지만, 짧은 시간에도 많이 친해질 수 있었다. 같은팀이 되자! 라고 외쳤던 우리의 예상과는 달리 학교별로 찢고, 랜덤배정이여서 모두 같은 팀이 되진 못했다ㅋㅋㅋㅋ(그래도 이때 정을 많이 느꼈다)

4. 약간은 살인적인 Schedule..?? 📋

맨 마지막에 전문가 멘토링 및 개발 진행 ⭐️(무박)⭐️ 이라고 되어있는 저 일정표를 보고 "진짜? 아니지? 에이 뭐 당직 서는 것도 아니고~"했던 예상과는 다르게 진짜였다. 팀빌딩할때, 팀장여부 가능이라해놔서, 자연스레 내가 3조 팀장이 되었다.(역시 천상 ENTJ인 나...⭐️)

5. 그래도 재미있는 교육들 📚

(역시 대학생들은 장난에 진심이다)

AWS를 활용한 교육을 들으며, 어떤식으로 돌아가는지, AWS콘솔에서 Cloud9 IDE를 통해 EC2에 엑세스를 하며, 어떻게 서버 실행이되는지 참 잘알게되었다. 정말 자세히 알려주셔서 잘 따라하고, 이해할 수 있었다. 그리고 정말 재미있던건, 강사님이 자신것에 접근이 안되는 학생들에게 한해 강사님의 RDS를 열어주셨는데, 여러명이 장난을 쳤다. (ㅋㅋㅋㅋ강사님을 놀리는데 진심인 사람들) 그래도 웃으며 수업을 들을 수 있었고, 강사님도 재미있어하시는 분위기였다. 그래도 삭막한 분위기도 아니였고, 그렇게 경쟁자로만 생각하는 분위기는 아니여서 참 다행이였다.

6.Slack?알고는 있었지만, 회사생활하기 참 좋겠는걸? 🤩

멘토님들이 정말 많이 강조를 하셨다. 슬랙이 정말 간편하다고. 이 전에는 편한 카톡도 있는데, 메신저일 뿐 아닌가? 라는 생각뿐이였다. 그냥 공적인 느낌의 메신저, 단톡아닌가?라고 예전엔 생각했다. 하지만 아니였다. 3일동안 이 슬랙으로 협업하고, 슬랙으로 챗봇 프로그램을 개발하며, 협업과 기록을 하기에 정말 좋다는 생각이 들었다. 왜 그렇게 멘토님들이 강조를 했는지 알것 같다. (한 멘토님이 "저희 슬랙한테 광고받은거 아니에요"라고 할만큼 강조를 하시긴했다.)

7. 2일차 - 진짜 해커톤의 시작(밤샘 시작!) 🤯

(멘토님1 + 5명의 구성원) 다른 팀도 마찬가지로 모두 다른학교로 구성된 팀으로 짜여졌다. 하지만 우리조엔 인천대는 없었다.(우리는 강원대, 강원대, 경상국립대, 연암공대, 서울과기대 였다.) 각설하고, 우리의 팀명은 나대신해조였다. 우리 조는 나름(?)재미있는 이름으로 지었다고 생각한다. 조원의 좋은 작명센스로ㅎㅎ 컨셉은 명확했다. AI가 무언가 대신해준다는 생각으로! 우리는 오후 11시 반까지 회의를 했고, '한자어,신조어 번역 챗봇'으로 정했고, 구체화 및 개발을 했다. 이런 것이 진짜 개발인가? 팀원들과 이렇게까지 한적이 있었나 싶었다. 5명이 '협업'하면서 'Struggling'한 느낌은 처음이였다. 이렇게 까지 무엇인가 새로운걸 개발하며 매달려본적이 있던가, 나 자신을 더 반성하며 나아갔다. 조원들이 졸면서도 열심히 하는것을 보며, 나도 열심히 해야지 라는 생각으로 나아갔다.

8. 개발성공...?인가요? 실패? 그래도 "오히려 좋아"😊

우리 조가 만든것은 챗봇으로 세대갈등을 해결하자!를 모티브로 만든 "한자어, 신조어 번역기"이다.

먼저 한자어나 신조어를 말하면,
바로밑에 말풍선에서 자동으로 번역을해준다.
상대방의 말도 번역을 해준다. 우리 챗봇의 메커니즘이다. 처음에 멘토분들과 심사위원분들이 신박해 하긴했는데, "구현하기 어려울 것이다, 자료가 너무 없을뿐더러, 신뢰있는 사이트를 찾기 힘들다."라는 이야기를 하신것이 기억이 난다. 그래도 어떻게든 만들긴해서, 시간이 있다면, 다음에 어떻게 구현할지도 생각해놨다. 우리 조원들이 정말 자랑스러웠다. 사실 등수안에 들진 못했지만, 그래도 구현될때까지, 끝까지 붙잡은 우리 조원들이 자랑스러웠다. 사실 이런 경험도 나에겐 중요하다. 무조건 상을 받는게 아니란 사실을. 이렇게 열심히 조원들과 협업하며 달려나간것이, 그 자체로도 의미가 있다는것을. 상을 받고싶었던 것은 맞지만, 자기소개서에도 쓸 당당한 스토리가 하나 더 생겼기 때문에, 뜻깊은 경험이었다.

9. 3일차..? 비몽사몽, 긴장되는 발표 시작😅

나름 열심히 발표한다 했는데, 밤을 샜고, 앞에 심사위원분들이 있어 긴장된 탓인지, 발표를 많이 절었다. 분명 대본도 써가지고 갔는데 엄청 절었다. 비몽사몽한 탓인가 싶었지만, 사실 변명하고 싶지도 않다. 오히려 조원들한테 미안했다. 내가 잘못 발표해서 우리의 구현 결과가 높게 평가가 안된것은 아닌지, 분명 이 전에 멘토님들이 흥미 있어하던 주제인데, 좋지않은 내 발표를 듣고나서 등수 안에 못든건지.. 사실 내탓을 좀 했다. 물론 다른 팀이 못했다는건 아니다. 12팀이 있었는데, 12팀 모두 결과가 좋았고, 실제로 신기한것도 많았다. 12팀 전부 출중했다. 제일 기억에 남는건, 주차공유시스템, 내가 실제로 앱개발 프로젝트로 진행 중인 여행 서비스, 계단 지도 서비스..정도 있다. 하지만 우리팀 모두가 고생했기에, 정말 난 안타까웠다. 내가 조금 더 빨리 결정했더라면, 내가 조금 더 개발을 잘했더라면, 내가 조금 더 발표를 잘했더라면.. 자책을 했던 것 같다.

하지만 그럼에도 배운것이 있었다. 내가 무엇을 잘하는지, 어떤 것을 더 배워나가야하는지를.

AWS 리빙랩 글로컬 해커톤은 나에겐 그런 해커톤이었다. AWS 클라우드 환경만 배운것이 아닌 나의 개발자로서의 커리어를 잘 알려주는 해커톤이었다.

Fin. 후기 마무리.

정말 배울 것이 많았던 해커톤이었다. 졸업유예를 한 현재, 만약 이런 기회가 한번 더 있다면, 무조건 한번 더 참가하고, 개발자를 꿈꾸는 친구들에게도 추천할 것이다. 이런 경험은 돈주고도 못살 것 같다. 밤새 토론하고, 개발하며, 같은 목표를 위해 나아가는것을. 해커톤이란 것이 짧은 시간 내엔 완벽하게 개발은 못하지만, 그래도 이번 AWS해커톤은 열정을 가지고 한다면 분명 배울것이 있고, 개발자를 꿈꾸는 자로서 개발자로 한걸음 더 가는 기회가 아닌가 싶다.

PS. 💌

이 교육과정을 모두 가르쳐주신 멘토님들 정말 감사합니다. 덕분에 많은 것을 배웠습니다.
우리 3조 정말 고생 많았습니다! 덕분에 이런 경험도해보고, 우리 조원들 끝까지 포기하지 않고 달려주신 것에 대해 정말정말 감사합니다.
혼자 해커톤을 갔는데, 친하게, 친절하게 대해준 참가자분들 너무 감사합니다. 덕분에 편히 같이 수업도 듣고, 3일간 재미있게 있을 수 있었습니다.
AWS 리빙랩 글로컬 해커톤에 참가한 분들 모두가 수고많으셨습니다. 앞으로에 개발길의 꽃길만 가득하길!

많이 늦은(?) 개발자 컨퍼런스 참가 후기(Samsung Developer Conference Korea 2023)

Mon, 15 Jan 2024 02:37:44 GMT

(SDC23 Korea가 열렸던 강당, 삼성전자 서초사옥)

Why? 취준하는 대학생이 간 이유?

1. 개발자가 되고싶다. 근데 현업에서 뭘 쓰는지 어디서 알아봐? 🧑🏻‍💻

"근데, 이 부분은 현업에서 잘 안쓰여요. 하지만 실습을 위해 해봅시다."

인터넷에서 개발 강의를 들을때 이 말을 참 많이 듣는다. 물론 강사님들이 현업에서 어떻게 쓰는지, 어떤게 쓰이는지 알려주는 경우도 많지만, 실제로 어디에, 어떻게 쓰이는지 보고싶었다. 또한 현업에 종사하는 개발자분들의 공부 방법도 질문하면서 듣고싶었다. 신입이며, 인턴이며 지원하는 것 마다 다 낙방했기에, 4학년인 나로선, 할 수 있는 최선을 다 하고싶었다.

2.SDC23 Korea에서 커리어 상담을 해준다고? 🗣️

"SDC23 Korea에서는 커리어톡을 진행합니다."

SDC23 Korea 광고를 처음 보았을때, 내가 가면 잘 알아들을 수 있을까? 어떤 기술인지 알고? 그래 그냥 가서 듣고, 적어 놓고 공부하자. 이 생각으로 가려했다. 그런데 Career talk 부스가 따로 있다는 이야기를 보자마자, 바로 사전등록을 마쳤다. 삼성전자에서 커리어 상담을 해준다는데 취준생이 마다할 이유가 없었다. 내 목표인 기업에서 나에게 해주는 이야기를 듣고싶었다.(사실 제일 간절했다.)

3. 개발자는 평생 공부해야하는 직업 📚

"공부를 안하면 그것이 제일 적나라하게 드러나는 직업, 성공을 위해서는 관련 기술을 계속해서 공부를 해야만 하는 직업"

어떠한 직업이든 관련해서 공부를 해야하는것은 당연하다. 하지만 개발자가 특히 더 그러한 이유는 다른 직업보다 기술 및 트렌드의 변화가 매우 빠르기 때문이다. 사실, 이 세상에는 700개이상의 프로그래밍 언어가 존재한다. 용도에 따라 다르기 때문인데, 현재 다 공부할수는 없기에, 내가 지금 무엇을 공부해야할지, 앞으로 어떻게 공부 해나가야할지 대비하기위해 컨퍼런스를 가려했다.

Samsung Developer Conference Korea 2023 후기

1. 다양한 현업 개발자가 발표하는 세션들

나는 이틀 둘다 참가하는 것으로 했다. 첫번째날 다 듣고 돌아오면서 첫번째로 든 생각은 세상에는 다양한 기술들이 개발되고 있구나, 내가 어떻게 기여를 할 수 있을까? 였다. 현재 어떤 기술을 사용하고있는지, 어떠한 방법으로 프로젝트를 진행하는지, 어떤 방법으로 개발을 하고, 공부하는지에 대해 다 배울 수 있었다. 나는 정말 좋은 기회라 생각했고, 많은 사람을 보고, 다양한 기술을 보고 느낀점은, '열심히 개발 공부를 해야겠다.' 였다. 어떠한 Flow로 그 기술이 돌아가고, 어떠한 방식으로 팀을 운영하며, 개발 공부를 할때 어떠한 관점으로 했는지 등 여러가지 현업 개발자 분들의 발표를 들으며 경청하며, 필기도하고, 길을 잡을 수 없었던 내가 나아갈 방향을 잡는데 도움이 된 정말 좋은 기회였다.

(각 세션에서 무엇을 발표하는지 밖에서 보기 쉽게 세워 두었다.)

2. 현재 삼성전자의 다양하고 신기한 기술을 볼 수 있는 전시 부스

'와 이런것도 구현이 된다고?' 의 연속이였다. 소프트웨어의 취약성을 발견해주는 S-Ray라던지 참 신기한게 많았다. 특히 평소 임베디드 시스템을 좀 다뤄본 탓인가, IOT기기에 눈이 간건 어쩔 수 없었다. 전시 부스에서 matter 표준에 대해서 자세히 설명해주시고, IOT기기가 어떠한 형식으로 돌아가는지, 타사 기기와 어떻게 맞게 돌아가는지에 대해 설명해주셨다. 역시 그러한 표준이 없었으면 불편했을 것 같다. 역시 기기 개발에도 다양한 회사가 얽혀있는 것 같았다. 이 외에도 다양한 기술이 준비되어있었는데, 삼성 헬스관련 오픈소스, vision인식 기반 오븐 등 신기한 것이 많았다.

(matter 표준 마크)

컨퍼런스 관련 첫번째 글을 끝마치며...

개인적으로는 매우 만족했다. 아니, 좋은 기회였다.

정말 다양한 기술에 눈을 뜨고 다른 컨퍼런스에도 관심이 가게 되었다. 다양한 기술들에 대해 사람들이 토론하고, 발표를 듣는게, 매우 인상깊었다. 개발 취준생은 Refresh할겸 가는 것도 좋을 것 같다. 물론 아직 취직을 못해본 학생이지만, 가서 현직 개발자 분들과 만나고, 네트워킹도 해보는 시간을 가져보는 것도 좋을 것 같다. 현재 회사들이 어떤 것들을 중점적으로 다루는지를 볼 수 있게 된 좋은 계기인 것 같다. 이제 껏 쓴, 나의 이야기를 한 줄로 정리하자면,

내가 개발 공부를 할때 우왕좌왕 하던 중, SDC23 Korea가 중심을 잡아주는 역할을 해주었다.

다른 후기로, 취준생이란 것을 어필하고, IT기술에 관심있어 하다보니, 현직 개발자분들이 어떻게 공부해야 할지, 어떤식으로 나아가야 할지에 대해서 정말 친절히 설명해주셨다. 그리고 면접 대응법까지, 상세히 설명해주셨다. 나는 웰컴키트로 받은 펜과 노트로 받아 적으며, 열심히 하겠다고 다짐하며 2일차까지 개발자분들의 발표를 듣고, 네트워킹을 했다.

앞으로 정말 열심히해서 좋은데 가야겠다.

Linux? Ubuntu? 암튼, 니가 뭔데 날 괴롭혀?🫤 (feat. OS:Operating System, MBTI)

Sun, 05 Mar 2023 23:39:56 GMT

😒Linux? 그게 뭔데?

'Unix'기반 OS (Unix based OS)

Unix? 넌 또 뭐야?🤨라고 하실겁니다. Unix는 운영체제(OS) 중 하나입니다. Linux는 컴퓨터 분야에 관심이 조금 있다면 어느정도 들어는 봤을겁니다. 저도 정말 있다 정도만 들어봤을 정도니깐요. ~~(써볼 생각은 못했음)~~ 그런데 Unix? 조금 생소했습니다. 이 OS는 'C와 어셈블리어로 이루어진 교육 및 연구 기관에서 즐겨 사용되는 범용 다중 사용자 방식의 대화식, 시분할처리 시스템용 운영 체제' 라고 조금 검색해보시면 나옵니다. 쉽게 말해서, 거의 '서버(Server)' 에 특화된 OS입니다. 그럼 서버에만 자주 쓰일까? 그건 또 아닙니다. 개인PC에서도 잘 쓰입니다. 대표적으로는, 여러분들이 많이 아시는 Apple 사의 'Mac OS' 가 있습니다.

E인 아들(Linux), I인 아버지(Unix)

제가 위에서 말씀 드렸듯, Linux는 Unix기반으로 태어났습니다. ~~펭귄 마스코트가 참 귀엽다.~~ MBTI가 요즘 유행이죠? 굳이 비유를 하자면 Unix는 'I'(introvert) 성향이 짙은 아빠(Unix), 'E'(extrovert) 성향이 짙은 아들(Linux)이라고 볼 수 있겠네요.~~(IU...EL..?)~~ Unix는 독점적 성격을 가진 OS입니다. 그래서 버그나 위협이 나타나면 IBM에서 패치프로그램이 나올때까지 이용자는 한없이 기다려야하고, 소스코드 또한 저작권이있어 베일에 싸여있습니다. 밖을 나가기 싫어하죠. 하지만, 많은 자식 중 'Linux' 란 아들이 여기저기 놀러다니며 많은 사용자들과, 많은 기기들과 친해지며 성장해 나갔습니다. Linux는 독점적이지 않은,** Open-Source** 입니다. 그래서, 버그가 나타나거나 위협이 나타나면, 사용자들 혹은 기업들이 발벗고 나서서 고쳐주죠.

Linux, 그래도 이젠 어른.(feat. Ubuntu, Android)

이 아들도 커서 Ubuntu, Fedora, Red Hat, Debian,** Android** ,Cent OS 등 많은 자식, 손자들을 가지게 됩니다.

네, 임베디드(Embedded)에서 흔히 사용하는 그 Ubuntu 맞고요, 그 유명한 구글(Google)의 Android 맞습니다. 유명한 것들도 개방적인 Open Source인 것을 보면, Linux의 영향을 많이 받았다는 것을 볼 수 있습니다.

Linux의 사용이유 (부제: Windows가 안되는 이유)

그래서? Linux 왜쓰는데? 그냥 윈도우 쓰면 안돼?😕

Windows OS

네, Windows는 쉽고 직관적이죠, 많은 사용자들의 편의를 위해 만들어진 OS이다 보니 편리하죠. 다만, 단점이 있습니다.

❗보안성 문제 Windows는 보안이 취약하여 보안이 특히 중요한 서버의 구성에 윈도우를 사용하기엔 적합하지 않습니다. 또한 기계에 들어가는 독립적 장치인 임베디드 시스템에도 보안이 중요하기에 적절하지 않습니다. ❗트래픽 문제 Windows는 많은양의 네트워크 부하를 감당하지 못합니다. 어떠한 프로그램이든 서버가 금방 터지면 안되겠죠. 따라서 적절하지 않습니다. ❗크기 문제 Windows의 용량은 정말정말 큽니다. 소형의 칩셋들, 작은 스펙을 가진 임베디드 컴퓨터들이 감당할 수 없습니다. ❗소스 문제 Windows는 IBM에서 관리하는 Unix와 비슷하게 Microsoft사에서 관리하기 때문에 유저들이 여러 문제가 생겼을때 대처하기가 힘듭니다.

Closing remarks.

사실, 리눅스(정확히는 우분투를 쓰고있다.)는 저에게 있어서 적이였습니다. 터미널에 들어가 명령어를 하나하나 쳐서 어떤걸 구동시키고, 파일에 들어가고, 설치하고.. 직관적으로 화면으로 결과가 보이는 윈도우와 맥 유저로서 익숙치 않았기때문입니다. 하지만 사용 이유와 그 특징에 대해 알았으니, 지금 프로젝트에서 사용하고있는 만큼 잘 쓰려합니다.