C++ Code

noconcoll

hihi

sdf33

asdfasdfsdfasdfsdfsdfsdasdfasdf<h3>dkdkdkd</h3><h1>dkdsklfjsdlkfj</h1>

asdfsdf

오늘 이야기할 단일 책임 원칙(SRP)은 이 SOLID 의 다섯 가지 원칙 중 첫 번째에 해당하며, 이를 잘 이해하고 적용하는 것이 나머지 원칙들을 제대로 구현할 수 있는 토대가 된다고 생각합니다 

단일 책임 원칙 (Single Responsibility Principle, SRP) - SOLID

Spring

<img src="https://image.until.blog/thingk0/article/1731421180527.png" data-width="100%" data-align="center" alt="2116">분명 Lombok의 애너테이션을 사용하는 것은 편리한 코드 자동 생성을 제공하지만, 성능 및 메모리 사용 측면에서 예상치 못한 문제가 발생할 수 있다는 것을 알고 계신가요???? <s>(아니면 아직 경험을 못 해봤거나..)</s><img src="https://image.until.blog/thingk0/article/1731419432597.png" data-width="50%" data-align="center" alt="2107">처음 Lombok을 도입했을 때, 코드의 양을 줄여주고, 수동으로 일일히 보일러 플레이트 코드를 작성할 필요 없이 간단하게 해결되는 점이 너무 편리하고 좋았습니다. 물론 지금도 좋아하구요 👍👍하.지.만 실제 프로젝트에서 여러 연관 관계를 가진 엔티티들을 다루다 보니, 예상치 못한 성능 저하나 무한 재귀 호출 등의 문제가 발생하기 시작했습니다.특히 Lazy 로딩 필드에서 의도치 않게 데이터베이스 조회가 일어나는 경험을 하면서 무조건적으로 롬복 어노테이션을 사용하는 것이 위험할 수 있음을 깨닫게 되었죠..<img src="https://image.until.blog/thingk0/article/1731419528568.png" data-width="75%" data-align="center" alt="2108">이 글에서는 롬복의 여러 어노테이션 중 특히 <code spellcheck="false">@EqualsAndHashCode</code> 사용 시 발생할 수 있는 주요 문제점들과 이를 해결하기 위한 대안에 대해 알아보겠습니다<hr><h2>1. @EqualsAndHashCode의 문제점</h2><code spellcheck="false">@EqualsAndHashCode</code>는 분명 편리한 자동 코드 생성을 가능하게 하지만, JPA와 결합할 때 몇 가지 주요 문제점들이 발생합니다. 이를 아래에서 자세히 살펴보겠습니다.<h3>1.1 Lazy 로딩 및 연관 관계 문제</h3><code spellcheck="false">@EqualsAndHashCode</code>는 모든 필드를 기반으로 <code spellcheck="false">equals</code>와 <code spellcheck="false">hashCode</code> 메서드를 자동으로 생성합니다.하지만 JPA 엔티티에서 연관 관계가 있는 필드를 사용할 경우, 예상치 못한 Lazy 로딩이 발생하여 성능에 큰 영향을 줄 수 있습니다.문제 설명JPA 엔티티에서 연관 관계를 가지는 필드를 <code spellcheck="false">@ManyToOne</code>이나 <code spellcheck="false">@OneToMany</code>로 선언할 때, 이를 Lazy 로딩 전략으로 설정하는 것이 일반적입니다그러나 <code spellcheck="false">@EqualsAndHashCode</code> 애너테이션이 연관된 필드를 참조할 경우, 해당 필드가 아직 초기화되지 않았다면 데이터베이스 조회가 발생합니다.<img src="https://image.until.blog/thingk0/article/1731419671479.png" data-width="50%" data-align="center" alt="2109">이는 의도치 않은 SQL 쿼리를 유발하고, 성능 저하의 원인이 될 수 있습니다.예시 코드<pre spellcheck="false"><code>@EqualsAndHashCode
@Entity
public class Order {

 @Id
 @GeneratedValue
 private Long id;

 @ManyToOne(fetch = FetchType.LAZY)
 private Customer customer;
 
}</code></pre>위 예시에서 <code spellcheck="false">Order</code> 클래스의 <code spellcheck="false">customer</code> 필드는 Lazy 로딩됩니다.그러나 <code spellcheck="false">@EqualsAndHashCode</code>가 적용되면 <code spellcheck="false">equals</code>나 <code spellcheck="false">hashCode</code> 메서드 호출 시 <code spellcheck="false">customer</code> 필드를 참조하게 되어 의도치 않은 데이터베이스 조회가 발생할 수 있습니다.<h3>1.2 StackOverflowError 발생 위험</h3>양방향 연관 관계에 있는 엔티티들에 <code spellcheck="false">@EqualsAndHashCode</code>를 사용하면, 무한 재귀 호출로 인해 <code spellcheck="false">StackOverflowError</code>가 발생할 수 있습니다.문제 설명양방향 연관 관계가 설정된 엔티티들은 서로를 참조하게 됩니다. 이때 <code spellcheck="false">@EqualsAndHashCode</code>가 적용된 필드에서 서로를 계속 참조하는 구조가 되어, 무한 재귀 호출이 발생합니다.이로 인해 애플리케이션은 <code spellcheck="false">StackOverflowError</code>로 인해 비정상 종료될 수 있습니다.예시 코드<pre spellcheck="false"><code>@EqualsAndHashCode
@Entity
public class Parent {

 @Id
 @GeneratedValue
 private Long id;

 @OneToMany(mappedBy = "parent")
 private List&lt;Child&gt; children;
 
}

@EqualsAndHashCode
@Entity
public class Child {

 @Id
 @GeneratedValue
 private Long id;

 @ManyToOne
 private Parent parent;

}</code></pre>위 코드에서 <code spellcheck="false">Parent</code>와 <code spellcheck="false">Child</code>는 서로 양방향 연관 관계를 가지고 있으며, 양쪽에 <code spellcheck="false">@EqualsAndHashCode</code>가 적용되어 있다면 <code spellcheck="false">equals</code> 및 <code spellcheck="false">hashCode</code> 메서드에서 무한 재귀가 발생합니다.<img src="https://image.until.blog/thingk0/article/1731419740710.png" data-width="75%" data-align="center" alt="2110">이는 결과적으로 <code spellcheck="false">StackOverflowError</code>를 유발하게 됩니다.<h3>1.3 메모리 과다 사용 문제</h3>모든 필드를 사용하여 <code spellcheck="false">hashCode</code>를 생성하는 경우, 엔티티의 크기가 크다면 메모리 사용량이 증가하게 됩니다. 이는 특히 대규모 엔티티나 복잡한 객체 구조를 가진 경우 문제를 일으킬 수 있습니다.문제 설명JPA에서는 엔티티의 <code spellcheck="false">hashCode</code>와 <code spellcheck="false">equals</code> 메서드가 영속성 컨텍스트에서 객체를 비교하고 식별하는 데 중요한 역할을 합니다.모든 필드를 <code spellcheck="false">hashCode</code> 생성에 사용하면 필드의 데이터 크기에 비례하여 메모리 사용량이 급격히 증가하게 됩니다.예시 코드<pre spellcheck="false"><code>@EqualsAndHashCode
@Entity
public class Product {

 @Id
 @GeneratedValue
 private Long id;

 private String name;
 private String description;
 private BigDecimal price;
 private LocalDateTime createdAt;
 
 ...

}</code></pre>위 코드에서 모든 필드를 사용하여 hashCode를 생성하는 경우, <code spellcheck="false">Product</code> 객체가 크다면 메모리 과다 사용 및 성능 저하를 초래할 수 있습니다.<img src="https://image.until.blog/thingk0/article/1731419804053.png" data-width="75%" data-align="center" alt="2111">이는 특히 해당 객체들이 컬렉션에 포함되어 있을 때 문제를 더욱 심화시킵니다.<hr><h2>2. 대안 및 해결 방안</h2><code spellcheck="false">@EqualsAndHashCode</code> 사용 시 발생할 수 있는 위와 같은 문제를 해결하기 위해, 다음과 같은 대안을 고려할 수 있습니다.<h3>2.1 식별자 필드만 사용</h3><code spellcheck="false">@EqualsAndHashCode</code> 대신, 엔티티의 고유 식별자 필드(예: <code spellcheck="false">id</code>)만을 기준으로 <code spellcheck="false">equals</code>와 <code spellcheck="false">hashCode</code> 메서드를 작성하는 것이 좋습니다.이를 통해 불필요한 필드 참조로 인한 성능 저하를 방지할 수 있습니다.예시 코드<pre spellcheck="false"><code>@EqualsAndHashCode(onlyExplicitlyIncluded = true)
@Entity
public class Product {

 @Id
 @GeneratedValue
 @EqualsAndHashCode.Include
 private Long id;

 private String name;
 private String description;
}</code></pre><h3>2.2 Lombok의 @EqualsAndHashCode 옵션 활용</h3>Lombok의 <code spellcheck="false">@EqualsAndHashCode</code> 애너테이션에 <code spellcheck="false">onlyExplicitlyIncluded = true</code> 옵션을 사용하고, 필요한 필드에 <code spellcheck="false">@EqualsAndHashCode.Include</code>를 적용하는 방식도 추천됩니다.<img src="https://image.until.blog/thingk0/article/1731419908753.png" data-width="50%" data-align="center" alt="2112">이를 통해 특정 필드만 포함하여 <code spellcheck="false">equals</code>와 <code spellcheck="false">hashCode</code>를 정의할 수 있습니다.예시 코드<pre spellcheck="false"><code>@EqualsAndHashCode(onlyExplicitlyIncluded = true)
@Entity
public class Order {

 @Id
 @GeneratedValue
 @EqualsAndHashCode.Include
 private Long id;

 @ManyToOne(fetch = FetchType.LAZY)
 private Customer customer;
 
}</code></pre>위 코드에서는 <code spellcheck="false">onlyExplicitlyIncluded = true</code>를 사용하여 <code spellcheck="false">id</code> 필드만 <code spellcheck="false">equals</code>와 <code spellcheck="false">hashCode</code>에 포함시킵니다.이를 통해 Lazy 로딩 필드를 참조하는 문제나 불필요한 메모리 사용 문제를 피할 수 있습니다.<hr><h2>3. 결론</h2>JPA 엔티티에서 Lombok의 <code spellcheck="false">@EqualsAndHashCode</code> 애너테이션을 사용할 때는 Lazy 로딩 필드 참조, 양방향 연관 관계로 인한 <code spellcheck="false">StackOverflowError</code>, 메모리 과다 사용 등의 문제에 주의해야 합니다.이러한 문제를 방지하기 위해 식별자 필드만 사용하거나, Lombok의 옵션을 적절히 활용하여 불필요한 필드를 제외하는 것이 바람직합니다.애플리케이션의 성능과 안정성을 보장하려면, <code spellcheck="false">@EqualsAndHashCode</code>의 사용을 신중하게 검토하고 필요한 경우 커스텀 메서드를 작성하는 것을 고려하는 것이 좋습니다.<img src="https://image.until.blog/thingk0/article/1731420503092.gif" data-width="50%" data-align="center" alt="2115">

편리하지만 치명적인 함정: Lombok의 @EqualsAndHashCode 사용 시 JPA 엔티티 성능 문제를 피하는 방법

Lombok의 @EqualsAndHashCode, 당신의 JPA 성능을 망칠 수도 있똬

애플리케이션을 설계할 때 우리는 코드 재사용성과 구조적 설계를 위해 <code spellcheck="false">상속(Inheritance)</code>과 <code spellcheck="false">컴포지션(Composition)</code>이라는 두 가지 주요 기법을 사용할 수 있습니다. 상속은 자식 클래스가 부모 클래스의 속성과 메서드를 물려받아 쉽게 코드 재사용이 가능하다는 장점을 가지고 있지만, 현실적으로 유지보수성에서 큰 문제를 일으킬 수 있습니다. 이러한 이유로 저는 상속을 피하고 싶은 경우가 많습니다.<img src="https://image.until.blog/thingk0/article/1731222508133.png" data-width="100%" data-align="center" alt="2052">대안으로 컴포지션은 객체 간의 느슨한 결합을 유지하며, 설계 유연성과 변경 용이성을 높여줍니다. 이 글에서는 왜 '상속'을 피하고 싶은지에 대한 이유와 컴포지션이 어떤 장점들을 제공하는지 비교해 보겠습니다 !<hr><h3>1. 상속 (Inheritance)</h3><img src="https://image.until.blog/thingk0/article/1731222764517.png" data-width="100%" data-align="center" alt="2053">상속은 자식 클래스가 부모 클래스의 속성과 메서드를 물려받는 구조로, 코드 재사용성을 극대화하고 계층적 구조를 쉽게 구현할 수 있습니다. 그러나 이러한 장점들에도 불구하고 상속에는 여러 단점이 존재합니다.장점:<ul><li>코드의 재사용성: 부모 클래스에 정의한 기능을 자식 클래스에서 재사용할 수 있어 코드 중복을 줄입니다. <ul><li>예를 들어, 여러 컨트롤러에서 공통적으로 사용하는 로직을 <code spellcheck="false">BaseController</code>에 정의할 수 있습니다.<pre spellcheck="false"><code>public class BaseController {
 public void logRequest() {
 System.out.println("Request received");
 }
}

public class UserController extends BaseController {
 public void getUser() {
 logRequest();
 // 사용자 정보 반환 로직
 }
}</code></pre></li></ul></li><li>계층적 구조: 클래스 간 관계가 명확해지므로 구조적인 설계가 용이합니다. <ul><li>예를 들어, <code spellcheck="false">UserController</code>와 같은 컨트롤러 클래스가 <code spellcheck="false">BaseController</code>를 상속받으면 이를 통해 로직의 구조를 명확하게 나타낼 수 있습니다.</li></ul></li><li>다형성: 부모 타입으로 자식 클래스를 참조하여 코드를 더 유연하게 작성할 수 있습니다. <ul><li>예를 들어, 다양한 동물 클래스를 <code spellcheck="false">Animal</code>이라는 부모 클래스로 묶어 처리할 수 있습니다.<pre spellcheck="false"><code>public class Animal {
 public void makeSound() {
 System.out.println("Some sound");
 }
}

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

public class Cat extends Animal {
 @Override
 public void makeSound() {
 System.out.println("Meow");
 }
}

public void playWithAnimal(Animal animal) {
 animal.makeSound();
}</code></pre></li></ul></li></ul>단점:<ul><li>강한 결합: 부모 클래스와 자식 클래스 간 결합이 강해지기 때문에 부모 클래스가 변경되면 자식 클래스에까지 영향을 미칠 수 있습니다. 이로 인해 유지보수가 매우 어려워질 수 있습니다.<img src="https://image.until.blog/thingk0/article/1731223081267.png" data-width="100%" data-align="center" alt="2055"><ul><li>이미지 출처: <a target="_blank" rel="noopener noreferrer nofollow" href="https://ahnyezi.github.io/java/javastudy-8-interface/">https://ahnyezi.github.io/java/javastudy-8-interface/</a></li></ul></li><li>유연성의 부족: 자바는 단일 상속만 지원하므로 설계에 제약이 생기고, 확장성이 떨어질 수 있습니다.</li><li>재사용의 한계: 상속은 "is-a" 관계일 때만 적합하며, 무리하게 사용할 경우 구조가 불명확해질 수 있습니다. <ul><li>상속 관계를 남용하면 결국 코드의 가독성이나 유지보수성이 저하될 수 있습니다.</li></ul></li></ul><hr><h3>2. 컴포지션 (Composition)</h3><img src="https://image.until.blog/thingk0/article/1731222971312.png" data-width="100%" data-align="center" alt="2054">컴포지션은 객체가 다른 객체를 멤버 변수로 포함하는 방식으로, 객체 간의 느슨한 결합을 유지합니다. 이는 "has-a" 관계를 형성하며, 더 유연한 설계를 가능하게 합니다.장점:<ul><li>유연성: 컴포지션을 통해 클래스 간 결합을 느슨하게 만들 수 있으며, 이를 통해 독립적인 변경과 기능 확장이 가능합니다. 스프링의 <code spellcheck="false">@Autowired</code>를 통한 의존성 주입 방식도 이러한 컴포지션을 활용한 사례입니다.<pre spellcheck="false"><code>public class LoggingService {
 public void log(String message) {
 System.out.println(message);
 }
}

public class UserService {
 private final LoggingService loggingService;

 public UserService(LoggingService loggingService) {
 this.loggingService = loggingService;
 }

 public void createUser() {
 loggingService.log("Creating user");
 // 사용자 생성 로직
 }
}</code></pre></li><li>재사용성 향상: 여러 클래스에서 공통으로 사용하는 <code spellcheck="false">LoggingService</code>를 다른 클래스에 포함하여 로깅 기능을 재사용할 수 있습니다.</li><li>다중 기능 구현: 자바의 단일 상속 제약을 우회하고, 여러 객체의 기능을 동시에 활용할 수 있습니다. <ul><li>예를 들어, <code spellcheck="false">NotificationService</code>와 <code spellcheck="false">AuditService</code>를 모두 포함하는 <code spellcheck="false">OrderService</code>를 설계할 수 있습니다.<pre spellcheck="false"><code>public class NotificationService {
 public void sendNotification(String message) {
 System.out.println("Notification: " + message);
 }
}

public class AuditService {
 public void audit(String action) {
 System.out.println("Audit log: " + action);
 }
}

public class OrderService {
 private final NotificationService notificationService;
 private final AuditService auditService;

 public OrderService(NotificationService notificationService, AuditService auditService) {
 this.notificationService = notificationService;
 this.auditService = auditService;
 }

 public void placeOrder() {
 auditService.audit("Order placed");
 notificationService.sendNotification("Your order has been placed.");
 }
}</code></pre></li></ul></li></ul>단점:<ul><li>코드 복잡도 증가: 객체 간의 관계 설정 및 관리가 복잡해질 수 있습니다. 하지만 이는 객체 간의 독립성과 유연성을 얻기 위한 대가입니다.</li><li>인터페이스 의존: 컴포지션을 잘 활용하기 위해서는 인터페이스 설계가 중요하며, 이는 초기 설계의 복잡성을 높일 수 있습니다. <ul><li>하지만 이런 인터페이스 기반 설계는 장기적으로 볼 때 유지보수성과 확장성에서 이점을 제공할 수 있습니다.</li></ul></li></ul><hr><h3>3. 언제 상속을, 언제 컴포지션을 사용할까?</h3><img src="https://image.until.blog/thingk0/article/1731223295411.png" data-width="100%" data-align="center" alt="2056"><ul><li>코드 재사용이 목적일 때: 코드 재사용이 주된 목적이며, "is-a" 관계가 명확할 경우 상속을 고려할 수 있습니다. 예를 들어, 공통 엔티티를 상속받아 여러 도메인 모델을 생성하는 경우입니다.<pre spellcheck="false"><code>public class BaseEntity {
 private Long id;
 private LocalDateTime createdAt;
 private LocalDateTime updatedAt;
 // getter, setter, 공통 로직 등
}

public class User extends BaseEntity {
 private String name;
 private String email;
 // User-specific 로직
}

public class Product extends BaseEntity {
 private String productName;
 private double price;
 // Product-specific 로직
}</code></pre></li><li>유연성과 유지보수성: 시스템의 복잡도가 높고 변화 가능성이 큰 경우 컴포지션이 더 적합합니다. 스프링에서 다양한 Bean을 조합해 애플리케이션을 구성하는 방식이 그 예입니다.<pre spellcheck="false"><code>@Service
public class OrderService {
 private final PaymentService paymentService;
 private final ShippingService shippingService;

 @Autowired
 public OrderService(PaymentService paymentService, ShippingService shippingService) {
 this.paymentService = paymentService;
 this.shippingService = shippingService;
 }

 public void processOrder(Order order) {
 paymentService.processPayment(order);
 shippingService.shipOrder(order);
 }
}</code></pre></li><li>테스트 용이성: 컴포지션은 테스트하기 쉽습니다. 독립적인 Mocking 및 주입을 통한 단위 테스트가 가능하기 때문입니다.<pre spellcheck="false"><code>@Mock
private PaymentService paymentService;

@Mock
private ShippingService shippingService;

@InjectMocks
private OrderService orderService;

@Test
public void testProcessOrder() {
 Order order = new Order();
 // Mocking 설정
 doNothing().when(paymentService).processPayment(order);
 doNothing().when(shippingService).shipOrder(order);

 orderService.processOrder(order);

 // 메서드 호출 확인
 verify(paymentService).processPayment(order);
 verify(shippingService).shipOrder(order);
}</code></pre></li><li>다중 상속의 필요: 자바의 단일 상속 제약을 피하고 여러 객체의 기능을 조합해야 할 때 컴포지션을 사용하는 것이 좋습니다.<pre spellcheck="false"><code>public class ReportService {
 private final NotificationService notificationService;
 private final LoggingService loggingService;

 public ReportService(NotificationService notificationService, LoggingService loggingService) {
 this.notificationService = notificationService;
 this.loggingService = loggingService;
 }

 public void generateReport() {
 loggingService.log("Generating report...");
 // 리포트 생성 로직
 notificationService.sendNotification("Report generated successfully");
 }
}</code></pre></li></ul><hr><h3>4. 결론</h3>상속과 컴포지션은 각각 장단점이 있으며, 상황에 따라 적절히 선택하는 것이 중요합니다. 그러나 저는 개인적으로 '상속'을 자주 사용하고 싶지 않습니다. 왜냐하면 강한 결합과 유연성 부족으로 인해 유지보수성이 떨어질 수 있기 때문입니다. <img src="https://image.until.blog/thingk0/article/1731223501373.png" data-width="50%" data-align="center" alt="2057">반면, 컴포지션은 느슨한 결합과 높은 유연성을 제공하며, 변화와 확장에 강한 구조를 설계할 수 있도록 도와줍니다. 이는 스프링부트 애플리케이션에서 더 유지보수하기 쉬운 설계를 만드는 데 큰 도움이 됩니다.최종적으로는 애플리케이션의 요구사항과 유지보수성, 확장성을 고려하여 두 가지 접근법을 적절히 혼용하는 것이 바람직합니다. 하지만 장기적인 관점에서 컴포지션을 더 많이 활용하는 것이 더 나은 설계로 이어질 수 있다고 생각합니다 :)

저는 왜 '상속'을 피하고 싶은지에 대한 이유와 컴포지션이 어떤 장점들을 제공하는지 비교해 보겠습니다

저는 사실 '상속' 을 별로 좋아하지 않아요 ?

🪟 Window

<img src="https://image.until.blog/morethanmin/article/1716045513650" alt="until-71">항상 맥북만 사용하다가 이번에 데스크탑을 맞추게 되면서 개발환경을 윈도우에서 세팅하게 되었다.<h2>fnm이란?</h2>노드 버전을 관리할 수 있게 해주는 매니저로 nvm과 유사하지만 윈도우에서는 nvm이 지원되지 않기 때문에 fnm를 사용해보려고한다.<h2>winget으로 fnm 설치하기</h2>파워쉘에서 아래와 같이 입력하여 설치할 수 있다.<pre spellcheck="false"><code>winget install Schniz.fnm</code></pre><h3>0x8a15000f 오류가 발생하는 경우</h3>마이크로소프트 스토어에서 앱 설치 관리자를 업데이트 해주면 된다.<img src="https://image.until.blog/morethanmin/article/1716045690970" alt="until-72"><h2>fnm으로 node 설치하기</h2><h3>프로필 설정</h3>우선 <code spellcheck="false">PowerShell</code>프로필에 환경변수를 등록해야한다.<code spellcheck="false">~\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1</code> 경로에 아래와같이 입력 해주면 된다.<pre spellcheck="false"><code>fnm env --use-on-cd | Out-String | Invoke-Expression</code></pre><h3>PowerShell 실행시 PSSecurityException 오류가 발생하는 경우</h3>기본적으로 스크립트 삽입하는 것이 막혀있기 때문에 설정을 바꿔줘야한다.관리자 권한으로 <code spellcheck="false">PowerShell</code> 을 실행해서 아래와 같이 입력한다.<pre spellcheck="false"><code>Set-ExecutionPolicy RemoteSigned</code></pre><h3>node 설치</h3>이제 <code spellcheck="false">PowerShell</code> 을 재부팅하고 아래와 같이 입력해 노드를 설치하면된다.<pre spellcheck="false"><code>fnm use --install-if-missing 20</code></pre><hr>그럼 이제 node를 사용할 수 있다! 근데 PowerShell도 그렇고 여러 이슈들도 그렇고 좀 귀찮은 것 같다. 좀 더 사용해보다가 정 안되면 wsl을 사용해야겠다.

항상 맥북만 사용하다가 이번에 데스크탑을 맞추게 되면서 개발환경을 윈도우에서 세팅하게 되었다.fnm이란?노드 버전을 관리할 수 있게 해주는 매니저로 nvm과 유사하지만 윈도우에서는 nvm이 지원되지 않기 때문에 fnm를 사용해보려고한다.winget으로 fnm 설치하기파워쉘에서 아래와 같이 입력하여 설치할 수 있다.winget install Schniz.fn

윈도우에서 winget으로 fnm 설치하기 (Fast Node Manager)

취미

<h3>HG x Minecraft Base 65 Keyboard - Grass Block 구매후기</h3><a target="_blank" rel="noopener noreferrer nofollow" href="https://higround.co/products/minecraft-x-hg-base-65-keyboard-grass-block">https://higround.co/products/minecraft-x-hg-base-65-keyboard-grass-block</a><hr>나는 몰랐다. 내가 마인크래프트 굿즈를 살줄... 근데 그게 키보드 일줄... 근데 그걸 직구를 할줄...나는 게임을 좋아하는데 마인크래프트랑 포켓몬을 좋아하는 편이다.하이그라운드에서는 둘다 판매를 한다. 키보드를 몇번 사봤다만, 화이트에 심플한 디자인만 사다가 애정하는 캐릭터들이 잔뜩 그려져 있는 키보드를 보니 눈이 돌아가는줄 알았다. 하이그라운드에는 그 외의 덕질하기 좋은 애니키보드도 많다.아주.. 뭔가 잘 아는 사람들인거같다... 음...어찌됐든 저찌됐든 7월 2일에 구매해서 7월 11일에 배송받앗다. 생각보다 빠르게 배송받았다.구매 과정에서 주문취소가 3번이나 되기도 했으며 영어로 메일을 보내기도 했고 그 과정을 좀 공유하려 한다.구매를 고민하는 분들 의사결정에 도움이 되길..<h1></h1><h1>결제금액</h1><img src="https://image.until.blog/dody/article/1720795464943" alt="until-819">패키지 보호? 저건 배송보험 인거같아서 소중히 제품을 받고 싶은 마음에 결제했다.키보드는 145달러 20만원 정도이고, 원래 쓰던 키보드들도 그정도 해서 크게 부담이 되진않았다.배송비는 5만원정도인데, 뭐 해외에서 오는 값 생각하면 비싸지만... 어쩔수 없다 생각...그렇게 25만원 정도로 구매를 했다.<h1>3번의 주문 취소</h1>나는 해외직구는 처음인데 결제정보를 제대로 입력했음에도 불구하고, 계속해서 취소되었다고 메일을 받았다. 주문하자마자 취소를 받았기 때문에.. 내가 잘못된 정보를 작성한건가? 싶어서 메일을 보냈다.<blockquote><h4>Why cancel my payment?</h4>I really want to buy it, but is there something I'm writing wrong? I'm curious what the problem is.</blockquote>딱 이렇게 본론만 적어 6월21일 메일을 보냈고, 아래 답장을 7월 2일에 받았다.한국의 고객센터와 같은 속도를 바라지 않았기 때문에 천천히 기다렸다. 그래도 친절하게 사유를 알려주셨고.. 자동플래그에서 나를 제외해서 결제하기에 문제가 없게 도와주셨다.내가 또 개발자이다 보니, 저러한 의사결정과 대응에 아주 만족하고 감사함을 느끼고 바로 주문을 다시 했고<img src="https://image.until.blog/dody/article/1720795636084" alt="until-820">드디어.. 결제가 성공했다7월 2일에 결제해서 7월 12일 퇴근하고 돌아오니 집앞에 택배가 와있었고, 바로 테스트 중이다.<h1>맥북과 호환</h1>아니 이것에 대해서는 고민조차 하지도 않았었다. 당연히 될줄 알았는데 window, alt, ctrl 키를 마주했을때는 조금 당황했을지도...처음에는 키가 완벽하게 작동하지 않아서 뭔가 잘못됐다 생각했는데,<a target="_blank" rel="noopener noreferrer nofollow" href="https://higround.co/blogs/hypegeek-update/how-to-connect-a-higround-keyboard-to-an-apple-macbook">https://higround.co/blogs/hypegeek-update/how-to-connect-a-higround-keyboard-to-an-apple-macbook</a>하이그라운드의 블로그 글을 참고해서 도움을 받았다.중간 부분에 Key Mapping 부분을 읽어보면 window는 command alt는 option의 역할을 하고 있다고 되어있어서, 두 위치를 바꿔주기만 하면 문제가 없다고 생각했다.system setting &gt; keyboard &gt; keyboard shortcuts 에서 수정이 가능하다.<img src="https://image.until.blog/dody/article/1720796773431" alt="until-821"><img src="https://image.until.blog/dody/article/1720796817271" alt="until-822">modifier keys &gt; select keyboard가 higround인걸 확인하고 option 과 command 키 위치를 바꿔주면 맥 호환은 완벽하게 된다.<h1>그래서 만족하는가?</h1>완전 대만족이다. 내가 구매한건 잔디블록의 키보드인데나는 식물을 좋아해서 식물의 갈색과 녹색을 좋아해서 나에게 이렇게 안성맞춤일수가 없다.<img src="https://image.until.blog/dody/article/1720795444318" alt="until-817">외관도 불투명 녹색? 못참지사실 박스를 오픈하면서도 감동을 받았는데 디테일이 좀 뛰어났음..<img src="https://image.until.blog/dody/article/1720796960599" alt="until-823"><img src="https://image.until.blog/dody/article/1720796970729" alt="until-824">ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ마인크래프트 화면 박스에 그려져 있는거 진짜 졸귀탱... 나도 다이아 검 가지고 싶어잉... &gt;0&lt;<img src="https://image.until.blog/dody/article/1720797000505" alt="until-825">키캡 제거나 하는 거나 usb to c케이블 들어있었다.이런 디테일이 예상치못한 감동을 만든다니까 정말..거기다가 키보드의 조명이 장난 아니다... 하이그라운드의 기술력인거같은데 되게 다양한 스타일의 조명을 제공해주는데, 나는 그냥 불빛만 전체적으로 나오는 키보드만 써봤지.. 이렇게 스타일리쉬한 조명이 나오는건 처음 봤는데 키보드 칠 맛이 난다.정말로 정말로 다양한 조명이 있다.<a target="_blank" rel="noopener noreferrer nofollow" href="https://app.higround.co/">https://app.higround.co/</a>이곳에서는 조명 커스텀이 가능하다던데, find device에 내 기기가 뜨지 않아서 나는 안해봤다. 꼭 저걸 하지 않아도 키보드 단축키로 조명을 스위칭 할수 있기 때문에 앞으로 딱히 필요 없을듯하다.하여튼 오타쿠들 하이드라운드로 다 모여~~~~<h1>단점</h1><h3>1) 65키 괜춘?</h3>딱봐도 키가 65개에다가 콤팩트하기 때문에 손에 익지 않을사람은 안익을거같다. 나는 원래 텐키리스도 잘쓰던 사람이라 거의 바로 적응했다.흠... 오른쪽 쉬프트랑 방향키가 좀 킹받긴 하지만 뭐...할만하다.<h3>2) 백틱 위치 괜춘?</h3>물결이라던가 템플릿 리터럴 코드 쓸 때 좀 당황스럽다.백틱은 보통 esc 아래에 있는데, 이 키보드는 제일오른쪽상단에 위치한다.이게 당황스럽긴한데,왼손으로는 shift를 누르고 오른손으로는 백틱버튼을 누르면 생각보다 안정적이고 편하다... 백틱의 위치는 애초부터 이곳에 있는게 모두의 행복과 가까운게 아닐까 생각이 들 정도...<h1>결론</h1>그 외 단점은 없다.기계식 키보드의 스위치 종류에 빠삭하지는 못해서 자세히 평가를 내리진 못하겠지만,저소음적축만 사용하던 나였는데 그것보다는 경쾌하고 키압이 적은 편이다.히히 너무 만족스러운 소비였고 ~~ (이 물결 치면서도 백틱 위치 헷깔려서 삐끗함)마인크래프트 하러 가야겠다🪴🪴🪴

higround 마인크래프트 키보드를 산 사람이 있다? 

[취미]🌴 higround 마인크래프트 키보드 구매 후기 (맥북 호환)

<img src="https://image.until.blog/until/article/1725700507876.png" data-width="100%" data-align="center" alt="until-1322">안녕하세요. 몰댄민입니다. 언틸 업데이트 사항을 알려드릴게요.<h1>아티클 모달 UI가 개선되었어요</h1>피드에서 아티클을 볼 때 아티클 상세로 바로 이동할 수 있었으면 좋겠다는 요청이 많았어요.사실.. 이전에도 아티클 제목을 누르면 아티클 상세 페이지로 이동이 가능했었는데요. 이 기능이 유저에게 직관적이지 않다고 판단했어요.<img src="https://image.until.blog/until/article/1725701544361.gif" data-width="100%" data-align="center" alt="until-1324">때문에 아티클 모달에 간단한 헤더를 추가해 직관적으로 상세페이지로 이동할 수 있도록 개선했어요.앞으로도 많은 피드백 부탁드립니다!<h1>누가 리액션을 남겼는지 볼 수 있어요</h1>이전에는 리액션을 남겨도 누가 남긴 것인지 알림이 아니면 알 수가 없었는데요.🥲이제 리액션 영역에 마우스를 올려놓으면 누가 리액션을 남겼는지 확인할 수 있도록 툴팁을 추가했어요.<img src="https://image.until.blog/until/article/1725700873621.gif" data-width="100%" data-align="center" alt="until-1323"><h1>아티클에 컬렉션 정보가 추가되었어요</h1>그동안 컬렉션으로 아티클을 분류해도 해당 아티클이 어떤 컬렉션인지 인지하기가 어려웠어요.이를 개선하기 위해 아티클 리스트와 아티클 상세페이지에 컬렉션 정보를 추가했어요.<img src="https://image.until.blog/until/article/1725701773006.gif" data-width="100%" data-align="center" alt="until-1325"><h1>Latex 문법을 지원해요</h1>이제 Latex을 사용할 수 있어요! 사용하는 방법은 Markdown에서 Latex를 사용하는 것과 동일해요.<img src="https://image.until.blog/until/article/1725702175192.gif" data-width="100%" data-align="center" alt="until-1326"><h1>그 외 수정사항</h1><ul><li>팔로워 랭킹이 추가되었어요.</li><li>코드블록 스타일이 개선되었어요.</li><li>그 외 여러 버그를 고쳤어요.</li></ul><h1>기타</h1><ul><li>서비스에 대한 건의사항은 커뮤니티 또는 댓글 등 편한 곳으로 알려주세요. 감사합니다!</li></ul>

피드 UI 개선, 리액션 기능, 컬렉션 추가 등이 추가되었어요.

24.09.07 업데이트 내역

🖥 백엔드

Cotuber에 도입된 AI 자막 생성 기능이 어떤 과정을 거쳐 만들어졌는지 공유합니다.

우리 팀이 자동으로 자막을 생성하기까지

<img src="https://image.until.blog/steady/article/1727346269489.png" alt="until-1565"><h2>어디에 쓰이나?</h2><hr>한 서비스를 개발할 때 여러 플랫폼의 소셜 로그인 기능을 구현하다가 로그인 플랫폼에 상관없이 각 유저별로 서로를 특정할 수 있는 공통의 값이 필요하게 되었고 나는 닉네임을 필수로 입력받아 이 부분을 처리하려고 했다.하지만 회원을 등록할 때 닉네임을 직접 입력받게 되니 회원가입의 과정이 부자연스러웠고, 닉네임을 입력하지 않고 중간에 이탈할 경우의 데이터 처리가 모호해져 우선 무작위 닉네임을 지정하고 추후 변경하는 프로세스를 생각하게 되었다.그때 필요했던 기능이 이 무작위 닉네임 생성 기능이었다.<h2>개발 과정</h2><hr>가장 먼저 떠올랐던 예시는 썸네일에 사용한 블리자드의 무작위 작명이었다. 무작위로 주어진 단어들을 조합하여 특정한 닉네임을 만들어내는 단순한 기능이였다.우선 내가 개발하는 서비스는 반려동물과 관련된 서비스였기 때문에 동물과 관련된 닉네임을 생성하기로 했고 앞쪽에는 형용사를 뒤쪽에는 동물 이름을 사용해 닉네임을 만들어 보았다.<pre spellcheck="false"><code class="language-java">public class NicknameGenerator {

 // 형용사 배열
 private static final String[] adjectives = {
 "귀여운", "발랄한", "사랑스러운", "똑똑한", "활발한", "졸린", "장난꾸러기", "용감한", "상냥한", "행복한",
 "느긋한", "온화한", "믿음직한", "애교 많은", "웃음 가득한", "엉뚱한", "당당한", "재빠른", "고요한", "부드러운"
 };

 // 동물 이름 배열
 private static final String[] animals = {
 "강아지", "고양이", "햄스터", "토끼", "앵무새", "거북이", "고슴도치", "말티즈", "푸들", "치와와",
 "골든리트리버", "페르시안", "스피츠", "요크셔테리어", "러시안블루", "코뉴어", "페럿", "다람쥐", "이구아나", "비글"
 };

 // 랜덤 닉네임 생성 함수
 public String generateNickname() {
 Random random = new Random();

 // 배열의 길이에 맞춰 랜덤으로 배열 값을 조회
 String adjective = adjectives[random.nextInt(adjectives.length)];
 String animal = animals[random.nextInt(animals.length)];
 // 추가적으로 닉네임 중복을 방지하기 위해 1~999까지의 무작위 숫자 조회
 int number = random.nextInt(1000);

 return adjective + animal + number;
 }
}</code></pre>위 처럼 간단한 무작위 닉네임 생성기를 만들어 보았다.하지만 이걸로는 유저의 닉네임 중복을 완벽히 막을 수는 없어서 DB를 통해 해당 닉네임이 존재하는 지 확인 후 재생성하는 과정도 포함시켜야 한다.<h2></h2><h2>돌아보며</h2><hr><blockquote>개발 후 코드를 보면 간단하지만 차근차근 생각해 나가는 과정이 중요한 것 같다.코드 자동화 기술이 워낙 많이 발전해서 이 정도는 간단하게 작성해주겠지만 백지 상태에서 스스로 생각하면서 만들어봐야 더 기억에 오래 남아 추후에 시간을 절약하게 되는 것 같다.모든 코드를 백지에서 부터 천천히 만들 순 없겠지만, 미래를 위해 자동으로 작성된 코드라면 천천히 작동 방식을 생각해보며 머릿속에 남기며 공부해 나가보자</blockquote>

어디에 쓰이나?한 서비스를 개발할 때 여러 플랫폼의 소셜 로그인 기능을 구현하다가 로그인 플랫폼에 상관없이 각 유저별로 서로를 특정할 수 있는 공통의 값이 필요하게 되었고 나는 닉네임을 필수로 입력받아 이 부분을 처리하려고 했다.하지만 회원을 등록할 때 닉네임을 직접 입력받게 되니 회원가입의 과정이 부자연스러웠고, 닉네임을 입력하지 않고 중간에 이탈할 경우