브릭섬의 AI 시스템 이야기

AI시스템은 Production을 전제로 만들어야 한다 (Contexual AI CEO 강연 리뷰)

브릭섬 — Tue, 22 Apr 2025 13:32:18 +0900

요즘 AI 업계에서 ‘RAG’라는 말을 자주 듣는다. Retrieval-Augmented Generation, 검색 기반 생성 모델이라는 뜻인데, 막상 실전에서 이걸 직접 구현해본 사람은 많지 않다. 이번에 본 Contexual AI CEO의 유튜브 강연은 꽤 인상 깊었다. Meta와 Hugging Face에서 이름을 알린 연구자이자, 현재는 Contextual AI의 CEO인 Douwe Kiela가 직접 자신의 경험을 바탕으로 RAG 시스템 구축에 필요한 현실적인 조언들을 들려주었다. 그는 Meta 시절, RAG 기술을 개발한 주역이었고, 지금은 스탠퍼드에서 겸임 교수로도 활동 중이다. 2023년에 창업한 Contextual AI는 설립 1년 만에 약 1억 달러를 유치했고, HSBC, Qualcomm 같은 대기업을 고객으로 두고 있다.

Contextual AI CEO 가 말하는 10가지 교훈

1. RAG는 단순한 LLM과 DB의 조합이 아니다.

RAG를 단순히 LLM의 동작으로만 이해하는 사람들이 많다.하지만 Douwe는 RAG는 결국 시스템으로 동작한다. LLM의 추론과 단순한 RAG 검색 정확도만으로는 부족하다. 인덱싱, 리랭킹, context window 설계 등 모든 단계가 유기적으로 연결되어야 한다. 하나의 파이프라인으로서 작동해야 진짜 결과를 낼 수 있다는 이야기다.

2. 모델보다 중요한 것은 결국 데이터다

무슨 모델을 쓰느냐보다, 어떤 데이터를 얼마나 잘 준비하느냐가 훨씬 더 큰 영향을 미친다. 특히 도메인에 특화된 문서를 얼마나 정제하고 정리했는지가 성능을 좌우한다. 형식이 제각각이거나, 버전 관리가 되지 않은 문서는 오히려 성능을 떨어뜨린다. 수집, 전처리, 인덱싱 과정을 반복하면서 다듬는 일이 핵심이다.

3. Pilot이 잘 돌아간다고 실전에서도 잘 되는 것은 아니다

이 부분이 내가 제일 크게 공감했던 내용이다. 실제로 나도 몇몇 프로젝트에서 Pilot 단계에서는 아무 문제 없이 잘 작동했다. 하지만 production 환경에 옮겨가면서부터는 상황이 완전히 달라졌다. latency가 튀고, 캐싱이 안 되고, 보안 요소들이 누락되면서 하나하나 다시 손봐야 했다. 단순히 100개 내외의 문서로는 RAG는 정말 잘 동작한다. 하지만 이게 기업의 전체 문서가 되고 몇 십만 건의 문서가 넘어가면서 이제 온갖 문제들이 터지기 시작한다. 결국 병목은 모델이 아니라 전체 시스템 구조에서 발생했다. Douwe도 같은 말을 했다. Pilot에서는 잘 보이지 않는 문제들이 production에서는 반드시 드러난다. 처음부터 production 기준으로 설계하지 않으면, 나중에 더 큰 비용을 치르게 된다. 운영 환경에서 필요한 요소들을 미리 고려하고, 전체 시스템으로 바라보는 시각이 필요하다.

4. 구조는 단순하고 모듈화돼야 한다

복잡하고 멋진 아키텍처보다, 단순하고 교체 가능한 구조가 장기적으로는 훨씬 유리하다. 검색기, 리랭커, LLM, UI 같은 컴포넌트들이 독립적으로 작동할 수 있어야 유지보수도 편하고 확장도 용이하다. MLOps와 DevOps의 협업을 고려한 구조가 결국 제품의 생명력을 결정한다.

5. 아무리 좋은 모델이라도 UX가 나쁘면 외면받는다

모델이 아무리 좋아도, 사용자 경험이 나쁘면 결국 사용자는 떠난다. 느린 검색, 불명확한 답변, 출처가 없는 결과는 신뢰를 떨어뜨린다. 버튼 배치, 히스토리 기능, 직관적인 인터페이스 같은 기본 요소들이 오히려 실제 사용성을 좌우한다. 기술도 중요하지만 이걸 누가 쓰는지 유저 경험도 고려해야 한다.

6. 측정할 수 없는 것은 개선할 수 없다

느낌만으로는 시스템을 개선할 수 없다. RAG 시스템의 특성상, hallucination 비율, recall@K, 사용자 클릭 피드백 같은 맞춤형 지표들을 정의하고 추적하는 일이 매우 중요하다. 단순한 accuracy보다, 실제 사용자 만족도를 반영하는 지표가 훨씬 더 가치 있다.

7. 사용자 피드백이 가장 강력한 데이터다

서비스는 런칭 이후가 진짜 시작이다. 실패한 응답, 사용 중단 시점, 반복적인 행동 패턴 등을 데이터처럼 수집하고 분석해야 한다. 이 피드백을 retraining에 반영하고 개선하는 사이클을 꾸준히 반복해야 진짜 ‘PMF (Product-Market Fit)’에 도달할 수 있다. 사람들이 스스로 다시 찾아오게 만드는 제품, 그것이 진짜 성공이다.

8. 실패는 빠를수록 낫다

완벽한 제품을 만들겠다는 욕심은 종종 출시조차 못 하게 만든다. 오히려 빠르게 시도하고, 빠르게 실패하고, 빠르게 개선하는 것이 더 현명한 방법이다. “이건 아니다”를 빨리 확인하는 것도 큰 진전이다. 실패는 시간 낭비가 아니라 학습의 속도다.

9. 보안과 프라이버시는 처음부터 고려해야 한다

3번 항목과도 비슷한 내용인데, 엔터프라이즈 시장에서는 보안이 필수 조건이다. GDPR, SOC2, 멀티 tenancy, 접근 권한, 감사 로그 같은 요소들은 제품을 설계할 때부터 포함되어야 한다. “우리는 고객 데이터를 직접 보지 않는다”는 구조를 만들 수 있어야 한다. 그래야 기업 고객의 신뢰를 얻을 수 있다.

10. 기술보다 중요한 것은 팀과 전략이다

좋은 기술만으로는 성공할 수 없다. 궁극적으로 중요한 것은 팀의 조합과 방향성이다. 뛰어난 개발자, 문제를 정의할 줄 아는 PM, 도메인에 대한 깊은 이해를 가진 전문가가 함께할 때 진짜 제품이 만들어진다. 단기적인 기능 개선보다, 장기적인 비전을 그릴 수 있는 팀이 결국 시장에서 살아남는다.

마치며

RAG 시스템을 도입하거나 준비하고 있는 사람이라면, 이 10가지 교훈은 꽤 현실적인 체크리스트가 될 수 있다. 특히 PoC만 잘 되면 다 된 거라고 생각했던 나의 과거 경험을 떠올리며, 다시 한 번 “연습과 실전은 다르다”는 말을 마음에 새기게 된다. 또한 Douwe 의 현장에서 굴러본 경험이 돋보이는 유튜브 영상이었고 현장이 중요하다는 생각을 가지고 있는 내게도 많은 울림을 주는 영상이었다. 시간이 되시는 분들은 꼭 한 번 보셨으면 좋겠다.

유튜브 링크

Logseq 요새 자주쓰는 새로운 노트앱

브릭섬 — Thu, 27 Jul 2023 13:38:09 +0900

지금까지 노트나 메모앱은 iOS에서 기본으로 제공하는 메모앱이나, 구글의 Keep 을 주로 썼었다. 개발 관련 문서들은 거의 마크다운으로 쓰기 때문에 회사에서 사용하는 컨플루언스나 Notion 을 활용했는데, 매번 쓸때마다 잘 구조화 해야지, 카테고리화 해야지 하는 병?이 있어서인지 가볍게 쓰기가 불편했다. 개인 Notion 도 활용해보려 했는데 내가 그날그날 쓴 내용들을 적어도 나중에 보려면 여러군데에 분산되어 있거나 한눈에 모아서 보기가 좀 불편해서 결국에는 심리적으로 좀 잘 안쓰게 되었다.

그러다가 우연히 유튜브에서 요새 개발자들 사이에서 자주 쓴다는 Logseq 이라는 노트앱이 있다길래 한번 시험삼아 써보게 되었는데, 결과적으로 내가 메모를 하는 습관에 아주 잘 맞는 앱이라서 지금은 거의 매일 이것만 쓰고 있다. 내 메모 습관들을 간단히 얘기해 보자면,

매일매일 내가 한일이나 회의에서 들은 내용들을 짤막하게 글을 남김. 전혀 조직화 되지 않은 문장이고 나만 알아볼 수 있는 문장임. (사실상 문자만 한글인셈...)
긴 문장들이 아닌, 리스트나 나열 형식으로 꼭지를 달아 개조식으로 씀 (마크다운 형식처럼)

이렇게 크게 2가지인데, 이 두가지를 정말 잘 만족시켜주는 나에게 딱 맞는 노트앱인 것 같다

그리고 오픈소스여서 현재도 활발하게 개발이 진행중이고, 개발자들이 직접 개발한 여러 플러그인들이 있고 예쁜 테마들도 많아서 좀 더 쓸 맛이 난다. 나도 태생이 개발자인지라 주기적으로 빠르게 기능들이 업데이트 되는게 기다려져서 업데이트 할때마다 이번에는 어떤 기능이 추가되었을지 기대감을 주는게 한 몫이기도 하다.

https://logseq.com/

A privacy-first, open-source knowledge base

A privacy-first, open-source platform for knowledge management and collaboration.

logseq.com

공식 사이트는 여기에 있고, Windows, Mac OS, iOS, 안드로이드 모두 지원한다. 나는 아이폰을 쓰고 재택근무 할때는 윈도우 데스크탑을 쓰고 회사에서는 맥북을 쓰는데 이 세 개의 디바이스에는 원활하게 잘 동기화가 되어서 잘 쓰고 있다.

한달 정도 Logseq 를 써보면서 느낀 장점과 단점은 이렇다.

장점

모든 구조가 마크다운이어서 매우 개발자 친화적이다. 하나의 페이지 내에서 여러 꼭지를 달아 문서를 작성하는데, 이 한꼭지를 Block 이라고 한다.
매일 자연스럽게 일지 (journal) 을 쓸 수 있게 하는 구조인데, 이 일지를 작성할 때는 정말 구조화나 문서 카테고리 등 신경은 안쓰고 막 써도 된다.
왜냐면, 문서 안에 페이지를 Link 하거나 tag 하는 기능이 있는데, 이걸로 자연스럽게 Link 한 페이지나 tag 별로 Block 들을 모아서 보여주기 때문에, 나중에 한번에 찾아보기 정말 쉽다.

그렇기 때문에 나처럼 두서없이 메모들을 남기는 습관을 가지는 사람한테는 대충 일지에 그날 떠올랐던 아이디어나 회의에서 들은 내용들을 적어놓고 태그만 달아놔도 나중에 그 태그만 모아서 확인할 수 있다. 예를 들어 현재 회사에서 nexus 라는 코드명의 프로젝트를 진행하고 있는데, 내 일지 내에 nexus 프로젝트 관련된 내용들은 대충 갈겨 써놓고 태그만 달아놓으면, Nexus 라는 페이지에 관련된 모든 블록들이 모여있다. 필요하면 그 문서에서 나중에 이 블록들을 모아서 정리하면 된다. (따로 정리를 하지 않아도 되기도 하고)

단점

아직 오픈소스라 공식적으로 여러 디바이스간 동기화 기능을 제공하고 있지 않다. (Beta 로 제공중)
- 월 $5 또는 $15를 기부하면 Backer 또는 Sponser 가 될 수 있는데, 이걸 해야 Sync 기능을 사용할 수 있다.
- 하지만 iCloud 또는 Google Drive 등 클라우드 스토리지를 쓴다면 여러 디바이스에서 동기화 할 수 있는 기능을 사용할 수 있다. 이부분은 내가 따로 포스팅을 해볼 예정이다. (나도 저번주까지는 이렇게 사용했는데, Beta 로 제공하는 동기화 기능을 써보고 싶어서 이번주부터 기부를 시작했는데 매우 만족하고 있다.
국내에 사용자가 많지 않아 매뉴얼이나 커뮤니티가 많지 않다. 거의 영어로된 사이트들을 보고 사용법을 익혀야 한다.

뭐 생각나는 장단점은 이정도다. 정리하자면 나는 두서없이 메모를 휘갈기는 내 성격과 딱맞는 앱이다. 그리고 메모를 하는 것에 대해서 심리적인 장벽이 더 낮아져서 그런지 더 자주 빈번하게 메모를 하는 빈도도 늘어난 것 같다. 다만 개발자가 아니거나 앱 세팅 등에 익숙하지 않은 분들이라면 조금 Logseq 을 쓰는게 다른 노트앱보다는 좀 불편할 수는 있다. (아무래도 여러 플러그인이나 설정들이 필요하기는 하니까) 하지만 한번 세팅도 그리 어렵지도 않으니, 이참에 참신한 노트앱을 찾고있는 분들에게는 한번 써보시길 추천한다.

기술블로그 매뉴얼 사이트 구축해보기 (Read the Docs)

브릭섬 — Fri, 26 Aug 2022 12:44:54 +0900

나도 늘어나는 고객들의 기술지원을 하면서 반복된 질문들을 조금이나마 줄이고 또 우리 Product 에 대해 고객들에게 공개가능한 기술 문서를 제공하고자 매뉴얼 사이트를 구축하고자 했다. 이것저것 찾아봤지만 Readthedocs 가 가장 쓸만 하다고 판단했다. 그 이유는 다음과 같다.

전세계에서 가장 널리 쓰이는 검증된 서비스
Markdown 문서 지원
엔지니어가 문서를 올리기 편해야 함

여기서 우리는 2번째 사실이 매우 중요했는데, 대부분의 고객지원 문서를 내부에서 Markdown 문서로 작성하고 있었기 때문이다. 만약 새로운 포맷으로 다시 매뉴얼을 작성해야 했다면 기술문서를 작성해야 하는 엔지니어들의 원망의 소리가 귓가에 맴돌아, 무조건 Markdown 문서를 지원해야 한다는 옵션을 최우선적으로 고려했다.

서론은 여기까지 하고 그럼 이제 실제로 간단한 Readthedocs 매뉴얼 사이트를 구축해보고 샘플 문서도 올려본다.

Read the Docs 계정만들기

다음 사이트에서 계정을 만들어주자. Read the Docs 는 Github 과 같은 저장소와 연동되어 매뉴얼 사이트를 빌드하기 때문에 가능하다면 본인의 Github 계정과 연동하여 계정을 생성하는게 좋다.

매뉴얼 관리용 Repository 만들기

Github의 Repository를 하나 만들어준다. 이 Repo 에는 실제 매뉴얼인 Markdown 문서 및 Read the Docs 설정파일들이 들어가게 된다. readthedocs-sample 이라는 이름의 Repo 를 만들어봤다.

Repository 에 설정파일 담기

Repository 폴더 구조는 다음과 같이 생성해준다.

readthedocs-sample
| +-- docs
|     +-- index.md
|     +-- sample.md
|     +-- requirements.txt
| .readthedocs.yaml
| mkdocs.yml

docs/requirements.txt : 마크다운 문서를 readthedocs 로 빌드할 때 필요한 패키지들 정보가 담겨있다. 해당 경로는 .readthedocs.yaml 에서 참조하고 있다.
.readthedocs.yaml : Read the Docs 의 설정파일
mkdocs.yml : mkdocs 의 설정파일

우리들이 담을 마크다운 문서 (index.md, sample.md 등)는 docs/ 디렉토리 아래에 담아주면 된다. docs/ 디렉토리 아래에 하위 디렉토리를 만들어도 알아서 잘 빌드해준다.

프로젝트 만들기

이제 다시 readthedocs.org 로 돌아와서 프로젝트를 생성해주자. 우측 상단의 계정 > 내 프로젝트에 들어가서 ‘Import a Proect’ 를 클릭해준다. Github 계정의 Repo 중의 연동할만한 Repo 목록이 뜬다. 방금 우리가 생성한 readthedocs-sample 의 + 버튼을 클릭해주자.

특별히 변경하고 싶은 내용이 없다면 변경하지 말고 ‘Edit advanced project options’ 만 체크하주고 다음을 클릭해주자. (참고로 기본 브랜치도 main 으로 그대로 놔두어도 된다. 나중에 알아서 main 브랜치가 생성된다)

그 다음 문서종류는 Mkdocs, 언어는 Korean 으로 선택한하고 Finish 를 눌러 마무리 해준다.

Repo에 Push 해서 반영되는지 확인해보기

Repo 에 파일들을 Push 하게 되면 자동으로 Read the Docs 상에서 빌드가 된다.

문서보기를 클릭하면 정상적으로 빌드되어 올라감을 확인할 수 있다. Read the Docs 에서는 빌드와 함께 사이트의 호스팅까지 제공해 준다. 보통 repository명.readthedocs.io URL로 호스팅이 제공된다. 유료로 돈을 내면 커스텀 도메인을 붙이거나, Private Repository 를 쓸 수 있는 등의 기능이 제공되나 보다.

mkdocs 개발서버를 띄워보기

하지만 mkdocs 를 빌드하기 전에 미리 마크다운 문서들이 미리 어떻게 보이는지를 확인하고 싶은 경우가 있을 것이다. 나도 그렇고…

그럴 경우 mkdocs 개발서버를 띄워서 미리 사이트의 느낌을 확인할 수 있다.

개발서버에 대한 자세한 내용은 이 매뉴얼을 참고하자.

Repository 가 있는 디렉토리로 이동하자. 아무래도 Python 패키지를 깔아야 하고 커멘드로 개발서버를 띄워야 하니 리눅스나 맥 환경이 적절할 것 같다.

mkdocs 를 설치한다.

cd ~/readthedocs-sample

pip install mkdocs

mkdocs 서버를 띄우기 위해 필요한 Python package 들을 설치하자.

pip install -r docs/requirements.txt

mkdocs 를 실행해보자. 아래와 같이 뜨면 정상적으로 잘 뜬거다.

~/readthedocs-sample$ mkdocs serve
INFO     -  Building documentation...
INFO     -  Cleaning site directory
INFO     -  Documentation built in 0.03 seconds
INFO     -  [23:02:08] Watching paths for changes: 'docs', 'mkdocs.yml'
INFO     -  [23:02:08] Serving on <http://127.0.0.1:8000/>
INFO     -  [23:02:10] Browser connected: <http://127.0.0.1:8000/>

브라우저를 통해 http://127.0.0.1:8000 으로 접속해본다. 잘 뜨는 것을 확인할 수 있다.

이렇게 Repo 에 Push 를 하기 전에 먼저 개발서버를 통해 원하는 느낌으로 문서들이 잘 올라갔는지, 렌더링은 잘 되었는지 확인한 후 올리면 좋을 것 같다.

WSL 에서 Network Unreachable 이 뜰 때

브릭섬 — Mon, 1 Aug 2022 23:59:45 +0900

WSL 에서 갑자기 Network Unreachable 이라는 메세지가 뜨면서 인터넷망이나 DNS와 연결이 되지 않을 때는 다음과 같이 쉽게 처리해 볼 수 있다. Powershell 이나 CMD 를 켜서 (WSL 아님) 다음 명령어를 실행한 후, WSL 를 다시 켜보면 잘 될 것 이다.

wsl --shutdown

끝.

Linux Terminal 에 Git branch + Conda 환경 동시에 표시하기

브릭섬 — Sun, 17 Jul 2022 16:20:03 +0900

Linux Terminal 의 .bashrc 를 커스터마이징하면 터미널을 자기에게 맞게 유용하고 편하게 쓸 수 있는 방법은 무궁무진하다. 나는 사실 로컬에서 작업하는 경우는 거의 없고 웬만하면 원격 리눅스 개발서버에서 작업을 하고, 또 그 개발서버가 꽤나 그 수가 많기 때문에 하나하나 커스터마이징 하기는 귀찮기도 해서 잘 하지 않는 편이다. 따라서 최소한 내가 필요한 편의기능만 터미널에 보일 수 있도록 커스터마이징 하는데 그게 이 두가지이다.

Anaconda 가상환경이 보이는 것
현재 Git branch 를 나타내는 것

이 두 가지 외에는 잘 건드려고 하지 않는다. 따라서 나같은 미니멀한 유저 중에서 위 2가지만 필요한 사람들이 있다면 내 설정을 참고해서 세팅해보는 것도 좋을 것 같다.

Environments

Ubuntu 18.04 (사실 리눅스 환경이면 배포판이나 버전은 큰 상관없다)
Anaconda 가 설치되어 있음

Anaconda 가상환경이 보이도록 설정

사실 이건 Anaconda 가 설치되어 있는 환경이라면 기본적으로 아래와 같이 나타날 것이다. 이건 Anaconda 가 설치되면서 conda init 이 자동으로 실행되게 하도록 디폴트 옵션을 건들지 않았다면, 자동으로 적용되어 있을 것이므로 요건 생략하도록 한다.

Anaconda 를 정상적으로 설치했다면 conda init 에 의해서 터미널에 진입하면 자동으로 base 라는 이름의 conda 가상환경에 진입되도록 설정된다.

현재 Git branch 를 나타내도록 설정

~/.bashrc 의 아래 부분을 수정한다. 우분투를 설치하고 따로 이 파일을 안건드렸다면, 대걍 59~62번째 줄에 위치한다. 해당 부분을 아래와 같이 추가하고 수정해준다.

수정 전

if [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi

수정 후

# git_branch() 라는 함수를 추가
git_branch() {
    git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ (\1)/'
}

if [ "$color_prompt" = yes ]; then
	# 요기 PS1 만 수정해주면 된다. else 쪽은 안건드려도 큰 문제없다.
    PS1="${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\033[00;36m\]\$(git_branch)\[\033[00m\]\$ "
else
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi

수정해주고 파일을 저장한 후에 터미널을 한번 종료하든가, 그게 귀찮으면 아래 명령어로 수정된 .bashrc 를 적용해준다.

source ~/.bashrc

이렇게 해주면, Git repository 와 연동된 디렉토리에 들어가면 아래와 같이 이쁘게 conda 환경 및 Git branch 정보가 이쁘게 표시된다.

일본회사 면접 때 가장 중요한 자세

브릭섬 — Sat, 25 Jun 2022 14:44:51 +0900

사실 나는 대학교를 졸업하며 일본으로 취업하겠다고 한 건 심각하게 결정했다기 보다는 정말 가벼운 마음으로 결정했었다. 25세 대학교 졸업학기 시절에는 딱히 여자친구가 있는 것도 아니었고 처자식이 있는 것도 아니어서, '그냥 뭐 가서 망하면 다시 돌아와서 취직하면 되지 뭐' 라고 생각하며 도전 했던 것 같다. 그렇게 첫직장인 일본 대기업 SI 회사를 거쳐, 컨설팅펌 까지 2개의 회사를 거쳐서 한국으로 돌아왔다.

첫 일본회사나 두번 째 일본 회사에 이직을 할 때 그 당시 면접관들이나 HR 분들이랑 술자리를 가질 기회가 몇번 있었는데 내 면접 당시에 대한 이야기들도 많이 들어볼 수 있었는데 그게 참 재밌었다. 일본 회사가 나를 골랐던 이유는 '일본사람 같지 않아서' 라는 거였다. 처음에는 이 말을 듣고 '내가 한국인인데 당연한 소리 아닌가' 싶었는데, 좀 더 이야기를 들어보니 납득이 갔다. 수많은 외국인 지원자들이 면접을 보게 되면 왜 일본에서 일하고 싶냐 라는 질문에 대해서는 대개 일본 문화나 일본 애니메이션에 흥미가 많다, 일본에 대한 나라를 경험해보고 싶다 라는 이유를 대기 마련이다. 하지만 이건 면접관들 입장에서는 천편일률적인 답변이다. 또한 생각보다 면접관들은 일본을 잘 알거나 일본문화를 사랑하는 지원자에 대해서 큰 매력은 느끼지 않는 것 같다. 나같은 경우는 이런 걸 미리 알았던 것은 아니지만, 일본에서 왜 일하고 싶냐 라는 질문에 대해서는 '꼭 일본이 아니었어도 그냥 해외에 나가서도 내 실력이 통하는지를 부딪혀 보고 싶었다. 사실 일본이 아니라 중국, 미국이어도 상관없다' 라고 답했다. '그럼 여기는 한국과 문화가 다를텐데 동료들과 의견 충돌이 생기면 어떻게 할건가' 라는 질문이 들어왔을 때는 '문화 차이는 어딜가나 있는거고 꼭 국가간의 문화차이라기 보다는 여기만의 사내문화가 뭔질 이해하고, 그 사내문화에 따라 같이 일하는 인간 대 인간으로 풀어나가고 싶다.' 라고 답하며 크게 일본이 어떻고 저렇고 요런 답변들은 안했던 것 같다. 이게 면접관들에게는 생각보다 큰 임팩트였나 보다. 다들 일단 합격을 하고 보긴 해야하니, 일본이라는 나라와 문화에 잘 적응할 수 있다 라는 것을 어필하려고 하는 가운데, 나한테는 그런게 안보였고 그냥 외국인의 정체성으로 회사의 한 구성원으로 잘 녹아들겠다는 점이 많이 기억에 남았다고 하더라.

실제로 첫직장에서 한국인 엔지니어를 뽑을 때, 아직 일본어가 서투른 지원자를 위해 통역역할로 면접에 함께 참석한 적이 있다. 특이했던 게 2명의 지원자가 동시에 들어와서 면접관들은 나를 통해서 이 2명의 지원자에게 질문을 던지는 식이었다. 이 2명은 정말 캐릭터가 각각 확실했다. A지원자는 꽤 오래전부터 일본취업에 관심이 많았는지, 방에 들어올 때부터 일본 비즈니스 매너라든가 말하는 방식이라든가 거의 모든게 일본화 되어 있었다. 질문에 대한 답변도 들어보면 일본문화에도 관심이 많았고, 꽤나 회사에 대해서도 많은 준비를 해왔던 것 같았다. 무엇보다 한국말로 답하기는 했지만 약간 당황하는 제스쳐나 몸짓 등이 정말 일본사람 같았다. 누가보면 다른 일본회사에서 1~2년정도 일하고 온 건 아닌가 싶을정도로 너무 자연스러웠다. 반면에, B지원자는 이와는 정반대로 이제 막 취업면접 보러 다니는 전형적인 졸업학기 한국인 대학생 같았다. 일본 비즈니스 문화, 예절 같은건 잘 모르는 듯 했지만 그렇다고 예의가 없는 건 아니었다. 한국어로 답변했지만 질문에 대한 답변도 비교적 짧고 명확했고, 당당하게 외국인으로써 이 회사에서 일하겠다는 전제로 시원시원 답했었다. 어떻게 보면 내가 처음 면접봤던 느낌과도 비슷했다.

결과는 예상했겠지만, B가 합격했고 A는 떨어졌다. 2명의 TO가 있었음에도 말이다. 나중에 지원자들이 나가고 면접관분들께 이야기를 들었는데 딱 이 한마디만 하시더라.

'A를 뽑을 거면 그냥 일본애들 뽑는게 낫지 뭐'

절대 일본에서 잃어버려서는 안될 것

브릭섬 — Fri, 24 Jun 2022 00:54:42 +0900

한국에서 고등학교 동창들이 도쿄로 놀러온 적이 있다. 아직 일본생활을 한지 1년도 안될 때였을 때니 고국에서 바다건너 오는 친구들이 얼마나 반가웠을까. 신주쿠의 야키토리 (닭꼬치) 집에서 즐거운 마음에 들떠 부어라 마셔라 했다.

친구들과 헤어지고 정신을 차려보니 난 택시 안이었고, 어느덧 내 집 앞에 택시는 거의 도착해 있었다.

몽롱한 상태로 택시기사님에게 돈을 내려고 보니, 이런.. 아무리 찾아봐도 지갑이 없다.

일본은 현금문화라서 지갑에는 지폐 열댓장은 들어있었고, 또 일본에 온지 얼마 되지 않아 언제 뭐가 필요할지 몰라서 신분증이며 현금카드며 왕창 넣어놨었기 때문에 내 지갑은 항상 두툼했기에 금방 발견될 터이다. 그런데 한참을 가방을 뒤지고 양복 주머니를 더듬고, 택시 바닥을 헤집어봐도 내 지갑은 없었다. 결국 밤12시가 넘어가는 시간이었지만 기숙사의 한국인 친구에게 전화해서 급하게 돈을 빌려 택시기사에게 냈다. 그 한국인 친구는 몸도 안좋아서 일찍 잠드는 편인데, 지금도 그 날만 생각하면 미안한 마음과 고마움이 가득하다.

다음날 일어나서 지갑을 잃어버렸을 경우 해야되는 것에 대해서 인터넷을 검색해 보았다. 일단 지갑을 잃어버린 곳으로 추정된 곳 근처의 파출소로 가서 신고를 해야한다고 한다. 회사를 마치자마자 신주쿠 근방의 파출소로 가서 지갑을 잃어버렸다고 신고했고, 뭐 당연한 얘기겠지만 아직 분실지갑이 접수되지는 않았다고 한다. 지갑 분실신고를 하면 신고증명서를 발급해 주는데, 만약 분실지갑을 찾지 못해서 신분증 등을 다시 발급받아야 할 경우 반드시 이 신고증명서가 필요하다고 한다.

지갑에 있는 돈이야 잃어버리는 셈 친다고 하지만, 일본에서 와서 발급받았던 신분증, 은행 현금카드 등등 이 모든 걸 다시 발급받아야 한다는게 너무나 절망적이었다. 왜냐면 2015년 당시에도 일본은 대부분 종이로 접수가 이루어지는 문화이고 뭘 하나 발급받는데도 정말 오랜시간들이 걸렸기 때문이다. 마치 처음 일본에 온 것과 같은 기분까지 들었다. 이걸 내가 처음부터 다시 해야한다고...?

그 뒤로 어떻게 되었냐고? 결국 지갑은 발견되지 않았고, 나는 신분증 (재류카드) 부터 발급받기 위해 저 멀리 입출국 사무소까지 왔다갔다 해야했고, 또 잃어버렸던 은행 현금카드, 기타 포인트 카드 등등, 고등학교 친구들과 술을 마시기 하루전과 같은 생활로 돌아가기까지는 한 달이 걸렸다. 일단 온라인으로 재발급신청 할 수 있는 것은 하나도 없었고, 더 큰 문제는 어느 한군데를 가도 꼭 한번 더 가야하거나 대기시간이 기본 1시간은 걸리는 경우가 대다수였다. 그 땐 아직 회사 신입사원 연수기간이었고 또 파이팅 넘쳤을 때라 퇴근하고 이리저리 사방팔방 출입국 사무소, 동사무소, 은행 등등 왔다갔다 할 수 있었지만, 이 사건 뒤로는 무슨 일이 있어도, 아무리 취했어도 지갑 하나는 안잃어버리는 정신력을 갖추었다. 정말 두번다시는 겪고 싶지 않은 일이다. 여러분이 상상하는 그 이상으로 귀찮다. 절대 지갑만은 잃어버리지 마시라.

[GCP] Cloud Storage 의 모든 Bucket 사용량 확인

브릭섬 — Mon, 14 Mar 2022 21:47:07 +0900

1. Cloud Shell 로 진입

2. 모든 Bucket 확인

gsutil du -sh

3. 특정 Bucket 용량만 확인

gsutil du -sh gs://{bucket-name}

MySQL 용량정리 (Binary log 삭제)

브릭섬 — Wed, 9 Mar 2022 11:52:35 +0900

MySQL 서버를 운영하다보면, 로그 축적 등으로 용량이 부족하여 DB 연결에 에러가 생기는 경우가 종종 있다. 이 경우 일반적으로 Binary log 를 삭제해주는 방법을 생각해 볼 수 있다.

들어가기전에

MySQL를 Docker 이미지를 통해 사용중인 경우를 기준으로 설명한다.
꼭 Docker 버전에 국한된 것은 아니니 VM에 MySQL에 설치형으로 구축한 경우나 SaaS 경우에도 동일하게 적용 가능하다.
MySQL 이미지는 mysql:8 을 사용하였다.

Binary log 확인방법

먼저 나는 일반적으로 docker-compose 를 통해 컨테이너를 관리하는 걸 좋아해서 나의 MySQL docker-compose 를 먼저 간략히 보여드린다. 아주 심플한 구성이며 포트번호도 3306으로 기본 세팅이다.

보안이 필요한 부분은 좀 가렸다.

도커 컨테이너로 진입한다.

docker exec -it <container-id> mysql -u <mysql-id> -p

# 나같은 경우는 컨테이너ID는 55b86a7044b7, MySQL은 Root로 접근하려 하므로 아래와 같다.
# docker exec -it 55b86a7044b7 mysql -u root -p

현재 binary logs 를 확인해보자. 아래 명령어로 확인해보니 현재 2개의 로그가 있는 것을 알 수 있다.

show binary logs;

그럼, binary log의 보존기간을 확인해보자. 현재 나는 3,600초(1시간)으로 설정이 되어있다.

 show variables like 'binlog_expire%';

(참고) 예전에는 'expire_logs_days' 라는 변수로 보존기간을 관리했었는데 binlog_expire_logs_seconds 로 바뀐듯 하다.

binary log 보존기간은 아래와 같이 변경 가능하다. 1,800초(30분)으로 변경하니 정상적으로 변경된 것을 확인할 수 있다.

# 30분으로 변경
set global binlog_expire_logs_seconds=1800;

Binary log 삭제방법

삭제하는 방법은 기간을 지정하거나, 로그번호를 지정해서 삭제하는 방법 등 여러가지가 있다.

현재 로그 이전의 로그들 삭제하기

PURGE BINARY LOGS BEFORE NOW();

구체적인 일자를 지정하여 삭제하기

PURGE BINARY LOGS BEFORE '2020-03-09 00:00:00';

로그번호를 지정해서 삭제하기

# binlog.000245 까지 삭제됨
PURGE BINARY LOGS TO 'binlog.000246';

마치며

binary log 파일은 생각보다 용량이 꽤 된다. 나같은 경우는 1G가량이 되는데, 서비스를 정신없이 운영하다가 DB에서 에러가 나거나 과도하게 트랜잭션이 많이 발생하는 경우에는 20~30개 이상 순식간에 쌓여버리는 경우도 있다. 이 때, binary log가 과도하게 쌓여서 DB에 충분한 용량이 없을 경우에는 위와 같은 방식으로 주기적으로 삭제해주거나, binary log 의 수명을 짧게 가져가주는게 좋다.

binary log 최근 것만 남기도 삭제하고 나니 한결 마음이 가벼워졌다. /var/lib/mysql 에서 확인가능하다.

끝.

SSH 접속오류 해결방법 - WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

브릭섬 — Thu, 3 Mar 2022 10:53:13 +0900

가끔 SSH 원격서버를 포맷하거나 설정을 건드렸을 때, 아래와 에러가 나면서 SSH 원격접속이 불가능한 경우가 있다.

해결방법은 간단하다. 아래 파일에서 해당 원격서버의 부분을 지워주고 저장하면 된다.

Windows: C:\Users\유저명\.ssh\known_hosts
Linux: ~/.ssh/known_hosts

만약 SSH 원격서버의 IP가 165.244.190.39 라고 한다면, 해당 부분의 줄을 삭제하고 저장해주면 된다.

끝