앱 시작 화면에 개발자 핸드폰 전화번호를 적어놔봐라. 그래도 전화 안 온다. 예전에 누군가에게 들었던 이야기.

사용자의 목소리

앱 시작 화면에 개발자 핸드폰 전화번호를 적어놔봐라. 그래도 전화 안 온다.
예전에 누군가에게 들었던 이야기.

인상적이었습니다. 진짜 그럴까?

커피한잔도 앱 시작 화면 정도는 아니지만 홈페이지 하단에 고객센터 전화번호를 노출해두고 있습니다.
말이 고객 센터지, 제가 가진 두 개의 핸드폰 번호 중 하나입니다.

가끔 전화가 오면 긴장 반 설렘 반으로 전화를 받습니다.
하지만 불행히도(?) 사용자분들에게 전화가 오기보단 스팸 전화가 대부분입니다.
난 사용자들 목소리가 듣고 싶은 건데.

커피한잔에서 사용자들에게 보내는 메일은 발신 전용 메일이 없습니다.
발신 전용으로 보낸다는 건 답장을 보내지 말라는 뜻.
사용자들 목소리 듣기가 얼마나 어려운데…

이야기를 더 많이 들어보기 위해 정말 스플래시 화면에 전화번호를 한 번 노출해 봐야겠습니다.

https://jeho.page/essay/2024/10/17/user-voice.html

앱 시작 화면에 개발자 핸드폰 전화번호를 적어놔봐라. 그래도 전화 안 온다. 예전에 누군가에게 들었던 이야기. 인상적이었습니다. 진짜 그럴까? 커피한잔도 앱 시작 화면 정도는 아니지만 홈페이지 하단에 고객센터 전화번호를 노출해두고 있습니다. 말이 고객 센터지, 제가 가진 두 개의 핸드폰 번호 중 하나입니다. 가끔 전화가 오면 긴장 반 설렘 반으로 전화를 받습니다. 하지만 불행히도(?) 사용자분들에게 전화가 오기보단 스팸 전화가 대부분입니다. 난 사용자들 목소리가 듣고 싶은 건데. 커피한잔에서 사용자들에게 보내는 메일은 발신 전용 메일이 없습니다. 발신 전용으로 보낸다는 건 답장을 보내지 말라는 뜻. 사용자들 목소리 듣기가 얼마나 어려운데… 이야기를 더 많이 들어보기 위해 정말 스플래시 화면에 전화번호를 한 번 노출해 봐야겠습니다. https://jeho.page/essay/2024/10/17/user-voice.html

K리그 프로그래머

Express 프레임워크가 Node.js 생태계에서 대표 웹 프레임워크를 담당하고 있다면 Elysia는 Bun 생태계에서 비슷한 역할과 인지도를 갖고 있는 하고 있는 웹 프레임워크입니다.

물론 간단한 웹 서버를 개발할 때는 Bun에서 제공하는 HTTP 서버만으로도 충분할 때가 많지만, Elysia는 웹 서버 개발에 필요한 왠만한 기능이 모두 내장되어 있어서 단순한 서버 개발 뿐만 아니라 복잡한 서버 개발까지 사용할 수 있는 확장성이 띄어난 웹 프레임워크입니다.

타입스크립트를 바로 실행하는 Bun과 마찬가지로 Elysia도 타입스크립트에 매우 친화적인 API를 제공하면서도 개발자가 피곤하게 타입스크립트를 많이 작성하지 않도록 매우 인체 공학적으로 설계가 되어 있습니다. 다시 말해서, 다른 웹 프레임워크처럼 개발자에게 번거로운 타이핑(typing)을 강요하지 않고, 강력한 타입 추론을 통해서 코드 편집기에서 훌륭한 자동 완성(autocomplete)과 정적 타입 체킹을 제공합니다. 그래서 Elysia를 쓰면 마치 순수한(Vanilla) 자바스크립트를 쓰는 듯한 산뜻한 개발자 경험을 하면서도, 버그가 적은 견고한 서버 애플리케이션을 작성할 수 있습니다.

아래 예제 코드를 보시면 Elysia의 API가 얼마나 아름답고 직관적인지 실감이 나실 겁니다. 딱히 Elysia를 배우시지 않으신 분도 코드만 보면 대강 웹 서버가 어떻게 동작하는지 감을 잡을 수 있을 정도니까요.

import { Elysia } from "elysia";

new Elysia()
  .get("/", "Hello World")
  .get("/image", Bun.file("mika.webp"))
  .get("/stream", function* () {
    yield "Hello";
    yield "World";
  })
  .ws("/realtime", {
    message(ws, message) {
      ws.send("got:" + message);
    },
  })
  .listen(3000);

Elysia는 개발자 경험 뿐만 아니라 성능 측면에서도 기존 웹 프레임워크를 압도하는 모습을 보여줍니다. 벤치마크 결과를 보면 Elysia는 초당 Express보다 무려 21배, Fastify보다 6배 많은 요청을 처리하는 것으로 알려져 있습니다. 지나친 단순화이지만 Node.js에서 Express 익스프레스 서버 인스턴스로 처리할 수 있는 트래픽을, Bun에서는 1개의 Elysia 서버 인스턴스로 처리할 수 있다는 말입니다. 단순히 런타임과 프레임워크를 바꿔서 이 정도의 성능 향상을 이룰 수 있다니, Bun과 Elysia는 정말 매력적인 조합이 아닐 수 없습니다.

Bun이 Node.js를 잇는 차세대 자바스크립트 런타임으로 급 부상하면서, Bun을 위해서 탄생한 웹 프레임워크인 Elysia도 큰 관심을 받고 있습니다. 이번 포스팅에서는 Elysia의 주요 특징과 사용법, 그리고 Elysia가 다른 웹 프레임워크와 어떻게 차별화되는지에 대해서 살펴보겠습니다.

📝 포스팅: https://www.daleseo.com/elysia/

혹시 Bun에 대해서 생소하신 분들께는 아래 게시물을 추천드리고 싶습니다.

📕 Bun: 귀엽지만 강력한 새로운 자바스크립트 런타임: https://careerly.co.kr/comments/92202
📗 Bun v1.1 출시 소식: https://careerly.co.kr/comments/102544
📘 헬로 Bun 출간 소식: 귀엽지만 강력한 새로운 자바스크립트 런타임: https://careerly.co.kr/comments/111998

Express 프레임워크가 Node.js 생태계에서 대표 웹 프레임워크를 담당하고 있다면 Elysia는 Bun 생태계에서 비슷한 역할과 인지도를 갖고 있는 하고 있는 웹 프레임워크입니다. 물론 간단한 웹 서버를 개발할 때는 Bun에서 제공하는 HTTP 서버만으로도 충분할 때가 많지만, Elysia는 웹 서버 개발에 필요한 왠만한 기능이 모두 내장되어 있어서 단순한 서버 개발 뿐만 아니라 복잡한 서버 개발까지 사용할 수 있는 확장성이 띄어난 웹 프레임워크입니다. 타입스크립트를 바로 실행하는 Bun과 마찬가지로 Elysia도 타입스크립트에 매우 친화적인 API를 제공하면서도 개발자가 피곤하게 타입스크립트를 많이 작성하지 않도록 매우 인체 공학적으로 설계가 되어 있습니다. 다시 말해서, 다른 웹 프레임워크처럼 개발자에게 번거로운 타이핑(typing)을 강요하지 않고, 강력한 타입 추론을 통해서 코드 편집기에서 훌륭한 자동 완성(autocomplete)과 정적 타입 체킹을 제공합니다. 그래서 Elysia를 쓰면 마치 순수한(Vanilla) 자바스크립트를 쓰는 듯한 산뜻한 개발자 경험을 하면서도, 버그가 적은 견고한 서버 애플리케이션을 작성할 수 있습니다. 아래 예제 코드를 보시면 Elysia의 API가 얼마나 아름답고 직관적인지 실감이 나실 겁니다. 딱히 Elysia를 배우시지 않으신 분도 코드만 보면 대강 웹 서버가 어떻게 동작하는지 감을 잡을 수 있을 정도니까요. <pre ><code>import { Elysia } from "elysia";

new Elysia()
 .get("/", "Hello World")
 .get("/image", Bun.file("mika.webp"))
 .get("/stream", function* () {
 yield "Hello";
 yield "World";
 })
 .ws("/realtime", {
 message(ws, message) {
 ws.send("got:" + message);
 },
 })
 .listen(3000);</code></pre> Elysia는 개발자 경험 뿐만 아니라 성능 측면에서도 기존 웹 프레임워크를 압도하는 모습을 보여줍니다. 벤치마크 결과를 보면 Elysia는 초당 Express보다 무려 21배, Fastify보다 6배 많은 요청을 처리하는 것으로 알려져 있습니다. 지나친 단순화이지만 Node.js에서 Express 익스프레스 서버 인스턴스로 처리할 수 있는 트래픽을, Bun에서는 1개의 Elysia 서버 인스턴스로 처리할 수 있다는 말입니다. 단순히 런타임과 프레임워크를 바꿔서 이 정도의 성능 향상을 이룰 수 있다니, Bun과 Elysia는 정말 매력적인 조합이 아닐 수 없습니다. Bun이 Node.js를 잇는 차세대 자바스크립트 런타임으로 급 부상하면서, Bun을 위해서 탄생한 웹 프레임워크인 Elysia도 큰 관심을 받고 있습니다. 이번 포스팅에서는 Elysia의 주요 특징과 사용법, 그리고 Elysia가 다른 웹 프레임워크와 어떻게 차별화되는지에 대해서 살펴보겠습니다. 📝 포스팅: https://www.daleseo.com/elysia/ 혹시 Bun에 대해서 생소하신 분들께는 아래 게시물을 추천드리고 싶습니다. 📕 Bun: 귀엽지만 강력한 새로운 자바스크립트 런타임: https://careerly.co.kr/comments/92202📗 Bun v1.1 출시 소식: https://careerly.co.kr/comments/102544📘 헬로 Bun 출간 소식: 귀엽지만 강력한 새로운 자바스크립트 런타임: https://careerly.co.kr/comments/111998

Elysia: Bun을 위한 인체 공학적 웹 프레임워크

원문: https://ruanmartinelli.com/blog/tanstack-query-openapi

[번역] OpenAPI와 함께 타입 안전성을 갖춘 Tanstack Query

오늘 소개해드릴 글은 두나무의 조영제님이 번역해주신 글입니다.

아마 프론트엔드 개발자라면, 서버 측에서 제공해 준 Swagger 문서를 보며 API 타입을 생성하고, 클라이언트와 서버 간 연동 코드를 한땀 한땀 작성해 본 경험이 있을 것 같습니다. 이 과정은 매우 지루할 뿐만 아니라, 오타가 발생하거나 서버와의 실시간 동기화가 잘 이루어지지 않아 버그가 발생하기도 합니다.
이 글에서는 이러한 문제를 해결하기 위해, 서버의 API 명세가 변경될 때마다 자동으로 타입을 생성 또는 수정하고, 최근 리액트에서 자주쓰이는 TanStack Query를 커스터마이징하여 더욱 안전하고 편리한 API 호출을 구현하는 방법을 설명합니다.
이 글을 통해 여러분도 OpenAPI와 TanStack Query를 효과적으로 결합하여 타입 문제로 인한 골치 아픈 버그를 미리 예방하고, 서버와의 의사소통 비용도 줄이며 개발 속도도 높일 수 있기를 바랍니다. 😃

글 링크: https://bit.ly/4eW8hPq

오늘 소개해드릴 글은 두나무의 조영제님이 번역해주신 글입니다. 아마 프론트엔드 개발자라면, 서버 측에서 제공해 준 Swagger 문서를 보며 API 타입을 생성하고, 클라이언트와 서버 간 연동 코드를 한땀 한땀 작성해 본 경험이 있을 것 같습니다. 이 과정은 매우 지루할 뿐만 아니라, 오타가 발생하거나 서버와의 실시간 동기화가 잘 이루어지지 않아 버그가 발생하기도 합니다.이 글에서는 이러한 문제를 해결하기 위해, 서버의 API 명세가 변경될 때마다 자동으로 타입을 생성 또는 수정하고, 최근 리액트에서 자주쓰이는 TanStack Query를 커스터마이징하여 더욱 안전하고 편리한 API 호출을 구현하는 방법을 설명합니다.이 글을 통해 여러분도 OpenAPI와 TanStack Query를 효과적으로 결합하여 타입 문제로 인한 골치 아픈 버그를 미리 예방하고, 서버와의 의사소통 비용도 줄이며 개발 속도도 높일 수 있기를 바랍니다. 😃 글 링크: https://bit.ly/4eW8hPq

내일배움캠프

OpenAPI와 함께 타입 안전성을 갖춘 Tanstack Query

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

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

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

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

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

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

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

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

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

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

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

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

Explore the top 10 web development trends for 2025. Gain valuable insights into the future of web design, technology, and user experience.

Top 10 Web Development Trends to Watch in 2025 - Tech Guide

생성형AI와 LLM이 핫트렌드인 현재이지만, 여전히 우리는 쇼핑이나 항공권 티켓팅, 블로그, SNS를 웹으로 접근하고 있습니다. 따라서 전략적 우위를 확보하기 위해서는 웹 개발 최신 트렌드를 이해하고 이에 적응하는 것이 무엇보다 중요합니다. 이와 관련하여 2025년 웹개발 트렌드를 함께 살펴보시죠!

🧲 맞춤형 비주얼(Customised Visuals)
 * 브랜드 아이덴티티를 반영하여 특별히 디자인된 일반적인 스톡 이미지에서 맞춤형 레이아웃과 이미지로 전환 필요
 * 사용자들은 창의적인 그래픽과 아이콘을 일관된 색상으로 조합하여 더욱 매력적인 경험을 제공하는 웹사이트를 기억하는 경향
 * 맞춤형 비주얼에 투자함으로써 온라인 시장에서 차별화 및 탐색 기능을 개선하고 사용자의 콘텐츠 접근성을 높일 수 있음
   
   
🧲 모바일 우선 디자인(Mobile-First Design)
 * 전 세계 웹 트래픽의 50% 이상이 모바일 디바이스에서 발생
 * 모바일 응답성을 우선시하는 직관적인 웹사이트는 사용자 참여도와 리텐션 향상 유도
 * 모바일에 맞게 작은 화면과 빠른 로딩 시간에 완벽하게 최적화 필요
   
   
🧲 다크 모드(Dark Mode)
 * 사용자가 기존의 밝은 색상의 배경에서 어두운 테마로 전환할 수 있는 다크 모드는 최신 웹 디자인의 필수 요소
 * 다크 모드의 인기는 미적 매력과 함께 저조도 환경에서 눈의 피로를 줄이고 OLED 화면의 배터리 수명을 절약하는 등의 이점
 * 다크 모드는 생생한 색상 및 이미지와 잘 대비되는 세련되고 현대적인 외관을 제공함으로써 사용자 경험을 향상시키고, 사용자 참여도를 높일 수 있음
   
   
🧲 AR/VR을 통한 몰입형 경험(Immersive Experiences with AR/VR)
 * 증강 현실과 가상 현실이 웹 개발에 통합되면서 2025년까지 사용자 상호 작용이 혁신적으로 변화할 것으로 예상
 * AR/VR 기술은 몰입도 높은 인터랙티브 경험을 제공하여 사용자를 더욱 깊이 참여시킴
   * 예) 소매업체는 가상 의류 시착 서비스를 제공하거나 고객이 구매 전에 제품의 3D 모델을 미리 볼 수 있어 보다 효과적임
   * 예) 부동산, 이커머스, 관광과 같은 산업에서는 브라우저를 통해 직접 실물과 같은 경험을 제공하는 데 AR과 VR이 중요한 역할
     
     
🧲 싱글 페이지 애플리케이션(Single Page Applications)
 * 빠른 로딩 시간과 간소화된 브라우징 경험 인기
 * 기존 웹사이트와 달리 SPA는 전체 페이지를 다시 로드할 필요 없이 단일 HTML 페이지를 로드하고 콘텐츠를 동적으로 업데이트
 * 빠르고 끊김 없는 브라우징 경험을 제공을 통해 방문자 유지 필수

🧲 혁신 기술과의 통합(Integration of Emerging Technologies)
 * 인공지능, 머신러닝, 블록체인과 같은 새로운 기술은 2025년에도 웹 개발을 계속해서 재편
 * 인공지능과 머신러닝은 각 사용자에게 개인화된 경험을 제공하는 더 스마트하고 직관적인 웹사이트를 만드는 데 사용
   * 예)AI 기반 챗봇은 실시간 지원 서비스 제공
 * 블록체인 기술 또한 웹 개발에 더욱 통합되어 보안, 투명성, 신뢰성을 강화

🧲 프로그레시브 웹 앱(Progressive Web Apps)
 * 웹 액세스의 편리함과 네이티브 앱의 기능을 결합하여 웹과 모바일 앱의 장점을 모두 제공
 * PWA는 브라우저를 통해 액세스할 수 있지만 모바일 앱처럼 작동하여 오프라인 기능을 제공
 * 모든 디바이스에서 원활하게 작동하는 PWA는 전용 앱을 개발하지 않고도 모바일 참여도를 향상시키고자 하는 경우에 이상적임
   
   
🧲 보안 강화(Enhanced Security)
 * 웹사이트는 다단계 인증, 암호화, 보안 프레임워크 등 더욱 강력한 보안 프로토콜을 구현하여 민감한 데이터를 보호하고 사용자 개인정보 보호 필요
 * 보안 위협이 진화함에 따라 웹사이트에 사전 예방적 보안 조치를 도입하여 취약점을 사전에 방지하는 것이 중요

🧲 마이크로 인터랙션(Micro Interactions)
 * 웹사이트를 통해 사용자를 안내하고 사용자 참여를 향상시키는 미묘한 디자인 요소
   * 예)애니메이션, 호버 효과, 버튼 누르기, 작은 피드백 표시기 등
 * 마이크로 인터랙션이 더욱 발전하여 전반적인 사용자 경험을 향상시키는 부드러운 전환과 동적 요소 제공
   
   
🧲 음성 검색
 * Siri, Alexa, Google Assistant와 같은 음성 비서를 사용하는 사용자가 증가함에 따라 음성 검색의 인기는 계속 높아짐
 * 웹사이트는 자연어 처리에 집중하고 음성 검색 친화적인 SEO를 구현하여 음성 검색을 통해 콘텐츠를 쉽게 찾을 수 있도록
 * 음성 검색을 통해 사용자는 타이핑 없이도 빠르고 효율적으로 정보를 찾을 수 있으므로 이러한 트렌드에 적응하면 경쟁 우위 제공
   
   

 * source: https://www.techguide.com.au/news/internet-news/top-10-web-development-trends-to-watch-in-2025/

생성형AI와 LLM이 핫트렌드인 현재이지만, 여전히 우리는 쇼핑이나 항공권 티켓팅, 블로그, SNS를 웹으로 접근하고 있습니다. 따라서 전략적 우위를 확보하기 위해서는 웹 개발 최신 트렌드를 이해하고 이에 적응하는 것이 무엇보다 중요합니다. 이와 관련하여 2025년 웹개발 트렌드를 함께 살펴보시죠! 🧲 맞춤형 비주얼(Customised Visuals)<ul ><li>브랜드 아이덴티티를 반영하여 특별히 디자인된 일반적인 스톡 이미지에서 맞춤형 레이아웃과 이미지로 전환 필요</li><li>사용자들은 창의적인 그래픽과 아이콘을 일관된 색상으로 조합하여 더욱 매력적인 경험을 제공하는 웹사이트를 기억하는 경향</li><li>맞춤형 비주얼에 투자함으로써 온라인 시장에서 차별화 및 탐색 기능을 개선하고 사용자의 콘텐츠 접근성을 높일 수 있음 </li></ul>🧲 모바일 우선 디자인(Mobile-First Design)<ul ><li>전 세계 웹 트래픽의 50% 이상이 모바일 디바이스에서 발생</li><li>모바일 응답성을 우선시하는 직관적인 웹사이트는 사용자 참여도와 리텐션 향상 유도</li><li>모바일에 맞게 작은 화면과 빠른 로딩 시간에 완벽하게 최적화 필요 </li></ul>🧲 다크 모드(Dark Mode)<ul ><li>사용자가 기존의 밝은 색상의 배경에서 어두운 테마로 전환할 수 있는 다크 모드는 최신 웹 디자인의 필수 요소</li><li>다크 모드의 인기는 미적 매력과 함께 저조도 환경에서 눈의 피로를 줄이고 OLED 화면의 배터리 수명을 절약하는 등의 이점</li><li>다크 모드는 생생한 색상 및 이미지와 잘 대비되는 세련되고 현대적인 외관을 제공함으로써 사용자 경험을 향상시키고, 사용자 참여도를 높일 수 있음 </li></ul>🧲 AR/VR을 통한 몰입형 경험(Immersive Experiences with AR/VR)<ul ><li>증강 현실과 가상 현실이 웹 개발에 통합되면서 2025년까지 사용자 상호 작용이 혁신적으로 변화할 것으로 예상</li><li>AR/VR 기술은 몰입도 높은 인터랙티브 경험을 제공하여 사용자를 더욱 깊이 참여시킴<ul ><li>예) 소매업체는 가상 의류 시착 서비스를 제공하거나 고객이 구매 전에 제품의 3D 모델을 미리 볼 수 있어 보다 효과적임</li><li>예) 부동산, 이커머스, 관광과 같은 산업에서는 브라우저를 통해 직접 실물과 같은 경험을 제공하는 데 AR과 VR이 중요한 역할 </li></ul></li></ul>🧲 싱글 페이지 애플리케이션(Single Page Applications)<ul ><li>빠른 로딩 시간과 간소화된 브라우징 경험 인기</li><li>기존 웹사이트와 달리 SPA는 전체 페이지를 다시 로드할 필요 없이 단일 HTML 페이지를 로드하고 콘텐츠를 동적으로 업데이트</li><li>빠르고 끊김 없는 브라우징 경험을 제공을 통해 방문자 유지 필수</li></ul> 🧲 혁신 기술과의 통합(Integration of Emerging Technologies)<ul ><li>인공지능, 머신러닝, 블록체인과 같은 새로운 기술은 2025년에도 웹 개발을 계속해서 재편</li><li>인공지능과 머신러닝은 각 사용자에게 개인화된 경험을 제공하는 더 스마트하고 직관적인 웹사이트를 만드는 데 사용<ul ><li>예)AI 기반 챗봇은 실시간 지원 서비스 제공</li></ul></li><li>블록체인 기술 또한 웹 개발에 더욱 통합되어 보안, 투명성, 신뢰성을 강화</li></ul> 🧲 프로그레시브 웹 앱(Progressive Web Apps)<ul ><li>웹 액세스의 편리함과 네이티브 앱의 기능을 결합하여 웹과 모바일 앱의 장점을 모두 제공</li><li>PWA는 브라우저를 통해 액세스할 수 있지만 모바일 앱처럼 작동하여 오프라인 기능을 제공</li><li>모든 디바이스에서 원활하게 작동하는 PWA는 전용 앱을 개발하지 않고도 모바일 참여도를 향상시키고자 하는 경우에 이상적임 </li></ul>🧲 보안 강화(Enhanced Security)<ul ><li>웹사이트는 다단계 인증, 암호화, 보안 프레임워크 등 더욱 강력한 보안 프로토콜을 구현하여 민감한 데이터를 보호하고 사용자 개인정보 보호 필요</li><li>보안 위협이 진화함에 따라 웹사이트에 사전 예방적 보안 조치를 도입하여 취약점을 사전에 방지하는 것이 중요</li></ul> 🧲 마이크로 인터랙션(Micro Interactions)<ul ><li>웹사이트를 통해 사용자를 안내하고 사용자 참여를 향상시키는 미묘한 디자인 요소<ul ><li>예)애니메이션, 호버 효과, 버튼 누르기, 작은 피드백 표시기 등</li></ul></li><li>마이크로 인터랙션이 더욱 발전하여 전반적인 사용자 경험을 향상시키는 부드러운 전환과 동적 요소 제공 </li></ul>🧲 음성 검색<ul ><li>Siri, Alexa, Google Assistant와 같은 음성 비서를 사용하는 사용자가 증가함에 따라 음성 검색의 인기는 계속 높아짐</li><li>웹사이트는 자연어 처리에 집중하고 음성 검색 친화적인 SEO를 구현하여 음성 검색을 통해 콘텐츠를 쉽게 찾을 수 있도록</li><li>음성 검색을 통해 사용자는 타이핑 없이도 빠르고 효율적으로 정보를 찾을 수 있으므로 이러한 트렌드에 적응하면 경쟁 우위 제공 </li></ul> <ul ><li>source: https://www.techguide.com.au/news/internet-news/top-10-web-development-trends-to-watch-in-2025/</li></ul>

Tech Guide

[TechGuide]2025년에 주목해야 할 10가지 웹 개발 트렌드

재직자 대상 커리어 성장 코스, INNER CIRCLE

패스트캠퍼스 : INNER CIRCLE | 패스트캠퍼스

주니어 개발자로서 몇 년을 일하다 보면 자연스럽게 아래와 같은 고민들을 하실 것 같습니다.

“앞으로 5년 후에도 개발자로 살아남을 수 있을까?”
“사수도 없고, 내가 혼자서 잘하고 있는 게 맞을까?”
“풀스택 개발자로 취업은 했지만, 실무에선 무슨 일이 어떻게 돌아가는지 막막하다.”
“회사에서 주어진 일만 할 게 아니라, 내가 정말 원하는 프로젝트를 해보고 싶다.”

저도 물론 경험했던 고민들이고, 특강 및 멘토링 때 매번 말씀드리는 내용이지만
이런 고민들을 해결할 수 있는 여러 방법중에 좋은것 하나는 A-Z 까지 경험해볼 수 있는 프로젝트를 진행하는 겁니다.

이와 관련되서 도움을 받으실 수 있을만한 교육 과정이 있어 공유드립니다.

바로 이너서클(INNER CIRCLE) 이라는 교육인데요, 제가 느꼈던 이너서클 교육의 가장 큰 장점은 다음과 같습니다.

📌 실무 중심의 팀프로젝트 커리큘럼
단순한 이론 수업이 아닌, 13주간 100% 팀 프로젝트 중심 커리큘럼으로 진행되어 회사에서는 경험할 수 없는 다양한 매력적인 프로젝트를 A 부터 Z 까지 진행함으로써 한단계 더 성장하는 기회가 될 수 있습니다.

📌 실시간 온라인 진행 가능
100% 실시간 온라인으로 진행하는 재직자 대상 무료 교육으로 평일 저녁, 주말에 진행하기 때문에 직장과 병행하여 수강이 가능합니다.
또한 이너서클 과정 전반에 걸쳐 패스트캠퍼스의 온라인 VOD 강의를 제공하여 커리큘럼 진행중에 얼마든지 이론적 보완과 성장이 가능합니다.

📌 동료들과 함께 성장
이너서클은 혼자가 아닌 동료 개발자들과의 협력을 경험할 수 있게 도와줍니다.
프로젝트를 진행하며 동료 개발자들간의 피드백과 상호 평가를 통해 성장하고, 수료 후에도 오프라인 네트워킹으로 지속적인 교류가 가능합니다.

📌 업계 상위 1% 리더와 검증된 동료
IT 업계 최고의 리더(네카라쿠배 출신의 IT 테크 리더)들이 강사로 참여하고, 이러한 리더들의 꼼꼼한 선발절차를 거쳐 팀프로젝트를 같이할 동료들이 선발된다고 합니다.
개발팀장, CTO 등을 하셨던 리더분들이기 때문에 높은 수준의 실무 노하우를 배울 수 있고 이런 검증된 동료들과의 실전 경험과 교류는 개발자의 커리어를 쌓아가는데 매우 중요하다고 생각합니다.

📌 비용
450만 원 상당의 교육비가 전액 국비 지원으로 무료입니다.
또한 이너서클 수료 후, 패스트캠퍼스 취준생 멘토링 프로그램에 참여할 수 있는 기회가 주어지게 되는데 만약 프로그램에 참여하게 된다면 이에 대한 수익을 얻을 수 있다고 합니다.

📌 창업 및 프로젝트 지원
팀별 프로젝트 진행 시, 프로젝트 지원금이 제공되며, 수료 후 창업을 준비한다면 패스트캠퍼스 미디어 노출, 인터뷰 등 다양한 지원을 받을 수 있습니다.

성장에 목마르신 모든 분들이 참여하실 수 있다면 좋겠지만, 3년차 이상의 경력이 있으신 분들 중 최종적으로 선별된 50명만 교육에 참여가 가능하다고 합니다.🥲

10월 27일까지 사전 신청을 완료하면, 얼리버드 이벤트로 개발자 커리어와 취업 시장에 관한 인사이트, 이너서클에 대한 사전 설명을 제공하는 멤버십 가이드 초대권도 드린다고 하니 관심있으신 분들은 이점 참고해주시면 좋겠습니다.
(설명회는 10월 31일 19시에 온라인 라이브로 진행 예정이라고 합니다.)

🔗 신청 바로 가기: https://bit.ly/3U5CQu3 

추가로 이너서클 측에서 감사하게도 제 이름으로 추천인 코드를 입력 후 수강 등록을 완료하면
대기업 이직을 위한 자기소개서 작성법 전자책을 무료로 받을 수 있게 해주신다고 하니 이 점도 참고해주세요.

🎁 추천인 코드 입력 방법
 1. 신청 바로 가기(https://bit.ly/3U5CQu3)에서 신청하기 버튼 클릭
 2. 신청 폼 작성
 3. 마지막 인지 경로 항목 작성 시 Other 클릭
 4. 주관식 문항에 추천인 코드 [이양일] 작성

이 글이 성장하고 싶으신 주니어 개발자 분들에게 조금이나마 도움이 되었으면 좋겠습니다. 🙏

주니어 개발자로서 몇 년을 일하다 보면 자연스럽게 아래와 같은 고민들을 하실 것 같습니다. “앞으로 5년 후에도 개발자로 살아남을 수 있을까?” “사수도 없고, 내가 혼자서 잘하고 있는 게 맞을까?” “풀스택 개발자로 취업은 했지만, 실무에선 무슨 일이 어떻게 돌아가는지 막막하다.” “회사에서 주어진 일만 할 게 아니라, 내가 정말 원하는 프로젝트를 해보고 싶다.” 저도 물론 경험했던 고민들이고, 특강 및 멘토링 때 매번 말씀드리는 내용이지만이런 고민들을 해결할 수 있는 여러 방법중에 좋은것 하나는 A-Z 까지 경험해볼 수 있는 프로젝트를 진행하는 겁니다. 이와 관련되서 도움을 받으실 수 있을만한 교육 과정이 있어 공유드립니다. 바로 이너서클(INNER CIRCLE) 이라는 교육인데요, 제가 느꼈던 이너서클 교육의 가장 큰 장점은 다음과 같습니다. 📌 실무 중심의 팀프로젝트 커리큘럼단순한 이론 수업이 아닌, 13주간 100% 팀 프로젝트 중심 커리큘럼으로 진행되어 회사에서는 경험할 수 없는 다양한 매력적인 프로젝트를 A 부터 Z 까지 진행함으로써 한단계 더 성장하는 기회가 될 수 있습니다. 📌 실시간 온라인 진행 가능100% 실시간 온라인으로 진행하는 재직자 대상 무료 교육으로 평일 저녁, 주말에 진행하기 때문에 직장과 병행하여 수강이 가능합니다.또한 이너서클 과정 전반에 걸쳐 패스트캠퍼스의 온라인 VOD 강의를 제공하여 커리큘럼 진행중에 얼마든지 이론적 보완과 성장이 가능합니다. 📌 동료들과 함께 성장이너서클은 혼자가 아닌 동료 개발자들과의 협력을 경험할 수 있게 도와줍니다.프로젝트를 진행하며 동료 개발자들간의 피드백과 상호 평가를 통해 성장하고, 수료 후에도 오프라인 네트워킹으로 지속적인 교류가 가능합니다. 📌 업계 상위 1% 리더와 검증된 동료IT 업계 최고의 리더(네카라쿠배 출신의 IT 테크 리더)들이 강사로 참여하고, 이러한 리더들의 꼼꼼한 선발절차를 거쳐 팀프로젝트를 같이할 동료들이 선발된다고 합니다.개발팀장, CTO 등을 하셨던 리더분들이기 때문에 높은 수준의 실무 노하우를 배울 수 있고 이런 검증된 동료들과의 실전 경험과 교류는 개발자의 커리어를 쌓아가는데 매우 중요하다고 생각합니다. 📌 비용450만 원 상당의 교육비가 전액 국비 지원으로 무료입니다.또한 이너서클 수료 후, 패스트캠퍼스 취준생 멘토링 프로그램에 참여할 수 있는 기회가 주어지게 되는데 만약 프로그램에 참여하게 된다면 이에 대한 수익을 얻을 수 있다고 합니다. 📌 창업 및 프로젝트 지원팀별 프로젝트 진행 시, 프로젝트 지원금이 제공되며, 수료 후 창업을 준비한다면 패스트캠퍼스 미디어 노출, 인터뷰 등 다양한 지원을 받을 수 있습니다. 성장에 목마르신 모든 분들이 참여하실 수 있다면 좋겠지만, 3년차 이상의 경력이 있으신 분들 중 최종적으로 선별된 50명만 교육에 참여가 가능하다고 합니다.🥲 10월 27일까지 사전 신청을 완료하면, 얼리버드 이벤트로 개발자 커리어와 취업 시장에 관한 인사이트, 이너서클에 대한 사전 설명을 제공하는 멤버십 가이드 초대권도 드린다고 하니 관심있으신 분들은 이점 참고해주시면 좋겠습니다.(설명회는 10월 31일 19시에 온라인 라이브로 진행 예정이라고 합니다.) 🔗 신청 바로 가기: https://bit.ly/3U5CQu3&nbsp; 추가로 이너서클 측에서 감사하게도 제 이름으로 추천인 코드를 입력 후 수강 등록을 완료하면대기업 이직을 위한 자기소개서 작성법 전자책을 무료로 받을 수 있게 해주신다고 하니 이 점도 참고해주세요. 🎁 추천인 코드 입력 방법<ol ><li>신청 바로 가기(https://bit.ly/3U5CQu3)에서&nbsp;신청하기&nbsp;버튼 클릭</li><li>신청 폼 작성</li><li>마지막&nbsp;인지 경로&nbsp;항목 작성 시&nbsp;Other&nbsp;클릭</li><li>주관식 문항에 추천인 코드 [이양일] 작성</li></ol> 이 글이 성장하고 싶으신 주니어 개발자 분들에게 조금이나마 도움이 되었으면 좋겠습니다. 🙏

📢 실무 프로젝트로 성장하고 싶은 주니어 개발자 분들에게

폭포수모델의 SW 프로세스 글에서 간략히 다루었던 협업 프로세스에서의 테스트 활동에 대해 좀 더 자세히 살펴보겠습니다. 

테스트 프로세스
테스트 프로세스는, 개발된 소프트웨어의 품질 기준을 만족하기 위한 테스트 수행 절차로 소프트웨어 테스트를 효율적으로 실행하기 위한 테스트 계획과 설계, 조직의 역할과 책임, 필요한 작업 및 절차, 산출물 등 테스트 단계별 활동을 정의한 것입니다. 
테스트 프로세스를 통해 소프트웨어의 품질 기준과 테스트 범위를 측정하고 개발 구현된 소프트웨어와 요구 사항과의 차이를 판별하며 테스트 진행과정을 관리하기 위해 각 테스트 단계의 활동을 정의하는 것이 목적입니다. 

테스트 프로세스는 테스트 계획에 따라 테스트를 수행하기 위한 세부 활동과 테스트 조직의 품질 목표와 기준을 바탕으로 테스트 수행을 모니터링하고 제어하며 테스트 종료 활동을 포함합니다.
테스트 수행을 위한 세부 활동은 테스트 설계 및 구현, 테스트 환경 구축, 테스트 실행, 검출된 결함 등록 및 관리, 테스트 산출물(설계서, 테스트 케이스, 준비·진행·완료 보고서 등) 작성 및 관리, 종료 활동으로 구성됩니다. 

테스트 프로세스: 세부 단계별 활동의 정의와 수행방법
테스트 계획
테스트 계획은 소프트웨어의 품질 목표를 달성하기 위해 검증에 필요한 활동을 정의하는 단계로 전체 테스트 범위를 포함한 종합적인 계획과 폭포수 모델 단계별 테스트 수행 계획 및 테스트 유형별(기능성, 유지보수성, 사용성 등) 수행 계획으로 설계합니다. 

①테스트 수행 계획은 테스트 대상 시스템 및 비즈니스 리스크를 식별하고 테스트 주요 요소를 분류하여 테스트 전략을 수립합니다. 수행 계획과 전략 설계 시 프로젝트 계획서와 요구사항을 분석하여 테스트 범위, 테스트 목적, 리스크 분석, 담당자, 일정, 투입 비용, 제약 사항 등을 고려합니다.
② 프로젝트 계획서/요구사항을 분석하여 테스트 목적 및 테스트 범위 설정, 테스트 일정을 계획합니다.
③ 개발 생명주기 각 단계에 적합한 테스트 유형을 선정하고 테스트 단계별 수행방법을 정의합니다.
  ▶ 개발 생명주기 : waterfall, agile에 따라 테스트 유형과 방법 정의 및 선정 
  ▶ 테스트 유형 : 기능 테스트, 성능 테스트, API 테스트, 네트워크 테스트 등 선정
  ▶ 테스트 방법 선택시 고려사항 : 시스템 복잡도, 중요도, 조직/개발 성숙도, 요구사항, 일정 등
고려
④ 테스트 단계별 품질 목표 기준을 선정하고 품질 지표 관리 방안을 정의합니다. 
▶ 테스트 시작 기준 
Fail 시 테스트 중단. 수정 후 다음 시작 가능 시기 조율.
  ▶ 테스트 완료 기준 
제품 출시를 위한 오픈 가능한 품질 목표 기준을 설정하여 Fail시 출시 일정을 지연하거나 추가
테스트 일정을 조율합니다.
품질 목표를 달성하여 제품 출시가 가능한 상태인지 공유하고 최종 품질 상태에 대한 QA 판단
결과 오픈 가능 여부를 전달합니다.

[테스트 완료 기준 예시]
1. 계획된 품질 보증 활동을 모두 완료
2. 위험도가 “중” 이상인 리스크가 없거나 대응 방안이 마련되어야 함
3. Major 이상 잔존 결함 없음
4. 잔존하는 이슈 / 리스크가 있을 경우 대응 방안이 준비되지 않았다면 테스트 종료 불가함
5. 보안 검수 및 성능 검수 결과 권고된 시정 사항이 조치 완료되거나 대응 방안 마련
6. 테스트 종료가 불가한 경우 프로젝트 담당자가 모두 참여하여 제품의 품질 상태 확인 및 테스트 종료가 불가한 원인을 확인하여 제품 출시 여부를 결정하도록 함 & 해결되어야 하는 문제에 대한 해결방안 마련 및 추가 일정 협의

⑤ 테스트 수행 환경 구성 및 구현
테스트를 수행하기 위한 기본 데이터들을 정리하고 어떤 환경에서 테스트를 수행할 지 미리 준비하여 각 프로젝트 목적에 맞는 환경과 자원을 준비하고 문서화합니다. 테스트를 위한 데이터의 예로는 테스트 계정, 계정에 따른 권한, 네트워크, 제품 출시 타겟 국가에 따른 조건, 테스트 서버(API, 클라이언트, DB 등) 설정 등이 있습니다. 

[테스트 환경 예시]
▶ Dev : 개발 환경
▶ QA : QA 테스트 환경
▶ Staging : 실 환경을 복제한 운영 테스트용 환경 (라이브와 동일한 서버/DB 백업)
▶ 각각의 환경과 연동된 테스트 빌드 

⑥ 테스트 수행 역할 선정
⑦ 테스트 단계별 산출물 정의
⑧ 계획된 테스트 전략을 바탕으로 QA Plan 작성 
QA Plan은 테스트를 하기위해 필요한 자원들을 요약한 것으로 정해진 프로세스대로 업무를 수행하기 위한 청사진 역할을 하며 계획된 방향으로 테스트가 진행될 수 있도록 가이드 역할을 합니다.

테스트 설계
테스트 목표와 목적을 테스트 케이스로 변환하는 단계입니다. 테스트 설계는 고객 요구사항 명세서, 기획 문서, 개발 설계서와 시스템 아키텍처 등의 산출물과 리스크 분석 결과를 기반으로 테스트 대상을 식별하고 테스트 범위를 정의하며 테스트 절차에 따른 수행 명세서(테스트 케이스 또는 테스트 시나리오)를 작성하는 활동입니다. 

테스트 케이스를 작성하기 위해 먼저 ①테스트 대상을 분석하고 범위를 선정합니다. 테스트 베이시스를 분석하여 테스트 대상 기능을 선정하고 리스크 분석을 통해 테스트 우선순위를 선정하며 테스트 전략과 총괄 테스트 수행 계획서를 바탕으로 테스트 범위를 결정합니다. 이를 바탕으로 자동화, API, 보안, 성능 등 기술 검증이 필요한 범위를 도출합니다.

테스트 대상 분석 및 테스트 범위가 식별되면 테스트 베이시스를 기반으로 ②테스트 케이스 또는 테스트 시나리오를 작성합니다. 테스트 케이스 작성 시 명세서와 요구사항에 맞춰 테스트 성공과 실패 기준을 정의하고 테스트 설계 기법을 적용하여 테스트 케이스를 작성합니다. 효율적이고 효과적인 테스트 실행을 위하여 기능 연관성과 유저 흐름을 고려하여 테스트 케이스의 순서를 구성하도록 합니다. 또한 기술 검증에 필요한 테스트 스크립트 작성을 위해 테스트 케이스를 선별합니다. 테스트 케이스 작성이 완료되면 테스트 조직 내부 또는 프로젝트 관련자와 함께 리뷰를 진행하여 작성된 내용을 검토합니다. 

테스트 케이스 작성이 완료되면 테스트 수행을 위한 ③테스트 데이터 및 테스트 도구를 준비합니다.  기능 및 기술 검증용 테스트 케이스를 실행하기 위한 데이터와 테스트 대상을 설정하는 데 필요한 데이터, 테스트 케이스에서 요구하는 조건과 상태를 충족하게 만드는 데이터를 준비하고 기술 검증 테스트를 위한 도구(예: Appium, Postman, Jmeter 등)와 결함 보고용 관리 도구(예: JIRA, Redmine 등)를 준비합니다.

테스트 구현과 실행
①테스트 구현은 선별한 테스트 케이스에 맞게 자동화, 성능, API 등 기술 검증용 테스트 코드를 작성하고 코드를 실행하여 성공·실패 검증 포인트를 설정하고 무결성을 검증하는 활동입니다.
②테스트 실행은 작성한 테스트 케이스를 바탕으로 테스트 활동을 수행하는 단계입니다. 테스트 케이스를 수행하기 전 프로젝트 정책에 따라 수행해야 하는 테스트 환경을 확인합니다. 설정된 환경에서 테스트 케이스에 기술된 단계와 테스트 데이터를 확인하고 해당 기능이 수행 절차에 따라 기대 결과를 만족하는지 실행 결과를 기록하며 테스트를 수행합니다. 

테스트 실행 중 기대 결과에 만족하지 못해 실패 처리된 결과는 분석을 통해 테스터의 단순 실수인지 시스템 결함인지 판단하여 수정이 필요한 결함으로 판명되거나 테스트 케이스에 기술되어 있지 않지만 유효한 버그를 발견한 경우 버그 관리 시스템에 ③결함을 기록하고 프로젝트 관계자들에게 이슈를 보고합니다. 등록된 버그에 해당되는 테스트 케이스에는 버그의 ID(식별자)를 기록하여 버그 진행 상태를 체크하고 업데이트합니다.

테스트 수행이 완료되면 ④테스트 결과를 기록하고 검토합니다. 테스트 케이스 실행 결과 및 보고된 결함의 조치 내역을 취합하여 품질 상태에 대한 기록을 작성합니다. 작성된 기록을 확인하여 테스트 진행 상황, 제품 품질 상태, 테스트 활동 품질, 프로젝트 진행 중 논의가 필요한 주제, 주요 결함 내용을 파악하고 테스트 수행에 걸림돌이 되는 부분을 제거하고 계획한 품질 검증 활동을 일정에 맞춰 완료할 수 있도록 필요한 조치를 지원합니다.

테스트 완료 및 평가
계획한 품질 보증 활동을 완료하면 테스트 완료 조건과 최종 테스트 수행 결과를 비교하여 출시가 가능한 상태인지 판단하여 ①테스트 최종 결과 보고서를 작성합니다. 제품의 출시 가능 여부는 테스트 종료 보고서QA Sign-off로 전달됩니다. 이 보고서를 통해 품질 목표를 달성했는지, 출시가 가능한 상태인지 공유하고 최종 품질 상태에 대한 테스트 담당자의 판단 결과를 전달합니다. 

산출물 구성은 테스트 수행 단계별 품질 현황 결과 보고서와 유사하나 내용상 두가지 차이가 있습니다. 첫째, 테스트 담당자의 테스트 완료 평가와 제품의 출시 가능 여부에 대한 최종 의견을 전달합니다. 출시 불가한 상황일 경우 원인을 공유하고 문제 해결 방안과 출시 여부 결정을 위한 관련자 협의 미팅(오픈 적합성 회의)을 요청합니다. 둘째, 전체 테스트 기간에 수행된 테스트의 최종 상태를 공유합니다. 총 테스트 케이스 수행 결과, 계획 대비 차이점, 잔존 결함과 리스크, 합의된 논 이슈known-issue를 공유하고 전체 품질 검증 활동 진행 결과를 작성합니다. 

테스트를 종료하고 제품의 출시가 결정되면 오픈 예정일에 제품이 고객에게 공개됩니다. 출시 후 테스터는 라이브 환경에서 제품의 주요 기능과 작동에 문제가 발생하지 않는지, 고객의 불편사항과 결함에 대한 피드백이 전달되지 않는지 ②모니터링을 수행합니다. 모니터링 후 특별한 이슈나 특이사항이 발생하지 않으면 모니터링 보고서를 공유하고 프로젝트를 최종 마무리합니다. 이후 유지보수 담당자에게 제품 및 품질 기록을 이관함으로 테스트 프로세스가 종료됩니다.

마지막으로 ③완료된 품질 검증 활동과 프로세스를 평가하고 개선사항을 제안하는 미팅을 진행합니다. 테스트 활동에 대한 평가는 완료된 프로젝트에서 수행한 테스트 활동 데이터를 수집하고 각 테스트 단계와 테스트 종류별로 결과를 분석하여 테스트 활동에 대한 객관적인 평가를 기록합니다. 해당 미팅의 참여 대상은 프로젝트에 참여한 테스트 담당자(QA, TL, SET, TE) 및 테스트 조직 전체이며 미팅의 주요 의제는 테스트 수행 시 발생한 문제점(휴먼 이슈, 테스트 산출물 이슈 등), 수행 절차상 개선사항, 특이 결함 케이스, 프로세스 개선 사항을 공유하여 테스트 지식과 경험을 축적하고 문제점을 개선하는 활동을 수행합니다.

테스트 평가가 완료되면 각 프로젝트 관련자들과 모여 ④프로젝트 회고Post-mortem 활동을 진행합니다. 회고를 진행하는 목적은 각 직무 담당자의 잘잘못을 가리고 찾아내는 것에 집중하는 것보다 모두가 서로에게 안전하게 이야기할 수 있는 환경을 만들고 회고라는 마침표를 찍음으로 새로운 일을 준비할 수 있도록 하기 위함입니다. 회고의 참여 대상은 기획, 개발, 테스터, 마케팅 등 프로젝트 전체 인원이며 미팅의 주요 회고 내용은 프로젝트에서 발생한 잘한 일(Keep), 잘못한 일(Problem), 개선 활동(Try)을 복기하는 것입니다. 잘한 일은 앞으로 더 잘할 수 있도록 프로세스로 정립하고 잘못된 일은 재발을 방지하기 위한 대책을 수립하거나 시스템 또는 프로세스의 개선 방안을 도출하여 이전보다 나은 다음을 준비합니다.

폭포수모델의 SW 프로세스 글에서 간략히 다루었던 협업 프로세스에서의 테스트 활동에 대해 좀 더 자세히 살펴보겠습니다.&nbsp; 테스트 프로세스테스트 프로세스는, 개발된 소프트웨어의 품질 기준을 만족하기 위한 테스트 수행 절차로 소프트웨어 테스트를 효율적으로 실행하기 위한 테스트 계획과 설계, 조직의 역할과 책임, 필요한 작업 및 절차, 산출물 등 테스트 단계별 활동을 정의한 것입니다.&nbsp;테스트 프로세스를 통해 소프트웨어의 품질 기준과 테스트 범위를 측정하고 개발 구현된 소프트웨어와 요구 사항과의 차이를 판별하며 테스트 진행과정을 관리하기 위해 각 테스트 단계의 활동을 정의하는 것이 목적입니다.&nbsp; 테스트 프로세스는 테스트 계획에 따라 테스트를 수행하기 위한 세부 활동과 테스트 조직의 품질 목표와 기준을 바탕으로 테스트 수행을 모니터링하고 제어하며 테스트 종료 활동을 포함합니다.테스트 수행을 위한 세부 활동은 테스트 설계 및 구현, 테스트 환경 구축, 테스트 실행, 검출된 결함 등록 및 관리, 테스트 산출물(설계서, 테스트 케이스, 준비·진행·완료 보고서 등) 작성 및 관리, 종료 활동으로 구성됩니다.&nbsp; 테스트 프로세스:&nbsp;세부 단계별 활동의 정의와 수행방법테스트 계획테스트 계획은 소프트웨어의 품질 목표를 달성하기 위해 검증에 필요한 활동을 정의하는 단계로 전체 테스트 범위를 포함한 종합적인 계획과 폭포수 모델 단계별 테스트 수행 계획 및 테스트 유형별(기능성, 유지보수성, 사용성 등) 수행 계획으로 설계합니다.&nbsp; ①테스트 수행 계획은&nbsp;테스트 대상 시스템 및 비즈니스 리스크를 식별하고 테스트 주요 요소를 분류하여 테스트 전략을 수립합니다. 수행 계획과 전략 설계 시 프로젝트 계획서와 요구사항을 분석하여 테스트 범위, 테스트 목적, 리스크 분석, 담당자, 일정, 투입 비용, 제약 사항 등을 고려합니다.② 프로젝트 계획서/요구사항을 분석하여 테스트 목적 및 테스트 범위 설정, 테스트 일정을 계획합니다.③ 개발 생명주기 각 단계에 적합한 테스트 유형을 선정하고 테스트 단계별 수행방법을 정의합니다.&nbsp;&nbsp;▶ 개발 생명주기 : waterfall, agile에 따라 테스트 유형과 방법 정의 및 선정&nbsp;&nbsp;&nbsp;▶&nbsp;테스트 유형 : 기능 테스트, 성능 테스트, API 테스트, 네트워크 테스트 등 선정&nbsp;&nbsp;▶ 테스트 방법 선택시 고려사항 : 시스템 복잡도, 중요도, 조직/개발 성숙도, 요구사항, 일정 등 고려④ 테스트 단계별 품질 목표 기준을 선정하고 품질 지표 관리 방안을 정의합니다.&nbsp; ▶ 테스트&nbsp;시작 기준&nbsp; Fail 시 테스트 중단. 수정 후 다음 시작 가능 시기 조율.&nbsp; ▶ 테스트&nbsp;완료 기준&nbsp; 제품 출시를 위한 오픈 가능한 품질 목표 기준을 설정하여 Fail시 출시 일정을 지연하거나 추가 테스트 일정을 조율합니다. 품질 목표를 달성하여 제품 출시가 가능한 상태인지 공유하고 최종 품질 상태에 대한 QA 판단 결과 오픈 가능 여부를 전달합니다. [테스트 완료 기준 예시] 1. 계획된 품질 보증 활동을 모두 완료2. 위험도가 “중” 이상인 리스크가 없거나 대응 방안이 마련되어야 함3. Major 이상 잔존 결함 없음4. 잔존하는 이슈 / 리스크가 있을 경우 대응 방안이 준비되지 않았다면 테스트 종료 불가함5. 보안 검수 및 성능 검수 결과 권고된 시정 사항이 조치 완료되거나 대응 방안 마련6. 테스트 종료가 불가한 경우 프로젝트 담당자가 모두 참여하여 제품의 품질 상태 확인 및 테스트 종료가 불가한 원인을 확인하여 제품 출시 여부를 결정하도록 함 &amp; 해결되어야 하는 문제에 대한 해결방안 마련 및 추가 일정 협의 ⑤ 테스트 수행 환경 구성 및 구현 테스트를 수행하기 위한 기본 데이터들을 정리하고 어떤 환경에서 테스트를 수행할 지 미리 준비하여 각 프로젝트 목적에 맞는 환경과 자원을 준비하고 문서화합니다.&nbsp;테스트를 위한 데이터의 예로는 테스트 계정, 계정에 따른 권한, 네트워크, 제품 출시 타겟 국가에 따른 조건, 테스트 서버(API, 클라이언트, DB 등) 설정 등이 있습니다.&nbsp; [테스트 환경 예시]▶ Dev : 개발 환경▶ QA : QA 테스트 환경▶ Staging : 실 환경을 복제한 운영 테스트용 환경 (라이브와 동일한 서버/DB 백업)▶ 각각의 환경과 연동된 테스트 빌드&nbsp; ⑥ 테스트 수행 역할 선정⑦ 테스트 단계별 산출물 정의⑧&nbsp;계획된 테스트 전략을 바탕으로 QA Plan 작성&nbsp;QA Plan은 테스트를 하기위해 필요한 자원들을 요약한 것으로 정해진 프로세스대로 업무를 수행하기 위한 청사진 역할을 하며 계획된 방향으로 테스트가 진행될 수 있도록 가이드 역할을 합니다. 테스트 설계테스트 목표와 목적을 테스트 케이스로 변환하는 단계입니다. 테스트 설계는 고객 요구사항 명세서, 기획 문서, 개발 설계서와 시스템 아키텍처 등의 산출물과 리스크 분석 결과를 기반으로 테스트 대상을 식별하고 테스트 범위를 정의하며 테스트 절차에 따른 수행 명세서(테스트 케이스 또는 테스트 시나리오)를 작성하는 활동입니다.&nbsp; 테스트 케이스를 작성하기 위해 먼저&nbsp;①테스트 대상을 분석하고 범위를 선정합니다. 테스트 베이시스를 분석하여 테스트 대상 기능을 선정하고 리스크 분석을 통해 테스트 우선순위를 선정하며 테스트 전략과 총괄 테스트 수행 계획서를 바탕으로 테스트 범위를 결정합니다. 이를 바탕으로 자동화, API, 보안, 성능 등 기술 검증이 필요한 범위를 도출합니다. 테스트 대상 분석 및 테스트 범위가 식별되면 테스트 베이시스를 기반으로&nbsp;②테스트 케이스 또는 테스트 시나리오를 작성합니다. 테스트 케이스 작성 시 명세서와 요구사항에 맞춰 테스트 성공과 실패 기준을 정의하고 테스트 설계 기법을 적용하여 테스트 케이스를 작성합니다. 효율적이고 효과적인 테스트 실행을 위하여 기능 연관성과 유저 흐름을 고려하여 테스트 케이스의 순서를 구성하도록 합니다. 또한 기술 검증에 필요한 테스트 스크립트 작성을 위해 테스트 케이스를 선별합니다. 테스트 케이스 작성이 완료되면 테스트 조직 내부 또는 프로젝트 관련자와 함께 리뷰를 진행하여 작성된 내용을 검토합니다.&nbsp; 테스트 케이스 작성이 완료되면 테스트 수행을 위한&nbsp;③테스트 데이터 및 테스트 도구를 준비합니다. &nbsp;기능 및 기술 검증용 테스트 케이스를 실행하기 위한 데이터와 테스트 대상을 설정하는 데 필요한 데이터, 테스트 케이스에서 요구하는 조건과 상태를 충족하게 만드는 데이터를 준비하고 기술 검증 테스트를 위한 도구(예: Appium, Postman, Jmeter 등)와 결함 보고용 관리 도구(예: JIRA, Redmine 등)를 준비합니다. 테스트 구현과 실행①테스트 구현은&nbsp;선별한 테스트 케이스에 맞게&nbsp;자동화, 성능, API 등 기술 검증용 테스트 코드를 작성하고&nbsp;코드를 실행하여 성공·실패 검증 포인트를 설정하고 무결성을 검증하는 활동입니다.②테스트 실행은 작성한 테스트 케이스를 바탕으로 테스트 활동을 수행하는 단계입니다. 테스트 케이스를 수행하기 전 프로젝트 정책에 따라 수행해야 하는 테스트 환경을 확인합니다. 설정된 환경에서 테스트 케이스에 기술된 단계와 테스트 데이터를 확인하고 해당 기능이 수행 절차에 따라 기대 결과를 만족하는지 실행 결과를 기록하며 테스트를 수행합니다.&nbsp; 테스트 실행 중 기대 결과에 만족하지 못해 실패 처리된 결과는 분석을 통해 테스터의 단순 실수인지 시스템 결함인지 판단하여 수정이 필요한 결함으로 판명되거나 테스트 케이스에 기술되어 있지 않지만 유효한 버그를 발견한 경우 버그 관리 시스템에 ③결함을 기록하고 프로젝트 관계자들에게 이슈를 보고합니다.&nbsp;등록된 버그에 해당되는 테스트 케이스에는 버그의 ID(식별자)를 기록하여 버그 진행 상태를 체크하고 업데이트합니다. 테스트 수행이 완료되면&nbsp;④테스트 결과를 기록하고 검토합니다. 테스트 케이스 실행 결과 및 보고된 결함의 조치 내역을 취합하여 품질 상태에 대한 기록을 작성합니다. 작성된 기록을 확인하여 테스트 진행 상황, 제품 품질 상태, 테스트 활동 품질, 프로젝트 진행 중 논의가 필요한 주제, 주요 결함 내용을 파악하고 테스트 수행에 걸림돌이 되는 부분을 제거하고 계획한 품질 검증 활동을 일정에 맞춰 완료할 수 있도록 필요한 조치를 지원합니다. 테스트 완료 및 평가계획한 품질 보증 활동을 완료하면 테스트 완료 조건과 최종 테스트 수행 결과를 비교하여 출시가 가능한 상태인지 판단하여&nbsp;①테스트 최종 결과 보고서를 작성합니다.&nbsp;제품의 출시 가능 여부는&nbsp;테스트 종료 보고서QA Sign-off로 전달됩니다. 이 보고서를 통해 품질 목표를 달성했는지, 출시가 가능한 상태인지 공유하고 최종 품질 상태에 대한 테스트 담당자의 판단 결과를 전달합니다.&nbsp; 산출물 구성은 테스트 수행 단계별 품질 현황 결과 보고서와 유사하나 내용상 두가지 차이가 있습니다.&nbsp;첫째,&nbsp;테스트 담당자의 테스트 완료 평가와 제품의 출시 가능 여부에 대한 최종 의견을 전달합니다. 출시 불가한 상황일 경우 원인을 공유하고 문제 해결 방안과 출시 여부 결정을 위한 관련자 협의 미팅(오픈 적합성 회의)을 요청합니다.&nbsp;둘째,&nbsp;전체 테스트 기간에 수행된 테스트의 최종 상태를 공유합니다. 총 테스트 케이스 수행 결과, 계획 대비 차이점, 잔존 결함과 리스크, 합의된 논 이슈known-issue를 공유하고 전체 품질 검증 활동 진행 결과를 작성합니다.&nbsp; 테스트를 종료하고 제품의 출시가 결정되면 오픈 예정일에 제품이 고객에게 공개됩니다. 출시 후 테스터는 라이브 환경에서 제품의 주요 기능과 작동에 문제가 발생하지 않는지, 고객의 불편사항과 결함에 대한 피드백이 전달되지 않는지&nbsp;②모니터링을 수행합니다. 모니터링 후 특별한 이슈나 특이사항이 발생하지 않으면 모니터링 보고서를 공유하고 프로젝트를 최종 마무리합니다. 이후 유지보수 담당자에게 제품 및 품질 기록을 이관함으로 테스트 프로세스가 종료됩니다. 마지막으로 ③완료된&nbsp;품질 검증 활동과 프로세스를 평가하고 개선사항을 제안하는 미팅을 진행합니다.&nbsp;테스트 활동에 대한 평가는 완료된 프로젝트에서 수행한 테스트 활동 데이터를 수집하고 각 테스트 단계와 테스트 종류별로 결과를 분석하여 테스트 활동에 대한 객관적인 평가를 기록합니다. 해당 미팅의&nbsp;참여 대상은 프로젝트에 참여한 테스트 담당자(QA, TL, SET, TE) 및 테스트 조직 전체이며 미팅의 주요 의제는&nbsp;테스트 수행 시 발생한 문제점(휴먼 이슈, 테스트 산출물 이슈 등), 수행 절차상 개선사항, 특이 결함 케이스, 프로세스 개선 사항을 공유하여 테스트 지식과 경험을 축적하고 문제점을 개선하는 활동을 수행합니다. 테스트 평가가 완료되면 각 프로젝트 관련자들과 모여 ④프로젝트 회고Post-mortem&nbsp;활동을 진행합니다.&nbsp;회고를 진행하는 목적은 각 직무 담당자의 잘잘못을 가리고 찾아내는 것에 집중하는 것보다 모두가 서로에게 안전하게 이야기할 수 있는 환경을 만들고 회고라는 마침표를 찍음으로 새로운 일을 준비할 수 있도록 하기 위함입니다. 회고의 참여 대상은&nbsp;기획, 개발, 테스터, 마케팅 등 프로젝트 전체 인원이며 미팅의 주요 회고 내용은 프로젝트에서 발생한 잘한 일(Keep), 잘못한 일(Problem), 개선 활동(Try)을 복기하는 것입니다. 잘한 일은 앞으로 더 잘할 수 있도록 프로세스로 정립하고 잘못된 일은 재발을 방지하기 위한 대책을 수립하거나 시스템 또는 프로세스의 개선 방안을 도출하여 이전보다 나은 다음을 준비합니다.

[SW프로세스 III]협업 프로세스 내 테스트 활동

Facebook

과거 퍼블리에서 근무하시던 민우님께서 퍼블리를 애도하며 써주신 글입니다. 결국 사업은 시장의 크기나 시장의 성장 가능성이 있는 곳에서 하는게 성공할 가능성이 높아진다 라는 의미가 담겨있습니다.

퍼블리의 첫 타겟 고객은 고급 컨텐츠, 지적 컨텐츠를 바라는 사람들이었습니다.
책 읽기를 좋아하고, 뛰어난 사람들은 어떤 생각을 하는지 궁금해하고, 남들이 모르는 걸 알게 되면 자랑하고 싶어서 근질근질거리는 사람들을 위한 컨텐츠를 표방하며 사람들을 끌어들였습니다.

그런데 회사에 들어가서 보니
구매 데이터를 분석하고, 구매자들을 만나서 심층 인터뷰를 하고, 광고를 집행해보면서 내린 결론 은 시장의 뚜렷한 한계가 있는걸로 보였습니다.
이 시장은 한계가 있고, 타겟 대상으로 뭔가를 파는 시장은 벤처 스케일의 스타트업이 타겟할 만큼의 규모가 나오지 않는다고 생각했습니다.
이 소수의 고객들 마저 '신선한 시도'에 돈을 내고 있는거지, 지속적으로 구매를 해줄 가능성은 낮다고 생각했습니다.

이 의견에 대해서 설득하지 못했습니다.
데이터를 분석하는, 고객을 만나는, 광고를 집행하는 사람도 저 혼자였기에 팀에 설득하기란 쉽지 않았습니다. 또한 고급 컨텐츠, 지적 컨텐츠에 커다란 애정을 가지고 있는 공동창업자를 설득하는 건 거의 불가능에 가까운 일이었습니다.
하지만 설득할 필요 없이 시장은 명확하게 피드백을 주고 있었습니다.

그러고 나서 조금씩 큰 시장을 찾아내려고 했었습니다.
고객이 제품에서 가치를 얻는 데에 걸리는 시간이 너무 길다고 판단했고, 짧은 호흡의 컨텐츠, 바로 써먹을 수 있는 컨텐츠를 제공해야 더 많은 고객이 이용할 것이라고 판단했습니다.
먹고사니즘이 걸려있는, 불안감을 해소하고 싶은 자들은 직업에 대한 불안이 큰 사람들일 거라 판단했고 그 결과로 사회 초년생들을 타겟하기 시작했습니다.

조금씩 고객 규모는 늘어났지만
너무 조금씩 늘어났고, 어느 순간에는 한계에 부딪혔다고 생각했습니다. 퍼블리가 타겟하는 고객은 '일을 더 잘하고 싶은 사람 & 꾸준히 정진하는 사람 & 능동적으로 텍스트를 읽고 이해하려는 사람 & 거기에 돈을 쓸 만큼 진심인 사람' 들의 교집합이기에 이 시장은 너무 작고, 아무리 광고비를 쏟아부어도 성장에 한계가 있을 것이라고 결론을 내렸습니다.

물론 반대되는 생각도 있었습니다.
퍼블리는 충분히 매력적이고, 시장이 작은게 아닌 잘 못팔고 있는거고 잘 팔면 충분히 클것이다 라는 의견입니다.

일하면서 강하게 하게 된 생각은
'스타트업은 시장 크기가 거의 전부다' 라는 것입니다.
퍼블리 이전에는 쏘카에서 일했는데 쏘카존을 늘리는 대로 성장했고 하루에 몇억씩 매출이 나는 게 너무 당연했습니다. 차를 구매할 만큼의 경제력은 없지만 차를 타고 운전하고 싶은 욕망을 가진 젊은이들이 너무 많았고 쏘카는 욕망에 맞게 차를 공급해주기만 하면 됐습니다.

퍼블리에서는 열심히 일했지만 한계가 있었습니다.
충분히 뛰어난 역량을 가진 구성원들이였고, 좋은 방식으로 일하려 했습니다. 이 구성원들이 다른 시장을 타겟하는 사업을 했으면 분명히 좋은 성과가 나왔을 거라고 생각합니다.
사업이 성장하고 성공하려면 사람들의 욕망을 건드려야하고, 그게 벤처 스케일의 사업이 되려면 큰 욕망을 건드려야 했었습니다.

과거 퍼블리에서 근무하시던 민우님께서 퍼블리를 애도하며 써주신 글입니다. 결국 사업은 시장의 크기나 시장의 성장 가능성이 있는 곳에서 하는게 성공할 가능성이 높아진다 라는 의미가 담겨있습니다. 퍼블리의 첫 타겟 고객은 고급 컨텐츠, 지적 컨텐츠를 바라는 사람들이었습니다.책 읽기를 좋아하고, 뛰어난 사람들은 어떤 생각을 하는지 궁금해하고, 남들이 모르는 걸 알게 되면 자랑하고 싶어서 근질근질거리는 사람들을 위한 컨텐츠를 표방하며 사람들을 끌어들였습니다. 그런데 회사에 들어가서 보니구매 데이터를 분석하고, 구매자들을 만나서 심층 인터뷰를 하고, 광고를 집행해보면서 내린 결론 은 시장의 뚜렷한 한계가 있는걸로 보였습니다.이 시장은 한계가 있고, 타겟 대상으로 뭔가를 파는 시장은 벤처 스케일의 스타트업이 타겟할 만큼의 규모가 나오지 않는다고 생각했습니다. 이 소수의 고객들 마저 '신선한 시도'에 돈을 내고 있는거지, 지속적으로 구매를 해줄 가능성은 낮다고 생각했습니다. 이 의견에 대해서 설득하지 못했습니다.데이터를 분석하는, 고객을 만나는, 광고를 집행하는 사람도 저 혼자였기에 팀에 설득하기란 쉽지 않았습니다. 또한 고급 컨텐츠, 지적 컨텐츠에 커다란 애정을 가지고 있는 공동창업자를 설득하는 건 거의 불가능에 가까운 일이었습니다. 하지만 설득할 필요 없이 시장은 명확하게 피드백을 주고 있었습니다. 그러고 나서 조금씩 큰 시장을 찾아내려고 했었습니다. 고객이 제품에서 가치를 얻는 데에 걸리는 시간이 너무 길다고 판단했고, 짧은 호흡의 컨텐츠, 바로 써먹을 수 있는 컨텐츠를 제공해야 더 많은 고객이 이용할 것이라고 판단했습니다. 먹고사니즘이 걸려있는, 불안감을 해소하고 싶은 자들은 직업에 대한 불안이 큰 사람들일 거라 판단했고 그 결과로 사회 초년생들을 타겟하기 시작했습니다. 조금씩 고객 규모는 늘어났지만너무 조금씩 늘어났고, 어느 순간에는 한계에 부딪혔다고 생각했습니다. 퍼블리가 타겟하는 고객은 '일을 더 잘하고 싶은 사람 &amp; 꾸준히 정진하는 사람 &amp; 능동적으로 텍스트를 읽고 이해하려는 사람 &amp; 거기에 돈을 쓸 만큼 진심인 사람' 들의 교집합이기에 이 시장은 너무 작고, 아무리 광고비를 쏟아부어도 성장에 한계가 있을 것이라고 결론을 내렸습니다. 물론 반대되는 생각도 있었습니다.퍼블리는 충분히 매력적이고, 시장이 작은게 아닌 잘 못팔고 있는거고 잘 팔면 충분히 클것이다 라는 의견입니다. 일하면서 강하게 하게 된 생각은'스타트업은 시장 크기가 거의 전부다' 라는 것입니다. 퍼블리 이전에는 쏘카에서 일했는데 쏘카존을 늘리는 대로 성장했고 하루에 몇억씩 매출이 나는 게 너무 당연했습니다. 차를 구매할 만큼의 경제력은 없지만 차를 타고 운전하고 싶은 욕망을 가진 젊은이들이 너무 많았고 쏘카는 욕망에 맞게 차를 공급해주기만 하면 됐습니다. 퍼블리에서는 열심히 일했지만 한계가 있었습니다.충분히 뛰어난 역량을 가진 구성원들이였고, 좋은 방식으로 일하려 했습니다. 이 구성원들이 다른 시장을 타겟하는 사업을 했으면 분명히 좋은 성과가 나왔을 거라고 생각합니다. 사업이 성장하고 성공하려면 사람들의 욕망을 건드려야하고, 그게 벤처 스케일의 사업이 되려면 큰 욕망을 건드려야 했었습니다.

www.facebook.com

결국 시장이 제일 중요하다

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

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

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

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

사이드 프로젝트 만들 때

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 시각화툴

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

알고리즘 | 알고달레

📕 코딩 테스트에 단골로 등장하는 문제(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

네이버 블로그 | 계절의 기록

《올리브영 다크 패턴에 돌아선 사용자》

 1. 개요 : 웹 애플리케이션을 구축하는 새로운 방법. 선언적인 컴포넌트를 가져와서 효율적인 JavaScript로 변환하여 DOM을 정교하게 업데이트하는 컴파일러. 따로 프레임워크를 로딩하지 않기에 기존 프론트엔드 기술보다 빠른 웹 어플리케이션을 만들 수 있음.
 2. 주간 다운로드 수 : 597,807
 3. 버전 정보 : 4.2.2 (23.10.19)
 4. github star : 73.1k
 5. 라이센스 : MIT License (https://github.com/sveltejs/svelte/blob/master/LICENSE.md)
 6. 공식 문서 링크 : https://svelte.dev/docs/introduction
 7. 패키지 페이지 링크 : https://www.npmjs.com/package/svelte
 8. 리뷰 : 👇아래 댓글에서 확인할 수 있어요 👇
    * 도움이 된 리뷰엔 좋아요도 잊지 말고 눌러주세요 👍
    * 리뷰 양식 (리뷰 작성 시 복사해서 활용하세요!)
      * -무엇을 위해 쓰(썼)는지 (용도/적용한 기능) :
        -어떤 이유 때문에 이 라이브러리를 사용했는지 :
        -만족 점수 & 이유 : /10

<ol><li>개요 : 웹 애플리케이션을 구축하는 새로운 방법. 선언적인 컴포넌트를 가져와서 효율적인 JavaScript로 변환하여 DOM을 정교하게 업데이트하는 컴파일러. 따로 프레임워크를 로딩하지 않기에 기존 프론트엔드 기술보다 빠른 웹 어플리케이션을 만들 수 있음.</li><li>주간 다운로드 수 : 597,807</li><li>버전 정보 : 4.2.2 (23.10.19)</li><li>github star : 73.1k</li><li>라이센스 : MIT License (https://github.com/sveltejs/svelte/blob/master/LICENSE.md)</li><li>공식 문서 링크 : https://svelte.dev/docs/introduction</li><li>패키지 페이지 링크 : https://www.npmjs.com/package/svelte</li><li>리뷰 : 👇아래 댓글에서 확인할 수 있어요 👇<ul><li>도움이 된 리뷰엔 좋아요도 잊지 말고 눌러주세요 👍</li><li>리뷰 양식 (리뷰 작성 시 복사해서 활용하세요!)<ul><li>-무엇을 위해 쓰(썼)는지 (용도/적용한 기능) : -어떤 이유 때문에 이 라이브러리를 사용했는지 :-만족 점수 &amp; 이유 : /10</li></ul></li></ul></li></ol>

현재는 퍼블리 팀 엔지니어 분들의 리뷰만 있는데요, 리뷰가 많이 쌓여있지 않은 초반에는 더욱 작성해주시기 어려울 것으로 생각됩니다. 초반에 리뷰를 작성한 50분에게는 소박하지만 감사의 마음을 담아 스타벅스 기프티콘을 보내드릴게요. 
리뷰만 남겨주시면 커리어리 메시지를 통해 기프티콘 절차를 따로 안내드리겠습니다 :)

[라이브러리] Svelte 상세 정보 & 리뷰

댓글 1

비슷한 게시물

주간 인기 TOP 10

추천 프로필