Hono is a web framework that is fast, lightweight, and built using the Web Standards API. Hear the story of Hono by the creator of Hono.

The story of web framework Hono, from the creator of Hono

Hono를 만든 Cloudflare 직원이 Hono를 소개하는 글입니다.

2021년에 Cloudflare의 Workers에서 애플리케이션을 만들려고 하다가 자신의 목적에 맞는 프레임워크가 없다는 것을 깨닫고 Trie 트리 기반 라우터로 웹 프레이웜크를 만들기 시작했다고 합니다. Hono는 웹 표준 API만 사용하기 때문에 모든 자바스크립트 런타임에서 실행할 수 있고 라우팅도 쉽게 작성할 수 있고 RPC를 사용하면 클라이언트까지도 쉽게 작성할 수 있습니다.

서버측 템플릿 엔진으로 여러 기술을 검토했지만 Workers와 호환성을 검토하다가 JSX를 떠올리고 JSX를 서버에서만 템플릿으로 사용하게 되었습니다.

Hono를 많이 들어봤지만 직접 써보지는 않다가 최근에 Hono에 대해서 더 많이 듣고 있는상황인데 그 만들어진 과정을 들으니 재밌게 읽었습니다.

https://blog.cloudflare.com/the-story-of-web-framework-hono-from-the-creator-of-hono/

Hono를 만든 Cloudflare 직원이 Hono를 소개하는 글입니다. 2021년에 Cloudflare의 Workers에서 애플리케이션을 만들려고 하다가 자신의 목적에 맞는 프레임워크가 없다는 것을 깨닫고 Trie 트리 기반 라우터로 웹 프레이웜크를 만들기 시작했다고 합니다. Hono는 웹 표준 API만 사용하기 때문에 모든 자바스크립트 런타임에서 실행할 수 있고 라우팅도 쉽게 작성할 수 있고 RPC를 사용하면 클라이언트까지도 쉽게 작성할 수 있습니다. 서버측 템플릿 엔진으로 여러 기술을 검토했지만 Workers와 호환성을 검토하다가 JSX를 떠올리고 JSX를 서버에서만 템플릿으로 사용하게 되었습니다. Hono를 많이 들어봤지만 직접 써보지는 않다가 최근에 Hono에 대해서 더 많이 듣고 있는상황인데 그 만들어진 과정을 들으니 재밌게 읽었습니다. https://blog.cloudflare.com/the-story-of-web-framework-hono-from-the-creator-of-hono/

The Cloudflare Blog

Redis는 Java 애플리케이션에서 캐싱, 세션 관리, 실시간 데이터 저장소로 자주 사용됩니다. Redis 클라이언트에서 데이터를 저장하거나 가져올 때, 데이터는 반드시 직렬화되어야 합니다. 직렬화 방식은 성능과 코드의 유지보수에 큰 영향을 미치기 때문에 잘 선택해야 합니다. 이번 포스팅에서는 Java에서 Redis 직렬화 시 자주 사용하는 방법들을 비교하고 각 방식의 특징과 예제를 설명합니다. JdkSerializationRedisSerializerJDK 기본 직렬화는 Java 표준 라이브러리에서 제공하는 java.io.Serializable 인터페이스를 사용하여 객체를 바이트 스트림으로 변환하는 방식입니다. 이 방식은 사용하기 편리하지만, 다소 무거운 오버헤드가 있을 수 있습니다.  장점:Java ..

Java Redis 직렬화 삼총사: Json, String, JDK

이번 포스팅에서는 Java에서 Redis 직렬화 시 자주 사용하는 방법들을 비교하고 각 방식의 특징과 예제를 설명합니다.
 
JdkSerializationRedisSerializer
JDK 기본 직렬화는 Java 표준 라이브러리에서 제공하는 java.io.Serializable 인터페이스를 사용하여 객체를 바이트 스트림으로 변환하는 방식입니다. 이 방식은 사용하기 편리하지만, 다소 무거운 오버헤드가 있을 수 있습니다. 
 
장점:
 * Java 내장 기능이라 별도의 라이브러리 필요 없음
 * 복잡한 객체 구조도 쉽게 직렬화 가능
단점:
 * 직렬화된 데이터가 상대적으로 큼
 * 직렬화/역직렬화 과정이 비교적 느림
public class RedisConfig {
 public RedisTemplate<String, Object> redisTemplate() {
 RedisTemplate<String, Object> template = new RedisTemplate<>();
 template.setValueSerializer(new JdkSerializationRedisSerializer());
 // 기타 설정
 return template;
 }
} 

저장되는 형태
127.0.0.1:6379> GET user:2
"\xac\xed\x00\x05sr\x00\x04User...\x78\x6f"

 
StringRedisSerializer
String 직렬화는 데이터를 문자열 형태로 저장하는 방식입니다. 이 방식은 간단하고 가볍기 때문에 기본적인 키-값 저장에 적합합니다. 직렬화 과정 없이 단순히 데이터를 문자열로 변환하여 Redis에 저장합니다.
 
장점:
 * 속도가 빠르고 갑벼움
 * 데이터가 사람이 읽을 수 있어 디버깅이 쉬움
단점:
 * 객체 직렬화에 비해 유연성이 떨어짐
 * 복잡한 데이터 구조에는 적합하지 않음 
import org.springframework.data.redis.serializer.StringRedisSerializer;
import org.springframework.data.redis.core.RedisTemplate;

public class RedisConfig {
 public RedisTemplate<String, String> redisTemplate() {
 RedisTemplate<String, String> template = new RedisTemplate<>();
 template.setKeySerializer(new StringRedisSerializer());
 template.setValueSerializer(new StringRedisSerializer());
 // 기타 설정
 return template;
 }
}

저장되는 형태
127.0.0.1:6379> GET message
"Hello, World!"

 
GenericJackson2JsonRedisSerializer
JSON 직렬화는 객체를 JSON 문자열로 변환하는 방식입니다. JSON은 가볍고 사람이 읽을 수 있으며 다양한 언어와 호환이 잘 됩니다. Jackson 라이브러리 등을 활용해 손쉽게 구현할 수 있습니다.
 
장점:
 * 데이터 포맷이 가볍고 사람이 읽기 쉬움
 * 다양한 언어 간 호환성 우수
 * 객체 타입을 손쉽게 복원 가능
단점:
 * 데이터 크기가 텍스트 기반이라 다소 클 수 있음
 * 이진 데이터보다는 느림
import org.springframework.data.redis.serializer.GenericJackson2JsonRedisSerializer;
import org.springframework.data.redis.core.RedisTemplate;

public class RedisConfig {
 public RedisTemplate<String, Object> redisTemplate() {
 RedisTemplate<String, Object> template = new RedisTemplate<>();
 template.setValueSerializer(new GenericJackson2JsonRedisSerializer());
 // 기타 설정
 return template;
 }
}

저장되는 형태
127.0.0.1:6379> GET user:1
"{\"@class\":\"com.example.User\",\"name\":\"Alice\",\"age\":25}"

 
케이스별 선택
 * 여러 언어와의 호환성: GenericJackson2JsonRedisSerializer 추천
 * 같은 언어(Java) 간 데이터 공유: GenericJackson2JsonRedisSerializer 또는 JdkSerializationRedisSerializer 추천
 * 단순 데이터: StringRedisSerializer 추천
 * 복잡한 객체 또는 Java 전용 데이터: JdkSerializationRedisSerializer (단, 모든 서비스가 Java인 경우에만)
 
저 같은 경우는 서로 다른 서비스에서 동일한 Redis 클러스터를 사용하고 있었습니다. 동일한 프로젝트가 아니었기에 JdkSerializationRedisSerializer은 사용할 수 없었고, 간단한 데이터도 아니었기에 String을 선택하기에도 어려웠습니다.
 
결국 GenericJackson2JsonRedisSerializer를 선택하였는데, 기본적으로 포함되는 @class 속성은 데이터의 타입 정보를 제공하지만, 다른 서비스에서 필요하지 않았습니다. 이를 비활성화하려면 ObjectMapper 설정을 통해 커스터마이징할 수 있습니다.

이번 포스팅에서는 Java에서 Redis 직렬화 시 자주 사용하는 방법들을 비교하고 각 방식의 특징과 예제를 설명합니다.&nbsp;JdkSerializationRedisSerializerJDK 기본 직렬화는 Java 표준 라이브러리에서 제공하는 java.io.Serializable 인터페이스를 사용하여 객체를 바이트 스트림으로 변환하는 방식입니다. 이 방식은 사용하기 편리하지만, 다소 무거운 오버헤드가 있을 수 있습니다.&nbsp;&nbsp;장점:<ul ><li>Java 내장 기능이라 별도의 라이브러리 필요 없음</li><li>복잡한 객체 구조도 쉽게 직렬화 가능</li></ul>단점:<ul ><li>직렬화된 데이터가 상대적으로 큼</li><li>직렬화/역직렬화 과정이 비교적 느림</li></ul><pre ><code class="language-java">public class RedisConfig {
 public RedisTemplate&lt;String, Object&gt; redisTemplate() {
 RedisTemplate&lt;String, Object&gt; template = new RedisTemplate&lt;&gt;();
 template.setValueSerializer(new JdkSerializationRedisSerializer());
 // 기타 설정
 return template;
 }
}&nbsp;</code></pre>저장되는 형태<pre ><code class="language-ruby">127.0.0.1:6379&gt; GET user:2
"\xac\xed\x00\x05sr\x00\x04User...\x78\x6f"</code></pre>&nbsp;StringRedisSerializerString 직렬화는 데이터를 문자열 형태로 저장하는 방식입니다. 이 방식은 간단하고 가볍기 때문에 기본적인 키-값 저장에 적합합니다. 직렬화 과정 없이 단순히 데이터를 문자열로 변환하여 Redis에 저장합니다.&nbsp;장점:<ul ><li>속도가 빠르고 갑벼움</li><li>데이터가 사람이 읽을 수 있어 디버깅이 쉬움</li></ul>단점:<ul ><li>객체 직렬화에 비해 유연성이 떨어짐</li><li>복잡한 데이터 구조에는 적합하지 않음&nbsp;</li></ul><pre ><code class="language-java">import org.springframework.data.redis.serializer.StringRedisSerializer;
import org.springframework.data.redis.core.RedisTemplate;

public class RedisConfig {
 public RedisTemplate&lt;String, String&gt; redisTemplate() {
 RedisTemplate&lt;String, String&gt; template = new RedisTemplate&lt;&gt;();
 template.setKeySerializer(new StringRedisSerializer());
 template.setValueSerializer(new StringRedisSerializer());
 // 기타 설정
 return template;
 }
}</code></pre>저장되는 형태<pre ><code class="language-ruby">127.0.0.1:6379&gt; GET message
"Hello, World!"</code></pre>&nbsp;GenericJackson2JsonRedisSerializerJSON 직렬화는 객체를 JSON 문자열로 변환하는 방식입니다. JSON은 가볍고 사람이 읽을 수 있으며 다양한 언어와 호환이 잘 됩니다. Jackson 라이브러리 등을 활용해 손쉽게 구현할 수 있습니다.&nbsp;장점:<ul ><li>데이터 포맷이 가볍고 사람이 읽기 쉬움</li><li>다양한 언어 간 호환성 우수</li><li>객체 타입을 손쉽게 복원 가능</li></ul>단점:<ul ><li>데이터 크기가 텍스트 기반이라 다소 클 수 있음</li><li>이진 데이터보다는 느림</li></ul><pre ><code class="language-java">import org.springframework.data.redis.serializer.GenericJackson2JsonRedisSerializer;
import org.springframework.data.redis.core.RedisTemplate;

public class RedisConfig {
 public RedisTemplate&lt;String, Object&gt; redisTemplate() {
 RedisTemplate&lt;String, Object&gt; template = new RedisTemplate&lt;&gt;();
 template.setValueSerializer(new GenericJackson2JsonRedisSerializer());
 // 기타 설정
 return template;
 }
}</code></pre>저장되는 형태<pre ><code class="language-ruby">127.0.0.1:6379&gt; GET user:1
"{\"@class\":\"com.example.User\",\"name\":\"Alice\",\"age\":25}"</code></pre>&nbsp;케이스별 선택<ul ><li>여러 언어와의 호환성: GenericJackson2JsonRedisSerializer 추천</li><li>같은 언어(Java) 간 데이터 공유: GenericJackson2JsonRedisSerializer 또는 JdkSerializationRedisSerializer 추천</li><li>단순 데이터: StringRedisSerializer 추천</li><li>복잡한 객체 또는 Java 전용 데이터: JdkSerializationRedisSerializer (단, 모든 서비스가 Java인 경우에만)</li></ul>&nbsp;저 같은 경우는 서로 다른 서비스에서 동일한 Redis 클러스터를 사용하고 있었습니다. 동일한 프로젝트가 아니었기에 JdkSerializationRedisSerializer은 사용할 수 없었고, 간단한 데이터도 아니었기에 String을 선택하기에도 어려웠습니다.&nbsp;결국 GenericJackson2JsonRedisSerializer를 선택하였는데, 기본적으로 포함되는 @class 속성은 데이터의 타입 정보를 제공하지만, 다른 서비스에서 필요하지 않았습니다. 이를 비활성화하려면 ObjectMapper 설정을 통해 커스터마이징할 수 있습니다.

덕토피아

🕊️ Java Redis직렬화 삼총사: Json, String, JDK

Java 만 쓰고 redis 용으로 직렬화를 한다면 protostuff 도 추천드립니다. 빠르고 별도 정의 없이 사용할 수 있어서요. 직렬화 결과물이 byte 라 사람이 볼 수는 없다는 소소한(?) 단점이 있겠습니다.

We really did this! We work in a very large Javascript monorepo at Microsoft we colloquially call 1JS. Using some new changes to the git client it went from 178GB to 5GB.

How we shrunk our Javascript monorepo git size by 94%

Microsoft 내부에서 1JS라고 부르는 엄청나게 큰 자바스크립트 모노 레포가 있다고 합니다. 이 모노 레포에는 2,500개의 패키지가 있고 코드 라인도 2,000만 라인이 넘어서면서 최근의 클론은 178GB나 되었습니다.

용량이 점점 커지면서 생산성에 문제가 되었기 때문에 너무 큰 파일을 올리거나 하는 등의 문제를 막기 위해서 여러 가지 방법을 시도해서 저장소가 커지는 속도는 느려졌지만 계속 커지고 있었다고 합니다. 그러던 중 Microsoft에서 가장 큰 모노레포인 Office보다도 커지가 뭔가 잘못되었다는 생각이 들었습니다.

내부에 Git에 기여하던 사람도 있어서 문제를 자세히 찾아본 결과 git에서 패킹할 때 파일명의 마지막 16자만 검사하기 로직으로 인해서 CHANGELOG.md 등 어디나 있을 만한 파일의 diff를 검사하면서 사실상 다른 파일과의 diff를 엄청나게 많이 만들고 있다는 것을 발견하고 git windows에 이를 수정해는 패치를 올리게 됩니다.

이 수정사항을 적용한 뒤에 git repack을 하자 178GB가 5GB로 줄어들었다고 합니다.

https://www.jonathancreamer.com/how-we-shrunk-our-git-repo-size-by-94-percent/

Microsoft 내부에서 1JS라고 부르는 엄청나게 큰 자바스크립트 모노 레포가 있다고 합니다. 이 모노 레포에는 2,500개의 패키지가 있고 코드 라인도 2,000만 라인이 넘어서면서 최근의 클론은 178GB나 되었습니다. 용량이 점점 커지면서 생산성에 문제가 되었기 때문에 너무 큰 파일을 올리거나 하는 등의 문제를 막기 위해서 여러 가지 방법을 시도해서 저장소가 커지는 속도는 느려졌지만 계속 커지고 있었다고 합니다. 그러던 중 Microsoft에서 가장 큰 모노레포인 Office보다도 커지가 뭔가 잘못되었다는 생각이 들었습니다. 내부에 Git에 기여하던 사람도 있어서 문제를 자세히 찾아본 결과 git에서 패킹할 때 파일명의 마지막 16자만 검사하기 로직으로 인해서 CHANGELOG.md 등 어디나 있을 만한 파일의 diff를 검사하면서 사실상 다른 파일과의 diff를 엄청나게 많이 만들고 있다는 것을 발견하고 git windows에 이를 수정해는 패치를 올리게 됩니다. 이 수정사항을 적용한 뒤에 git repack을 하자 178GB가 5GB로 줄어들었다고 합니다. https://www.jonathancreamer.com/how-we-shrunk-our-git-repo-size-by-94-percent/

Jonathan Creamer

유튜브 영상을 통해 본 분들도 있겠지만 일론 머스크는 다음과 같은 면접 질문을 통해 Exceptional Ability를 갖춘 사람을 찾으려 한다고 한다.

 * 인생 여정에 대해 말해달라는 걸로 시작해서
 * 그 과정에서 어떤 어려운 문제에 직면했으며
 * 그 문제를 어떻게 해결했고 어떤 결정을 내렸는가?

답변을 듣고 꼬리에 꼬리를 물고 계속해서 구체적이고 디테일한 질문을 통해 정말 본인이 한 것인지 아니면 남이 한 걸 본인이 한 것처럼 거짓말하는지도 알 수 있다고 한다. 인생 여정 이야기를 먼저 하는 이유는 그 사람에 대해 더 잘 알고 싶기도 하고 본인 이야기를 해야 좀더 다음 질문에 솔직하게 답변하게 되기 때문이 아닌가 싶다.

여러분들도 한번 위의 질문에 한번 본인이 자문자답해보면 어떨까 싶다. 특히 경력이 어느 정도 되는 분들이라면 어떤 문제를 해결보았고 그 과정에서 어떤 결정을 내렸는지 굉장히 의미있는 질문이다. 특히 "결정"이란 포인트가 중요하다. 커리어 초기에는 내가 결정을 내리기 보다는 남이 내린 결정에 맞춰 일을 하게 되지만 레벨이 올라가면서 결정을 내리는 역할을 하게 된다. 또 좋은 결과로 이루어진 결정만 의미가 있는 것이 아니다. 무엇을 배웠고 다음 번에는 이렇게 다르게 해보겠다는 것도 충분히 좋은 답변이다.

여담으로 X에서 일하는 지인에게 일론 머스크가 CEO가 된 뒤에 무엇이 변했는지 물어보았다.

 * 엔지니어의 수를 25% 밑으로 줄였고 레벨의 수를 확 줄여서 이제는 말단 개발자에서 세번 올라가면 일론 머스크라고 한다. 이제 트럼프가 미국 대통령이 되면서 일론 머스크가 정부 효율성을 높이는 일을 맡을 꺼라고 하던데 칼바람이 불 가능성이 높다. 25%로 줄였음에도 불구하고 전체적인 성과는 좋아졌으면 좋아졌지 나빠지지 않았다고 한다. 어쩌면 파킨슨의 법칙이 적용되고 있었는지도 모르겠다. 파킨슨의 법칙은 주어진 업무는 그 일을 처리할 수 있는 시간만큼 늘어나게 되며 사람이 있는만큼 더 바빠지는 현상을 말한다.
 * 구글 클라우드에서 X 서비스가 돌고 있었는데 그걸 클라우드 바깥(On-Premise)으로 이전하는 프로젝트를 진행 중이라 한다. 다들 클라우드에서 도는 세상에 비용을 이슈로 클라우드 이전 세상으로 돌아가는 셈인데 이 역시 일론 머스크가 아니라면 할 수 없는 결정이 아닌가 싶다.

유튜브 영상을 통해 본 분들도 있겠지만 일론 머스크는 다음과 같은 면접 질문을 통해 Exceptional Ability를 갖춘 사람을 찾으려 한다고 한다. <ul ><li>인생 여정에 대해 말해달라는 걸로 시작해서</li><li>그 과정에서 어떤 어려운 문제에 직면했으며</li><li>그 문제를 어떻게 해결했고 어떤 결정을 내렸는가?</li></ul> 답변을 듣고 꼬리에 꼬리를 물고 계속해서 구체적이고 디테일한 질문을 통해 정말 본인이 한 것인지 아니면 남이 한 걸 본인이 한 것처럼 거짓말하는지도 알 수 있다고 한다. 인생 여정 이야기를 먼저 하는 이유는 그 사람에 대해 더 잘 알고 싶기도 하고 본인 이야기를 해야 좀더 다음 질문에 솔직하게 답변하게 되기 때문이 아닌가 싶다. 여러분들도 한번 위의 질문에 한번 본인이 자문자답해보면 어떨까 싶다. 특히 경력이 어느 정도 되는 분들이라면 어떤 문제를 해결보았고 그 과정에서 어떤 결정을 내렸는지 굉장히 의미있는 질문이다. 특히 "결정"이란 포인트가 중요하다. 커리어 초기에는 내가 결정을 내리기 보다는 남이 내린 결정에 맞춰 일을 하게 되지만 레벨이 올라가면서 결정을 내리는 역할을 하게 된다. 또 좋은 결과로 이루어진 결정만 의미가 있는 것이 아니다. 무엇을 배웠고 다음 번에는 이렇게 다르게 해보겠다는 것도 충분히 좋은 답변이다. 여담으로 X에서 일하는 지인에게 일론 머스크가 CEO가 된 뒤에 무엇이 변했는지 물어보았다. <ul ><li>엔지니어의 수를 25% 밑으로 줄였고 레벨의 수를 확 줄여서 이제는 말단 개발자에서 세번 올라가면 일론 머스크라고 한다. 이제 트럼프가 미국 대통령이 되면서 일론 머스크가 정부 효율성을 높이는 일을 맡을 꺼라고 하던데 칼바람이 불 가능성이 높다. 25%로 줄였음에도 불구하고 전체적인 성과는 좋아졌으면 좋아졌지 나빠지지 않았다고 한다. 어쩌면 파킨슨의 법칙이 적용되고 있었는지도 모르겠다. 파킨슨의 법칙은 주어진 업무는 그 일을 처리할 수 있는 시간만큼 늘어나게 되며 사람이 있는만큼 더 바빠지는 현상을 말한다.</li><li>구글 클라우드에서 X 서비스가 돌고 있었는데 그걸 클라우드 바깥(On-Premise)으로 이전하는 프로젝트를 진행 중이라 한다. 다들 클라우드에서 도는 세상에 비용을 이슈로 클라우드 이전 세상으로 돌아가는 셈인데 이 역시 일론 머스크가 아니라면 할 수 없는 결정이 아닌가 싶다.</li></ul>

일론 머스크의 면접 질문

야후 다닐 때 매니지먼트 트랙으로 간 다음부터 매해 연말이 되면 1월에 있을 직원 연간 평가를 앞두고 엄청난 스트레스를 받았다. 그 이유는 내 팀원들 평가하는 걸로 끝이 아니고 팀원들을 레벨별로 잘하는 순서대로 소팅을 한 다음에 다른 동료 매니저들과 만나서 전체적으로 소팅을 하는 과정을 거쳐야만 했기 때문이다.

여기서 앞서 이야기한 레벨별로 팀원들을 고과기준으로 최고 성과자부터 최저 성과자로 정렬하는 방식의 평가를 Stack Ranking이라고 부른다. 마이크로소프트도 같은 방식을 택하는 걸로 알고 있는데 지금도 그런지는 모르겠다. 보통 이 방식에 최하위 평가를 받은 사람들은 연봉인상이 없고 회사에 따라서는 해고 대상자가 되면서 PIP(Performance Improvement Plan)에 들어가는 경우들도 많다. 이 자체도 스트레스지만 그때 많이 깨달은 포인트는 미리 피드백을 많이 솔직하게 주는 것이 중요하다는 점이었다. 앞단에 미리 불편한 대화를 많이 나누는 것이 나중에 큰 충돌을 방지하는데 큰 도움이 되었다.

다음으로 Calibration은 동료 매니저들과 상위 매니저와 조직 담당 HRBP(HR Business Partner)가 모여 각 팀의 고과에 따라 정렬된 인원들을 레벨 별로 하나의 순서로 통합하는 과정을 말한다. 개발자들에게 익숙한 머지 소트라고 보면 된다 :) 이때 미리 고과 레벨별로 퍼센트를 정해놓게 진행하는 것이 일반적이다.

 * Top Performer: 10%
 * Above Average: 25%
 * Average: 60%
 * Below Average: 5%

동료 매니저들과 상위 매니저가 같이 다양한 관점에서 개인에 대한 평을 공유하게 되기 때문에 평소 협업을 하는 태도나 의사 소통 능력도 기술적인 능력만큼 중요해진다. 내가 아무리 특정 개인을 좋게 평가해도 다른 매니저들이 동의하지 않는다면 좋은 평가를 줄 수가 없다. 그래서 평소에 동료 매니저들과 주기적인 일대일 미팅을 통해 팀원들에 대한 평을 서로 공유하는 것이 좋다.

이 Calibration 과정은 몇 시간씩 여러 번의 회의를 통해 열띤 토론으로 이루어지게 되며 가장 스트레스받는 순간이다. 보통 일주일내내 모여서 이야기하고 어떤 날은 하루 다 블록해놓고 논의하기도 하고 어떤 날은 밤 늦게까지 이어지기도 한다. 그러다보면 사이가 멀어지고 불편해지는 동료 매니저가 생기기도 한다. 대상 인원이 많은 경우 모든 사람들을 놓고 의견을 공유하기는 힘들어서 보통은 고성과자와 저성과자와 승진 대상자를 놓고 대부분의 시간을 보낸다. 이 과정은 처음에도 힘들었지만 시간이 지난다고 딱히 더 편해지지는 않았다 :)

야후 다닐 때 매니지먼트 트랙으로 간 다음부터 매해 연말이 되면 1월에 있을 직원 연간 평가를 앞두고 엄청난 스트레스를 받았다. 그 이유는 내 팀원들 평가하는 걸로 끝이 아니고 팀원들을 레벨별로 잘하는 순서대로 소팅을 한 다음에 다른 동료 매니저들과 만나서 전체적으로 소팅을 하는 과정을 거쳐야만 했기 때문이다. 여기서 앞서 이야기한 레벨별로 팀원들을 고과기준으로 최고 성과자부터 최저 성과자로 정렬하는 방식의 평가를 Stack Ranking이라고 부른다. 마이크로소프트도 같은 방식을 택하는 걸로 알고 있는데 지금도 그런지는 모르겠다. 보통 이 방식에 최하위 평가를 받은 사람들은 연봉인상이 없고 회사에 따라서는 해고 대상자가 되면서 PIP(Performance Improvement Plan)에 들어가는 경우들도 많다. 이 자체도 스트레스지만 그때 많이 깨달은 포인트는 미리 피드백을 많이 솔직하게 주는 것이 중요하다는 점이었다. 앞단에 미리 불편한 대화를 많이 나누는 것이 나중에 큰 충돌을 방지하는데 큰 도움이 되었다. 다음으로 Calibration은 동료 매니저들과 상위 매니저와 조직 담당 HRBP(HR Business Partner)가 모여 각 팀의 고과에 따라 정렬된 인원들을 레벨 별로 하나의 순서로 통합하는 과정을 말한다. 개발자들에게 익숙한 머지 소트라고 보면 된다 :) 이때 미리 고과 레벨별로 퍼센트를 정해놓게 진행하는 것이 일반적이다. <ul ><li>Top Performer: 10%</li><li>Above Average: 25%</li><li>Average: 60%</li><li>Below Average: 5%</li></ul> 동료 매니저들과 상위 매니저가 같이 다양한 관점에서 개인에 대한 평을 공유하게 되기 때문에 평소 협업을 하는 태도나 의사 소통 능력도 기술적인 능력만큼 중요해진다. 내가 아무리 특정 개인을 좋게 평가해도 다른 매니저들이 동의하지 않는다면 좋은 평가를 줄 수가 없다. 그래서 평소에 동료 매니저들과 주기적인 일대일 미팅을 통해 팀원들에 대한 평을 서로 공유하는 것이 좋다. 이 Calibration 과정은 몇 시간씩 여러 번의 회의를 통해 열띤 토론으로 이루어지게 되며 가장 스트레스받는 순간이다. 보통 일주일내내 모여서 이야기하고 어떤 날은 하루 다 블록해놓고 논의하기도 하고 어떤 날은 밤 늦게까지 이어지기도 한다. 그러다보면 사이가 멀어지고 불편해지는 동료 매니저가 생기기도 한다. 대상 인원이 많은 경우 모든 사람들을 놓고 의견을 공유하기는 힘들어서 보통은 고성과자와 저성과자와 승진 대상자를 놓고 대부분의 시간을 보낸다. 이 과정은 처음에도 힘들었지만 시간이 지난다고 딱히 더 편해지지는 않았다 :)

실리콘밸리의 평가방식 - Stack Ranking과 Calibration

어제 유튜브 라이브에서 했던 이야기 중 하나가 실리콘밸리 혹은 미국 IT 회사에서 일하는 인력이 받는 보상 구조에 관한 것이다. 미국 IT 기업 인력은 풀타임인 경우 Exempt Employee라해서 업무 시간이 주 40시간이 넘어가도 초과 근무수당이 없다. Non Exempt Employee라고 하면 보통 파트타임이거나 비정규직으로 40시간이 넘어갈 때 초과 근무 수당을 받게 된다. 다르게 이야기하면 풀타임인 경우 초과 근무한다고 해도 수당을 더 받거나 하는 일은 없다. 하지만 내 경험상 한국 회사 직원들과 비교하면 미국 인력들이 더 오랜 시간 일을 한다. 예를 들면 주말이나 저녁 시간에도 이메일이나 메신저로 대화가 오고 간다. 왜 그럴까? 앞서 노동법적인 것도 있지만 기본적으로 일의 성과에 따라 보상의 크기에 큰 차등이 있고 회사 주식이 보상의 일부이기 때문이 아닌가 싶다. 실리콘 밸리에서 일하는 사람들의 노동시간은 한국보다 훨씬 길다. 그 이유는 간단하다. 노동법 상으로 제약이 없기 때문이면서 기본적으로는 일을 잘 하는 사람에게 보상을 몰아주는 구조이기 때문이다.

미국 IT 회사의 보상은 기본적으로 아래 3가지 요소로 구성이 된다.

 * 연봉
 * 보너스
 * 주식

물론 작은 회사라면 보너스는 처음에 없다. 내가 다녔던 7개 스타트업들 중에 보너스를 주었던 곳은 아무 곳도 없었다. 또한 스타트업 관점에서는 어느 정도 성장하기 전까지는 주식도 가치를 알기 힘든 종이 조각에 가깝다. 하지만 상장을 한 회사이거나 크게 성장한 스타트업이라면 모두 위 3가지로 보상을 구성하며 이를 보통 Total Compensation이라고 부르며 줄여서 Total Comp라고 부르기도 한다. 한국은 대기업이라 해도 대부분 주식을 주지는 않는다. 이는 미국에 진출한 한국 대기업들도 마찬가지인데 주식을 못 주다보니 보너스나 연봉 등을 조금더 주려고는 하지만 좋은 인력의 채용이란 관점에서는 경쟁력이 떨어지는 것은 사실이다.

먼저 연봉이나 보너스의 경우 한국은 좀더 균등하게 나눠먹기 식이라면 조금은 집단주의적인 경향이 있다면 미국은 개인의 성과에 따라 (물론 회사와 조직의 성과가 있어야 한다) 확연히 다르게 나눠주는 경향이 있다. 몇 년전 한국 모 대기업과 컨설팅할 때 느낀 점은 이렇게 보너스를 나눠준다면 누가 과연 열심히 일할까 싶다는 거였다.

주식 같은 경우는 Stock Option이 보통 작은 스타트업에서는 일반적이고 어느 성장을 해서 가치가 인정이 되기 시작하면 Secondary Market과 같은 장외 시장에서 거래가 되기 시작하면 많은 회사들이 Stock Option이 아닌 RSU (Restricted Stock Units)이란 형태로 주식을 주기 시작한다. Stock Option과 RSU간에는 큰 차이가 있다.

개인 관점에서 보면 Stock Option은 정해진 가격으로 정해진 시간 후에 주식을 살 수 있는 권한을 이야기하는 것이며 언제 사고 파느냐에 따라 long-term capital gain이 되면서 세금을 덜 내도 된다는 장점이 있지만 휴지조각이 될 수도 있다는 단점이 존재한다. RSU라고 무조건 돈이 되는 건 아니지만 기본적으로는 정해진 시간 후에 그날 주식 가격에 맞춰 미리 정해진 수의 주식이 바로 내 소득이 잡힌다. 이는 short-term capital gain이 되기에 세율에 있어서 stock option과 같은 장점이 존재하지는 않는다. 주식의 경우 계약하기에 따라 Early exercise나 Single-trigger, double-trigger 같은 조항을 걸 수 있기도 한데 이는 회사에서 정말 탐내는 인력인 경우 가능한 예외 조항들에 가깝다.

앞서 연봉, 보너스, 주식 이외에도 보상에 영향을 주는 요소들로는 개인연금을 회사에서 매칭해주는 401K employer match 퍼센트나 우리 사주 형태로 stock option이나 RSU와는 다르게 회사 주식을 싸게 살 수 있는 ESPP(Employee Stock Purchase Plan) 같은 것이 있다. 한국에 있는데 미국에는 없는 걸로 퇴직금을 들 수 있다. 미국의 경우 퇴사시 사용하지 않은 휴가가 있다면 이걸 돈으로 환산해주기는 하는데 무한 휴가 제도를 사용하는 곳이라면 이 역시 해당 사항이 없다.

혹시 이에 대해 궁금한 점들이 있다면 댓글로 질문 요망! 유튜브 라이브 영상 링크도 댓들에 걸어 놓았으니 참고. 다음 글은 미국 IT 회사들에서 개인을 평가하는 방식에 대해 이야기해보고자 한다.

어제 유튜브 라이브에서 했던 이야기 중 하나가 실리콘밸리 혹은 미국 IT 회사에서 일하는 인력이 받는 보상 구조에 관한 것이다. 미국 IT 기업 인력은 풀타임인 경우 Exempt Employee라해서 업무 시간이 주 40시간이 넘어가도 초과 근무수당이 없다. Non Exempt Employee라고 하면 보통 파트타임이거나 비정규직으로 40시간이 넘어갈 때 초과 근무 수당을 받게 된다. 다르게 이야기하면 풀타임인 경우 초과 근무한다고 해도 수당을 더 받거나 하는 일은 없다. 하지만 내 경험상 한국 회사 직원들과 비교하면 미국 인력들이 더 오랜 시간 일을 한다. 예를 들면 주말이나 저녁 시간에도 이메일이나 메신저로 대화가 오고 간다. 왜 그럴까? 앞서 노동법적인 것도 있지만 기본적으로 일의 성과에 따라 보상의 크기에 큰 차등이 있고 회사 주식이 보상의 일부이기 때문이 아닌가 싶다. 실리콘 밸리에서 일하는 사람들의 노동시간은 한국보다 훨씬 길다. 그 이유는 간단하다. 노동법 상으로 제약이 없기 때문이면서 기본적으로는 일을 잘 하는 사람에게 보상을 몰아주는 구조이기 때문이다. 미국 IT 회사의 보상은 기본적으로 아래 3가지 요소로 구성이 된다. <ul ><li>연봉</li><li>보너스</li><li>주식</li></ul> 물론 작은 회사라면 보너스는 처음에 없다. 내가 다녔던 7개 스타트업들 중에 보너스를 주었던 곳은 아무 곳도 없었다. 또한 스타트업 관점에서는 어느 정도 성장하기 전까지는 주식도 가치를 알기 힘든 종이 조각에 가깝다. 하지만 상장을 한 회사이거나 크게 성장한 스타트업이라면 모두 위 3가지로 보상을 구성하며 이를 보통 Total Compensation이라고 부르며 줄여서 Total Comp라고 부르기도 한다. 한국은 대기업이라 해도 대부분 주식을 주지는 않는다. 이는 미국에 진출한 한국 대기업들도 마찬가지인데 주식을 못 주다보니 보너스나 연봉 등을 조금더 주려고는 하지만 좋은 인력의 채용이란 관점에서는 경쟁력이 떨어지는 것은 사실이다. 먼저 연봉이나 보너스의 경우 한국은 좀더 균등하게 나눠먹기 식이라면 조금은 집단주의적인 경향이 있다면 미국은 개인의 성과에 따라 (물론 회사와 조직의 성과가 있어야 한다) 확연히 다르게 나눠주는 경향이 있다. 몇 년전 한국 모 대기업과 컨설팅할 때 느낀 점은 이렇게 보너스를 나눠준다면 누가 과연 열심히 일할까 싶다는 거였다. 주식 같은 경우는 Stock Option이 보통 작은 스타트업에서는 일반적이고 어느 성장을 해서 가치가 인정이 되기 시작하면 Secondary Market과 같은 장외 시장에서 거래가 되기 시작하면 많은 회사들이 Stock Option이 아닌 RSU (Restricted Stock Units)이란 형태로 주식을 주기 시작한다. Stock Option과 RSU간에는 큰 차이가 있다. 개인 관점에서 보면 Stock Option은 정해진 가격으로 정해진 시간 후에 주식을 살 수 있는 권한을 이야기하는 것이며 언제 사고 파느냐에 따라 long-term capital gain이 되면서 세금을 덜 내도 된다는 장점이 있지만 휴지조각이 될 수도 있다는 단점이 존재한다. RSU라고 무조건 돈이 되는 건 아니지만 기본적으로는 정해진 시간 후에 그날 주식 가격에 맞춰 미리 정해진 수의 주식이 바로 내 소득이 잡힌다. 이는 short-term capital gain이 되기에 세율에 있어서 stock option과 같은 장점이 존재하지는 않는다. 주식의 경우 계약하기에 따라 Early exercise나 Single-trigger, double-trigger 같은 조항을 걸 수 있기도 한데 이는 회사에서 정말 탐내는 인력인 경우 가능한 예외 조항들에 가깝다. 앞서 연봉, 보너스, 주식 이외에도 보상에 영향을 주는 요소들로는 개인연금을 회사에서 매칭해주는 401K employer match 퍼센트나 우리 사주 형태로 stock option이나 RSU와는 다르게 회사 주식을 싸게 살 수 있는 ESPP(Employee Stock Purchase Plan) 같은 것이 있다. 한국에 있는데 미국에는 없는 걸로 퇴직금을 들 수 있다. 미국의 경우 퇴사시 사용하지 않은 휴가가 있다면 이걸 돈으로 환산해주기는 하는데 무한 휴가 제도를 사용하는 곳이라면 이 역시 해당 사항이 없다. 혹시 이에 대해 궁금한 점들이 있다면 댓글로 질문 요망! 유튜브 라이브 영상 링크도 댓들에 걸어 놓았으니 참고. 다음 글은 미국 IT 회사들에서 개인을 평가하는 방식에 대해 이야기해보고자 한다.

실리콘 밸리 인력 보상 구조 - 왜 실리콘 밸리 사람들은 일을 많이 할까

커리어 Q&A: 일대일 미팅, 평가/보상, 매니저 업 등등: https://youtube.com/live/E8vZiSHVP-c

Hibernate 는 지연 로딩, 캐싱, 쿼리 순서 최적화 등 개발자가 애플리케이션 개발에만 집중할 수 있도록 여러가지 편의 기능을 제공합니다. 저는 오늘 이 ‘편의 기능’ 때문에 ‘불편해진’ 경험들에 대해 이야기 해보려 합니다.

Hibernate 의 ‘불편한’ 편의 기능들

JPA(Hibernate)를 사용하면서 생긴 불평불만들
Hibernate 는 정말 좋은 프레임워크일까?
https://medium.com/@hyeon9mak/hibernate-%EC%9D%98-%EB%B6%88%ED%8E%B8%ED%95%9C-%ED%8E%B8%EC%9D%98-%EA%B8%B0%EB%8A%A5%EB%93%A4-06a1fbc7492a

JPA(Hibernate)를 사용하면서 생긴 불평불만들Hibernate 는 정말 좋은 프레임워크일까?https://medium.com/@hyeon9mak/hibernate-%EC%9D%98-%EB%B6%88%ED%8E%B8%ED%95%9C-%ED%8E%B8%EC%9D%98-%EA%B8%B0%EB%8A%A5%EB%93%A4-06a1fbc7492a

Medium

개인적으로는 jpa가 충분한 지식 없이 그대로 쓰기에는 너무 불편하다고 느꼈습니다 그러나 그럼에도 불구하고 사용하는 큰 이유는 타입세이프 하다는 점과 쿼리나 테이블정보 등을 객체로 관리할수 있다는게 큰 장점으로 다가왔습니다 물론 쉽게 쓰고 빨리퇴근하려고 사용하시는 분들도 있겠지만 모든 프레임워크도 사용하려면 사용법을 알고 쓰는게 당연하다고 생각됩니다.

Why Engineers Need To Write

여러분은 엔지니어로서 글쓰기를 얼마나 중요하게 생각하시나요? 코딩 역시도 잘 생각해보면 컴퓨터와 소통하기 위한 글쓰기 인데, 다른 개발자들과의 원활한 소통을 위해 내 생각을 글로 잘 쓰는것 역시 점점 더 중요해져가고 있는 것 같습니다.

 * 글쓰기는 곧 일의 일부
   * 중급 엔지니어로 성장하면서 글쓰기가 업무에서 큰 비중을 차지하게 됩니다.
   * 기술적인 질문을 던지고, 코드 리뷰를 하고, 디자인 문서를 작성하는 등 글쓰기는 협업의 핵심 요소로 자리 잡습니다.
   * 특히 코로나 이후 비대면 문화가 강화되면서, 비동기적 소통을 위한 문서화가 필수가 되었습니다.
     
     
 * 글쓰기는 자기 확장의 도구
   * 글쓰기를 통해 자신의 지식을 팀에 공유하면, 팀 전체의 생산성이 높아집니다.
   * 예를 들어, 동료의 작업 노트가 위키 형태로 팀원들에게 공유되면서 효율성을 높이는 사례가 있습니다.
   * 직접 코드를 작성하는 데 한계가 있지만, 글쓰기를 통해 팀을 더 빠르고 효과적으로 움직이게 하는 영향력을 발휘할 수 있습니다.

 * 글쓰기는 사고력을 강화한다
   * 글을 쓰면서 생각을 구조화하고 논리적으로 정리할 수 있습니다.
   * 디자인 문서를 작성하면서 새로운 최적화 방법이나 문제점을 발견하는 경우도 많습니다.
   * 이는 단순히 기존의 아이디어를 명확히 하는 것을 넘어, 새로운 아이디어를 창출하는 과정이 됩니다.

 * AI 시대에도 글쓰기의 가치는 여전하다
   * ChatGPT 같은 도구가 글쓰기를 대신할 수 있어도, 스스로 생각을 글로 표현하는 능력은 중요합니다.
   * 글쓰기는 단순한 작업이 아니라 사고를 논리적이고 깊이 있게 만들며, 이를 통해 더 나은 결정을 내리게 해줍니다.

여러분은 일상 업무에서 글쓰기를 얼마나 활용하고 계신가요? 팀과의 협업을 강화하기 위해 어떤 글쓰기 습관을 도입해볼 수 있을까요? :)

https://www.developing.dev/p/why-engineers-need-to-write

여러분은 엔지니어로서 글쓰기를 얼마나 중요하게 생각하시나요? 코딩 역시도 잘 생각해보면 컴퓨터와 소통하기 위한 글쓰기 인데, 다른 개발자들과의 원활한 소통을 위해 내 생각을 글로 잘 쓰는것 역시 점점 더 중요해져가고 있는 것 같습니다. <ul ><li>글쓰기는 곧 일의 일부<ul ><li>중급 엔지니어로 성장하면서 글쓰기가 업무에서 큰 비중을 차지하게 됩니다.</li><li>기술적인 질문을 던지고, 코드 리뷰를 하고, 디자인 문서를 작성하는 등 글쓰기는 협업의 핵심 요소로 자리 잡습니다.</li><li>특히 코로나 이후 비대면 문화가 강화되면서, 비동기적 소통을 위한 문서화가 필수가 되었습니다. </li></ul></li><li>글쓰기는 자기 확장의 도구<ul ><li>글쓰기를 통해 자신의 지식을 팀에 공유하면, 팀 전체의 생산성이 높아집니다.</li><li>예를 들어, 동료의 작업 노트가 위키 형태로 팀원들에게 공유되면서 효율성을 높이는 사례가 있습니다.</li><li>직접 코드를 작성하는 데 한계가 있지만, 글쓰기를 통해 팀을 더 빠르고 효과적으로 움직이게 하는 영향력을 발휘할 수 있습니다.</li></ul></li></ul> <ul ><li>글쓰기는 사고력을 강화한다<ul ><li>글을 쓰면서 생각을 구조화하고 논리적으로 정리할 수 있습니다.</li><li>디자인 문서를 작성하면서 새로운 최적화 방법이나 문제점을 발견하는 경우도 많습니다.</li><li>이는 단순히 기존의 아이디어를 명확히 하는 것을 넘어, 새로운 아이디어를 창출하는 과정이 됩니다.</li></ul></li></ul> <ul ><li>AI 시대에도 글쓰기의 가치는 여전하다<ul ><li>ChatGPT 같은 도구가 글쓰기를 대신할 수 있어도, 스스로 생각을 글로 표현하는 능력은 중요합니다.</li><li>글쓰기는 단순한 작업이 아니라 사고를 논리적이고 깊이 있게 만들며, 이를 통해 더 나은 결정을 내리게 해줍니다.</li></ul></li></ul> 여러분은 일상 업무에서 글쓰기를 얼마나 활용하고 계신가요? 팀과의 협업을 강화하기 위해 어떤 글쓰기 습관을 도입해볼 수 있을까요? :) https://www.developing.dev/p/why-engineers-need-to-write

www.developing.dev

개발자가 글을 써야 하는 이유

코드에 주석을 많이 달아주는 사람이 좋아요

3 Lessons from the Smartest Developers I’ve Worked With

여러분은 뛰어난 개발자들과의 경험을 통해 어떤 깨달음을 얻었나요? 이 글은 저자가 세 명의 비범한 동료 개발자들에게 배운 교훈을 통해 어떻게 성장했는지를 보여줍니다. 그들은 기술적 전문성과 함께 삶과 일에 대한 새로운 태도를 엿볼수 있네요!

1. 테스트와 도구 활용의 중요성
 * "Don"과의 페어 프로그래밍에서 저자는 테스트 없는 코드를 피하고 철저하게 테스트하는 법을 배웠습니다.
 * "VS Code 단축키를 익라"는 그의 요구는 생산성을 높이는 데 큰 도움이 되었습니다.
 * "기능이 작동만 하면 된다"는 사고에서 벗어나, 올바르게 작동하도록 만드는 것의 가치를 깨달았습니다.

2. 코드 리뷰의 철저함
 * 초반엔 저자가 작성한 코드가 항상 "Looks good to me!"라는 대충 검토로 넘어갔지만, Parker는 이를 단호히 바로잡았습니다.
 * 철저한 코드 리뷰 프로세스
   1. 코드를 로컬 환경에서 실행해 기능을 먼저 검증.
   2. 코드 라인별 검토로 새로운 부분을 이해.
   3. 불명확한 부분은 질문을 통해 명확히 함.
   4. 큰 리뷰는 개발자와 직접 만나 설명 듣기.
   5. 맥락 전환을 막기 위해, 오전에 리뷰 진행.
 * 이 과정 덕분에 저자는 "팀 내에서 인정받는 리뷰어"로 성장할 수 있었습니다.
   
   
3. 비즈니스 목표와 기술 선택의 연결
 * 초기에는 최신 기술(Next.js, TypeScript 등)을 도입하려 했지만, James는 "이것이 비즈니스에 어떤 가치를 주는가?"라는 본질적인 질문을 던졌습니다.
 * 이 질문 통해 기술적 욕심을 내려놓고, 비즈니스 목표와 관련된 문제를 해결하도록 도와주었습니다.
   
   
성장의 열쇠는 불편함 속에서 찾아라
 * 테스트와 도구 활용을 배우며 기본기를 탄탄히!
 * 철저한 코드 리뷰를 통한 동료들과의 든든한 신뢰 !
 * 기술과 비즈니스 목표를 연결하는 사고방식!

---

여러분의 팀원들로부터 배우고 적용한 경험은 무엇인가요? 지금 함께하는 동료와 어떤 새로운 교훈을 나눌 수 있을지 고민해보는 것은 어떨까요?

https://brianjenney.medium.com/3-lessons-from-the-smartest-developers-ive-worked-with-5b233f51fc15

여러분은 뛰어난 개발자들과의 경험을 통해 어떤 깨달음을 얻었나요? 이 글은 저자가 세 명의 비범한 동료 개발자들에게 배운 교훈을 통해 어떻게 성장했는지를 보여줍니다. 그들은 기술적 전문성과 함께 삶과 일에 대한 새로운 태도를 엿볼수 있네요! 1. 테스트와 도구 활용의 중요성<ul ><li>"Don"과의 페어 프로그래밍에서 저자는 테스트 없는 코드를 피하고 철저하게 테스트하는 법을 배웠습니다.</li><li>"VS Code 단축키를 익라"는 그의 요구는 생산성을 높이는 데 큰 도움이 되었습니다.</li><li>"기능이 작동만 하면 된다"는 사고에서 벗어나, 올바르게 작동하도록 만드는 것의 가치를 깨달았습니다.</li></ul> 2. 코드 리뷰의 철저함<ul ><li>초반엔 저자가 작성한 코드가 항상 "Looks good to me!"라는 대충 검토로 넘어갔지만, Parker는 이를 단호히 바로잡았습니다.</li><li>철저한 코드 리뷰 프로세스<ol ><li>코드를 로컬 환경에서 실행해 기능을 먼저 검증.</li><li>코드 라인별 검토로 새로운 부분을 이해.</li><li>불명확한 부분은 질문을 통해 명확히 함.</li><li>큰 리뷰는 개발자와 직접 만나 설명 듣기.</li><li>맥락 전환을 막기 위해, 오전에 리뷰 진행.</li></ol></li><li>이 과정 덕분에 저자는 "팀 내에서 인정받는 리뷰어"로 성장할 수 있었습니다. </li></ul>3. 비즈니스 목표와 기술 선택의 연결<ul ><li>초기에는 최신 기술(Next.js, TypeScript 등)을 도입하려 했지만, James는 "이것이 비즈니스에 어떤 가치를 주는가?"라는 본질적인 질문을 던졌습니다.</li><li>이 질문 통해 기술적 욕심을 내려놓고, 비즈니스 목표와 관련된 문제를 해결하도록 도와주었습니다. </li></ul>성장의 열쇠는 불편함 속에서 찾아라<ul ><li>테스트와 도구 활용을 배우며 기본기를 탄탄히!</li><li>철저한 코드 리뷰를 통한 동료들과의 든든한 신뢰 ! </li><li>기술과 비즈니스 목표를 연결하는 사고방식!</li></ul> --- 여러분의 팀원들로부터 배우고 적용한 경험은 무엇인가요? 지금 함께하는 동료와 어떤 새로운 교훈을 나눌 수 있을지 고민해보는 것은 어떨까요? https://brianjenney.medium.com/3-lessons-from-the-smartest-developers-ive-worked-with-5b233f51fc15

최고의 개발자들에게 배운 3가지 교훈

사소한 부분이지만 좋은 아티클에 한 가지 오타가 있어 말씀드려요 😄 “VS Code 단축키를 익라” 대신 “VS Code 단축키를 익혀라“가 더 자연스러울 것 같아요! 좋은 내용 공유 감사합니다 !!

나보다 시니어가 질문을 했는데 어떻게 답을 해야할지 잘 모르겠고, 그 상황이 두려움으로 느껴진 적 있으신가요? 그냥 그 상황을 도망치고만 싶을 때 어떻게 했었나요?

압박감 속에서도 침착함을 유지하기 위한 BAA 프레임워크(Breath, Assess, Act / 호흡하기, 파악하기, 행동하기)를 소개합니다. 각 단계에서 차분히 상황을 다루며 신중한 결정을 내리는 방법을 체계적으로 연습해 볼 수 있습니다.

예제 상황 1.
상위 결정자들에게 프로젝트 프레젠테이션 부사장님이 중 다음과 같은 질문을 합니다.
“왜 Feature X를 개발하지 않나요? 왜 Feature Y에 집중하죠?”

 * 두려움의 이유
   * 권위 있는 인물에게 "잘못된 답변"을 하는 것에 대한 두려움.
   * 과거 합의된 결정이 잘못된 것으로 드러날까 봐의 불안.
   * 상사에게 “아니오”라고 말하기 꺼려지는 심리적 부담.

 * BAA 적용하기
   * Breath: 심호흡으로 긴장을 풀고 직함의 위압감을 잊습니다.
   * Assess: 질문 의도와 가정을 파악합니다.
     * “Feature X는 이전 리뷰에서 불필요하다고 결론 내렸습니다. 현재 Feature Y가 사용자 연구에서 더 가치 있는 것으로 나타났습니다. 다시 검토할 필요가 있나요?”
   * Act: 상대방의 어조에 겁먹거나 망설임으로 대답을 흐리지마세요. 명확한 답변으로 시작하고, 정당성을 공유합니다.
     * "Feature X는 이전에 검토했을 때 불필요하다고 여겨졌고, Feature Y가 더 큰 가치가 있을거라 판단했습니다. Feature X를 다시 고려해야한다고 생각하시나요?"

예제 상황 2.
예상치 못한 서비스 장애로 다른 엔지니어들이 모두 지켜보는 상황. 팀에서는 원인을 계속 찾을 수 없고, 그냥 무작위로 수정을 하다가는 상황을 더 악화시킬 수도 있는 상황.

 * 두려움의 이유
   * 리더로서 "모든 답을 가지고 있어야 한다"는 압박.
   * 실패가 동료들로부터 자신의 역량을 의심받게 할 것이라는 걱정.
   * 빠른 행동이 불러올 부정적인 결과에 대한 불안.
     
     
 * BAA 적용하기
   * Breath: "컨텍스트를 이해할 시간이 필요합니다."라며 침착을 유지.
   * Assess: 현상과 영향, 트리거, 잠재된 이슈 등을 명확히 분리.
   * Act: 지금 파악된것과 파악되지 않은 것을 명확하게 전달하세요.
     * "우리가 아는 것과 모르는 것을 명확히 하며, 잠재적 원인을 조사 중입니다. 필요하다면 다른 팀의 도움을 요청하겠습니다."
     * 정기적으로 업데이트를 공유하여, 주변 사람들이 추측하지 못하도록 합니다.

예제 상황3.
프로젝트를 잘 마무리 했다고 생각했는데 "프로젝트 중에 커뮤니케이션이 미흡했던 것 같습니다" 라는 부정적인 피드백을 받아 자신감에 타격을 입었습니다.

 * 두려움의 이유
   * 자신의 능력에 대한 의심과 낮아진 자신감.
   * 부정적인 평가가 경력이나 승진에 미칠 영향에 대한 걱정.
   * 이때 하면 안되는 일
     * 피드백 거부하기
     * 구체적인 내용을 듣지 않은 채 그대로 받아들이기

 * BAA 적용하기
   * Breath: 비판적 피드백은 놀라울 수 있으나, 차분히 경청.
   * Assess: "구체적으로 어떤 상황을 의미하나요?"라며 피드백의 구체성을 파악.
   * Act: 피드백을 주는 사람에게 내가 경청하고 있다는 신호를 보내기
     * "이 피드백에 놀랐지만, 개선할 수 있도록 더 알아가고 싶습니다."라는 태도로 대화 진행.
     * 논의도 중요하지만, 세부 사항에 대해 숙고할 시간이 필요하다 느낀다면 충분한 시간을 갖도록 해보세요.

---

예상치 못한 상황에서 두려움을 느끼고 당황하는 것은 너무나도 자연스러운 현상입니다. 행동하기 전에 생각을 제대로 하기 어렵습니다.

하지만 한번 숨을 돌리고, 문제 상황을 직시하고, 최선의 행동 선택을 연습한다면 더 나은 동료, 리더가 되어 갈 수 있을거에요 :)

나보다 시니어가 질문을 했는데 어떻게 답을 해야할지 잘 모르겠고, 그 상황이 두려움으로 느껴진 적 있으신가요? 그냥 그 상황을 도망치고만 싶을 때 어떻게 했었나요? 압박감 속에서도 침착함을 유지하기 위한 BAA 프레임워크(Breath, Assess, Act / 호흡하기, 파악하기, 행동하기)를 소개합니다. 각 단계에서 차분히 상황을 다루며 신중한 결정을 내리는 방법을 체계적으로 연습해 볼 수 있습니다. 예제 상황 1. 상위 결정자들에게 프로젝트 프레젠테이션 부사장님이 중 다음과 같은 질문을 합니다.“왜 Feature X를 개발하지 않나요? 왜 Feature Y에 집중하죠?” <ul ><li>두려움의 이유<ul ><li>권위 있는 인물에게 "잘못된 답변"을 하는 것에 대한 두려움.</li><li>과거 합의된 결정이 잘못된 것으로 드러날까 봐의 불안.</li><li>상사에게 “아니오”라고 말하기 꺼려지는 심리적 부담.</li></ul></li></ul> <ul ><li>BAA 적용하기<ul ><li>Breath: 심호흡으로 긴장을 풀고 직함의 위압감을 잊습니다.</li><li>Assess: 질문 의도와 가정을 파악합니다.<ul ><li>“Feature X는 이전 리뷰에서 불필요하다고 결론 내렸습니다. 현재 Feature Y가 사용자 연구에서 더 가치 있는 것으로 나타났습니다. 다시 검토할 필요가 있나요?”</li></ul></li><li>Act: 상대방의 어조에 겁먹거나 망설임으로 대답을 흐리지마세요. 명확한 답변으로 시작하고, 정당성을 공유합니다.<ul ><li>"Feature X는 이전에 검토했을 때 불필요하다고 여겨졌고, Feature Y가 더 큰 가치가 있을거라 판단했습니다. Feature X를 다시 고려해야한다고 생각하시나요?"</li></ul></li></ul></li></ul> 예제 상황 2.예상치 못한 서비스 장애로 다른 엔지니어들이 모두 지켜보는 상황. 팀에서는 원인을 계속 찾을 수 없고, 그냥 무작위로 수정을 하다가는 상황을 더 악화시킬 수도 있는 상황. <ul ><li>두려움의 이유<ul ><li>리더로서 "모든 답을 가지고 있어야 한다"는 압박.</li><li>실패가 동료들로부터 자신의 역량을 의심받게 할 것이라는 걱정.</li><li>빠른 행동이 불러올 부정적인 결과에 대한 불안. </li></ul></li><li>BAA 적용하기<ul ><li>Breath: "컨텍스트를 이해할 시간이 필요합니다."라며 침착을 유지.</li><li>Assess: 현상과 영향, 트리거, 잠재된 이슈 등을 명확히 분리.</li><li>Act: 지금 파악된것과 파악되지 않은 것을 명확하게 전달하세요.<ul ><li>"우리가 아는 것과 모르는 것을 명확히 하며, 잠재적 원인을 조사 중입니다. 필요하다면 다른 팀의 도움을 요청하겠습니다."</li><li>정기적으로 업데이트를 공유하여, 주변 사람들이 추측하지 못하도록 합니다.</li></ul></li></ul></li></ul> 예제 상황3.프로젝트를 잘 마무리 했다고 생각했는데 "프로젝트 중에 커뮤니케이션이 미흡했던 것 같습니다" 라는 부정적인 피드백을 받아 자신감에 타격을 입었습니다. <ul ><li>두려움의 이유<ul ><li>자신의 능력에 대한 의심과 낮아진 자신감.</li><li>부정적인 평가가 경력이나 승진에 미칠 영향에 대한 걱정.</li><li>이때 하면 안되는 일<ul ><li>피드백 거부하기</li><li>구체적인 내용을 듣지 않은 채 그대로 받아들이기</li></ul></li></ul></li></ul> <ul ><li>BAA 적용하기<ul ><li>Breath: 비판적 피드백은 놀라울 수 있으나, 차분히 경청.</li><li>Assess: "구체적으로 어떤 상황을 의미하나요?"라며 피드백의 구체성을 파악.</li><li>Act: 피드백을 주는 사람에게 내가 경청하고 있다는 신호를 보내기<ul ><li>"이 피드백에 놀랐지만, 개선할 수 있도록 더 알아가고 싶습니다."라는 태도로 대화 진행.</li><li>논의도 중요하지만, 세부 사항에 대해 숙고할 시간이 필요하다 느낀다면 충분한 시간을 갖도록 해보세요.</li></ul></li></ul></li></ul> --- 예상치 못한 상황에서 두려움을 느끼고 당황하는 것은 너무나도 자연스러운 현상입니다. 행동하기 전에 생각을 제대로 하기 어렵습니다. 하지만 한번 숨을 돌리고, 문제 상황을 직시하고, 최선의 행동 선택을 연습한다면 더 나은 동료, 리더가 되어 갈 수 있을거에요 :)

압박 상황 안에서도 침착함을 유지하는 방법

Write Down the Plan

엔지니어로서 일하면서 우리는 얼마나 자주 우리의 계획을 문서화하고 있을까요? 많은 경우 계획을 머릿속에만 담아두거나 구두로만 설명하고 끝내곤 합니다. 이 글에서는 "성장하는 엔지니어들"이나 "리더들"은 '계획을 글로 남기는' 습관을 가진 사람들이 많다고 합니다. 필자는 자신의 경험을 통해 이 습관이 프로모션과 성장을 가속화했다고 전하고 있습니다. 그렇다면, 계획을 문서화하는 습관이 우리에게 어떤 이점을 줄 수 있을까요?

 * 사고력 향상: 글로 생각을 정리하다 보면 논리적 서사로 전개되며 생각이 더 명확해집니다. 간결하게 쓰려는 과정에서 문제의 최적화나 추가적인 예외 상황을 발견하게 되는 경우도 많습니다.

 * 팀원 간의 정렬 (Alignment) 구축: 계획을 문서로 작성해 공유하면, 피드백을 받으면서 점차 팀원 모두가 같은 페이지에 있게 됩니다. 이를 통해 사전에 이견을 조율하고, 합의를 얻는 과정이 훨씬 수월해집니다.

 * 자신의 가시성 및 인지도 상승: 작성된 계획을 공유하면, 동료나 리더가 그 계획과 성과를 자연스럽게 연결지어 생각하게 됩니다. 덕분에 평가나 성과 회의에서도 미리 인지된 성과가 도움이 되어 보다 원활한 논의가 가능합니다.

이 블로그 글에서는 위와 같은 문서화 습관 덕분에 커리어의 여러 기회를 얻었다고 하는데요. 여러분들은 지금까지의 프로젝트에서 '글로 계획을 남기는' 습관을 얼마나 실천해 보셨나요? 다음 번 프로젝트에서는 이 습관을 도입해 보고 그 효과를 직접 경험해 보는 건 어떨까요?

https://www.developing.dev/p/write-down-the-plan

엔지니어로서 일하면서 우리는 얼마나 자주 우리의 계획을 문서화하고 있을까요? 많은 경우 계획을 머릿속에만 담아두거나 구두로만 설명하고 끝내곤 합니다. 이 글에서는 "성장하는 엔지니어들"이나 "리더들"은 '계획을 글로 남기는' 습관을 가진 사람들이 많다고 합니다. 필자는 자신의 경험을 통해 이 습관이 프로모션과 성장을 가속화했다고 전하고 있습니다. 그렇다면, 계획을 문서화하는 습관이 우리에게 어떤 이점을 줄 수 있을까요? <ul ><li>사고력 향상: 글로 생각을 정리하다 보면 논리적 서사로 전개되며 생각이 더 명확해집니다. 간결하게 쓰려는 과정에서 문제의 최적화나 추가적인 예외 상황을 발견하게 되는 경우도 많습니다.</li></ul> <ul ><li>팀원 간의 정렬 (Alignment) 구축: 계획을 문서로 작성해 공유하면, 피드백을 받으면서 점차 팀원 모두가 같은 페이지에 있게 됩니다. 이를 통해 사전에 이견을 조율하고, 합의를 얻는 과정이 훨씬 수월해집니다.</li></ul> <ul ><li>자신의 가시성 및 인지도 상승: 작성된 계획을 공유하면, 동료나 리더가 그 계획과 성과를 자연스럽게 연결지어 생각하게 됩니다. 덕분에 평가나 성과 회의에서도 미리 인지된 성과가 도움이 되어 보다 원활한 논의가 가능합니다.</li></ul> 이 블로그 글에서는 위와 같은 문서화 습관 덕분에 커리어의 여러 기회를 얻었다고 하는데요. 여러분들은 지금까지의 프로젝트에서 '글로 계획을 남기는' 습관을 얼마나 실천해 보셨나요? 다음 번 프로젝트에서는 이 습관을 도입해 보고 그 효과를 직접 경험해 보는 건 어떨까요? https://www.developing.dev/p/write-down-the-plan

계획을 글로 써보기

강연이 끝나고 무대로 달려갔어요. 강연자는 스타트업 CTO로 최근 엑싯을 경험한 분이셨죠. 두 번째 창업을 앞두고 계셨어요.

같이 일하고 싶다고 말씀드렸어요. 인턴으로, 무급이어도 좋다고 말씀드렸어요. 기회가 찾아왔다는 생각에 무작정 들이밀었어요.

그 후 6개월간 수업과 연계해 학교에서 돈을 받고 회사에선 일을 배웠어요. 그게 첫 인턴 경험이었어요.

무대를 향해 달려가던 그때의 두근거림이 아직도 생생해요. 그날의 작은 용기가 지금의 저를 만들었어요.

강연이 끝나고 무대로 달려갔어요. 강연자는 스타트업 CTO로 최근 엑싯을 경험한 분이셨죠. 두 번째 창업을 앞두고 계셨어요. 같이 일하고 싶다고 말씀드렸어요. 인턴으로, 무급이어도 좋다고 말씀드렸어요. 기회가 찾아왔다는 생각에 무작정 들이밀었어요. 그 후 6개월간 수업과 연계해 학교에서 돈을 받고 회사에선 일을 배웠어요. 그게 첫 인턴 경험이었어요. 무대를 향해 달려가던 그때의 두근거림이 아직도 생생해요. 그날의 작은 용기가 지금의 저를 만들었어요.

개발자에겐 용기가 필요해요

content-visibility는 레이아웃과 페인트의 관점에서 DOM의 특정 부분을 “숨길” 수 있는 새로운 CSS 기능입니다.

(번역) CSS content-visibility를 이용해 렌더링 성능 향상 시키기

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

CSS의 content-visibility에 대해 알고 계신가요? 브라우저가 요소의 렌더링을 필요로 할 때 까지 생략할 수 있도록 해 페이지 로드 성능을 향상할 수 있게 도와주는 CSS 속성입니다.

이 글에서는 content-visibility를 이용해 큰 목록의 렌더링 성능 이슈를 해결했던 실제 경험을 통해 어떤 장점이 있는지 그리고 한계는 무엇인지에 대해 일반적으로 큰 목록의 성능 향상을 위해 사용하는 가상 목록과 비교하여 자세히 설명하고 있습니다.

실제 문제가 되었던 부분을 추적하는 것 부터, 해결하는 과정까지 자세하게 풀어내며 고민했던 내용들을 살펴보시고 나면, 성능 문제가 발생했을 때 고려해 볼 수 있는 또 하나의 선택지를 얻으실 수 있지 않을까 생각됩니다.

글 링크 : https://velog.io/@superlipbalm/improving-rendering-performance-with-css-content-visibility

오늘 소개해드릴 글은 라인플러스의 김찬희님이 번역해주신 글입니다. CSS의 content-visibility에 대해 알고 계신가요? 브라우저가 요소의 렌더링을 필요로 할 때 까지 생략할 수 있도록 해 페이지 로드 성능을 향상할 수 있게 도와주는 CSS 속성입니다. 이 글에서는 content-visibility를 이용해 큰 목록의 렌더링 성능 이슈를 해결했던 실제 경험을 통해 어떤 장점이 있는지 그리고 한계는 무엇인지에 대해 일반적으로 큰 목록의 성능 향상을 위해 사용하는 가상 목록과 비교하여 자세히 설명하고 있습니다. 실제 문제가 되었던 부분을 추적하는 것 부터, 해결하는 과정까지 자세하게 풀어내며 고민했던 내용들을 살펴보시고 나면, 성능 문제가 발생했을 때 고려해 볼 수 있는 또 하나의 선택지를 얻으실 수 있지 않을까 생각됩니다. 글 링크 : https://velog.io/@superlipbalm/improving-rendering-performance-with-css-content-visibility

velog.io

CSS content-visibility로 렌더링 성능 향상 시키

Rewriting Pierre to be zero-latency • Pierre Changelog

Bootstrap을 만들었던 개발자들이 모여서 만드는 협업 도구 Pierre가 일반적인 REST API를 사용해서 서비스를 만들었다가 로컬 퍼스터 동기화 프레임워크인 Replicache를 사용해서 완전히 다시 작성했습니다.

서비스를 고도화하면서 점점 가져와야할 데이터가 많아지면서 사용자 경험이 안좋아지자 Replicache를 도입했다고 합니다. 브라우저의 IndexedDB에 저장하고 Replicache가 백엔드와 알아서 동기화하기 때문에 백엔드와 프론트엔드의 관심사를 분리해서 작성할 수 있는 장점이 있었고 다른 도구와 달리 Replicach는 인증과 엑세스 제어를 구현하는 사람에게 위임하기 때문에 서비스에 맞게 이를 구현할 수 있는 것도 큰 장점이었다고 합니다.

이렇게 로컬에 캐시를 두고 동괴화를 함으로써 Pierre의 레이턴시가 크게 개선되었는데 Pierre가 Replicache를 어떻게 사용했는지를 설명하고 있습니다.

https://docs.pierre.co/changelog/local-first

Bootstrap을 만들었던 개발자들이 모여서 만드는 협업 도구 Pierre가 일반적인 REST API를 사용해서 서비스를 만들었다가 로컬 퍼스터 동기화 프레임워크인 Replicache를 사용해서 완전히 다시 작성했습니다. 서비스를 고도화하면서 점점 가져와야할 데이터가 많아지면서 사용자 경험이 안좋아지자 Replicache를 도입했다고 합니다. 브라우저의 IndexedDB에 저장하고 Replicache가 백엔드와 알아서 동기화하기 때문에 백엔드와 프론트엔드의 관심사를 분리해서 작성할 수 있는 장점이 있었고 다른 도구와 달리 Replicach는 인증과 엑세스 제어를 구현하는 사람에게 위임하기 때문에 서비스에 맞게 이를 구현할 수 있는 것도 큰 장점이었다고 합니다. 이렇게 로컬에 캐시를 두고 동괴화를 함으로써 Pierre의 레이턴시가 크게 개선되었는데 Pierre가 Replicache를 어떻게 사용했는지를 설명하고 있습니다. https://docs.pierre.co/changelog/local-first

docs.pierre.co

Bootstrap을 만들었던 개발자들이 모여서 만드는 협업 도구 

AI 기반 Software Testing "개념 이해"

JetBrains IDE인 WebStorm과 Rider를 비상업적으로 사용하는 것은 이제 무료입니다! 블로그 게시물에서 자세히 알아보세요.

이제 WebStorm과 Rider를 비상업용으로 무료 제공 | JetBrains 블로그

JetBrains의 WebStorm이 무료로 제공하기로 했다는 반가운 소식이 있네요.
그동안 무료인 VSCode가 워낙 좋아서 WebStorm 유료 결제를 하며 사용하지는 않고 있었는데요. WebStorm이 좀 더 풍부한 기능을 제공하는 만큼, 이번 무료화 결정으로 더 많은 개발자분들이 활용해 보실 수 있게 되었습니다.

다만 한가지 주의할 점은, 이 무료 라이선스는 학습이나 취미 개발 등 비상업적 용도로만 사용이 가능합니다. 회사에서의 사용이나 수익이 발생하는 프로젝트에는 여전히 유료 라이선스가 필요하니 이 점 유의하여 사용하시기를 권장드립니다.

https://blog.jetbrains.com/ko/blog/2024/10/24/webstorm-and-rider-are-now-free-for-non-commercial-use/

JetBrains의 WebStorm이 무료로 제공하기로 했다는 반가운 소식이 있네요.그동안 무료인 VSCode가 워낙 좋아서 WebStorm 유료 결제를 하며 사용하지는 않고 있었는데요. WebStorm이 좀 더 풍부한 기능을 제공하는 만큼, 이번 무료화 결정으로 더 많은 개발자분들이 활용해 보실 수 있게 되었습니다. 다만 한가지 주의할 점은, 이 무료 라이선스는 학습이나 취미 개발 등 비상업적 용도로만 사용이 가능합니다. 회사에서의 사용이나 수익이 발생하는 프로젝트에는 여전히 유료 라이선스가 필요하니 이 점 유의하여 사용하시기를 권장드립니다. https://blog.jetbrains.com/ko/blog/2024/10/24/webstorm-and-rider-are-now-free-for-non-commercial-use/

The JetBrains Blog

JetBrains WebStorm 무료화 소식

01 . 몇 해 전 흥미로운 기사 하나를 접한 적이 있습니다. 영어 원문을 번역해놓은 자료라 명확하게 제목이 떠오르지는 않지만 아마도 이런 문장이 헤드라인에 걸려있었던 걸로 기억합니다.
'당신은 이 아티클 역시 완독하지 않을 것이다. 하지만 누군가에게 공유할 것이고, 이에 대해 이야기할 것이고, 다시 재생산할 것이다.'
꽤 특이한 제목의 이 기사는 원문을 제대로 읽지 않은 채 오로지 공유하거나 코멘트하는 것에만 관심을 기울이는 사람들을 꼬집기 위한 기획 기사였습니다. 특히 SNS를 포함해 사회적 영향력이 있는 사람일수록 알리는 것에만 집중할 뿐 온전히 집중해 콘텐츠를 소비하는 것을 점점 등한시한다는 것이죠.

02 . 한 유튜브 채널에 출연한 배우 정우성 님도 이런 말을 하시더라고요.
"영화인들이 영화계 어렵다는 말을 달고 살지만 배우 중에도 영화 잘 안보는 사람이 많습니다. 자기가 몸담고 있는 일인데 영화를 보지도 않고서 영화계가 어쩐다 저쩐다 하는 건 어불성설이죠."
이 말만 들으면 '그게 가능할까?' 싶지만 잠시 기억을 더듬어보니 제가 경험한 몇몇 사람들도 크게 다르지 않은 양상을 보였다는 걸 알게 되고 말았습니다. 자기 의견을 강조하거나 공유하는 것에 심취한 나머지 눈 앞의 콘텐츠에는 제대로 집중하지 못하는 사람들을 꽤 많이 봤으니 말이죠.

03 . 대표적으로는 앞서 소개한 기사의 내용처럼 자신도 제대로 읽지 않은 콘텐츠를 추천하고 공유하는 사례를 들 수 있습니다. 뭐 당연히 너무 좋거나 반가운 콘텐츠를 만나다 보면 선공유 후감상도 할 수 있는 법이죠. 하지만 '누가 뭐라고 말했다' 혹은 '누가 이렇게 했다더라'라는 그 단편의 메시지 몇 줄만 보고서 전체의 감상을 아우르는 메시지를 던지는 건 엄격히 말해 남을 기만하는 행동에 가깝습니다. 끝까지 보지도 않은 영화를 최고라고 추켜세우며 추천한 사람이 있다면 그 누구의 신뢰도 얻지 못할 테니까요.

04 . 예전에 인스타그램을 통해서도 한 번 언급한 적이 있지만 책 추천사 카테고리로 들어가면 상황은 점점 더 심각해집니다. 감사한 기회로 저도 종종 다른 분들이 출간하는 책에 추천사를 쓸 기회가 있지만 그때마다 제가 정중히 요청드리는 것 중 한 가지는 책 전문을 모두 읽고 나서 추천사를 작성할 수 있도록 최소 일주일의 시간은 주면 좋겠다는 것입니다.
하지만 때론 이틀 만에 추천사를 달라고 하는 경우도 있고 정말 심한 경우에는 온라인 서점에 올라가는 도서 요약 정보만 전달한 채 시간이 촉박하니 추천사 먼저 작성해 주면 좋겠다고 말하는 경우도 있죠. 그런 사람들이 책을 기획하고 편집하고 출간했다고 생각하면 솔직히 실망을 넘어 화가 나는 것도 사실입니다.

05 . 그렇다고 단순히 상대를 기만하는 행위에만 화가 나느냐 하면 그보다는 조금 더 본질적인 이유가 있습니다. 우리가 실망을 금치 못하는 진짜 주된 포인트는 바로 본인조차 그 콘텐츠를 있는 그대로 사랑하지 않으면서 (사랑할 기회와 시간조차 없었다고 보는 게 맞겠군요...) 오직 자신의 영향력을 과시하기 위해 해당 콘텐츠를 교묘히 이용한다는 데 있기 때문입니다. 쉽게 말해 정말 좋은 콘텐츠를 많은 사람에게 알리고 싶은 마음 대신 그 콘텐츠를 알릴 수 있을 정도의 영향력을 가진 자신이 주목받기를 바라는 마음이 더 클 수도 있다는 얘기입니다.

06 . 반론을 생각해 보지 않은 것은 아닙니다. 누군가는 이렇게 얘기할 수도 있죠.
'그 사람이 그런 영향력을 가지게 된 데에는 싫으나 좋으나 사람들이 열광하는 포인트가 있을 텐데 그걸 존중해 주는 것도 좋지 않을까요?'라고 말입니다. 일리 있는 말입니다.
하지만 이렇게 한 번 생각해 보면 어떨까요? 만약 백종원 대표님이 직접 먹어보지도 않은 채 어느 식당이 유명하다는 이유만으로, 혹은 맛있어 보인다는 이유만으로 여러분들께 '너무 맛있었다'는 표현을 쓰며 추천한다면요? 곽튜브나 빠니보틀이 실제로 가보지 않은 여행지를 리뷰하며 '여기 너무 좋았다'고 극찬하며 여러분에게 강추 여행지로 소개한다면요? 이건 좀 얘기가 달라지지 않을까요?

07 . 개념 설명을 위해 비약에 가까운 예시를 들긴 했지만 이제 다시 현실로 돌아와 이야기를 이어가 보겠습니다. 저는 적어도 대중을 상대로 무엇인가를 소개하고 추천할 때는 그 유형을 나눌 수 있어야 한다고 봅니다.
첫째는 '흥미롭다 (혹은 재미있겠다) 그러니 우리 지금부터 같이 즐겨보자'는 스탠스입니다. 둘째는 '나는 온전히 그 콘텐츠를 소비했고 또 나는 충분히 만족했으므로 여러분들에게 추천한다'는 스탠스입니다. 그리고 마지막 세 번째는 '콘텐츠를 온전히 소비했음은 물론이고 그에 대한 비평이나 또는 내 관점에서의 새로운 의견을 덧붙이고 싶기 때문에 입을 연다'는 입장입니다.

08 . 당연히 이 세 가지는 본질 자체가 다르고 사람들에게 전달되기까지의 단계 역시 구분됩니다. '아직 안 보긴 했는데 여러분들에게 추천드리고(?), 동시에 이 콘텐츠에 대한 제 입장은 이렇습니다'는 마치 '아직 배송이 안 와서 써보지는 못했는데 너무 좋네요. 여러분에게도 적극 추천드리고 앞으로도 이런 물건 많이 팔아주셨으면 해요'라는 가정형 미래 화법의 고객리뷰와 다를 바가 없습니다. 논리는커녕 인과관계조차 성립될 수가 없는 의견인 것이죠.

09 . 세상에 즐길 거리가 워낙 많다 보니 한 사람이 온전한 하나의 콘텐츠를 소비하기가 힘들어진 것은 맞습니다. 때문에 그저 간보기 식으로 찍어서(!) 리뷰를 하는 사람들이 많아지고 질보단 양, 양보단 속도라는 생각으로 일단 다른 사람들보다 먼저 이슈를 선점하려는 사람들 역시 점점 늘어나는 것 또한 부정할 수 없습니다.
그러나 이런 현상이 리뷰를 하고, 의견을 내는 사람들의 얄팍한 행태를 모두 감싸줄 수는 없습니다. 세상이 그런 것은 그런 것이고, 그 안에서 우리가 해야 할 것 또 지켜야 할 것은 엄연히 존재하는 것이니 말입니다.

10 . '나는 저렇게 목소리를 내는 인플루언서가 아니니까', '나는 SNS에 개인적인 주장 안 하니까'라고 생각하고 넘기기에는 우리 실생활에서도 이런 일이 비일비재하게 벌어진다는 것이 더 슬픈 현실입니다. 리뷰를 부탁하는 동료의 콘텐츠를 두고 대충 눈으로 읽고서 자기 감상을 추가하는 것에 더 열을 올린 적은 없었는지, 중요한 내용을 정리한 메일의 한두 문장만 본 다음 '일이 이렇게 굴러가고 있구나'라는 현실 왜곡형 자기 해석만을 떠안고 다른 이슈로 눈을 돌린 적은 없는지 우리 모두 한 번쯤은 반성해 볼 지점이 분명히 있어 보이니까요, 내 의견을 한 줄이라도 추가하고 싶다면 우선은 그 콘텐츠에 집중하는 것이 예의이자 윤리일지 모릅니다.

01 . 몇 해 전 흥미로운 기사 하나를 접한 적이 있습니다. 영어 원문을 번역해놓은 자료라 명확하게 제목이 떠오르지는 않지만 아마도 이런 문장이 헤드라인에 걸려있었던 걸로 기억합니다.'당신은 이 아티클 역시 완독하지 않을 것이다. 하지만 누군가에게 공유할 것이고, 이에 대해 이야기할 것이고, 다시 재생산할 것이다.'꽤 특이한 제목의 이 기사는 원문을 제대로 읽지 않은 채 오로지 공유하거나 코멘트하는 것에만 관심을 기울이는 사람들을 꼬집기 위한 기획 기사였습니다. 특히 SNS를 포함해 사회적 영향력이 있는 사람일수록 알리는 것에만 집중할 뿐 온전히 집중해 콘텐츠를 소비하는 것을 점점 등한시한다는 것이죠. 02 . 한 유튜브 채널에 출연한 배우 정우성 님도 이런 말을 하시더라고요."영화인들이 영화계 어렵다는 말을 달고 살지만 배우 중에도 영화 잘 안보는 사람이 많습니다. 자기가 몸담고 있는 일인데 영화를 보지도 않고서 영화계가 어쩐다 저쩐다 하는 건 어불성설이죠."이 말만 들으면 '그게 가능할까?' 싶지만 잠시 기억을 더듬어보니 제가 경험한 몇몇 사람들도 크게 다르지 않은 양상을 보였다는 걸 알게 되고 말았습니다. 자기 의견을 강조하거나 공유하는 것에 심취한 나머지 눈 앞의 콘텐츠에는 제대로 집중하지 못하는 사람들을 꽤 많이 봤으니 말이죠. 03 . 대표적으로는 앞서 소개한 기사의 내용처럼 자신도 제대로 읽지 않은 콘텐츠를 추천하고 공유하는 사례를 들 수 있습니다. 뭐 당연히 너무 좋거나 반가운 콘텐츠를 만나다 보면 선공유 후감상도 할 수 있는 법이죠. 하지만 '누가 뭐라고 말했다' 혹은 '누가 이렇게 했다더라'라는 그 단편의 메시지 몇 줄만 보고서 전체의 감상을 아우르는 메시지를 던지는 건 엄격히 말해 남을 기만하는 행동에 가깝습니다. 끝까지 보지도 않은 영화를 최고라고 추켜세우며 추천한 사람이 있다면 그 누구의 신뢰도 얻지 못할 테니까요. 04 . 예전에 인스타그램을 통해서도 한 번 언급한 적이 있지만 책 추천사 카테고리로 들어가면 상황은 점점 더 심각해집니다. 감사한 기회로 저도 종종 다른 분들이 출간하는 책에 추천사를 쓸 기회가 있지만 그때마다 제가 정중히 요청드리는 것 중 한 가지는 책 전문을 모두 읽고 나서 추천사를 작성할 수 있도록 최소 일주일의 시간은 주면 좋겠다는 것입니다. 하지만 때론 이틀 만에 추천사를 달라고 하는 경우도 있고 정말 심한 경우에는 온라인 서점에 올라가는 도서 요약 정보만 전달한 채 시간이 촉박하니 추천사 먼저 작성해 주면 좋겠다고 말하는 경우도 있죠. 그런 사람들이 책을 기획하고 편집하고 출간했다고 생각하면 솔직히 실망을 넘어 화가 나는 것도 사실입니다. 05 . 그렇다고 단순히 상대를 기만하는 행위에만 화가 나느냐 하면 그보다는 조금 더 본질적인 이유가 있습니다. 우리가 실망을 금치 못하는 진짜 주된 포인트는 바로 본인조차 그 콘텐츠를 있는 그대로 사랑하지 않으면서 (사랑할 기회와 시간조차 없었다고 보는 게 맞겠군요...) 오직 자신의 영향력을 과시하기 위해 해당 콘텐츠를 교묘히 이용한다는 데 있기 때문입니다. 쉽게 말해 정말 좋은 콘텐츠를 많은 사람에게 알리고 싶은 마음 대신 그 콘텐츠를 알릴 수 있을 정도의 영향력을 가진 자신이 주목받기를 바라는 마음이 더 클 수도 있다는 얘기입니다. 06 . 반론을 생각해 보지 않은 것은 아닙니다. 누군가는 이렇게 얘기할 수도 있죠.'그 사람이 그런 영향력을 가지게 된 데에는 싫으나 좋으나 사람들이 열광하는 포인트가 있을 텐데 그걸 존중해 주는 것도 좋지 않을까요?'라고 말입니다. 일리 있는 말입니다. 하지만 이렇게 한 번 생각해 보면 어떨까요? 만약 백종원 대표님이 직접 먹어보지도 않은 채 어느 식당이 유명하다는 이유만으로, 혹은 맛있어 보인다는 이유만으로 여러분들께 '너무 맛있었다'는 표현을 쓰며 추천한다면요? 곽튜브나 빠니보틀이 실제로 가보지 않은 여행지를 리뷰하며 '여기 너무 좋았다'고 극찬하며 여러분에게 강추 여행지로 소개한다면요? 이건 좀 얘기가 달라지지 않을까요? 07 . 개념 설명을 위해 비약에 가까운 예시를 들긴 했지만 이제 다시 현실로 돌아와 이야기를 이어가 보겠습니다. 저는 적어도 대중을 상대로 무엇인가를 소개하고 추천할 때는 그 유형을 나눌 수 있어야 한다고 봅니다.첫째는 '흥미롭다 (혹은 재미있겠다) 그러니 우리 지금부터 같이 즐겨보자'는 스탠스입니다. 둘째는 '나는 온전히 그 콘텐츠를 소비했고 또 나는 충분히 만족했으므로 여러분들에게 추천한다'는 스탠스입니다. 그리고 마지막 세 번째는 '콘텐츠를 온전히 소비했음은 물론이고 그에 대한 비평이나 또는 내 관점에서의 새로운 의견을 덧붙이고 싶기 때문에 입을 연다'는 입장입니다. 08 . 당연히 이 세 가지는 본질 자체가 다르고 사람들에게 전달되기까지의 단계 역시 구분됩니다. '아직 안 보긴 했는데 여러분들에게 추천드리고(?), 동시에 이 콘텐츠에 대한 제 입장은 이렇습니다'는 마치 '아직 배송이 안 와서 써보지는 못했는데 너무 좋네요. 여러분에게도 적극 추천드리고 앞으로도 이런 물건 많이 팔아주셨으면 해요'라는 가정형 미래 화법의 고객리뷰와 다를 바가 없습니다. 논리는커녕 인과관계조차 성립될 수가 없는 의견인 것이죠. 09 . 세상에 즐길 거리가 워낙 많다 보니 한 사람이 온전한 하나의 콘텐츠를 소비하기가 힘들어진 것은 맞습니다. 때문에 그저 간보기 식으로 찍어서(!) 리뷰를 하는 사람들이 많아지고 질보단 양, 양보단 속도라는 생각으로 일단 다른 사람들보다 먼저 이슈를 선점하려는 사람들 역시 점점 늘어나는 것 또한 부정할 수 없습니다.그러나 이런 현상이 리뷰를 하고, 의견을 내는 사람들의 얄팍한 행태를 모두 감싸줄 수는 없습니다. 세상이 그런 것은 그런 것이고, 그 안에서 우리가 해야 할 것 또 지켜야 할 것은 엄연히 존재하는 것이니 말입니다. 10 . '나는 저렇게 목소리를 내는 인플루언서가 아니니까', '나는 SNS에 개인적인 주장 안 하니까'라고 생각하고 넘기기에는 우리 실생활에서도 이런 일이 비일비재하게 벌어진다는 것이 더 슬픈 현실입니다. 리뷰를 부탁하는 동료의 콘텐츠를 두고 대충 눈으로 읽고서 자기 감상을 추가하는 것에 더 열을 올린 적은 없었는지, 중요한 내용을 정리한 메일의 한두 문장만 본 다음 '일이 이렇게 굴러가고 있구나'라는 현실 왜곡형 자기 해석만을 떠안고 다른 이슈로 눈을 돌린 적은 없는지 우리 모두 한 번쯤은 반성해 볼 지점이 분명히 있어 보이니까요, 내 의견을 한 줄이라도 추가하고 싶다면 우선은 그 콘텐츠에 집중하는 것이 예의이자 윤리일지 모릅니다.

본인도 안 읽은 걸 대체 왜 추천하는 거죠?

1. 미친 소리 같지만, 대한민국 빵집 원탑 ‘성심당'과 전 세계 원탑 크리에이터 ‘미스터 비스트’의 성장 과정에는 뜻밖의 공통점이 있다. 2. 그건 바로, ‘나눔'을 통해 성장했다는 점. 성심당은 그날 팔고 남은 빵을 지역 단체에 기부하는 나눔 철학을 사업 초기부터 유지했다고.  3. 야구 선수를 꿈꾸다 크론병으로 포기한 뒤, 유튜브에 미쳐 있었던 미스터

성심당과 미스터 비스트의 뜻밖의 공통점

1. 미친 소리 같지만, 대한민국 빵집 원탑 ‘성심당'과 전 세계 원탑 크리에이터 ‘미스터 비스트’의 성장 과정에는 뜻밖의 공통점이 있다.

2. 그건 바로, ‘나눔'을 통해 성장했다는 점. 성심당은 그날 팔고 남은 빵을 지역 단체에 기부하는 나눔 철학을 사업 초기부터 유지했다고.

3. 야구 선수를 꿈꾸다 크론병으로 포기한 뒤, 유튜브에 미쳐 있었던 미스터 비스트(=제임스 도널드슨)는, 부모님의 반대 속에서도 유튜브를 하느라 첫 시작은 어설프기 그지없었다. 변변한 촬영 장비나 마이크조차 없었고, 형의 노트북을 빌려서 편집한 탓에 초창기 콘텐츠 퀄리티는 엉망을 넘어 형편없는 수준이었다.

4. 그래서 미스터 비스트는 초기 2년 동안 300개가 넘는 콘텐츠를 올렸음에도, 구독자 1000명을 모으지 못했다.

5. 그런 그가 전 세계 압도적 1위 유튜버로 성장한 데는, 여러 이유와 배경이 있지만, 그가 폭발적으로 성장할 수 있었던 계기 중 하나는 자신에게 생긴 첫 광고 수익을 모두 노숙자에게 나눠주는 영상을 찍으면서였다.

6. 그 뒤로, 나눔이 가지는 가치를 깨달은 미스터 비스트는 콘텐츠로 번 수익 대다수를 콘텐츠 제작과 구독자들에게 나눠주는 자신만의 성장 방정식을 만들어냈고, 미스터 비스트가 성장할수록 나눔의 폭은 상상을 초월할 정도로 커졌다.

7. 그리고 미스터 비스트가 이 방식으로 폭발적으로 성장하자, 수많은 사람들이 이 방식을 따라 했고 지금도 따라 하고 있지만, 미스터 비스트는 압도적 1위라는 규모를 활용해 언터처블이 되고 있으며, 미스터 비스트의 방식으로 미스터 비스트를 따라잡으려면 전 세계 1위가 되어야 하는데, 현재로서는 그럴 가능성을 0.1%라도 가진 크리에이터는 전 세계에 없다고 봐도 무방한 상황.

8. 물론 급변하는 콘텐츠 생태계에서 미스터 비스트가 영원히 원탑의 자리를 유지할 수 있을 것이라고는 생각하지 않지만, 그를 따라 하는 방식으로는 웬만해서는 미스터 비스트를 따라잡기는 쉽지 않아 보인달까?

9. 그리고 이런 나눔이 성장의 원동력이 될 수 있는 건, 드라이하게 보면 사업은 돈을 버는 과정이지만, 네트워크 관점에서 보면 사업은 고객과 연결되는 친밀한 관계를 구축하는 과정이기 때문. 이 과정에서 나눔은 네트워크를 활성화시키는 요소 중 하나이고.

10. 실제로 구글이 뇌과학자들과 연구한 결과에 따르면, 콘텐츠를 소비하는 데 있어 독자가 느끼는 친밀함의 정도가 그 콘텐츠의 퀄리티를 판단하는데 직접적인 영향을 미친다고 한다.

11. 즉, 많은 사람들이 간과하지만, 친밀함의 구축은 사업에서나 콘텐츠에서나 굉장히 중요한 요소라는 얘기.

12. 그리고 사람들 중에는 요즘 커뮤니티가 뜨고 있다며 커뮤니티를 마치 마케팅 도구로 생각하는 사람들이 없진 않은데, 냉정하게 말하면, 사람들이 진짜 원하는 건 커뮤니티가 아니라, 친밀함과 다정함일 수 있다. 커뮤니티는 그걸 담아내는 하나의 방식일 뿐이고. 그래서 다정함이나 친밀함에 대한 고려 없이 커뮤니티를 마케팅 도구로 접근하는 사람들의 경우, 별 반응이 없는 경우가 대다수고.

13. 무튼 뜬금없지만, 요즘 드라마 <이토록 친밀한 배신자>를 재미있게 보고 있는데, 어쩌면 사업이란 것 역시 고객에게 삶과 밀착된 ’친밀한 존재’가 되는 과정일 수 있다. 그런 의미에서 프레드 라이켈트가 창시한 NPS 역시도 고객에게 회사가 얼마나 친밀한 존재인가를 측정하는 도구인지도 모르고.

14. 그러니 온갖 멋진 숫자를 나열하며 거창하고 현란하게 사업의 목표를 정할 수도 있겠지만, 정반대로 소박하게 사업의 목표를 정할 수도 있다. 고객에게 ‘이토록 친밀한 뉴스레터, 이토록 친밀한 창작자, 이토록 친밀한 멤버십’이 되는 것도 괜찮은 목표일 수 있지 않을까? 무튼 나 화이팅! 😉

++ 멤버십에 미스터 비스트가 전 세계 원탑이 되는 과정을 3부작으로 정리한 콘텐츠가 있는 건 안 비밀입니다. 내용이 궁금하다면 막차 탑승을 ㅎㅎ

#오늘의아무말

https://brunch.co.kr/@somewonyoon/236

1. 미친 소리 같지만, 대한민국 빵집 원탑 ‘성심당'과 전 세계 원탑 크리에이터 ‘미스터 비스트’의 성장 과정에는 뜻밖의 공통점이 있다. 2. 그건 바로, ‘나눔'을 통해 성장했다는 점. 성심당은 그날 팔고 남은 빵을 지역 단체에 기부하는 나눔 철학을 사업 초기부터 유지했다고. 3. 야구 선수를 꿈꾸다 크론병으로 포기한 뒤, 유튜브에 미쳐 있었던 미스터 비스트(=제임스 도널드슨)는, 부모님의 반대 속에서도 유튜브를 하느라 첫 시작은 어설프기 그지없었다. 변변한 촬영 장비나 마이크조차 없었고, 형의 노트북을 빌려서 편집한 탓에 초창기 콘텐츠 퀄리티는 엉망을 넘어 형편없는 수준이었다. 4. 그래서 미스터 비스트는 초기 2년 동안 300개가 넘는 콘텐츠를 올렸음에도, 구독자 1000명을 모으지 못했다. 5. 그런 그가 전 세계 압도적 1위 유튜버로 성장한 데는, 여러 이유와 배경이 있지만, 그가 폭발적으로 성장할 수 있었던 계기 중 하나는 자신에게 생긴 첫 광고 수익을 모두 노숙자에게 나눠주는 영상을 찍으면서였다. 6. 그 뒤로, 나눔이 가지는 가치를 깨달은 미스터 비스트는 콘텐츠로 번 수익 대다수를 콘텐츠 제작과 구독자들에게 나눠주는 자신만의 성장 방정식을 만들어냈고, 미스터 비스트가 성장할수록 나눔의 폭은 상상을 초월할 정도로 커졌다. 7. 그리고 미스터 비스트가 이 방식으로 폭발적으로 성장하자, 수많은 사람들이 이 방식을 따라 했고 지금도 따라 하고 있지만, 미스터 비스트는 압도적 1위라는 규모를 활용해 언터처블이 되고 있으며, 미스터 비스트의 방식으로 미스터 비스트를 따라잡으려면 전 세계 1위가 되어야 하는데, 현재로서는 그럴 가능성을 0.1%라도 가진 크리에이터는 전 세계에 없다고 봐도 무방한 상황. 8. 물론 급변하는 콘텐츠 생태계에서 미스터 비스트가 영원히 원탑의 자리를 유지할 수 있을 것이라고는 생각하지 않지만, 그를 따라 하는 방식으로는 웬만해서는 미스터 비스트를 따라잡기는 쉽지 않아 보인달까? 9. 그리고 이런 나눔이 성장의 원동력이 될 수 있는 건, 드라이하게 보면 사업은 돈을 버는 과정이지만, 네트워크 관점에서 보면 사업은 고객과 연결되는 친밀한 관계를 구축하는 과정이기 때문. 이 과정에서 나눔은 네트워크를 활성화시키는 요소 중 하나이고. 10. 실제로 구글이 뇌과학자들과 연구한 결과에 따르면, 콘텐츠를 소비하는 데 있어 독자가 느끼는 친밀함의 정도가 그 콘텐츠의 퀄리티를 판단하는데 직접적인 영향을 미친다고 한다. 11. 즉, 많은 사람들이 간과하지만, 친밀함의 구축은 사업에서나 콘텐츠에서나 굉장히 중요한 요소라는 얘기. 12. 그리고 사람들 중에는 요즘 커뮤니티가 뜨고 있다며 커뮤니티를 마치 마케팅 도구로 생각하는 사람들이 없진 않은데, 냉정하게 말하면, 사람들이 진짜 원하는 건 커뮤니티가 아니라, 친밀함과 다정함일 수 있다. 커뮤니티는 그걸 담아내는 하나의 방식일 뿐이고. 그래서 다정함이나 친밀함에 대한 고려 없이 커뮤니티를 마케팅 도구로 접근하는 사람들의 경우, 별 반응이 없는 경우가 대다수고. 13. 무튼 뜬금없지만, 요즘 드라마 &lt;이토록 친밀한 배신자&gt;를 재미있게 보고 있는데, 어쩌면 사업이란 것 역시 고객에게 삶과 밀착된 ’친밀한 존재’가 되는 과정일 수 있다. 그런 의미에서 프레드 라이켈트가 창시한 NPS 역시도 고객에게 회사가 얼마나 친밀한 존재인가를 측정하는 도구인지도 모르고. 14. 그러니 온갖 멋진 숫자를 나열하며 거창하고 현란하게 사업의 목표를 정할 수도 있겠지만, 정반대로 소박하게 사업의 목표를 정할 수도 있다. 고객에게 ‘이토록 친밀한 뉴스레터, 이토록 친밀한 창작자, 이토록 친밀한 멤버십’이 되는 것도 괜찮은 목표일 수 있지 않을까? 무튼 나 화이팅! 😉 ++ 멤버십에 미스터 비스트가 전 세계 원탑이 되는 과정을 3부작으로 정리한 콘텐츠가 있는 건 안 비밀입니다. 내용이 궁금하다면 막차 탑승을 ㅎㅎ #오늘의아무말 https://brunch.co.kr/@somewonyoon/236

Brunch Story

원문: https://manupa.dev/blog/anatomy-of-shadcn-ui

[번역] shadcn/ui 의 해부

버튼, Input, DatePicker 등 자주 쓰는 UI 전용 컴포넌트들이 있습니다. 익숙하지만, 이걸 처음부터 Tailwind 등을 사용해 맨땅부터 다시 컴포넌트를 다 만들기에는 작업량이 너무 방대합니다. 처음에는 UI정도라 도전을 해보지만 키입력과 겉은 상호작용도 중요하니까요. 만약 a11y처럼 접근성까지 고려한다면 너무 큰 작업이 되겠네요.

그래서 우리는 남들이 잘 만들어둔 전통적인 디자인 시스템인 MUI, Ant Design, Chakra 등을 사용했습니다. 이들 컴포넌트 구성은 탄탄하지만, 단점은 그들의 디자인을 따라야만 합니다. 그래서 디자인을 고쳐보고자 하지믄 이미 개성을 갖춘 디자인 시스템의 스타일링을 커스텀하는 건 여간 고된 일이 아니죠. 또한 그들이 만들어주지 않는 컴포넌트가 기획에서 요구되면 커스텀을 할수 없는 걸 커스텀하기 위한 고생은 아주 아찔합니다😅

기본기능만 제공하고 스타일링과 커스텀은 우리가 직접 하면 어떨까요? 그래서 Radix와 같이 기본적인 컴포넌트의 골격만 제공하고, 스타일링을 직접 하는 방식은 훨씬 더 좋은 발상이었습니다. headless의 탄생이죠. 그러나 필요한 모든 스타일링을 전부 다 처음부터하는 것은 당장은 활용하기 어려운 점이 있습니다.

shadcn/ui는 흥미로운 해법을 제시합니다. Radix의 headless 기능을 기반으로, 기본적인 구조에 깔끔하지만 개성 없는 디자인을 제공합니다.(개성없다 했지만 엄청 이쁩니다)

여기에 Tailwind를 활용한 스타일링 레이어를 통해 디자인 시스템을 구축하고, Tailwind 설정을 조정하여 개성 있는 디자인 시스템을 점진적으로 구축할 수 있습니다.

커스텀 컴포넌트를 만들기 어려운 단점은 어떻게 극복했을까요? npm 패키지가 아닌 copy-paste 방식으로 컴포넌트 코드를 직접 제공하여, TypeScript의 완벽한 타입 지원과 함께 원하는 부분을 얼마든지 커스터마이징할 수 있도록 했습니다.

디자인 시스템과 UI컴포넌트에 범주에사 가장 핫한 점진적인 디자인 시스템을 만들기 위해 고민하고 멋진 해법을 제시한 shadcn/ui에 대한 좋은 글이 있어 공유합니다.

https://siosio3103.medium.com/shadcn-ui-%EC%9D%98-%ED%95%B4%EB%B6%80-ebd469c34614

ps: 이 글은 Korean FE Article 뉴스레터를 통해 알게 되었습니다 🙂

버튼, Input, DatePicker 등 자주 쓰는 UI 전용 컴포넌트들이 있습니다. 익숙하지만, 이걸 처음부터 Tailwind 등을 사용해 맨땅부터 다시 컴포넌트를 다 만들기에는 작업량이 너무 방대합니다. 처음에는 UI정도라 도전을 해보지만 키입력과 겉은 상호작용도 중요하니까요. 만약 a11y처럼 접근성까지 고려한다면 너무 큰 작업이 되겠네요. 그래서 우리는 남들이 잘 만들어둔 전통적인 디자인 시스템인 MUI, Ant Design, Chakra 등을 사용했습니다. 이들 컴포넌트 구성은 탄탄하지만, 단점은 그들의 디자인을 따라야만 합니다. 그래서 디자인을 고쳐보고자 하지믄 이미 개성을 갖춘 디자인 시스템의 스타일링을 커스텀하는 건 여간 고된 일이 아니죠. 또한 그들이 만들어주지 않는 컴포넌트가 기획에서 요구되면 커스텀을 할수 없는 걸 커스텀하기 위한 고생은 아주 아찔합니다😅 기본기능만 제공하고 스타일링과 커스텀은 우리가 직접 하면 어떨까요? 그래서 Radix와 같이 기본적인 컴포넌트의 골격만 제공하고, 스타일링을 직접 하는 방식은 훨씬 더 좋은 발상이었습니다. headless의 탄생이죠. 그러나 필요한 모든 스타일링을 전부 다 처음부터하는 것은 당장은 활용하기 어려운 점이 있습니다. shadcn/ui는 흥미로운 해법을 제시합니다. Radix의 headless 기능을 기반으로, 기본적인 구조에 깔끔하지만 개성 없는 디자인을 제공합니다.(개성없다 했지만 엄청 이쁩니다) 여기에 Tailwind를 활용한 스타일링 레이어를 통해 디자인 시스템을 구축하고, Tailwind 설정을 조정하여 개성 있는 디자인 시스템을 점진적으로 구축할 수 있습니다. 커스텀 컴포넌트를 만들기 어려운 단점은 어떻게 극복했을까요? npm 패키지가 아닌 copy-paste 방식으로 컴포넌트 코드를 직접 제공하여, TypeScript의 완벽한 타입 지원과 함께 원하는 부분을 얼마든지 커스터마이징할 수 있도록 했습니다. 디자인 시스템과 UI컴포넌트에 범주에사 가장 핫한 점진적인 디자인 시스템을 만들기 위해 고민하고 멋진 해법을 제시한 shadcn/ui에 대한 좋은 글이 있어 공유합니다. https://siosio3103.medium.com/shadcn-ui-%EC%9D%98-%ED%95%B4%EB%B6%80-ebd469c34614 ps: 이 글은 Korean FE Article 뉴스레터를 통해 알게 되었습니다 🙂

<디자인시스템 컴포넌트 UI 라이브러리 가장 진화된 버전 shad

지금까지 다녔던 회사를 세어보니 5개네요.
약 15년간 일했으니 평균 3년 정도를 다녔나 봅니다.
스타트업부터 중소기업, 대기업까지.

저는 제가 다닌 모든 회사의 주식을 어떤 방식으로든 보유했습니다.

1. 우리사주로 얻은 것도 있었고
2. 스톡옵션으로 받은 것
3. 상장 회사 주식을 시장에서 매입한 것
4. 전환사채로 회사에 돈을 빌려주고 나중에 주식으로 전환한 일
5. 창업자들의 기존 주식을 산 것까지
소소한 이익을 얻은 것도 있었고 완전 대박 그리고 완전 망함 까지.
이 또한 다양한 경험들을 했습니다.

투자라고 하면 주식이나 부동산 투자가 먼저 생각나겠지만,
회사를 선택하는 것이야말로 그보다 중요한 투자 일지 모릅니다.
(또 다른 중요 투자로는 결혼이 있겠습니다)

내 주위에 어떤 사람이 있을 것인지.
하루 중 가장 많은 시간을 투자하는 그 일이 얼마나 즐거울 것인지.
얼마나 큰 부를 얻을 것인지.
이런 것들은 삶에서 정말 중요한 요소잖아요?

회사를 고른다는 건 이런 중요한 선택을 하는 것인데,
이렇게 고민하고 선택한 회사의 주식을 (살 수 있는데도) 사지 않는 것이 좀 이상했습니다.
뭔가 모순되는 것처럼 느껴졌거든요.

회사가 잘 될 거라는 기대가 없고 함께 일하는 동료들을 존경하지도 않는다면 왜 다니기로 선택한 거지?
월급만을 위해서?
한 번 선택하면 인생의 3년이 지나가는데, 과연 나는 좋은 선택을 한 것일까?

다니는 회사의 주식을 산다는 것은 회사와 나를 엮는 일입니다.
나와 회사의 목표를 일치 시킨다고 말할 수도 있겠습니다.
이렇게 하면 주인 의식을 갖기도 좋습니다. 소소하지만, 진짜 법적 주인이 되는 거니까.
저는 이렇게 일하는 것이 더 즐겁습니다.

어떤 사람들은 분산 투자를 하라는 뜻으로 이렇게 말합니다.
“왜 계란을 한 바구니에 담으려고 하시나요?”
그러면 저는 이런 생각이 듭니다.

‘자기가 선택한 회사를 못 믿고 다른 회사를 믿을 거면 그냥 그 다른 회사 다니는 게 좋지 않을까?’

저는 제가 모르는 사람들이 일하는 회사 주식보다는 저와 제가 선택한 동료들이 일하는 회사의 주식을 갖고 싶거든요.

한편으로 이런 생각도 해보면 좋습니다.
나는 과연 회사를 충분히 신중하게 선택하는가?
나와 맞는 직무가 있다는 이유만으로 선택한 건 아닐까?

회사 한 번 선택하면 인생의 빛나는 시절 몇 년이 순식간에 지나갑니다.
그럴만한 가치가 있는 회사와 시간을 보내야 합니다.

지금까지 다녔던 회사를 세어보니 5개네요. 약 15년간 일했으니 평균 3년 정도를 다녔나 봅니다. 스타트업부터 중소기업, 대기업까지. 저는 제가 다닌 모든 회사의 주식을 어떤 방식으로든 보유했습니다. 1. 우리사주로 얻은 것도 있었고 2. 스톡옵션으로 받은 것 3. 상장 회사 주식을 시장에서 매입한 것 4. 전환사채로 회사에 돈을 빌려주고 나중에 주식으로 전환한 일 5. 창업자들의 기존 주식을 산 것까지 소소한 이익을 얻은 것도 있었고 완전 대박 그리고 완전 망함 까지. 이 또한 다양한 경험들을 했습니다. 투자라고 하면 주식이나 부동산 투자가 먼저 생각나겠지만, 회사를 선택하는 것이야말로 그보다 중요한 투자 일지 모릅니다. (또 다른 중요 투자로는 결혼이 있겠습니다) 내 주위에 어떤 사람이 있을 것인지. 하루 중 가장 많은 시간을 투자하는 그 일이 얼마나 즐거울 것인지. 얼마나 큰 부를 얻을 것인지. 이런 것들은 삶에서 정말 중요한 요소잖아요? 회사를 고른다는 건 이런 중요한 선택을 하는 것인데, 이렇게 고민하고 선택한 회사의 주식을 (살 수 있는데도) 사지 않는 것이 좀 이상했습니다. 뭔가 모순되는 것처럼 느껴졌거든요. 회사가 잘 될 거라는 기대가 없고 함께 일하는 동료들을 존경하지도 않는다면 왜 다니기로 선택한 거지? 월급만을 위해서? 한 번 선택하면 인생의 3년이 지나가는데, 과연 나는 좋은 선택을 한 것일까? 다니는 회사의 주식을 산다는 것은 회사와 나를 엮는 일입니다. 나와 회사의 목표를 일치 시킨다고 말할 수도 있겠습니다. 이렇게 하면 주인 의식을 갖기도 좋습니다. 소소하지만, 진짜 법적 주인이 되는 거니까. 저는 이렇게 일하는 것이 더 즐겁습니다. 어떤 사람들은 분산 투자를 하라는 뜻으로 이렇게 말합니다. “왜 계란을 한 바구니에 담으려고 하시나요?” 그러면 저는 이런 생각이 듭니다. ‘자기가 선택한 회사를 못 믿고 다른 회사를 믿을 거면 그냥 그 다른 회사 다니는 게 좋지 않을까?’ 저는 제가 모르는 사람들이 일하는 회사 주식보다는 저와 제가 선택한 동료들이 일하는 회사의 주식을 갖고 싶거든요. 한편으로 이런 생각도 해보면 좋습니다. 나는 과연 회사를 충분히 신중하게 선택하는가? 나와 맞는 직무가 있다는 이유만으로 선택한 건 아닐까? 회사 한 번 선택하면 인생의 빛나는 시절 몇 년이 순식간에 지나갑니다. 그럴만한 가치가 있는 회사와 시간을 보내야 합니다.

회사 선택은 어떤 재테크보다도 중요한 투자

A mountain of spam PRs landed in the Express.js project repo after a popular YouTube tutorial used it as an example for contributing to open source. This put a spotlight on the mandate for job seekers to find a way to contribute to OSS.

Express.js Spam PRs Incident Highlights the Commoditization of Open Source Contributions - Socket

Node.js의 오래된 웹 프레임워크인 Express.js 저장소에 대량으로 스팸 PR이 등록되는 문제가 발생했습니다.

구독자가 486만명이나 있는 한 인기 유튜버가 GitHub에서 Pull Request로 기여하는 방법을 설명하면서 express.js 저장소를 대상으로 설명한게 발단이 되었습니다. 유튜버는 Express.js를 포크해서 사용했지만 시청자들이 아마 포크를 정확히 구분하지 못해서 이를 따라하는 과정에서 express.js 원 저장소에서 README를 수정하는 수십개의 Pull Request가 올라오게 되었고 메인테이너들은 이를 계속 닫느라고 한참동안 고생을 했습니다.

소프트웨어 엔지니어가 인기 직종이 되고 오픈소스 기여가 하나의 스팩처럼 되면서 오픈소스 생태계에 안좋은 영향을 주고 있다는 의견도 나오고 대부분의 사람은 오픈소스에 기여하지 말아야 한다는 이야기까지 나오고 있습니다.

오픈소스를 이해하고 기여하는 것이 중요하다고 생각하는 편이라 이런 사건이 벌어질 때마다 많은 생각이 교차합니다.

https://socket.dev/blog/express-js-spam-prs-commoditization-of-open-source

Node.js의 오래된 웹 프레임워크인 Express.js 저장소에 대량으로 스팸 PR이 등록되는 문제가 발생했습니다. 구독자가 486만명이나 있는 한 인기 유튜버가 GitHub에서 Pull Request로 기여하는 방법을 설명하면서 express.js 저장소를 대상으로 설명한게 발단이 되었습니다. 유튜버는 Express.js를 포크해서 사용했지만 시청자들이 아마 포크를 정확히 구분하지 못해서 이를 따라하는 과정에서 express.js 원 저장소에서 README를 수정하는 수십개의 Pull Request가 올라오게 되었고 메인테이너들은 이를 계속 닫느라고 한참동안 고생을 했습니다. 소프트웨어 엔지니어가 인기 직종이 되고 오픈소스 기여가 하나의 스팩처럼 되면서 오픈소스 생태계에 안좋은 영향을 주고 있다는 의견도 나오고 대부분의 사람은 오픈소스에 기여하지 말아야 한다는 이야기까지 나오고 있습니다. 오픈소스를 이해하고 기여하는 것이 중요하다고 생각하는 편이라 이런 사건이 벌어질 때마다 많은 생각이 교차합니다. https://socket.dev/blog/express-js-spam-prs-commoditization-of-open-source

Socket

The https://incrediboxsprunki.org/ encourages players to discover unique beats and melodies by trying out various combinations.

a 백엔드 개발자

tommchris

동아대학교 컴퓨터공학과

허세진

소프트웨어 엔지니어

김지섭

Data Analytics Engineer

이인영

#데이터분석 #데이터애널리스트 #스타트업 #창업 #사이드프로젝트 #3D아티스트 

Java/ASP 개발자

웹 개발자

Java 개발자

여행 서비스 백엔드 및 프론트엔드 개발, 인프라 관리

시니어 웹 개발자

시니어 소프트웨어 엔지니어

javascript

Kubernetes

React

typescript

Next.js

Node.js

Github

Argo CD

프론트엔드, 백엔드, 모바일 개발팀을 리드하며 OTT 서비스 개발

개발팀 Lead

컴퓨터학과

Outsider

블로그

트위터

오픈소스를 좋아하는 개발자로 종종 블로그에 글을 쓰고 있습니다. 현재는 인프라 관련 일을 하고 있으며 새로운 트랜드를 파악하는 걸 즐겨하고 즐겁게 코딩하는걸 좋아합니다.

댓글 1

비슷한 게시물

주간 인기 TOP 10

추천 프로필