코딩은 가슴이 시킨다

멀티패러다임 프로그래밍 서평

coldMater — Sun, 25 May 2025 04:09:26 +0900

도서정보: 한빛미디어 | 유인동 지음 | 511p | 2025년 4월 21일 발행

2024년 여름 유인동님의 이전 저서인 함수형 자바스크립트 프로그래밍 책을 가지고 스터디를 진행했었습니다. 그 경험은 저에게 많은 영감을 주었고, 더 좋은 소스코드를 작성하기 위해 고민하게 만들었으며, 읽기 좋고 유지보수하기 용이한 코드를 작성하는 실력을 높여주었다고 생각합니다. 그렇게 1년이 지나 최근 멀티패러다임 프로그래밍 책의 발간소식을 듣게 되었습니다. 저에게 많은 영향을 주었던 저자님의 신간 발간 소식이었기에 꼭 읽어봐야겠다는 생각을 하고 있었습니다. 특히나 책의 소개 문구가 신선했습니다.

멀티패러다임 프로그래밍 - 유인동 (한빛미디어)

“객체지향, 함수형, 명령형의 통합적 사고로 구현하는 소프트웨어 설계와 구현”
- 멀티패러다임 프로그래밍

“어!? 이 3개가 합쳐지는거였다고?” 마침 서평단 모집 이벤트가 열려 응모하였고, 참 감사하게도 서평단으로 선정해주셔서 이렇게 책을 읽고 서평을 작성해봅니다.

멀티패러다임과 가치를 전하는 프로덕트

우리는 주변에서 패러다임간의 우위를 논하는 장면을 어렵지 않게 목격하게 됩니다. 가독성을 위해 명령형보다는 선언형으로 작성해야 한다거나, 특정 패러다임이 대세라든가 하는 이야기들 말이죠. 우리는 일반적으로 “하나의 메인 패러다임과 나머지 보조 패러다임들”과 같은 방식으로 프로그래밍을 바라보아 왔습니다. 굳이 함수형 체이닝 방식을 지원하는 구조를 만들어보려고 코드를 더 복잡하게 만들어버린다거나, for(명령형)문으로 마무리지어야 할때면 괜히 아쉬움이 남는다거나 하면서 저 자신도 그 관점에서 자유롭지 못했습니다. 책은 어떤 상황에 어떤 패러다임이 적절하며, 때로는 과감히 패러다임을 버려야함을 이야기해줍니다.

395p.
명령형 스타일은 상황에 따라 오히려 코드를 단순하고 명확하게 만들수 있습니다.

184p.
각 패러다임으로 작성한 코드는 서로를 완전히 대체할 수 있으며 필요하다면 섞어서 사용할 수도 있습니다. 멀티패러다임 언어를 사용하는 우리는 언제든지, 심지어 하나의 함수 안에서도 상황에 따라 가장 알맞은 패러다임을 선택하거나 조합하여 활용할 수 있습니다.

하나의 패러다임을 선택하고 모든 코드를 그 패러다임에 맞춰 ~~마치 다른 클래스는 포기하고 전직을 해야만 하는 게임 캐릭터의 운명처럼~~ 개발을 해야할 것 같은 느낌이 있었습니다. 특정 조직의 개발 문화도 우리는 함수형이다, 객체지향이다 처럼 하나의 패러다임으로 대표될 것이라고 생각하기도 했었습니다. 그러나 과감히 특정 패러다임을 포기하는 것도 하나의 선명한 옵션일 수 있음을 책은 말해주고 있습니다.

386p.
특정 부분은 함수형 패러다임이 적합하고 어떤 부분은 명령형 코드가 더 단순할 때, 두 패러다임을 과감히 섞거나 빼는 태도가 유지보수성과 확장성에 도움을 줄 수 있습니다.

만약 당신이 이미 “패러다임이 무슨 상관이야. 고객에게 가치를 전하는 제품을 만드는 게 더 중요하지.”라는 가치관을 갖고 있었다면 크게 박수를 쳐드리고 싶습니다. 그러한 가치관에 이 책이 이야기하는 멀티패러다임의 가치가 더해진다면 더욱 지속가능한 제품개발을 이어갈 수 있을 것입니다.

498p.
이러한 구조(멀티패러다임 기반 소프트웨어 개발 아키텍처)는 규모가 큰 애플리케이션에서도 유연성과 확장성을 보장하며 프로젝트가 장기화될수록 안정성, 유지보수성 그리고 추가 기능 개발에 큰 이점을 제공합니다.

변하는 것과 변하지 않는 것

제프베조스: 변화를 묻지 말고, 불변을 보라” - ChatGPT 로 생성 Excalidraw 로 수정

누군가 10년 후 어떤 변화가 있을 것이라는 기자의 질문에 10년 뒤에도 변하지 않을 것이라는 더 중요한 것에 대해서는 왜 질문하지 않느냐라고 반문했다던 아마존의 제프 베조스 회장의 일화는 유명합니다. 멀티패러다임 프로그래밍은 10년 뒤에도 변하지 않을 것에 대한 이야기입니다. 우리 개발자들은 평생 새로운 기술을 습득하고 새로운 지식을 학습해야하며 심지어 그것을 즐기는 사람들입니다. 하지만 대부분은 또 한편으로 뒤처지면 어쩌나 하는 불안감을 갖고 있는 것도 사실입니다. 이 책은 그런 불안을 어느정도 해소해주는 요소도 갖고 있었다고 생각합니다. AI 의 시대에 여전히 멀티패러다임적인 사고를 갖고 사람이 관여해야할 부분이 있다는 것을 직접 보여줍니다. 또한, 채용 시장 위에서 생산성(추후 확장성과 유지보수성을 보장한)으로 평가 받아야만 하는 피고용인의 입장에서 갖추어야할 좋은 개발자의 자질을 스스로 정의할 수 있도록 도와줍니다.

유대인의 속담에 삼겹줄은 끊어지지 않는다는 말이 있습니다. 명령형, 함수형, 객체지향의 세 패러다임을 섞는다는 그시도가 곧 삼겹줄이 되어 앞으로도 끊어지지 않을 개발자의 기본기로 만들어봐야겠다는 생각을 해보게 됩니다.

다시 기본으로

401p. 탄탄한 기본기는 결국 뛰어난 응용력을 이끌어냅니다.

책을 읽으면서 더욱 친숙해질 수 있었던 기본기에 준하는 개념들을 나열해봅니다.

Promise

저는 2018년도 여름에 본격적으로 개발을 업으로 삼기 시작했는데, 저는 비동기-논블록킹 언어인 javascript 를 async/await 을 남발하며 거의 블록킹 언어처럼 사용했던 부끄러운 과거가 있는 개발자입니다. 조금씩 비동기 방식의 프로그래밍에 익숙해지면서, 비동기 처리에 관해 새로운 관점을 제시해줬던 게 『Node.js 디자인 패턴 바이블』이라는 책이었고, 『멀티패러다임 프로그래밍』을 통해 그 관점을 확장할 수 있었습니다. javascript 개발자(node, typescript)에게는 Promise 는 기본개념이지만, 오랫동안 익숙하게 사용해왔던 Promise 에 관해서도 보완할 부분이 있다는 점을 발견할 수 있었고(예제의 코드를 보고도 동작을 제대로 예측하지 못했던 부분이 더러 있었던 점), 기본기에 대해서 더욱 제대로 공부하고, 다양한 사례에 익숙해질 필요가 있겠다는 생각을 하게 되었습니다

비동기 프로그래밍

비동기 동시성 제어에 대한 실무 경험을 해본 경험이 많이 없습니다. 비동기 요청을 한꺼번에 보내야 하는 상황의 대부분은 await Promise.all(…) 로 해결이 가능했었고, 한꺼번에 수 백개의 요청을 보낼 때 런타임 제약으로 인해 요청을 끊어 보내야 할 때도 있었지만, 단순히 요청을 임의의 개수로 나눠 각각을 await Promise.all() 하여 보냈던 기억이 납니다. 책에서는 ~~비동기 동시성 제어에 관해서는 거의 최종 보스급으로~~ 비동기 방식 기반으로 동시성 핸들링 기능을 구현하게 되는데 (6.2. 멀티패러다임을 활용한 동시성 핸들링) n 개의 비동기 작업을 한 번에 m 개씩 수행하도록 하는 일종의 동시성(부하) 제어 부분을 다룹니다. 이제 비동기 동시성 제어를 활용한 부하 처리를 위한 지식적 기반은 갖추게 되었으니 수백만개의 요청이야 만들면 되는 것이고 백엔드 개발자의 통과의례처럼 여겨지는 대용량 부하 처리 경험에 한걸음 가까워진 느낌입니다. 토비의 스프링의 저자이신 이일민님께서는 새로운 기능의 튜토리얼만 20~30번을 직접 작성하고 실행해보면서 기능의 본질을 파악하신다고 합니다. 이 책의 비동기 요청 동시성 제어 파트는 이일민님의 일화의 방식을 적용해보아야겠다는 생각이 드는 파트였고, 시간을 내어 꼭 도전해볼 계획입니다.

언어에 대한 이해

23p. 현재 우리는 어쩌면 특정 라이브러리나 프레임워크에 의존하며 그에 맞는 한정적인 패러다임을 따르다가 언어 레벨의 다양한 기능과 패러다임을 충분히 활용하지 못하고 있을지도 모릅니다.

특정 프레임워크나 라이브러리의 사용에 익숙해지다보면 대부분의 문제 상황이 이미 정형화된 패턴 위에서 손쉽게 해결되기 때문에 기본 문법에 소홀하게 되는 경향이 있는 것 같습니다. 꼭 특정 프레임워크나 라이브러리에 종속되는 부분에서 오는 문제이기 이전에, 비즈니스적 요구사항은 대체적으로 이전에 이미 작성된 누군가의 코드 패턴을 복사해오는 것으로 해결이 가능한 상황이 많았던 것도 언어의 기본에 대해 소홀하게 되는 원인으로 꼽을 수 있다고 생각합니다. 그러한 일반 개발자들에게 22년차의 경력을 가진 개발자가 책을 통해서 그동안의 경험을 밀도있게 전달해주고 있습니다. 특히 현업 관점에서 javascript, typescript 에 관해서는 언어 자체의 패러다임의 보다 깊은 이해와 함께 현직 개발자들의 코드 표현력을 높여준다고 생각합니다.

동작하는 코드 그 너머

424p. 어쩌면 우리의 이벤트가 자꾸만 루프에 빠지고 부수 효과가 발생하는 이유는 처음 작은 문제를 마주했을 때 근본적인 원인을 파악하기보다 구조가 어긋난 상태에서 단순히 if 문으로 상황을 막으려 하거나 이벤트와 상태/흐름을 관리하는 라이브러리를 무분별하게 도입하는 등의 단편적 대응을 했기 때문일지도 모릅니다.

우리는 매일 과거의 코드와 씨름합니다. 레거시, 동료의 코드, 심지어는 과거의 내가 작성한 코드도 그 싸움의 대상이 됩니다. 좋은 개발자는 유지보수(및 디버깅)하기 쉽고, 확장에 유리하며, 비즈니스적 요구사항에 신속하고 유연하게 대처할 수 있는 코드 베이스를 어떻게 구성할 수 있을지 고민합니다. 책은 그 고민에 도움이 될 만한 현실적인 해답을 책 전반에 걸쳐 제시합니다. 책의 전반에 걸쳐 좋은 개발 문화를 위해 실무에 적용해볼 수 있을 법한 내용들이 조각 조각 분포되어 있습니다. 긴 호흡으로 읽어가며 한 부분 한 부분 어떻게 현업에 적용해볼 수 있을지 고민해보는 것도 좋은 읽기 방법이 될 것이라고 생각합니다.

책의 장단점

적은 시각 자료

(추측이지만) 출판사와 저자가 책의 분량을 애써 줄이려고 한 흔적들이 있습니다. 아마도 일반 소설책 정도의 두께에 저자가 전하고자 하는 바를 최대한 놓치지 않고 담으면서도, 독자가 책의 분량이나 가격과 같은 책의 외형에 압도되지 않기를 바란 것이 아닐까 추측해봅니다.

어떻게든 제한된 분량 안에 중요한 것에 집중하며 많은 것을 전달하려는 출판의도에 대한 추측을 사실이라고 가정해본다면 모두 이해가 되는 부분이지만, 책의 물리적 분량을 줄이기 위한 노력의 일환으로 세부 내용이 축약되거나 포함되지 않은 것처럼 느껴지는 부분들이 있습니다. 책의 전반적인 흐름과 의도를 헤치는 수준은 아닙니다. 하지만 보완된다면 독자가 개념을 이해하는 데 더욱 도움이 될 만한 부분들도 있었다고 생각되는데요. 가령, 로직을 한국어 문장으로만 설명(마치 수능의 비문학 지문같은 느낌)하여 코드를 직접 떠올려보아야 했던 부분이 있었고, 규모가 큰 객체 구조에 대해서는 다이어그램을 포함해주었으면 어땠을까 하는 부분들이 있었습니다. 하지만 그러한 부분일지라도 곱씹으면서 또는 직접 손으로 그려보면서, 그리고 무엇보다 예제코드에 대해서는 책을 200%로 활용하기 부분에서처럼 직접 코딩해보면서 구조를 그려본다면 연결과 이해가 더욱 와닿게 될 것이라고 생각합니다.

대상 독자

또한 책에서는 “언어의 기본문법을 이해”하고 있으면 어렵지 않게 읽을 수 있음을 이야기하고 있습니다. 반면, 한빛미디어의 도서 소개페이지에서는 책의 난이도가 “중고급”으로 표현되어 있는데요. ‘중고급’이라는 표현이 보다 추상적이기는 해도 오히려 책의 난이도를 더 적절히 표현한 것 같아보입니다. 만약 책을 읽어야 할 지 말아야 할 지 고민하는 입문자가 있다면 저는 다음과 같이 조언해줄 것 같습니다. 굳이 읽어야겠다면, 사례를 중심으로 무엇을 할 수 있게 되는지 가볍게 읽고 이해가 당장 되지 않더라도 어느정도 수준이 있는 내용이니까 너무 압도되지는 말라고요.

예제의 높은 실무 연관성

책의 초반부(이론)에서는 각 패러다임의 이론적 토대를 설명하기 위해 [1,2,3] 과 같은 예시용 데이터들을 활용한 예제들이 주를 이룹니다. 하지만 후반부(응용)로 갈수록 예제가 실무에서 있을법한 예제를 많이 보여주는데요. 아예 실무에의 적극적인 활용을 가정하고 가능하면 실무에 바로 쓰일 수 있는 코드로 예제를 구성한 저자의 노력이 돋보입니다.

개인적으로 기술(기법)을 이해할 때 단순히 어떻게(how)만이해하는 것을 넘어서 무엇(what)과 왜(why)라는 맥락적인 부분과 함께 학습하면 실제 응용 상황 발생시 해당 기술(기법)을 떠올리는 데 큰 도움이 된다고 생각하는데요. 책의 응용부에서 예제는 모두 실무 연관성이 높은 예제로 구성되어 있으며, 실제로 비슷한 요구사항이 발생했을 때 해당 예제를 그대로 적용해도 될만큼 높은 완성도를 갖추고 있습니다.

마치며

책을 모두 읽고 나니, 함수형 프로그래밍은 로직의 흐름 곧 시간에 관한 이야기이며, 객체지향 패러다임은 구조 즉 공간에 관한 이야기인 것 같다는 생각, 그리고 명령형 프로그래밍은 이들을 엮는 물리법칙에 비유할 수 있지 않을까라는 생각을 해보게 되었습니다.

Generated By Gemini - Multiparadigm Metaphor Spacetime

시간과 공간의 개념을 하나의 개념으로 통합했던 아인슈타인이 상대성이론이라는 위대한 업적과 함께 인류를 한 층 더 미래에 가깝게 이끌었던 것처럼, 소프트웨어 업계에 멀티패러다임이라는 방식이 다가올 미래를 더욱 앞당기게 되는 모습을 상상해봅니다. 그렇게 보다 빠르게 만나게 될 미래를 기대해보게 됩니다.

2026년 버전 gemini 작품:

가면서 읽고, 기다리며 읽고, 오면서 읽고, 플래그는 나중에 정리가 필요한 부분 (이해가 잘 안되거나, 새로운 개념이거나, 공유하고싶거나)

멀티패러다임이라는 개념을 5년 전에 알고 있었다면 얼마나 더 많은 코드에 멀티패러다임을 적용해볼 수 있었을텐데라는 아쉬움이 생길 정도로, 지금이라도 멀티패러다임을 알게 되어 다행이라는 생각이 듭니다. 완독 후 지금 이 순간 제게는 멀티패러다임의 아우라가 가득합니다. ~~(망치가 생겼습니다. 그 순간 모든 것이 못으로...)~~ 미래를 앞당기는 그 여정에 함께할 기회가 주어진것만 같은 느낌과 함께 미래에 저는 어떤 개발자로 성장해있을지 그려보게 됩니다.

한빛미디어의 도서 지원을 받아 작성한 리뷰입니다.

[협업도구] 무설치 그림판 Excalidraw ️

coldMater — Wed, 27 Nov 2024 01:35:16 +0900

이번 글에서는 제가 간단한 그림을 그릴 때 유용하게 사용하고 있는 Excalidraw 를 소개해보려고 합니다. 이름에 걸맞게 군더더기는 빼고 정말 필요한 기능들을 주옥같이 모아놓은 툴입니다.

Excalidraw | Online whiteboard collaboration made easy

Excalidraw is a free virtual collaborative whiteboard for creating simple hand-drawn style diagrams, illustrations, flowcharts.. No sign-up. Just draw

plus.excalidraw.com

Excalidraw 의 주요 장점

웹브라우저에서 바로 접속하여 그리기를 시작
LowFi 를 지향하지만, 충분한 퀄리티의 결과물을 제공
다이어그램을 그리는 데 유용한 기능들을 제공 (화살표, 자석 기능 등)
그림파일(PNG)로 바로 복사 또는 저장 가능
단축키 제공
파워포인트 못지 않은 직관적이고 유연한 객체 선택 방식
기타 이미지 툴에 버금가는 기본 기능 제공

Excalidraw 은...

미니멀리즘

언제 어디서나 웹브라우저에서 바로 접근이 가능한 그림판(~~이라기엔 너무 작고 강력한 다이어그램 툴~~)입니다. Excalidraw 를 활용하면 주요 도형들을 손쉽게 나열하여 원하는 그림을 그릴 수 있는데, 신경쓰지 않아도 낮지만 괜찮은 퀄리티의 그림을 만들어줍니다.

그리드모드

그리드모드를 켜서(ctrl + ' 또는 캔버스에서 오른쪽버튼) 불필요한 픽셀 단위의 조정을 피할 수 있습니다.

grid 모드를 켜면 불필요한 픽셀 단위의 조정을 하지 않아도 된다.

극강의 UX

특히 다이어그램을 손으로 그려야 할 때 유용한 (자석 기능 등) 기능들이 있으며, 대상을 선택하고, 이동, 회전, 삭제하는 등의 기능들도 직관적이며 매끄럽게 작동합니다. 수많은 단축키들을 지원하여 익숙해진다면 머릿속에 있는 그림을 판서하는 것보다 빠르게 그릴 수 있게 됩니다. 웹페이지임에도 오른쪽 버튼 메뉴를 지원하여 일반 이미지 편집기에서 사용하는 기능(그룹, 레이어;뒤/앞으로 보내기)들을 사용할 수 있습니다.

Snap to Objects 모드

snap to objects (alt + s) 모드를 켜서 객체간의 관계를 가이드선으로 표현해줄 수 있습니다.

snap to objects 모드가 켜져 있는 모습

자석(?) 기능

(제가 이걸 Excalidraw 가 정확히 뭐라고 부르는지는 모르겠지만) 화살표 등을 객체에 붙여주면, 객체가 이동할 때 화살표도 따라 이동합니다.

Excalidraw 의 자석 기능

그림 추출

아무래도 이미지 편집기의 가장 중요한 기능일 것입니다. Excalidraw 는 SVG 와 PNG 타입을 지원하며, 선택한 대상을 클립보드에 복사하기, 또는 파일로 내려받기가 가능합니다.

캔버스 전부가 아니라 선택한 이미지만 따로 내보내기가 가능하다.

유료 기능

아카이브

저장소(아카이브) 기능을 활용하려면 유료로 사용하여야 하기는 하지만, 저는 개인적으로 필요할 때 그리고, 그림으로 복사하는 정도로 활용하고 있습니다.

꿀팁

PNG 로 복사 단축키

Excalidraw 에서 PNG 로 복사 단축키는 shift + alt(option) + c 입니다.

Excalidraw PNG 로 복사하기 단축키: shift + alt + c

정리

단순한 아이디어 정리 용도의 스케치 프로그램이 필요하다면 Excalidraw 를 사용해보세요! 또 별도로 알고 계신 꿀팁이 있으시다면 댓글로 알려주시면 감사하겠습니다.

맥북 키 반복 입력 속도 향상법

coldMater — Tue, 26 Nov 2024 21:47:31 +0900

맥북을 사용할 때 키보드를 누르고 있으면 입력이 반복되어 일어납니다. 가령, 방향키를 꾹 눌러 커서를 이동한다든가 할 때 이 기능을 사용하게 됩니다. 기본적인 키 반복 입력 속도는 굉장히 느린데요. 이 속도를 빠르게 하는 방법을 알아봅니다.

어머! 이건 꼭 켜야 해 !

맥북 키 반복 입력 속도 향상법

맥북 설정(setting)을 열어줍니다.
키보드(keybard) 항목으로 이동합니다.
Key repeat rate 를 Fast 쪽으로 이동시켜줍니다.

key repeat rate

맥OS 설정의 키보드, 키 입력 반복(key repeat rate)

delay until repeat

Key repeat rate 오른쪽으로 보면 Delay until repeat 이라는 부분이 있습니다. 이는, 키가 눌러지고 있을 때 키가 눌리기 시작한 시점으로부터 얼마 뒤에 반복을 시작할지 설정하는 부분입니다. 저는 이것도 최대한 빠르게 설정하여 사용하고 있습니다.

Delay until repeat 키 입력 반복이 시작되기까지 기다릴 간격의 길이 설정

모식도로 보기

key repeat rate 와 delay until repeat 를 모식도로 나타내면 아래와 같습니다.

맥OS 설정의 key repeat rate 와 delay until repeat 을 모식도로 나타내봄

체감하기

키보드의 방향키를 꾸욱 눌러 어떤 차이가 있는지 체감해보실 수 있도록 동영상을 준비했습니다.

맥북 기본 설정

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

키 반복 입력 속도 최대

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

정리

현기증 난단 말이에요. 빨리 키보드 입력 빠르게 해주세요.

크롬 영어 사전 세팅 (ft. 크롬 검색엔진 설정)

coldMater — Mon, 25 Nov 2024 22:02:14 +0900

크롬 브라우저에서 영어 사전을 활용할 수 있는 다양한 방법이 있습니다. 대표적으로는 익스텐션을 이용하는 방법입니다. 하지만, 익스텐션의 다양한 기능에도 불구하고 영어 사전 서비스 자체를 이용하고 싶을 수 있습니다. 저 같은 경우, 예문을 함께 보고 싶다거나, (예문을 제공하는 익스텐션이 있다고 하더라도) 큰 화면으로 여러 의미를 함께 보고 싶은 경우가 그런 경우입니다. 특히 저는 각 서비스에서 제공하는 '단어장'기능이 필요했었는데, 모르는 단어를 신속하게 단어장에 추가할 수 있어 매우 유용합니다. 크롬이 제공하는 '검색엔진 설정' 기능으로 간단한 세팅을 마치고 나면 다양한 영어사전 서비스를 손쉽고 빠르게 이용할 수 있습니다. 오늘은 그 꿀팁을 공유해보고자 합니다.

대상 영어 사전 서비스 선정

저는 다음영어사전을 선택하여 포스팅을 진행해보려고 합니다. 영어사전을 선택할 때, 주소창에 검색한 단어나 표현이 나타나는지 확인해야 합니다.

url에 물음표 뒤에 나타나는 문자열을 '쿼리스트링'이라고 하고, 이 부분을 '쿼리'라고 부릅니다.

?query=dictionary 와 같이 쿼리스트링에 검색한 키워드가 들어가는 검색 서비스를 선택해야 한다.

국내 대표적인 영어사전 사이트인 '다음사전', '네이버사전'은 모두 쿼리스트링 형태의 사전검색을 지원합니다.

꼭 쿼리 부분에 키워드가 들어가지 않고, 콜린스 사전의 경우 url path 부분의 마지막에 입력한 키워드가 들어가기도 합니다.

telescope 부분이 입력한 키워드에 해당하는 부분이다.

이렇게 url 에 키워드가 들어가는 영어사전 서비스를 찾았다면 1단계는 통과입니다.

크롬 검색엔진에 사이트 등록

url 에 키워드가 들어가는 서비스를 찾았다면, 주소창의 url 을 복사해줍니다. 크롬 기준으로 ctrl + l 을 누르면 주소창으로 커서가 이동하면서 블록이 씌워집니다. 이 주소를 복사해줍니다.

크롬 검색엔진 설정

그리고 크롬 오른쪽 상단의 점 세개 버튼을 클릭합니다.

크롬 설정(우측 상단 점 세개 버튼)에서 '검색엔진', '검색엔진 및 사이트 검색 관리'를 차례로 눌러줍니다.

'사이트 검색' 에 해당하는 부분에서 '추가' 버튼을 클릭합니다.

'검색엔진 및 사이트 검색 관리'를 클릭하면 등장하는 섹션

마지막으로 아래 스크린샷과 같이 이름(1), 바로가기 단축키(2), URL 에 위에서 복사했던 주소(url)을 붙여 넣어줍니다.

주소를 붙여넣어줄 때, 키워드에 해당하는 부분은 `%s`로 변경해줍니다.

복사한 주소를 붙여넣고 키워드에 해당하는 부분을 %s 로 변경한다.

바로가기는 단축키입니다. 편하게 쓸 단축키를 지정해줍니다. (주소창에서 해당 키를 넣고 스페이스를 입력하면, 해당 검색엔진 모드로 변경됩니다.)

다음 영어사전을 기준으로 검색한 키워드는 쿼리스트링의 `q=` 다음에 오는 문자열입니다. 아래 스크린샷과 같이 키워드 부분을 `%s`로 변경해줍니다. (&전까지만 변경해주세요. 뒤의 dic=eng 는 '영어사전'을 뜻합니다.)

url 의 쿼리스트링 부분에서 키워드에 해당하는 부분을 `%s` 로 변경해준다.

단축키 조합으로 영어사전 검색

위에서 모든 세팅을 마쳤다면 아래와 같이 순서대로 입력합니다.

ctrl + l 로 주소창으로 이동
바로가기 단축키 입력 (저의 경우에는 `dd`)
검색할 키워드 입력
- ctrl+enter 를 누르면 새 탭에서 결과가 열립니다.
- shift+enter 를 누르면 새 창에서 결과가 열립니다.
결과 확인

원서를 읽다가 모르는 단어를 발견하고 이를 크롬 검색엔진에 등록해둔 다음 영어사전으로 검색해보는 모습

응용

사실 url 에 내가 입력한 키워드가 영향을 줄 수 있는 모든 구조에 적용이 가능합니다. 특히, 입력했던 키워드는 자동완성이 되기 때문에, 자주 찾는 페이지에도 적용해두면 편리합니다. 이 포스팅에서는 '영어 사전' 기능에 집중하여 설명했지만, url 로 검색 기능을 지원하는 모든 서비스에서 응용기 가능합니다.

github 대상 repository로 바로 이동: https://github.com/coldMater/%s
도서 검색 (yes24 등): https://www.yes24.com/Product/Search?domain=ALL&query=%s
coldmater 블로그 내 검색: https://coldmater.tistory.com/search/%s
사내 위키 검색 키워드 연동
Jira 이슈키 검색 연동 (또는 키워드 검색 연동)

자주 이용하는 서비스가 있다면 url 을 유심히 봐보세요. 더 좋은 꿀팁을 발견할 수 있을지도 모릅니다. 좋은 꿀팁이 생기신다면 댓글로 공유해주세요!

정리

영어사전을 크롬 검색엔진 설정을 활용하여 설정하는 방법을 알아보았습니다. 포스팅 가운데 gif 처럼 익숙해지면 모르는 단어가 생길 때마다 바로 바로 대상 단어를 검색해볼 수 있습니다. 특히 다음 영어사전 또는 네이버 영어사전을 활용하면 '단어장' 기능을 활용하여 검색해본 단어를 별도로 모아볼 수 있게 저장할 수도 있습니다. 그리고 이를 응용하면 다양한 검색 서비스를 유용하게 사용할 수도 있습니다.

스크럼 스토리포인트의 대안

coldMater — Sun, 24 Nov 2024 03:10:09 +0900

스크럼은 애자일의 가치를 실현시키기 위한 프레임워크입니다. 이 때, 작업자들이 수행해야 하는 티켓의 규모 또는 복잡도를 나타내기 위해 '스토리포인트'라는 개념을 사용하게 되는데요. 오늘은 이 스토리포인트의 개념에 대해서 짚어보고, 이 개념이 실무에서 쓰기에 부적절한 이유를 물리량의 관점에서 설명드린 뒤, 스토리포인트의 대안을 제시해보려고 합니다.

스토리포인트와 추정

스토리 포인트는 제품 백로그 항목 또는 기타 작업을 완전히 구현하는 데 필요한 전반적인 노력의 추정치를 표현하기 위한 측정 단위입니다. 팀은 작업 복잡성, 작업량, 위험 또는 불확실성과 관련하여 스토리 포인트를 할당합니다.

https://www.atlassian.com/ko/agile/project-management/estimation

아틀라시안의 포스팅에서 스토리포인트를 '전반적인 노력의 추정치'로서 정의합니다. 이 스토리포인트는 '플래닝포커'라는 행위를 통해서 측정됩니다. (플래닝포커를 진행하는 방식에 대해서는 이 글에서는 자세히 설명하지 않습니다.) 이렇게 측정된 스토리포인트가 갖게 되는 의미는 다음과 같습니다.

경험주의

먼저, 팀이 결성된 초기에는 스토리포인트가 제대로 측정되지 않을 수 있습니다. 스크럼 가이드에서는 '경험주의'를 강조하는데, 스크럼이란 어떤 정해진 프레임워크라기보다는, 팀에 의해 개선될 수 있고, 커스텀하게 운영되어야 한다는 것입니다. 마찬가지로, 플래닝포커를 거듭할수록 구성원 간에 서로를 더 이해하게 되고, 프로덕트를 이해하게 되면서 합이 맞아지게 된다는 기대를 그 근거로 하고 있습니다.

더 나은 스토리포인트 추정이 되어가는 과정

특정 작업의 스토리포인트가 할당이 되고, 그 스토리포인트가 적절했는지에 대해서 회고에서 이야기합니다. 어떤 이유로 스토리포인트가 더 높았어야 했는지, 또는 더 낮았어야 했는지를 서로 평가하고 피드백합니다. 이러한 행위는 추후 플래닝포커에 근거가 되어 더 나은 스토리포인트를 '추정'할 수 있도록 도움을 줄 수 있어야 합니다.

거대한 스토리포인트

스토리포인트가 크게 잡혔다는 것은, 그 작업이 더 세분화되어야 한다는 의미이기도 합니다. 따라서, 플래닝포커 중에 스토리포인트가 높게 책정된 작업이 있다면, 그 작업을 세분화하여 작업을 구체화합니다. 곧, 스토리포인트가 크다는 것은 해당 작업의 정의가 모호하다는 것을 의미하기도 합니다.

벨로시티

이렇게 측정된 스토리포인트는 팀의 벨로시티(velocity)를 측정하는 데 사용되게 됩니다. 팀이 지난 3개의 스프린트동안 처리한 스토리포인트가 각각, 26sp, 21sp, 32sp 였다면 지난 3개의 스프린트동안 처리한 스토리포인트의 평균은 약 26.3 이므로, 다음 스프린트에서 이 팀이 해결하길 기대하는 스토리포인트는 26.3 입니다. 즉, 하나의 스프린트 동안 팀이 처리할 수 있는 스토리포인트의 기댓값이 '벨로시티'입니다. (단위: story points/sprint)

벨로시티로 프로젝트 완료 시기 추정

회사에서 하나의 큰 프로젝트를 팀에 맡겼고, 이 프로젝트를 기능 단위로 구분해서 나눠보았더니 약 30개정도의 작업(티켓)으로 분리되어 명세할 수 있었다고 가정합시다. 30개의 작업 각각에 대해서 플래닝포커를 진행했고, 계산된 스토리포인트의 총 합은 80sp 가 되었습니다. 그렇다면, 이 팀이 이 프로젝트에 몰두하였을 때, 프로젝트 완성까지 기대되는 소요 스프린트는 80sp / 26.3sp/sprint 으로 계산하여 3.04sprint 가 나오게 됩니다. 약 3번의 스프린트를 거치면 해당 프로젝트가 완성될 수 있다고 기대할 수 있는 것입니다.

스토리포인트의 결함

물리량으로서의 스토리포인트

학창시절 수학이나 과학 시험을 볼 때, 가령 계산 결과로 '길이'를 써야 한다면, '27cm'와 같이 그 단위를 꼭 써주어야만 정답처리가 되고, '27'으로만 쓰면 오답처리가 되는 기억이 납니다. 스토리포인트는 '단위'를 정할 수 없기 때문에 추정으로서는 어색한 개념입니다.

위 아틀라시안 포스팅을 참고하더라도 스토리포인트를 구성하는 요소는 복잡성, 작업량, 위험 또는 불확실성 이 복합적으로 작용하여 결정됩니다. 여기에서 나열된 개념만 4가지인데, 이 4가지의 각각 정의되기도 힘들뿐더러, 정의된다고 하더라도 서로 단위가 다를 것이기에 이걸 합산하여 표현하기에는 무리가 있습니다. 이러한 개념을 팀 단위에서 '경험주의'라는 이름 아래, 플래닝포커를 통해 집단지성을 이용한 어떤 연결고리를 만들어내어 팀 내에서 통용되는 관습적 의미의 '스토리포인트'를 완성시킬 수는 있지만, 문제는 이 스토리포인트가 결국 '벨로시티'와 연결된다는 것입니다.

작업량 추정을 시간과 떼어내기

스토리포인트가 제안된 배경에는, 시간 기반의 추정이 작업자들을 시간에 쫓기게 만들거나, 압박감을 주어 프로덕트 개발에 방해가 된다는 가정이 담겨 있습니다. 그래서 스토리포인트는 숫자가 아닌 티셔츠 사이즈로 측정하기도 하고 피보나치 수열로 한정하기도 하는 것입니다. 어차피 틀릴 추정을 정확히 하려고 애쓰지 말자는 의도도 담겨 있습니다. 여기서 추구하려고 하는 본질이 무엇이었는지는 개인적으로도 굉장히 공감이 되는 부분입니다. 하지만 결국 이 스토리포인트들은 평균이 내어져 벨로시티의 재료가 됩니다.

고전적인 물리 개념인 '거리', '시간', '속도'의 개념을 보면, 거리라는 개념 자체는 시간과 관계 없는 개념이지만 '속도'를 정의하면서 연관되어지게 됩니다. 결국 '속도'를 정의하면서부터 '거리'와 '시간'의 개념의 관계가 형성됩니다. 이는 스토리포인트와 벨로시티의 관계에 대해서도 동일하게 적용된다고 볼 수 있습니다.

스토리포인트의 대안

론 제프리즈의 사과

론 제프리즈(Ron Jeffries)는 스토리포인트의 창시자라고 여겨지는 인물입니다. 2019년 5월에 글을 하나 올리게 되는데, '스토리포인트 발명에 대한 사과'라고 이름 붙일 수 있을 것입니다.

I like to say that I may have invented story points, and if I did, I’m sorry now. Let’s explore my current thinking on story points. At least one of us is interested in what I think.

https://ronjeffries.com/articles/019-01ff/story-points/Index.html

스토리포인트의 개념이 어떻게 업계에서 왜곡되어 사용되고 있는지, 그리고 현재 자신이 생각하는 스토리포인트의 대안에 대해 설명합니다. 이 글이 스토리포인트의 발명에 대한 사과처럼 보이지만, 실은 그렇다기보다, 제품 개발에 있어서의 본질이 무엇인지 다시금 생각해보게 해주는 글이라 꼭 따로 읽어보시기를 권해봅니다.

위 인용문의 본문의 내용을 정리하면 다음과 같습니다.

비교: 불행하게도 추정치로 팀을 비교하는 잘못은 흔하게 일어남 (본능임)
추적: 추정을 정확하게 하기보다 가치를 빠르게 전달하는 것이 중요
압박: 많이 하는 것보다 가치 있는 일을 하는 것이 중요
예측완료: 마감일을 정해 한꺼번에 작업을 전달하기보다, 가까운 날짜를 정해 가장 좋아보이는 기능을 제공하는 것이 중요
분할: 스토리포인트 추정의 대안 - 하루보다 적게 걸리는 작업으로 분할하기
미래예측: 그럼에도 추정이 필요하지 않아요? 라는 질문에 대한 가이드(는 위 인용문 링크 참조)

스토리를 작게 나누기

위 론 제프리즈의 글에서는 스토리를 나누라고 제안합니다. 가능하면 작은 노력을 들이면서도 높은 가치를 전달할 수 있는 작업으로요. 작업 시간도 제안합니다. 하루보다 적게 걸리거나 수시간동안 작업할 수 있는 분량으로요.

작업이 실제로 얼마나 걸릴지 정확히 그 누구도 알 수 없습니다.

“when will all this be done?” The answer is that no one knows.

3개월이 걸릴 것 같은 작업에 대한 추정이 3일이 걸릴 것 같은 추정보다 오차가 더 크게 날 것입니다. 따라서, 작업이 세분화 될수록, 오히려 추정하기 쉬워집니다.

추정은 본래 미래 예측의 속성을 갖기에 정밀하기 어려운 행위이지만, 작게 만들 수록 그 오차를 줄일 수 있습니다. 즉, 스토리를 작게 만들수록 프로젝트(또는 릴리즈)의 예측가능성을 높일 수 있습니다.

Productivity VS Activity

스토리포인트라는 주제 자체가 어떻게 하면 '추정을 제대로 해볼 수 있을까'라는 질문에서 찾게 된 개념이라면, 그 질문의 방향을 바꿔야 함을 론 제프리즈는 이야기합니다. 추정보다 중요한 것은 가치의 전달이라고요. one thing 의 저자는 한 인터뷰에서 생산성(Productivity)과 Activity(활동)을 구분지어 이야기합니다. 진정한 생산성은 정해진 시간에 정해진 일을 최대한 많이 해내는 것이 아니라, 가치 있는 일을 해내는 것이 생산성이라고 언급합니다.

정리

스토리포인트의 개념과 활용되는 방식에 대해 알아보는 것을 시작으로 스토리포인트의 결함이 무엇인지 물리량의 예를 근거로 설명해보았습니다. 이어서 스토리포인트의 창시자가 스토리포인트의 대안으로 제시하는 여러 개념들을 살펴보았습니다. 중요한 것은 '정확한 추정'보다 '가치를 더하는 것'임을 알 수 있었는데요. 그렇더라도, 추정을 해야 한다면 스토리를 더 잘게 쪼개 하루보다 적은 수시간 단위의 일로 나누는 것이 타당하다는 제안 또한 알아보았습니다. 개인적으로도 내가 해야겠다라고 생각한 모든 일들을 해내기 위해 어떻게 하면 생산성을 높일 수 있을까? 를 고민해왔었는데요. 점점 모든 일을 다 해낼 수는 없음을 깨달아가는 요즘입니다. 어떻게 하면 더 가치 있는 일을 할 수 있을까? 그렇다면 내가 집중하지 않아야 되는 일은 무엇인가, 버려야 하는 열망은 무엇인가에 대해서도 질문해보게 되는 순간이었습니다. 이 글이 여러분들께서 더 가치 있는 일에 집중하게 되는 계기가 되길 바라면서 이만 글을 마칩니다.

To me, the important thing in Real Agile is to pick the next few things to do, and do them promptly. The key question is to find the most valuable things to do, and to do them quickly. - Ron Jeffries

큰 수에 대한 감각

coldMater — Sat, 23 Nov 2024 23:47:51 +0900

뉴스나 어떤 통계자료를 보다 보면 아주 큰 단위의 수가 등장하여 막연하게 느껴지는 경우가 있습니다. 오늘은 대한민국에서 수를 세는 단위와 미국에서 수를 세는 단위를 비교해보고 각각을 비교하기에 용이한 팁을 공유해볼까 합니다.

아라비아 숫자를 사용한 수를 표현하는 방법에서는 진법을 활용합니다. 진법에서 '진'이라는 글자는 '나아갈 진'을 사용합니다. 수를 표현하기 위해 숫자를 사용하는데, 숫자는 0부터 9까지를 사용할 수 있으므로 9를 넘어서는 숫자를 표기하기 위하여 새로운 숫자를 만들기보다, '진법'을 활용하여 수를 표현합니다. 자릿수를 확장하여 나아간다는 의미에서 이 방식을 '진법'이라고 부릅니다. 9에서 1이 더해진 숫자를 '십'이라고 하는데, 아라비아 수로는 9 다음 수를 표현할 숫자가 없으므로, 진법을 활용해서 '십의 자리'라고 부르는 곳으로 수를 나아가고, '일의 자리'는 0으로 리셋합니다. 그렇게 10이 됩니다.

문화권마다 10단위로 수가 증가할 때마다 그 수에 이름을 붙입니다. 한 번 나아간 수인 10은 '십', 두 번 나아간 수인 100 은 '백', 세 번 나아간 수인 1000은 '천', 네 번 나아간 수인 10000은 '만' 입니다. 그렇다면 다섯 번 나아간 수인 100000 은 뭐라고 부를까요? 이 수엔 붙여진 이름이 없습니다. 이 때 '진법'을 활용하여 만이 10개 모인 수이므로 '십만'이라고 표현합니다. 마찬가지로 영어 문화권에서는 보통 10은 'ten', 100은 'hundred', 1000은 'thousand' 라고 합니다. 그렇다면 한 번 더 나아간 10000 은 뭐라고 부를까요? '만'에 해당하는 일반 명사는 없습니다. 여기서도 '진법'을 활용합니다. 영어에서 10000은 thousand 가 10번 모였으므로 'ten thousand' 라고 표현합니다.

한자문화권에서는 숫자가 4번 나아갈 때마다 이름을 붙였습니다.

1_0000: 만
1_0000_0000: 억
1_0000_0000_0000: 조
1_0000_0000_0000_0000: 경

우리가 흔히 큰 수를 셀 때 맨 오른쪽 0부터 '일, 십, 백, 천, 만, 십만, 백만, ...' 세어 나가는 경우가 흔한데, 4자리로 끊어서 세어가면 훨씬 빨리 수를 파악할 수 있습니다.

2023년 대한민국의 1년 예산은 638조 7276억원이다.

영어문화권에서는 숫자가 3번 나아갈 때마다 이름을 붙였습니다. 큰 수를 나타낼 때 컴마를 0이 3번 반복될 때마다 찍게 되는 것은 이 이유때문입니다.

1_000: thousand
1_000_000: million
1_000_000_000: billion
1_000_000_000_000: trillion

수에 이름이 붙여지는 원리를 가지고 원화와 달러 사이의 관계를 생각해봅시다. 보통 1달러에 000을 붙여서 원화로 만든 뒤 환율을 적용하여 계산하는 셈법을 많이 사용합니다.

1달러를 원화로 만들 때
000을 붙여서 1000원을 만들고 [개략적 단위환산]
1000원에 환율을 적용 -> 1400원

1달러 에서 '달러' 대신 '000원'을 붙이면 2.단계까지 진행한 것이 되기 때문에 흔히 쓰이는 방법입니다.

100달러 는 그렇다면 얼마일까요? 달러 대신 000원 을 붙이면 되니까, 100000원 입니다. 10만원이네요. (환율을 적용하면 14만원) 1000달러는 그렇다면 얼마일까요? 100만원입니다. (환율 적용시 140만원) 이 단위는 투자의 세계에서는 의미 있는 가격이기도 합니다. 비트코인의 가격을 이야기 할 때 1k라는 단위를 쓰기도 하는데, k 는 1000을 의미하는 수(kilo)로써 1k달러 는 한화로 100만원에 대응되며, 환율을 적용하면 약 140만원 정도가 됩니다.

백만장자(millionaire)는 표현이 있습니다. 백만은 0이 여섯 개 있는 수이고, 1_000_000입니다. 백만장자가 백만달러를 가지고 있는 사람이라고 생각해보면, 이 사람은 한화로 얼마 정도를 갖고 있게 되는 것일까요? 0을 3개 붙여주면 10_0000_0000 이니까 10억입니다. 환율을 적용하면 약 14억이겠네요.

가령 10억달러라고 했을 때 한화로는 얼마정도로 환산이 될까요? 먼저 10억달러는 0이 몇개일까요? 억은 0이 8개이므로 10억은 0이 9개이고, '달러'를 '000원'으로 치환하면 0이 12개가 됩니다. 0이 12개인 수의 이름은 '조'이므로, 10억달러는 1조원에 대응되며, 환율을 적용하면 약 1.4조원(1조 4000억)이 되겠네요.

위 두 가지 환산에서 어떤 규칙을 발견할 수 있습니다.

100만달러 -> 10억원
10억달러 -> 1조원

환율을 적용하기 전에 개략적인 단위수만 맞추는 과정만 놓고 보면, 단위 앞 수는 자릿수가 하나 줄었고, '만달러'는 '억원'이 되면서 '만'이 '억' 이 되고, '억달러'는 '조원'이 되면서 '억'이 '조'가 되었습니다. 즉, '숫자 자릿수를 하나 줄이고, 큰 단위를 하나 올리면 개략적인 원화가 됩니다. 이게 가능한 이유는 (율 적용전) 1달러가 1000원에 대응되기 때문인데, 이 1000원은 다음 큰 수의 이름(만, 조, 억 등)이 되기 위해 필요한 0이 하나 부족합니다. 그래서 이걸 앞에 있는 수에서 빌려다 쓰면 다음 큰 수의 이름이 되면서, 앞의 수의 0은 하나 줄이는 것이죠.

달러 단위 원화로 쉽게 바꾸기

만약 1억달러 처럼 빌려올 자리가 없는 경우에는 천단위로 내려주면 됩니다. 1000경원입니다. 단순히 0을 3번 붙여 생각해도 되지만, 이런 방식으로도 환산이 가능하다는 것을 인지해두는 것도 나쁘지 않을 것입니다.

10억달러인 1B달러 는 우리나라의 1조원과 대응한다는 사실은 다음과 같이도 설명할 수 있습니다. 1B 은 0이 9개입니다. 그리고 달러는 '000원'으로 대응될 수 있으므로 1B달러는 원화로 변경했을 때 0을 총 12개 가지게 됩니다. 12개는 4가 3번 반복되는 것이므로, '조'에 대응되기 때문입니다. 따라서 외국 뉴스나 통계에서 6B달러와 같은 표현이 나온다면, 이는 'B달러' 를 그대로'조원'으로 계산한 뒤 환율을 적용하여 감을 잡으면 됩니다.

뉴스나 통계에서 '$...B' 단위가 나왔을 때 대충이라도 원화로 감 잡는 방법

달러 단위가 아닌 경우에도, 영어문화권에서는 0이 3개마다 이름이 붙여지고, 한자문화권에서는 0이 4개마다 이름이 붙여진다는 사실을 통해서 million, billion, trillion 은 각각 백만, 10억, 1조 입니다. 마찬가지로 앞 숫자는 백, 10, 1로 줄어들었고, 큰 수의 단위는 만, 억, 조로 증가합니다.

새삼 SI 단위계가 꿈꾼 세계가 어떤 세계인지 공감을 하게 되면서 포스팅을 마칩니다.

npm semver 에서 caret(^) 의 의미와 활용

coldMater — Fri, 22 Nov 2024 23:53:22 +0900

npm 패키지를 사용할 때 무심코 npm i [패키지명] 를 하게 되면 package.json 버전에는 caret(^)이 붙게 됩니다. 이 caret 의 의미를 알아봅니다. 그리고 이를 패키지를 사용하는 입장에서와 패키지를 관리하는 입장에서의 활용법도 알아봅니다.

npm 패키지 caret의 의미

node-semver 라는 이름으로 관리되는 패키지에서 karot(^) 버저닝의 의미를 정하고 있습니다.

https://github.com/npm/node-semver

GitHub - npm/node-semver: The semver parser for node (the one npm uses)

The semver parser for node (the one npm uses). Contribute to npm/node-semver development by creating an account on GitHub.

github.com

Allows changes that do not modify the left-most non-zero element in the [major, minor, patch] tuple. In other words, this allows patch and minor updates for versions 1.0.0 and above, patch updates for versions 0.X >=0.1.0, and no updates for versions 0.0.X.

버전 왼쪽에 붙어있는 caret(^)은 '가장 왼쪽의 0이 아닌 요소가 바뀌지 않는 변경만을 허용'한다는 표시입니다. 이를 좀 더 풀어서 알아봅니다.

일러두기: semver 의 요소

semver 는 . 을 기준으로 3가지로 구분됩니다. [major, minor, patch] 튜플로 구성된다고 인용문은 설명하고 있습니다. semver 에서 각 요소는 major, minor, patch 중 하나를 의미합니다. 1.2.3 의 버전이라면 major 요소는 1, minor 요소는 2, patch 요소는 3입니다. semver 에 대해 자세히 알아보고 싶다면 다음 글을 참고해주세요.

가장 쉬운 유의적 버전 semver

현대의 프로그램은 많고 복잡한 의존 관계를 가지고 있습니다. 만약 의존하고 있던 프로그램의 버전이 업데이트 되면서 문제가 생기면 대응을 해야하는데, 의존하는 라이브러리가 수십개에다

coldmater.tistory.com

가장왼쪽의 0이 아닌 요소

가령 ^0.1.3 라면 가장 왼쪽의 0이 아닌 요소는 minor 에 해당하는 1입니다.

만약 ^3.5.7 라면 가장 왼쪽의 0이 아닌 요소는 major 에 해당하는 3입니다.

수정을 하지 않는 변경 허용

semver 에서 caret(^) 지시자는 가장 왼쪽의 0이 아닌 요소가 바뀌지 않는 변경만을 허용합니다.

package.json 에 "lib-a": "^0.1.3" 으로 버전이 지정된 경우

가장 왼쪽의 0 이 아닌 요소가 minor 버전인 1 이므로 minor 버전이 수정되지 않는 변경만 허용됩니다.
이는 곧 patch 버전이 수정되는 변경만이 허용된다는 의미가 됩니다.
lib-a 패키지의 0.1.4 버전이 npm 에 등록되어 있다면 업데이트합니다. (패치 버전 업데이트)
lib-a 패키지의 0.2.0 버전이 npm 에 등록되어 있더라도 업데이트 하지 않습니다. (마이너 버전 고정)
lib-a 패키지의 1.0.0 버전이 npm 에 등록되어 있더라도 업데이트 하지 않습니다. (메이저 버전 고정)

package.json 에 "lib-b": "^3.5.7" 으로 버전이 지정된 경우

가장 왼쪽의 0 이 아닌 요소가 major 버전인 3 이므로 major 버전이 수정되지 않는 변경만 허용됩니다.
이는 곧 major 를 제외한, minor 버전과 patch 버전을 수정하는 변경이 허용된다는 의미가 됩니다.
lib-a 패키지의 3.5.8 버전이 npm 에 등록되어 있다면 업데이트합니다. (패치 버전 업데이트)
lib-a 패키지의 3.6.0 버전이 npm 에 등록되어 있다면 업데이트합니다. (마이너 버전 업데이트)
lib-a 패키지의 4.0.0 버전이 npm 에 등록되어 있더라도 업데이트 하지 않습니다. (메이저 버전 고정)

정리

npm semver 의 caret(^) 은 breaking change 가 예상되는 버전 요소의 수정을 제외하고 변경(업데이트)한다.

그 세부 사항은 아래와 같다.

major 버전이 0(zero)인 패키지의 업데이트는 패치버전이 수정되는 변경(업데이트)만 허용한다.

semver 에서 major 버전이 0 인 패키지는 (0.0.3, 0.8.9 등) 공식 배포판이 아닌 것으로 간주합니다. 따라서 이 경우 minor 버전의 업데이트에서도 breaking change 가 있을것으로 간주하고, minor 버전의 자동 업데이트를 제한합니다.

major 버전이 1 이상인 패키지의 업데이트는 마이너버전과 패치 버전이 수정되는 변경(업데이트)만 허용한다.

semver 에서 major 버전이 1 이상인 패키지는 (1.0.0, 12.8.9 등) 공식 배포판으로 보고, breaking change 가 있을 것이라고 기대되는 major 버전만을 자동 업데이트하지 않습니다.

해보기

빈 nodejs 패키지를 하나 만들고 (npm init) 다음 과정을 따라 진행해봅니다.

major 버전이 0인 패키지

패키지 설치하기

명령줄에 다음과 같이 0.2.0 버전의 typeorm 을 설치해봅니다. typeorm 은 글 작성일 기준으로 최신버전이 0.3.20 인 패키지입니다.

npm i typeorm@0.2.0

package.json 에는 다음과 같이 ^ 이 붙어 0.2.0 버전의 패키지가 설치됩니다.

0.2.0 버전으로 고정되어 package.json 에 패키지 정보가 추가되었다.

명령줄에 다음을 입력하여 설치된 버전을 확인합니다.

(node_modules 에서 typeorm 폴더의 package.json 을 통해 직접 확인할 수도 있습니다.)

npm list typeorm

typeorm 의 버전은 0.2.0 버전으로 설치가 되어 있다.

패키지 업데이트하기

이제 typeorm 을 다시 설치하는 명령어를 실행해봅니다.

npm i typeorm

패키지가 0.2.45 버전으로 업데이트 되었다.

package.json 의 정보도 함께 업데이트가 된 것을 확인할 수 있습니다.

package.json 의 정보도 함께 0.2.45 로 업데이트 되었다.

0.3.20 버전이 있지만, ^0.2.0 으로 지정되어있었기 때문에, 패치버전의 업데이트만 진행되었습니다.

package.json 만 남겨두고 pacakge-lock.json 및 node_modules 폴더를 지운 상태에서 npm i 를 할 때 package.json 의 버전 정보는 변경되지 않지만, 실제 설치되어 있는 패키지의 caret(^) 규칙을 따른 최신 버전일 수 있습니다.

major 버전이 1 이상인 패키지

npm list decimal.js

패키지 설치하기

명령줄에 다음과 같이 decimal.js@9.0.0 버전을 설치해봅시다. decimal.js 는 글 작성일 기준으로 10.4.3 이 최신버전입니다.

npm i decimal.js@7.0.0

package.json 에는 다음과 같이 ^ 이 붙어 7.0.0 버전의 패키지가 설치됩니다.

9.0.0 버전으로 caret(^) 이 붙어 package.json 에 패키지 정보가 추가되었다.

버전 정보를 확인해봅니다. (node_modules 의 decimal.js 폴더의 package.json 파일을 통해서도 확인 가능)

npm list decimal.js

decimal.js 의 버전은 7.0.0 버전으로 설치가 되어 있다.

패키지 업데이트하기

이제 decimal.js 를 다시 설치하는 명령어를 실행해봅니다.

npm i decimal.js

패키지가 7.5.1 버전으로 업데이트 되었다.

package.json 의 정보도 함께 업데이트가 된 것을 확인할 수 있습니다.

package.json 의 정보도 함께 7.5.1 로 업데이트 되었다.

10.4.3 버전이 있지만, ^7.0.0 으로 지정되어있었기 때문에, 마이너 및 패치버전의 업데이트만 진행하였습니다.

package.json 만 남겨두고 pacakge-lock.json 및 node_modules 폴더를 지운 상태에서 npm i 를 할 때 package.json 의 버전 정보는 변경되지 않지만, 실제 설치되어 있는 패키지의 버전은 다를 수 있습니다.

정리

npm i [패키지명] 명령어를 사용했을 때 package.json 에는 기본적으로 caret(^) 표시가 붙습니다. 이는 breaking change 가 있을 수 있는 업데이트는 진행하지 않음을 의미합니다. 패키지를 관리하는 입장에서도 breaking change 가 있는 업데이트의 경우 semver 의 의미에 따라 버저닝을 해주어야 합니다.

ChatGPT 로 영어공부하기 - 동일문장구조 대량생성

coldMater — Thu, 21 Nov 2024 23:55:13 +0900

2023년 초 ChatGPT 가 활성화되면서 대중 사이에 LLM 이 인식되기 시작할 무렵, 당시 ChatGPT는 할루시네이션, 속도 등의 문제를 안고 있었지만, 그 당시에도 '영어 문법'에 관해서는 퀄리티가 높은 답변을 내놓는 것으로 알려져있었다. 개발을 배울 때 머신러닝도 살짝 접할 기회가 있었는데, 당시 프로젝트 아이디어로 '해석이 잘 되지 않는 문장을 넣으면, 그 문장과 비슷한 구조를 가진 문장들을 대량으로 응답해주는 서비스'를 만들면 좋겠다고 생각했었다. 영어공부는 보다 '훈련'에 가깝기 때문에, 비슷한 패턴을 최대한 많이 접해보는 것이 중요하다. (그래서, 영어 단어와 뜻을 1:1 로 연결짓는 것보다, 해당 단어를 다양한 예문 속에서 접해보는 것이 중요한 이유이기도 하다.)

전치사 + 관계대명사 문법 구조를 학습하다가

최근 CORS 관련 포스팅을 하다가 MDN 문서를 자주 찾아보게 됐었는데, 유독 전치사 + 관계대명사(in which, by which) 형태의 문장이 많았었다. 그 중에 하나가 다음 문장이었다.

Cross-Origin Resource Sharing (CORS) is an HTTP-header based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading resources.

이 문장에 대한 해석이 바로 되지는 않았고, 이내 `from which` 라는 표현이 전치사 + 관계대명사 형태의 문법 구조를 갖고 있음을 알게 되었다. 이와 관련된 문법 학습을 진행하고 다시 보면 어떻게 해석해야 할지 앞에 오는 단어와 뒤에 오는 단어들을 왔다갔다거리며 해석을 할 수는 있게 되었다.

여기서 특히 해석이 쉽지 않았던 부분은 다음과 같다. (해당 부분을 강조하기 위해 축약했다.)

CORS allows a server to indicate any origins from which a browser should permit loading resources.

전치사 + 관계대명사 문법을 찾아보니 이건 두 문장이 합쳐진거라고 했다.

CORS allows a server to indicate any origins.
a browser should permit loading resources from any origins.

이걸 관계대명사로 합쳐서 다음과 같이 만든다. (차라리 이 구조는 내게 익숙하다.)

CORS allows a server to indicate any origins which a browser should permit loading resources from.

그런데 여기서 from 이라는 전치사는 관계대명사 which 의 왼쪽으로 뺄 수 있다. 이유야 있겠지만, 난 이게 이해가 잘 가지 않았다. 이걸 기존 문장 구조에 껴맞추어 해석하려면 마치 문장을 거꾸로 읽으면서 해석해야 한다. (which -> origins -> from)

내가 익숙하지 않을 뿐

직독직해를 위해서 이런건 좋지 않다. 그저 나는 이 문법구조에 익숙하지 않을 뿐인 것이다. 인공지능을 활용하기로 했다. 수년 전 생각했던 프로젝트는, 이제 인공지능에게 몇마디만 넣어주면 알아서 문장을 생성해준다.

동일 문법구조 문장 대량생성

프롬프트

아래 프롬프트에서 <문법이름>과 <영어문장> 부분을 학습하고 싶은 대상으로 치환하여 입력했다.

내가 영어 문장을 줄테니까, 최대한 단어의 위치에 맞는 품사와 동일한 다른 단어를 써서 새로운 문장을 만들어줘. 단, 내가 제시한 문장의 각 단어의 위치에 대응하는 다른 단어들이 존재해야 해. 만약 생략 가능한 단어라면 생략해도 되는데, 가능하면 대응하는 품사의 단어로 맞춰주면 좋을 것 같아. 특히 <문법이름> 문법을 이해하고 싶은건데, 이 문법 구조에 해당하는 문장 구조에 익숙해지고 싶은거야. 방금 말한 내용대로 영어 문장을 10개 만들어줘.

<영어문장>

결과

Wide-Area Network Sharing (WANS) supports a protocol-header driven approach that enables a client to specify specific servers (address, method, or port) beyond its own to which a user may request accessing files.
Network-Level Data Sharing (NLDS) is a TCP-header related method that permits a server to specify multiple addresses (network, segment, or port) apart from its default where a browser might accept downloading assets.
Secure-Access Control Systems (SACS) involve a cryptographic-key initiated system that authorizes a host to define certain endpoints (subnet, protocol, or device) outside its boundaries by which a client could allow transmitting information.
... (생략)

아래 그림은 원문과 생성된 문장의 문법적 구조가 동일함을 보여준다. (마지막 문장은 분야가 다른(IT 말고) 주제로 문장 생성을 더 부탁했더니 만들어 준 문장이다.)

ChatGPT에 원문을 던지자 문법적으로 동일한 문장 구조를 가진 문장을 생성해주었다.

아무래도 훈련하고 싶은 문장과 비슷한 패턴의 문장들을 원하는 만큼 뽑아낼 수 있으니, 의지만 있다면, 이 문법 패턴에 익숙해지는 것은 이제 시간문제다.

스크럼과 기민함의 본질 서문

coldMater — Wed, 20 Nov 2024 23:56:27 +0900

DALL.E 가 이 글을 읽고(?) 그려준 썸네일

개발을 막 배우기 시작했을 때 정보처리 국가 공인 시험을 준비하면서, 나선형 개발 프로세스, 애자일이라고 불리우는 개발 프로세스를 처음 알게 됐었다. 개발자로서 첫 취업을 준비하면서는, 당시 우아한형제들이었던것으로 기억하는데, 추천 도서 목록이 주어졌던 것으로 기억한다. 그 외에 많은 개발쪽의 구루라고 하는 사람(주로 페이스북 인플루언서)들이 추천하는 많은 책들이 애자일에 관한 내용을 다루고 있었던 것으로 기억한다. 그렇게 소프트웨어 업계에서 일하는 방식이 일반적으로 그렇다라는 것을 알게 됐었다.

애자일의 본질부터 이야기하고 가자면, 짧게 반복되는 주기마다 가치를 더하는 것이 애자일의 핵심이자, (앞으로 이 블로그에서 애자일과 스크럼에 이야기 하게 된다면) 이것이 하고 싶은 이야기의 전부이다. 개발 프로세스가 짧은 반복 주기를 가져야 하는 것은 빠른 피드백을 받기 위해서다. 가치라는 것은 다양하게 정의할 수 있겠지만, 기업에서 제품을 개발하는 입장에서의 정의는 '고객에게 제공된 가치를 통해 수익이 창출'될 수 있어야 한다.

보통 폭포수 모델과 비교되며, 개발자의 이상향처럼 애자일이 이야기되곤 했던 것 같다. 그래서 상징적으로 애자일을 개발자들의 핑곗거리로 전락시키는 경우도 많이 봐왔다. 개발자들 스스로든, 개발자와 함께 일하는 유관 부서든 그 시각은 어디서나 존재했다. 그 와중에 '애자일을 앞세워' 일을 하는 구성원들이 애자일 또는 스크럼이라는 대상에 대해 공통된 정의라도 가지고 있었다면 한결 나았을 것 같은데, 슬프게도 조직 구성원 대부분은 애자일과 스크럼을 제대로 이해하고 활용하고자 하는 의지가 없다는 것도 알게 되었다.

그렇다면, 조직에 애자일, 스크럼 전문가가 있다면 어떨까? 아마 전문가니까 조직에 그런 문화를 제대로 이식해줄 수 있으리라고 막연히 상상해보곤 했다. 수년이 흐른 지금, 그런 문화를 갈망하는 조직 자체의 열망이 중요하단 사실을 여러 주변 사례들을 통해 점점 명확하게 느껴 가고 있다.

'출근했더니 스크럼 마스터가 된 건에 관하여'라는 책이 있다. 내가 딱 그랬다. 어느 날, 회의실로 불려 들어간 나는 스크럼 마스터라는 직책을 맡게 된다. 처음에는 그저 데일리 스크럼을 주도하고, (약간은 팀장처럼 팀원들을 매니징하는 일을 곁들여서) 스프린트 리뷰 회의를 준비하여 진행하는 것이 전부라고 생각했다. 그러다가 수개월 동안 사용하고 있던 개념이 실제로는 다른 걸 의미하는 개념이었다는 것을 알게 되었었다. 이를 계기로 스크럼의 요소들의 정의를 알아보기 시작했는데, 그 용어뿐 아니라 전반적으로 잘 못 이해하고 사용하고 있는 용어나 개념이 은근히 많다는 사실까지 알게 되었다. 용어가 제대로 정의되지 않은 상태에서 이루어지는 커뮤니케이션은 모래 위에 지은 성과 같아서, 그렇게 이루어진 합의는 언제든 무너질 수 있기에 용어의 정의는 매우 중요하다. 나름 스스로를 이성적인 사람이라고 생각하는 걸 자존감의 원천으로 삼던 캐릭터인 탓에, 용어를 잘못 사용하고 있었다는 사실은 개인적으로 꽤 충격이었다. 그래서 개발 자체와는 어느정도 거리가 있음에도 '진짜 스크럼 마스터'가 되어보기로 결심을 했다.

주변에 애자일을 제대로 하고 있다는 사람을 만날 기회는 없었기에, 애자일을 제대로 이해하기 위해 할 수 있는 최선은 애자일 선언문을 그냥 외워보는 것이었다. 나는 애자일의 4가지 원칙을 '공포계획'이라고 앞글자를 따서 다른 사람들에게 소개하는 걸 좋아한다. 실제로도 이걸 외우고 나니 보이는 것들이 있었다. 그리고 회고 시간에 애자일 선언문을 근거로 더 많은 주장을 제시할 수 있었다.

스크럼은 애자일이라는 철학(?)을 구현해놓은 일종의 프레임워크이기에, 스크럼을 제대로 이해하기 위해서는 애자일 선언문을 먼저 이해할 필요가 있다. 이 4가지 내용을 현재 프로세스를 되돌아보는 데 체크리스트로 사용한다면 언제나 유효하다. 애자일 문화를 정착하고자 하는 팀에게 가장 먼저 해주고 싶은 부분이 있다면 바로 이 부분이다. 프로세스는 어떻게 운영해도 상관 없으니, 주기적으로 회고 시간을 갖고, 이 4가지만 원칙을 가지고 지난 프로세스를 판단해보라는 것이다.

회고 때 이런 상황을 그려볼 수 있다. 만약 스프린트 리뷰 회의가 장표 위주의 구두로만 전달되는 정적인 회의였다면, 회고 시간에 '동작하는 소프트웨어'를 직접 보여주는 게 필요하다고 주장해야 한다. 여기서 더 나아가, 리뷰 회의에 참여한 고객들(회사 내 제품 관계자 포함)이 제품 시연만으로 기능을 파악하기에 어려움이 있었다면, 이번에는 직접 제품을 사용해볼 수 있도록 데모 시간을 가져보자는 주장을 해볼 수도 있다.

애자일 선언문 자체를 팀 차원에서 자주 들여다보고 피드백 해보는 것 만으로도 매 주기마다 제품에 가치를 더하는 행위에 많은 도움을 줄 수 있다. '스크럼' 프레임워크는 애자일의 가치를 보다 실천적으로 실현할 수 있도록 도와주는 도구다. 스크럼을 잘 살펴보게 되면, 결국 애자일의 4가지 철학이 모두 담겨 있음을 알 수 있다. 종종 스크럼 프로세스만 좇다가 애자일의 본질을 놓치는 경우도 많은데, 이런 상황이 발생했을 때 애자일의 본질을 놓치지 않도록 균형을 잡아 주는 역할이 스크럼 마스터다.

지금은 스크럼 마스터를 하지 않고 멀찌감치 떨어져서 침을 튀기고 있지만, 팀의 프로세스를 가이드해줄 수 있으리라고 (스스로) 생각하여, 가끔은 기민함이라고 번역되는 애자일과, 스크럼에 대해서 이야기를 해보려고 한다.

[맥OS] 협업스킬이 향상되는 맥OS 스크린샷 단축키

coldMater — Tue, 19 Nov 2024 22:49:15 +0900

요즘 좋은 스크린샷 프로그램이나 스크린캐스트 프로그램들이 많이 나와있지만, 순정 기능을 익혀 두는 것은 생산성 향상에 많은 도움이 됩니다. 그런 의미에서, 맥OS 의 기본 스크린샷과 Preview 기능을 활용하여 스크린샷을 찍고, 스크린샷에 별도의 표시(Annotation)를 하는 방법을 알아봅니다.

맥OS 스크린샷 단축키

Cmd + 3: 전체화면 스크린샷 찍기
Cmd + 4: 선택영역 스크린샷 찍기
Cmd + 5: 동영상 찍기(스크린캐스트) & 스크린샷 옵션

스크린샷으로 협업능력 끌어올리기

맥OS Preview 기능을 활용하여 rectangle, arrow, line Annotation 을 추가해보았다.

기본 설정

맥OS 의 스크린샷 기능과 Preview 의 Annotation 기능을 조합하면 손쉽게 스크린샷에 표시를 할 수 있습니다. 먼저 스크린샷을 찍은 뒤 어떤 기능을 할지 정할 수 있는데요. 거기서 Preview 를 먼저 지정해주어야 합니다.

스크린샷 찍은 뒤 행동 지정하기

먼저 Cmd + Shift + 5 를 눌러 스크린샷 옵션을 불러와줍니다.
Options 을 클릭합니다.
Preview 를 선택해줍니다.

스크린샷을 찍은 뒤 행동으로, 특정 위치에 저장하기, 클립보드에 복사, 메일 보내기, 메시지 보내기, Preview 로 열기가 있습니다.

Preview Markup Toolbar 설정

Preview 에서는 생각보다 다양한 기능이 제공되지만, '용건만 간단히' 협업 능력을 끌어올리기 위해 몇가지만 살펴봅니다. 먼저 Cmd + Shift + A 키로 Markup Toolbart 를 켜고 끌 수 있습니다. (View - show/hide Markup Toolbar 에서도 가능)

아래 스크린샷의 A, B, C 에서 선의 두께, 선의 색상, 도형 내부 색상을 지정할 수 있습니다.

저는 눈에띄게 표현하는 게 효과적이라고 생각해서 빨강색으로 지정하여 사용합니다.

Cmd + Shift + A 로 마크업툴바를 토글할 수 있다.

주요 Annotation

첫번째 스크린샷과 같이 3가지 어노테이션을 추가하는 단축키를 소개합니다. 아래 4가지 어노테이션이면 스크린샷에 표현하고 싶은 내용을 거의 대부분 표현할 수 있습니다.

Cmd + Ctrl + A: 화살표(Arrow)
Cmd + Ctrl + R: 사각형(Rectangle)
Cmd + Ctrl + I: 선(I?)
Cmd + Ctrl + T: 문자열 입력하기

Preview 에서 지원하는 기본 Annotation 종류, 단축키를 외워두면 유용하다.

Preview Copy

Preview 윈도우가 활성화된 채로 Cmd + C 를 눌러 이미지를 복사해줍니다.

Cmd + Shift + 5

이 단축키로 스크린샷 설정 및 스크린캐스트(화면 동영상 찍기)를 할 수 있습니다.

동영상 찍기

Cmd + Shift + 5 로 호출된 스크린캐스트 단축키

스크린캐스트 도중 다시 Cmd + Shift + 5 를 누르면 중지 버튼이 활성화된다. 클릭하면 녹화를 중단한다.

녹화중에는 상단에 중지버튼이 활성화된다. 잊지 말고 꼭 누르도록 하자.

Cmd + Shift + 5 를 눌러 스크린캐스트 창을 열어줍니다.
A 부분의 옵션을 선택합니다.
- Record Entire Screen (전체 화면 스크린캐스트)
- Record Selected Portion (선택 부분만 찍기)
B 부분의 Record 가 활성화되는데, 이 버튼을 클릭하여 녹화를 시작합니다.
녹화를 중지하려면 화면 상단의 녹화중지 버튼을 클릭하거나, 다시 Cmd + Shift + 5 를 눌러 중지 버튼을 눌러준다.

스크린샷 찍기

Cmd + Shift + 3 으로 전체화면 스크린샷을, 또는 Cmd + Shift + 4 으로 선택영역 스크린샷을 찍을 수 있습니다.

Cmd + Shift + 5 로도 두 기능을 할 수 있는데, 한가지를 더 할 수 있습니다.

Cmd + Shift + 5 에서 스크린샷의 대상 범위

스크린샷의 빨강색 상자 내부의 아이콘은 각각 순서대로 다음을 의미합니다.

전체영역 스크린샷

듀얼모니터라면 특정 모니터를 선택해야 합니다.

선택한 창 스크린샷 (Capture Selected Window)

활성화된 창을 선택합니다. 이 기능을 활용하면 테두리가 예쁘게(?) 그림자가 들어간 채로 찍혀 나옵니다.

Capture Selected Window 기능으로 찍은 스크린샷. 테두리에 그림자가 들어가 있다.

선택영역 스크린샷

모니터의 특정 영역을 미리 지정해둘 수 있습니다. 모니터의 특정 부분을 여러 번 스크린샷을 찍어야 한다면 유용합니다. option 의 마지막 선택을 기억하기 (Remember Last Selection) 를 선택하면, 다음번 Cmd + Shift + 5 를 눌렀을 때 그 전에 선택한 영역이 그대로 남아있습니다. 그 상태에서 Enter 를 누르면 바로 스크린샷을 찍을 수 있습니다. 여기서 Preview 여는 것 대신 특정 폴더에 저장을 하도록 하여 특정 영역의 스크린샷을 계속 찍을 수 있습니다.

Cmd + Shift + 5 에서 선택영역 스크린샷 기능으로 선택영역을 선택한 모습