안녕하세요. iOS개발팀 드락입니다. 2024.12.2~6 라스베가스에서 열린 2024 AWS re:Invent에 다녀오게 되어, 보고 듣고 느낀 것들을 간단히 스케치하고자 합니다.저희 일행은 일요일 오전 10시에 인청공항 집결 후 인천에서 LA로, LA에서 미국 국내선으로 환승해서 라스베가스까지 비행하게 됩니다. 이동에는 공항 대기시간을 포함해서 대략 20시간 걸린 것 같네요..A380 처음 타봅니다..뚱땡이 비행기네요 ㅎㅎ이번 출장동안 저희가 묵을 이집트 컨셉의 룩소르 호텔 모습입니다.re:Invent 출장에서 저의 목표는컨퍼런스 세션 참관엑스포 참관업계 분들과 네트워킹 및 다양한 솔루션 듣고 견문 넓히기였습니다.오전 8시부터 저녁까지 일과 시간 동안 여러가지 다양한 세션들을 들을 수 있었고, 일부를 한번 공유해 봅니다.세션 슬라이드들에 임팩트있고 공감갔던 내용들이 많아서 사진을 많이 찍었는데 저작권상 블로그 글에 활용하지 못하고 세션 원본 링크와 글로만 풀어야 하는 점이 조금 아쉽네요 ㅜㅜhttps://medium.com/media/15c565a4c5ef7581f3b6151eb745017a/href야놀자클라우드의 CEO Jeff Kim이 스피커로 참석한 세션에서는 AI와 실시간 데이터를 활용한 초개인화 전략, SaaS 솔루션을 통한 호스피탈리티 운영 개선 스토리 등의 소개가 있었습니다. 세션 후 짧게 인사를 나누었는데요. 여기어때를 경쟁사로 생각하지 않고 고객이라고 생각한다고 이야기주셨던 게 기억에 남네요..ㅎㅎhttps://medium.com/media/ab1172e1c318bf4dfb14c5b71f789dc6/href미리캔버스로 잘 알려진 미리디에서도 이미 AI를 적극적으로 활용하고 있었습니다. 탬플릿들의 메타데이터를 기반으로 유사 탬플릿들을 모아서 추천하고 있네요. 저희 제휴점 이미지 메타데이터 구축 및 활용과도 유사한 접근이었습니다. 개발자들이 각자의 자리에서 생각하는 게 다들 비슷비슷 합니다 :)LLM 서비스의 대표적인 인터페이스 방식인 챗봇의 형태가 자연어로 소통한다는 부분에서 사용법이 조금 모호할 수는 있지만 그만큼 다방면에서 가장 유연한 대응성과 개발 용이성을 가지고 있기도 한 것 같습니다. 가장 모호하지만 대응 범위도 가장 넓다고 하면 될까요.. 그래서 많은 회사들이 챗봇 형식 기반으로 여러가지 부가적인 기능들을 제공하는 식으로 진행되고 있지 않나 싶습니다.이미 가지고 있는 데이터들을 어떻게 Gen AI가 잘 인식/처리/제공할 수 있게 할 것인가?AI를 통해 나온 결과물.. 일부는 쓸만할 것 같긴 한데 실제 서비스로 쓰기에는 조금 부족하다 싶은 부분들이 섞이게 되는데, 이 부분을 어떻게 잘 처리해서 최종 결과물의 완성도를 올릴 수 있을까?현시점에서 Gen AI 활용 관련해서 고민하는 많은 회사들의 공통된 관심사가 아닐까 합니다.LG도 자사에서 확보해둔 데이터에 메타정보를 더하고 그를 기반으로 필터링하는 형태를 이미 상당히 진행했고, 내부 서비스에 활용하고 있는 모습이었습니다. Text나 문서를 SQL 또는 xml이나

안녕하세요! 커뮤니티실 그룹 플랫폼팀의 서버 개발자 하이디(Heidi)예요 저는 동네에서 일어나는 다양한 온·오프라인 활동을 연결하는 모임 서비스를 만들어 나가고 있어요.커뮤니티실은 사용자에게 연결의 가치를 전하기 위해 도전적이고 다양한 기능들을 빠르게 테스트하는 조직이에요.이 과정에서 서버와 클라이언트 간의 API 인터페이스 조율이 자주 발생하게 되어 팀원 모두가 JSON 관리의 달인이 되고 있단 생각을 하곤 해요 . 그렇다 보니 API 라는 소통 수단은, 구현하는 것 뿐만 아니라 설계하는 것 또한 매우 중요하다는 점을 깨닫게 됐어요. 효율적인 API 설계야말로 원활한 데이터 교환을 위한 초석이 되기 때문이에요.그런 의미에서, 오늘은 커뮤니티실 개발자들이 어떤 방식으로 API를 만들어왔고, 현재는 어떻게 만들고 있는지 소개하는 시간을 가져볼까 해요. 어려운 내용은 아니니, 가벼운 마음으로 재밌게 읽어주세요  Design-First커뮤니티실에서 만들고 있는 서비스는 사용자 경험을 중요하게 여기고 있는 만큼 다양한 화면과 기능으로 이루어져 있어요. 따라서 클라이언트 관점에서의 API 설계가 매우 중요해요. 사용자가 어떤 방식으로 서비스를 경험하게 될지를 고려해 API를 설계해야 하니까요.이런 이유로, 커뮤니티실에서는 API를 설계할 때 자연스럽게 Design-First API 접근 방식을 택하게 됐어요.Design-First 접근 방식이란, API 설계 시에 명세를 먼저 작성하는 접근법을 뜻해요.서버 구현에 앞서, 클라이언트와 함께 양쪽의 의견이 잘 버무려진 API 명세를 정의한 다음, 이를 기반으로 클라이언트와 서버를 동시에 구현하는 방식으로 API를 만들고 있다고 이해해주시면 되어요. (아마 많은 분께 익숙한 방식일 것 같아요  )커뮤니티실 API 설계 방식 변천사과거 API 설계 방식, 노션2022년 초에는 주로 노션을 통해 API 명세를 작성했어요. 노션은 누구나 쉽게 접근 및 수정을 할 수 있기에, 서버와 클라이언트가 API 명세에 대해 빠르게 논의할 수 있었기 때문이에요.노션을 이용해 API 를 만드는 과정은 아래와 같아요.API 명세를 작성한다.위의 명세에 기반해2 1. 클라이언트에서 Mocking API를 작성하고, 임시로 사용한다.2 2. 서버에서 API를 작성한다.3. 서버에서 API가 완성되면, 클라이언트에서 해당 API를 사용한다.노션을 이용한 API 작성 과정노션은 구성원이 적은 상황에서 서로 가볍고 빠르게 소통하고 수정할 수 있다는 장점이 있었어요. 하지만 점차 동료들이 늘어나고 서비스의 크기가 커지면서 여러 가지 문제점에 직면하게 되었죠.  ~ 노션으로 API 명세를 논의해봤다면 왠지 모르게 익숙할 문제점들 ~1️ 노션 API 명세를 보고, 요청/응답 모델을 수동으로 작성해요. 개발 속도의 저하 2️ 유사한 구조를 가진 API가 늘어날수록, 그에 따른 비효율은 더 커졌어요. 비효율적인 개발 3️ API 명세를 만드는 사람마다 방식이 달라요 표준이 없음 4️ 게시글 조회 API 말고, 사용자 정보 조회 API 명세는 어디서 찾아야 해요? 명세의 파편화 5️ 이 명세 최신 맞아요? API 명세 신뢰도 부족 이러한 문제점들을 하나씩 겪게 되면서, 우리 팀에 더 잘 맞는 API 설계 방법은 없을지 고민하기 시작했어요. 그러다가 기존 문제점들을 보완할 수 있는 새로운 방식을 찾게 되었죠. 그건 바로 API 명세 작성을 위한 IDL인 **OpenAPI Specification** 이었어요.OpenAPI Specification, OASOpenAPI Specification, 줄여서 OAS라고 불리는 이 인터페이스 언어는 HTTP API를 정의하고 문서화하기 위한 규격이에요. API의 엔드포인트, 매개변수, 입출력 데이터 형식을 JSON 이나 YAML 형태로 표현할 수 있어요.또한, OAS의 규격에 맞는 API 명세를 작성하면 openapi-generator라는 도구를 통해 API 문서와 다양한 프로그래밍 언어의 클라이언트/서버 코드를 자동으로 생성해줄 수 있어요.OAS API 명세를 기반으로 생성된 API 문서, 각 언어별 서버/클라이언트 코드OAS를 사용하면 노션을 이용한 기존 API 명세 설계 방식의 문제점들이 이렇게 해결돼요.1️  , 2️ 노션 API 명세를 보고, 요청/응답 모델을 수동으로 작성해요. / 유사한 구조를 가진 API가 늘어날수록, 그에 따른 비효율이 커져요. YAML 이나 JSON으로 API 명세를 작성하면 각 요청과 응답에 대한 코드를 생성할 수 있으므로, 수동으로 작성하지 않아도 돼요.3️ API 명세를 만드는 사람마다 방식이 달라요. OAS에서 제안하는 규격대로 API 명세를 작성해야하기 때문에 API를 일관된 형식으로 작성할 수 있어요.4️ 게시글 조회 API 말고, 사용자 정보 조회 API 명세는 어디서 찾아야 해요? 모든 API 명세를 별도 저장소에서 관리하면, 각 명세를 쉽게 찾을 수 있어요.5️ 이 명세 최신 맞아요? API 명세를 통해 코드로 만들어진 요청/응답 모델을 사용하면, 코드와 명세와 강결합되어 항상 최신성이 보장돼요.그뿐만 아니라 OAS는 누구나 쉽게 이해할 수 있는 YAML 이나 JSON으로 API를 정의할 수 있어요. 그래서 누구나(심지어 개발자가 아니더라도) API 명세에 기여할 수 있죠. 이런 점은 클라이언트 중심 API 설계를 중요하게 여기는 커뮤니티실의 개발 방향성과도 잘 맞아떨어진다고 생각했어요.그래서!(두둥) 커뮤니티실은 OAS로 API 명세를 관리하기로 했어요.  현재 API 설계 방식, OAS새로이 OAS를 도입한 결과, API 명세를 만들어가는 과정은 이렇게 달라졌어요.API 명세를 관리할 전용 저장소(GitHub Repository)를 만든다.해당 저장소에 Pull Request 를 열어 API 명세를 정의하고 검토한다.명세가 main 브랜치에 머지되면, GitHub Actions 워크플로우에서 openapi-generator를 실행해 클라이언트/서버 코드를 자동으로 생성한다.클라이언트/서버는 생성된 코드를 사용한다.OAS를 이용한 API 작성 과정이렇게 API 명세를 논의하는 공간(

안녕하세요, 데보션영 3기로 활동중인 강대훈입니다 🙇🏻‍♂️먼저 이 글을 쓰게 된 계기는, 데보션에서 노션에 대한 자세한 소개 글 을 접하고, 같은 노트 앱인 옵시디언에 대한 소개글도 있으면 좋을듯 해서 작성하게 되었습니다.옵시디언 사용 이유와 몇 가지 플러그인 활용법, 장단점에 대해 간단히 다뤄보겠습니다 😊그동안 저는 필기 앱으로 수 년간 노션을 주로 활용해왔습니다.노션은 정말 많은 장점들을 가지고 있습니다.우선 러닝커브가 거의 없다시피 하며, 기존 노트앱에 꿈꿔온 수많은 기능들이 내재되어 있어 처음 접했을 땐 거의 혁신과도 같았습니다.그러나 몇가지 이슈들로 인해 타 노트앱으로의 이전을 마음먹었습니다.1. 느린 속도와 높은 메모리 점유율노션은 노트앱치곤 리소스를 많이 잡아먹고, 데이터가 쌓일 수록 속도도 눈에 띄게 느려졌습니다.백그라운드에 두었을 때에도 옵시디언의 약 두배에 달하는 메모리 사용량을 보여주었고,실제 사용 중일 때에는 1GB를 넘어가는 기염을 토하기도 했습니다.저는 노트 앱에 메모리를 1GB 이상 투자하는 것이 과연 맞을까 생각이 들었고, 노트를 켜고 메모를 작성할 때마다 버벅임과 버퍼링을 겪으며 스트레스를 받아왔습니다.다음은 노션에서 기존에 사용하던 대시보드입니다.기본적인 UI가 예쁘고 깔끔하긴 하지만, 어느 정도 쓰다보면 질리는 것은 사실입니다.자유롭게 커스터마이징이 힘들다는 것이 사용하면서 계속 아쉬웠습니다.물론 노션 인핸서와 같은 어느정도의 솔루션은 존재하지만, 커스터마이징에 한계가 있고 노션 앱의 업데이트에 따라 호환성이 깨질 수 있다는 점 등 다양한 문제가 존재합니다.앞선 속도와도 같은 원인으로, 노션은 클라우드 기반이기 때문에 데이터베이스도 노션 쪽에서 가지고 있고, 내 데이터에 대한 주권이 나에게 있지 않습니다.따라서 노션 서비스에 모종의 장애가 발생할 경우, 내가 작성한 노트를 보지 못하고 최악의 경우 소실할 수도 있고, 최근 들어서도 몇 번이나 노션 서버에 장애가 생겨 노트를 보지 못해 불편을 겪는 상황이 종종 있었습니다.또한 인터넷이 차단된 폐쇄망 혹은 네트워크가 불안정한 환경에서도 노트를 볼 수 없습니다.위 요소들은 상당한 디메리트라고 생각하고 노트 앱을 변경하게 된 결정적인 이유가 되었습니다.옵시디언은 빠르게 성장하고 생태계를 넓히는 중인 노트앱으로, 로컬 + 마크다운 기반으로 작동하는 노트앱으로서 메모 앱들의 대체제로 떠올랐습니다.이 앱은 위에서 제시한 노션의 단점들을 상쇄할 수 있는 요소들을 가지고 있어, 활용하기에 따라 무궁무진한 가능성을 가지고 있습니다.1. 능동적인 데이터 백업과 빠른 속도먼저 로컬 기반으로 동작하기 때문에, 데이터를 사용자 개인이 저장하고 있습니다.그리고 마크다운 기반이기에 텍스트 파일로서 저장되고, 텍스트 편집기와 파일 관리자로 노트를 편집, 관리할 수 있을 뿐만 아니라 데이터 용량 자체도 굉장히 작습니다.또한 데이터를 사용자가 가지고 있으므로 이중 , 삼중 백업 또한 자유입니다. 깃허브, 외장하드, NAS등 다양한 백업 루트를 활용할 수 있습니다.물론 로컬 + 마크다운 기반이라는 말은 속도가 굉장히 빠르다는 것 또한 의미합니다.데이터가 아무리 쌓여도, 속도로 인해 답답할 일도 없고 메모리를 과다하게 사용하는 일도 없습니다.2. 다양한 커스터마이징 요소와 무한한 확장성옵시디언은 쉽게 질릴 일이 없습니다.마치 어렸을 적 다꾸를 하듯이, 메모 앱을 입맛대로 꾸밀 수 있는데요, 옵시디언에는 사용자들이 제작한 다양한 테마들이 존재합니다.이를 클릭 몇 번으로 자유롭게 사용 가능하고, 그 안에서도 얼마든지 커스터마이징 또한 가능합니다.저는 개인적으로 사용하는 볼트는 AnuPpuccin을 사용 중입니다.*(볼트는 저장소의 단위로, 노션의 워크스페이스와 비슷한 개념이라고 볼 수 있습니다)위 사진이 옵시디언을 처음 시작했을 때의 모습이고,위 모습이 제가 커스텀해서 현재 사용 중인 모습입니다.이처럼 보이는 UI 뿐만 아니라 모든 동작에 대한 단축키, 노트 생성에 대한 규칙, 아웃링크 규칙, 헤더 사이즈 별 색상 설정등 상상하는 대부분의 요소를 커스텀할 수 있습니다.물론 이는 옵시디언에서 기본적으로 제공하는 기능도 있지만, 대부분은 커뮤니티 플러그인 을 통해 이루어집니다.옵시디언의 가장 큰 특징 중 하나로, 사용자가 만든 추가 확장 기능을 커뮤니티 플러그인이라고 부릅니다.사용자들은 불편을 겪는 요소나 필요하다고 생각하는 기능들을 공식 웹사이트에 건의하는 것이 아닌, 직접 만들고 배포하며 생태계를 키워갑니다.24년 4월 기준 1631개의 플러그인이 공식적으로 존재하며, 비공식적으로 배포 중인(불법 요소가 있어서가 아니라 베타 버전 상태인) 플러그인까지 포함하면 그 수는 정말 방대합니다.다양한 플러그인 활용법들은 이후 옵시디언의 단점에 대해 다루면서 함께 알아보겠습니다.3. 무료로 제한 없이 사용 가능옵시디언은 유료 라이선스가 존재하며, 장치간 노트 동기화와 노트 퍼블리싱은 유료 솔루션으로서 제공중입니다.그러나 이러한 부분들도 후술할 커뮤니티 플러그인에서 무료로 해결 가능합니다.옵시디언은 매우 강력한 검색 기능을 제공합니다.노트들이 모두 각각의 텍스트 파일이기 때문에 굉장히 빠른 속도의 검색을 제공합니다.위 예시는 제 노트에서 실제로 특정 키워드를 검색하는 모습을 녹화한 것입니다.'smb' 에 대해 검색한다면, 해당 키워드가 포함된 모든 노트와, 아웃링크를 가진 노트까지 전부 검색이 가능합니다.또한 데이터의 양과 상관없이 매우 빠른 쿼리 속도를 보여줍니다.🩹옵시디언의 보완 가능한 단점과 유용한 플러그인옵시디언의 대부분의 단점들은 플러그인을 통해 보완이 가능합니다.몇 가지 필수적이라고 생각하는 기능들을 구현하는 방법을 플러그인 사용법과 함께 다뤄보겠습니다.대시보드의 필요성은 말해봐야 입만 아픕니다.폴더 탐색기와 달리 한 눈에 내가 현재 진행하는 모든 일들과 해야 하는 일을 볼 수 있고,그러한 파일들을 모두 아웃링크 / 인링크로 연결하여 사용성을 극대화 할 수 있습니다.더불어 노트 앱에서 자칫 길을 잃는 것을 방지해 줍니다.• None 메모를 쉽게 관리하는 색인으로 설계된 대시보드 만들기먼저 dashboard CSS 스니펫을 현재

안녕하세요? 저는 강남언니에서 웹 프론트엔드 개발자로 일하고 있는 Evan입니다. 이 글에서 저는 스쿼드에서 제품을 개발하면서 직면했던 한 가지 큰 도전, 바로 '제품 정책 문서 파편화' 문제와 그 해결 과정에 대해 이야기하고자 합니다. 제품 개발 과정에서 정보의 분산은 큰 혼란을 야기할 수 있습니다. 저희 팀은 이 문제를 해결하기 위해 기존의 작업 방식을 재고하고, 새로운 솔루션인 'FigNotion'을 만들었습니다.강남언니 제품 개발 조직은 디자인 협업 툴로 Figma(피그마), 또 문서 관리 도구로 Notion(노션)을 사용하고 있습니다. 스쿼드 마다 세부적인 내용은 다를 수 있으나 일반적으로 제품과 관련된 정책은 Notion으로 관리하고 제품 디자인은 Figma에서 관리하고 있습니다.창 하나에 있는 디자인과 정책이전에는 디자인 파일에 있는 화면의 정책이 적혀 있는 문서를 찾기가 어려웠습니다. 이를테면 A 화면 디자인 파일을 봤는데, 특정 UI에 대한 정책 문서를 찾고 싶다면 방대한 노션 데이터베이스로 이동해 정책을 찾는 식이었죠. 위 문제를 해결하기 위해 강남언니 제품 조직은 Figma 파일 옆에 정책 문서를 작성하기 시작했습니다.이렇게 하면 디자인과 정책이 한 군데에 있기 때문에 프론트엔드 개발자는 작업 시 Figma 파일 하나에서 디자인 요구사항과 정책을 확인하며 코드를 작성하면 됩니다. Figma와 Notion 두 창을 띄워놓지 않을 수 있게 된 것이죠. 하지만 개발 완료 후 제품 릴리즈를 위해 인수테스트를 할 때면 꼭 하나 둘 놓치는 요구사항들이 생겼습니다.분명히 디자인 옆에 적혀 있는 정책대로 개발했는데 왜 놓친 걸까요?요구사항을 놓친 이유는 정책 문서가 두 군데 있었기 때문이었습니다.제품 요구사항은 변하기 마련입니다. 노션의 정책 문서, 인수테스트에서 사용하는 Test Case 문서에는 변경사항이 반영됐는데, 개발할 때 참고하던 Figma에는 반영이 안 된 것이었죠. 관리 지점이 늘어나면서 파편화가 생긴 것입니다.그래서 모든 정책 변경사항을 챙기기 위해 Figma 파일과 Notion 문서를 함께 챙겼습니다. 두 문서를 비교하기 전까지 이것이 정확한 정책인지 확신할 수 없었습니다. 그리고 두 문서가 서로 다르면 어떤 것이 맞는 정책인지 제품 개발을 멈추고 동료들과 이야기했습니다.하지만 이것은 귀찮고 성가신 일이었습니다. 저는 이 문제를 해결할 수 없을까 고민하기 시작했습니다.디자인 옆에 있는 문서가 원본 문서를 바라볼 수 있다면정책 문서 파편화 문제를 해결하기 위해 다음의 요구사항을 만족하는 제품이 필요했습니다.• Figma 디자인 파일 안에서 특정 Notion 문서의 내용을 불러올 수 있어야 한다.• 위에서 만든 문서는 원본 Notion 문서와 내용이 항상 같아야 한다.위 요구사항을 만족시키는 제품으로 Figma Widget을 떠올렸습니다.Figma Widget은 사용자 인터페이스 디자인을 위한 Figma 애플리케이션에서 사용할 수 있는 작고 사용자 정의 가능한 구성 요소인데요. Widget은 디자이너들이 더 효율적이고