기술의 역사를 살펴보는 팟캐스트입니다

1l. JavaScript Framework: Isomorphic JavaScript Framework - Meteor - RetroTech

1l. JavaScript Framework: Isomorphic JavaScript Framework - Meteor

오랜만에 새로운 팟캐스트 에피소드를 녹음했습니다. 대본은 계속 쓰고 있었는데 이것저것 하다보니 시간이 꽤 걸리게 되었네요. 이번에 살펴본 자바스크립트 프레임워크는 아이소모픽 자바스크립트 프레임워크로 알려진 Meteor입니다.

자료를 찾아보면서 GraphQL 등 다양한 부분의 역사에도 이어진 것을 발견해서 재밌었습니다.

https://retrotech.outsider.dev/episodes/1l

1l. JavaScript Framework: Isomorphic JavaScript Framework - Meteor 오랜만에 새로운 팟캐스트 에피소드를 녹음했습니다. 대본은 계속 쓰고 있었는데 이것저것 하다보니 시간이 꽤 걸리게 되었네요. 이번에 살펴본 자바스크립트 프레임워크는 아이소모픽 자바스크립트 프레임워크로 알려진 Meteor입니다. 자료를 찾아보면서 GraphQL 등 다양한 부분의 역사에도 이어진 것을 발견해서 재밌었습니다. https://retrotech.outsider.dev/episodes/1l

RetroTech 팟캐스트

토스 코어의 프론트엔드 챕터는 80명이 넘는 많은 분들이 함께 일하고 있는데요. 조직 운영을 유기적으로 하고 모든 구성원들이 긴밀하게 협업할 수 있도록 챕터 리드가 많은 역할을 하고 있답니다. 🙋‍♂️이 아티클에서는 프론트엔드 챕터 리드에 대해 궁금해하실만한 질문 10개에 대해서, 실...

토스 프론트엔드 챕터 리드는 어떤 역할인가요?

토스의 챕터 리드는 동일한 도메인을 가진 여러 사일로 개발자들(대여섯 명)이 모여 기술을 교류하는 역할을 담당합니다. 이들은 프론트엔드 개발 조직을 설계하고, 채용 및 1:1 미팅을 통해 구성원의 니즈를 파악하여 최적의 위치에 배치하는데요. 또한, 협력적이고 생산적인 작업 환경을 조성한다고 합니다.

챕터 리드로서의 기여 사례
 * 1:1 미팅: 개발 과정을 회고하고 잘한 점과 아쉬운 점을 논의합니다. 액션 아이템을 설정한 후 체크리스트를 구성원들이 직접 만들도록 제안합니다.
 * 신규 기능 개발: 체크리스트를 함께 돌아보며 점검합니다.

구성원 성장을 위한 노력
 * 코드 리뷰 문화: 꼼꼼한 코드 리뷰 문화를 조성합니다.
 * 심적 안정: 구성원들이 심리적으로 안정감을 느낄 수 있도록 지원합니다.
 * 주기적 1:1 미팅: 성장 방향을 파악하고 적절한 팀 배치를 합니다.

챕터 간 교류
온/오프라인을 통해 자주 소통하고 스터디를 진행합니다. 한 달에 최소 두 번은 미팅과 식사
자리를 마련하여 친밀감을 쌓고 조직 운영 현황을 리뷰합니다.

리드로서의 보람
스스로 문제를 해결할 수 있도록 돕는 것이 가장 중요합니다. 이를 통해 회사에 대한 기여의 폭이 훨씬 넓어집니다.
업무와 리딩 시간 관리 방법
 * 업무 집중 시간: 점심시간 전에는 혼자 하는 일들을 처리합니다. 커뮤니케이션은 주로 오후에 진행합니다.
 * 예측 가능성: 점심 시간 이후에는 마무리한 일들이 많아 조급함이 덜합니다.
 * 업무 시각화: 우선순위를 정렬하고 업무 처리 정도를 예측합니다.

리드의 역할은 단순히 뛰어난 개발 능력을 넘어서는 복합적인 리더십을 요구합니다. 프로젝트의 성공적인 수행, 팀원 개개인의 성장 촉진, 그리고 건강한 팀 문화 조성을 포괄하는데요. 이러한 리더십 요소들은 현재 리드 포지션에 있지 않다고 하더라도 중요한 지향점이 되는것 같습니다.

좀 더 자세한 토스의 프론트엔드 리드의 역할에 대해 더 알고 싶으신 분은 원문 게시글을 확인해 보시길 권장드립니다.

https://toss.im/career/article/28734

토스의 챕터 리드는 동일한 도메인을 가진 여러 사일로 개발자들(대여섯 명)이 모여 기술을 교류하는 역할을 담당합니다. 이들은 프론트엔드 개발 조직을 설계하고, 채용 및 1:1 미팅을 통해 구성원의 니즈를 파악하여 최적의 위치에 배치하는데요. 또한, 협력적이고 생산적인 작업 환경을 조성한다고 합니다. 챕터 리드로서의 기여 사례<ul ><li>1:1 미팅: 개발 과정을 회고하고 잘한 점과 아쉬운 점을 논의합니다. 액션 아이템을 설정한 후 체크리스트를 구성원들이 직접 만들도록 제안합니다.</li><li>신규 기능 개발: 체크리스트를 함께 돌아보며 점검합니다.</li></ul> 구성원 성장을 위한 노력<ul ><li>코드 리뷰 문화: 꼼꼼한 코드 리뷰 문화를 조성합니다.</li><li>심적 안정: 구성원들이 심리적으로 안정감을 느낄 수 있도록 지원합니다.</li><li>주기적 1:1 미팅: 성장 방향을 파악하고 적절한 팀 배치를 합니다.</li></ul> 챕터 간 교류온/오프라인을 통해 자주 소통하고 스터디를 진행합니다. 한 달에 최소 두 번은 미팅과 식사 자리를 마련하여 친밀감을 쌓고 조직 운영 현황을 리뷰합니다. 리드로서의 보람스스로 문제를 해결할 수 있도록 돕는 것이 가장 중요합니다. 이를 통해 회사에 대한 기여의 폭이 훨씬 넓어집니다.업무와 리딩 시간 관리 방법<ul ><li>업무 집중 시간: 점심시간 전에는 혼자 하는 일들을 처리합니다. 커뮤니케이션은 주로 오후에 진행합니다.</li><li>예측 가능성: 점심 시간 이후에는 마무리한 일들이 많아 조급함이 덜합니다.</li><li>업무 시각화: 우선순위를 정렬하고 업무 처리 정도를 예측합니다.</li></ul> 리드의 역할은 단순히 뛰어난 개발 능력을 넘어서는 복합적인 리더십을 요구합니다. 프로젝트의 성공적인 수행, 팀원 개개인의 성장 촉진, 그리고 건강한 팀 문화 조성을 포괄하는데요. 이러한 리더십 요소들은 현재 리드 포지션에 있지 않다고 하더라도 중요한 지향점이 되는것 같습니다. 좀 더 자세한 토스의 프론트엔드 리드의 역할에 대해 더 알고 싶으신 분은 원문 게시글을 확인해 보시길 권장드립니다. https://toss.im/career/article/28734

Toss

토스 챕터 리드의 역할과 책임: 프론트엔드 개발팀 리딩

보통 fetch는 signal, XHR은 abort를 사용해 요청을 취소하는데요, 일반적인 프로미스는 어떻게 취소할 수 있을까요? 이 글에서는 그 방법으로 프로미스의 결과를 폐기 또는 무시하는 방법을 설명하고 있습니다.

[번역] 자바스크립트에서 프로미스를 취소하는 방법

오늘 소개해드릴 글은 라인플러스의 김은빈님이 번역해주신 글입니다.

자바스크립트에서 요청을 취소하는 방법으로는 XHR은
xhr.abort()
를, fetch는
signal
을 사용합니다. 그렇다면 일반적인 프로미스는 어떻게 취소할 수 있을까요?

현재 자바스크립트는 일반적인 프로미스를 취소하는 API를 따로 제공하고 있지 않습니다. 따라서 이 글에서는 프로미스의 결과를 폐기 또는 무시하는 방법을 설명하고 있습니다. 바로 적용 가능할만한 간단한 리액트 훅도 있으니 한 번 참고해보시는건 어떠신가요? :)

> 글 링크: https://velog.io/@eunbinn/cancel-promises-javascript

오늘 소개해드릴 글은 라인플러스의 김은빈님이 번역해주신 글입니다. 자바스크립트에서 요청을 취소하는 방법으로는 XHR은 <code >xhr.abort()</code>를, fetch는 <code >signal</code>을 사용합니다. 그렇다면 일반적인 프로미스는 어떻게 취소할 수 있을까요? 현재 자바스크립트는 일반적인 프로미스를 취소하는 API를 따로 제공하고 있지 않습니다. 따라서 이 글에서는 프로미스의 결과를 폐기 또는 무시하는 방법을 설명하고 있습니다. 바로 적용 가능할만한 간단한 리액트 훅도 있으니 한 번 참고해보시는건 어떠신가요? :) &gt; 글 링크: https://velog.io/@eunbinn/cancel-promises-javascript

Velog

자바스크립트에서 프로미스를 취소하는 방법

친할수록 더 조심하고 배려해야 한다는 걸. 나도 누군가와 이렇게 오랫동안 잘 지낼 수 있는 사람이었다니 기쁘고 좋습니다.

아내와 존댓말을 하는 이유

어릴 적부터 종종 친구들과의 관계를 망치곤 했습니다.
제가 문제였습니다.

나의 이 가벼운 입. 상처 주는 행동.
조금만 친해졌다 하면 어김없이 이런 행동이 튀어나왔습니다.
상대방이 다 이해해 줄 거라 생각하고.
어리석게도 늦은 나이까지 이런 실수를 계속했습니다.

그래서 더 결혼이 무서웠는지도 모르겠습니다.
내가 또 망쳐버릴까 봐.

아내와는 존댓말을 합니다.
나이가 서로 동갑임에도.

절대 함부로 하지 않겠다는 장치 같은 것이기도 하고...
우리의 의지와 다짐이기도 합니다.

아내와 만난 지 곧 10년이 됩니다.
그동안 아내에게 화를 내며 목소리를 높인 적이 한 번도 없습니다.
당연히 아내도 마찬가지입니다.

서로 존댓말을 하는 것이 영향을 줬을까?
분명히 그랬을 것 같습니다.

친할수록 더 조심하고 배려해야 한다는 걸 30살이 훌쩍 넘어서야 배웠습니다.
이제라도 배워서 다행입니다.
나도 누군가와 이렇게 오랫동안 잘 지낼 수 있는 사람이었구나.
내가 되고 싶던 내 모습에 가까워져 가고 있다고 생각합니다. 기쁘고 좋습니다.

---
커피한잔의 공지사항으로 주절주절 적어본 글입니다.
공지사항을 이렇게 적는 소개팅 어플이 커피한잔 말고 또 있을까?
있을리가!(ㅋㅋ)

세이노의 가르침에서 인상 깊게 배운 가르침 중 하나는 고객과 개인적인 이야기를 많이 나누라는 것.
가르침을 열심히 따라보고 있습니다. 좋은 것 같습니다.

https://withcoffee.app/notices/76

어릴 적부터 종종 친구들과의 관계를 망치곤 했습니다. 제가 문제였습니다. 나의 이 가벼운 입. 상처 주는 행동. 조금만 친해졌다 하면 어김없이 이런 행동이 튀어나왔습니다. 상대방이 다 이해해 줄 거라 생각하고. 어리석게도 늦은 나이까지 이런 실수를 계속했습니다. 그래서 더 결혼이 무서웠는지도 모르겠습니다. 내가 또 망쳐버릴까 봐. 아내와는 존댓말을 합니다. 나이가 서로 동갑임에도. 절대 함부로 하지 않겠다는 장치 같은 것이기도 하고... 우리의 의지와 다짐이기도 합니다. 아내와 만난 지 곧 10년이 됩니다. 그동안 아내에게 화를 내며 목소리를 높인 적이 한 번도 없습니다. 당연히 아내도 마찬가지입니다. 서로 존댓말을 하는 것이 영향을 줬을까? 분명히 그랬을 것 같습니다. 친할수록 더 조심하고 배려해야 한다는 걸 30살이 훌쩍 넘어서야 배웠습니다. 이제라도 배워서 다행입니다. 나도 누군가와 이렇게 오랫동안 잘 지낼 수 있는 사람이었구나. 내가 되고 싶던 내 모습에 가까워져 가고 있다고 생각합니다. 기쁘고 좋습니다. --- 커피한잔의 공지사항으로 주절주절 적어본 글입니다. 공지사항을 이렇게 적는 소개팅 어플이 커피한잔 말고 또 있을까? 있을리가!(ㅋㅋ) 세이노의 가르침에서 인상 깊게 배운 가르침 중 하나는 고객과 개인적인 이야기를 많이 나누라는 것. 가르침을 열심히 따라보고 있습니다. 좋은 것 같습니다. https://withcoffee.app/notices/76

커피한잔 - 직장인 소개팅

콜로소 회원이라면 누구나 무료! [무료특강] 백엔드 개발이 편리해지는 코틀린과 스프링 부트

[무료특강] 백엔드 개발이 편리해지는 코틀린과 스프링 부트

얼마전에 콜로소에 코틀린과 스프링부트를 활용한 현대적 백엔드 개발(https://coloso.co.kr/products/programming-parkseungkyoo) 이라는 강의를 오픈하였습니다.

관련해서 무료특강을 진행했었는데요.
30분 정도 되는 짧은 강의이지만 다음의 내용들을 알려드립니다.

 * 백엔드 개발 프로세스
   * 폭포수와 애자일은 어떻게 다른지
 * 코틀린과 스프링부트
   * 코틀린의 특징 및 코틀린의 장점
   * 스프링과 스프링 부트의 비교
 * 아키텍처
   * 아키텍처란 무엇인지
   * 설계 원칙은 어떻게 되는지

콜로소에서 무료로 보실 수 있으니 백엔드 개발에 관심있으신 분들은 한번 확인해보시면 좋을 것 같습니다.
https://bit.ly/4bGHogl

얼마전에 콜로소에 코틀린과 스프링부트를 활용한 현대적 백엔드 개발(https://coloso.co.kr/products/programming-parkseungkyoo) 이라는 강의를 오픈하였습니다. 관련해서 무료특강을 진행했었는데요. 30분 정도 되는 짧은 강의이지만 다음의 내용들을 알려드립니다. <ul ><li>백엔드 개발 프로세스<ul ><li>폭포수와 애자일은 어떻게 다른지</li></ul></li><li>코틀린과 스프링부트<ul ><li>코틀린의 특징 및 코틀린의 장점</li><li>스프링과 스프링 부트의 비교</li></ul></li><li>아키텍처<ul ><li>아키텍처란 무엇인지</li><li>설계 원칙은 어떻게 되는지 </li></ul></li></ul> 콜로소에서 무료로 보실 수 있으니 백엔드 개발에 관심있으신 분들은 한번 확인해보시면 좋을 것 같습니다. https://bit.ly/4bGHogl

Coloso

백엔드 개발이 편해지는 코틀린과 스프링 부트

If-else statements, though ubiquitous, can lead to complex and hard-to-maintain code if overused. In this article, we'll explore various strategies to reduce the use of if-else constructs in Java...

Refactoring Java Spring Boot Code: Eliminating If-Else Statements for Cleaner, Extensible Logic

If-else 문은 흔하지만 남용되면 복잡하고 유지보수가 어려운 코드로 이어질 수 있습니다. 이 글에서는 Java Spring Boot 프로젝트에서 if-else 문을 줄이기 위한 다양한 전략을 탐구하여 코드를 더 모듈화하고, 유지보수하기 쉽고, 읽기 쉽게 만드는 방법에 대해 설명하겠습니다.
 
If-Else 문을 줄이는 전략
 * 전략 패턴(Strategy Pattern)
 * Enum 사용
 * 다형성(Polymorphism)
 * 람다 표현식과 함수형 인터페이스
 * 명령 패턴(Command Pattern)
 * 가드 절(Guard Clauses)

1. 전략 패턴
전략 패턴은 알고리즘의 가족을 정의하고, 각각을 캡슐화하며, 이들을 상호 교환 가능하게 만듭니다. 여러 가지 방법으로 특정 작업을 수행해야 할 때 유용합니다.
 
예제: 결제 처리 시스템
먼저 PaymentStrategy 인터페이스를 정의합니다:
public interface PaymentStrategy {
 void pay(double amount);
}

그런 다음, 다른 결제 전략을 구현합니다:
@Component
public class CreditCardPayment implements PaymentStrategy {
 @Override
 public void pay(double amount) {
 // 신용 카드 결제 처리 로직
 System.out.println("Paid " + amount + " using Credit Card.");
 }
}

@Component
public class PaypalPayment implements PaymentStrategy {
 @Override
 public void pay(double amount) {
 // PayPal 결제 처리 로직
 System.out.println("Paid " + amount + " using PayPal.");
 }
}

 
2. Enum 사용
Enums는 미리 정의된 상수 집합과 그와 관련된 동작을 나타내는 데 사용할 수 있습니다.
 
예제: 주문 상태 관리
다양한 동작을 가진 OrderStatus enum을 정의합니다:
public enum OrderStatus {
 NEW {
 @Override
 public void handle() {
 System.out.println("Processing new order.");
 }
 },
 SHIPPED {
 @Override
 public void handle() {
 System.out.println("Order shipped.");
 }
 },
 DELIVERED {
 @Override
 public void handle() {
 System.out.println("Order delivered.");
 }
 };

 public abstract void handle();
}

 
3. 다형성 (Polymorphism)
다형성은 객체를 실제 클래스가 아닌 부모 클래스의 인스턴스로 취급할 수 있게 해줍니다. 이를 통해 부모 클래스의 참조를 통해 파생 클래스의 재정의된 메서드를 호출할 수 있습니다.
 
예제: 알림 시스템
Notification 인터페이스와 그 구현을 정의합니다:
public interface Notification {
 void send(String message);
}

public class EmailNotification implements Notification {
 @Override
 public void send(String message) {
 // 이메일 전송 로직
 System.out.println("Sending email: " + message);
 }
}

public class SmsNotification implements Notification {
 @Override
 public void send(String message) {
 // SMS 전송 로직
 System.out.println("Sending SMS: " + message);
 }
}

 
4. 람다 표현식과 함수형 인터페이스
람다 표현식은 특히 단일 메서드 인터페이스를 다룰 때 코드를 간소화할 수 있습니다.
 
예제: 할인 서비스
람다 표현식을 사용하는 할인 서비스를 정의합니다:
import java.util.HashMap;
import java.util.Map;
import java.util.function.Function;

public class DiscountService {
 private Map<String, Function<Double, Double>> discountStrategies = new HashMap<>();

 public DiscountService() {
 discountStrategies.put("SUMMER_SALE", price -> price * 0.9);
 discountStrategies.put("WINTER_SALE", price -> price * 0.8);
 }

 public double applyDiscount(String discountCode, double price) {
 return discountStrategies.getOrDefault(discountCode, Function.identity()).apply(price);
 }
}

 
5. 명령 패턴 (Command Pattern)
명령 패턴은 요청을 객체로 캡슐화하여 클라이언트를 큐, 요청, 작업으로 매개변수화할 수 있게 합니다.
 
예제: 파일 작업
Command 인터페이스와 구체적인 명령을 정의합니다:
public interface Command {
 void execute();
}

public class OpenFileCommand implements Command {
 private FileSystemReceiver fileSystem;

 public OpenFileCommand(FileSystemReceiver fs) {
 this.fileSystem = fs;
 }

 @Override
 public void execute() {
 this.fileSystem.openFile();
 }
}

public class CloseFileCommand implements Command {
 private FileSystemReceiver fileSystem;

 public CloseFileCommand(FileSystemReceiver fs) {
 this.fileSystem = fs;
 }

 @Override
 public void execute() {
 this.fileSystem.closeFile();
 }
}

 
6. 가드 절 (Guard Clauses)
가드 절은 조건을 미리 처리하여 중첩 구조를 줄이고 코드를 더 읽기 쉽게 만듭니다.

예제: 사용자 검증
사용자 입력을 검증하기 위해 if-else 문을 중첩하는 대신, 가드 절을 사용하여 잘못된 경우를 미리 처리합니다:
public class UserService {
 public void registerUser(User user) {
 if (user == null) {
 throw new IllegalArgumentException("User cannot be null");
 }
 if (user.getName() == null || user.getName().isEmpty()) {
 throw new IllegalArgumentException("User name cannot be empty");
 }
 if (user.getEmail() == null || user.getEmail().isEmpty()) {
 throw new IllegalArgumentException("User email cannot be empty");
 }
 // 등록 진행
 System.out.println("Registering user: " + user.getName());
 }
}

 
결론
이러한 전략을 적용함으로써 Java Spring Boot 프로젝트에서 if-else 문의 사용을 크게 줄일 수 있습니다. 이는 코드의 가독성을 높이고 유지보수성과 확장성을 향상시킵니다. 이러한 패턴과 관행을 채택하여 더 깨끗하고 효율적인 코드를 작성하세요.

번역: [https://ducktopia.tistory.com/129]
원문:

If-else 문은 흔하지만 남용되면 복잡하고 유지보수가 어려운 코드로 이어질 수 있습니다. 이 글에서는 Java Spring Boot 프로젝트에서 if-else 문을 줄이기 위한 다양한 전략을 탐구하여 코드를 더 모듈화하고, 유지보수하기 쉽고, 읽기 쉽게 만드는 방법에 대해 설명하겠습니다.&nbsp;If-Else 문을 줄이는 전략<ul ><li>전략 패턴(Strategy Pattern)</li><li>Enum 사용</li><li>다형성(Polymorphism)</li><li>람다 표현식과 함수형 인터페이스</li><li>명령 패턴(Command Pattern)</li><li>가드 절(Guard Clauses)</li></ul> 1. 전략 패턴전략 패턴은 알고리즘의 가족을 정의하고, 각각을 캡슐화하며, 이들을 상호 교환 가능하게 만듭니다. 여러 가지 방법으로 특정 작업을 수행해야 할 때 유용합니다.&nbsp;예제: 결제 처리 시스템먼저 PaymentStrategy 인터페이스를 정의합니다:<pre ><code class="language-java">public interface PaymentStrategy {
 void pay(double amount);
}</code></pre>그런 다음, 다른 결제 전략을 구현합니다:<pre ><code class="language-java">@Component
public class CreditCardPayment implements PaymentStrategy {
 @Override
 public void pay(double amount) {
 // 신용 카드 결제 처리 로직
 System.out.println("Paid " + amount + " using Credit Card.");
 }
}

@Component
public class PaypalPayment implements PaymentStrategy {
 @Override
 public void pay(double amount) {
 // PayPal 결제 처리 로직
 System.out.println("Paid " + amount + " using PayPal.");
 }
}</code></pre>&nbsp;2. Enum 사용Enums는 미리 정의된 상수 집합과 그와 관련된 동작을 나타내는 데 사용할 수 있습니다.&nbsp;예제: 주문 상태 관리다양한 동작을 가진 OrderStatus enum을 정의합니다:<pre ><code class="language-java">public enum OrderStatus {
 NEW {
 @Override
 public void handle() {
 System.out.println("Processing new order.");
 }
 },
 SHIPPED {
 @Override
 public void handle() {
 System.out.println("Order shipped.");
 }
 },
 DELIVERED {
 @Override
 public void handle() {
 System.out.println("Order delivered.");
 }
 };

 public abstract void handle();
}</code></pre>&nbsp;3. 다형성 (Polymorphism)다형성은 객체를 실제 클래스가 아닌 부모 클래스의 인스턴스로 취급할 수 있게 해줍니다. 이를 통해 부모 클래스의 참조를 통해 파생 클래스의 재정의된 메서드를 호출할 수 있습니다.&nbsp;예제: 알림 시스템Notification 인터페이스와 그 구현을 정의합니다:<pre ><code class="language-java">public interface Notification {
 void send(String message);
}

public class EmailNotification implements Notification {
 @Override
 public void send(String message) {
 // 이메일 전송 로직
 System.out.println("Sending email: " + message);
 }
}

public class SmsNotification implements Notification {
 @Override
 public void send(String message) {
 // SMS 전송 로직
 System.out.println("Sending SMS: " + message);
 }
}</code></pre>&nbsp;4. 람다 표현식과 함수형 인터페이스람다 표현식은 특히 단일 메서드 인터페이스를 다룰 때 코드를 간소화할 수 있습니다.&nbsp;예제: 할인 서비스람다 표현식을 사용하는 할인 서비스를 정의합니다:<pre ><code class="language-java">import java.util.HashMap;
import java.util.Map;
import java.util.function.Function;

public class DiscountService {
 private Map&lt;String, Function&lt;Double, Double&gt;&gt; discountStrategies = new HashMap&lt;&gt;();

 public DiscountService() {
 discountStrategies.put("SUMMER_SALE", price -&gt; price * 0.9);
 discountStrategies.put("WINTER_SALE", price -&gt; price * 0.8);
 }

 public double applyDiscount(String discountCode, double price) {
 return discountStrategies.getOrDefault(discountCode, Function.identity()).apply(price);
 }
}</code></pre>&nbsp;5. 명령 패턴 (Command Pattern)명령 패턴은 요청을 객체로 캡슐화하여 클라이언트를 큐, 요청, 작업으로 매개변수화할 수 있게 합니다.&nbsp;예제: 파일 작업Command 인터페이스와 구체적인 명령을 정의합니다:<pre ><code class="language-java">public interface Command {
 void execute();
}

public class OpenFileCommand implements Command {
 private FileSystemReceiver fileSystem;

 public OpenFileCommand(FileSystemReceiver fs) {
 this.fileSystem = fs;
 }

 @Override
 public void execute() {
 this.fileSystem.openFile();
 }
}

public class CloseFileCommand implements Command {
 private FileSystemReceiver fileSystem;

 public CloseFileCommand(FileSystemReceiver fs) {
 this.fileSystem = fs;
 }

 @Override
 public void execute() {
 this.fileSystem.closeFile();
 }
}</code></pre>&nbsp;6. 가드 절 (Guard Clauses)가드 절은 조건을 미리 처리하여 중첩 구조를 줄이고 코드를 더 읽기 쉽게 만듭니다. 예제: 사용자 검증사용자 입력을 검증하기 위해 if-else 문을 중첩하는 대신, 가드 절을 사용하여 잘못된 경우를 미리 처리합니다:<pre ><code class="language-java">public class UserService {
 public void registerUser(User user) {
 if (user == null) {
 throw new IllegalArgumentException("User cannot be null");
 }
 if (user.getName() == null || user.getName().isEmpty()) {
 throw new IllegalArgumentException("User name cannot be empty");
 }
 if (user.getEmail() == null || user.getEmail().isEmpty()) {
 throw new IllegalArgumentException("User email cannot be empty");
 }
 // 등록 진행
 System.out.println("Registering user: " + user.getName());
 }
}</code></pre>&nbsp;결론이러한 전략을 적용함으로써 Java Spring Boot 프로젝트에서 if-else 문의 사용을 크게 줄일 수 있습니다. 이는 코드의 가독성을 높이고 유지보수성과 확장성을 향상시킵니다. 이러한 패턴과 관행을 채택하여 더 깨끗하고 효율적인 코드를 작성하세요. 번역: [https://ducktopia.tistory.com/129]원문:

Medium

🕊️ Java Spring Boot에서 If-Else문 줄이기

이런 거 신입이 보고 if-else 써야할때 안쓸까봐 두려워요...

모바일 서비스를 위한 다양한 지표

📊 모바일 앱을 분석하기 위한 13가지 지표

🎈 한 줄 요약
- 수용미학의 관점에서 가장 기본적인 데이터가 '데이터 분석의 고전'이 아닐까?

✔️ 데이터를 확인하다 보면 항상 의문점이 들어요. '왜 갑자기 이렇게 유입이 늘었지?', '아니, 왜 갑자기 유입이 줄었지?'🤣 다양한 이유와 원인을 살펴봐도 모르겠더라고요.

✔️ 하지만 몇 날 며칠을 고민하다 보면 결국, 문제는 풀리게 돼 있어요. 어떻게요? 다양한 데이터를 종합해서 분석하다 보면은 말이죠. 그래서 저는 정량적인 데이터를 분석하는 것도 중요하지만 정성적으로 접근하는 것도 필요하다고 항상 생각하는 편이에요. 

✔️ 이걸 독자(사용자)의 관점으로 취하면, 수용미학이라 할 수 있어요. 인문학적으로 '대중의 관점'을 이해하려고 할 때 많이 사용하는 방법론인데, 잘 나가는 우리 지도교수님도 이건 어렵다고 많이 말을 하세요. 

✔️ 어렵다는 말과 함께 나오는 단어가 있는데요. 그건 바로 고전(classic)이에요. 그들은 과거나 현재나 여전히 중요한 요소를 담고 있으며, 그때도 지금도 똑같이 해석되고 있기 때문이죠. 그런 점에서 우리는 데이터를 해석할 때, 기준을 둘 고전이 필요해요. 

✔️ 그러면 현재 IT서비스에도 이러한 내용을 적용할 수 있을까?라는 고민이 생기는데요. 저는 좀 어렵지 않을까 해요. 도메인도 다르고, 환경도 다르고, 독자도 다르고, 사회적으로도 다르듯 너무나도 많은 것들이 다르기 때문이죠. 

✔️ 그래도 그걸 커버할 수 있는 것들이 있지 않을까요? 어쩌면 다시 원점으로 돌아가는 이야기일 수 있는데, 그게 기본적인 데이터 지표가 아닐까 해요. 그래서 이번에는 모바일 서비스에서 중요하게 봐야할 지표 13가지를 준비했어요.

✔️ 원문 아티클은 믹스패널의 <Mobile App Analytics: Top 13 metrics you should track>이고요. 이걸 해석한 내용을 링크에 담아뒀어요. 필요하신 분들튼 원문을 꼭! 참고해 주세요. 

1️⃣ DAU & MAU

✔️ 흔히들 쉽게 볼 수 있는 지표예요. 가장 기본적인 지표이기도 하죠. DAU는 하루 방문자 수를, MAU는 한 달 방문자 수를 의미해요. 

✔️ MAU가 나오니 갑자기 떠오른 내용이 있어요. 우리나라에서 가장 많이 사용하는 SNS 어플 순위에 관한 이야기예요. 우리는 모두가 인스타그램이 1위를 차지하지 않을까 예상했어요. 하지만 결과는 네이버 밴드였죠. 

✔️ 왜 네이버 밴드가 MAU 1위를 차지 했을까요? 저는 이렇게 생각해요. 밴드는 보통 모임의 성격을 띠기 때문에 1달에 1번은 쉽게 방문할 수 있어요. 다만, 매일같이 방문하지 않을 뿐이죠.

✔️ 이게 무슨 말일까요? MAU가 가지는 함정이라는 거예요. 1달에 1번 방문하면 MAU에 1로 카운트 돼요. 하지만 2번 방문해도 1로 카운트 되죠. 결과적으로 MAU가 높다고 DAU도 덩달아 높지 않을 가능성이 높다는 거예요. 특히나 모임의 성격을 지닌 네이버 밴드라면 더욱이 말이죠.

2️⃣ Stickiness

✔️ 고착도라고도 말하는 Stickiness는 DAU와 MAU를 이용하여 계산되는 일종의 고객 충성도를 나타내요. 계산하는 방법은 (DAU / MAU) × 100이죠.

✔️ 이 수치가 높을수록 많은 분들이 자주 들어온다는 것이고, 활성화가 잘 되고 있다는 의미죠. 네이버 밴드는 아마도 이 고착도가 낮을 거예요. DAU는 생각보다 낮을 가능성이 크기 때문이죠. 반면 인스타그램읕 100에 가까운 지표를 보이지 않을까 해요. 

✔️ 이러한 차이는 왜 발생할까요? 당연히 사용 목적이 다르기 때문이겠죠? 인스타그램은 보통의 일상을 담아내기 때문에 매일 접속할 가능성이 커요. 반면 밴드는? 모임이 필요할 때만 접속하겠죠. 

3️⃣ Retention Rate

✔️ 리텐션 비율은 쉽게 말해 '고객이 얼마나 이탈하지 않고 남아있느냐'예요. 고객 이탈률(Churn rate)과 반대되는 개념이죠. 

✔️ 이 비율이 중요한 이유는 새로운 고객을 모객하는데 우리는 상당히 많은 비용을 투자하기 때문이에요. 보통 새로운 고객을 모집할 때, 우리는 가장 큰 비용을 사용해요. 물론, 그 외 다른 마케팅 비용도 높기는 하지만 한 고객의 마음을 얻는게 가장 어려운 것이 사실이니까요.

✔️ 우리는 이 비율을 잘 유지했을 때, 마케팅이 효율적으로 돌아가고 있구나라고 생각하면 아주 편해요. 반면 이탈률(churn rate)가 지속적으로 증가한다면 다시 한번 서비스를 돌아볼 필요가 있어요. 

4️⃣ CPA 

✔️ CPA는 사용자 1명을 데려오는 비용이에요. 뭐 쉽게 말하자면 '우리 홈페이지에 1명을 가입시키는데 드는 비용' 또는 '우리 서비스를 처음으로 이용하게 만드는 비용'이라 할 수 있어요.

✔️ CPA는 낮으면 좋은게 맞아요. 효율적으로 돈을 사용해서 고객을 모집했기 때문이죠. 하지만 CPA가 LTV를 넘어서면 우리는 손해보는 장사를 하고 있다고 봐요.

✔️ 여기서 LTV는 고객 생애 가치라고 불려요. 7번에 이에 대한 내용도 나오니 확인해주세요.😘

5️⃣ Average daily sessions per DAU

✔️ 사용자가 하루에 얼마나 자주 서비스를 이용하는지 계산한 지표예요. 우리의 일상을 기록하는 인스타그램 등에서는 중요한 지표라 측정할 수 있어요.

✔️ 하지만 다른 서비스들에서는 다른 지표와 종합적으로 봐야하는데 그 이유는 사용자가 원하는 결과를 한번에 얻지 못했다는 것으로도 연결될 수 있기 때문이에요.

6️⃣ LifeTime Value

✔️ 고객 생애 가치로 사용자 1명이 서비스를 이용하는 동안 얼마만큼의 가치를 주는지 측정하는 지표예요. 앞서 말했듯 이 지표가 CPA보다 낮게 나온다면, 우리는 지금 손해를 보고 있는 거예요.

7️⃣ ARPU, ARPPU

✔️ 사용자 1명 당 수익을 의미해요. 약자를 풀어쓰면 Average reveune per user로 쓰죠. 전체 수익이 높은 와중에 이 지표가 낮게 나온다? 전체적인 수익성을 고민할 필요가 있어요. 효율적인지에 대해서는 물음표를 떠올릴 수밖에 없거든요.

✔️ ARPPU는 무료/유료 회원이 동시에 사용하는 서비스에서 사용하는 지표예요. 이를 통해 유료 회원의 가치를 더 정확하게 파악할 수 있죠.

8️⃣ ROI (& ROAS)

✔️ 마케팅 캠페인의 직접적인 성과를 측정하는 지표예요. 모든 투자 비용을 계산하기 어렵기 때문에, 광고 비용과 광고 운영에 드는 인건비를 포함하여 계산해요.

✔️ 모든 데이터가 그렇듯, 일관성을 유지해야 해요. 특히, ROI를 계산할 때는 더욱 그런데, ROI의 정확한 측정을 위해 또한, 개선을 위해 장기적으로 일관된 방식으로 측정해야 해요.

✔️ ROAS는 광고로 발생한 매출을 광고 비용으로 나눈 값이에요. 단기적인 캠페인에 많이 사용하는 편이죠. 여기서 ROI와의 차이가 발생해요. ROI는 전체적인 수익을 기준으로 계산하기 때문이죠.

9️⃣ APP load time

✔️ 말 그대로 앱 로딩 시간을 의미해요. 과거 인터넷이 느렸을 때는 누구든 오래 기다렸을 거예요. 하지만 초고속 인터넷을 모바일에서 사용할 수 있는 환경이기 때문에 단축될수록 좋아요.

✔️ 반면 유저가 기다릴 수 있는 한계점을 넘어서면, 유저는 바로 이탈하겠죠. 그래서 앱을 로딩하는 시간도 상당히 중요한 지표로 평가돼요.

🔟 Customer Satisfaction

✔️ 흔히 말하는 CS로 고객 만족도를 의미해요. 고객 만족도는 정량화된 지표로 만들기 가장 까다로운 영역이에요. 조사를 시행하면 정성적인 자료로 넘겨받기 때문이죠.

✔️ 그래서 이를 보완하는 것이 설문조사 형태이고, 그 안에서도 점수로 변환하여 산출하죠. 하지만 고객의 성향에 따라 극단적인 경우가 많기 때문에 또한, 정확한가?에 대해서 고민할 필요가 있어요.

✔️ 그래도 측정할 수 있는 방법은 크게 2가지예요. 하나는 CSAT 0~5점 사이의 지표를 활용하는 설문조사이고, 다른 하나는 NPS로 0~10점 사이의 지표를 활용하는 설문조사예요.

1️⃣1️⃣ Goal achievement

✔️ 회원가입, 공유, 구매 등 고객여정에서 중요한 목표에 도달한 사용자의 비율을 의미해요.

1️⃣2️⃣ Marketing Acquisition

✔️ 고객이 어떤 마케팅 채널을 통해 유입되었는지, 주요 수익을 발생하는 유저는 어떤 마케팅 채널에서 유입되었는지 파악하는 데이터예요. 이를 정확히 분석했을 때, 우리는 ROI를 높일 수 있어요.

1️⃣3️⃣ Behavior flow rate

✔️ 평균적인 고객 여정을 따르는 유저의 비율을 나타내요. 이러한 흐름을 측정하는 것은 상당히 어려워요. 하지만 잘 측정한다면 서비스가 얼마나 직관적인지 평가할 수 있을 거예요. 우리가 의도한 대로 고객이 따르고 있다는 것을 의미하니까요.

✔️ 하지만 그렇지 않다면? 원인이 매우 다양하기 때문에 유저 인터뷰나 유저 테스트를 통해 확인해야 해요. 각 퍼널별로 어떻게 고객이 유입되고 나가는지 측정해야 하기 때문이죠.

이민호

리텐션 계산하기 (4) Stickiness

오랜만에 분석가 같은 글을 하나 써보았네요. 리텐션 지표 고민하시는 분들 많으시죠? Stickiness(사용자 고착도)를 어떻게 계산하는지, 좀 지난 데이터지만 2015년 페이스북 YoY MAU 성장 지표와 Stickiness 데이터를 같이 살펴보면서 이런저런 의견을 덧붙여봤습니다.

재밌게 읽으셨다면 이 글 이외에 리텐션 시리즈 글이 세 개 더 있으니 살펴봐주세요 :D 탐라 분들 새해 복 많이 받으시고요.

인프런이 만드는 IT인의 축제, 인프콘에 초대합니다

인프콘 2024 - INFCON 2024

1. INFCON
- https://www.inflearn.com/conf/infcon-2024/
- ‘인프런’에서 주최하는 IT 컨퍼런스. 개발자, PM/PO, 디자이너 분야 등
- 2024년 8월 2일(금)
- 유료 / 참가 신청 마감. 추후 인프콘 다시보기 서비스 제공 예정

2. UbuCon Korea 2024
- https://2024.ubuntu-kr.org/ko/
- Ubuntu 코리아 컨퍼런스
- 2024년 8월 10일(토)
- 유료

3. FEConf24
- https://2024.feconf.kr/
- 국내 최대 프론트엔드 컨퍼런스
- 2024년 8월 24일(토)
- 유료

4. Kubernetes Korea Community Day 2024
- https://kcd-korea.net/
- 쿠버네티스에서 주최하는 국내 클라우드 네이티브 기술 컨퍼런스
- 2024년 9월 24일(화)
- 유료

5. OpenInfra Summit Asia 2024
- https://2024.openinfraasia.org/
- 클라우드 네이티브 오픈소스 기술 재단 ‘오픈인프라’ 컨퍼런스
- 2024년 9월 3일(화) ~ 9월 4일(수)
- 유료

6. KWDC 2024
- https://kwdc.dev/2024/
- 국내 애플 개발자 커뮤니티 3곳이 주최하는 한국 Apple 생태계 컨퍼런스
- 2024년 10월 24일(목)
- 유료

7. PyCon KR 2024
- https://2024.pycon.kr/
- 세계 각국의 파이썬 프로그래밍 언어 커뮤니티에서 주관하는 컨퍼런스
- 2024년 10월 25일(금) ~ 10월 27일(일)
- 유료

8. DebConf24
- https://debconf24.debconf.org/
- 데비안 운영체제, 소프트웨어 개발과 관련한 세미나
- 2024년 7월 28일(일) ~ 8월 4일(일)
- 유·무료(일반 무료, 전문가/기업 유료)

9. GopherCon Korea 2024
- https://festa.io/events/5098
- 한국의 Go 언어 사용자 모임 커뮤니티에서 주최하는 컨퍼런스
- 2024년 10월 12일(토) ~ 10월 13일(일)
- 유료

해외 컨퍼런스
1. GitHub Universe 2024
- https://githubuniverse.com/
- 2024년 10월 29일(화) ~ 10월 30일(수) / 미국 샌프란시스코
- 유료 / 온라인 라이브 스트리밍 무료

2. KubeCon + CloudNativeCon North America
- https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/
- 2024년 11월 12일(화) ~ 11월 15일(금) / 미국 유타주 솔트레이크시티
- 유료 / 키노트 라이브 스트리밍 무료

3. AWS re:Invent 2024
- https://reinvent.awsevents.com/
- 2024년 12월 2일(월) ~ 12월 6일(금) / 미국 라스베가스
- 유료 / 온라인 라이브 스트리밍 무료

1. INFCON- https://www.inflearn.com/conf/infcon-2024/- ‘인프런’에서 주최하는 IT 컨퍼런스. 개발자, PM/PO, 디자이너 분야 등- 2024년 8월 2일(금)- 유료 / 참가 신청 마감. 추후 인프콘 다시보기 서비스 제공 예정 2. UbuCon Korea 2024- https://2024.ubuntu-kr.org/ko/- Ubuntu 코리아 컨퍼런스- 2024년 8월 10일(토)- 유료 3. FEConf24- https://2024.feconf.kr/- 국내 최대 프론트엔드 컨퍼런스- 2024년 8월 24일(토)- 유료 4. Kubernetes Korea Community Day 2024- https://kcd-korea.net/- 쿠버네티스에서 주최하는 국내 클라우드 네이티브 기술 컨퍼런스- 2024년 9월 24일(화)- 유료 5. OpenInfra Summit Asia 2024- https://2024.openinfraasia.org/- 클라우드 네이티브 오픈소스 기술 재단 ‘오픈인프라’ 컨퍼런스- 2024년 9월 3일(화) ~ 9월 4일(수)- 유료 6. KWDC 2024- https://kwdc.dev/2024/- 국내 애플 개발자 커뮤니티 3곳이 주최하는 한국 Apple 생태계 컨퍼런스- 2024년 10월 24일(목)- 유료 7. PyCon KR 2024- https://2024.pycon.kr/- 세계 각국의 파이썬 프로그래밍 언어 커뮤니티에서 주관하는 컨퍼런스- 2024년 10월 25일(금) ~ 10월 27일(일)- 유료 8. DebConf24- https://debconf24.debconf.org/- 데비안 운영체제, 소프트웨어 개발과 관련한 세미나- 2024년 7월 28일(일) ~ 8월 4일(일)- 유·무료(일반 무료, 전문가/기업 유료) 9. GopherCon Korea 2024- https://festa.io/events/5098- 한국의 Go 언어 사용자 모임 커뮤니티에서 주최하는 컨퍼런스- 2024년 10월 12일(토) ~ 10월 13일(일)- 유료 해외 컨퍼런스1. GitHub Universe 2024- https://githubuniverse.com/- 2024년 10월 29일(화) ~ 10월 30일(수) / 미국 샌프란시스코- 유료 / 온라인 라이브 스트리밍 무료 2. KubeCon + CloudNativeCon North America- https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/- 2024년 11월 12일(화) ~ 11월 15일(금) / 미국 유타주 솔트레이크시티- 유료 / 키노트 라이브 스트리밍 무료 3. AWS re:Invent 2024- https://reinvent.awsevents.com/- 2024년 12월 2일(월) ~ 12월 6일(금) / 미국 라스베가스- 유료 / 온라인 라이브 스트리밍 무료

인프런

2024 하반기 IT 컨퍼런스

이력서는 중요합니다.
면접관에게는 지원자를 파악하기 위한 첫번째 장소이기 때문입니다.

이런 이력서 작성을 편리하게 도와주는 사이트가 있어서 소개드립니다.
resumemaker.online 인데요.

기존에 작성한 이력서가 있다면 업로드해서 AI가 초안을 작성해주기도 합니다.
컬러나 템플릿등을 설정할 수 도 있고, 꽤 정돈된 형태로 이력서가 나오게 됩니다.

한가지 단점은 한글 폰트를 지원하지 않습니다.
그래도 이력서 작성을 별로 해보시지 않았다면 툴의 도움을 받아서 채워보시는
것도 좋을 것 같습니다.

제가 기존에 써둔 이력서를 업로드 해서 만들어봤는데 퀄리티가 나쁘지 않네요.

이력서는 중요합니다.면접관에게는 지원자를 파악하기 위한 첫번째 장소이기 때문입니다. 이런 이력서 작성을 편리하게 도와주는 사이트가 있어서 소개드립니다.resumemaker.online 인데요. 기존에 작성한 이력서가 있다면 업로드해서 AI가 초안을 작성해주기도 합니다.컬러나 템플릿등을 설정할 수 도 있고, 꽤 정돈된 형태로 이력서가 나오게 됩니다. 한가지 단점은 한글 폰트를 지원하지 않습니다.그래도 이력서 작성을 별로 해보시지 않았다면 툴의 도움을 받아서 채워보시는것도 좋을 것 같습니다. 제가 기존에 써둔 이력서를 업로드 해서 만들어봤는데 퀄리티가 나쁘지 않네요.

이력서를 편하게 만듭시다 - resumemaker

I finally have the feeling that I&rsquo;m a decent programmer, so I thought it would be fun to write some advice with the idea of &ldquo;what would have gotten me to this point faster?&rdquo; I&rsquo;m not claiming this is great advice for everyone, just 

Marcus' Blog


한 개발자가 과거의 나에게 개발자로써 조언을 해준다면? 에 대해 작성해주신 글입니다.
몇 가지는 직접적으로 저에게 도움이 되는 부분도 있어, 일부 저에게 도움되는 부분만 요약해서 공유드립니다.

🤔 계속 발에 총을 쏘고 있다면, 총을 고쳐야한다.
팀에서 시스템에 대해 자주 실수 하는 부분이 있지만, 그 실수를 줄일 방법에 대해 생각하지 않는 경우가 많습니다. 이런 경우 시스템을 개선하여 실수를 줄이는 것이 중요합니다.
이러한 문제들은 해결할 자연스러운 시기가 없었기에 오래 지속되는 경우가 많으니, 생각보다 몇 분 동안만 고민하면 해결 할 수 있는게 많습니다. 이런 문제가 있을 때 자신과 팀의 삶을 더 쉽게 만들 수 있다는 것을 상기시키고 마음가짐을 갖는게 중요합니다.

🪠 품질과 속도 사이의 균형을 맞춰야한다.
구현 속도와 정확성에 대한 자신감 사이에는 항상 트레이드오프가 존재합니다. 현재 상황에서 버그를 출시하는 것이 얼마나 괜찮은지 자문해보고, 이에 대한 답변이 작업 방식에 영향을 미치지 않는다면 지나치게 경직된 것으로 생각하세요.

🪭 톱을 갈고 있는 시간은 거의 항상 가치가 있는 시간이다.
도구를 잘 다루는 것이 중요합니다. 코드를 빠르게 작성하고, 주요 단축키를 알고, 운영체제와 셀에 능숙해야 합니다. 새로운 엔지니어에게서 보이는 가장 큰 그린 플래그 중 하나는 도구 선택과 능숙한 사용에 대한 관심입니다.

🧘🏻‍♂️버그를 한 층 더 깊이 해결하려고 노력해야 한다.
버그를 표면적으로 해결하는 대신, 근본적인 원인을 찾아 해결하는 것이 중요합니다. 최대한 어떤 컴포넌트도 이 버그를 다시 겪지 않도록 해결하려고 노력해보세요.

🏃🏻‍♀️ 버그 조사 시 히스토리를 활용해야 한다.
이상한 버그를 조사할 때, git 히스토리를 활용하는 것이 중요합니다. 예를 들어 메모리 누수 문제를 조사할 때, 특정 커밋 이후에 문제가 발생한 경우가 많으니 참고하세요.

🎆 가끔은 나쁜 코드로 작성하는 쪽으로 오류를 범해봐라.
끔찍한 코드를 작성하는 것도 쉽고, 모든 모범사례를 절대적으로 따르는 코드를 작성하는 것도 정말 쉽습니다. 하지만 이런 코드 작성은 스타트업에 돈이 바닥 날 가능성이 큽니다.
또한 빨리 코드를 작성하게 되면 추후 나쁜 기술 부채로 인해 곤란을 겪게 될 수도 있습니다.
'나쁜' 코드의 의미를 명확하게 하고, 시간과 노력의 균형을 찾아 코드를 작성해보세요.

🏋️ 디버깅 하기 쉽게 만들어야 한다.
디버깅을 쉽게 하기 위한 노력을 하지 않으면, 소프트웨어가 점점 더 복잡해짐에 따라 각 이슈를 디버깅 하는데 엄청난 시간을 소비하게 될 것 입니다. 그렇게 되면 결국 변경 하는 것이 두려워지게 됩니다. 디버깅 시간 중 설정, 재현, 사후 정리에 소요되는 시간을 추적하는 데 주의를 기울이세요.

💁‍♂️ 팀에서 일할 때는 보통 질문을 해야 한다.
경력 초반자들은 '사소한 질문으로 동료를 귀찮게 하는 것' 보다 '모든 것을 스스로 알아내려고 노력하는 것'에 너무 치우쳐 있습니다. 한 시간 넘게 무언가를 알아내기 위해 시간을 허비하지말고 몇 분 만에 답을 찾을 수 있게 항상 질문하세요. 누군가에게 귀찮은 경우는 몇 분 안에 스스로 답을 찾을 수 있었다는 것이 분명할 때 뿐입니다.

👁️ 배포 주기는 매우 중요, 빠르고 자주 배포할 수 있는 방법 고민 필요
프로젝트 배포 속도는 시간이 지남에 따라 복리로 증가해서, 상상할 수 있는 것보다 빠르게 기능을 배포할 수 있게 됩니다. 스타트업은 런웨이가 제한적이고, 프로젝트에는 마감일이 항상 있으니 빠르게 배포하기 위해 여러가지 시도를 해보세요.

한 개발자가 과거의 나에게 개발자로써 조언을 해준다면? 에 대해 작성해주신 글입니다. 몇 가지는 직접적으로 저에게 도움이 되는 부분도 있어, 일부 저에게 도움되는 부분만 요약해서 공유드립니다. 🤔 계속 발에 총을 쏘고 있다면, 총을 고쳐야한다. 팀에서 시스템에 대해 자주 실수 하는 부분이 있지만, 그 실수를 줄일 방법에 대해 생각하지 않는 경우가 많습니다. 이런 경우 시스템을 개선하여 실수를 줄이는 것이 중요합니다. 이러한 문제들은 해결할 자연스러운 시기가 없었기에 오래 지속되는 경우가 많으니, 생각보다 몇 분 동안만 고민하면 해결 할 수 있는게 많습니다. 이런 문제가 있을 때 자신과 팀의 삶을 더 쉽게 만들 수 있다는 것을 상기시키고 마음가짐을 갖는게 중요합니다. 🪠 품질과 속도 사이의 균형을 맞춰야한다.구현 속도와 정확성에 대한 자신감 사이에는 항상 트레이드오프가 존재합니다. 현재 상황에서 버그를 출시하는 것이 얼마나 괜찮은지 자문해보고, 이에 대한 답변이 작업 방식에 영향을 미치지 않는다면 지나치게 경직된 것으로 생각하세요. 🪭 톱을 갈고 있는 시간은 거의 항상 가치가 있는 시간이다.도구를 잘 다루는 것이 중요합니다. 코드를 빠르게 작성하고, 주요 단축키를 알고, 운영체제와 셀에 능숙해야 합니다. 새로운 엔지니어에게서 보이는 가장 큰 그린 플래그 중 하나는 도구 선택과 능숙한 사용에 대한 관심입니다. 🧘🏻‍♂️버그를 한 층 더 깊이 해결하려고 노력해야 한다.버그를 표면적으로 해결하는 대신, 근본적인 원인을 찾아 해결하는 것이 중요합니다. 최대한 어떤 컴포넌트도 이 버그를 다시 겪지 않도록 해결하려고 노력해보세요. 🏃🏻‍♀️ 버그 조사 시 히스토리를 활용해야 한다.이상한 버그를 조사할 때, git 히스토리를 활용하는 것이 중요합니다. 예를 들어 메모리 누수 문제를 조사할 때, 특정 커밋 이후에 문제가 발생한 경우가 많으니 참고하세요. 🎆 가끔은 나쁜 코드로 작성하는 쪽으로 오류를 범해봐라.끔찍한 코드를 작성하는 것도 쉽고, 모든 모범사례를 절대적으로 따르는 코드를 작성하는 것도 정말 쉽습니다. 하지만 이런 코드 작성은 스타트업에 돈이 바닥 날 가능성이 큽니다. 또한 빨리 코드를 작성하게 되면 추후 나쁜 기술 부채로 인해 곤란을 겪게 될 수도 있습니다.'나쁜' 코드의 의미를 명확하게 하고, 시간과 노력의 균형을 찾아 코드를 작성해보세요. 🏋️ 디버깅 하기 쉽게 만들어야 한다.디버깅을 쉽게 하기 위한 노력을 하지 않으면, 소프트웨어가 점점 더 복잡해짐에 따라 각 이슈를 디버깅 하는데 엄청난 시간을 소비하게 될 것 입니다. 그렇게 되면 결국 변경 하는 것이 두려워지게 됩니다. 디버깅 시간 중 설정, 재현, 사후 정리에 소요되는 시간을 추적하는 데 주의를 기울이세요. 💁‍♂️ 팀에서 일할 때는 보통 질문을 해야 한다.경력 초반자들은 '사소한 질문으로 동료를 귀찮게 하는 것' 보다 '모든 것을 스스로 알아내려고 노력하는 것'에 너무 치우쳐 있습니다. 한 시간 넘게 무언가를 알아내기 위해 시간을 허비하지말고 몇 분 만에 답을 찾을 수 있게 항상 질문하세요. 누군가에게 귀찮은 경우는 몇 분 안에 스스로 답을 찾을 수 있었다는 것이 분명할 때 뿐입니다. 👁️ 배포 주기는 매우 중요, 빠르고 자주 배포할 수 있는 방법 고민 필요프로젝트 배포 속도는 시간이 지남에 따라 복리로 증가해서, 상상할 수 있는 것보다 빠르게 기능을 배포할 수 있게 됩니다. 스타트업은 런웨이가 제한적이고, 프로젝트에는 마감일이 항상 있으니 빠르게 배포하기 위해 여러가지 시도를 해보세요.

mbuffett.com

15년 전 나에게 해주고 싶은 프로그래밍 조언

컴퓨터 공부를 처음 시작한 날이 2004년 8월 25일. 이제 20년이 지났습니다.

죽을 만큼 힘든 날은 없었다

컴퓨터 공부를 처음 시작한 날이 2004년 8월 25일.
이제 20년이 지났습니다.

돌아보면 그렇게 쉽진 않았지만 또 그렇게 어렵지도 않았던 것 같습니다.

매일 조금씩 힘들고 피곤하긴 했지만..
죽을 만큼 힘들다고 생각해 본 날은 없습니다.

마라톤 금메달리스트 황영조 선수가 훈련 중에 자동차가 지나가면 그 바퀴 밑으로 뛰어들어 죽고 싶었다고 말했던 걸 기억합니다. 도대체 어느 정도 힘들어야 죽어버리는 게 낫겠다는 생각을 할 수 있을까?

저에게는 그런 날은 하루도 없었던 것입니다.
이 정도면 뭐 할만한 것 아닌가?

죽을 만큼 힘들게 훈련하진 않더라도,
(그렇게 해야 세계 챔피언이 될 수 있나 봅니다)
적당한 훈련을 매일 오랫동안 해나가면 인생을 편안하게 살 만큼의 성취 정도는 이룰 수 있다는 걸 나중에야 알게 됐습니다.
왜냐면 그것조차 할 수 있는 사람이 별로 없으니까.

이걸 알고 나서 마음이 참 편해졌습니다.
난 분명히 잘될 거야.
더 즐기면서 일할 수 있게 되었습니다.

https://jeho.page/essay/2024/07/17/not-easy-but-not-hard-either.html

컴퓨터 공부를 처음 시작한 날이 2004년 8월 25일. 이제 20년이 지났습니다. 돌아보면 그렇게 쉽진 않았지만 또 그렇게 어렵지도 않았던 것 같습니다. 매일 조금씩 힘들고 피곤하긴 했지만.. 죽을 만큼 힘들다고 생각해 본 날은 없습니다. 마라톤 금메달리스트 황영조 선수가 훈련 중에 자동차가 지나가면 그 바퀴 밑으로 뛰어들어 죽고 싶었다고 말했던 걸 기억합니다. 도대체 어느 정도 힘들어야 죽어버리는 게 낫겠다는 생각을 할 수 있을까? 저에게는 그런 날은 하루도 없었던 것입니다. 이 정도면 뭐 할만한 것 아닌가? 죽을 만큼 힘들게 훈련하진 않더라도, (그렇게 해야 세계 챔피언이 될 수 있나 봅니다) 적당한 훈련을 매일 오랫동안 해나가면 인생을 편안하게 살 만큼의 성취 정도는 이룰 수 있다는 걸 나중에야 알게 됐습니다. 왜냐면 그것조차 할 수 있는 사람이 별로 없으니까. 이걸 알고 나서 마음이 참 편해졌습니다. 난 분명히 잘될 거야. 더 즐기면서 일할 수 있게 되었습니다. https://jeho.page/essay/2024/07/17/not-easy-but-not-hard-either.html

K리그 프로그래머

회계는 지난 수백 년 동안 크게 변하지 않았음그럼에도 불구하고, 금융 시스템을 위한 소프트웨어를 구축하는 올바른 방법에 대해 많은 혼란이 있음이 글에서는 대기업에서 금융 시스템을 구축한 경험을 바탕으로 한 교훈을 공유회계 시스템 구축에 초점을 맞추겠지만, 이 원칙들은 더 일반적인 금융 시스템에도 적용됨기본 금융 용어 정의일반 원장 (General Ledge

금융 시스템 구축을 위한 엔지니어링 원칙 | GeekNews

예전에 회계 시스템 만들때, "아 정말 나는 금융을 하나도 모르는 구나" 하면서 참 고생했던 기억이 있습니다.

숫자 계산을 좋아하는 개발자들이지만, 역사가 긴 금융, 회계 시스템, 환율, 정책, 원리에 대해서 이해하지 않으면 설계에서부터 시작해서, 멱등성 유지, 트랜잭션 등 자칫 고려하지 못하면 큰일 나는 구석들도 많은 아주 흥미로우면서 후덜덜한 영역일 것 같습니다.

news.hada.io/topic?id=15794

블로그 글 뿐만 아니라 저도 설계에 도움 많이 받았던 글들 공유드려봅니다!

 * Martin Fowler - Accounting Patterns : https://martinfowler.com/apsupp/accounting.pdf
   
 * 실제 서비스 API로 만들면 이런 모양이 될꺼다!로 제일 참고하기 좋았던 Twisp Doc (GraphQL) : https://t.co/m78EFpYX7w

예전에 회계 시스템 만들때, "아 정말 나는 금융을 하나도 모르는 구나" 하면서 참 고생했던 기억이 있습니다. 숫자 계산을 좋아하는 개발자들이지만, 역사가 긴 금융, 회계 시스템, 환율, 정책, 원리에 대해서 이해하지 않으면 설계에서부터 시작해서, 멱등성 유지, 트랜잭션 등 자칫 고려하지 못하면 큰일 나는 구석들도 많은 아주 흥미로우면서 후덜덜한 영역일 것 같습니다. news.hada.io/topic?id=15794 블로그 글 뿐만 아니라 저도 설계에 도움 많이 받았던 글들 공유드려봅니다! <ul ><li>Martin Fowler - Accounting Patterns : https://martinfowler.com/apsupp/accounting.pdf </li><li>실제 서비스 API로 만들면 이런 모양이 될꺼다!로 제일 참고하기 좋았던 Twisp Doc (GraphQL) : https://t.co/m78EFpYX7w </li></ul>

GeekNews

금융 시스템 구축을 위한 엔지니어링 원칙

테스트 코드는 왜 써야 할까요? 테스트 코드가 가져오는 베네핏들에는 어떤 것이 있을까요?

모닥불 | EP.3 프론트엔드 개발에서 테스트 자동화, 꼭 해야 할까?

프론트엔드 개발 영역에서 테스트 코드의 필요성은 지속적인 논의의 대상입니다. 사용자 인터페이스와 직접적으로 연결되는 프론트엔드 코드의 특성상, 빈번하고 다양한 변화에 직면하게 되기 때문인데요. 이러한 환경에서 개발자들은 때때로 시간적 제약으로 인해 테스트 코드 작성을 생략하고 즉각적인 개발에 집중하게 되는데요. 이는 단기적으로 생산성 향상으로 느껴질 수 있습니다.
그러나 이러한 접근은 '단기적 효율'과 '장기적 지속가능성' 사이의 균형에 대한 문제를 제기합니다. 테스트 코드 없이 진행되는 개발이 당장은 빠른 결과물 도출로 이어질 수 있지만, 장기적 관점에서는 오히려 생산성 저하와 품질 문제로 이어질 수 있기 때문인데요.
그렇다면 테스트 코드가 어떻게 장기적인 생산성 향상에 기여하는 것일까요? 다음은 테스트 코드가 가져다주는 주요 이점들입니다:
 1. 신속한 피드백 루프: 테스트 코드는 개발자가 변경사항을 즉각적으로 검증할 수 있게 해줍니다. 이는 수동 테스트 과정을 최소화하고, 버그를 조기에 발견하여 수정 비용을 절감시킵니다.
 2. 리팩토링 자신감: 잘 작성된 테스트 코드는 개발자에게 코드 개선에 대한 자신감을 부여합니다. 기존 기능의 정상 작동을 보장하면서 새로운 기능을 추가하거나 라이브러리 업데이트를 할 수 있습니다.
 3. 문서화 효과: 테스트 코드는 실행 가능한 명세서 역할을 합니다. 특히 빠르게 변화하는 스타트업 환경에서, 테스트 코드는 최신 상태의 신뢰할 수 있는 문서가 됩니다.

그렇다면 테스트 코드는 어떻게 작성해야 할까요? 아마 많은 개발자 분들이 실질적으로 궁금해하는 내용일텐데요. 전통적인 테스트 피라미드 접근법은 유닛 테스트를 기반으로, 통합 테스트, 그리고 E2E(End-to-End) 테스트 순으로 구성됩니다. 그러나 실제 개발 에서는 이론과 실제 적용 사이의 간극이 존재하기 마련인데요. 토스의 테스트 전략은 아래와 같은 개념 으로 구성되어 있습니다:
 1. 전략적 선별: 복잡성이 높고 비즈니스에 중요한 기능에 테스트 역량을 집중합니다. 단순한 UI 요소보다는 핵심 비즈니스 로직과 주요 사용자 시나리오에 초점을 맞춤으로써, 테스트의 투자 대비 생산성을 극대화합니다.
 2. 통합 테스트 중심 접근: 페이지 단위의 통합 테스트로 실제 사용자 경험에 더 가까운 테스트 시나리오를 구성합니다. 이러한 방식은 개별 컴포넌트의 기능성뿐만 아니라, 상호작용하여 전체 시스템을 구성하는지 검증할 수 있게 해줍니다.
 3. 생산성과 효율성의 균형: 너무 단순한 테스트는 작성하지 않습니다. 예를 들어, 즉시 확인 가능한 단순 UI 변경사항에 대해서는 별도의 자동화된 테스트를 작성하지 않습니다.

결론적으로, 토스의 프론트엔드 테스트는 기존의 이론적 모델을 맹목적으로 따르기보다는 실질적인 가치를 제공하는 방향으로 접근하고 있습니다. 통합테스트 중심의 실용적 접근을 통해 개발 생산성과 품질 사이의 적절한 균형을 맞추는게 인상적이었습니다.

https://toss.tech/article/firesidechat_frontend_3

프론트엔드 개발 영역에서 테스트 코드의 필요성은 지속적인 논의의 대상입니다. 사용자 인터페이스와 직접적으로 연결되는 프론트엔드 코드의 특성상, 빈번하고 다양한 변화에 직면하게 되기 때문인데요. 이러한 환경에서 개발자들은 때때로 시간적 제약으로 인해 테스트 코드 작성을 생략하고 즉각적인 개발에 집중하게 되는데요. 이는 단기적으로 생산성 향상으로 느껴질 수 있습니다.그러나 이러한 접근은 '단기적 효율'과 '장기적 지속가능성' 사이의 균형에 대한 문제를 제기합니다. 테스트 코드 없이 진행되는 개발이 당장은 빠른 결과물 도출로 이어질 수 있지만, 장기적 관점에서는 오히려 생산성 저하와 품질 문제로 이어질 수 있기 때문인데요.그렇다면 테스트 코드가 어떻게 장기적인 생산성 향상에 기여하는 것일까요? 다음은 테스트 코드가 가져다주는 주요 이점들입니다:<ol ><li>신속한 피드백 루프: 테스트 코드는 개발자가 변경사항을 즉각적으로 검증할 수 있게 해줍니다. 이는 수동 테스트 과정을 최소화하고, 버그를 조기에 발견하여 수정 비용을 절감시킵니다.</li><li>리팩토링 자신감: 잘 작성된 테스트 코드는 개발자에게 코드 개선에 대한 자신감을 부여합니다. 기존 기능의 정상 작동을 보장하면서 새로운 기능을 추가하거나 라이브러리 업데이트를 할 수 있습니다.</li><li>문서화 효과: 테스트 코드는 실행 가능한 명세서 역할을 합니다. 특히 빠르게 변화하는 스타트업 환경에서, 테스트 코드는 최신 상태의 신뢰할 수 있는 문서가 됩니다.</li></ol> 그렇다면 테스트 코드는 어떻게 작성해야 할까요? 아마 많은 개발자 분들이 실질적으로 궁금해하는 내용일텐데요. 전통적인 테스트 피라미드 접근법은 유닛 테스트를 기반으로, 통합 테스트, 그리고 E2E(End-to-End) 테스트 순으로 구성됩니다. 그러나 실제 개발 에서는 이론과 실제 적용 사이의 간극이 존재하기 마련인데요. 토스의 테스트 전략은 아래와 같은 개념 으로 구성되어 있습니다:<ol ><li>전략적 선별: 복잡성이 높고 비즈니스에 중요한 기능에 테스트 역량을 집중합니다. 단순한 UI 요소보다는 핵심 비즈니스 로직과 주요 사용자 시나리오에 초점을 맞춤으로써, 테스트의 투자 대비 생산성을 극대화합니다.</li><li>통합 테스트 중심 접근: 페이지 단위의 통합 테스트로 실제 사용자 경험에 더 가까운 테스트 시나리오를 구성합니다. 이러한 방식은 개별 컴포넌트의 기능성뿐만 아니라, 상호작용하여 전체 시스템을 구성하는지 검증할 수 있게 해줍니다.</li><li>생산성과 효율성의 균형: 너무 단순한 테스트는 작성하지 않습니다. 예를 들어, 즉시 확인 가능한 단순 UI 변경사항에 대해서는 별도의 자동화된 테스트를 작성하지 않습니다.</li></ol> 결론적으로, 토스의 프론트엔드 테스트는 기존의 이론적 모델을 맹목적으로 따르기보다는 실질적인 가치를 제공하는 방향으로 접근하고 있습니다. 통합테스트 중심의 실용적 접근을 통해 개발 생산성과 품질 사이의 적절한 균형을 맞추는게 인상적이었습니다. https://toss.tech/article/firesidechat_frontend_3

변화하는 UI, 변하지 않는 품질: 토스의 프론트엔드 테스트 전략

원문 : https&#x3A;//dev.to/yoskutik/extremely-reducing-the-size-of-npm-package-3420

[번역] NPM 패키지 크기 대폭 축소하기

오늘 소개해드릴 글은 라인플러스의 손수림님이 번역해주신 글입니다.

이 글에서는 테스트 커버리지, 문서 작성, 유효한 버전 관리, 변경 로그 관리 등 패키지 개발의 다양한 측면을 다루고 있으며 특히 패키지의 크기를 최소화하는 방법에 초점을 맞추고 있습니다.

글은 크게 두 가지 부분로 나뉘어지며 첫 번째 부분에서는 의존성 설정과 빌드 프로세스와 같은 일반적인 팁을, 두 번째 부분에서는 개발자 경험(DX)을 약간 희생하면서도 패키지 크기를 더 작게 만드는 구체적인 코드 작성 방법을 설명합니다.

각종 최적화 팁과 더불어 코드 예제와 설명이 포함되어 있어 패키지 배포에 관심이 있으신 분들은 가볍게 읽어보시는 것을 추천드립니다. :)

> 글 링크 : https://velog.io/@surim014/extremely-reducing-the-size-of-npm-packages

오늘 소개해드릴 글은 라인플러스의 손수림님이 번역해주신 글입니다. 이 글에서는 테스트 커버리지, 문서 작성, 유효한 버전 관리, 변경 로그 관리 등 패키지 개발의 다양한 측면을 다루고 있으며 특히 패키지의 크기를 최소화하는 방법에 초점을 맞추고 있습니다. 글은 크게 두 가지 부분로 나뉘어지며 첫 번째 부분에서는 의존성 설정과 빌드 프로세스와 같은 일반적인 팁을, 두 번째 부분에서는 개발자 경험(DX)을 약간 희생하면서도 패키지 크기를 더 작게 만드는 구체적인 코드 작성 방법을 설명합니다. 각종 최적화 팁과 더불어 코드 예제와 설명이 포함되어 있어 패키지 배포에 관심이 있으신 분들은 가볍게 읽어보시는 것을 추천드립니다. :) &gt; 글 링크 : https://velog.io/@surim014/extremely-reducing-the-size-of-npm-packages

NPM 패키지 크기 대폭 축소하기

테니스 황제라고 불리는 로저 페더러의 최근 다트머스 졸업 연설. 모든 내용 하나하나가 주옥같았다. 일등 하는 사람들은 항상 배울 것이 있다. 그것도 전 세계 1등이니까. 그 사람이 거기까지 가는 데 있어서 내면적으로 겪은 경험들은... 아주 값진 지혜들을 담고 있다. 모든 내용들이 다 좋았지만, 나는 캡처한 부분이 제일 좋았다.

로저 페더러 다트머스 졸업연설

테니스 황제라고 불리는 로저 페더러의 최근 다트머스 졸업 연설이 인상적이다. 그가 이제 대학을 졸업하고 사회로 나가는 졸업생들과 나눈 세 가지 메시지에 내 생각을 얹어본다.

1) Effortless is a myth. (공짜는 없다)
우린 모두 타고난 각자의 재능이 있다. 기가 막힌 음색을 가지고 태어난 사람도 있고, 숫자에 능한 사람도 있고, 동물적으로 운동감각이 뛰어난 사람도 있다. 성공하려면 타고난 재능을 가지고 있어야 한다는 말도 맞을지 모르겠다. 그래서일까? 우리는 종종 성공한 사람들을 보며 타고난 재능이라고 치부해 버리기도 하고, 쉽게 해내는 (것처럼 보이는) 결과물을 보며 그 자리까지 가기 위해 흘린 피 땀 눈물을 외면해 버리기도 한다.

로저 페더러는 자신이 테니스 선수에게 필요한 재능을 타고났음을 인정하면서(타고난 재능을 커리어와 연결시키는 건 매우 중요하다), 타고난 재능만으로는 성공할 수 없음을 강조한다. "Believe in yourself has to be earned."라며 자신에 대한 믿음은 경기를 승리로 이끄는데 꼭 필요한 재능인데, 이는 타고난 재능이 아니라 각고의 노력으로 얻어내야 하는 재능이라고 말한다. 인내심과 끈기, 과정을 즐길 수 있는 여유, 자기 관리... 이 모든 게 치열한 자신과의 싸움으로 만들어낸 재능이라는 것이다. 나는 개인적으로 "to be earned"라는 말을 좋아한다. 우리의 성공이 타고난 재능으로 결정된다면 억울하고 재미없는 삶이 되겠지만, 내가 노력해서 얻어낸 재능으로 성공을 만들 수 있다면 살아볼 만한 인생이라는 에너지가 생긴다.

나는 최근 일적으로 폭풍 속을 걷는 것 같은 시기를 보내고 있는데, 자기 확신, 회복력, 긍정적 마인드 이 세 재능을 바닥내지 않고 든든하게 키우기 위해 노력 중이다. 새로운 프로젝트를 리딩하고 팀을 매니징하고 의사결정을 내리는데 자기 확신은 필수이다. 그렇지 않으면 매사 불안감이 커져서 잘못된 판단을 내리거나, 결정을 미루거나, 책임을 전가해 버리는 결과를 내기 쉽다. 새로운 일을 시도할 때는 (특히 제로투원을 만들어 낼 때는) 실수나 실패를 했을 때 빠르게 인정하고 회복할 수 있어야 한다. 한 번에 성공하는 게 목표가 아니라 빠르게 실패하고 그걸 발판으로 또다시 시도하거나 피벗을 하면서 방향을 잡아 가는게 중요하기 때문이다. 실수나 실패에 타격이 큰 사람은 오래 버틸 수가 없다. 자기 확신과 회복력은 긍정적 마인드를 베이스로 한다. 괜찮다는 마음, 할 수 있다는 마음, 까짓것 일단 한번 해보지 뭐, 아님 말고! 하는 초긍정 마인드가 성공에 꼭 필요한 재능이고, 이건 타고난 재능이 아니라 치열한 노력으로 만들어진다. "Belive in yourself has to be earned."

각자 가진 재능을 잘 살펴보고 어떤 재능을 더 키워야 하는지 적어보면 어떨까. 성실한 것도, 잘 웃는 것도, 친화력 있는 것도, 책임감이 있는 것도 모두 노력으로 얻어야 하는 재능들이다.

2) It's only a point. (그저 1 포인트일 뿐이다)
테니스의 황제라고 불리는 로저 페더러의 한 세트 평균 승률은 54%. 세계 최고 탑 플레이어이지만 승률은 50% 정도라는 것이다. (야구도 3할이면 최강 타자라고 불린다). 한 포인트는 승부사에게 매우 중요한 순간이지만(그래서 한 포인트를 얻기 위해 최선을 다해야 하지만), 졌을 땐 그저 한 포인트로 진거 일뿐이라는 거다. 진 포인트에 연연하면 다음 포인트를 놓치게 된다. 인생을 살다 보면 1 포인트를 잃게 되는 경우가 흔히 생기는데, 1 포인트는 그저 1 포인트일 뿐. It's OK. It's only a point. 인생 최고의 샷을 만들었다면? 그 또한 1 포인트일 뿐이다.

"When you're playing a point, it has to be the most important thing in the world and it is. But when it's behind you it's behind you. This mindset is really crucial because it frees you to fully commit to the next point and the next point after, with intensity, clarify, and focus. The truth is whatever game you play in life, sometimes you're going to lose; a point, a match, a season, a job.. it's a roller coaster with many ups and downs, but negative energy is wasted energy. You want to become a master at overcoming hard moments. That is a sign of a champion."

월드 챔피언은 모든 경기를 이겨서가 아니라, 자신의 패배를 다루는 법을 잘 알고 훈련한 사람이라고 강조한다.

"The best in the world are not the best because they win every point. But it's because they know they lose again and again and have learned how to deal with it."

어느 날은 일을 잘 해낸 것 같아서 뿌듯하다가, 어느 날은 다 망친 것 같아서 자괴감에 빠질 때도 있다. 동료들에게 칭찬을 듣기도 하고 비난을 받기도 한다. 내가 만든 결과물이 졸작인 것 같아서 다 버리고 싶은 날들이 이어지기도 한다. 성공도 실패도 그저 내 커리어 인생에 1 포인트일 뿐이다. 1포인트로 게임에서 진 것보다, 더 위험한 게 '난 역시 안 되나 봐', '자존심 상해서 그만뒀어', '다시 도전한 엄두가 안 나' 이런 마음으로 이어지는 패배감이다. 그저 1 포인트라는 걸 상기하자. 세계 최강 선수도 승률이 50%이고, 최강 타자도 3할인데, 평범한 내가 매번 성공한다면 그게 더 이상한 거다. 일희일비하지 말자. 그저 1 포인트씩 쌓아가는 거다.

3) Life is bigger than a court.
16살에 테니스 커리어를 시작해서 24년 동안 테니스 코트에서 살았고 테니스에서 인생을 배웠다고 생각했는데, 2022년에 은퇴를 하고 보니 자신이 몰랐던 큰 세상이 있더라는 깨달음.

내가 처한 상황이 절망적이라고 느껴질 때, 내가 손에 쥐고 있는 걸 놓으면 세상이 무너질 것 같은 두려움이 생길 때, 나만 뒤처지고 억울한 것 같다는 생각이 밀려올 때.. 내 눈에 가림막을 하고 무작정 달리고 있는 건 아닌지 멈춰서 살펴봐야 한다. 생각해 보면 내가 만나는 사람들의 숫자도 지극히 제한적이고, 내가 속한 커리어 분야도 매우 협소하고 (게다가 나는 내가 하는 일 외엔 모르는 게 너무 많다), 내가 경험한 세계도 고작 몇몇 나라와 도시들뿐이다. 여행을 하면 내가 모르는 세상과 만나게 되는 게 가장 큰 인생 배움이 된다. 세상은 넓고, 사람들은 다양하고, 삶은 다 각자 다른 모습으로 꽃을 피운다. 인생을 내 커리어 코트에 묶어 놓는다면 경기가 끝났을 때 멘붕이 올 것이다. 커리어는 커리어일 뿐, 인생 전부가 아니다. 꼭 명심하자.

https://www.youtube.com/watch?v=t8v0cHn_LRc

테니스 황제라고 불리는 로저 페더러의 최근 다트머스 졸업 연설이 인상적이다. 그가 이제 대학을 졸업하고 사회로 나가는 졸업생들과 나눈 세 가지 메시지에 내 생각을 얹어본다.​1) Effortless is a myth. (공짜는 없다)우린 모두 타고난 각자의 재능이 있다. 기가 막힌 음색을 가지고 태어난 사람도 있고, 숫자에 능한 사람도 있고, 동물적으로 운동감각이 뛰어난 사람도 있다. 성공하려면 타고난 재능을 가지고 있어야 한다는 말도 맞을지 모르겠다. 그래서일까? 우리는 종종 성공한 사람들을 보며 타고난 재능이라고 치부해 버리기도 하고, 쉽게 해내는 (것처럼 보이는) 결과물을 보며 그 자리까지 가기 위해 흘린 피 땀 눈물을 외면해 버리기도 한다.​로저 페더러는 자신이 테니스 선수에게 필요한 재능을 타고났음을 인정하면서(타고난 재능을 커리어와 연결시키는 건 매우 중요하다), 타고난 재능만으로는 성공할 수 없음을 강조한다. "Believe in yourself has to be earned."라며 자신에 대한 믿음은 경기를 승리로 이끄는데 꼭 필요한 재능인데, 이는 타고난 재능이 아니라 각고의 노력으로 얻어내야 하는 재능이라고 말한다. 인내심과 끈기, 과정을 즐길 수 있는 여유, 자기 관리... 이 모든 게 치열한 자신과의 싸움으로 만들어낸 재능이라는 것이다. 나는 개인적으로 "to be earned"라는 말을 좋아한다. 우리의 성공이 타고난 재능으로 결정된다면 억울하고 재미없는 삶이 되겠지만, 내가 노력해서 얻어낸 재능으로 성공을 만들 수 있다면 살아볼 만한 인생이라는 에너지가 생긴다.​나는 최근 일적으로 폭풍 속을 걷는 것 같은 시기를 보내고 있는데, 자기 확신, 회복력, 긍정적 마인드 이 세 재능을 바닥내지 않고 든든하게 키우기 위해 노력 중이다. 새로운 프로젝트를 리딩하고 팀을 매니징하고 의사결정을 내리는데 자기 확신은 필수이다. 그렇지 않으면 매사 불안감이 커져서 잘못된 판단을 내리거나, 결정을 미루거나, 책임을 전가해 버리는 결과를 내기 쉽다. 새로운 일을 시도할 때는 (특히 제로투원을 만들어 낼 때는) 실수나 실패를 했을 때 빠르게 인정하고 회복할 수 있어야 한다. 한 번에 성공하는 게 목표가 아니라 빠르게 실패하고 그걸 발판으로 또다시 시도하거나 피벗을 하면서 방향을 잡아 가는게 중요하기 때문이다. 실수나 실패에 타격이 큰 사람은 오래 버틸 수가 없다. 자기 확신과 회복력은 긍정적 마인드를 베이스로 한다. 괜찮다는 마음, 할 수 있다는 마음, 까짓것 일단 한번 해보지 뭐, 아님 말고! 하는 초긍정 마인드가 성공에 꼭 필요한 재능이고, 이건 타고난 재능이 아니라 치열한 노력으로 만들어진다. "Belive in yourself has to be earned."​각자 가진 재능을 잘 살펴보고 어떤 재능을 더 키워야 하는지 적어보면 어떨까. 성실한 것도, 잘 웃는 것도, 친화력 있는 것도, 책임감이 있는 것도 모두 노력으로 얻어야 하는 재능들이다.​2) It's only a point. (그저 1 포인트일 뿐이다)테니스의 황제라고 불리는 로저 페더러의 한 세트 평균 승률은 54%. 세계 최고 탑 플레이어이지만 승률은 50% 정도라는 것이다. (야구도 3할이면 최강 타자라고 불린다). 한 포인트는 승부사에게 매우 중요한 순간이지만(그래서 한 포인트를 얻기 위해 최선을 다해야 하지만), 졌을 땐 그저 한 포인트로 진거 일뿐이라는 거다. 진 포인트에 연연하면 다음 포인트를 놓치게 된다. 인생을 살다 보면 1 포인트를 잃게 되는 경우가 흔히 생기는데, 1 포인트는 그저 1 포인트일 뿐. It's OK. It's only a point. 인생 최고의 샷을 만들었다면? 그 또한 1 포인트일 뿐이다.​"When you're playing a point, it has to be the most important thing in the world and it is. But when it's behind you it's behind you. This mindset is really crucial because it frees you to fully commit to the next point and the next point after, with intensity, clarify, and focus. The truth is whatever game you play in life, sometimes you're going to lose; a point, a match, a season, a job.. it's a roller coaster with many ups and downs, but negative energy is wasted energy. You want to become a master at overcoming hard moments. That is a sign of a champion."​월드 챔피언은 모든 경기를 이겨서가 아니라, 자신의 패배를 다루는 법을 잘 알고 훈련한 사람이라고 강조한다.​"The best in the world are not the best because they win every point. But it's because they know they lose again and again and have learned how to deal with it." 어느 날은 일을 잘 해낸 것 같아서 뿌듯하다가, 어느 날은 다 망친 것 같아서 자괴감에 빠질 때도 있다. 동료들에게 칭찬을 듣기도 하고 비난을 받기도 한다. 내가 만든 결과물이 졸작인 것 같아서 다 버리고 싶은 날들이 이어지기도 한다. 성공도 실패도 그저 내 커리어 인생에 1 포인트일 뿐이다. 1포인트로 게임에서 진 것보다, 더 위험한 게 '난 역시 안 되나 봐', '자존심 상해서 그만뒀어', '다시 도전한 엄두가 안 나' 이런 마음으로 이어지는 패배감이다. 그저 1 포인트라는 걸 상기하자. 세계 최강 선수도 승률이 50%이고, 최강 타자도 3할인데, 평범한 내가 매번 성공한다면 그게 더 이상한 거다. 일희일비하지 말자. 그저 1 포인트씩 쌓아가는 거다.​3) Life is bigger than a court.16살에 테니스 커리어를 시작해서 24년 동안 테니스 코트에서 살았고 테니스에서 인생을 배웠다고 생각했는데, 2022년에 은퇴를 하고 보니 자신이 몰랐던 큰 세상이 있더라는 깨달음.​내가 처한 상황이 절망적이라고 느껴질 때, 내가 손에 쥐고 있는 걸 놓으면 세상이 무너질 것 같은 두려움이 생길 때, 나만 뒤처지고 억울한 것 같다는 생각이 밀려올 때.. 내 눈에 가림막을 하고 무작정 달리고 있는 건 아닌지 멈춰서 살펴봐야 한다. 생각해 보면 내가 만나는 사람들의 숫자도 지극히 제한적이고, 내가 속한 커리어 분야도 매우 협소하고 (게다가 나는 내가 하는 일 외엔 모르는 게 너무 많다), 내가 경험한 세계도 고작 몇몇 나라와 도시들뿐이다. 여행을 하면 내가 모르는 세상과 만나게 되는 게 가장 큰 인생 배움이 된다. 세상은 넓고, 사람들은 다양하고, 삶은 다 각자 다른 모습으로 꽃을 피운다. 인생을 내 커리어 코트에 묶어 놓는다면 경기가 끝났을 때 멘붕이 올 것이다. 커리어는 커리어일 뿐, 인생 전부가 아니다. 꼭 명심하자.​https://www.youtube.com/watch?v=t8v0cHn_LRc

YouTube

로저 페더러에게 배우는 성공의 비결

리눅스의 창시자인 리누스 토발즈의 유명한 말 중에 다음과 같은 명언이 있다.

“Talk is cheap, show me the code.”

AI가 대신 코딩해주는 시대에, 이제 이 말은 다음처럼 바뀌어야 하지 않을까 싶다.

“Code is cheap, talk about value.”

리눅스의 창시자인 리누스 토발즈의 유명한 말 중에 다음과 같은 명언이 있다. “Talk is cheap, show me the code.” AI가 대신 코딩해주는 시대에, 이제 이 말은 다음처럼 바뀌어야 하지 않을까 싶다. “Code is cheap, talk about value.”

리눅스의 창시자인 리누스 토발즈의 유명한 말 중에 다음과 같은 명

SCAMPER는 아이디어 발상을 도와주는 창의적 사고도구입니다. 각각의 알파벳은 아이디어를 발전시키기 위한 구체적인 질문을 나타냅니다.

1. Substitute (대체하기): 어떤 요소를 다른 것으로 바꿀 수 있을까?
- 예시: 플라스틱 빨대를 종이 빨대로 대체하기.

2. Combine (결합하기): 두 가지 요소를 결합하면 새로운 것이 나올까?
- 예시: 스마트폰과 카메라 기능 결합.

3. Adapt (적용하기): 다른 분야에서 성공한 아이디어를 적용할 수 있을까?
- 예시: 자동차 좌석의 열선 기능을 사무실 의자에 적용.

4. Modify (변형하기): 기존 아이디어를 어떻게 변형할 수 있을까?
- 예시: 기존 제품의 색상이나 크기 변경.

5. Put to another use (다른 용도로 사용하기): 다른 방식으로 활용할 수 있을까?
- 예시: 와인병을 꽃병으로 사용.

6. Eliminate (제거하기): 불필요한 요소를 제거할 수 있을까?
- 예시: 제품의 복잡한 기능을 제거하고 단순화.

7. Reverse (반대로 생각하기): 순서를 뒤집거나 반대로 해볼 수 있을까?
- 예시: 패키지 배송을 고객이 직접 픽업하게 하기.

SCAMPER는 아이디어 발상을 도와주는 창의적 사고도구입니다. 각각의 알파벳은 아이디어를 발전시키기 위한 구체적인 질문을 나타냅니다. 1. Substitute (대체하기): 어떤 요소를 다른 것으로 바꿀 수 있을까? - 예시: 플라스틱 빨대를 종이 빨대로 대체하기. 2. Combine (결합하기): 두 가지 요소를 결합하면 새로운 것이 나올까? - 예시: 스마트폰과 카메라 기능 결합. 3. Adapt (적용하기): 다른 분야에서 성공한 아이디어를 적용할 수 있을까? - 예시: 자동차 좌석의 열선 기능을 사무실 의자에 적용. 4. Modify (변형하기): 기존 아이디어를 어떻게 변형할 수 있을까? - 예시: 기존 제품의 색상이나 크기 변경. 5. Put to another use (다른 용도로 사용하기): 다른 방식으로 활용할 수 있을까? - 예시: 와인병을 꽃병으로 사용. 6. Eliminate (제거하기): 불필요한 요소를 제거할 수 있을까? - 예시: 제품의 복잡한 기능을 제거하고 단순화. 7. Reverse (반대로 생각하기): 순서를 뒤집거나 반대로 해볼 수 있을까? - 예시: 패키지 배송을 고객이 직접 픽업하게 하기.

아이디어가 잘 안생길 때 쓸 수 있는 프레임워크 SCAMPER 💡

연차별 직책별 망한 커리어의 기준

🤔 나 연차별 커리어 잘 쌓고있나? 단순명료 점검 기준

흔히 말하는 직장인의 역량은 공통역량(커뮤니케이션 스킬 등)+직무역량+리더십역량인데요, 연차가 쌓일수록 리더십역량에서 승승장구 or 도태가 결정되더라고요. 물론 앞에 두 역량이 단연 우수하다는 전제인데, 가끔 직무역량이 딸려도 잘나가는 사람들이 있다만 오래가지는 못하는 것 같습니다. 

스타트업, 중소기업같이 작은 규모일수록 레벨을 체크레스트+2 정도로 생각해야 좀 더 객관적으로 자신의 수준을 파악하는 것이라고 하니, 좀 더 큰 규모로 이직을 생각한다면 이 점 잘 고려해 커리어 경험을 만들어가야겠어요.

연차별 커리어 체크리스트
✔️ 아직까지는 아무것도 해본 적 없는 것 같다 (⁉️)
✔️ 회사의 규칙과 시스템을 잘 활용할 수 있다 (대리급)
✔️ 나혼자 하는 업무는 큰 문제 없이 수행할 수 있다(대리급)
✔️ 문제점을 진단해서 개선시킨 적이 있다(차과장급)
✔️ 팀원을 이끌고 목표를 달성한 적이 있다(차과장급)
✔️ 새로운 프로젝트/신사업을 제안하여 추진한 적이 있다(부장급)
✔️ 사업의 구조와 일하는 방식을 바꿔본 적이 있다(임원급)

퍼블리의 그로스 매니저로 커리어를 시작하여, 현재는 멤버십 사업을 총괄하고 있습니다.
합리적이고 해피한 세상을 향해 살아가고 있으며, 책과 교육, 경제에 관심을 가지고 있습니다.
일하는 것을 싫어하지만, 많이 하고 있습니다..

커리어리 Lead Product Manager

김광종

퍼블리 그로스매니저로 커리어를 시작하여, 프로덕트매니저와 사업총괄을 거쳐, 커리어리팀을 리드하였습니다.
합리적이고 해피한 세상을 향해 살아가고 있으며, 책/교육/경제에 관심이 있습니다.
자유로운 삶을 추구하지만, 지금은 일에 매여 있습니다..

마케팅

김연아

에델만코리아 과장

유지수

이커머스

라이프스타일

패션 / 뷰티

식음료

커뮤니케이션 매니저

주거 / 부동산 / 프롭테크

커뮤니케이션 리드

언론학

공현주

브런치

인스타그램

10년차 커뮤니케이터. 브랜드의 말과 그릇을 고민합니다. 지금은 컬리에서 커뮤니케이션 매니저로 일하고 있습니다. 꾸준함은 재능이고 태도는 경쟁력이라 믿습니다.

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필