데이터 무결성을 관리하는 데 있어서 트랜잭션 매니저는 자바 애플리케이션에서 매우 중요한 역할을 합니다. 이번 포스팅에서는 자바의 기본 트랜잭션 매니저 인터페이스와 그 구현체들을 알아보겠습니다. 트랜잭션 매니저란? 트랜잭션 매니저는 여러 데이터베이스 작업이 하나로 묶일 수 있도록 관리해주는 구성 요소입니다. 이는 모든 작업이 성공적으로 완료되거나, 하나라도 실패할 경우 전체 작업을 원상태로 되돌리는 'All or Nothing'의 원칙을 보장합니다.

자바의 기본 트랜잭션 매니저와 그 구현체들

데이터 무결성을 관리하는 데 있어서 트랜잭션 매니저는 자바 애플리케이션에서 매우 중요한 역할을 합니다. 이번 포스팅에서는 자바의 기본 트랜잭션 매니저 인터페이스와 그 구현체들을 알아보겠습니다. 
 
트랜잭션 매니저란?
트랜잭션 매니저는 여러 데이터베이스 작업이 하나로 묶일 수 있도록 관리해주는 구성 요소입니다. 이는 모든 작업이 성공적으로 완료되거나, 하나라도 실패할 경우 전체 작업을 원상태로 되돌리는 'All or Nothing'의 원칙을 보장합니다. 자바에서는 주로 JTA(Java Transaction API)를 이용하여 트랜잭션을 관리합니다.
 
스프링과 트랜잭션 매니저
스프링 프레임워크에서는 더 편리하게 트랜잭션을 관리할 수 있는 추상화된 트랜잭션 매니저를 제공합니다. PlatformTransactionManager 인터페이스는 스프링의 다양한 트랜잭션 매니저가 구현하는 기본 인터페이스이며, 구현 클래스에는 DataSourceTransactionManager, JpaTransactionManager 등이 있습니다.
 
이러한 구현체들은 애플리케이션의 데이터 접근 방식에 따라 적합한 트랜잭션 관리 방법을 제공합니다. 가장 일반적으로 사용되는 몇 가지 PlatformTransactionManager 구현체와 그 특징에 대해 설명하겠습니다.
 
DataSourceTransactionManager
JDBC를 직접 사용할 때 주로 이용합니다. 이 구현체는 데이터 소스를 통해 직접 커넥션을 관리하고, JDBC의 기본 트랜잭션 API를 이용하여 트랜잭션을 처리합니다. 간단하고 직관적이어서 JDBC 기반의 데이터베이스 작업에 매우 적합합니다.
 * 단일 JDBC 데이터 소스에 대한 트랜잭션 관리에 최적화되어 있습니다.
 * 다른 리소스와의 트랜잭션을 관리할 수 없기 때문에 JTA와 같은 분산 트랜잭션 환경에서는 사용하기 어렵습니다.

HibernateTransactionManager
Hibernate 세션과 트랜잭션을 관리하기 위해 설계되었습니다. 이 매니저는 Hibernate 세션을 현재 스레드에 바인딩하고, 트랜잭션이 시작될 때 세션을 열고 종료할 때 세션을 정리합니다.
 * Hibernate 세션과 생명주기를 동기화하여 안정적인 세션 관리를 가능하게 합니다.
 * Hibernate를 사용하는 애플리케이션에서 데이터에 접근하는 코드의 일관성을 유지하도록 도와줍니다.
 * 다른 데이터 접근 기술과 함께 사용할 경우, JTA를 사용하는 것이 더 적합할 수 있습니다.

JpaTransactionManager
JPA를 사용하는 애플리케이션에서 엔티티 매니저의 생명주기와 트랜잭션을 관리합니다. 이 매니저는 JPA 엔티티 매니저를 스프링 프레임워크의 트랜잭션 관리 프레임워크에 통합하여 사용합니다.
 * JPA 기반의 애플리케이션에서 트랜잭션과 엔티티 매니저의 통합 관리를 제공합니다.
 * 데이터베이스 기술의 추상화를 지원하므로, 다양한 데이터베이스 기술에 쉽게 적용될 수 있습니다.

결론
PlatformTransactionManager의 다양한 구현체들은 자바 스프링 프레임워크에서 각기 다른 데이터 접근 기술에 따른 트랜잭션 관리를 가능하게 합니다. 이를 통해 개발자들은 애플리케이션의 요구 사항에 맞는 최적의 트랜잭션 관리 전략을 선택하고 구현할 수 있습니다. 각 구현체의 특성을 이해하고 적절히 활용하면, 데이터의 일관성과 무결성을 효과적으로 유지하면서 안정적인 애플리케이션을 구축할 수 있습니다.

데이터 무결성을 관리하는 데 있어서 트랜잭션 매니저는 자바 애플리케이션에서 매우 중요한 역할을 합니다. 이번 포스팅에서는 자바의 기본 트랜잭션 매니저 인터페이스와 그 구현체들을 알아보겠습니다.&nbsp;&nbsp;트랜잭션 매니저란?트랜잭션 매니저는 여러 데이터베이스 작업이 하나로 묶일 수 있도록 관리해주는 구성 요소입니다. 이는 모든 작업이 성공적으로 완료되거나, 하나라도 실패할 경우 전체 작업을 원상태로 되돌리는 'All or Nothing'의 원칙을 보장합니다. 자바에서는 주로 JTA(Java Transaction API)를 이용하여 트랜잭션을 관리합니다.&nbsp;스프링과 트랜잭션 매니저스프링 프레임워크에서는 더 편리하게 트랜잭션을 관리할 수 있는 추상화된 트랜잭션 매니저를 제공합니다. PlatformTransactionManager 인터페이스는 스프링의 다양한 트랜잭션 매니저가 구현하는 기본 인터페이스이며, 구현 클래스에는 DataSourceTransactionManager, JpaTransactionManager 등이 있습니다.&nbsp;이러한 구현체들은 애플리케이션의 데이터 접근 방식에 따라 적합한 트랜잭션 관리 방법을 제공합니다. 가장 일반적으로 사용되는 몇 가지 PlatformTransactionManager 구현체와 그 특징에 대해 설명하겠습니다.&nbsp;DataSourceTransactionManagerJDBC를 직접 사용할 때 주로 이용합니다. 이 구현체는 데이터 소스를 통해 직접 커넥션을 관리하고, JDBC의 기본 트랜잭션 API를 이용하여 트랜잭션을 처리합니다. 간단하고 직관적이어서 JDBC 기반의 데이터베이스 작업에 매우 적합합니다.<ul ><li>단일 JDBC 데이터 소스에 대한 트랜잭션 관리에 최적화되어 있습니다.</li><li>다른 리소스와의 트랜잭션을 관리할 수 없기 때문에 JTA와 같은 분산 트랜잭션 환경에서는 사용하기 어렵습니다.</li></ul> HibernateTransactionManagerHibernate 세션과 트랜잭션을 관리하기 위해 설계되었습니다. 이 매니저는 Hibernate 세션을 현재 스레드에 바인딩하고, 트랜잭션이 시작될 때 세션을 열고 종료할 때 세션을 정리합니다.<ul ><li>Hibernate 세션과 생명주기를 동기화하여 안정적인 세션 관리를 가능하게 합니다.</li><li>Hibernate를 사용하는 애플리케이션에서 데이터에 접근하는 코드의 일관성을 유지하도록 도와줍니다.</li><li>다른 데이터 접근 기술과 함께 사용할 경우, JTA를 사용하는 것이 더 적합할 수 있습니다.</li></ul> JpaTransactionManagerJPA를 사용하는 애플리케이션에서 엔티티 매니저의 생명주기와 트랜잭션을 관리합니다. 이 매니저는 JPA 엔티티 매니저를 스프링 프레임워크의 트랜잭션 관리 프레임워크에 통합하여 사용합니다.<ul ><li>JPA 기반의 애플리케이션에서 트랜잭션과 엔티티 매니저의 통합 관리를 제공합니다.</li><li>데이터베이스 기술의 추상화를 지원하므로, 다양한 데이터베이스 기술에 쉽게 적용될 수 있습니다.</li></ul> 결론PlatformTransactionManager의 다양한 구현체들은 자바 스프링 프레임워크에서 각기 다른 데이터 접근 기술에 따른 트랜잭션 관리를 가능하게 합니다. 이를 통해 개발자들은 애플리케이션의 요구 사항에 맞는 최적의 트랜잭션 관리 전략을 선택하고 구현할 수 있습니다. 각 구현체의 특성을 이해하고 적절히 활용하면, 데이터의 일관성과 무결성을 효과적으로 유지하면서 안정적인 애플리케이션을 구축할 수 있습니다.

덕토피아

🕊️ 자바의 기본 트랜잭션 매니저와 그 구현체들

이번에 소개할 개발자는 백엔드 분야에서 활동하며, 한 회사에서 올해 만 10년 차를 맞이한 인물입니다. 현재 네이버쇼핑에서 ‘패션타운’ 서비스를 개발하고 있는 권태관 개발자가 그 주인공인데요. ‘네이버’라는 한 회사에서만 10년이라는 긴 시간을 보낸 만큼, 그가 참여했던 서비스도 쥬니버, 날씨, 네이버페이, V Live, 쇼핑라이브 등 다양합니다. 권태관 개발자에게 지난 10년은 개발자로서 다양한 경험을 쌓으며, 성장할 수 있었던 시간이었는데요. 어느덧

어제보다 1cm 더 성장하기: 네이버 권태관 개발자 | 요즘IT

성장하는 개발자에 대해 인터뷰 한 내용을 공유 드립니다. 이번 인터뷰를 하면서 질문에 대한 답변을 하다보니 제 자신을 다시 돌아볼 수 있는 기회가 되었고 더 단단해져야겠다 라는 생각도 들었던 좋은 기회로 기억될 것 같습니다. 인생, 그리고 개발자 커리어에 정답이나 따라야만 하는 로드맵은 없겠지만 계속 성장에 대한 고민을 스스로 하다보면 자신만의 호흡이 생기지 않을까 싶더라구요.

https://yozm.wishket.com/magazine/detail/2539/

성장하는 개발자에 대해 인터뷰 한 내용을 공유 드립니다. 이번 인터뷰를 하면서 질문에 대한 답변을 하다보니 제 자신을 다시 돌아볼 수 있는 기회가 되었고 더 단단해져야겠다 라는 생각도 들었던 좋은 기회로 기억될 것 같습니다. 인생, 그리고 개발자 커리어에 정답이나 따라야만 하는 로드맵은 없겠지만 계속 성장에 대한 고민을 스스로 하다보면 자신만의 호흡이 생기지 않을까 싶더라구요. https://yozm.wishket.com/magazine/detail/2539/

요즘IT

어제보다 1cm 더 성장하기

HashMap is Hash table based implementation of the Map interface. This implementation provides all of the optional map operations, and permits null values and the null key. (The HashMap class is...

Barclays Java Spring-Boot Micro-service Interview Question with answer 2024

Finally 블록에서 예외가 발생하면 어떻게 되나요?
자바에서, try-catch에서 finally 블록 내에서 예외가 발생할 때의 동작은, try-catch 블록의 예외 처리와 약간 다릅니다. 
 
[Try-Catch 블록의 예외]
 * 정상적인 플로우가 중지됩니다.
 * 예외 유형과 일치하는 catch 블록이 있다면, 해당 블록 내의 코드가 실행됩니다. 이를 통해 예외를 처리할 수 있습니다.
 * catch 블록이 완료되거나 어떤 catch 블록과도 일치하지 않으면 finally 블록의 코드가 실행됩니다.
[Finally 블록의 예외]
 * 원래의 예외가 중지됩니다. 이는 원래의 예외가 메서드 호출자에게 전달되지 않는 것을 의미합니다.
 * finally 블록에서 던진 예외가 호출자에게 전파되는 새로운 예외가 됩니다.
[키 포인트]
 * finally 블록은 try-catch 블록에서 예외가 발생하는지 여부에 관계없이 항상 실행됩니다.
 * finally 블록의 예외는 원래의 예외를 억제합니다.
 * finally 블록에서 던진 예외는 호출자가 처리해야 하는 새로운 예외가 됩니다.
[Finally 블록의 쓰임새]
 * 리소스(데이터베이스 연결, 파일 클로징)를 해제합니다.
 * 예외에 관계없이 항상 수행해야 하는 정리 작업을 처리합니다.
 
자바의 다이아몬드 문제란 무엇인가요?
"다이아몬드 문제"란 여러 상속 시나리오에서 발생하는 특정한 문제를 의미합니다. 클래스 상속 다이어그램을 그릴 때 발생하는 다이아몬드 모양에서 이름을 따왔습니다.

 1. 자바의 접근방식: 자바는 클래스의 다중상속을 지원하지 않습니다. 그러나 자바는 인터페이스의 다중상속은 허용합니다. 
 2. 자바 인터페이스의 다이아몬드 문제: 클래스가 두 개의 인터페이스를 구현하고 두 인터페이스가 모두 동일한 메소드명을 가진다면, 구현 클래스는 모호성을 해결하기 위해 메서드를 자체적으로 구현해야 합니다.
interface InterfaceA {
    default void display() {
        System.out.println("Inside InterfaceA");
    }
}

interface InterfaceB {
    default void display() {
        System.out.println("Inside InterfaceB");
    }
}

class MyClass implements InterfaceA, InterfaceB {
    // Here, we must provide our own implementation of display to resolve the ambiguity.
    @Override
    public void display() {
        InterfaceA.super.display(); // calling InterfaceA's default implementation
        InterfaceB.super.display(); // calling InterfaceB's default implementation
    }
}

어떻게 해결할 수 있을까요?

1. 메서드 오버라이딩: 구현 클래스에서 자신만의 구현을 제공하여 모호함을 해결합니다. 이 방식은 기본 구현 중 하나를 선택하거나 완전히 새로운 구현을 제공하고자 할 때 적합합니다.
class MyClass implements InterfaceA, InterfaceB {
    @Override
    public void display() {
        System.out.println("Hello world");
    }
}

2. 특정 인터페이스의 메서드 호출: 특정한 인터페이스의 메서드를 호출합니다. 
class MyClass implements InterfaceA, InterfaceB {
    @Override
    public void display() {
        InterfaceA.super.display(); // or InterfaceB.super.display()
        // Additional logic if needed
    }
}

 
Multilevel 상속이란 무엇인가요?
Multilevel 상속에서 A 클래스는 B 클래스를 상속하며, B 클래스 역시 C 클래스를 상속합니다.
 
자식 클래스는 부모 클래스를 통해 조부모 클래스에서 간접적으로 상속됩니다. 자식 클래스는 부모 및 조부모 클래스의 모든 public/protected 멤버에 접근할 수 있습니다.
 
String, Stringbuffer, Stringbuilder의 차이는 무엇인가요?
(번역/원문 참고)
 
메서드 오버라이딩과 오버로딩은 무엇인가요?
[메서드 오버로딩]
 * 단일 클래스 내에서 발생합니다. 이름은 같지만 매개 변수가 다른 동일한 클래스의 여러 메서드를 말합니다.
 * 메서드 오버로딩을 사용하면 유사한 작업을 수행하지만 입력/출력이 다른 메서드를 만들 수 있습니다.
class Calculator {
  public int add(int a, int b) {
    return a + b;
  }

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

[메서드 오버라이딩]
 * 상속에서 클래스 간에 메서드 오버라이딩이 발생합니다. 하위 클래스가 상위 클래스에서 상속된 메서드를 재정의하는 것을 말합니다. 메서드는 상위 클래스 메서드와 동일한 이름, 반환 유형 및 매개 변수를 갖습니다.
 * 메서드 오버라이딩을 사용하면 하위 클래스가 상위 클래스에서 상속된 메서드를 자체적으로 구현하여 하위 클래스에 대한 동작을 전문화할 수 있습니다.
class Animal {
  public void makeSound() {
    System.out.println("Generic animal sound");
  }
}

class Dog extends Animal {
  @Override
  public void makeSound() {
    System.out.println("Woof!");
  }
}

 
예외 클래스의 계층구조는 무엇인가요?
Arraylist와 Linkedlist의 차이는 무엇인가요?
Set과 Arraylist의 차이는 무엇인가요?
(번역/원문 참고)
 
번역: [https://ducktopia.tistory.com/119]
원문:

Finally 블록에서 예외가 발생하면 어떻게 되나요?자바에서, try-catch에서 finally 블록 내에서 예외가 발생할 때의 동작은, try-catch 블록의 예외 처리와 약간 다릅니다.&nbsp;&nbsp;[Try-Catch 블록의 예외]<ul ><li>정상적인 플로우가 중지됩니다.</li><li>예외 유형과 일치하는 catch 블록이 있다면, 해당 블록 내의 코드가 실행됩니다. 이를 통해 예외를 처리할 수 있습니다.</li><li>catch 블록이 완료되거나 어떤 catch 블록과도 일치하지 않으면 finally 블록의 코드가 실행됩니다.</li></ul>[Finally 블록의 예외]<ul ><li>원래의 예외가 중지됩니다. 이는 원래의 예외가 메서드 호출자에게 전달되지 않는 것을 의미합니다.</li><li>finally 블록에서 던진 예외가 호출자에게 전파되는 새로운 예외가 됩니다.</li></ul>[키 포인트]<ul ><li>finally 블록은 try-catch 블록에서 예외가 발생하는지 여부에 관계없이 항상 실행됩니다.</li><li>finally 블록의 예외는 원래의 예외를 억제합니다.</li><li>finally 블록에서 던진 예외는 호출자가 처리해야 하는 새로운 예외가 됩니다.</li></ul>[Finally 블록의 쓰임새]<ul ><li>리소스(데이터베이스 연결, 파일 클로징)를 해제합니다.</li><li>예외에 관계없이 항상 수행해야 하는 정리 작업을 처리합니다.</li></ul>&nbsp;자바의 다이아몬드 문제란 무엇인가요?"다이아몬드 문제"란 여러 상속 시나리오에서 발생하는 특정한 문제를 의미합니다. 클래스 상속 다이어그램을 그릴 때 발생하는 다이아몬드 모양에서 이름을 따왔습니다. <ol ><li>자바의 접근방식: 자바는 클래스의 다중상속을 지원하지 않습니다. 그러나 자바는 인터페이스의 다중상속은 허용합니다.&nbsp;</li><li>자바 인터페이스의 다이아몬드 문제: 클래스가 두 개의 인터페이스를 구현하고 두 인터페이스가 모두 동일한 메소드명을 가진다면, 구현 클래스는 모호성을 해결하기 위해 메서드를 자체적으로 구현해야 합니다.</li></ol><pre ><code class="language-java">interface InterfaceA {
 default void display() {
 System.out.println("Inside InterfaceA");
 }
}

interface InterfaceB {
 default void display() {
 System.out.println("Inside InterfaceB");
 }
}

class MyClass implements InterfaceA, InterfaceB {
 // Here, we must provide our own implementation of display to resolve the ambiguity.
 @Override
 public void display() {
 InterfaceA.super.display(); // calling InterfaceA's default implementation
 InterfaceB.super.display(); // calling InterfaceB's default implementation
 }
}</code></pre>어떻게 해결할 수 있을까요? 1. 메서드 오버라이딩: 구현 클래스에서 자신만의 구현을 제공하여 모호함을 해결합니다. 이 방식은 기본 구현 중 하나를 선택하거나 완전히 새로운 구현을 제공하고자 할 때 적합합니다.<pre ><code class="language-java">class MyClass implements InterfaceA, InterfaceB {
 @Override
 public void display() {
 System.out.println("Hello world");
 }
}</code></pre>2. 특정 인터페이스의 메서드 호출: 특정한 인터페이스의 메서드를 호출합니다.&nbsp;<pre ><code class="language-java">class MyClass implements InterfaceA, InterfaceB {
 @Override
 public void display() {
 InterfaceA.super.display(); // or InterfaceB.super.display()
 // Additional logic if needed
 }
}</code></pre>&nbsp;Multilevel 상속이란 무엇인가요?Multilevel 상속에서 A 클래스는 B 클래스를 상속하며, B 클래스 역시 C 클래스를 상속합니다.&nbsp;자식 클래스는 부모 클래스를 통해 조부모 클래스에서 간접적으로 상속됩니다. 자식 클래스는 부모 및 조부모 클래스의 모든 public/protected 멤버에 접근할 수 있습니다.&nbsp;String, Stringbuffer, Stringbuilder의 차이는 무엇인가요?(번역/원문 참고)&nbsp;메서드 오버라이딩과 오버로딩은 무엇인가요?[메서드 오버로딩]<ul ><li>단일 클래스 내에서 발생합니다. 이름은 같지만 매개 변수가 다른 동일한 클래스의 여러 메서드를 말합니다.</li><li>메서드 오버로딩을 사용하면 유사한 작업을 수행하지만 입력/출력이 다른 메서드를 만들 수 있습니다.</li></ul><pre ><code class="language-java">class Calculator {
 public int add(int a, int b) {
 return a + b;
 }

 public double add(double a, double b) {
 return a + b;
 }
}</code></pre>[메서드 오버라이딩]<ul ><li>상속에서 클래스 간에 메서드 오버라이딩이 발생합니다. 하위 클래스가 상위 클래스에서 상속된 메서드를 재정의하는 것을 말합니다. 메서드는 상위 클래스 메서드와 동일한 이름, 반환 유형 및 매개 변수를 갖습니다.</li><li>메서드 오버라이딩을 사용하면 하위 클래스가 상위 클래스에서 상속된 메서드를 자체적으로 구현하여 하위 클래스에 대한 동작을 전문화할 수 있습니다.</li></ul><pre ><code class="language-java">class Animal {
 public void makeSound() {
 System.out.println("Generic animal sound");
 }
}

class Dog extends Animal {
 @Override
 public void makeSound() {
 System.out.println("Woof!");
 }
}</code></pre>&nbsp;예외 클래스의 계층구조는 무엇인가요?Arraylist와 Linkedlist의 차이는 무엇인가요?Set과 Arraylist의 차이는 무엇인가요?(번역/원문 참고)&nbsp;번역: [https://ducktopia.tistory.com/119]원문:

Medium

🕊️ 2024 버클리즈 Java SpringBoot 인터뷰 질문 (3)

스타트UP스토리]황도연 당근마켓 대표[이 기사에 나온 스타트업에 대한 보다 다양한 기업정보는 유니콘팩토리 빅데이터 플랫폼 '데이터랩'에서 볼 수 있습니다.]"하이퍼로컬(지역밀착)에 충실했다."2023년 당근마켓(이하 당근)의 연간 흑자전환 비결을 묻는 질문에 황도연 대표는 이렇게 답했다. 1시간 남짓한 시간 동안 진행된 인터뷰에서 황 대...

'플랫폼의 저주' 깨고 흑자 낸 당근마켓..."해외서도? 당근이죠!" - 머니투데이

21년 (-)352억원, 2022년 (-)464억원으로 적자폭이 나날이 늘어가던 당근에 대한 시선은 비관적이었습니다. 벤처투자 혹한기를 맞아 계속 현금을 태우기만 하는 당근이 지속가능할 것이냐는 의문도 있었고, 비용을 줄여서 억지로 영업적자를 줄이려다가 성장이 후퇴하는 것 아니냐는 우려도 있었는데요,

당근은 이런 의문이 무색하게도 매출을 22년 500억원 수준에서 23년 1270억원으로 늘리면서 흑자 전환에 성공했습니다. 영업이익은 173억원 흑자로 전년 대비 무려 (+)640억원을 늘렸습니다.

황도연 대표는 이에 대해서 "외부에서 보기에는 드라마틱해 보이겠지만, 계속 해 오던 것들이 실적으로 나타났을 뿐" 이라고 말했습니다. 워낙에 탄탄한 유저 풀과 서비스가 있었으니 수익으로 전환하기가 쉬웠고, 비용 절감도 시장에서 벌어지고 있는 무시무시한 구조조정 없이 광고선전비만을 줄임으로써 충분히 달성이 되었습니다.

21년 (-)352억원, 2022년 (-)464억원으로 적자폭이 나날이 늘어가던 당근에 대한 시선은 비관적이었습니다. 벤처투자 혹한기를 맞아 계속 현금을 태우기만 하는 당근이 지속가능할 것이냐는 의문도 있었고, 비용을 줄여서 억지로 영업적자를 줄이려다가 성장이 후퇴하는 것 아니냐는 우려도 있었는데요, 당근은 이런 의문이 무색하게도 매출을 22년 500억원 수준에서 23년 1270억원으로 늘리면서 흑자 전환에 성공했습니다. 영업이익은 173억원 흑자로 전년 대비 무려 (+)640억원을 늘렸습니다. 황도연 대표는 이에 대해서 "외부에서 보기에는 드라마틱해 보이겠지만, 계속 해 오던 것들이 실적으로 나타났을 뿐" 이라고 말했습니다. 워낙에 탄탄한 유저 풀과 서비스가 있었으니 수익으로 전환하기가 쉬웠고, 비용 절감도 시장에서 벌어지고 있는 무시무시한 구조조정 없이 광고선전비만을 줄임으로써 충분히 달성이 되었습니다.&nbsp;

머니투데이

1년만에 흑자전환 성공한 당근의 저력

지도 서비스에서 더 나은 사용자 경험은 무엇일까요? 더 정확하게, 더 빠르게, 그리고 더 쉽게. 기존의 길찾기 서비스는 실외에서 실외로 이동할 때 사용자에게 정보를 최적화하는 것에 집중했습니다. 카카오맵은 인천국제공항, 코엑스 등 실내에서 길안내 니즈가 있는 대형 복합공간에서도 위치정보를 기반으로 한 길안내 서비스를 제공합니다.

[ 큐레이터의 문장 🎒 ]

기술에 고민이 담기면 더 나은 서비스를 만들 수 있습니다.

지도 서비스에서 더 나은 사용자 경험은 무엇일까요? 더 정확하게, 더 빠르게, 그리고 더 쉽게. 기존의 길찾기 서비스는 실외에서 실외로 이동할 때 사용자에게 정보를 최적화하는 것에 집중했습니다. 카카오맵은 인천국제공항, 코엑스 등 실내에서 길안내 니즈가 있는 대형 복합공간에서도 위치정보를 기반으로 한 길안내 서비스를 제공합니다. [ 큐레이터의 문장 🎒 ] 기술에 고민이 담기면 더 나은 서비스를 만들 수 있습니다.

⟪카카오맵의 더 나은 UX⟫

데이제로인사이트위대한 창업가들은 어떻게 처음 비즈니스를 시작했을까요? 방송에 출연한 ...

🗒️전 세계 10억명이 쓰는 위키피디아는 왜 광고를 붙이지 않을까?

위키피디아는 전 세계 7위, 10억명의 유저가 이용하는 광고 없이 오로지 기부금만으로 운영되는 사이트입니다. 사실 이정도 트래픽이면 광고만 붙여도 명확한 비즈니스 모델이 생길텐데, 왜 광고를 붙이지 않는지 위키피디아 창업가의 인터뷰 내용을 공유드립니다.

🏄🏻‍♂️어차피 실패할 거면 그냥 빨리해야한다.
아이디어가 실현 가능성이 매우 낮아 실패하는 것이 당연하다면 차라리 서둘러 시작하는게 좋을때가 있습니다. 위키피디아 창업가가 맨 처음 시작한 Nupedia는 전문가들만 글을 쓸 수 있는 사이트였고 1년 동안 작성된 아티클의 수는 21개에 불과했습니다. 그마저도 표절 시비에 휘말리는 등 여러 고충을 겪었습니다.
그는 이 시도를 통해 '온라인 백과사전', '지식의 민주화'에 공감하는 많은 사람들을 자신의 커뮤니티에 모을 수 있었고 '모든 사람을 위한 무료 백과사전' 이라는 개념을 열망하는 사람들과 함께 '위키'라는 협업 방식을 이용해 위키피디아를 만들어냈습니다.

🤔 창업을 처음 도전하는 사람이라면
자신의 아이디어가 특별하다고 생각하는 경우가 많습니다. 이 아이디어를 성공시키기 위해서 완벽에 완벽을 기하는 경우가 많습니다. 하지만 1년을 준비했던, 10일을 준비했던 고객을 만나고 나면 결국 실패에 가까운 결과가 나올 확률이 큽니다.
위키피디아 창업가는 높은 실패 확률을 염두해뒀기에 작게라도 시작할 수 있었습니다. 그리고 인터넷이라는 큰 파도가 있었기에 결코 작지 않은 성공을 하게 된 것입니다.

👁️ 돈이 부족한게 오히려 경쟁력이 될 수 있습니다.
위키피디아를 처음 출시했을때만해도 지금처럼 완전 개방형으로 구현된 소프트웨어 모델이 아닌 사람이 일일히 검수해야하는 시스템이였습니다. 트래픽과 글은 기하급수적으로 늘어나는데 자금은 없었습니다. 그리고 이 커뮤니티에 주축이 되는 사용자들은 외부 자금으로 인해 플랫폼의 중립성이 무너지는 것을 반대했고, 그래서 다른 투자 없이 소프트웨어로 자동화된 검수 알고리즘과 정책을 만들수밖에 없었습니다.
자원이 부족한것이 오히려 아주 적은 인원으로 수 천만개에 달하는 사이트를 관리할 수 있게 된것입니다.

🏃‍♂️ 실리콘 밸리의 스타트업처럼 일을 하지 않았기에
만약 실리콘 밸리 스타일처럼 수 백만 달러를 투자받았다면 본능적으로 사람을 고용 했을 것입니다. 모더레이터 몇 명만 고용하면 쉽게 문제를 해결 할 수 있었지만 부족한 자금 상황에서도 해결 방법을 찾아냈기에 역설적으로 위키피디아의 핵심 가치를 지킬 수 있었습니다.
위키피디아가 광고 서비스를 했다면 지금과 같은 강력한 중립성을 지킬 수 없었을 것이고, 연 10억명이 사용하는 백과사전으로서의 역할도 할 수 없었을 것입니다.

🧘🏻‍♂️ 위키피디아는 기부금만으로 운영되고 있습니다.
위키피디아는 콘텐츠 생산량이 유튜브, 페이스북, 인스타그램, 트위터 등에 이은 5위 정도로 많습니다. 그리고 수 백만명으로부터 1년에 8,000만 달러가 넘는 기부금을 받아 운영하고 있습니다. 아직도 광고와 같은 뚜렷한 수익모델은 없고 오로지 커뮤니티 멤버들의 기부금을 통해 운영되고 있습니다.

🏋️ 비즈니스 모델은 어떻게든 만들어집니다.
기업의 취지와 가치를 믿는 사람들이 모인 커뮤니티는 강력합니다. 위키피디아는 "인류라면 누구나 접근할 수 있는 지식의 모음"을 만든다는 미션을 가지고 있고, 이 커뮤니티에 모인 사람들은 인류 최초로 인쇄 시스템을 만든 "쿠텐베르크"아 자신들을 동일시합니다.
그렇기에 기부금을 내면서 무료로 편집활동을 하는 것입니다.
팬이 모이고, 이들이 커뮤니티를 만들었다면 어떻게든 비즈니스 모델은 만들어질 수 있습니다.
어려운 것은 그 팬들이 모일 수 있도록 만드는 기업의 미션과, 커뮤니티가 유지될 수 있도록 노력한 창업가의 뚝심입니다.

위키피디아는 전 세계 7위, 10억명의 유저가 이용하는 광고 없이 오로지 기부금만으로 운영되는 사이트입니다. 사실 이정도 트래픽이면 광고만 붙여도 명확한 비즈니스 모델이 생길텐데, 왜 광고를 붙이지 않는지 위키피디아 창업가의 인터뷰 내용을 공유드립니다. 🏄🏻‍♂️어차피 실패할 거면 그냥 빨리해야한다.아이디어가 실현 가능성이 매우 낮아 실패하는 것이 당연하다면 차라리 서둘러 시작하는게 좋을때가 있습니다. 위키피디아 창업가가 맨 처음 시작한 Nupedia는 전문가들만 글을 쓸 수 있는 사이트였고 1년 동안 작성된 아티클의 수는 21개에 불과했습니다. 그마저도 표절 시비에 휘말리는 등 여러 고충을 겪었습니다.그는 이 시도를 통해 '온라인 백과사전', '지식의 민주화'에 공감하는 많은 사람들을 자신의 커뮤니티에 모을 수 있었고 '모든 사람을 위한 무료 백과사전' 이라는 개념을 열망하는 사람들과 함께 '위키'라는 협업 방식을 이용해 위키피디아를 만들어냈습니다. 🤔 창업을 처음 도전하는 사람이라면자신의 아이디어가 특별하다고 생각하는 경우가 많습니다. 이 아이디어를 성공시키기 위해서 완벽에 완벽을 기하는 경우가 많습니다. 하지만 1년을 준비했던, 10일을 준비했던 고객을 만나고 나면 결국 실패에 가까운 결과가 나올 확률이 큽니다.위키피디아 창업가는 높은 실패 확률을 염두해뒀기에 작게라도 시작할 수 있었습니다. 그리고 인터넷이라는 큰 파도가 있었기에 결코 작지 않은 성공을 하게 된 것입니다. 👁️ 돈이 부족한게 오히려 경쟁력이 될 수 있습니다.위키피디아를 처음 출시했을때만해도 지금처럼 완전 개방형으로 구현된 소프트웨어 모델이 아닌 사람이 일일히 검수해야하는 시스템이였습니다. 트래픽과 글은 기하급수적으로 늘어나는데 자금은 없었습니다. 그리고 이 커뮤니티에 주축이 되는 사용자들은 외부 자금으로 인해 플랫폼의 중립성이 무너지는 것을 반대했고, 그래서 다른 투자 없이 소프트웨어로 자동화된 검수 알고리즘과 정책을 만들수밖에 없었습니다.자원이 부족한것이 오히려 아주 적은 인원으로 수 천만개에 달하는 사이트를 관리할 수 있게 된것입니다. 🏃‍♂️ 실리콘 밸리의 스타트업처럼 일을 하지 않았기에만약 실리콘 밸리 스타일처럼 수 백만 달러를 투자받았다면 본능적으로 사람을 고용 했을 것입니다. 모더레이터 몇 명만 고용하면 쉽게 문제를 해결 할 수 있었지만 부족한 자금 상황에서도 해결 방법을 찾아냈기에 역설적으로 위키피디아의 핵심 가치를 지킬 수 있었습니다.위키피디아가 광고 서비스를 했다면 지금과 같은 강력한 중립성을 지킬 수 없었을 것이고, 연 10억명이 사용하는 백과사전으로서의 역할도 할 수 없었을 것입니다. 🧘🏻‍♂️ 위키피디아는 기부금만으로 운영되고 있습니다.위키피디아는 콘텐츠 생산량이 유튜브, 페이스북, 인스타그램, 트위터 등에 이은 5위 정도로 많습니다. 그리고 수 백만명으로부터 1년에 8,000만 달러가 넘는 기부금을 받아 운영하고 있습니다. 아직도 광고와 같은 뚜렷한 수익모델은 없고 오로지 커뮤니티 멤버들의 기부금을 통해 운영되고 있습니다. 🏋️ 비즈니스 모델은 어떻게든 만들어집니다.기업의 취지와 가치를 믿는 사람들이 모인 커뮤니티는 강력합니다. 위키피디아는 "인류라면 누구나 접근할 수 있는 지식의 모음"을 만든다는 미션을 가지고 있고, 이 커뮤니티에 모인 사람들은 인류 최초로 인쇄 시스템을 만든 "쿠텐베르크"아 자신들을 동일시합니다.그렇기에 기부금을 내면서 무료로 편집활동을 하는 것입니다.팬이 모이고, 이들이 커뮤니티를 만들었다면 어떻게든 비즈니스 모델은 만들어질 수 있습니다.어려운 것은 그 팬들이 모일 수 있도록 만드는 기업의 미션과, 커뮤니티가 유지될 수 있도록 노력한 창업가의 뚝심입니다.

혼자 연 7억 버는 크리에이터 사이언스의 '사랑받는 멤버십 만들기'요약본

10억명이 쓰는 위키피디아가 광고를 붙이지 않는 이유

AARRR를 활용하는 마케터들이 흔히 하는 오해는 이런 것입니다.

1. AARRR을 그대로 적용할 수 있다.
2. AARRR은 앞에서부터 순서대로 중요하다. 

그 중 첫 번째 오해에 대해 이야기 해 보려고 합니다. 

AARRR은 고객들의 일반적인 라이프 사이클을 단계 별로 구조화 한 퍼널입니다. 그래서 저는 이를 모든 서비스나 상황에 그대로 적용하기에는 무리가 있다고 믿어요. 고객들의 행동이 항상 첫 번째 A인 Acquisition부터 마지막 R인 Referral까지 단계 별로 순서대로 일어나지 않기 때문입니다. A부터 R까지 딱 이 순서대로 차근차근 일어나는 고객 여정은 의외로 흔치 않습니다.

에어비앤비와 노션의 고객 행동을 비교해 보면 쉽게 알 수 있습니다. 대부분 고객들은 가장 원하거나 쉬운 행동을 먼저 하고, 어렵고 귀찮은 행동은 미루는 경우가 많습니다. AARRR의 순서 그대로 행동하는 것이 아니라요. 어떤 계기로 인해 AARRR의 퍼널 중 몇 단계를 그대로 건너 뛰어 버리기도 합니다.

먼저 에어비앤비입니다. 고객이 여행을 준비하며 숙소를 찾다가 멋진 숙소를 판매하는 에어비앤비를 알게 되었고, 찾아낸 멋진 숙소의 예약이 마감 될까 급한 마음에 빨리 숙소를 결제 했습니다. 예약을 확인하기 위해 에어비앤비에 들락날락 하다보니 판매되는 투어 상품에 관심이 생겼고, 다음 여행에서는 에어비앤비에서 투어 상품도 구매를 했어요. 이 경우 AARRR에서 Acquisition과 Revenue가 전체 퍼널의 초반에 즉시 발생하고, Activation과 Retention이 뒤늦게 발생하게 됩니다. 매달 여행을 가는 사람이나 매일 숙소를 검색하는 사람이 많지 않다는 것을 감안하면 다시 Activation이 시작되는데 긴 공백 기간이 존재 할 것 이구요. 

이번에는 노션을 생각해 볼까요? 저는 다른 노트앱을 사용하다가 노션을 알게 되었어요. 심플한 UI에 끌려 무료 사용을 시작했고 아직까지 유료 결제 없이 잘 사용하고 있습니다. 무료 사용으로 가능한 기능만으로도 너무나 만족스러워 주위 사람들에게 많이 추천했고, 심지어 다양한 노션 템플릿을 만들어 사람들에게 공유 하기까지 했습니다. 이 경우 AARRR에서 Acquisition이 발생한 후 Activation이 매우 길게 이어졌습니다. 결제를 하지는 않았으니 Revenue와 Retention은 건너뛰고 Referral의 단계에 즉시 도달한 것이죠. 무료 서비스에 만족하고 있어 아마 당분간 Revenue의 단계를 거칠 일은 없을 것 같아요. 

물론 두 사례에서 Acquisition이나 Retention 등 단계 별 퍼널을 어떻게 정의 하느냐에 따라 해석이 달라질 수 있습니다. 많은 마케터들이 허무 지표에 빠지지 않기 위해 단순히 유입을 넘어 첫 구매나 무료 서비스 사용 등을 Acquisition의 핵심 지표로 설정하는 것처럼요. 지속 가능한 성장과 다음 퍼널까지 이어지는 건전한 고객 퍼널을 만들기 위해서 각 퍼널에서 중요한 고객 행동의 기준을 정하는 것이 필요합니다. Acquisition으로 생각해 보면  '고객이 우리 제품으로 침투되었다'고 판단할 수 있는 최소한의 기준이 되겠네요. 상품을 판매하는 이커머스라면 첫 구매를, 유료 서비스를 제공하는 앱이라면 7일 무료 사용이나 첫 결제를 유입의 기준으로 생각해 볼 수도 있습니다. 

이를 반대로 해석하면 마케터가 담당하는 서비스의 고객 행동을 고유한 퍼널로 도식화 하면 우리가 익히 알고 있는 AARRR의 순서가 나일 수 있다는 말입니다. 다른 말로 하면 마케터가 각 퍼널에서 필요한 고객 행동을 잘 정의하여 우리 서비스만의 퍼널을 그려보아야 한다는 것이기도 하고요. 

--

제가 하고싶은 말은 단순합니다. 우리는 흔히 ‘AARRR을 도입하자’라는 말을 ‘고객의 행동을 AARRR의 순서에 맞춰 그대로 분석하자’고 해석합니다. 하지만 이는 ’퍼널의 개념을 통해 우리 고객 만의 행동을 구조화하고 이를 통해 우리가 원하는 고객의 행동을 이끌어 내자’라는 의미에 가깝습니다. 이를 위해서는 퍼널의 개념을 정확히 이해하고 이를 통해 우리 고객의 행동을 해석할 수 있어야 합니다. 

이를 위해 제가 추천하는 방법은 ‘그로스 방정식’을 만드는 것이에요. AARRR에 존재하는 수 많은 지표들을 모두 관찰하거나 관리할 수 없으니까요. 그로스 방정식은 내가 원하는 최종 결과에 이르는 고객 행동의 퍼널을 수식의 형태로 구조화 한 것을 말합니다. 이를 통해 중요한 고객의 행동을 집중적으로 정량화 하고 측정 가능한 방식으로 바꿔 나갈 수 있어요.

이런 개념들은 제가 얼마전 인프런에서 런칭한 <그로스마케팅 101> 강의에 쉽게 설명되어 있으니 관심 있으신 분들은 아래 링크를 참고 부탁 드립니다 :) 

https://inf.run/DF6MT

AARRR를 활용하는 마케터들이 흔히 하는 오해는 이런 것입니다. 1. AARRR을 그대로 적용할 수 있다.2. AARRR은 앞에서부터 순서대로 중요하다.&nbsp; 그 중 첫 번째 오해에 대해 이야기 해 보려고 합니다.&nbsp; AARRR은 고객들의 일반적인 라이프 사이클을 단계 별로 구조화 한 퍼널입니다. 그래서 저는 이를 모든 서비스나 상황에 그대로 적용하기에는 무리가 있다고 믿어요. 고객들의 행동이 항상 첫 번째 A인 Acquisition부터 마지막 R인 Referral까지 단계 별로 순서대로 일어나지 않기 때문입니다. A부터 R까지 딱 이 순서대로 차근차근 일어나는 고객 여정은 의외로 흔치 않습니다. 에어비앤비와 노션의 고객 행동을 비교해 보면 쉽게 알 수 있습니다. 대부분 고객들은 가장 원하거나 쉬운 행동을 먼저 하고, 어렵고 귀찮은 행동은 미루는 경우가 많습니다. AARRR의 순서 그대로 행동하는 것이 아니라요. 어떤 계기로 인해 AARRR의 퍼널 중 몇 단계를 그대로 건너 뛰어 버리기도 합니다. 먼저 에어비앤비입니다. 고객이 여행을 준비하며 숙소를 찾다가 멋진 숙소를 판매하는 에어비앤비를 알게 되었고, 찾아낸 멋진 숙소의 예약이 마감 될까 급한 마음에 빨리 숙소를 결제 했습니다. 예약을 확인하기 위해 에어비앤비에 들락날락 하다보니 판매되는 투어 상품에 관심이 생겼고, 다음 여행에서는 에어비앤비에서 투어 상품도 구매를 했어요. 이 경우 AARRR에서 Acquisition과 Revenue가 전체 퍼널의 초반에 즉시 발생하고, Activation과 Retention이 뒤늦게 발생하게 됩니다. 매달 여행을 가는 사람이나 매일 숙소를 검색하는 사람이 많지 않다는 것을 감안하면 다시 Activation이 시작되는데 긴 공백 기간이 존재 할 것 이구요.&nbsp; 이번에는 노션을 생각해 볼까요? 저는 다른 노트앱을 사용하다가 노션을 알게 되었어요. 심플한 UI에 끌려 무료 사용을 시작했고 아직까지 유료 결제 없이 잘 사용하고 있습니다. 무료 사용으로 가능한 기능만으로도 너무나 만족스러워 주위 사람들에게 많이 추천했고, 심지어 다양한 노션 템플릿을 만들어 사람들에게 공유 하기까지 했습니다. 이 경우 AARRR에서 Acquisition이 발생한 후 Activation이 매우 길게 이어졌습니다. 결제를 하지는 않았으니 Revenue와 Retention은 건너뛰고 Referral의 단계에 즉시 도달한 것이죠. 무료 서비스에 만족하고 있어 아마 당분간 Revenue의 단계를 거칠 일은 없을 것 같아요.&nbsp; 물론 두 사례에서 Acquisition이나 Retention 등 단계 별 퍼널을 어떻게 정의 하느냐에 따라 해석이 달라질 수 있습니다. 많은 마케터들이 허무 지표에 빠지지 않기 위해 단순히 유입을 넘어 첫 구매나 무료 서비스 사용 등을 Acquisition의 핵심 지표로 설정하는 것처럼요. 지속 가능한 성장과 다음 퍼널까지 이어지는 건전한 고객 퍼널을 만들기 위해서 각 퍼널에서 중요한 고객 행동의 기준을 정하는 것이 필요합니다. Acquisition으로 생각해 보면&nbsp; '고객이 우리 제품으로 침투되었다'고 판단할 수 있는 최소한의 기준이 되겠네요. 상품을 판매하는 이커머스라면 첫 구매를, 유료 서비스를 제공하는 앱이라면 7일 무료 사용이나 첫 결제를 유입의 기준으로 생각해 볼 수도 있습니다.&nbsp; 이를 반대로 해석하면 마케터가 담당하는 서비스의 고객 행동을 고유한 퍼널로 도식화 하면 우리가 익히 알고 있는 AARRR의 순서가 나일 수 있다는 말입니다. 다른 말로 하면 마케터가 각 퍼널에서 필요한 고객 행동을 잘 정의하여 우리 서비스만의 퍼널을 그려보아야 한다는 것이기도 하고요.&nbsp; -- 제가 하고싶은 말은 단순합니다. 우리는 흔히 ‘AARRR을 도입하자’라는 말을 ‘고객의 행동을 AARRR의 순서에 맞춰 그대로 분석하자’고 해석합니다. 하지만 이는 ’퍼널의 개념을 통해 우리 고객 만의 행동을 구조화하고 이를 통해 우리가 원하는 고객의 행동을 이끌어 내자’라는 의미에 가깝습니다. 이를 위해서는 퍼널의 개념을 정확히 이해하고 이를 통해 우리 고객의 행동을 해석할 수 있어야 합니다.&nbsp; 이를 위해 제가 추천하는 방법은 ‘그로스 방정식’을 만드는 것이에요. AARRR에 존재하는 수 많은 지표들을 모두 관찰하거나 관리할 수 없으니까요. 그로스 방정식은 내가 원하는 최종 결과에 이르는 고객 행동의 퍼널을 수식의 형태로 구조화 한 것을 말합니다. 이를 통해 중요한 고객의 행동을 집중적으로 정량화 하고 측정 가능한 방식으로 바꿔 나갈 수 있어요. 이런 개념들은 제가 얼마전 인프런에서 런칭한 &lt;그로스마케팅 101&gt; 강의에 쉽게 설명되어 있으니 관심 있으신 분들은 아래 링크를 참고 부탁 드립니다 :)&nbsp; https://inf.run/DF6MT

AARRR에 대한 오해 (1)

코인베이스 창업자 인터뷰를 봤다. 어쩌다 코인 거래소 할 생각했냐는 질문에 대한 답이 인상 깊었다. (10년 전에) 창업 전에 그는 대기업 (에어비엔비) 개발자였다. 에어비엔비 플랫폼은 하나인데, 전 세계 돈은 수백가지랬다. 미국은 달러로, 일본은 엔화로, 유럽은 유로로, 한국은 원화로. 은행들도 수백가지랬다. 에어비엔비는 하나인데, 거기에 연결되는 은행이 수백가지랬다. 수많은 종류의 돈 처리하는 것만 해도 엄청난 비효율. 이게 뭔가 고민하던 찰나에 접했던 개념이 비트코인. 은행 없이 지갑으로 서로 돈을 쏘고, 받고 할 수 있으니.

그는 시간은 좀 걸리겠지만... '이거, 되겠다' 싶었다고 한다. 그렇게 대기업 (에어비엔비) 계속 다니면서 퇴근하고, 주말에 비트코인 관련 밋업 자리를 다 찾아갔다고 한다. 모르는 사람들 투성이지만, 어쨌든 궁금하니. 거기 만난 사람들이랑 퇴근하고, 주말에 프로토타입으로 코인 지갑 만들었다. 그리고 그것 위에 하나, 하나 기능 붙여서 지금의 거래소가 됐다는 이야기.

보는 사람은 본다. 보는 사람은 기회가 찾아왔을 때, 그게 기회인 지 알고 행동한다. 이거 '되겠다' 싶어서, 어쨌든 일면식 없는 사람들 찾아가서 코인 지갑 만들겠다고 한 그처럼. 10년도 더 전인데...

잘 생각해보면... 조금만 '버티면' 에어비엔비 상장하고 돈도 충분히 벌었을 텐데. 굳이 그렇게 까지 할 필요가 있었으려나? 충분히 좋은 인생, 적당히 만족스러운 인생 살 수 있었을 텐데. 그런 것들 다 버리고. 갑자기 코인 거래소 만든다고? 나라면? 몇 년만 기다리면 상장하고, 조금 안정 될텐데. 그 때 도전하자 생각하지 않았을지?

남의 인생 보면서, 저 사람은 저런 삶이니까... 생각하면 배우는 게 없다. 나도 모르게 수 많은 기회들을 이미 스쳐 보냈을지도 모르겠다는 생각을 했다. 지금도 기회가 둥둥 떠다니고 다닐 수도 있고 말이다. 기회는 원래 잘 안 보인다. 흐릿, 희미하게 보인다. 그것들이 기회인 줄 알고, 잡는 것 자체가 역량인 듯 싶다. 어쩌면 용기. 그런 삶의 자세 같은 것. 그런 생각이 들었다. 멋진 인터뷰.

영상 : https://www.youtube.com/watch?v=HgqD3X-XJxo

코인베이스 창업자 인터뷰를 봤다. 어쩌다 코인 거래소 할 생각했냐는 질문에 대한 답이 인상 깊었다. (10년 전에) 창업 전에 그는 대기업 (에어비엔비) 개발자였다. 에어비엔비 플랫폼은 하나인데, 전 세계 돈은 수백가지랬다. 미국은 달러로, 일본은 엔화로, 유럽은 유로로, 한국은 원화로. 은행들도 수백가지랬다. 에어비엔비는 하나인데, 거기에 연결되는 은행이 수백가지랬다. 수많은 종류의 돈 처리하는 것만 해도 엄청난 비효율. 이게 뭔가 고민하던 찰나에 접했던 개념이 비트코인. 은행 없이 지갑으로 서로 돈을 쏘고, 받고 할 수 있으니. 그는 시간은 좀 걸리겠지만... '이거, 되겠다' 싶었다고 한다. 그렇게 대기업 (에어비엔비) 계속 다니면서 퇴근하고, 주말에 비트코인 관련 밋업 자리를 다 찾아갔다고 한다. 모르는 사람들 투성이지만, 어쨌든 궁금하니. 거기 만난 사람들이랑 퇴근하고, 주말에 프로토타입으로 코인 지갑 만들었다. 그리고 그것 위에 하나, 하나 기능 붙여서 지금의 거래소가 됐다는 이야기. 보는 사람은 본다. 보는 사람은 기회가 찾아왔을 때, 그게 기회인 지 알고 행동한다. 이거 '되겠다' 싶어서, 어쨌든 일면식 없는 사람들 찾아가서 코인 지갑 만들겠다고 한 그처럼. 10년도 더 전인데... 잘&nbsp;생각해보면...&nbsp;조금만&nbsp;'버티면'&nbsp;에어비엔비&nbsp;상장하고&nbsp;돈도&nbsp;충분히&nbsp;벌었을&nbsp;텐데.&nbsp;굳이&nbsp;그렇게&nbsp;까지&nbsp;할&nbsp;필요가&nbsp;있었으려나?&nbsp;충분히&nbsp;좋은&nbsp;인생,&nbsp;적당히&nbsp;만족스러운&nbsp;인생&nbsp;살&nbsp;수&nbsp;있었을&nbsp;텐데.&nbsp;그런&nbsp;것들&nbsp;다&nbsp;버리고.&nbsp;갑자기&nbsp;코인&nbsp;거래소&nbsp;만든다고?&nbsp;나라면?&nbsp;몇&nbsp;년만&nbsp;기다리면&nbsp;상장하고,&nbsp;조금&nbsp;안정&nbsp;될텐데.&nbsp;그&nbsp;때&nbsp;도전하자&nbsp;생각하지&nbsp;않았을지? 남의&nbsp;인생&nbsp;보면서,&nbsp;저&nbsp;사람은&nbsp;저런&nbsp;삶이니까...&nbsp;생각하면&nbsp;배우는&nbsp;게&nbsp;없다.&nbsp;나도&nbsp;모르게&nbsp;수&nbsp;많은&nbsp;기회들을&nbsp;이미&nbsp;스쳐&nbsp;보냈을지도&nbsp;모르겠다는&nbsp;생각을&nbsp;했다.&nbsp;지금도&nbsp;기회가&nbsp;둥둥&nbsp;떠다니고&nbsp;다닐&nbsp;수도&nbsp;있고&nbsp;말이다.&nbsp;기회는&nbsp;원래&nbsp;잘&nbsp;안 보인다.&nbsp;흐릿,&nbsp;희미하게&nbsp;보인다.&nbsp;그것들이&nbsp;기회인&nbsp;줄&nbsp;알고,&nbsp;잡는&nbsp;것&nbsp;자체가&nbsp;역량인&nbsp;듯&nbsp;싶다.&nbsp;어쩌면&nbsp;용기.&nbsp;그런&nbsp;삶의&nbsp;자세&nbsp;같은&nbsp;것.&nbsp;그런&nbsp;생각이&nbsp;들었다.&nbsp;멋진&nbsp;인터뷰. 영상 : https://www.youtube.com/watch?v=HgqD3X-XJxo﻿

멀리 있지 않다

쇼츠 대세인 시대에도 '의미' 포기할 수 없는 창작자들의 고민... 이야기의 '깊이' 포기하지 않으면서 독자와 소통할 방안은

쇼츠 중독? 기다림이 설레는 사람은 '긴 이야기' 읽는다

1. ‘깊이 읽기’는 눈앞에 적힌 활자를 읽는 것이 아니라 그 활자들 사이, 그리고 그 활자들 너머를 읽는 것이다.

2. (다시 말해) ‘깊이 읽는다’는 것은 텍스트 너머로 가기 위해 활자 사이로 다이빙하는 것이다. 텍스트를 깊이 있게 읽을 때 사람은 이야기에 등장하는 사람에게 감정이입한다. 역지사지 관점에서 그 사람이 되어 본다.

3. <다시, 책으로>를 쓴 매리언 울프는 이런 ‘깊이 읽기’를 인간의 창의성이 발현되는 생성적 순간으로 들어서는 것이라고 표현했다. (’깊이 읽기’에서부터 창의성이 촉발된다는 얘기다)

4. 눈앞에 펼쳐진 활자나 이미지를 재미있게 소비하고 끝나는 것이 아니라, 무엇인가를 반추하면서 적혀 있지 않은 것까지 사유하며 자기 자신과 동시대, 그리고 인간의 운명에 대한 앎과 깨달음을 생성해내기 때문.

5. (그렇기 때문에) 당연하게도 이런 ‘깊이 읽기’는 (숏폼 콘텐츠를 소비하는 것보다) 어렵다. (게다가) 읽기는 누적적인 것이다. 누적된 것이 없으면 읽기는 고통의 과정이다.

6. 그러니 긴 이야기를 읽는 것은, '쾌감'이 아니라 '고통'을 유발한다고 볼 수 있다. (다시 말해) ‘깊게 읽기’란 즐거움을 유예하는 과정이며, (깊이 읽기 위해선) 그 유예를 즐길 수 있어야 한다.

7. (비유를 하자면) 드라마처럼 ‘다음 화에 계속(to be continued, 절단 신공)’이 주는 아쉬움을 설렘으로 바꿀 수 있어야, ‘긴 이야기’를 읽어낼 수 있다.

8. (즉) ‘다음’을 생각하는 사람, 기다림이 설레는 사람만이 ‘긴 이야기’를 읽을 수 있다.

9. 책 <도파민네이션>의 저자인 ‘애나 렘키’에 따르면, 사람들은 도파민에 ‘중독’될수록 점점 더 유예되는 일체의 쾌락을 폄하하는 태도를 보이게 된다고 한다. 즉, 보상으로서 쾌락은 즉각 주어져야 하며 그렇지 않고 지연되는 것을 견디지 못하고 의미부여를 하지도 않는다는 것이다. 애나 렘키는 이를 ‘지연 가치 폄하’라고 부른다.

10. (하지만 정말 중요한 깨달음이나 위대한 것들은 대부분 유예되어 한 발 늦게 온다. 즉, 위대한 많은 것들은 시간을 필요로 한다)

11. (그런 의미에서 ‘깊이 읽기’는, 그 시간을 기다리는 연습을 하는 것일 수 있다)

12. (그리고 숏폼 등 단기적 콘텐츠 소비가 늘어날수록, 깊이 읽는 역량은 점점 더 고귀해질 것이다. 깊이 읽기를 할 수 있는 사람은 많지 않을 테니까)

1. ‘깊이 읽기’는 눈앞에 적힌 활자를 읽는 것이 아니라 그 활자들 사이, 그리고 그 활자들 너머를 읽는 것이다. 2. (다시 말해) ‘깊이 읽는다’는 것은 텍스트 너머로 가기 위해 활자 사이로 다이빙하는 것이다. 텍스트를 깊이 있게 읽을 때 사람은 이야기에 등장하는 사람에게 감정이입한다. 역지사지 관점에서 그 사람이 되어 본다. 3. &lt;다시, 책으로&gt;를 쓴 매리언 울프는 이런 ‘깊이 읽기’를 인간의 창의성이 발현되는 생성적 순간으로 들어서는 것이라고 표현했다. (’깊이 읽기’에서부터 창의성이 촉발된다는 얘기다) 4. 눈앞에 펼쳐진 활자나 이미지를 재미있게 소비하고 끝나는 것이 아니라, 무엇인가를 반추하면서 적혀 있지 않은 것까지 사유하며 자기 자신과 동시대, 그리고 인간의 운명에 대한 앎과 깨달음을 생성해내기 때문. 5. (그렇기 때문에) 당연하게도 이런 ‘깊이 읽기’는 (숏폼 콘텐츠를 소비하는 것보다) 어렵다. (게다가) 읽기는 누적적인 것이다. 누적된 것이 없으면 읽기는 고통의 과정이다. 6. 그러니 긴 이야기를 읽는 것은, '쾌감'이 아니라 '고통'을 유발한다고 볼 수 있다. (다시 말해) ‘깊게 읽기’란 즐거움을 유예하는 과정이며, (깊이 읽기 위해선) 그 유예를 즐길 수 있어야 한다. 7. (비유를 하자면) 드라마처럼 ‘다음 화에 계속(to be continued, 절단 신공)’이 주는 아쉬움을 설렘으로 바꿀 수 있어야, ‘긴 이야기’를 읽어낼 수 있다. 8. (즉) ‘다음’을 생각하는 사람, 기다림이 설레는 사람만이 ‘긴 이야기’를 읽을 수 있다. 9. 책 &lt;도파민네이션&gt;의 저자인 ‘애나 렘키’에 따르면, 사람들은 도파민에 ‘중독’될수록 점점 더 유예되는 일체의 쾌락을 폄하하는 태도를 보이게 된다고 한다. 즉, 보상으로서 쾌락은 즉각 주어져야 하며 그렇지 않고 지연되는 것을 견디지 못하고 의미부여를 하지도 않는다는 것이다. 애나 렘키는 이를 ‘지연 가치 폄하’라고 부른다. 10. (하지만 정말 중요한 깨달음이나 위대한 것들은 대부분 유예되어 한 발 늦게 온다. 즉, 위대한 많은 것들은 시간을 필요로 한다) 11. (그런 의미에서 ‘깊이 읽기’는, 그 시간을 기다리는 연습을 하는 것일 수 있다) 12. (그리고 숏폼 등 단기적 콘텐츠 소비가 늘어날수록, 깊이 읽는 역량은 점점 더 고귀해질 것이다. 깊이 읽기를 할 수 있는 사람은 많지 않을 테니까)

한겨레21

‘깊이 읽기’는 앞으로 엄청난 경쟁력이 될 겁니다

Join은 무엇인가요?
Join은 여러 테이블의 데이터를 결합하기 위한 개념입니다. 공유 field를 기반으로 서로 다른 테이블에서 관련 정보를 검색할 수 있습니다. 다음과 같은 데이터베이스가 있다고 가정합시다:
 * 고객 테이블은 이름, ID와 같은 고객 정보를 저장합니다.
 * 주문 테이블은 고객 ID(고객 테이블과 연결된)를 포함한 주문 정보를 저장합니다.
완전한 정보를 위해, 고객 정보를 주문 정보와 결합해 보여주길 원할 것입니다. 이때 조인을 사용합니다.

 * Inner Join: 가장 일반적인 조인입니다. 두 테이블 모두에 포함된 내용만 반환합니다.
 * Left Join: 왼쪽 테이블의 모든 행과 오른쪽 테이블의 일치하는 행이 포함됩니다. 일치하지 않는 오른쪽 테이블의 행은 null 값을 가집니다.
 * Right Join: 오른쪽 테이블의 모든 행과 왼쪽 테이블의 일치하는 행이 포함됩니다. 일치하지 않는 왼쪽 테이블의 행은 null 값을 가집니다.
 * Full Join: 조인 조건에 일치하는 행이 있는지에 관계없이 두 테이블의 모든 행이 결합됩니다. 일치하지 않는 행은 해당 열에 null 값을 갖습니다.

 
Primary와 Foreign key의 차이점이 무엇인가요?
[Primary Key(기본 키)]
 * Uniqueness: 테이블의 각 행에 고유 식별자가 있는지 확인합니다. 이를 통해 레코드 중복을 방지하고 효율적인 데이터 검색이 가능합니다.
 * Single Key: 테이블은 기본 키를 하나만 가질 수 있습니다. 
 * Not null: 기본 키 열은 일반적으로 null 값을 허용하지 않습니다.
[Foreign Key(외래 키)]
 * Relationship Builder: 두 테이블 간의 연결을 설정합니다. 다른 테이블의 기본 키를 참조합니다.
 * Multiple Keys: 한 테이블에 여러 개의 외부 키가 있을 수 있습니다.
 * Nullable: 외부 키 열은 null 값을 허용합니다.
 
REST-API란 무엇인가요?
REST API는 Representational State Transfer API의 약자입니다. 웹 API를 설계하는 데 널리 사용되는 스타일입니다. 간단히 말해, HTTP 요청 및 응답을 사용하여 통신하는 방법에 대한 일련의 규칙을 정의합니다. 이를 통해 응용 프로그램은 사용된 프로그래밍 언어에 관계없이 표준화된 방식으로 서로 쉽게 상호 작용할 수 있습니다. 
 
언제 캡슐화와 추상화를 사용하나요?
캡슐화와 추상화는 코드 재사용성, 유지 보수성 및 보안을 강화하는 객체 지향 프로그래밍(OOP)의 기본 개념입니다. 
[캡슐화]
 * 데이터 숨김 및 보호: 객체의 내부 데이터에 대한 접근을 제어하고자 할 때 사용합니다. 데이터를 비공개로 설정하고 접근할 수 있는 메서드를 따로 제공하여 데이터 무결성을 보장하고 의도하지 않는 수정을 방지할 수 있습니다.
 * 은행 클래스에서 계좌금액 데이터를 캡슐화하여 입출금과 같은 적절한 방법을 통해서만 접근하게 합니다.
[추상화]
 * 기능에 집중: 추상화를 사용하여 클래스의 구현 세부 사항을 숨기고 인터페이스 또는 추상화 클래스를 통해 필수 기능만 노출합니다. 이를 통해 사용자는 기본 세부 구현에 대한 걱정 없이 객체와 상호 작용할 수 있습니다.
[결론]
 * 캡슐화를 사용하여 객체의 내부 데이터를 보호하고 데이터 접근을 제어합니다.
 * 추상화를 이용하여 "how"보다 "what"에 집중합니다.
 
Lazy Loading과 Eager Loading을 설명해주세요
Hibernate와 같은 ORM 프레임워크에서 데이터를 가져오기 위한 두 가지 전략이 Lazy loding과 Eager loading입니다. 데이터베이스에서 관련 객체가 로드되는 시기와 방법을 결정합니다.
[Lazy Loading(지연 로딩)]
 * Delay Loading: 데이터는 명시적으로 필요한 경우에만 검색됩니다. 사용자가 특정 제품을 클릭할 때만 제품 설명이나 리뷰와 같은 정보가 로딩되도록 합니다.
 * Performance Benefits: 사용하지 않는 데이터에 대한 불필요한 쿼리를 방지함으로써 데이터 로딩 시간을 개선할 수 있습니다.
 * Potential for Extra Queries: 관련 데이터가 필요한 경우 지연 로딩으로 인해 추가 쿼리가 실행되어 오버헤드가 발생할 수 있습니다.
[Eager Loading(즉시 로딩)]
 * Loads Everything Upfront: 모든 관련 데이터를 단일 쿼리에서 기본 객체와 함께 가져옵니다. 이는 사용자가 모든 데이터를 보지 않더라도 모든 제품 정보가 목록 페이지에 로드되는 것을 의미합니다.
 * Faster Access to Related Data: 데이터를 이미 불러왔으므로 관련 정보에 접근할 때 추가적인 쿼리가 필요하지 않습니다. 데이터 대부분을 사용해야 하는 시나리오의 경우 성능이 향상될 수 있습니다.
 * Potentially Slower Initial Load: 필요하지 않을 수도 있는 데이터를 가져오는 경우 초기 페이지 로딩 시간이 길어질 수 있습니다.
 
@GetMapping과 @PostMapping을 언제 사용하나요?
[@GetMapping]
 * HTTP GET 요청을 처리하는 메서드에서 이 어노테이션을 사용합니다. 일반적으로 서버에서 데이터를 검색하는 데 사용됩니다.
 * 리소스 목록 가져오기
 * 특정 리소스의 세부 정보 가져오기
 * 검색 또는 필터링 요청 처리 
@Controller
public class ProductController {

 @GetMapping("/products")
 public List<Product> getAllProducts() {
 // Logic to retrieve all products from the database
 }
}

[@PostMapping]
 * HTTP POST 요청을 처리하는 메서드에 이 어노테이션을 사용합니다. 일반적으로 생성 또는 업데이트 목적으로 서버에 데이터를 제출하는 데 사용됩니다.
 * 새 리소스 생성
 * 기존 리소스 업데이트
 * 리소스 삭제
@Controller
public class ProductController {

 @PostMapping("/products")
 public Product createProduct(@RequestBody Product product) {
 // Logic to save the new product to the database
 }
}

 
메서드 오버라이딩에 대한 예외 처리 규칙에는 어떤 것이 있나요?
[Same or Subclass Exception]
 * 슈퍼클래스의 메서드가 checked exception을 선언할 때, 오버라이딩된 메서드는 동일한 예외를 선언하거나 해당 예외의 하위 클래스를 선언할 수 있습니다. 이를 통해 하위 클래스에서 보다 구체적인 예외 처리가 가능합니다.
class SuperClass {
 public void doSomething() throws IOException {
 // ...
 }
}

class SubClass extends SuperClass {
 @Override
 public void doSomething() throws FileNotFoundException { // Subclass of IOException
 // ...
 }
}

[No Checked Exception]
 * 만약 슈퍼클래스 메서드가 예외를 선언하지 않으면, 하위 클래스의 메서드는 checked exception을 선언할 수 없습니다. 그러나, unchecked exception은 선언할 수 있습니다.
class SuperClass {
 public void doSomething() {
 // ...
 }
}

class SubClass extends SuperClass {
 @Override
 public void doSomething() throws IOException { // Not allowed (superclass doesn't throw IOException)
 // ...
 }
}

 
Spring MVC 플로우에 대해 설명해 주세요
Spring MVC는 MVC 아키텍처 패턴을 따르며, 이 패턴은 애플리케이션 로직, 데이터 프레젠테이션 및 사용자와의 상호작용을 분리하여 유지 보수성과 테스트성을 높입니다.
 
 1. Client Request: 사용자가 브라우저를 통해 웹 프로그램과 상호 작용하여 서버의 특정 URL에 대한 HTTP 요청을 날립니다.
 2. DispatcherServlet Intercept: DispatcherServlet이 Spring MVC의 프론트 컨트롤러 역할을 하며, 웹 컨테이너(Tomcat/Jetty)로부터 들어오는 모든 HTTP 요청을 수신합니다.
 3. Handler Mapping: DispatcherServlet이 요청을 처리할 컨트롤러 메서드를 결정하기 위해 일반적으로 RequestMappingHandlerMapping으로 구현되는 HandlerMapping을 참조합니다. 
 4. Handler Selection: HandlerMapping은 요청 URL 및 HTTP 메서드 기반으로 요청을 처리할 적절한 컨트롤러 클래스 및 메서드를 식별합니다.
 5. Controller Invocation: DispatcherServlet은 스프링 의존성 주입을 사용하여 식별된 컨트롤러 클래스의 인스턴스를 생성합니다. (아직 생성되지 않은 경우에) 그런 다음 컨트롤러에서 해당 메서드를 호출하여 요청 객체를 인수로 전달합니다.
 6. Model Population: 메서드 안에서 비즈니스 로직이 실행됩니다. 
 7. View Resolution: 모델이 채워지면 컨트롤러는 응답을 렌더링 할 뷰를 선택해야 합니다. 일반적으로 ViewResolver를 사용하여 적절한 뷰 템플릿을 선정합니다. 
 8. View Rendering: ViewResolver는 view name을 기준으로 뷰 템플릿을 찾습니다. 모델 객체는 최종 HTML 응답을 렌더링 하기 위해 뷰 엔진(JSP/FreeMarker)으로 전달됩니다. 렌더링 된 HTML 응답은 클라이언트의 브라우저로 다시 전송됩니다. 
 
번역: [https://ducktopia.tistory.com/118]
원문:

Join은 무엇인가요?Join은 여러 테이블의 데이터를 결합하기 위한 개념입니다. 공유 field를 기반으로 서로 다른 테이블에서 관련 정보를 검색할 수 있습니다. 다음과 같은 데이터베이스가 있다고 가정합시다:<ul ><li>고객 테이블은 이름, ID와 같은 고객 정보를 저장합니다.</li><li>주문 테이블은 고객 ID(고객 테이블과 연결된)를 포함한 주문 정보를 저장합니다.</li></ul>완전한 정보를 위해, 고객 정보를 주문 정보와 결합해 보여주길 원할 것입니다. 이때 조인을 사용합니다. <ul ><li>Inner Join: 가장 일반적인 조인입니다. 두 테이블 모두에 포함된 내용만 반환합니다.</li><li>Left Join: 왼쪽 테이블의 모든 행과 오른쪽 테이블의 일치하는 행이 포함됩니다. 일치하지 않는 오른쪽 테이블의 행은 null 값을 가집니다.</li><li>Right Join: 오른쪽 테이블의 모든 행과 왼쪽 테이블의 일치하는 행이 포함됩니다. 일치하지 않는 왼쪽 테이블의 행은 null 값을 가집니다.</li><li>Full Join: 조인 조건에 일치하는 행이 있는지에 관계없이 두 테이블의 모든 행이 결합됩니다. 일치하지 않는 행은 해당 열에 null 값을 갖습니다.</li></ul> &nbsp;Primary와 Foreign key의 차이점이 무엇인가요?[Primary Key(기본 키)]<ul ><li>Uniqueness: 테이블의 각 행에 고유 식별자가 있는지 확인합니다. 이를 통해 레코드 중복을 방지하고 효율적인 데이터 검색이 가능합니다.</li><li>Single Key: 테이블은 기본 키를 하나만 가질 수 있습니다.&nbsp;</li><li>Not null: 기본 키 열은 일반적으로 null 값을 허용하지 않습니다.</li></ul>[Foreign Key(외래 키)]<ul ><li>Relationship Builder: 두 테이블 간의 연결을 설정합니다. 다른 테이블의 기본 키를 참조합니다.</li><li>Multiple Keys: 한 테이블에 여러 개의 외부 키가 있을 수 있습니다.</li><li>Nullable: 외부 키 열은 null 값을 허용합니다.</li></ul>&nbsp;REST-API란 무엇인가요?REST API는 Representational State Transfer API의 약자입니다. 웹 API를 설계하는 데 널리 사용되는 스타일입니다. 간단히 말해, HTTP 요청 및 응답을 사용하여 통신하는 방법에 대한 일련의 규칙을 정의합니다. 이를 통해 응용 프로그램은 사용된 프로그래밍 언어에 관계없이 표준화된 방식으로 서로 쉽게 상호 작용할 수 있습니다.&nbsp;&nbsp;언제 캡슐화와 추상화를 사용하나요?캡슐화와 추상화는 코드 재사용성, 유지 보수성 및 보안을 강화하는 객체 지향 프로그래밍(OOP)의 기본 개념입니다.&nbsp;[캡슐화]<ul ><li>데이터 숨김 및 보호: 객체의 내부 데이터에 대한 접근을 제어하고자 할 때 사용합니다. 데이터를 비공개로 설정하고 접근할 수 있는 메서드를 따로 제공하여 데이터 무결성을 보장하고 의도하지 않는 수정을 방지할 수 있습니다.</li><li>은행 클래스에서 계좌금액 데이터를 캡슐화하여 입출금과 같은 적절한 방법을 통해서만 접근하게 합니다.</li></ul>[추상화]<ul ><li>기능에 집중: 추상화를 사용하여 클래스의 구현 세부 사항을 숨기고 인터페이스 또는 추상화 클래스를 통해 필수 기능만 노출합니다. 이를 통해 사용자는 기본 세부 구현에 대한 걱정 없이 객체와 상호 작용할 수 있습니다.</li></ul>[결론]<ul ><li>캡슐화를 사용하여 객체의 내부 데이터를 보호하고 데이터 접근을 제어합니다.</li><li>추상화를 이용하여 "how"보다 "what"에 집중합니다.</li></ul>&nbsp;Lazy Loading과 Eager Loading을 설명해주세요Hibernate와 같은 ORM 프레임워크에서 데이터를 가져오기 위한 두 가지 전략이 Lazy loding과 Eager loading입니다. 데이터베이스에서 관련 객체가 로드되는 시기와 방법을 결정합니다.[Lazy Loading(지연 로딩)]<ul ><li>Delay Loading: 데이터는 명시적으로 필요한 경우에만 검색됩니다. 사용자가 특정 제품을 클릭할 때만 제품 설명이나 리뷰와 같은 정보가 로딩되도록 합니다.</li><li>Performance Benefits: 사용하지 않는 데이터에 대한 불필요한 쿼리를 방지함으로써 데이터 로딩 시간을 개선할 수 있습니다.</li><li>Potential for Extra Queries: 관련 데이터가 필요한 경우 지연 로딩으로 인해 추가 쿼리가 실행되어 오버헤드가 발생할 수 있습니다.</li></ul>[Eager Loading(즉시 로딩)]<ul ><li>Loads Everything Upfront: 모든 관련 데이터를 단일 쿼리에서 기본 객체와 함께 가져옵니다. 이는 사용자가 모든 데이터를 보지 않더라도 모든 제품 정보가 목록 페이지에 로드되는 것을 의미합니다.</li><li>Faster Access to Related Data: 데이터를 이미 불러왔으므로 관련 정보에 접근할 때 추가적인 쿼리가 필요하지 않습니다. 데이터 대부분을 사용해야 하는 시나리오의 경우 성능이 향상될 수 있습니다.</li><li>Potentially Slower Initial Load: 필요하지 않을 수도 있는 데이터를 가져오는 경우 초기 페이지 로딩 시간이 길어질 수 있습니다.</li></ul>&nbsp;@GetMapping과 @PostMapping을 언제 사용하나요?[@GetMapping]<ul ><li>HTTP GET 요청을 처리하는 메서드에서 이 어노테이션을 사용합니다. 일반적으로 서버에서 데이터를 검색하는 데 사용됩니다.</li><li>리소스 목록 가져오기</li><li>특정 리소스의 세부 정보 가져오기</li><li>검색 또는 필터링 요청 처리&nbsp;</li></ul><pre ><code class="language-java">@Controller
public class ProductController {

 @GetMapping("/products")
 public List&lt;Product&gt; getAllProducts() {
 // Logic to retrieve all products from the database
 }
}</code></pre>[@PostMapping]<ul ><li>HTTP POST 요청을 처리하는 메서드에 이 어노테이션을 사용합니다. 일반적으로 생성 또는 업데이트 목적으로 서버에 데이터를 제출하는 데 사용됩니다.</li><li>새 리소스 생성</li><li>기존 리소스 업데이트</li><li>리소스 삭제</li></ul><pre ><code class="language-java">@Controller
public class ProductController {

 @PostMapping("/products")
 public Product createProduct(@RequestBody Product product) {
 // Logic to save the new product to the database
 }
}</code></pre>&nbsp;메서드 오버라이딩에 대한 예외 처리 규칙에는 어떤 것이 있나요?[Same or Subclass Exception]<ul ><li>슈퍼클래스의 메서드가 checked exception을 선언할 때, 오버라이딩된 메서드는 동일한 예외를 선언하거나 해당 예외의 하위 클래스를 선언할 수 있습니다. 이를 통해 하위 클래스에서 보다 구체적인 예외 처리가 가능합니다.</li></ul><pre ><code class="language-java">class SuperClass {
 public void doSomething() throws IOException {
 // ...
 }
}

class SubClass extends SuperClass {
 @Override
 public void doSomething() throws FileNotFoundException { // Subclass of IOException
 // ...
 }
}</code></pre>[No Checked Exception]<ul ><li>만약 슈퍼클래스 메서드가 예외를 선언하지 않으면, 하위 클래스의 메서드는 checked exception을 선언할 수 없습니다. 그러나, unchecked exception은 선언할 수 있습니다.</li></ul><pre ><code class="language-java">class SuperClass {
 public void doSomething() {
 // ...
 }
}

class SubClass extends SuperClass {
 @Override
 public void doSomething() throws IOException { // Not allowed (superclass doesn't throw IOException)
 // ...
 }
}</code></pre>&nbsp;Spring MVC 플로우에 대해 설명해 주세요Spring MVC는 MVC 아키텍처 패턴을 따르며, 이 패턴은 애플리케이션 로직, 데이터 프레젠테이션 및 사용자와의 상호작용을 분리하여 유지 보수성과 테스트성을 높입니다.&nbsp;<ol ><li>Client Request: 사용자가 브라우저를 통해 웹 프로그램과 상호 작용하여 서버의 특정 URL에 대한 HTTP 요청을 날립니다.</li><li>DispatcherServlet Intercept: DispatcherServlet이 Spring MVC의 프론트 컨트롤러 역할을 하며, 웹 컨테이너(Tomcat/Jetty)로부터 들어오는 모든 HTTP 요청을 수신합니다.</li><li>Handler Mapping: DispatcherServlet이 요청을 처리할 컨트롤러 메서드를 결정하기 위해 일반적으로 RequestMappingHandlerMapping으로 구현되는 HandlerMapping을 참조합니다.&nbsp;</li><li>Handler Selection: HandlerMapping은 요청 URL 및 HTTP 메서드 기반으로 요청을 처리할 적절한 컨트롤러 클래스 및 메서드를 식별합니다.</li><li>Controller Invocation: DispatcherServlet은 스프링 의존성 주입을 사용하여 식별된 컨트롤러 클래스의 인스턴스를 생성합니다. (아직 생성되지 않은 경우에) 그런 다음 컨트롤러에서 해당 메서드를 호출하여 요청 객체를 인수로 전달합니다.</li><li>Model Population: 메서드 안에서 비즈니스 로직이 실행됩니다.&nbsp;</li><li>View Resolution: 모델이 채워지면 컨트롤러는 응답을 렌더링 할 뷰를 선택해야 합니다. 일반적으로 ViewResolver를 사용하여 적절한 뷰 템플릿을 선정합니다.&nbsp;</li><li>View Rendering: ViewResolver는 view name을 기준으로 뷰 템플릿을 찾습니다. 모델 객체는 최종 HTML 응답을 렌더링 하기 위해 뷰 엔진(JSP/FreeMarker)으로 전달됩니다. 렌더링 된 HTML 응답은 클라이언트의 브라우저로 다시 전송됩니다.&nbsp;</li></ol>&nbsp;번역: [https://ducktopia.tistory.com/118]원문:

🕊️ 2024 버클리즈 Java SpringBoot 인터뷰 질문 (2)

Netflix는 Java, RxJava 및 Spring Boot를 활용해 마이크로서비스 아키텍처를 발전시켰으며, GraphQL Federation으로의 전환을 통해 더욱 발전했다. 이 글에서는 Netflix의 아키텍처 변화와 Java 사용 변천사를 설명한다.

Netflix의 Java 사용 변천사 (번역)

안녕하세요 :) 저는 최근에 다시 Java와 Spring Boot를 사용하는 미국 회사로 이직하면서, 지난 2년간 스타트업에서 Ruby on Rails를 사용하며 잊고 지내던 Java와 Spring 생태계에 다시 발을 내딛었습니다. 🥰

현재 회사에서는 수많은 모놀리틱 서비스와 마이크로서비스가 함께 사용되는 상황이라 꽤 복잡한 아키텍처로 구성되어 있습니다. 그리고 새로운 Java/Spring 기반 서비스들이 빠르게 추가되고 있어서 각 서비스들 간의 통신이나 아키텍처 구성을 어떻게 개선해가면 좋을지 고민되는 상황이었는데요. 🙃

팀에 빅테크(FAANG) 출신 시니어 개발자들도 있어서 제가 이 개선을 주도하지는 않겠지만,
적어도 아키텍처 개선 방향에 대한 내 의견을 가지고 있어야겠다
는 생각으로 힌트를 얻고자 Java 기반 서비스들의 큰 형님격인 Netflix의 문을 두드렸습니다.

Netflix는 Java 기반 서비스들의 아키텍처를 어떻게 발전시켜나갔는지 궁금해서 찾아보다가 이 글을 발견했고, 오랜만에 Java 생태계로 돌아온 저에게 유익했던 글이라 DeepL의 도움을 받아 번역해보았습니다.

전체 내용 보기 👉 https://www.integer.blog/evolution-of-java-usage-at-netflix/?ref=careerly.co.kr

📌 목차
 1. Groovy 시대 with BFF(Backend For Frontend)
 2. RxJava와 리액티브 프로그래밍 사용
 3. GraphQL Federation으로 전환
 4. Netflix가 사용하는 Java 버전
 5. Netflix가 사용하는 Spring Boot

안녕하세요 :) 저는 최근에 다시 Java와 Spring Boot를 사용하는 미국 회사로 이직하면서, 지난 2년간 스타트업에서 Ruby on Rails를 사용하며 잊고 지내던 Java와 Spring 생태계에 다시 발을 내딛었습니다. 🥰 현재 회사에서는 수많은 모놀리틱 서비스와 마이크로서비스가 함께 사용되는 상황이라 꽤 복잡한 아키텍처로 구성되어 있습니다. 그리고 새로운 Java/Spring 기반 서비스들이 빠르게 추가되고 있어서 각 서비스들 간의 통신이나 아키텍처 구성을 어떻게 개선해가면 좋을지 고민되는 상황이었는데요. 🙃 팀에 빅테크(FAANG) 출신 시니어 개발자들도 있어서 제가 이 개선을 주도하지는 않겠지만, <code >적어도 아키텍처 개선 방향에 대한 내 의견을 가지고 있어야겠다</code>는 생각으로 힌트를 얻고자 Java 기반 서비스들의 큰 형님격인 Netflix의 문을 두드렸습니다. Netflix는 Java 기반 서비스들의 아키텍처를 어떻게 발전시켜나갔는지 궁금해서 찾아보다가 이 글을 발견했고, 오랜만에 Java 생태계로 돌아온 저에게 유익했던 글이라 DeepL의 도움을 받아 번역해보았습니다. 전체 내용 보기 👉 https://www.integer.blog/evolution-of-java-usage-at-netflix/?ref=careerly.co.kr 📌 목차<ol ><li>Groovy 시대 with BFF(Backend For Frontend)</li><li>RxJava와 리액티브 프로그래밍 사용</li><li>GraphQL Federation으로 전환</li><li>Netflix가 사용하는 Java 버전</li><li>Netflix가 사용하는 Spring Boot</li></ol>

1nteger 🏄🏻‍♂️

Mobile development is a dynamic field that evolves rapidly, demanding developers to be proactive in keeping up with the latest trends, tools, and technologies. As the app landscape continuously...

How to Stay Up-to-Date as a Mobile Developer

개발자가 간단하게 실천할 수 있는 최신 정보 습득 방법에 대해 가져와 봤습니다! 이미 실천하고 계신 분들도 많으실 것 같네요ㅎㅎ 빠르게 변하는 산업인 만큼 지속적으로 새로운 정보를 받아들이는 것은 중요할 것 같습니다.

 1.  개발자 블로그 및 뉴스레터 구독하기
     iOS, aOS 공식 블로그뿐만 아니라 업계 전문가가 운영하는 블로그나 뉴스레터를 정기적으로 받아보는 것은 꾸준히 정보의 흐름을 읽을 수 있는 가장 좋은 방법입니다.
     
     
 2.  소셜 미디어 및 온라인 커뮤니티에 참여하기
     트위터, 레딧, 스택오브플로우와 같은 개발자 커뮤니티에 가입하는 것은 개발자들과 함께 소통하면서 성장할 수 있는 좋은 방법입니다. (커리어리도 마찬가지입니다!) 관련 해시태그를 팔로우하고, 스레드에 참여해서 좋은 정보를 실시간으로 얻어보세요! (개인적으로 일론머스크의 트윗이 재밌더군요...)
     
     
 3.  컨퍼런스 및 모임 참석
     온라인 및 오프라인 컨퍼런스에 주기적으로 참여하면 동료 개발자들과 네트워크를 형성하고, 최신 업계 동향을 접할 수 있습니다. wwdc, google i/o뿐만 아니라 국내 기업에서 주최하는 세션이나 컨퍼런스에 참여해 보세요!
     
     
 4.  온라인 강좌를 통한 지속적 학습
     코세라와 같은 유명 플랫폼에서 제공하는 온라인 강좌를 통해 지속적으로 지식을 심화해 나가는 것도 좋은 방법입니다. 최신 도구나 프레임워크를 학습하는 것은 나에게 큰 도움이 될 것입니다!
     
     
 5.  출퇴근 시간에 팟캐스트 듣기
     통근 시간을 이용해 팟캐스트의 힘을 활용해 보세요! Fragmented, Swift by Sundell 및 Android Developers Backstage와 같은 팟캐스트에서는 최신 모바일 개발 사례나 인터뷰 및 토론을 제공합니다! 영어 공부도 덤이고요! 이 외에 주요 CEO들이 출연하여 기술에 대해 이야기하는 ACQUIRED를 추천드립니다! 최근에는 앤비디아의 젠슨 황이 출연하기도 했죠.
     
     
 6.  GitHub 리포지토리 및 오픈 소스 프로젝트를 팔로우하기
     GitHub만큼이나 개발자가 코드를 파보기가 좋은 데가 없죠. 도메인와 관련된 프레임워크 라이브러리 오픈소스 프로젝트의 저장소를 꾸준히 기여하고, 참여하면 코딩 기술을 업그레이드할 뿐만 아니라 새로운 코딩 표준 및 공동 개발 방식을 접할 수 있습니다.
     
     
 7.  베타 릴리즈 사용해 보기
     얼리어답터가 되어 운영체제, SDK 및 개발도구의 베타 릴리즈를 실험하면 누구보다 빠른 기술을 습득할 수 있습니다. 이러한 경험을 통해 앱을 조정하고, 개발 커뮤니티에 좋은 의견들을 나눠볼 수 있죠.
     
     
 8.  업계 보고서 읽기
     보고서를 통해 업계 최신 동향을 광범위하게 얻을 수 있습니다. 또한 시장 행동과 타깃 유저 행동에 대한 통팔력을 통해 더 큰 그림을 이해하고, 프로젝트 방향에 대한 정보를 입각한 결정을 내릴 수 있습니다. 해외 쪽 뿐만 아니라 국내 주요 기업도 리포트를 발간하고 있으니, 참고하면 좋을 것 같습니다.
     
     
 9.  개인적인 개발 계획 수립
     커리어적인 성장을 위해 체계적인 계획을 개발하는 것이 중요합니다. 학습을 위한 시간을 확보하고, 강좌 및 컨퍼런스와 같은 앞선 내용들에 리소스를 할당하고 정기적으로 스스로 평가하는 시간을 가져보는 것이 좋습니다.
     
     
 10. 지속적인 네트워킹
     네트워킹은 최신 정보를 유지하는 데에 필수적인 요소입니다 동료 개발자와 소통하고, 적극적으로 협업 기회를 찾아보는 것입니다. 멘토링 및 협업 프로젝트에 참여하는 것도 좋습니다.
     
     본문에 대한 원글은 아래 링크에서 볼 수 있습니다.
     https://medium.com/gitconnected/how-to-stay-up-to-date-as-a-mobile-developer-0d6c5ef47acc

개발자가 간단하게 실천할 수 있는 최신 정보 습득 방법에 대해 가져와 봤습니다! 이미 실천하고 계신 분들도 많으실 것 같네요ㅎㅎ 빠르게 변하는 산업인 만큼 지속적으로 새로운 정보를 받아들이는 것은 중요할 것 같습니다. <ol ><li>개발자 블로그 및 뉴스레터 구독하기iOS, aOS 공식 블로그뿐만 아니라 업계 전문가가 운영하는 블로그나 뉴스레터를 정기적으로 받아보는 것은 꾸준히 정보의 흐름을 읽을 수 있는 가장 좋은 방법입니다. </li><li>소셜 미디어 및 온라인 커뮤니티에 참여하기트위터, 레딧, 스택오브플로우와 같은 개발자 커뮤니티에 가입하는 것은 개발자들과 함께 소통하면서 성장할 수 있는 좋은 방법입니다. (커리어리도 마찬가지입니다!) 관련 해시태그를 팔로우하고, 스레드에 참여해서 좋은 정보를 실시간으로 얻어보세요! (개인적으로 일론머스크의 트윗이 재밌더군요...) </li><li>컨퍼런스 및 모임 참석온라인 및 오프라인 컨퍼런스에 주기적으로 참여하면 동료 개발자들과 네트워크를 형성하고, 최신 업계 동향을 접할 수 있습니다. wwdc, google i/o뿐만 아니라 국내 기업에서 주최하는 세션이나 컨퍼런스에 참여해 보세요! </li><li>온라인 강좌를 통한 지속적 학습코세라와 같은 유명 플랫폼에서 제공하는 온라인 강좌를 통해 지속적으로 지식을 심화해 나가는 것도 좋은 방법입니다. 최신 도구나 프레임워크를 학습하는 것은 나에게 큰 도움이 될 것입니다! </li><li>출퇴근 시간에 팟캐스트 듣기통근 시간을 이용해 팟캐스트의 힘을 활용해 보세요! Fragmented, Swift by Sundell 및 Android Developers Backstage와 같은 팟캐스트에서는 최신 모바일 개발 사례나 인터뷰 및 토론을 제공합니다! 영어 공부도 덤이고요! 이 외에 주요 CEO들이 출연하여 기술에 대해 이야기하는 ACQUIRED를 추천드립니다! 최근에는 앤비디아의 젠슨 황이 출연하기도 했죠. </li><li>GitHub 리포지토리 및 오픈 소스 프로젝트를 팔로우하기GitHub만큼이나 개발자가 코드를 파보기가 좋은 데가 없죠. 도메인와 관련된 프레임워크 라이브러리 오픈소스 프로젝트의 저장소를 꾸준히 기여하고, 참여하면 코딩 기술을 업그레이드할 뿐만 아니라 새로운 코딩 표준 및 공동 개발 방식을 접할 수 있습니다. </li><li>베타 릴리즈 사용해 보기 얼리어답터가 되어 운영체제, SDK 및 개발도구의 베타 릴리즈를 실험하면 누구보다 빠른 기술을 습득할 수 있습니다. 이러한 경험을 통해 앱을 조정하고, 개발 커뮤니티에 좋은 의견들을 나눠볼 수 있죠. </li><li>업계 보고서 읽기보고서를 통해 업계 최신 동향을 광범위하게 얻을 수 있습니다. 또한 시장 행동과 타깃 유저 행동에 대한 통팔력을 통해 더 큰 그림을 이해하고, 프로젝트 방향에 대한 정보를 입각한 결정을 내릴 수 있습니다. 해외 쪽 뿐만 아니라 국내 주요 기업도 리포트를 발간하고 있으니, 참고하면 좋을 것 같습니다. </li><li>개인적인 개발 계획 수립커리어적인 성장을 위해 체계적인 계획을 개발하는 것이 중요합니다. 학습을 위한 시간을 확보하고, 강좌 및 컨퍼런스와 같은 앞선 내용들에 리소스를 할당하고 정기적으로 스스로 평가하는 시간을 가져보는 것이 좋습니다. </li><li>지속적인 네트워킹네트워킹은 최신 정보를 유지하는 데에 필수적인 요소입니다 동료 개발자와 소통하고, 적극적으로 협업 기회를 찾아보는 것입니다. 멘토링 및 협업 프로젝트에 참여하는 것도 좋습니다. 본문에 대한 원글은 아래 링크에서 볼 수 있습니다.https://medium.com/gitconnected/how-to-stay-up-to-date-as-a-mobile-developer-0d6c5ef47acc</li></ol>

개발자가 실생활에서 실천할 수 있는 스터디 방법 소개 🔑

 1. 기본기 확실히 하기
 2. 학습 능력 키우기
 3. 의사 소통 잘하기
 4. 문제 정의 잘하기
 5. 태스크 완료 시간 추정 잘하기
 6. 운영을 고려한 코드 작성하기
 7. 서비스 사고 대처 능력 키우기
 8. 결과를 내는데 집중하기
 9. 영향력 갖기 (코딩 멍키)

대부분의 개발자들은 굉장히 트렌디하다. 특히 한국 개발자들이 더 그렇다. 회사 일이 아무리 바쁘고 재미있어도 일에서 사용하는 기술이 최신이 아닌 레거시라고 생각하면 뒤쳐진다고 느끼고 조바심과 불안감을 많이 느낀다. 안 그래도 시간도 없고 힘도 부치는데 회사 일이 끝나면 새로운 기술을 조바심/불안감 기반으로 공부하는 경우가 아주 흔한다. 흔히 이야기하는 주경야독인데 약간 건강하지 않은 형태의 주경야독이다. 낮에는 회사 일을 하느라 바쁜 와중에 밤에는 선행학습을 하느라 바쁘다는 거다. 예를 들면 회사에서 레거시 시스템을 사용하는데 이게 커리어에 도움이 안된다고 보니 밤에 지금 마켓에서 핫한 시스템 공부를 하는 거다. 이 공부의 모티브가 중요한데 불안감이나 조바심이 주된 모티브라면 건강하지 않다.

내가 생각하는 건강한 학습은 평소 맡은 업무에 몰두하고 성취하는 경험을 통해 자신감을 쌓고 인정받고 (이에 대해서 뒤 "3. 의사 소통 잘하기"와 "4. 문제 정의 잘하기"에서 더 이야기해볼 예정이다) 이를 바탕으로 필요 중심 그리고 호기심 중심으로 학습하는 것이다. 즉 "현재"(필요성)에 집중하고 "나"(호기심)에 집중하는 거다. 여기에 약간의 조바심이나 불안감이 조미료처럼 첨가된다면 금상첨화다.

그런데 이게 가능하라면 내가 있는 환경이 중요해진다. 내가 잘 맞지 않는 환경이라면 현재에 집중하기가 쉽지 않을 것이다. 잘 맞는 환경인지 아닌지 판단하는 첫 번째는 같이 일하는 사람들이 어떤 사람들인지 특히 내 매니저가 어떤 사람인지 보는 건데 힘들어도 배울 점이 많고 성장한다는 느낌이 든다면 좋은 환경이다.

다음으로 나만의 학습방법을 만들어보는 것이 필요하다. 수능공부를 하는 것이 아니니 뭔가 두꺼운 책을 하나 사서 처음부터 끝까지 읽어야만 학습이 아니란 점, 필요한만큼 이해하고 넘어가도 된다는 점, 학습을 하다보면 항상 어느 시점에는 벽에 부딪칠 것이기에 꾸준함이 중요하다는 것 등등을 인지해야 한다. 개인적으로는 잘 모르는 주제가 생기면 유투브 등으로 짧은 영상 몇개 보고 더 깊게 들어갈 필요가 있다면 잘 아는 지인들에게 (적절히 보상을 해주고) 물어본다던지 아니면 더 긴 영상 강의(유데미, 인프런, 유투브 등등)등을 찾아서 밀도있게 학습하는 형태로 가려고 한다. 뭔가 정말 제대로 배우고 싶을텐데 다른 사람을 가르쳐보거나 톡을 하는 기회를 만들어서 강제로 학습하려고 한다.

결국 내가 인정받는 것은 내가 만든 결과물이지 어떤 기술을 알고 있느냐는 아니라는 점을 인식하고 호기심과 필요성 중심으로 학습으로 하는 습관을 갖도록 하자.

<ol ><li>기본기 확실히 하기</li><li>학습 능력 키우기</li><li>의사 소통 잘하기</li><li>문제 정의 잘하기</li><li>태스크 완료 시간 추정 잘하기</li><li>운영을 고려한 코드 작성하기</li><li>서비스 사고 대처 능력 키우기</li><li>결과를 내는데 집중하기</li><li>영향력 갖기 <s>(코딩 멍키)</s></li></ol> 대부분의 개발자들은 굉장히 트렌디하다. 특히 한국 개발자들이 더 그렇다. 회사 일이 아무리 바쁘고 재미있어도 일에서 사용하는 기술이 최신이 아닌 레거시라고 생각하면 뒤쳐진다고 느끼고 조바심과 불안감을 많이 느낀다. 안 그래도 시간도 없고 힘도 부치는데 회사 일이 끝나면 새로운 기술을 조바심/불안감 기반으로 공부하는 경우가 아주 흔한다. 흔히 이야기하는 주경야독인데 약간 건강하지 않은 형태의 주경야독이다. 낮에는 회사 일을 하느라 바쁜 와중에 밤에는 선행학습을 하느라 바쁘다는 거다. 예를 들면 회사에서 레거시 시스템을 사용하는데 이게 커리어에 도움이 안된다고 보니 밤에 지금 마켓에서 핫한 시스템 공부를 하는 거다. 이 공부의 모티브가 중요한데 불안감이나 조바심이 주된 모티브라면 건강하지 않다. 내가 생각하는 건강한 학습은 평소 맡은 업무에 몰두하고 성취하는 경험을 통해 자신감을 쌓고 인정받고 (이에 대해서 뒤 "3. 의사 소통 잘하기"와 "4. 문제 정의 잘하기"에서 더 이야기해볼 예정이다) 이를 바탕으로 필요 중심 그리고 호기심 중심으로 학습하는 것이다. 즉 "현재"(필요성)에 집중하고 "나"(호기심)에 집중하는 거다. 여기에 약간의 조바심이나 불안감이 조미료처럼 첨가된다면 금상첨화다. 그런데 이게 가능하라면 내가 있는 환경이 중요해진다. 내가 잘 맞지 않는 환경이라면 현재에 집중하기가 쉽지 않을 것이다. 잘 맞는 환경인지 아닌지 판단하는 첫 번째는 같이 일하는 사람들이 어떤 사람들인지 특히 내 매니저가 어떤 사람인지 보는 건데 힘들어도 배울 점이 많고 성장한다는 느낌이 든다면 좋은 환경이다. 다음으로 나만의 학습방법을 만들어보는 것이 필요하다. 수능공부를 하는 것이 아니니 뭔가 두꺼운 책을 하나 사서 처음부터 끝까지 읽어야만 학습이 아니란 점, 필요한만큼 이해하고 넘어가도 된다는 점, 학습을 하다보면 항상 어느 시점에는 벽에 부딪칠 것이기에 꾸준함이 중요하다는 것 등등을 인지해야 한다. 개인적으로는 잘 모르는 주제가 생기면 유투브 등으로 짧은 영상 몇개 보고 더 깊게 들어갈 필요가 있다면 잘 아는 지인들에게 (적절히 보상을 해주고) 물어본다던지 아니면 더 긴 영상 강의(유데미, 인프런, 유투브 등등)등을 찾아서 밀도있게 학습하는 형태로 가려고 한다. 뭔가 정말 제대로 배우고 싶을텐데 다른 사람을 가르쳐보거나 톡을 하는 기회를 만들어서 강제로 학습하려고 한다. 결국 내가 인정받는 것은 내가 만든 결과물이지 어떤 기술을 알고 있느냐는 아니라는 점을 인식하고 호기심과 필요성 중심으로 학습으로 하는 습관을 갖도록 하자.

좋은 개발자가 알아야하는 9가지 포인트들 - 2. 학습 능력 키우

스레드를 5개월만에 런칭하기 위해 모놀리틱 아키텍처를 사용했고, 5일 만에 1억명의 사용자가 몰려드는 것을 수용할 수 있었음.

사용된 기술은 커스텀 버전의 Django와 PHP, 데이터 저장소로는 TAO/UDB/MySQL와 ZippyDB 그리고 피크 타임을 위한 서버리스 펑션 Async.

자, 말 할 거 많죠? ㅋㅋㅋ 한마디하고 싶은 분들 다 여기여기 붙으세요. 🤣🤣🤣

스레드를 5개월만에 런칭하기 위해 모놀리틱 아키텍처를 사용했고, 5일 만에 1억명의 사용자가 몰려드는 것을 수용할 수 있었음. 사용된 기술은 커스텀 버전의 Django와 PHP, 데이터 저장소로는 TAO/UDB/MySQL와 ZippyDB 그리고 피크 타임을 위한 서버리스 펑션 Async. 자, 말 할 거 많죠? ㅋㅋㅋ 한마디하고 싶은 분들 다 여기여기 붙으세요. 🤣🤣🤣

📝 메타의 스레드, 모놀리틱 아키텍처 사용

차세대 자바스크립트 런타임으로 주목받고 있는 Bun이 v1.1을 출시하였습니다. 하필 거짓말처럼 만우절에 출시를 하여 윈도우즈 사용자들의 애간장을 태웠는데요. 그동안 Bun을 윈도우에서 사용하려면 WSL(Windows Subsystem for Linux)가 필요했었는데, 이제는 네이티브로도 사용할 수 있게 되었습니다 🙌

자세한 내용은 아래 공식 블로그와 유튜브 영상을 참고 바랍니다. 실제 Bun을 개발하고 있는 엔지니어들이 직접 나와서 소개하고 있는데 같은 개발자로서 약간 웃프네용 😂

📝 블로그: https://bun.sh/blog/bun-v1.1
📺 영상: https://youtu.be/yXTFOeGly9o

많은 분들이 Bun을 단순히 Node.js 보다 무지 빠른 자바스크립트 런타임이라고 알고 계시는데, 사실 Bun은 개발자 경험이 놀랍도록 띄어난 올인원 툴키트(all-in-one toolkit)입니다. Bun만 있으면 복잡한 과정없이 자바스크립트 뿐만 아니라 타입스크립트나 JSX로 작성된 코드를 바로 실행할 수 있으며, 패키지 매니저와 테스트 러너, 심지어 번들러까지 탑재하고 있습니다. 즉, 이 모든 귀찮은 일들이 다른 라이브러리 설치하지 않아도 Bun 하나만 있으면 해결됩니다 🤯

Bun에 대해서 더 알고 싶으시다면 아래 게시물을 추천드리겠습니다.

📕 Bun: 귀엽지만 강력한 새로운 자바스크립트 런타임: https://careerly.co.kr/comments/92202

차세대 자바스크립트 런타임으로 주목받고 있는 Bun이 v1.1을 출시하였습니다. 하필 거짓말처럼 만우절에 출시를 하여 윈도우즈 사용자들의 애간장을 태웠는데요. 그동안 Bun을 윈도우에서 사용하려면 WSL(Windows Subsystem for Linux)가 필요했었는데, 이제는 네이티브로도 사용할 수 있게 되었습니다 🙌 자세한 내용은 아래 공식 블로그와 유튜브 영상을 참고 바랍니다. 실제 Bun을 개발하고 있는 엔지니어들이 직접 나와서 소개하고 있는데 같은 개발자로서 약간 웃프네용 😂 📝 블로그: https://bun.sh/blog/bun-v1.1📺 영상: https://youtu.be/yXTFOeGly9o 많은 분들이 Bun을 단순히 Node.js 보다 무지 빠른 자바스크립트 런타임이라고 알고 계시는데, 사실 Bun은 개발자 경험이 놀랍도록 띄어난 올인원 툴키트(all-in-one toolkit)입니다. Bun만 있으면 복잡한 과정없이 자바스크립트 뿐만 아니라 타입스크립트나 JSX로 작성된 코드를 바로 실행할 수 있으며, 패키지 매니저와 테스트 러너, 심지어 번들러까지 탑재하고 있습니다. 즉, 이 모든 귀찮은 일들이 다른 라이브러리 설치하지 않아도 Bun 하나만 있으면 해결됩니다 🤯 Bun에 대해서 더 알고 싶으시다면 아래 게시물을 추천드리겠습니다. 📕 Bun: 귀엽지만 강력한 새로운 자바스크립트 런타임: https://careerly.co.kr/comments/92202

🥟 Bun v1.1 출시 소식

디자인 시스템, 코드를 넘어서

https://so-so.dev/react/design-system-beyond-code/

같은 걸 3번 만드는 경험은 흔치 않죠. 그래서 글에 깊은 맛이 있답니다!!

https://so-so.dev/react/design-system-beyond-code/ 같은 걸 3번 만드는 경험은 흔치 않죠. 그래서 글에 깊은 맛이 있답니다!!

So-so

디자인시스템 3번만든 이야기

🕊️ 2024 버클리즈 Java SpringBoot 인터뷰 질문 

Learn to become an Data Analyst using this roadmap. Community driven, articles, resources, guides, interview questions, quizzes for modern backend development.

Data Analyst Roadmap

개발자분들은 roadmap.sh에 대해 이미 아시겠죠?
최근 데이터분석가의 로드맵도 업데이트되어 공유합니다!

사실 이렇게 보면.. 개발자 로드맵보다 조금 정립되어있지 않은 느낌도 드는데, 그래도 참고해보면 좋을 것 같아요!

https://roadmap.sh/data-analyst

개발자분들은 roadmap.sh에 대해 이미 아시겠죠?최근 데이터분석가의 로드맵도 업데이트되어 공유합니다! 사실 이렇게 보면.. 개발자 로드맵보다 조금 정립되어있지 않은 느낌도 드는데, 그래도 참고해보면 좋을 것 같아요! https://roadmap.sh/data-analyst

roadmap.sh

데이터분석가 로드맵 🤓

1. 감정은 전염되기 때문에 매우 중요하다.

2. 사람들은 자신과 연관된 것들을 자랑스러워하고 자신과 동료들이 성공할 것이라고 믿고 싶어 한다.

3. 그래서 조직을 이끄는 리더에게 주어진 가장 중요한 임무 하나가 자신감을 보여 주는 것이다.

4. 사람들은 자신감 넘치는 사람을 따르고 지지하고 싶어 한다.

5. 그렇기 때문에 자신감 있어 보이는 사람들이 취직하고 승진할 가능성이 크다.

6. 이뿐만 아니라 리더가 자신감 있게 행동하면 그 자신감이 전염되어 그를 따르는 다른 사람들도 더 자신감 있게 행동한다.

#권력을경영하는7가지원칙

1. 감정은 전염되기 때문에 매우 중요하다. 2. 사람들은 자신과 연관된 것들을 자랑스러워하고 자신과 동료들이 성공할 것이라고 믿고 싶어 한다. 3. 그래서 조직을 이끄는 리더에게 주어진 가장 중요한 임무 하나가 자신감을 보여 주는 것이다. 4. 사람들은 자신감 넘치는 사람을 따르고 지지하고 싶어 한다. 5. 그렇기 때문에 자신감 있어 보이는 사람들이 취직하고 승진할 가능성이 크다. 6. 이뿐만 아니라 리더가 자신감 있게 행동하면 그 자신감이 전염되어 그를 따르는 다른 사람들도 더 자신감 있게 행동한다. #권력을경영하는7가지원칙

< 리더의 자신감은 전염된다 >

Optimism, obsession, self-belief, raw horsepower and personal connections are how things get started. Cohesive teams, the right combination of calmness and urgency, and unreasonable commitment are...

What I Wish Someone Had Told Me

1. 일은 낙관, 집념, 신념, 거친 돌파력, 인간적 연결에서부터 시작됩니다.

2. 하지만 일을 마무리하는 것은 단합된 팀, 빠른 속도와 차분함의 조합, 무한한 헌신입니다.

3. (사람들이 착각하지만) 팀에게는 ‘중요한데 어려운 일을 하는 것’이 ‘중요하지 않지만 쉬운 일을 하는 것’보다 훨씬 더 쉽습니다. 담대한 목표는 사람들의 동기를 자극하니까요.

4. 인센티브는 슈퍼 파워지만, 신중하게 설정해야 합니다. (그게 고객이든, 직원이든, 한 번 도입한 인센티브를 되돌리긴 쉽지 않기 때문입니다)

5. (너무 많은 일을 동시에 벌이려고 하지 말고) 확신을 가지는 소수의 몇 가지에 자원을 집중하세요. 하지만 말이 쉽지, 이를 행동으로 옮기는 건 쉽진 않을 겁니다. 생각했던 것보다 훨씬 더 많은 것들을 (뼈를 깎는 고통을 감수하며) 제거해야 할 테니까요. (=존 우든 효과)

6. 커뮤니케이션은 명확하고 깔끔하게 하세요.

7. 조직의 구조가 구성원들이 생산적으로 일하는 것을 방해하게 않도록 하세요. 특히 관료주의와 헛소리에 대해선 발견할 때마다 싸우고, 구성원들 또한 이를 발견할 때마다 싸우도록 만드세요.

8. 비즈니스에서 중요한 건 결과입니다. 과정이 좋았다며, 나쁜 결과를 변명하도록 내버려두지 마세요. (결과가 안 좋았다면, 분명 프로세스에 문제가 있는 겁니다. 따라서 과정이 좋았다는 위로가 아니라, 문제를 파악하고 개선해야 더 나은 결과를 얻을 수 있습니다)

9. 채용에 더 많은 시간을 투자하고, 빠르게 성장할 가능성이 보이는 사람들을 영입하기 위해 위험을 무릎 써보세요!

10. 슈퍼스타는 보이는 것보다 훨씬 더 큰 가치를 가지지만, 그들에 대한 평가는 조직의 성과에 어떤 기여를 했는지를 두고 정확하게 내려야 합니다.

11. 빠른 반복은 많은 문제를 해결합니다. 특히 빠르게 반복할 수 있으면, 틀려도 상관없습니다. (빠르게 반복하는 과정에서 틀린 것들을 계속 수정할 테니까요)

12. 물리 법칙에 해당하는 비즈니스와는 싸우지 마세요. (비과학적인 믿음으로 사업을 하지 말라는 말입니다)

13. 영감은 쉽게 깨지고, 삶은 놀랍도록 빠릅니다. 그리고 아무것도 하지 않은 것이야말로 최악의 위험입니다.

14. 스케일은 급부상하고 있는 신흥 자산입니다.

15. 복리는 마법입니다. 그러니 규모와 복리가 만나는 비즈니스를 하세요.

16. 쓰러져도 다시 일어나 계속 나아가세요.

17. 위대한 사람들과 함께 일하는 것은 인생에서 가장 큰 축복 중 하나입니다.

- 샘 알트만

https://blog.samaltman.com/what-i-wish-someone-had-told-me

1. 일은 낙관, 집념, 신념, 거친 돌파력, 인간적 연결에서부터 시작됩니다. 2. 하지만 일을 마무리하는 것은 단합된 팀, 빠른 속도와 차분함의 조합, 무한한 헌신입니다. 3. (사람들이 착각하지만) 팀에게는 ‘중요한데 어려운 일을 하는 것’이 ‘중요하지 않지만 쉬운 일을 하는 것’보다 훨씬 더 쉽습니다. 담대한 목표는 사람들의 동기를 자극하니까요. 4. 인센티브는 슈퍼 파워지만, 신중하게 설정해야 합니다. (그게 고객이든, 직원이든, 한 번 도입한 인센티브를 되돌리긴 쉽지 않기 때문입니다) 5. (너무 많은 일을 동시에 벌이려고 하지 말고) 확신을 가지는 소수의 몇 가지에 자원을 집중하세요. 하지만 말이 쉽지, 이를 행동으로 옮기는 건 쉽진 않을 겁니다. 생각했던 것보다 훨씬 더 많은 것들을 (뼈를 깎는 고통을 감수하며) 제거해야 할 테니까요. (=존 우든 효과) 6. 커뮤니케이션은 명확하고 깔끔하게 하세요. 7. 조직의 구조가 구성원들이 생산적으로 일하는 것을 방해하게 않도록 하세요. 특히 관료주의와 헛소리에 대해선 발견할 때마다 싸우고, 구성원들 또한 이를 발견할 때마다 싸우도록 만드세요. 8. 비즈니스에서 중요한 건 결과입니다. 과정이 좋았다며, 나쁜 결과를 변명하도록 내버려두지 마세요. (결과가 안 좋았다면, 분명 프로세스에 문제가 있는 겁니다. 따라서 과정이 좋았다는 위로가 아니라, 문제를 파악하고 개선해야 더 나은 결과를 얻을 수 있습니다) 9. 채용에 더 많은 시간을 투자하고, 빠르게 성장할 가능성이 보이는 사람들을 영입하기 위해 위험을 무릎 써보세요! 10. 슈퍼스타는 보이는 것보다 훨씬 더 큰 가치를 가지지만, 그들에 대한 평가는 조직의 성과에 어떤 기여를 했는지를 두고 정확하게 내려야 합니다. 11. 빠른 반복은 많은 문제를 해결합니다. 특히 빠르게 반복할 수 있으면, 틀려도 상관없습니다. (빠르게 반복하는 과정에서 틀린 것들을 계속 수정할 테니까요) 12. 물리 법칙에 해당하는 비즈니스와는 싸우지 마세요. (비과학적인 믿음으로 사업을 하지 말라는 말입니다) 13. 영감은 쉽게 깨지고, 삶은 놀랍도록 빠릅니다. 그리고 아무것도 하지 않은 것이야말로 최악의 위험입니다. 14. 스케일은 급부상하고 있는 신흥 자산입니다. 15. 복리는 마법입니다. 그러니 규모와 복리가 만나는 비즈니스를 하세요. 16. 쓰러져도 다시 일어나 계속 나아가세요. 17. 위대한 사람들과 함께 일하는 것은 인생에서 가장 큰 축복 중 하나입니다. - 샘 알트만 https://blog.samaltman.com/what-i-wish-someone-had-told-me

Sam Altman

창업을 하고자 하는 사람들에게 해주고 싶은 말들

CPU에 대해 간단히 정리해보고 구형 노트북에서 직접 분해한 인텔 CPU 스펙 탐색하기 ! CPU란? Central Processing Unit 중앙처리장치, 중앙작업장치 프로세서(processor) 라고도 불린다. 사용자가 마우스나 키보드로 입력한 명령어를 수행하거나, 실행 중인 프로그램 명령어를 해석하여 데이터를 계산하고 처리하는 장치이다. 각 부품에 명령을 내린다. CPU 성능을 판단할 수 있는 척도인 코어, 스레드, 클럭을 사람에 비유해 이해해보

CPU에 대해 간단히 알아보고(feat. core, thread, clock), 메인보드에서 떼낸 내 CPU 스펙을 살펴보자

CPU에 관해 정리한 글이며, 마지막엔 직접 분해한 cpu의 스펙을 적어봤습니다. 
+) 하이퍼스레딩이란?

Having

CPU란 무엇인가 간단 정리(feat. 코어, 스레드, 클럭)

중국학부

천수병

Insta

Github

Tech Blog

안녕하세요.
머지않아 회사의 비즈니스 전략을 같이 고민하고픈 백엔드 주니어 개발자🧑🏻‍💻입니다.
현재 취준생이며, 많이 배우고 성장할 수 있는 회사의 신입 개발자가 되길 희망합니다😄
#개발자 #백엔드 #웹개발 #softskills

CPU란 무엇인가 간단 정리(feat. 코어, 스레드, 클럭)

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필