remember-tech 최신 글

최신 글

• 리멤버 iOS의 SwiftUI 도입기 — 허들을 하나씩 넘기며

  리멤버 iOS의 SwiftUI 도입기 — 허들을 하나씩 넘기며 Hurdle Between Remember And SwiftUI 안녕하세요, 리멤버 iOS챕터 허성진입니다. SwiftUI, 도입하셨나요? 새 프로젝트라면 이미 자연스러운 선택이 되었지만, 오래된 UIKit 앱이라면 여전히 어디서부터 시작하지?라는 막막함이 남아있을 수 있습니다. 리멤버는 명함 관리부터 경력직 채용, 직장인 커뮤니티, 그리고 최근 출시된 커넥트 SNS까지 — 일하는 프로들을 위한 비즈니스 네트워크 앱입니다. 2014년 출시 이후 10년이 넘는 시간 동안 서비스를 이어오고 있고, 그만큼 코드베이스의 대부분은 UIKit을 기반으로 구성되어 있습니다. Remember App Store Screenshots 최근 AI 코딩 도구와 Figma MCP 같은 디자인-개발 연동 도구들이 등장하면서 SwiftUI를 써야 할 이유가 더욱 명확해졌습니다. 선언적 스타일의 SwiftUI는 이런 도구들과 훨씬 자연스럽게 맞아떨어지기 때문입니다. 지금은 리멤버 앱에서 SwiftUI를 적극적으로 사용하고 있지만, 여기까지 오는 과정은 결코 단순하지 않았습니다. 이 글에서는 리멤버 iOS챕터가 SwiftUI를 도입하며 마주친 허들들과, 그것을 하나씩 넘겨온 과정을 공유합니다. 위젯이라는 작은 영역에서 시작해 전체 화면을 SwiftUI로 구현할 수 있게 되기까지의 과정을 총 5단계로 나눠 이야기합니다. 1단계. 위젯 — 리스크 없는 첫 시작 Remember Card Camera Widget 가장 간단하게 SwiftUI를 적용해볼 수 있는 곳은 어디일까요? 앱 본체와 완전히 분리된 위젯 Extension이라고 생각합니다. UIKit 코드베이스와 충돌할 일이 없고, 잘못되더라도 앱 본체에 영향을 주지 않습니다. iOS 14에서 WidgetKit이 등장하면서 위젯은 SwiftUI만으로 작성해야 했고, 자연스럽게 SwiftUI를 접하는 첫 창구가 되었습니다. 제가 합류했을 때 이미 커뮤니티 베스트글 위젯이 있었는데요, 2020년 당시 iOS챕터에서 SwiftUI를 써보고 싶어서 만들어진 위젯이라고 전해들었습니다. 거기에 어느 날, 고객 VoC에서 출발한 아이디어이기도 했던 명함 촬영 바로가기 위젯을 개인적인 호기심으로 직접 만들어봤습니다. Remember Card Camera Widget VOC 당시 리더분의 적극적인 지지 덕분에 실제 배포까지 이어졌습니다. Remember Card Camera Widget Making Messages 이미지 하나를 탭하면 명함 촬영으로 바로 연결되는 단순한 위젯이었습니다. 말 그대로 발만 살짝 담가보는 단계였습니다. 그 작은 경험이 SwiftUI와의 첫 개인적인 만남이 되었습니다. Remember iOS Widgets @main struct RememberWidgetBundle: WidgetBundle { var body: some Widget { RememberCardCameraWidget() // 명함 촬영 위젯 RememberCommunityWidget() // 커뮤니티 베스트글 위젯 } } 2단계 . 셀 — UIKit 화면에 SwiftUI 뷰 심기 위젯으로 감을 잡았다면, 다음 질문은 “UIKit기반 위에 SwiftUI를 어떻게 넣을 수 있을까?”였습니다. UIHostingController를 사용하면 된다는 것은 알지만, 실제로 부딪혀보기 전까지는 어디서 어떻게 시작해야 할지 막막했습니다. 2-1. SwiftUI 탐색 — “제 이력서에 ‘SwiftUI 도입’을 작성하고 싶었습니다” 챕터 내에서 SwiftUI 도입에 대한 공감대는 있었습니다. 하지만 저는 SwiftUI를 써본 적이 없었기에 궁금하기도 했고, 직접 써보고 싶다는 마음에 리멤버 iOS 앱의 공지사항 목록 화면을 SwiftUI로 시행착오를 겪으며 만들어봤습니다. 셀을 SwiftUI로 감싸는 시도도 해보고, 전체 화면을 SwiftUI로 만든 다음 VIPER 아키텍처와 연결해보는 시도도 했는데, UIKit과 SwiftUI의 경계를 어디에 그어야 할지 감이 잡히지 않아 어색했

  2026년 3월 24일

• “AI로 얼마나 빨리 만드나?” Amazon Q와 ‘팀딸깍’의 해커톤 다작 도전기(2)

  그림 1. 특별상 받은 ‘팀 딸깍’ 인원들 안녕하세요! 리멤버 개발실 백엔드팀 이형로입니다. 지난번 ‘네이버 웍스 메일 가드’ 이야기에 이어, 저희 ‘팀딸깍’이 [제1회 리멤버 사내 해커톤]에서 벌인 또 다른 도전기를 들려드리려고 합니다. 혹시 기억하시나요? 저희 팀의 모토! “AI로 얼마나 빠르게 많은 문제들을 해결할 수 있을까?” Amazon Q를 마음껏 쓸 수 있다는 엄청난 기회 앞에서, 저희는 ‘다작(多作)’ 전략을 밀어붙였습니다. 해커톤 기간 동안 3개의 프로젝트 완성을 목표로 달렸습니다. 오늘은 그중에서도 저희 팀이 가장 집중했던 프로젝트인 ‘AI 모의 면접’ 솔루션 개발기를 풀어보겠습니다. ‘네이버 웍스 메일 가드’나 ‘편리한 공고 검색’도 의미 있었지만, 이 프로젝트는 저희에게 특별한 의미가 있었습니다. 바로 ‘딸깍’이라는 저희의 단순한 철학이 가장 복잡하고 야심 찬 과제까지 해결할 수 있는지 증명해 볼 수 있는, 최고의 시험대였기 때문입니다. “이력서는 냈는데… 뭘 물어볼지 감도 안 잡힌다.” 이직이나 취업 준비, 해보셨다면 누구나 공감할 겁니다. 서류 합격의 기쁨도 잠시, 면접이라는 큰 산 앞에서 막막함을 느끼는 순간 😵‍💫 “내 경력에서 뭘 중요하게 볼까?” “이 회사, 이 직무에서는 어떤 질문이 나올까?” “내 답변, 이대로 괜찮은 걸까?” 이런 고민들로 예상 질문을 찾고, 답변을 다듬는 데만 평균 3–4시간 이상이 소요됩니다. (물론 이건 공인된 통계가 아니라, 저희 팀원들의 경험에 기반한 추측이자 가설이라는 점을 말씀드립니다.) 하지만 그렇게 찾은 정보는 너무 일반적이거나, 내 상황과는 동떨어진 경우가 대부분이죠. 객관적인 피드백은 꿈도 꾸기 어렵고요. ‘팀딸깍’은 바로 이 비효율적이고 어려운 면접 준비 과정을 혁신하기로 했습니다. 3–4시간의 삽질, ‘개인 AI 면접관’ 고용으로 끝내기 🤖 그림 2. 개인 AI 면접관을 고용하기 위한 첫 화면 방금 고용한 AI 면접관, 스펙은 이렇습니다! (핵심 기능) 단순히 질문만 던지는 챗봇이 아닙니다. 진짜 면접관처럼, 여러분의 맥락을 이해하고 핵심을 짚어냅니다. 개인화 질문 생성: 여러분의 이력서와 지원하는 채용 공고를 동시에 분석합니다. 두 문서를 교차 분석하여, 여러분의 경험과 해당 직무의 핵심 역량을 검증하는 날카로운 맞춤 질문과 그 ‘숨은 의도’까지 생성해 줍니다. (더 이상 “당신의 강점은 무엇인가요?” 같은 질문에 시간을 낭비할 필요가 없습니다.) 족집게 AI 피드백: 생성된 질문에 답변을 입력하면, AI가 답변의 논리성, 직무 적합성 등을 다각도로 분석합니다. ‘강점’, ‘개선할 점’, 심지어 ‘모범 답안 예시’까지 제공하여, 막연한 연습이 아닌 데이터 기반의 실력 향상을 가능하게 합니다. 어떻게 면접 준비를 도와주나요? AI 면접관과는 이렇게 면접을 준비하게 됩니다. 바로 한번 보시죠. 그림 3. 이력서 및 채용공고 정보 업로드 및 면접 방식 선택 화면 정보 입력: 웹 화면에 이력서(텍스트 or 파일)와 채용 공고(텍스트 or URL)를 입력하고 ‘면접 시작’ 버튼을 누릅니다. (면접은 텍스트, 음성 두가지 방식으로 진행이 가능합니다) 그림 4. 생성된 면접 질문 및 질문 의도 확인 화면 질문 생성: 잠시 기다리면, AI가 여러분만을 위한 질문 목록과 각 질문의 의도를 화면에 보여줍니다. 질문: 이전 직장에서 비효율적인 프로세스를 개선한 경험이 있나요? 어떤 문제를 해결했고, 어떤 방식으로 접근했는지 말씀해주세요. 질문 의도: 지원자의 문제 해결 능력과 개선 의지를 확인하고자 합니다. 어떠신가요? 저희는 꽤 날카롭고 실제 받을 만한 면접 질문이라고 생각합니다. 답변 입력: 질문과 의도를 확인하고, 실제 면접처럼 답변을 텍스트 또는 음성으로 입력하여 제출합니다. (저는 테스트 삼아 간단하게만 적어봤습니다.) 그림 5. 질문에 대한 답변 피드백 화면 피드백 확인: 답변 제출 후, AI가 분석한 상세 피드백이 화면에 나타납니다. 보이시나요? 제 테스트 답변에 다음과 같이 피드백을 주었습니다. - 강점: 답변에서 이전 직장에서의 비효율

  2025년 11월 11일

• 개발자가 개발을 안하는 세계에서..

  안녕하세요, 저는 리멤버앤컴퍼니에서 웹 프론트엔드팀 및 채용혁신 크루에서 프론트엔드 개발자로 일하고 있는 김승모입니다. 10.17 AWS Korea의 트레이닝 룸에서 리멤버의 첫 해커톤을 진행하게 됐는데요. 그 과정에서 저희팀이 AI로 어떻게 한달동안 프로덕트를 만들었는지에 대해서 공유드리고자 이 글을 작성합니다! 1. 그 시작 TMI지만 저는 취업준비생일때 구름톤이라는 해커톤에서 최우수상을 받았었던 경험이 있는데요. 3박가량 거의 잠 없이 개발했지만 너무 재밌었던 경험이 있었습니다. 그리고 저는 AI로 어떻게 팀 생산성이 늘어날 수 있을까에 대한 고민이 많은 엔지니어에요. 그러 던 중 사내에 해커톤-팀빌딩 채널이 개설되고 팀을 구하거나 사람을 구하는 활동이 일어났습니다. 저는 당시 입사한 지 2개월정도 밖에 되지 않았던터라 현재 업무에 적응해야하는것에 가장 큰 의무감을 갖고 있었고 참여를 고민했었는데요. 하지만 옛날에 최우수상을 받았던 그 도파민을 다시 느끼고 싶었기도 했습니다. 그래서 저는 저를 갈아넣더라도 두가지 토끼를 다 잡아보고 싶었고 마침 저희 크루에서 해커톤을 나가보자고 제안주셔서 팀 고진감랩에 합류하게 됐습니다. 그렇게 약 한달동안 개발한 후 당일에 발표와 결과물을 통해 수상을 하는 해커톤의 여정이 시작됐습니다. 2. AI 컨셉에 과몰입하기 저희 팀의 컨셉은 AI에 과몰입하기였습니다. 저희 팀의 구성은 PM(1), Designer(1), Frontend Developer(2)였는데요. 다른 어떤 팀들보다 AI를 효율적으로 활용해서 효율을 높여, 거기서 벌어들인 시간으로 각자 하지 않았던 업무를 해보게 됐습니다. 즉 디자이너가 기획을, PM이 개발을, 두명의 프론트엔드 개발자가 기획을 보조하고 에이전트를 구축하는 롤을 갖게 됐습니다. 그리고 우리가 프로토타입의 퀄리티를 높이기 위해서 그 무엇이든 할 수 있고, 그 과정에서 사용할 수 있는 AI를 적극적으로 활용해보기로 했습니다. 세어보니 총 10가지를 사용했네요.(Figma MCP, Figma AI, Amazon Q Developer, Amazon Bedrock, ClaudeCode, UXPilot, V0, Perplexity, Clova, LLM들) 아이디어 구상도 AI를 활용해보자 아이디어 구상도 AI를 활용해 봤는데요. 각자의 아이디어를 가져와서 어떤 제품을 만들어볼지에 대한 회의 시간이 있었고 저는 V0라는 UI자동 생성 및 배포 플랫폼을 활용해서 제 아이디어를 프로토타이핑 했습니다. 결과물 나쁘지 않을지도? 다른 분들도 Gemini의 Canvas를 활용해 프로토타이핑을 화면에 바로 렌더해서 이를 공유하셨습니다. ex: Gemini Canvas로 계산기 앱 만들기 이렇게 시작부터 AI를 활용했는데요. 어떻게 이 AI들을 활용해서 제품을 만들었는지에 대한 얘기는 챕터3 쉿, 개발중에서 이어서 작성해보려 합니다. 3. 쉿, 개발중 그래도 나름 AWS에서 엠배서더를 하고 있고 제가 당연히 해야 할 영역이 Agent개발이라고 생각했습니다. 첫번째 레슨: 바이브 코딩 환경 제공하기 저는 개발자가 아닌 사람이 바이브코딩 하는건 가능하지만, 바이브코딩을 할 수 있는 환경의 퀄리티를 높여주기 위해선 개발자의 경험과 도움이 꼭 필요하다고 생각했어요. 그래서 저는 개발자가 큰 관점에서 두가지의 역할을 해야한다고 생각했습니다. 비개발자가 바이브코딩을 할 수 있는 환경을 제공하기 AI에 익숙해질 수 있는 문화를 만들기 비개발자가 바이브코딩을 할 수 있는 환경을 제공하기 첫번째 문제를 해결하기 위해서 저를 포함한 프론트엔드 개발자 2명이 초기 개발 세팅을 도와드렸습니다. (스크립트 딸깍하면 누구든지 바이브코딩할 수 있는 환경을 만들고 싶었습니다 원래는 ㅠㅠ) 그리고 실제로 바이브코딩 할 수 있는 환경을 제공해드리기로 했는데요. 첫번째는 Rules입니다. Amazon Q Developer 내 GUI IDE에서 Rules버튼을 클릭하면 내가 원하는 Rules들을 추가해줄 수 있는데요. 이는 LLM에서 시스템프롬프트와 유사하다고 생각하면되고, git으로 추적 가능한 md파일

  2025년 11월 4일

• “AI로 얼마나 빨리 만드나?” Amazon Q와 ‘팀딸깍’의 해커톤 다작 도전기(1)

  안녕하세요! 리멤버 개발실 백엔드팀 이형로입니다. 얼마 전, 저희 리멤버에서 [제1회 사내 해커톤]이 열렸습니다. (두둥!) 이번 해커톤에는 아주 특별한 점이 있었습니다. 바로 AWS 의 credit 지원을 받아 Amazon Q를 거의 무제한으로, 마음껏 사용할 수 있다는 점이었죠! (이런 기회, 못 참죠. 😉) “AI로 얼마나 빠르게 문제들을 해결할 수 있을까?”라는 궁금증과, “Q를 공짜로 맘껏 써볼 수 있다!”는 설렘이 합쳐져… 저희 ‘팀딸깍’이 탄생했습니다. 네, 이름 그대로 ‘딸깍’하면 AI가 다 만들어주는 걸 꿈꿨습니다. 🤣 그래서 저희의 해커톤 전략은 ‘다작(多作)’! 해커톤 기간동안 3개의 프로젝트를 진행하여 제출하기로 했습니다. 저희는 ‘업무와 커리어에서 겪는 비효율적인 순간들’이라는 공통의 주제 아래, 세 가지 구체적인 키워드로 문제를 정의했는데요. 바로 ‘한순간의 실수’, ‘답답한 검색’, 그리고 ‘막막한 면접 준비’였습니다. 오늘은 그 3개의 프로젝트 중, 저희의 아찔한 ‘한순간의 실수’ 키워드를 해결하기 위해 만든 ’네이버 웍스 이메일 가드’ 이야기를 들려드릴게요. “큰일 났다. 참조에 100명 넣고 보냈다.” 혹시 이런 상상, 해보셨나요? 중요한 공지사항을 여러 고객사 담당자님께 한 번에 보내려는데… 그만 ‘숨은 참조(BCC)’가 아니라 ‘참조(CC)’에 모든 분을 넣고 ‘보내기’ 버튼을 클릭하는 순간. 생각만 해도 아찔합니다. 😱 참조’에 걸린 모든 분이 서로의 이메일 주소를 확인하게 되는, 그야말로 ‘개인정보 유출 사고’가 터지는 거죠. 저희 ‘팀딸깍’은 바로 이 문제를 풀기로 했습니다. “조직원의 실수로 치부할것이 아니라, 실수가 일어나기 직전에 시스템이 막아주자!” 그래서 탄생했습니다. “이메일 안전 가드” 이 친구의 임무는 단 하나입니다. “사용자가 개인정보 유출 실수를 저지르기 직전, 무조건 한 번 더 생각하게 만든다!” 그래서, 어떻게 막아주나요? (핵심 기능) 무작정 모든 메일을 막으면 오히려 업무가 불편해지겠죠. (해커톤에서 그런 걸 만들면 감점이 되겠죠!?😆) 그래서 딱 필요한 순간, 즉 ’사고 위험이 높은 순간’에만 경고창이 뜨도록 설계했습니다. ‘보내기’ 버튼을 누를 때, ‘받는사람(To)’과 ‘참조(CC)’를 검사해서 아래 두 가지 조건 중 하나라도 해당하면 즉시 경고창을 띄웁니다. (해커톤이 끝나고 버전이 업그레이드 됐어요 🤣) ‘도메인 혼용’ 감지: 사내 도메인을 제외한 서로 다른 외부 도메인이 2개 이상 포함된 경우 ‘외부 개인 메일’ 감지: gmail.com, naver.com, daum.net 등 주요 개인 메일 주소가 2명 이상 포함된 경우 즉, 내부 직원끼리만 보내거나, 특정 고객사 1곳의 담당자 여러 명에게 보내는 건 통과! 하지만 여러 고객사나 불특정 다수에게 보낼 위험이 있는 메일은 정확하게 잡아냅니다. 어떻게 실수를 막아주나요? (3중 안전장치) 말로만 설명하면 감이 안 오시죠? 그럼 저희가 만든 ‘이메일 안전 가드’, 어떻게 생겼는지 살짝 보고 가실까요? 만약 위 조건에 해당하는 위험한 메일을 발송하면, ‘보내기’를 누르는 즉시 이런 경고창이 뜹니다. 경고창이 활성화 된 화면 [이대로 발송] 버튼은 아예 비활성화되어 있습니다. 실수로 ‘Enter’ 키를 누르거나 마우스를 잘못 클릭해도 메일이 발송되지 않죠. 만약 정말로 위험을 인지했고, 그럼에도 불구하고 ‘참조’로 보내는 것이 맞다면, 직접 체크박스를 클릭해야 합니다. ‘이대로 발송’ 버튼 활성화 화면 ‘이대로 보내도 문제가 없습니다.’라는 문구를 직접 체크해야만 [이대로 발송] 버튼이 활성화됩니다. 이 ‘귀찮은’ 3중 안전장치 덕분에, 사용자는 발송 전에 최소한 한 번은 더 생각하게 되고, ‘아차!’ 싶으면 [다시 확인]을 눌러 ‘숨은 참조’로 수정할 기회를 얻게 됩니다. “팀딸깍”이 3개나 만든 비결? (feat. Amazon Q) 어떻게 저희가 해커톤 기간에 3개나 되는 프로젝트를 만들었을까요? (짧은 시간은 아니였지만!?) (속닥속닥) 네, 저희 팀 이름(‘팀딸깍’)이 스포일러였

  2025년 10월 29일

• 제1회 리멤버 사내 해커톤을 마치며

  제1회 리멤버 해커톤을 마치며 안녕하세요? 저는 리멤버에서 현재 제품 본부 소속의 개발실 리더 역할을 맡고 있는 이한별입니다. 지난 7월에 아무런 계획과 준비도 없이 덜컥 공지부터 내버리고 준비를 어떻게 해야 할 지 모르겠는 막막함과 걱정에 밤잠 설쳤던(사실은 잘 잤습니다) ‘제1회 리멤버 Gen AI 해커톤’이 지난 10월 17일, 정말 많은 분들의 열정과 열기 속에서 무사히 막을 내렸습니다. 7월 22일에 냅다 던진 해커톤 개최 공지 이런 행사를 주최해 본 경험이 전무했던 제가 AWS라는 멋진 파트너와 함께 50명이 넘는 규모의 행사를 치러내기까지, 그야말로 ‘우당탕탕’의 연속이었어요. 오늘은 이 과정에서 제가 느낀 점들을 공유해볼까 합니다. 재밌고 즐거운 시간을 보낸 해커톤 행사였던 만큼 이 후기 느낌의 글도 조금 가볍게 적어보았어요! 😆 1. 5분 발표? 10분도 모자랐던 열정의 현장 “제품과 사내 업무의 AI/LLM을 활용한 자동화”라는, 다소 딱딱할 수 있는 주제였지만 총 12개의 팀이 정말 멋진 아이디어들을 가지고 참여해 주셨습니다. 원래 계획은 팀당 5분의 짧은 발표였는데… 막상 시작을 해보니 거의 모든 팀이 7–8분을 훌쩍 넘겨 발표를 진행했습니다. 그런데, 상당한 노력과 시간을 들여 구현하고 발표도 준비해주셨기 때문에 진행자 역할을 맡은 제가 5분이 됐다고 딱 자를 수 없었습니다. 그리고 Q&A 도 팀당 3~4분 이상은 할애하는 것이 필요했습니다. 운영진 입장에서는 계획했던 시간이 밀리기 시작하며 살짝 당황스럽긴 했지만, 그만큼 모든 팀이 이 해커톤에 얼마나 진심이었는지, 자신의 아이디어를 얼마나 열정적으로 공유하고 싶어 했는지 느낄 수 있어서 오히려 감사한 시간이었습니다. (너그럽게 양해해주신 모든 분들께 감사를! 🙏) 발표를 마친 팀에게 질문을 하시는 심사위원 분들과 뒤에 서 있는 나(ㅋㅋ) 2. 반짝반짝 빛났던 12개의 아이디어, 그리고 수상팀! 제가 보았을 때 사실 12개 팀의 모든 아이디어가 당장 우리 제품에 적용하거나 베타 서비스를 시작할 수 있을 만큼 완성도가 있었고 훌륭했습니다. 심사위원분들께서 순위를 정하는 데 정말 오랜 시간 고심하셨을 정도였죠. 실제로 순위가 100점 만점 기준으로 0.5점 차이로 갈리기도 했습니다. 그 치열했던 경쟁 속에서, 영광의 수상팀을 소개합니다! 🥇 1등: 2pm 팀 🥈 2등: 미모사 팀 🥉 공동 3등: 고진감랩 팀, ai로운 팀 ✨ 공동 특별상 (AWS Q Developer 적극 활용팀): 팀 딸깍, 소금과후추 팀 수상하신 모든 팀에게 다시 한번 뜨거운 축하의 박수를 보냅니다! 👏👏 3등을 수상한 고진감랩 팀의 발표 3. 저의 우당탕탕… 겉보기엔 순조로워 보였을지 모르지만, 저에게는 식은땀이 흐르는 순간들이 있었습니다… (티가 많이 나서 겉보기에도 순조로워 보이지 않았을지도…) 아찔 모먼트1. 현장에서의 임기응변은 역시 쉽지 않아 심사가 끝나고 시상식 전까지, 수상팀의 이름과 팀원분들 성함을 예쁘게 만들어둔 슬라이드에 기입해야 했습니다. 1~3등에 특별상까지… 이걸 Amazon Q Developer 를 이용해 미리 만들어둔 프롬프트로 html 에 반영만 하면 되는 거였는데, 그런데 이게 웬걸? 심사 과정에서 계획에 없던 공동3등도 추가적으로 선정하기로 결정되었고, 제가 채점표를 잘못 보고 다른 팀 이름을 적었기도 했어서 정말 식은 땀이 났습니다… 팀 이름을 잘못 적으면 아주아주 큰 일이니까요. 다행히 제가 그렇게 당황해하고 있을 때 제 리더이시자 저희 CPO 께서 심사위원 분들 소개와 인삿말, CEO 의 소감 공유 시간 등을 진행해주시며 부족했던 제 시간을 확보해주셨어요. 😌 아찔 모먼트2. “3등팀은… 어? 어어…?” (수상팀 스포일러 발생) 그리고… 또 아찔했던 순간이 있었는데요. 수상팀을 한 팀 한 팀 발표하며 슬라이드 쇼를 넘겨야 했는데 실수로 클릭 한 번을 잘못 했더니, 3등 팀(고진감랩 팀)을 발표하기 전에 화면에 뿅 하고 나타나 버렸습니다. 😱 순간 머릿속이 하얘졌지만, 다행히 참가자분들 모두 못본 척해주시고 유쾌하게 웃어

  2025년 10월 19일

• 코드 한 줄로 경험하는 React 동시성의 마법

  안녕하세요! 리멤버앤컴퍼니 파운데이션 크루에서 Web Frontend Software Engineer로 일하고 있는 성정민입니다. 최근 저는 사용자가 검색창에 키워드를 입력할 때마다 실시간으로 UI를 업데이트하는 기능을 개발했습니다. 그런데 문제가 발생했어요. 검색창에 글자를 입력할 때마다 수천 개의 데이터를 필터링하고 화면에 표시해야 하는데, 이 과정에서 입력이 멈칫거리는 현상이 나타났습니다. 예를 들어, 사용자가 “안녕”을 입력할 때 “안”까지는 괜찮다가 “녕”을 입력하는 순간 브라우저가 잠시 멈추는 식이었습니다. 처음에는 이 문제를 어떻게 해결할지 고민하다가 React 18의 동시성 모드에서 소개된 useTransition API를 적용해보았습니다. 처음 적용했을 때는 "와, 이게 해결되네!" 싶었지만, 단순히 "마법"이라고 넘기기엔 궁금한 점이 많았습니다. 그래서 React의 내부 동작을 좀 더 깊이 들여다보며 이 기능의 원리를 제대로 이해하고 싶었고, 그 내용을 여러분과 함께 나누고자 합니다. React와 동시성 렌더링의 이해 리멤버의 웹 서비스는 대부분 React로 만들어져 있습니다. React는 2017년 Fiber 아키텍처를 도입한 이후로 Suspense, 동시성 같은 기능을 꾸준히 발전시켜왔고, 2024년엔 React Compiler라는 멋진 변화를 선보이기도 했죠. 오늘은 그중에서도 React 18의 동시성 기능과 이를 통해 UI를 최적화한 이야기를 해보려고 합니다. 동시성과 병렬성: 비슷하지만 다른 개념 동시성이란 무엇일까요? 단어 자체만 보면 여러 작업을 동시에 수행한다는 의미로 보입니다. 그렇다면 병렬성과 같은 개념일까요? 이 두 개념의 차이를 명확히 이해하는 것이 중요합니다. Go 언어 창시자의 Concurrency is not parallelism 발표에 따르면… “동시성은 독립적으로 실행되는 프로세스들의 조합이다.” “병렬성은 연관된 복수의 연산들을 동시에 실행하는 것이다.” “동시성은 여러 일을 한꺼번에 다루는 문제에 관한 것이다.” “병렬성은 여러 일을 한꺼번에 실행하는 방법에 관한 것이다.” 병렬성은 멀티 코어 환경에서 실제로 여러 작업이 동시에 처리되는 개념입니다. 반면, 동시성은 싱글 코어에서도 작동할 수 있으며, 여러 작업이 동시에 실행되는 것처럼 보이지만 실제로는 번갈아 가며 실행됩니다. 마치 여러분이 동영상을 보다가 코드를 작성하는 것처럼, 작업 간에 전환하면서 여러 일을 처리하는 방식이에요. 정리하자면, 동시성은 2개 이상의 독립적인 작업을 잘게 나누어 마치 동시에 실행되는 것처럼 프로그램을 구조화하는 방법입니다. React가 동시성을 도입한 이유: 브라우저의 렌더링 블로킹 문제 브라우저의 메인 스레드는 JavaScript 실행, DOM 조작, 스타일 계산, 레이아웃, 페인팅을 모두 담당하는 싱글 스레드로 동작합니다. 메인 스레드가 어떤 작업을 시작하면, 그 작업이 완료될 때까지 다른 작업을 수행할 수 없습니다. 일반적으로는 이것이 문제가 되지 않아요. React의 Virtual DOM과 diff 알고리즘이 매우 빠르기 때문이죠. 하지만 렌더링 과정이 길어지는 상황에서는 문제가 발생합니다. 예를 들어, 수천 개의 데이터가 있는 복잡한 목록을 필터링하거나 정렬할 때 화면이 버벅거리게 됩니다. 간단한 예를 들어볼까요? 아래 예제에서는 입력창에 글자를 입력할 때마다 입력된 글자 수의 비례해서 셀의 수가 증가하며 화면이 업데이트됩니다. https://medium.com/media/a4f61d912f663e645c3262694e15bff8/href 입력값이 적을 때는 문제가 없지만, 입력값이 늘어날수록 색상 목록과 사용자 입력의 렌더링 속도가 느려지는 것을 볼 수 있습니다. 이것이 바로 블로킹 렌더링입니다. JavaScript 연산이 길어지면서 프레임이 드롭되고, 사용자 입력은 뒤로 밀려나게 됩니다. 60fps로 부드럽게 동작해야 할 애니메이션이 끊기고, 버튼 클릭이나 입력이 지연되는 현상이 발생하죠. 전통적으로 이 문제는 디바운싱(debounce)이나 스로틀링(throttle)

  2025년 4월 16일

• 리멤버 개발실을 소개합니다

  안녕하세요? 저는 일하는 프로들과 비즈니스 기회를 연결하는 리멤버의 제품본부 개발실에서 리더 역할을 맡고 있는 이한별이라고 합니다. 😁 제가 리멤버에 합류한 지 5년이 지나가는데, 그동안 상당히 많은 제품 변화도 있었지만 저희 조직의 변화도 있었는데요. 이번 글에서는 그러한 변화들을 거쳐 온 현재의 개발실의 모습을 가볍게 소개드리고자 합니다. 매트릭스 조직 구조 오늘날의 리멤버의 제품본부는 매트릭스 조직 구조라고도 표현되는 조직 구조로 구성돼 있어요. 기능 조직(팀) 1개의 팀은 같은 직무를 가진 구성원들의 집합이에요. 현재 개발실에는 백엔드 팀, 웹 프론트엔드 팀, iOS 팀, Android 팀, DevOps 팀의 5개 팀으로 구성돼 있습니다. 목적 조직(크루) 1개의 크루는 Product Owner(PO), Product Manager(PM), Product Designer(PD), Quality Assurance(QA), Data Intelligence(DI), Software engineers(개발자) 가 서로 다른 직무를 가졌지만 하나의 목적을 공유하고 업무를 추진하는 조직이에요. 현재 리멤버 제품본부는 Foundation crew 채용혁신 crew 구직Wow crew 신사업 crew (리멤버 커넥트) 자소설 crew 이렇게 5개의 크루를 조직하여 운영하고 있어요. 크루는 회사의 상황에 따라 신규 결성이 되거나 목적이 바뀌는 것처럼 유연성을 갖고 있습니다. 한 개 크루에서는 평균적으로 15명의 동료들로 구성돼 있어요. 이렇게 매트릭스 조직구조로 돼 있는 것을, 개발실이라는 기능 조직 관점에서 도식화해보면 이런 모습으로 나타낼 수 있어요. 크루와 팀은 각각 목표를 설정하고, 업무를 진행하게 됩니다. 한 명의 개발자는 각 팀과 크루에 동시에 속해있다보니, 일하다 보면 우선순위 판단이 어렵거나 지금 해도 되는지와 같은 고민에 빠지게 되기도 하는데요. 조직 전체 차원에서 최대한 이 고민을 덜기 위해 시간 분배를 통해서 균형을 맞추고 있습니다. 균형을 맞추기 위한 여러 장치들이 있어요. 😉 개발실 분위기는 다양하고 많은 사람들이 모여있기 때문에 딱 “어떻다! 이렇다!” 라고 설명하기는 어렵지만 평상시의 대화들이 존중을 바탕으로 하는 수평적이에요. 직급이 없는데다 <Tech Lead> 나 <팀 Leader> 역할과 같이 직함이 있는 일부 동료들을 제외하면 주니어든 시니어든 따로 구분하지 않고 더 나은 방법을 찾으면서 일하고 있어요. 즉, 좀 더 경험이 많다고 해서 그 분의 의견이 무조건 맞다고 고집 부리지도 않고, 경험이 좀 더 부족한 분이 내린 의사결정에 대해서도 한 번 내린 결정이라면 다른 동료들도 스스로 얼라인할 줄 알고 따르는 분위기랄까요? 그런 존중과 신뢰 기반으로 논의를 하고, 대화를 합니다. 어떤 사람들이 있나요? 개발자들이 하는 업무는 “문제 풀이" 라고 표현하고 싶습니다. 문제 풀이에서 나오는 문제들은 항상 쉽지만도, 항상 어렵지만도 않은데요. 그렇지만 어려운 문제를 풀어야 할 때는 지치기도 하고, 힘들기도 합니다. 저는 개인적으로 이 과정속에서 어떻게든 해내고야 말겠다는 긍정적인 사고방식을 가지신 분들이라면 이 문제 풀이에 유리함을 가졌다는 견해를 갖고 있는데요. 저희 리멤버 개발실에는 모두 이런 긍정적인 사고방식을 가지신 분들로 구성돼 있다고 자신있게 말씀드릴 수 있습니다. 이러한 표현이 <어떤 사람들이 있는지?> 에 대한 속 시원한 답은 안 될 거란 걸 알기에 몇몇 개발실 동료분의 특징들도 남겨놓아 봅니다. 🙂 개발 서적 출판한 사람 오픈소스 Contributor 글로벌 기업 출신 이모지(emoji) 장인 일하는 방식 말로 설명하기보다는 그림으로 보여드리는 것이 더 이해하기 좋을 것 같아 그림 그리는 것에 전혀 재능이 없지만 용기내 그려서 설명드려 보겠습니다. 리멤버 개발실에서 일하는 개발 파이프라인 우선, 위 그림과 같은 순서대로 일이 만들어지고, 개발을 진행하게 됩니다. 그림에서는 다 표현못하는 중간중간 커뮤니케이션이라든지, 다른 프로세스들(like 회고, A/B테스트, 성과 측정 후

  2025년 3월 24일

• 사용자 모르게 리멤버 UI icon 개선하기

  배경 2022년 리멤버 리브랜딩 리멤버는 2022년 7월 ‘기회가 열린다, 리멤버’라는 슬로건과 함께 명함 앱을 넘어 비즈니스의 다양한 기회가 열리는 직장인 슈퍼앱으로 나아가고자 리브랜딩이 진행되었습니다. 이 과정에서 리브랜딩 심볼의 큰 변화가 있었는데요. 명함을 연상시키는 기존 사각형을 벗어나 다양한 기회가 열리는 ‘문’을 형상화한 스퀘어로 진화했고, 이 스퀘어가 리멤버 R의 한 획을 받쳐주면서 대표성 있는 새로운 심볼로 탄생하게 되었습니다. 리멤버 심볼 리멤버 스퀘어는 서비스 곳곳에 반영이 되었고, UI icon에도 역시 리멤버 스퀘어가 적용이 되었습니다. 리브랜딩과 함께 개발된 UI icon은 기존의 Material design을 참고하여 디자인 된 ver1의 아이콘보다 확실한 개성을 가진 형태로 완성되었습니다. 리멤버 UI icon ver 1.5 리브랜딩과 함께 새롭게 만들어진 ver1.5의 리멤버 UI icon은 Filled type의 아이콘이라는 점과 모서리의 깎임 효과 그리고 -3°의 기울임이라는 큰 특징들이 있었습니다. 각각의 특징 역시 리멤버 스퀘어라는 메타포에서 가져온 특징으로 리멤버의 브랜드 아이덴티티를 시각화 하는데 있어 두드러지는 포인트라고 볼 수 있었습니다. 새롭게 제작된 UI icon은 2022년 7월 리멤버 서비스 전체에 적용되었습니다. 그런데 문제가 있었습니다. Filled 타입과 Outline 타입의 밸런스 차이 ver1.5의 아이콘은 Filled 타입을 기본으로 디자인 되었습니다. 그러나 Filled 타입으로 표현할 수 없는 아이콘이 존재하기도 하는데요. Fill type과 Outline type이 혼재되었던 as-is 동일한 영역에 Filled 타입과 Outline 타입의 아이콘이 함께 사용되면 같은 아이콘 셋트임에도 불구하고 밸런스 차이가 나다보니 하나의 아이콘 셋트처럼 보이지 않는 문제가 있었습니다. 아이콘이 찌그러져 보여요 아이콘들 자체가 -3°의 기울임과 모서리 깎임 효과들이 적용되어 있는데, 사용자 눈에는 의도된 디자인이 아니라 잘못된 형태로 인지되기 시작했습니다. 가령 네비게이션 아이콘의 기울여진 각도가 아이콘이 잘못 틀어져 있다고 인지한다던가 작은 사이즈의 Filled 타입 아이콘의 모서리가 깎인 부분을 사용자는 찌그러진 형태로 본다던가 하는 부분이었습니다. 새로운 아이콘이 적용된 서비스의 배포 비율이 올라가면서 관련 VOC도 증가하기 시작했습니다. UI icon을 만드는데 너무 많은 시간이 필요해요 as-is 아이콘 제작 프로세스 유저들의 사용성 문제 외에도 또다른 문제가 있었습니다. 새로운 기능들이 생기다보면 기존의 아이콘이 아닌 새로운 아이콘이 추가로 필요할때가 있는데요. 새로운 아이콘들은 가이드에 맞춰 제작하면 되는데 이 가이드가 너무나 복잡하고 번거로운 과정들을 거쳐야 하는것이 문제였습니다. 아이콘을 제작하기 위해서는 Figma에서 아이콘의 원형을 그린 후 Adobe illustrator의 아이콘 가이드 파일로 옮겨 모서리를 깎고 -3°의 기울임을 준 뒤 SVG로 내보내야 합니다. SVG 파일을 다시 Figma의 디자인 시스템에 등록하고, 작업중이던 화면에 적용해야 비로소 아이콘 1개의 제작이 완료되는 과정이었습니다. 개선 방향 폰트와 UI icon의 상관관계 UI icon을 개선하기에 앞서 중요한 두가지를 먼저 짚고 넘어가야 했습니다. UI icon이 어떤 환경에서 쓰이는지 다시 생각해보자 UI icon의 기능적인 역할을 충실히 하면서도 리멤버 브랜드 가치를 담을 수 있는 방향을 고민하자 UI icon은 대부분의 화면에서 폰트와 함께 사용됩니다. 리스트라던지 버튼이라던지 앱바와 탭바를 제외하면 대부분 폰트와 함께 나열되어 사용된다고 봐도 될 정도이기 때문에 폰트와의 밸러스가 매우 중요해 집니다. 브랜드를 설명할 수 있는 요소들은 심볼도 있겠지만 서비스 전반에 사용되는 컬러, 폰트 또한 브랜드를 설명할 수 있습니다. 게다가 아이콘은 대부분 폰트와 함께 사용될테니 리멤버 브랜드 가치가 담긴 폰트와 닮은 아이콘을 만드는것이 가장 적절하다고 판단했습니다. 이미 다

  2025년 2월 20일

• 리멤버에서 UT(사용자 테스트)는 어떻게 진행하나요?

  안녕하세요. 리멤버 프로덕트 디자이너 김희경입니다. 명함관리 서비스로 시작해 구인구직 서비스와 직장인 커뮤니티 서비스, 데일리 뉴스 콘텐츠까지 직장인을 위한 다양한 서비스를 리멤버에서 제공해왔는데요. 이 모든 서비스를 한 화면에서 경험할 수 있는 새로운 화면을 신설하기에 앞서 사용성 테스트(Usability Test)를 진행했었어요. 새로운 피쳐가 배포되기 이전에 사용성 테스트를 진행하며 경험한 UT 설계와 모더레이팅 과정에서 느낀 인사이트를 공유드릴게요. UT(사용성 테스트)는 언제 진행하나요? UT 즉 사용성 테스트는 신규 기능을 기획하는 단계 또는 신규 기능을 론칭하기 전 실제 리멤버 사용자에게 보여드리면서 우리 생각대로 사용하시는지, 문제점은 없는지 검증하기 위해 진행합니다. 특히 이번처럼 첫 화면을 신규로 만드는 경우는, 기존 대비 사용자가 불편하게 느끼시는 부분은 없는지 사전에 확인하는 것이 매우 중요했어요. UT 설계 UT는 ‘설계가 80%다.’라는 생각이 들 정도로 설계 과정이 매우 중요하다고 생각해요. UT 대상자는 누구를 어떤 과정으로 모집할 것인지, 인터뷰는 온라인으로 할 것인지, 오프라인으로 할 것인지, 인터뷰 관찰자는 어떤 방식으로 참여할지 등등 준비할 것이 생각보다 많았습니다. 그럼 어떤 순서와 과정을 거쳐 UT 설계를 했었는지 알려드릴게요. 01. 인터뷰 대상자 선정 사용자 행위에 영향을 미치는 조건을 리스트업 합니다. 우리 서비스를 사용한 기간이 얼마나 되었는지 그중 어떤 서비스를 중점적으로 사용하는지 우리 서비스를 방문하는 주기는 어떻게 되는지 IT 기기 조작이 익숙한 사람인지 조건에 따라 사용자군을 나누기도 하고 하나의 사용자군을 대상으로 인터뷰를 진행할 수 있습니다. 이번 인터뷰에서는 사용자 행위에 따라 군을 나누어, 총 4개의 사용자군을 대상으로 인터뷰를 진행했어요. 02. 인터뷰 대상 리크루팅 우리가 선정한 대상자들에게 인터뷰 정보를 안내하고 모집합니다. Tally를 활용해서 인터뷰 대상자에게 사용성 테스트 요청을 진행 인터뷰 환경 안내 : 온라인인지 오프라인인지 일정 스케줄링 : 가능한 날짜와 시간을 모두 받은 뒤 스케줄 조정 후 안내 인터뷰 동의 항목 안내 및 동의 받기 인터뷰 사례금 안내 인터뷰 모집에 응답을 주신 분들 중에서 직무나 추가 조건 및 다양성을 고려하여 인터뷰 대상자를 선정했습니다. 03. 역할 분담 이번 인터뷰는 신규 피처를 함께 기획했던 PO와 PD가 협업하여 진행했으며 아래의 역할을 나눠 UT를 준비했습니다. 인터뷰 설계 및 모더레이팅 인터뷰 대상자 리쿠르팅 및 사례금 지급 담당자 서기, 관찰자 04. Task 작성 사용자 인터뷰 진행에 사용되었던 Task 초안 사용성 테스트를 통해 확인하고 싶은 내용을 중심으로 Task를 설계하고 성공 기준과 실패 기준을 정합니다. 신규 화면에서도 기존에 자주 사용하던 기능을 빠르게 찾을 수 있는지, 몰랐던 기능들을 어떻게 인지하고 사용하게 되는지 등 검증하고 싶은 내용을 플로우 별로 나누고 Task와 질문을 작성했습니다. 실제 인터뷰에서는 사용자군에 따라 Task의 순서를 변경하고 자연스러운 진행을 위해 사용자에게 몰입할 수 있는 시나리오와 함께 Task를 안내했습니다. 05. 프로토타입 준비 인터뷰에서 검증하고 싶은 가설을 확인할 수 있는 형태로 프로토타입을 준비합니다. 참고로 모든 기능이 동작하지 않아도 됩니다. 이번에는 인터뷰 대상 사용자군 별로 Task를 진행할 수 있는 프로토타입을 준비하고, Task 내용에 따라 프로토타입 접속 계정도 다르게 세팅하여 인터뷰 대상자에게 제공했습니다. 06. 리허설 진행 실제 환경과 동일한 환경을 조성하고 사내에서 인터뷰 대상자를 1명을 선정하여 진행했습니다. 이때 관찰자로 디자인팀 동료들을 초대하여 인터뷰 과정을 지켜보고 이후 피드백을 받았습니다. 피드백을 바탕으로 인터뷰 대본 수정과 Task의 추가 질문들을 수정하여 실제 인터뷰를 진행하게 되었습니다. 실제 인터뷰를 진행하기 전 리허설 인터뷰는 필수로 진행하는 것을 추천해요. 예상하지 못한 현장에서의 변수들을 확인할 수 있고

  2025년 2월 17일

• RDS MySQL에서 RDS Aurora로 DB이전 다운타임 최소화 하기

  얼마 전 저희 리멤버 의 DB서버 이전이 있었습니다. 기존엔 AWS RDS에서 MySQL을 사용하고 있었으나 AuroraDB로 서버 이전을 하였고, 손쉽게(?) 작업을 마무리 할 수 있었습니다. 이전을 할 때 데이터 소실없이 이전 하는 것이 첫 번째로 중요했고, 두 번째로 중요했던 건 서비스의 다운타임을 최소화 하는 것 이었습니다. 첫 번째로 중요했던 데이터의 소실 없이 이전 하는건 철저한 검증을 통해 확인과 복원을 하면 되었지만, 두번째 중요했던 다운타임 최소화 문제는 조금 난감했습니다. DB이전과 함께 여러가지 밀려있던 작업을 위해 주말 새벽 5시간의 서비스 다운타임을 이용자들에게 공지했고, 저희는 이 시간 안에 예정된 모든 작업을 끝내야 했습니다. 결과적으로 공지 했던 시간 보다 2시간을 단축해 3시간만에 모든 작업을 끝낼 수 있었습니다. DB이전 작업엔 거의 시간이 들지 않았으니까요. DB이전을 할 때 다운타임을 최소화 하기 위한 방법은 놀라울 정도로 간단합니다. RDS MySQL의 최신 스냅샷을 Migrate기능을 이용해 AuroraDB로 이전 Migrate하는 동안의 데이터 변경분처리. (AuroraDB를 Replica server로 활용) 각 Applications에서 DB Endpoint를 AuroraDB의 Endpoint로 변경. 참 쉽죠? 2번에 대해 좀 더 정리해보자면, AuroraDB가 migrate되는 시간 동안 기존에 사용하던 MySQL DB에는 계속 데이터가 변경되고, 쌓여가고, 사라지고 있을 겁니다. Migrate하는 시간 동안의 데이터 Gap은 AuroraDB의 Migrate작업이 완료 된 후 이를 MySQL Master DB의 replica server화 하여 두 서버간 데이터의 동기화 합니다. 사실, AWS에서 이러한 방법에 대해 도큐먼트를 제공하고 있긴 하지만 자세한 방법까지는 다루고 있지 않기 때문에 이 글에서는 조금 전 설명드린 과정에 대해 그 방법을 풀어 볼 생각입니다. 0. 시작하기 전에 본격적으로 서버 이전을 진행하기 전에 RDS의 MySQL에서 한 가지 설정을 바꿔주고 시작 해야 하는데, “binlog retention hours”라는 RDS의 configuration 값을 바꿔 주어야 합니다. AWS Console의 Parameter Groups의 항목이 아니기때문에 브라우저가 아닌 터미널을 열어서 MySQL에 Master계정으로 접속을 해 주세요. RDS MySQL은 기본적으로 binlog를 삭제하는 주기가 빠르기 때문에 AuroraDB에 Migrate하는 동안의 binlog는 기록되어 보관될 수 있도록 설정 값을 바꿔야합니다. 아래와 같은 프로시저를 호출 해주세요. call mysql.rds_set_configuration(‘binlog retention hours’, 48); 혹시나 하는 마음에 binlog 보관 주기를 48시간으로 설정 했지만 24시간이면 충분 할 것 같습니다. 위 설정을 변경하기 전 스토리지가 충분한지 확인 후 변경하시기 바랍니다. 1. AuroraDB 인스턴스 생성 우선 AuroraDB의 인스턴스를 생성해 보겠습니다. 생성 시 기존에 사용하던 MySQL Master DB의 최신 Snapshot을 이용해 AuroraDB로 Migrate합니다. MySQL MasterDB를 선택하고, 상단의 Instance Actions탭에서 “Take Snapshot”을 눌러 현재 시점의 스냅샷을 준비해주세요. 스냅샷이 준비되었다면, “Migrate Latest Snapshot”를 눌러줍니다. 다음과 같은 화면이 나오면 기본적인 설정을 해 줍니다. 기존 MySQL Master DB의 설정을 따라가기 때문에 DB Instance Identifier와 Availability Zone지정 외에 별다른 작업이 필요 없을 것 같습니다. 자, Migrate버튼을 누르기 전에 이쯤에서 정말 중요한 메모를 하나 할 것입니다. 이 메모를 한 후 재빠르게 Migrate버튼을 눌러 AuroraDB인스턴스를 생성 할 겁니다. MySQL에 접속한 후 다음과 같은 명령어를 통해 bin

  2025년 1월 14일

이 블로그의 주제