코드 작성에 AI의 도움을 받을 수 있는 가장 유명한 도구 중 하나로, GitHub이 2021년 발표한 GitHub Copilot이 있습니다. 2024년 12월 GitHub Copilot for VS Code 무료 플랜을 제공하기 시작해,제한적(2k/월 코드 어시스트, 50건/월 채팅)이긴 하지만 누구나 활용할 수 있게 되었습니다.그런데 Copilot의 도움을 받으려면 프롬프트로 질의를 작성해야 하며, Copilot이 각자의 환경에 맞춰 답변하게 하려면 매번 프롬프트로 상황을 전달해야 합니다. 이는 매우 귀찮고 불편한 작업일 수 있습니다.이 글에서는 이러한 불편함을 없애고 개인별 환경 또는 프로젝트 환경에서 VS Code Copilot 지침을 만들고 이를 활용하는 방법을 간단한 예시와 함께 소개합니다.커스텀 지침커스텀 지침(custom instruction)을 미리 정의해 두면, Visual Studio Code(이하 VS Code) 내에서 Copilot이 답변할 때 이 지침을 따르도록 설정할 수 있습니다.프로젝트 저장소에 지침서 파일을 저장하면 해당 프로젝트에 참여하는 이들이 모두 동일한 지침에 따라 답변을 얻을 수 있고, VS Code 설정 파일인 settings.json 파일에 개인용 지침을 설정할 수도 있습니다.프로젝트 공통 지침프로젝트 공통 지침을 사용하려면 프로젝트의 .github/copilot-instructions.md 파일에 지침을 작성해 저장소에 푸시합니다.지침서 파일에는 다음과 같이 Copilot 채팅 질의 시 사용자의 질문을 보완하기 위한 컨텍스트 또는 관련 정보를 자연어 형태의 짧은 문장으로 작성합니다.We always write JavaScript with double quotes and tabs for indentation, so when your responses include JavaScript code, please follow those conventions.Our team uses Jira for tracking items of work. 하지만 지침에서 다음과 같이 외부 리소스를 참조하도록 요청하거나 특정 세부 정보 응답을 요청하면 제대로 동작하지 않을 수 있습니다.Always conform to the coding styles defined in styleguide.md in repo my-org/my-repo when generating code.Use @terminal when answering questions about Git.Answer all questions in the style of a friendly colleague, using informal language.Answer all questions in less than 1000 characters, and words of no more than 12 characters. 다음은 지침을 작성하지 않았을 때 Copilot 채팅 질의 답변입니다. 영어로 질의하면 Python 코드와 영어로 답변합니다.이제 다음과 같은 지침을 작성하

앱과 웹의 연결고리 : 여기어때 통합 WebView 구축기Photo by JJ Ying on Unsplash안녕하세요. 여기어때컴퍼니 Android개발팀 태런입니다.앱 개발 방식에는 네이티브 앱, 웹 앱, 하이브리드 앱 이렇게 세 가지가 있습니다. 각 방식은 개발 목적이나 사용 환경에 따라 선택되는데요. 여기어때 앱은 모바일 기기에 최적화된 네이티브 언어(예: Swift, Kotlin)로 개발된 네이티브 앱입니다. 구글 플레이 스토어나 앱 스토어에 등록된 대부분의 앱이 네이티브 앱에 해당하죠.그런데 네이티브 앱에서도 웹 콘텐츠를 사용하는 경우도 있는데요. 이럴 때는 웹뷰(WebView)를 활용하여 앱 내에서 웹페이지를 불러올 수 있습니다. 웹뷰로 외부 웹페이지를 앱 안에서 렌더링해 사용자 경험을 자연스럽게 유지할 수 있습니다.여기어때 앱에서도 웹뷰를 사용하나요?여기어때 앱 내에서도 웹뷰가 사용되고 있다는 사실, 알고 계셨나요? 저는 이 웹뷰에 대해 이야기해 보려고 합니다. 웹뷰가 무엇인지, 그리고 앱과 웹이 어떻게 연동되는지 설명하면서, 기존 여기어때 앱에서 파편화된 웹뷰를 통합했던 경험도 말씀드리겠습니다. 궁금하시다면 끝까지 읽어주세요!네이티브 앱과 웹의 연결고리 웹뷰(WebView)웹뷰란 무엇일까요? 네이티브 또는 크로스 플랫폼 앱 내부에 웹 브라우저 기능을 내장해 웹 콘텐츠를 표시할 수 있는 컴포넌트입니다. 간단히 말해, 앱 안에서 웹페이지를 직접 로드하고 보여주는 임베디드 브라우저라고 볼 수 있습니다. 웹뷰의 가장 큰 장점은 네이티브 앱과 웹의 강점을 결합해 개발 효율성을 극대화할 수 있다는 것입니다.그럼 웹뷰가 제공하는 주요 이점들을 살펴보겠습니다.첫째, 개발 비용을 절감 할 수 있습니다.웹뷰를 활용하면 하나의 웹페이지로 Android, iOS, 웹 등 다양한 플랫폼에서 동일한 콘텐츠를 제공할 수 있습니다. 이를 통해 개발 시간과 비용을 대폭 절감하고 유지보수도 간소화할 수 있죠. 특히 리소스가 제한된 스타트업이나 다양한 플랫폼 지원이 필요한 기업에게는 최적의 솔루션이 될 수 있습니다.둘째, 실시간 콘텐츠 업데이트가 가능합니다.웹뷰를 사용하면 앱을 재배포하지 않고도 웹 콘텐츠를 즉시 수정할 수 있습니다. 특히 빠른 업데이트가 필요한 상황에서 매우 유용합니다. 스토어 심사 절차를 거치지 않고도 콘텐츠를 바로 변경할 수 있어 긴급한 이슈에도 신속하게 대응할 수 있습니다.셋째, 앱을 빠르게 개발하여 출시할 수 있습니다.시장에 빠르게 진입하기 위해 초기 버전의 앱을 웹뷰로 구현하는 경우가 많습니다. 웹 기술을 활용해 빠르게 프로토타입을 만들고, 이후 필요에 따라 네이티브 기능으로 전환할 수 있습니다.이러한 장점을 바탕으로 개발 효율성과 유연성이 필요할 때 웹뷰를 사용한다면 강력한 도구가 될 것입니다. 다만, 속도 저하나 UI/UX 제약 같은 단점을 충분히 고려하여 사용해야 합니다. 특히, 빠른 시장 대응과 개발 비용 절감이 중요한 프로젝트라면 웹뷰는 좋은 선택이 될 수 있습니다.웹뷰에서 앱과 웹 연동하기웹뷰는 앱과 웹 간의 데이터 교환

굳이 Svelte 를 선택한 이유왜 하필 Svelte 인가요? 아직 시기상조 아닐까요?Javascript 가 Web 표준 개발 언어기 때문에, 자연스럽게 해당 언어에 기반한 Web Framework (혹은 Library) 는 짧은 시간 내 굉장히 많이 생기고, 동시에 많이 사라지고 있는 것 같습니다.Web Framework 를 선택하는 것이 더욱 어려운 이유는, Frontend 분야의 트렌드가 다른 개발 분야에 비해 비교적 빠르게 변화하고 있기 때문입니다.실제로, 지난 10년 사이에 크고 작은 지각 변동이 수차례 있었던 것 같습니다.2010년대 초반에는 jQuery, 2010년대 중반에는 Angular, 2010년대 후반 이후에는 React 와 Vue 가 Web Framework 핵심 트렌드였던 것 같습니다.개인적으로는 대부분의 기간을 Frontend 분야와 친숙하게 지내지 않았기 때문에, 위와 같이 빠르게 변하는 Frontend 업계 트렌드를 그저 '옆동네 불구경' 정도로 생각했던 것 같습니다.막상 Web 개발 공부를 시작하려다 보니 꽤나 많은 선택지 앞에서 당황했고, 실제로 공부하고자 하는 Web Framework 를 선택하는 과정에서 많은 고민을 하게 되었습니다.현재 시점에서 Javascript 기반의 Web Framework 를 선택할 때, 가장 안정적인 옵션은 의심의 여지없이 React 혹은 Vue 입니다.Frontend 분야에서 이미 전세계에서 큰 비중으로 활용되고 있기에, 개발 안정성이나 확장 가능성은 보장되었다고 해도 무방합니다.실제로, Frontend 분야의 채용 시장도 모두 React, Vue 중심으로 열려 있고, 온라인과 오프라인 구분할 것 없이 대부분의 학습 자료는 해당 Web Framework 위주로 구성되어 있습니다.또한, 현실적으로 개발자들에게 굉장히 중요한 요소로 작용하는 커뮤니티 성숙도 측면에서 압도적인 모습을 보이고 있습니다.직면한 문제가 무엇이든, 대부분 Google 혹은 Youtube 에 이미 해당 문제를 경험하고 해결한 사례가 존재하기 때문에React, Vue 에 익숙하지 않은 개발자더라도 풍부한 Reference 를 통해 어렵지 않게 궁금증을 해결할 수 있습니다.심지어, ChatGPT 도 다른 Web Framework 와 관련된 질문보다는 React, Vue 와 관련된 질문에 보다 명쾌한 해결책을 제시하는 경우가 많습니다.처음 Svelte 를 접하게 된 계기는 '노마드 코더' 라는 유튜버의 Svelte 소개 영상이었습니다.Frontend 분야에 대한 기본 지식이 부족했기에, Svelte 를 추천하는 다양한 이론적인 (Virtual DOM 을 사용하지 않는다든가, 경량화 되었다든가, 실질적인 의미의 Reactive 특성이 구현된 형태다든가 하는) 강점보다는,초심자 입장에서 가시적으로 느낄 수 있을 정도의 간결한 Code 형태가 굉장히 매력적으로 다가왔습니다.이를 계기로, Svelte 라는 Web Framework 에 관심을 가지고 다양한 자료를 찾아보기 시작했습니다.하단에 첨부된 이미지와 같이, 20

안녕하세요, 이번 글에서는 javascript의 Proxy API를 사용해 웹 기반 에서 gRPC 게임 서버와 효과적으로 통신하는 방법을 소개합니다.요즘 웹 서비스들은 통신 방식으로 대부분 REST API를 사용합니다. 하지만 실시간으로 많은 데이터를 주고받아야 하는 게임의 특성상, REST API를 사용하기에는 어려운 부분이 있습니다. 쿠키런: 킹덤을 포함한 데브시스터즈의 여러 게임은 효율적인 통신을 위해 API 프로토콜로 gRPC를 채택하고 있습니다. 아마 gRPC를 처음 들어보시는 분들도 있을 것 같은데요, gRPC의 특징 몇 가지 짚고 가겠습니다.• gRPC는 HTTP/2에 커스텀 헤더를 추가한 프로토콜로 통신합니다.• 메시지 데이터는 protocol buffers(이하 protobuf)를 사용해 바이너리 형태로 직렬화하여 전송합니다.• protobuf를 사용하여 데이터 구조를 정의할 수 있고, code-gen 라이브러리로 스키마에 대응하는 파일과 파일을 생성할 수 있습니다.위의 세 가지 특징으로 의 아키텍처를 아래와 같이 구성했습니다.gRPC에 필요한 커스텀 헤더를 브라우저가 지원하지 않아 로 직접 gRPC 호출을 할 수 없기 때문에 를 프록시 서버로 두어야 합니다.[1] code-gen으로 생성된 파일은 직렬화/역직렬화 로직으로 와 간의 gRPC 통신에 사용되고, 와 간의 통신은 직접 HTTP endpoint를 작성해야 합니다.그런데 이 구조에서는 한가지 문제점이 있습니다. 대부분의 protobuf code-gen 라이브러리가 Node.js 런타임을 대상으로 하기에 FE ↔ BE 통신의 구현체는 code-gen을 활용하지 못하고, gRPC method가 추가될 때마다 REST API의 endpoint를 직접 추가해야 하는 번거로움이 있습니다. 즉, protobuf를 쓰는 이유가 퇴색되고 있던 것입니다.오늘도 어김없이 개발자 김용쿠는 gRPC와 똑같은 REST API를 추가하다 문득 이런 생각이 들었습니다.저 타입처럼 동작하는 브라우저용 구현체를 자동으로 만들 수 없을까?[2]protobuf parser로 직접 FE용 code-gen을 만들어 이 문제를 해결할 수도 있습니다만, 이미 타입 정보가 존재하는데 각 endpoint와 1대1 대응하는 js 코드를 또 만들어야 할까요? 아래의 pseudo code를 상상하며 다음의 목표를 세웠습니다.• JavaScript 구현체와 code-gen으로 생성된 타입을 합쳐, 기존에 BE에서 사용하던 모습 그대로 마치 FE에도 api client 존재하듯 개발자를 속이자• 구현체는 타입 시그니처대로 동작해야 한다• 는 code-gen을 사용하지 않고 런타임에 동적으로 의 함수를 호출하도록 설계하자그런데 어떻게 code-gen 없이 구현체를 만들 수 있을까요? 답은 JavaScript Proxy에서 찾을 수 있습니다.JavaScript의 Proxy는 Reflection과 함께 JavaScript의 meta-programming 기법에 사용하는 API로, 객체의 여러가지 기본 동작을 재정의 할 수