🙅‍♂️ 내가 하지 않는 생각
- 이걸로 무조건 성공해서 돈 벌어야지
- 많은 기능 넣으면 사용자들이 좋아하겠지?
- 이왕 만드는 거 완벽하게 만들어야지

🙆‍♀️ 내가 하는 생각
- 사람들이 불편해 하는 점이 있는 것 같네. 한번 만들어 보자
- 실패해도 배운 점이 있도록 평소 사용하고 싶었던 기술이나 주제를 적용해보자
- 필요한 기능 1개만 추려서 빠르게 만들어 보자
- 완벽하기보단 우선 만들어보자. 반응 없으면 버리고, 반응이 있다면 그 때 개선하자

🙅‍♂️ 내가 하지 않는 생각- 이걸로 무조건 성공해서 돈 벌어야지 - 많은 기능 넣으면 사용자들이 좋아하겠지? - 이왕 만드는 거 완벽하게 만들어야지 🙆‍♀️ 내가 하는 생각- 사람들이 불편해 하는 점이 있는 것 같네. 한번 만들어 보자 - 실패해도 배운 점이 있도록 평소 사용하고 싶었던 기술이나 주제를 적용해보자 - 필요한 기능 1개만 추려서 빠르게 만들어 보자 - 완벽하기보단 우선 만들어보자. 반응 없으면 버리고, 반응이 있다면 그 때 개선하자

사이드 프로젝트 만들 때

1. 불확실성을 견디는 사람
불확실한 상황에도 묵묵히 1인분 이상을 해내는 사람

2. 불확실성을 즐기는 사람
불확실한 상황에서 만난 문제를 해결하길 즐기는 사람

3. 불확실성을 기회로 여기는 사람
불확실한 상황이 오히려 성장과 인정의 기회라고 믿는 사람

1. 불확실성을 견디는 사람불확실한 상황에도 묵묵히 1인분 이상을 해내는 사람 2. 불확실성을 즐기는 사람불확실한 상황에서 만난 문제를 해결하길 즐기는 사람 3. 불확실성을 기회로 여기는 사람불확실한 상황이 오히려 성장과 인정의 기회라고 믿는 사람

스타트업에서 모셔가는 개발자

그러니까 불확실한 사람을 모셔간다 이거죠!?

MongoDB는 NoSQL 데이터베이스로, 그 유연성 덕분에 Spring Boot와 자주 함께 사용됩니다. Spring Boot에서는 Spring Data MongoDB를 통해 MongoDB 연동을 쉽게 할 수 있습니다. Spring Data MongoDB는 두 가지 주요 방식을 제공합니다. 바로 MongoTemplate와 MongoRepository 입니다. 이번 포스팅에서는 이 두 가지 방법을 비교하고, 어떤 상황에서 각각을 사용하는 것이 좋은지 살펴보겠습니다. MongoRepository와 MongoTemplate[MongoRepository] MongoRepository는 레파지토리 패턴을 기반으로 한 인터페이스입니다. 기본적인 CRUD 메서드를 자동으로 제공합니다. Spring Data JPA와..

Spring Boot의 MongoDB 연동: MongoTemplate vs MongoRepository

MongoDB는 NoSQL 데이터베이스로, 그 유연성 덕분에 Spring Boot와 자주 함께 사용됩니다. Spring Boot에서는 Spring Data MongoDB를 통해 MongoDB 연동을 쉽게 할 수 있습니다. Spring Data MongoDB는 두 가지 주요 방식을 제공합니다.

바로 MongoTemplate와 MongoRepository 입니다.
 
이번 포스팅에서는 이 두 가지 방법을 비교하고, 어떤 상황에서 각각을 사용하는 것이 좋은지 살펴보겠습니다.
 
[MongoRepository]
MongoRepository는 레파지토리 패턴을 기반으로 한 인터페이스입니다. 기본적인 CRUD 메서드를 자동으로 제공합니다. Spring Data JPA와 비슷하게 작동하며, MongoDB 데이터를 처리하는 데 매우 간단한 방법을 제공합니다.
 
장점
 * 기본적인 CRUD 작업을 자동으로 처리
 * 코드가 매우 간결하고 유지보수가 쉬움
 * 메서드 이름만으로 커스텀 쿼리를 작성할 수 있음 (ex. findByCategory)
단점
 * 복잡한 쿼리 작업에서는 제한적
 * 커스터마이징이 어렵고 고급 기능을 구현하기에 한계가 있음
 
[MongoTemplate]
MongoTemplate은 Spring의 템플릿 패턴을 사용한 MongoDB 연동 방식입니다. 더 복잡한 MongoDB 제어가 가능하며, 어려운 쿼리 작성에 적합합니다.
 
장점
 * 복잡한 쿼리나 커스텀 작업을 더 쉽게 수행 가능
 * MongoDB와의 깊이 있는 상호작용에 적합
 * 더 세밀한 데이터 처리와 제어가 가능
단점
 * 기본적인 CRUD 작업도 코드로 직접 작성해야 하므로 코드가 다소 복잡해짐
 * 레파지토리 패턴보다 다소 비효율적일 수 있음
 
[MongoRepository 사용 예시]

Product 엔티티
@Document(collection = "products")
public class Product {
 @Id
 private String id;
 private String name;
 private String category;
}

ProductRepository 인터페이스
public interface ProductRepository extends MongoRepository<Product, String> {
 List<Product> findByCategory(String category);
}

MongoRepository를 확장한 ProductRepository를 정의하였습니다. CRUD 메서드는 기본으로 제공되며, 커스텀으로 findByCategory 같은 메서드를 쉽게 추가할 수 있습니다.
 
CRUD 작업 사용 예시
@Autowired
private ProductRepository productRepository;

public void addProduct(Product product) {
 productRepository.save(product);
}

public List<Product> getProductsByCategory(String category) {
 return productRepository.findByCategory(category);
}

이처럼 MongoRepository를 사용하면 간단한 CRUD 작업을 매우 직관적으로 처리할 수 있습니다.
 
[MongoTemplate 사용 예시]
이번에는 같은 Product 엔티티를 사용하여 MongoTemplate을 이용한 예제를 살펴보겠습니다.
 
MongoTemplate으로 복잡한 쿼리 작성
@Autowired
private MongoTemplate mongoTemplate;

public List<Product> findProductsByCategory(String category) {
 Query query = new Query();
 query.addCriteria(Criteria.where("category").is(category));
 return mongoTemplate.find(query, Product.class);
}

위 코드에서는 MongoTemplate을 사용하여 MongoDB 쿼리를 직접 사용했습니다. Criteria와 Query 객체를 이용해 더 복잡한 쿼리나 고급 기능을 쉽게 구현할 수 있습니다.
 
CRUD 작업 처리 
public void addProduct(Product product) {
 mongoTemplate.save(product);
}

public Product getProductById(String id) {
 return mongoTemplate.findById(id, Product.class);
}

MongoTemplate을 사용하면 모든 작업을 수동으로 처리해야 하지만, 그만큼 더 세밀하게 제어할 수 있는 장점이 있습니다.
 
[어떤 것을 선택해야 할까?]
MongoRepository를 사용해야 할 때:
 * 기본적인 CRUD 작업을 빠르게 처리해야 할 때
 * 코드의 간결함과 유지보수의 용이함이 중요할 때
MongoTemplate을 사용해야 할 때:
 * 복잡한 쿼리나 트랜잭션 처리가 필요한 경우
 * 데이터베이스와의 더 세밀한 상호작용이 필요할 때
 
[결론]
MongoDB와 Spring Boot의 연동에서 MongoRepository와 MongoTemplate은 각각 다른 용도에 맞춰 설계된 도구입니다. 저는 실제 프로젝트에서 bulk upsert 기능이 필요한 상황을 겪었는데, MongoRepository에는 해당 기능이 기본적으로 제공되지 않아, 더 유연한 MongoTemplate을 사용할 수밖에 없었습니다. 물론 upsert를 여러 번 호출하는 방법도 가능하지만, 이는 비효율적이므로 MongoTemplate을 통해 간단히 처리할 수 있었습니다.
 
반면, 단순한 조회 작업에서는 MongoRepository를 사용했습니다. MongoTemplate보다 코드가 훨씬 깔끔하고 유지보수하기가 쉬웠기 때문입니다. 이처럼 MongoRepository는 기본적인 작업에 최적화되어 있고, MongoTemplate은 고급 작업에서 강력한 기능을 제공합니다.
 
결국 중요한 것은 프로젝트의 요구사항에 맞춰 이 두 방식을 적절히 선택하거나 혼합하여 사용하는 것입니다. 각 도구가 제공하는 장점을 최대한 활용해, 프로젝트에 가장 적합한 솔루션을 찾는 것이 성공적인 MongoDB 연동의 핵심입니다.

MongoDB는 NoSQL 데이터베이스로, 그 유연성 덕분에 Spring Boot와 자주 함께 사용됩니다. Spring Boot에서는 Spring Data MongoDB를 통해 MongoDB 연동을 쉽게 할 수 있습니다. Spring Data MongoDB는 두 가지 주요 방식을 제공합니다. 바로&nbsp;MongoTemplate와&nbsp;MongoRepository 입니다.&nbsp;이번 포스팅에서는 이 두 가지 방법을 비교하고, 어떤 상황에서 각각을 사용하는 것이 좋은지 살펴보겠습니다.&nbsp;[MongoRepository]MongoRepository는 레파지토리 패턴을 기반으로 한 인터페이스입니다. 기본적인 CRUD 메서드를 자동으로 제공합니다. Spring Data JPA와 비슷하게 작동하며, MongoDB 데이터를 처리하는 데 매우 간단한 방법을 제공합니다.&nbsp;장점<ul ><li>기본적인 CRUD 작업을 자동으로 처리</li><li>코드가 매우 간결하고 유지보수가 쉬움</li><li>메서드 이름만으로 커스텀 쿼리를 작성할 수 있음 (ex. findByCategory)</li></ul>단점<ul ><li>복잡한 쿼리 작업에서는 제한적</li><li>커스터마이징이 어렵고 고급 기능을 구현하기에 한계가 있음</li></ul>&nbsp;[MongoTemplate]MongoTemplate은 Spring의 템플릿 패턴을 사용한 MongoDB 연동 방식입니다. 더 복잡한 MongoDB 제어가 가능하며, 어려운 쿼리 작성에 적합합니다.&nbsp;장점<ul ><li>복잡한 쿼리나 커스텀 작업을 더 쉽게 수행 가능</li><li>MongoDB와의 깊이 있는 상호작용에 적합</li><li>더 세밀한 데이터 처리와 제어가 가능</li></ul>단점<ul ><li>기본적인 CRUD 작업도 코드로 직접 작성해야 하므로 코드가 다소 복잡해짐</li><li>레파지토리 패턴보다 다소 비효율적일 수 있음</li></ul>&nbsp;[MongoRepository 사용 예시] Product 엔티티<pre ><code class="language-java">@Document(collection = "products")
public class Product {
 @Id
 private String id;
 private String name;
 private String category;
}</code></pre>ProductRepository 인터페이스<pre ><code class="language-java">public interface ProductRepository extends MongoRepository&lt;Product, String&gt; {
 List&lt;Product&gt; findByCategory(String category);
}</code></pre>MongoRepository를 확장한 ProductRepository를 정의하였습니다. CRUD 메서드는 기본으로 제공되며, 커스텀으로 findByCategory 같은 메서드를 쉽게 추가할 수 있습니다.&nbsp;CRUD 작업 사용 예시<pre ><code class="language-java">@Autowired
private ProductRepository productRepository;

public void addProduct(Product product) {
 productRepository.save(product);
}

public List&lt;Product&gt; getProductsByCategory(String category) {
 return productRepository.findByCategory(category);
}</code></pre>이처럼 MongoRepository를 사용하면 간단한 CRUD 작업을 매우 직관적으로 처리할 수 있습니다.&nbsp;[MongoTemplate 사용 예시]이번에는 같은 Product 엔티티를 사용하여 MongoTemplate을 이용한 예제를 살펴보겠습니다.&nbsp;MongoTemplate으로 복잡한 쿼리 작성<pre ><code class="language-java">@Autowired
private MongoTemplate mongoTemplate;

public List&lt;Product&gt; findProductsByCategory(String category) {
 Query query = new Query();
 query.addCriteria(Criteria.where("category").is(category));
 return mongoTemplate.find(query, Product.class);
}</code></pre>위 코드에서는 MongoTemplate을 사용하여 MongoDB 쿼리를 직접 사용했습니다. Criteria와 Query 객체를 이용해 더 복잡한 쿼리나 고급 기능을 쉽게 구현할 수 있습니다.&nbsp;CRUD 작업 처리&nbsp;<pre ><code class="language-java">public void addProduct(Product product) {
 mongoTemplate.save(product);
}

public Product getProductById(String id) {
 return mongoTemplate.findById(id, Product.class);
}</code></pre>MongoTemplate을 사용하면 모든 작업을 수동으로 처리해야 하지만, 그만큼 더 세밀하게 제어할 수 있는 장점이 있습니다.&nbsp;[어떤 것을 선택해야 할까?]MongoRepository를 사용해야 할 때:<ul ><li>기본적인 CRUD 작업을 빠르게 처리해야 할 때</li><li>코드의 간결함과 유지보수의 용이함이 중요할 때</li></ul>MongoTemplate을 사용해야 할 때:<ul ><li>복잡한 쿼리나 트랜잭션 처리가 필요한 경우</li><li>데이터베이스와의 더 세밀한 상호작용이 필요할 때</li></ul>&nbsp;[결론]MongoDB와 Spring Boot의 연동에서 MongoRepository와 MongoTemplate은 각각 다른 용도에 맞춰 설계된 도구입니다. 저는 실제 프로젝트에서 bulk upsert 기능이 필요한 상황을 겪었는데, MongoRepository에는 해당 기능이 기본적으로 제공되지 않아, 더 유연한 MongoTemplate을 사용할 수밖에 없었습니다. 물론 upsert를 여러 번 호출하는 방법도 가능하지만, 이는 비효율적이므로 MongoTemplate을 통해 간단히 처리할 수 있었습니다.&nbsp;반면, 단순한 조회 작업에서는 MongoRepository를 사용했습니다. MongoTemplate보다 코드가 훨씬 깔끔하고 유지보수하기가 쉬웠기 때문입니다. 이처럼 MongoRepository는 기본적인 작업에 최적화되어 있고, MongoTemplate은 고급 작업에서 강력한 기능을 제공합니다.&nbsp;결국 중요한 것은 프로젝트의 요구사항에 맞춰 이 두 방식을 적절히 선택하거나 혼합하여 사용하는 것입니다. 각 도구가 제공하는 장점을 최대한 활용해, 프로젝트에 가장 적합한 솔루션을 찾는 것이 성공적인 MongoDB 연동의 핵심입니다.

덕토피아

MongoRepository vs MongoTemplate 차이와 활용

이모카세 1호는 매일 같이 우리 식탁에 오르는 음식으로 100명의 요리사 중 6위를 차지했어요. 일상적인 것으로 심사위원의 마음을 얻은 결과죠.

개발자인 우리도 일상적인 것으로 유저의 마음을 얻을 수 있어요. 화려하고 멋진, 최신의 기술이 아니라 일상적인 기술로도 유저의 마음을 얻을 수 있어요.

여러분이 일상에서 다루는 기술의 가능성은 작지 않아요. 새로운 기술은 필요한 순간에 적절하게 사용하면 그만이에요.

매일 반복되는 일상의 기술만 다룬다고 너무 조급해하지 않아도 괜찮아요. 여러분은 내공을 쌓고 계신 거니까요.

이모카세 1호는 매일 같이 우리 식탁에 오르는 음식으로 100명의 요리사 중 6위를 차지했어요. 일상적인 것으로 심사위원의 마음을 얻은 결과죠. 개발자인 우리도 일상적인 것으로 유저의 마음을 얻을 수 있어요. 화려하고 멋진, 최신의 기술이 아니라 일상적인 기술로도 유저의 마음을 얻을 수 있어요. 여러분이 일상에서 다루는 기술의 가능성은 작지 않아요. 새로운 기술은 필요한 순간에 적절하게 사용하면 그만이에요. 매일 반복되는 일상의 기술만 다룬다고 너무 조급해하지 않아도 괜찮아요. 여러분은 내공을 쌓고 계신 거니까요.

흑백요리사, 이모카세가 대단한 이유

코틀린에서 웹소켓에 액터모델을 연결시켜  분산 상태처리가 가능한 웹소켓 모델로 업그레이드 시도를 해보겠습니다.

 * more : https://wiki.webnori.com/x/dYGZBQ

코틀린에서 웹소켓에 액터모델을 연결시켜&nbsp; 분산 상태처리가 가능한 웹소켓 모델로 업그레이드 시도를 해보겠습니다. <ul ><li>more : https://wiki.webnori.com/x/dYGZBQ</li></ul>

코틀린에서 웹소켓을 우아하게 사용하기

Online JSON view, format, minify, validate and compare. It also provides graph view to preview JSON data, semantic comparing two JSON diffs, convert JSON to CSV or CSV to JSON and support jq online.

JSON For You | The best online JSON tool

json 을 table로 변환하는 툴들은 많이 봤었는데, 이렇게 graph로 변환까지 해주는 툴은 처음보는 것 같아요!
구조 비교 & 텍스트 비교로 2개의 JSON간 차이점 빠른 확인도 가능해서 더 좋아요!

https://json4u.com/editor

json 을 table로 변환하는 툴들은 많이 봤었는데, 이렇게 graph로 변환까지 해주는 툴은 처음보는 것 같아요! 구조 비교 &amp; 텍스트 비교로 2개의 JSON간 차이점 빠른 확인도 가능해서 더 좋아요! https://json4u.com/editor

JSON For You

파워풀한 json 시각화툴

업무에 유용하겠어요 감사합니다!!

개발자의 인문학 공부를 함 시작해볼까 하는데요. ㅎㅎ 가장 쉽게(?) 생각 할 수 있는 방법으로 인문학 관련한 책 100권 읽기 프로젝트를 함 해보려고 하는데, 많은 인문학도 여러분들의 추천 부탁드리겠습니다. ㅎㅎ 🙏

인문학 책의 범위는 과연 어디까지인가부터가 어렵더라고요. 철학책부터..소설책도 인문학책이라고 하면 그럴 수도 있으니까요. 그래서, 그냥 추천 받아서 읽어보는 것으로 ㅎㅎ

이 프로젝트는 원래 예전부터 해볼라고 했지만 밍기적거리고 있었는데, 우리나라가 노벨 문학상을 탄 것을 보니 바로 시작해야겠다는 생각이 들었습니다. ㅎㅎ 노벨상의 긍정적인 효과?! 😆

암튼 무식한 공돌이를 위해 많은 인문학도 여러분들의 도움 부탁드립니다. 🙏

개발자의 인문학 공부를 함 시작해볼까 하는데요. ㅎㅎ 가장 쉽게(?) 생각 할 수 있는 방법으로 인문학 관련한 책 100권 읽기 프로젝트를 함 해보려고 하는데, 많은 인문학도 여러분들의 추천 부탁드리겠습니다. ㅎㅎ 🙏 인문학 책의 범위는 과연 어디까지인가부터가 어렵더라고요. 철학책부터..소설책도 인문학책이라고 하면 그럴 수도 있으니까요. 그래서, 그냥 추천 받아서 읽어보는 것으로 ㅎㅎ 이 프로젝트는 원래 예전부터 해볼라고 했지만 밍기적거리고 있었는데, 우리나라가 노벨 문학상을 탄 것을 보니 바로 시작해야겠다는 생각이 들었습니다. ㅎㅎ 노벨상의 긍정적인 효과?! 😆 암튼 무식한 공돌이를 위해 많은 인문학도 여러분들의 도움 부탁드립니다. 🙏

‪제가.. 그래도 기술 서적 외에도 책은 많이 읽긴 합니다. 어릴 땐 하루종일 책만 읽고, 학기동안 학교 도서관 책을 전부 읽는 기행을 보이고 그래서 부모님이 걱정하실 정도였어요. 초딩때 푸코의 추 이런 것도 읽긴 했음. 기억이 하나도 안나서 그렇지 ㅋㅋㅋ‬

The 2024 Tidelift state of the open source maintainer report

오픈소스 메인테이너를 지우너하는 플랫폼인 Tidelift에서 오픈소스 메인테이너 400여 명에게 설문조사를 진행한 결과입니다.

1. 메인테이너 중 60%는 여전히 작업 보수를 받지 못합니다.
2. 메인테이너가 더 많은 보수를 받을수록 프로젝트에는 더 많은 개선이 이루어집니다.
3. 32%는 다른 조직이나 개인으로부터 보수를 받고 고용주로부터 보수를 받는 메인테이너는 24%로 소폭 감소했습니다.
4. 메인테이너는 몇년전보다 보안에 3배 더 많은 시간을 쓰고 있습니다.
5. 메인테이너가 보수를 받는 경우 OpenSSF 스코어카드에 부합할 가능성이 훨씬 더 높습니다.
6. 보수를 받는 메인테이너는 보수를 받지 않는 메인테이너에 비해 중요한 보안 관행을 구현할 가능성이 더 높습니다.
7. 보수를 받는 메인테이너는 보수를 받지 않는 메인테이너에 비해 더 많은 유지 보수 작업과 문서화 작업을 합니다.
8. 거의 절반의 메인테이너가 자신의 작업이 과소 평가되고 무의미하다고 느낍니다.
9. xy utils 해킹 사건 이후 메인테이너의 2/3는 컨트리뷰터를 덜 신뢰합니다.
10. AI 기반 코딩 도구는 번창하고 있지만 메인테이너들은 코드 품질과 스팸 PR 등으로 이한 우려를 하고 있습니다.
11. 더 젊은 오픈소스 메인테이너는 AI 기반 코딩 도구를 사용할 가능성이 훨씬 더 큽니다.
12. 오픈소스 메인테이너 커뮤니티가 점점 나이가 들어가고 있습니다.

전혀 몰랐던 내용이 있는건 아니지만 좀더 확실하게 메인테이너에게 작업 보수를 주는 것이 중요하다는 것을 알게 되었고 메인테이너들이 더 자신들의 작업에 집중하고 더 많은 오픈소스 메인테이너가 참여할 수 있는 환경이 조성되어야 한다는 생각이 더 많이 들었습니다.

https://explore.tidelift.com/2024-survey

오픈소스 메인테이너를 지우너하는 플랫폼인 Tidelift에서 오픈소스 메인테이너 400여 명에게 설문조사를 진행한 결과입니다. 1. 메인테이너 중 60%는 여전히 작업 보수를 받지 못합니다.2. 메인테이너가 더 많은 보수를 받을수록 프로젝트에는 더 많은 개선이 이루어집니다.3. 32%는 다른 조직이나 개인으로부터 보수를 받고 고용주로부터 보수를 받는 메인테이너는 24%로 소폭 감소했습니다.4. 메인테이너는 몇년전보다 보안에 3배 더 많은 시간을 쓰고 있습니다.5. 메인테이너가 보수를 받는 경우 OpenSSF 스코어카드에 부합할 가능성이 훨씬 더 높습니다.6. 보수를 받는 메인테이너는 보수를 받지 않는 메인테이너에 비해 중요한 보안 관행을 구현할 가능성이 더 높습니다.7. 보수를 받는 메인테이너는 보수를 받지 않는 메인테이너에 비해 더 많은 유지 보수 작업과 문서화 작업을 합니다.8. 거의 절반의 메인테이너가 자신의 작업이 과소 평가되고 무의미하다고 느낍니다.9. xy utils 해킹 사건 이후 메인테이너의 2/3는 컨트리뷰터를 덜 신뢰합니다.10. AI 기반 코딩 도구는 번창하고 있지만 메인테이너들은 코드 품질과 스팸 PR 등으로 이한 우려를 하고 있습니다.11. 더 젊은 오픈소스 메인테이너는 AI 기반 코딩 도구를 사용할 가능성이 훨씬 더 큽니다.12. 오픈소스 메인테이너 커뮤니티가 점점 나이가 들어가고 있습니다. 전혀 몰랐던 내용이 있는건 아니지만 좀더 확실하게 메인테이너에게 작업 보수를 주는 것이 중요하다는 것을 알게 되었고 메인테이너들이 더 자신들의 작업에 집중하고 더 많은 오픈소스 메인테이너가 참여할 수 있는 환경이 조성되어야 한다는 생각이 더 많이 들었습니다. https://explore.tidelift.com/2024-survey

Tidelift

GitHub 에서 자주보던 브랜드인데 구체적으로 뭘하는지믄 몰랐어요. 소개해주셔서 감사합니다.

드림웍스의 애니메이션 영화 “와일드 로봇”을 봤다. 영화의 주제는 아니지만, 보는 내내 마음이란 무엇인가, 로봇도 마음을 가질 수 있는 것인가라는 진부한(?) 생각을 해 보았는데, 결론은 로봇도 마음을 가질 수 있다였다.

AI의 마음은 고사하고 지능도 가짜다라는 말도 많이 하고, 마음과 지능의 정의가 명확하지 않기도 하지만, 지금은 아닐지 몰라도 AI가 지능을 가질 수 있다는 것은 분명해졌다는 것과, 최근에 공감 능력도 지능의 영역이라는 주장들의 근원을 생각해보면, 결국 감정과 마음은 고차원적인 지능이며, 그렇다면 AI가 마음을 가질 수 있다는 논리.

고전명작 “바이센테니얼 맨” 역시 그러한 이야기를 시사하기도 하는데.. 과연 조금 더 지나 더 강력한 AI가 발명된 미래에는 이 생각들이 어떻게 받아들여질지 궁금하기도하다.

드림웍스의 애니메이션 영화 “와일드 로봇”을 봤다. 영화의 주제는 아니지만, 보는 내내 마음이란 무엇인가, 로봇도 마음을 가질 수 있는 것인가라는 진부한(?) 생각을 해 보았는데, 결론은 로봇도 마음을 가질 수 있다였다. AI의 마음은 고사하고 지능도 가짜다라는 말도 많이 하고, 마음과 지능의 정의가 명확하지 않기도 하지만, 지금은 아닐지 몰라도 AI가 지능을 가질 수 있다는 것은 분명해졌다는 것과, 최근에 공감 능력도 지능의 영역이라는 주장들의 근원을 생각해보면, 결국 감정과 마음은 고차원적인 지능이며, 그렇다면 AI가 마음을 가질 수 있다는 논리. 고전명작 “바이센테니얼 맨” 역시 그러한 이야기를 시사하기도 하는데.. 과연 조금 더 지나 더 강력한 AI가 발명된 미래에는 이 생각들이 어떻게 받아들여질지 궁금하기도하다.

My thoughts on license choices for balancing business interests and Open Source software and why the FSL is a better choice than the AGPL.

FSL: A Better Business/Open Source Balance Than AGPL

Flask를 만들고 오랫동안 오픈소스 활동을 한 Armin Ronacher가 FSL이 AGPL보다 더 좋은 선택이라고 설명하는 글입니다.

Elasticsearch가 몇년전 클라우드 사업의 충돌 문제로 오픈소스 라이센스를 빼고 오픈소스가 아니게 되었다가 최근 이제 문제가 해결되었다면서 다시 AGPL을 추가하면서 오픈소스 프로젝트가 되었습니다.

이 예시를 언급하면서 특정회사가 오픈소스 프로젝트 대부분을 책임지는 상황을 단일 벤더 모델이라고 얘기하면서 이러한 경우 FSL을 사용하면 이 공급업체가 상당한 권한을 가질수 있고 FSL은 2년이 지나면 오픈소스 라이센스로 자동변환이 되기 때문에 시간이 지남에 따라 권한이 약화된다고 얘기합니다. 그래서 Sentry가 지금 사업하는데는 문제가 없으면서 혹 Sentry 사업이 잘 안되어서 회사가 망하더라도 오픈소스 라이센스로 변경된 코드를 가지고 다른 누군가가 이어서 프로젝트를 할 수 있다고 설명합니다.

이렇게 어느 회사든 없어질 수 있는데 이런 경우 FSL이 훨씬 효과적이고 과거에도 회사가 괜찮은 프로젝트의 라이센스를 제대로 풀지 않고 회사가 없어지면서 문제가 된 경우도 많다고 얘기합니다.

AGPL을 쓰더라도 CLA(Contributor License Agreement)가 있냐 없냐에 따라 달라지는에 CLA가 있는 AGPL의 경우는 2년이 지난 뒤에는 FSL보다 저작권자가 더 강력한 권한을 가지게 된다고 합니다.

라이센스 문제는 꽤 복잡하긴 한데 FSL에 대해서 이 글에서 저는 설득력 있게 느껴졌습니다.

https://lucumr.pocoo.org/2024/9/23/fsl-agpl-open-source-businesses/

Flask를 만들고 오랫동안 오픈소스 활동을 한 Armin Ronacher가 FSL이 AGPL보다 더 좋은 선택이라고 설명하는 글입니다. Elasticsearch가 몇년전 클라우드 사업의 충돌 문제로 오픈소스 라이센스를 빼고 오픈소스가 아니게 되었다가 최근 이제 문제가 해결되었다면서 다시 AGPL을 추가하면서 오픈소스 프로젝트가 되었습니다. 이 예시를 언급하면서 특정회사가 오픈소스 프로젝트 대부분을 책임지는 상황을 단일 벤더 모델이라고 얘기하면서 이러한 경우 FSL을 사용하면 이 공급업체가 상당한 권한을 가질수 있고 FSL은 2년이 지나면 오픈소스 라이센스로 자동변환이 되기 때문에 시간이 지남에 따라 권한이 약화된다고 얘기합니다. 그래서 Sentry가 지금 사업하는데는 문제가 없으면서 혹 Sentry 사업이 잘 안되어서 회사가 망하더라도 오픈소스 라이센스로 변경된 코드를 가지고 다른 누군가가 이어서 프로젝트를 할 수 있다고 설명합니다. 이렇게 어느 회사든 없어질 수 있는데 이런 경우 FSL이 훨씬 효과적이고 과거에도 회사가 괜찮은 프로젝트의 라이센스를 제대로 풀지 않고 회사가 없어지면서 문제가 된 경우도 많다고 얘기합니다. AGPL을 쓰더라도 CLA(Contributor License Agreement)가 있냐 없냐에 따라 달라지는에 CLA가 있는 AGPL의 경우는 2년이 지난 뒤에는 FSL보다 저작권자가 더 강력한 권한을 가지게 된다고 합니다. 라이센스 문제는 꽤 복잡하긴 한데 FSL에 대해서 이 글에서 저는 설득력 있게 느껴졌습니다. https://lucumr.pocoo.org/2024/9/23/fsl-agpl-open-source-businesses/

Armin Ronacher's Thoughts and Writings

알고리즘 입문자를 위한 달레의 친절한 안내서

알고리즘 | 알고달레

📕 코딩 테스트에 단골로 등장하는 문제(LeetCode, 프로그래머스)에 대한 다양한 접근 방법과 답안 코드 (Python, JavaScript, Java)
📗 코딩 문제를 풀 때 반드시 필요한 알고리즘과 자료구조 설명 (최대한 입문자의 눈높이에서 친절하게 쉽게 🤗)
📘 코딩 시험/면접 준비 관련 가이드 + 17년 차 개발자 달레의 코딩 테스트 노하우 공유

개발자 달레님이 만드신 사이트인데요,
무료로 열려있어 공부하기도 좋고 깔끔해서 눈으로 보기도 좋아요!

https://www.algodale.com/algorithms/

📕 코딩 테스트에 단골로 등장하는 문제(LeetCode, 프로그래머스)에 대한 다양한 접근 방법과 답안 코드 (Python, JavaScript, Java) 📗 코딩 문제를 풀 때 반드시 필요한 알고리즘과 자료구조 설명 (최대한 입문자의 눈높이에서 친절하게 쉽게 🤗) 📘 코딩 시험/면접 준비 관련 가이드 + 17년 차 개발자 달레의 코딩 테스트 노하우 공유 개발자 달레님이 만드신 사이트인데요, 무료로 열려있어 공부하기도 좋고 깔끔해서 눈으로 보기도 좋아요! https://www.algodale.com/algorithms/

알고달레

코딩테스트 공부를 위한 추천 사이트

“아니, 도대체 왜 조회 쿼리 메서드에서 데드락이 생기는거야?”  

왜 조회 쿼리에서 데드락이 발생했을까?

"아니, 도대체 왜?"
'findBy...' 에서 데드락이 발생하는 걸 보고 궁금해서 이모저모 실험해보았어요.
https://hyeon9mak.github.io/why-occurs-deadlock-from-select-query/

"아니, 도대체 왜?"'findBy...' 에서 데드락이 발생하는 걸 보고 궁금해서 이모저모 실험해보았어요.https://hyeon9mak.github.io/why-occurs-deadlock-from-select-query/

현구막 기술 블로그

"아니, 도대체 왜?"
'findBy...' 에서 데드락이 발생하

마침내 제가 쓴 자바스크립트 책, "헬로 Bun"이 출간되어 온라인 서점에서 예약 판매가 시작되었습니다. Bun은 아직 국내에는 많이 알려지지 않았지만, 해외에서는 Node.js의 뒤를 잇는 차세대 자바스크립트 런타임으로 주목받고 있습니다. JavaScript Rising Stars 🌟 2023 집계에서 당당히 2위를 차지한 오픈 소스 프로젝트이며, State of JS 2023 설문 조사에서 개발자 응답에 가장 많이 오르고 내린 정말 HOT🔥한 기술입니다.

📕 YES24: https://www.yes24.com/Product/Goods/134021042
📗 교보문고: https://product.kyobobook.co.kr/detail/S000214450265
📘 알라딘: https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=348745550

사실 처음 Bun을 접했을 때는 제가 국내에 이 기술을 소개하는 책까지 쓰게 될 줄은 몰랐어요. 원래는 여타 기술처럼 제 블로그에서 한 번 다뤄보려고 했습니다. 그런데 이 귀여운 찐빵(?)이 겉보기와 다르게 기능과 성능이 후덜덜하더군요. 단순히 타입스크립트와 JSX를 바로 실행할 수 있는 자바스크립트 런타임인 줄 알았는데, 알고보니 모듈 시스템, 패키지 매니저, 테스트 러너, 번들러, 자체 DB, 웹소켓, CLI, 셸 스크립팅... "아니, Bun으로 내가 도대체 못하는 게 뭐지?"라는 생각이 들 정도였습니다. 자바스크립트 개발에 필요한 모든 기능을 자체적으로 제공하면서, 기존 런타임의 성능을 압도하는 이 차세대 기술을 블로그로 다루기에는 너무 방대하다는 것을 깨닫고 집필을 결심하게 되었습니다.

이 책이 단순히 Bun에 대한 기술서가 아니라, 많은 분들께 자바스크립트를 새롭게 만날 수 있는 계기가 되었으면 좋겠습니다. Bun의 등장으로 자바스크립트를 배우기 정말 좋은 시대가 열렸다고 생각합니다. 예전처럼 프로젝트 구성이나 라이브러리 설치하느라 오랫동안 씨름하지 않고 바로 재미있는 애플리케이션 개발을 Bun과 함께 시작하실 수 있습니다. 기존에 자바스크립트에 대해 좋지 못한 경험을 하셨던 현직 개발자분께도 추천드리고 싶습니다. Bun이 자바스크립트 개발자로서 고질적인 애로사항을 해결해 줄 뿐만 아니라, 자바스크립트에 대한 새로운 관점과 다양한 영감을 불어넣을 것입니다.

"헬로 Bun"을 통해 여러분이 자바스크립트를 더 쉽게 배우고, 더 즐겁게 소프트웨어 개발을 할 수 있기를 바랍니다. 많은 관심 부탁드립니다! 🙇‍♂️🙏

마침내 제가 쓴 자바스크립트 책, "헬로 Bun"이 출간되어 온라인 서점에서 예약 판매가 시작되었습니다. Bun은 아직 국내에는 많이 알려지지 않았지만, 해외에서는 Node.js의 뒤를 잇는 차세대 자바스크립트 런타임으로 주목받고 있습니다. JavaScript Rising Stars 🌟 2023 집계에서 당당히 2위를 차지한 오픈 소스 프로젝트이며, State of JS 2023 설문 조사에서 개발자 응답에 가장 많이 오르고 내린 정말 HOT🔥한 기술입니다. 📕 YES24: https://www.yes24.com/Product/Goods/134021042 📗 교보문고: https://product.kyobobook.co.kr/detail/S000214450265 📘 알라딘: https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=348745550 사실 처음 Bun을 접했을 때는 제가 국내에 이 기술을 소개하는 책까지 쓰게 될 줄은 몰랐어요. 원래는 여타 기술처럼 제 블로그에서 한 번 다뤄보려고 했습니다. 그런데 이 귀여운 찐빵(?)이 겉보기와 다르게 기능과 성능이 후덜덜하더군요. 단순히 타입스크립트와 JSX를 바로 실행할 수 있는 자바스크립트 런타임인 줄 알았는데, 알고보니 모듈 시스템, 패키지 매니저, 테스트 러너, 번들러, 자체 DB, 웹소켓, CLI, 셸 스크립팅... "아니, Bun으로 내가 도대체 못하는 게 뭐지?"라는 생각이 들 정도였습니다. 자바스크립트 개발에 필요한 모든 기능을 자체적으로 제공하면서, 기존 런타임의 성능을 압도하는 이 차세대 기술을 블로그로 다루기에는 너무 방대하다는 것을 깨닫고 집필을 결심하게 되었습니다. 이 책이 단순히 Bun에 대한 기술서가 아니라, 많은 분들께 자바스크립트를 새롭게 만날 수 있는 계기가 되었으면 좋겠습니다. Bun의 등장으로 자바스크립트를 배우기 정말 좋은 시대가 열렸다고 생각합니다. 예전처럼 프로젝트 구성이나 라이브러리 설치하느라 오랫동안 씨름하지 않고 바로 재미있는 애플리케이션 개발을 Bun과 함께 시작하실 수 있습니다. 기존에 자바스크립트에 대해 좋지 못한 경험을 하셨던 현직 개발자분께도 추천드리고 싶습니다. Bun이 자바스크립트 개발자로서 고질적인 애로사항을 해결해 줄 뿐만 아니라, 자바스크립트에 대한 새로운 관점과 다양한 영감을 불어넣을 것입니다. "헬로 Bun"을 통해 여러분이 자바스크립트를 더 쉽게 배우고, 더 즐겁게 소프트웨어 개발을 할 수 있기를 바랍니다. 많은 관심 부탁드립니다! 🙇‍♂️🙏

👋 헬로 Bun 🥟 출간 소식 📚

원문 : How to make your web page faster before it even loads How to make your web page faster before it even loads…

(번역) 웹 페이지가 로드되기 전에 더 빠르게 만드는 방법

오늘 소개해드릴 글은 42dot의 유경상님이 번역해주신 글입니다.

웹 페이지 성능 최적화라고 하면 대부분 페이지 로딩 후의 성능에 집중하는 경향이 있습니다. 하지만 이 글에서는 그 관점을 뒤집어 새로운 인사이트를 제공합니다. 저자는 첫 바이트가 도달하기 전 단계의 최적화에 주목하며, 브라우저의 Performance API와 Navigation Timing API를 활용해 캐시, DNS 조회, 연결 설정, TLS 협상 등 각 단계별 최적화 방법을 상세히 설명합니다.

만약 웹 성능 최적화에 대해 관심이 있으시다면, 이 글을 통해 최적화의 새로운 기회를 발견할 수 있을 것이라고 생각합니다. 이 글을 통해 웹 페이지 성능 최적화에 대한 시야를 넓히는 좋은 기회가 되시길 바랍니다 :)

글 링크 : https://ykss.netlify.app/translation/how_to_make_your_web_page_faster_before_it_even_loads/

오늘 소개해드릴 글은 42dot의 유경상님이 번역해주신 글입니다. 웹 페이지 성능 최적화라고 하면 대부분 페이지 로딩 후의 성능에 집중하는 경향이 있습니다. 하지만 이 글에서는 그 관점을 뒤집어 새로운 인사이트를 제공합니다. 저자는 첫 바이트가 도달하기 전 단계의 최적화에 주목하며, 브라우저의 Performance API와 Navigation Timing API를 활용해 캐시, DNS 조회, 연결 설정, TLS 협상 등 각 단계별 최적화 방법을 상세히 설명합니다. 만약 웹 성능 최적화에 대해 관심이 있으시다면, 이 글을 통해 최적화의 새로운 기회를 발견할 수 있을 것이라고 생각합니다. 이 글을 통해 웹 페이지 성능 최적화에 대한 시야를 넓히는 좋은 기회가 되시길 바랍니다 :) 글 링크 : https://ykss.netlify.app/translation/how_to_make_your_web_page_faster_before_it_even_loads/

ykss.netlify.app

웹 페이지가 로드되기 전에 더 빠르게 만드는 방법

Arthur's place

저자는 try-catch 블록 없이 에러를 처리할 수 있는 try 표현식을 제안합니다. 예를 들면 다음과 같습니다.
const [error, response] = try await fetch("https://arthur.place")

위 코드는 기존 try-catch 코드 블록을 간소화하고
error
를 반환값 앞에 먼저 배치하여 에러 핸들링에 대한 우선순위를 높이는 효과가 있습니다.
let response;
try {
  response = await fetch("https://arthur.place");
} catch (error) {
  // blah blah
}

아직 초기 단계의 제안이긴 하지만, 흥미로운 제안인 것 같습니다.
참고: 저자의 제안은 원래 안전 할당(`?=`)을 통해 에러 처리를 간소화하려는 제안이였으나, 의논 결과
try
표현식이 좀 더 관용적인 접근 방법이라고 생각되어 try 제안으로 변경한다고 합니다. 관련 Pull Request가 올라와있어, 이 글도 해당 PR의 내용을 기반으로 소개드린 점 참고 부탁드립니다.

https://github.com/arthurfiorette/proposal-safe-assignment-operator/pull/42

저자는 try-catch 블록&nbsp;없이 에러를 처리할 수 있는 try 표현식을 제안합니다. 예를 들면 다음과 같습니다.<pre ><code class="language-js">const [error, response] = try await fetch("https://arthur.place")</code></pre>위 코드는 기존 try-catch 코드 블록을 간소화하고 <code >error</code>를 반환값 앞에 먼저 배치하여 에러 핸들링에 대한 우선순위를 높이는 효과가 있습니다. <pre ><code class="language-js">let response;
try {
 response = await fetch("https://arthur.place");
} catch (error) {
 // blah blah
}</code></pre>아직 초기 단계의 제안이긴 하지만, 흥미로운 제안인 것 같습니다.참고: 저자의 제안은 원래 안전 할당(`?=`)을 통해 에러 처리를 간소화하려는 제안이였으나, 의논 결과 <code >try</code> 표현식이 좀 더 관용적인 접근 방법이라고 생각되어 try 제안으로 변경한다고 합니다. 관련 Pull Request가 올라와있어, 이 글도 해당 PR의 내용을 기반으로 소개드린 점 참고 부탁드립니다. https://github.com/arthurfiorette/proposal-safe-assignment-operator/pull/42

ECMAScript try-expressions 제안

You are being redirected...

소프트웨어는 시간이 흐르면서 기능이 추가되고 유지보수 작업이 누적되면서 자연스럽게 "침식" 현상을 겪습니다. 이는 코드 품질 저하, 기술 부채 증가, 그리고 성능 저하를 야기하여 유지보수 비용을 크게 증가시킵니다. 이 글에서는 소프트웨어 침식의 원인과 그로 인한 문제, 그리고 이를 방지하기 위한 방법을 소개합니다.

# 소프트웨어 침식의 원인과 문제
 * 지나치게 복잡해진 코드베이스: 시간이 지나며 요구사항 변화와 기능 추가로 인해 코드가 점점 복잡해짐.
 * 불필요한 의존성: 빠른 문제 해결을 위해 임시방편으로 추가된 의존성들이 코드베이스를 무겁게 함.
 * 중복 코드와 설계의 일관성 부족: 팀원 간 커뮤니케이션 부족 및 시간 제약으로 인해 코드 중복과 일관성 결여 발생.

# 소프트웨어 침식을 방지하는 방법
 * 지속적인 코드 리팩토링: 정기적인 코드 리뷰와 리팩토링을 통해 코드베이스의 품질을 유지.
 * 품질 관리 프로세스 개선: 코드 품질을 유지하기 위한 단위 테스트, 통합 테스트 등의 자동화된 테스트 도입.
 * 설계와 아키텍처 점검: 기존 아키텍처를 주기적으로 점검하고, 필요시 개선 작업을 진행.

소프트웨어 침식은 방치할 경우, 나중에 해결하는 데 많은 비용과 시간이 소요되므로 초기부터 주의 깊은 관리가 필요합니다. 여러분은 현재 프로젝트에서 소프트웨어 침식을 방지하기 위해 어떤 노력을 기울이고 계신가요?

https://www.softwaretestingnews.co.uk/software-is-eroding-before-our-eyes/

소프트웨어는 시간이 흐르면서 기능이 추가되고 유지보수 작업이 누적되면서 자연스럽게 "침식" 현상을 겪습니다. 이는 코드 품질 저하, 기술 부채 증가, 그리고 성능 저하를 야기하여 유지보수 비용을 크게 증가시킵니다. 이 글에서는 소프트웨어 침식의 원인과 그로 인한 문제, 그리고 이를 방지하기 위한 방법을 소개합니다. # 소프트웨어 침식의 원인과 문제<ul ><li>지나치게 복잡해진 코드베이스: 시간이 지나며 요구사항 변화와 기능 추가로 인해 코드가 점점 복잡해짐.</li><li>불필요한 의존성: 빠른 문제 해결을 위해 임시방편으로 추가된 의존성들이 코드베이스를 무겁게 함.</li><li>중복 코드와 설계의 일관성 부족: 팀원 간 커뮤니케이션 부족 및 시간 제약으로 인해 코드 중복과 일관성 결여 발생.</li></ul> # 소프트웨어 침식을 방지하는 방법<ul ><li>지속적인 코드 리팩토링: 정기적인 코드 리뷰와 리팩토링을 통해 코드베이스의 품질을 유지.</li><li>품질 관리 프로세스 개선: 코드 품질을 유지하기 위한 단위 테스트, 통합 테스트 등의 자동화된 테스트 도입.</li><li>설계와 아키텍처 점검: 기존 아키텍처를 주기적으로 점검하고, 필요시 개선 작업을 진행.</li></ul> 소프트웨어 침식은 방치할 경우, 나중에 해결하는 데 많은 비용과 시간이 소요되므로 초기부터 주의 깊은 관리가 필요합니다. 여러분은 현재 프로젝트에서 소프트웨어 침식을 방지하기 위해 어떤 노력을 기울이고 계신가요? https://www.softwaretestingnews.co.uk/software-is-eroding-before-our-eyes/

www.softwaretestingnews.co.uk

내 눈 앞에서 소프트웨어가 침식되고 있다

음.. 어떻게 얘길 시작해야 하나 

끗과 시작, 그 사이 어딘가

'최고가 되어 떠나라'
회사에 붙어있는 메시지 중 하나인데요.
퇴사부검을 보고나니 다들 멋지네요
앞으로 더 좋은 소식 기대하고 있을께요

https://www.brainbackdoor.com/retrospective/2019-2024

'최고가 되어 떠나라'회사에 붙어있는 메시지 중 하나인데요.퇴사부검을 보고나니 다들 멋지네요앞으로 더 좋은 소식 기대하고 있을께요 https://www.brainbackdoor.com/retrospective/2019-2024

동규님의 우아한형제들 퇴사부검

어제 심오한 고민을 하다가 헤라의 글로우 래스팅 파운데이션을 구매했다. 솔직히 양에 비해 가격이 저렴하...

[극대노주의] 올리브영 일반배송 은근슬쩍 오늘드림 변환 수법

제목부터 범상치 않습니다. [극대노주의]를 대괄호로 표시했죠. 결론부터 말씀드리면 뷰티 시장의 큰손, 올리브영 서비스를 앱으로 이용하면서 일반 배송으로 선택했지만 자동으로 선택된 항목으로 인해 '오늘 드림'으로 배송이 되어 증정품을 받지 못하는 상황을 경험한 사용자의 후기입니다. (트레바리 북클럽 <리서치 하는데요> 멤버인 초은 님이 클럽 커뮤니티에 공유해 주신 글이 인상적이라 제가 자세히 살펴보고 정리했습니다)

요약하면 사용자의 의도, 기대했던 것과 다른 경험을 제공하는 기만적 패턴이 문제였습니다. 구매할 때 일반 배송으로 받아야만 증정품을 받을 수 있기 때문에 의도적으로 '오늘 드림'이 아닌 '일반 배송'으로 선택하고 넘어간 것인데 다음 화면에서는 '무료 배송으로 내일 자정까지 받아보시겠어요?'라는 문구가 자동으로 선택되어 있는 겁니다. 문제는 이 문구가 '오늘 드림'을 의미하는 것인지도 모호하고 따져보면 내일 자정이니 '내일드림'이면 그럴듯해도, '오늘 드림'은 아니겠거니 생각하면서 진행을 했던 것인데 받아보니 증정품이 없었던 것이죠.

사용자가 고객센터에 문의한 결과 '무료배송으로 내일 자정까지 받아보시겠어요?'라는 문구를 선택하면 '오늘 드림' 배송으로 동의한 것이라 일반배송이 아닌 게 되므로 증정품을 받을 수 없다는 답변을 받았다고 합니다. 주목할 점은 (1) 문구를 자동으로 선택하도록 만든 것 (2) 이전에 선택한 옵션의 내용을 교모하게 바꿔두고 받을 수 있는 상품구성이 달라진 부분에 대해 사용자가 직접 제품을 받은 뒤 고객센터에 문의해야만 알 수 있다는 점이죠.

문구는 모호하고 화장품 구매에서 증정품이 미치는 영향을 고려할 때 올리브영의 이런 패턴(자동으로 문구 선택, 모호한 설명, 기대한 상품을 받지 못하는 경험)은 기만적이라고 할 수 있습니다. 사용자 블로그글에는 경험을 손상시킨 3가지 문제에 대한 언급이 있습니다.

[ 큐레이터의 문장 🎒 ]

1️⃣ "불만 접수방식도 불만 게시판이 명확하게 설립되어 있는 농심과 비교되어 더더욱 기분이 나빴고 (중략) 게다가 설문조사는 그렇게 꼬치꼬치 엄청난 수의 문항으로 물어보면서 이런 고객 불만사항 게시판은 또 마땅히 활성화되어 있지 않는다는 점이 대조되어 더 괘씸하다"

2️⃣ "아무리 생각해도 전에는 오해의 여지가 없도록 명백하게 '오늘드림'이라는 단어를 활용해 안내했었는데 이제 와서 오해의 여지가 다분한 유도성 문구로 변경해 둔 것이 의도가 없이 그런 것이라 생각되질 않기에 사은품 여부를 떠나서 더 기분이 나빴다."

3️⃣ "나는 앞으로 꼭 사은품을 안전하게 받을 수 있는 아모레퍼시픽 공식몰을 이용할 것이라 다짐하며"

https://m.blog.naver.com/boksle1127/223420780140

제목부터 범상치 않습니다. [극대노주의]를 대괄호로 표시했죠. 결론부터 말씀드리면 뷰티 시장의 큰손, 올리브영 서비스를 앱으로 이용하면서 일반 배송으로 선택했지만 자동으로 선택된 항목으로 인해 '오늘 드림'으로 배송이 되어 증정품을 받지 못하는 상황을 경험한 사용자의 후기입니다. (트레바리 북클럽 &lt;리서치 하는데요&gt; 멤버인 초은 님이 클럽 커뮤니티에 공유해 주신 글이 인상적이라 제가 자세히 살펴보고 정리했습니다) 요약하면 사용자의 의도, 기대했던 것과 다른 경험을 제공하는 기만적 패턴이 문제였습니다. 구매할 때 일반 배송으로 받아야만 증정품을 받을 수 있기 때문에 의도적으로 '오늘 드림'이 아닌 '일반 배송'으로 선택하고 넘어간 것인데 다음 화면에서는 '무료 배송으로 내일 자정까지 받아보시겠어요?'라는 문구가 자동으로 선택되어 있는 겁니다. 문제는 이 문구가 '오늘 드림'을 의미하는 것인지도 모호하고 따져보면 내일 자정이니 '내일드림'이면 그럴듯해도, '오늘 드림'은 아니겠거니 생각하면서 진행을 했던 것인데 받아보니 증정품이 없었던 것이죠. 사용자가 고객센터에 문의한 결과 '무료배송으로 내일 자정까지 받아보시겠어요?'라는 문구를 선택하면 '오늘 드림' 배송으로 동의한 것이라 일반배송이 아닌 게 되므로 증정품을 받을 수 없다는 답변을 받았다고 합니다. 주목할 점은 (1) 문구를 자동으로 선택하도록 만든 것 (2) 이전에 선택한 옵션의 내용을 교모하게 바꿔두고 받을 수 있는 상품구성이 달라진 부분에 대해 사용자가 직접 제품을 받은 뒤 고객센터에 문의해야만 알 수 있다는 점이죠. 문구는 모호하고 화장품 구매에서 증정품이 미치는 영향을 고려할 때 올리브영의 이런 패턴(자동으로 문구 선택, 모호한 설명, 기대한 상품을 받지 못하는 경험)은 기만적이라고 할 수 있습니다. 사용자 블로그글에는 경험을 손상시킨 3가지 문제에 대한 언급이 있습니다. [ 큐레이터의 문장 🎒 ] 1️⃣ "불만 접수방식도 불만 게시판이 명확하게 설립되어 있는 농심과 비교되어 더더욱 기분이 나빴고 (중략) 게다가 설문조사는 그렇게 꼬치꼬치 엄청난 수의 문항으로 물어보면서 이런 고객 불만사항 게시판은 또 마땅히 활성화되어 있지 않는다는 점이 대조되어 더 괘씸하다" 2️⃣ "아무리 생각해도 전에는 오해의 여지가 없도록 명백하게 '오늘드림'이라는 단어를 활용해 안내했었는데 이제 와서 오해의 여지가 다분한 유도성 문구로 변경해 둔 것이 의도가 없이 그런 것이라 생각되질 않기에 사은품 여부를 떠나서 더 기분이 나빴다." 3️⃣ "나는 앞으로 꼭 사은품을 안전하게 받을 수 있는 아모레퍼시픽 공식몰을 이용할 것이라 다짐하며" https://m.blog.naver.com/boksle1127/223420780140

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필