코드 바깥의 임팩트

개발자의 가치는 단순히 코드를 얼마나 잘 짜는지에만 있지 않다. 그 코드가 팀, 조직, 그리고 시장에 어떤 파장을 일으키는지, 얼마나 오래 살아남는지를 말해야 한다. 이 글은 DZone의 “Scaling Impact Beyond Code”를 참고하여 작성되었다.

코드를 넘어서

개발자라면 누구나 “좋은 코드”를 추구한다. 간결하고, 유지보수가 쉽고, 테스트가 잘 된 코드. 하지만 “임팩트 있는 개발자”가 되는 것은 다른 차원의 문제다. 코드 그 자체가 아니라, 코드가 세상에 미치는 영향, 그리고 그것을 지속 가능한 방향으로 확장해 나가는 과정이 중요하다.

한국의 개발문화는 빠르다. 한국 IT 기업의 제품은 출시도, 업데이트도 속도가 다르다. 그런데 그 속도감 속에 숨은 중요한 사실이 있다. 코드보다 빠르게 “사람”이 움직여야 한다는 점이다.

임팩트 확장

개발자들은 종종 “개발 실력”이란 단어 앞에서 스스로를 평가절하하거나, 반대로 과대평가하기도 한다. 하지만 실력은 단지 레벨업의 지표일 뿐이다. 정말로 중요한 것은, 그 실력이 팀에 어떤 방향을 제시하고, 어떤 구조를 만들며, 어떤 문제를 해결했는가에 있다.

임팩트를 확장하려면 세 가지가 필요하다:

• 기술 리더십

• 시스템적 사고

• 조직과의 접점

코드 한 줄에 집착하기보단, 기능 하나가 고객의 여정을 어떻게 바꾸는지 고민할 때, 개발자는 “기술자”에서 “설계자”로 진화한다.

팀워크

한국은 수직적인 문화가 여전히 개발조직에 남아 있다. 직급보다 나이가 중요하고, 대화보다 지시가 앞설 때도 있다. 하지만 코드의 생명력은 “커뮤니케이션”에 있다.

기술적 선택은 결국 합의의 산물이다. 데이터베이스를 고르고, 프레임워크를 바꾸고, API 스펙을 정의하는 순간마다 우리는 사람과 사람 사이의 합의를 코딩한다.

회고를 하고, PR 리뷰에 진심을 담고, 문서에 정성을 더하는 이유는 간단하다.

“코드를 이해하는 건 기계지만, 코드를 지속시키는 건 사람”이기 때문이다.

스케일이 아니라, 방향

많은 개발조직이 “스케일”을 이야기한다. 트래픽, 사용량, 서버 수 등 그러나 코드의 임팩트를 스케일로만 측정한다면 진짜 중요한 걸 놓칠 수 있다.

“지금 내가 만든 기능이 팀의 다음 분기 로드맵을 더 빠르게 만들 수 있을까?”

“내가 작성한 문서 하나가 신입 개발자 onboarding 시간을 줄였을까?”

“그 작은 유틸 함수가 다른 팀의 반복 업무를 자동화했을까?”

이런 질문이 바로 “임팩트”를 코드 바깥으로 확장하는 시작점이다.

개발문화에 남겨진 여백

근데 솔직히 한국에서 개발자들한테 “임팩트 키워봐”라고 하면 피식 웃을지도 모른다. 야근하다가 커피나 한 잔 더 마시는 게 현실적인 목표인 경우도 많다. 특히 중소기업이나 SI 업계에선 “스케일링? 그거 먹는 거임?” 할 정도로 여유가 없다. 그래도 작은 변화부터 시작할 수 있다.

예를 들면, 내가 짠 코드라도 문서화를 해놓는 거다. 한국 개발 문화에서 문서화가 좀 약한 편인데, 이거 하나만 잘해도 나중에 동료들이 고마워한다. 아니면 코드 리뷰 시간에 “이렇게 하면 더 나을 것 같아요” 하고 의견 내는 것도 방법이다. DZone에서도 비슷한 이야기를 한다. 작은 습관 하나가 결국엔 큰 차이를 만든다.

한국의 개발자들은 충분히 빠르다. 이제는 그 속도에 방향성을 더할 시간이다. 기술이 아니라 팀을 설계하고, 코드가 아니라 시스템을 만들어야 한다. 우리의 커밋이 조직 문화를 바꾸고, 리뷰 하나가 개발자 생태계를 성장시킨다.

“Scaling Impact Beyond Code” 에서 던지는 메시지는 단순하다. “너의 영향력을 키워봐”라는 거다. 한국에서 개발자로 살면서 바빠 죽겠어도, 가끔은 멈춰서 생각해보면 좋다. 내가 짠 코드가 팀에, 회사에, 아니면 사용자한테 어떤 가치를 주고 있는지 말이다. 그리고 그걸 조금 더 키울 방법은 뭔지 고민해본다.

작게 시작해도 괜찮다. 팀 회의에서 한 번 더 의견 내거나, 블로그에 내가 고민한 기술 문제 정리해서 올려도 좋다.

“코드 바깥의 임팩트”

그것이 진짜 Senior Developer의 역할이고, 다음 단계로 나아가는 방법이다.

Read More

AICC(Artificial Intelligence Contact Center), 기술과 경험 사이의 항해: 컨택센터의 내일을 묻다

AICC, 이제는 단순한 기술 트렌드를 넘어 고객 소통 방식의 근본적인 변화를 이끄는 동력이 되고 있다. 특히 팬데믹 이후 비대면 환경이 가속화되면서, 기업들은 앞다퉈 AICC 도입에 나서고 있다. 효율성 향상, 비용 절감, 24시간 끊김 없는 응대라는 약속은 분명 매력적이다. 하지만 이런 장밋빛 전망 이면에는 신중한 접근을 요구하는 목소리도 커지고 있다. 아시아경제에서 제기하는 비판적 분석 들은, 기술 도입의 열기 속에서 우리가 놓치고 있는 것은 없는지, 성급한 기대가 가져올 부작용은 무엇인지 날카롭게 질문한다.

이 글은 AICC를 둘러싼 이러한 다층적인 시선을 깊이 있게 탐구하려 한다. 단순히 찬반을 논하기보다, AICC 기술의 현재 수준과 명확한 한계, 그리고 이것이 고객 경험과 비즈니스 전략에 미치는 실질적인 영향은 무엇인지 구체적으로 들여다볼 것이다. 언제 AICC는 강력한 도구가 되고, 언제 인간의 섬세한 개입이 필수적인지, 그 경계와 균형점을 면밀히 살펴보는 여정이 될 것이다. 이는 AICC의 성숙한 도입과 활용을 위한 필수적인 대화이기도 하다.

아래의 글은 지극히 개인적인 생각을 담았다는 것을 강조한다.

AICC가 약속하는 혁신: 효율과 지능의 만남

AICC가 가져올 변화의 핵심은 '효율'과 '지능'의 결합에 있다. 구체적으로 어떤 가능성을 품고 있을까?

• 업무 처리 속도와 효율의 극대화: 단순 문의에 대한 평균 처리 시간(AHT, Average Handle Time)을 획기적으로 단축하고, 첫 통화 해결률(FCR, First Call Resolution)을 높이는 데 기여한다. AI는 동시에 여러 요청을 처리하며 지치지 않는다. 이는 곧 고객 대기 시간 감소로 이어진다.
• 시공간 제약 없는 고객 지원: 글로벌 고객 기반을 가진 기업에게 24시간 365일 응대는 필수다. AICC는 물리적 제약 없이 일관된 수준의 서비스를 제공하며 고객 접근성을 높인다.
• 운영 비용 최적화: 상담원 인건비 절감 효과는 물론, 장기적으로는 교육, 관리 비용 등 총 소유 비용(TCO, Total Cost of Ownership) 관점에서 이점을 제공한다. 물론 초기 투자 비용과 유지보수 비용은 고려해야 할 요소다.
• 일관된 브랜드 경험과 컴플라이언스 강화: AI는 정해진 규칙과 스크립트에 따라 응대하므로, 브랜드 메시지의 일관성을 유지하고 규정 준수(Compliance) 측면에서도 강점을 보인다. 모든 인터랙션 기록은 감사 추적에도 용이하다.
• 데이터 기반의 고객 인사이트 도출: AICC는 단순한 응대 도구가 아니다. STT(Speech-to-Text)로 변환된 방대한 음성 데이터, 텍스트 대화 기록을 NLP(자연어 처리) 기술로 분석한다. 이를 통해 감성 분석(Sentiment Analysis)으로 고객 만족도를 측정하고, 토픽 모델링(Topic Modeling)으로 주요 문의 유형과 이슈를 파악하며, 나아가 예측 분석(Predictive Analytics)으로 고객 이탈 징후나 잠재적 니즈를 감지하여 제품/서비스 개선 및 마케팅 전략 수립에 귀중한 인사이트를 제공한다.
• 인간 상담원의 역량 강화 (Agent Augmentation): AICC는 상담원을 대체하는 것이 아니라, 그들의 역량을 강화하는 방향으로 진화하고 있다. AI 기반 지식 베이스(Knowledge Base)는 상담원에게 필요한 정보를 실시간으로 찾아주고, 실시간 응답 추천 기능은 최적의 답변을 제안한다. 통화 내용을 자동으로 요약하거나 관련 정보를 RPA(Robotic Process Automation)를 통해 후속 시스템에 입력하는 등, 상담원이 고객과의 '관계' 형성과 복잡한 문제 해결이라는 본질적인 역할에 집중하도록 돕는다. 이는 상담원의 역할을 단순 응대자에서 고도의 문제 해결 능력을 갖춘 '슈퍼 에이전트' 또는 '관계 관리자'로 변화시키는 추세와 맞물린다.

여기서 현재 나는 "인간 상담원의 역량 강화"에 관심이 있다. 이게 잘되어야 나머지도 잘 될 것이라는 생각이든다.

기술의 그늘: 직시해야 할 한계와 도전 과제

화려한 가능성 뒤에는 분명 넘어야 할 산과 풀어야 할 숙제들이 존재한다. 비판적 분석(아시아경제 등)에서 꾸준히 제기되는 우려들은 다음과 같은 지점들에 집중된다.

• 인간적 공감과 유연성의 부재: 현재의 NLU(자연어 이해) 기술은 문맥 속 숨겨진 의도, 반어법, 문화적 뉘앙스, 복잡한 인간 감정을 완벽히 이해하는 데 명백한 한계를 갖는다. 특히 고객이 감정적으로 격앙되거나 예외적인 상황에 처했을 때, 기계적인 응대는 문제를 악화시킬 수 있다. 어설픈 공감 시도는 오히려 '불쾌한 골짜기(Uncanny Valley)' 현상을 유발하며 고객의 불신을 키울 위험도 있다.
• 예측 불가능한 복잡성 대응 능력: AI는 학습된 데이터 범위 내에서는 뛰어난 성능을 보이지만, 전혀 새로운 유형의 문제나 여러 정보가 복잡하게 얽힌 상황, 깊은 맥락 이해가 필요한 다중 대화(Multi-turn Dialogue)에서는 여전히 어려움을 겪는다. 이는 고객을 답답한 루프에 가두거나, 문제 해결을 지연시키는 결과로 이어질 수 있다.
• 고객 경험 저하 및 브랜드 손상 위험: 효율성만 추구하다 보면 고객 경험의 질이 떨어지기 쉽다. AI와의 소통에서 불편함을 느낀 고객은 쉽게 이탈하며, 부정적인 입소문은 브랜드 이미지에 치명타를 입힐 수 있다. 따라서 AI가 해결하지 못할 때 인간 상담원으로 매끄럽게 전환되는 에스컬레이션 경로(Escalation Path) 설계는 필수적이다. AI의 문턱에서 좌절하는 경험은 고객에게 최악의 기억을 남긴다.
• 결코 간단치 않은 도입과 운영의 현실: 성공적인 AICC 구축은 생각보다 훨씬 복잡하다.
• 데이터 품질 및 편향성 문제: 방대하고 질 좋은, 그리고 편향되지 않은 학습 데이터 확보가 관건이다. '쓰레기가 들어가면 쓰레기가 나온다(Garbage In, Garbage Out)'는 AI 세계의 금언은 여기서도 유효하다. 학습 데이터에 내재된 사회적 편견이 AI 응대에 그대로 반영될 위험도 상존한다.
• 기존 시스템과의 통합: CRM, ERP, 레거시 전화 시스템 등 기존 인프라와의 유기적인 연동은 기술적으로 큰 도전 과제다.
• 전문 인력 확보 및 유지: AI/ML 엔지니어, 데이터 과학자, 언어 전문가 등 시스템 구축과 지속적인 모델 튜닝, 성능 개선을 위한 전문 인력 확보가 필수적이다.
• 조직 내 변화 관리: 새로운 기술 도입은 필연적으로 업무 프로세스 변화와 구성원의 저항에 부딪힌다. 상담원 재교육, 역할 재정의, 변화에 대한 불안감 해소 등 섬세한 변화 관리가 동반되어야 한다.
• 지속적인 비용 발생: 높은 초기 투자 비용 외에도 클라우드 사용료, 라이선스 비용, 유지보수 및 업데이트, 전문 인력 인건비 등 지속적인 운영 비용을 고려해야 한다.
• 오류 가능성과 책임 소재의 불분명성: AI는 완벽하지 않다. 잘못된 정보를 제공하거나 오작동할 가능성은 언제나 존재하며, 이로 인한 피해 발생 시 책임 소재를 규명하는 것은 복잡한 법적, 윤리적 문제를 야기할 수 있다. 지속적인 성능 모니터링과 오류 감사 체계가 필요하다.
• 일자리 변화와 사회적 영향: AICC 확산은 필연적으로 기존 컨택센터 인력 구조에 영향을 미친다. 단순 반복 업무 감소는 해당 직무의 축소로 이어질 수 있으며, 이는 아시아경제 등 비판적 분석이 특히 우려하는 지점이다. 기술 변화에 따른 재교육(Reskilling) 및 직무 전환(Upskilling) 지원 등 사회적 차원의 고민이 요구된다.

AICC, 최적의 활용 시나리오 찾기

그렇다면 이 복잡한 기술을 언제, 어떻게 활용하는 것이 가장 효과적일까?

• 표준화된 정보 안내 및 단순 업무 자동화: FAQ, 상품 정보 안내, 배송 조회, 계좌 잔액 확인, 간단한 예약/변경 등 명확한 답변이 정해져 있고 반복성이 높은 업무
• 지능형 라우팅 및 초기 분류: 고객의 초기 발화 의도를 파악하고, 문의 유형이나 고객 가치 등을 분석하여 가장 적합한 상담원 또는 셀프서비스 채널로 연결하는 지능형 라우팅(Intelligent Routing). 과거 이력 기반의 예측 라우팅(Predictive Routing)도 활용될 수 있다.
• 시간 제약 없는 셀프서비스 채널 확장: 업무 시간 외 기본적인 문의 응대, 간단한 문제 해결 가이드 제공, 자주 묻는 질문 기반의 챗봇/보이스봇 운영
• 전략적 인사이트 도출을 위한 데이터 분석: 앞서 언급한 감성 분석, 트렌드 분석 등을 통해 얻은 인사이트를 고객 경험 개선, 상품 개발, 마케팅 캠페인 기획 등에 활용
• 인간 상담원 업무 지원 강화: 실시간 통화 내용 텍스트 변환(STT), 상담 중 관련 정보 자동 검색 및 추천(Knowledge Assist), 규정 준수 여부 실시간 점검, 통화 후 자동 요약 및 기록(Wrap-up Automation) 등 상담원의 생산성과 만족도를 높이는 데 집중

인간의 역할이 필요한 순간: 대체 불가능한 가치

기술이 아무리 발전해도 인간의 개입이 필수적인, 혹은 더 나은 결과를 만들어내는 영역은 분명히 존재한다.

• 고도의 문제 해결 및 협상: 메뉴얼에 없는 복잡한 문제, 여러 부서와의 협업이 필요한 사안, 고객과의 협상이나 창의적인 대안 제시가 요구될 때
• 깊은 공감과 감정적 지원이 필요할 때: 심각한 불만 제기, 위기 상황 대처, 취약 계층 고객 응대, 정서적 지지와 위로가 필요한 민감한 상담. 이러한 상황에서 인간의 진정성 있는 공감 능력은 무엇과도 바꿀 수 없다.
• 장기적 고객 관계 구축 및 관리: VIP 고객 관리, 충성도 제고를 위한 개인화된 소통, 신뢰 기반의 관계 구축이 중요한 비즈니스 영역. 인간적인 유대감 형성은 여전히 사람의 몫이다.
• 고객의 명시적 요구 및 복잡한 의도 파악: 고객이 AI와의 대화를 원치 않고 명확히 사람과의 연결을 요청할 경우, 이를 존중하고 신속하게 전환해야 한다. 또한, 말 속에 숨겨진 진짜 의도나 미묘한 뉘앙스를 파악해야 하는 상황에서는 인간의 직관과 경험이 중요하다. 특히 문화적 차이를 이해해야 하는 글로벌 커뮤니케이션에서는 더욱 그렇다.

결론: 기술과 경험 사이, 균형점을 향한 끊임없는 항해

결론적으로 AICC는 컨택센터의 모든 문제를 해결하는 '만병통치약'이 아니다. 동시에, 제대로 활용했을 때 가져올 수 있는 혁신적인 가치를 무시할 수도 없다. 

현재 가장 현실적이고 효과적인 접근법은 AI와 인간 상담원이 서로의 강점을 보완하며 시너지를 내는 하이브리드 모델을 구축하는 것이다. 

AI가 표준화되고 반복적인 업무를 처리하며 효율성을 높이는 동안, 인간은 그 기반 위에서 더욱 복잡하고, 감성적이며, 관계 지향적인 역할에 집중하는 방식이다. 

AI 우선 접근(AI-first) 후 필요 시 인간 개입, 혹은 인간 중심 접근(Human-first) 하에 AI가 보조하는 등 비즈니스 특성과 고객 전략에 맞는 다양한 형태의 하이브리드 모델을 설계할 수 있다.

AICC는 단순히 기존 컨택센터를 대체하는 것이 아니라, 고객 소통 생태계 전체를 변혁(Transformation) 시키는 과정에 있다. 아시아경제 등에서 제기되는 비판적인 글을 참고하면 이러한 변혁 과정에서 기술 만능주의에 빠지지 않고, 인간적인 가치와 윤리적 책임, 고객 경험의 본질을 끊임없이 성찰하게 하는 중요한 '견제와 균형(Checks and Balances)' 장치 역할을 한다.

앞으로는 AI가 고객의 니즈를 미리 예측하여 선제적으로 다가가는 프로액티브(Proactive) 컨택, 축적된 데이터를 기반으로 초개인화된 경험을 제공하는 하이퍼-퍼스널라이제이션(Hyper-personalization) 등 더욱 진화된 형태의 AICC 활용이 논의될 것이다. 

이처럼 기술은 끊임없이 발전하겠지만, 그 기술을 어떻게 인간적인 가치와 조화롭게 엮어내어 최적의 고객 경험을 창조할 것인가에 대한 고민, 즉 기술과 경험 사이의 균형점을 찾아가는 여정은 앞으로도 계속될 것이다. 이것이 바로 컨택센터의 내일을 만들어가는 핵심 과제다.

References

• 뺑뺑이 AI콜센터: https://www.asiae.co.kr/list/project/2024080713242310250A

Read More

모노레포(Monorepo)란?

이 글을 읽는 분들중 개발을 하시는 분들은 Facebook, Twitter(e.g. X), Google, Microsoft 등 대부분의 기업이 전체 코드베이스, 모든 서비스, 애플리케이션 및 도구를 단일 거대 저장소인 모노레포에 보관하는 것을 들어본 적이 있을 것이다.

대부분 팀이 코드베이스를 관리하는 일반적인 방식(저장소당 하나의 애플리케이션, 서비스)에 익숙 하다면 이는 매우 이상하게 들릴 수 있다. 우리가 구글이나 페이스북도 아닌데, 굳이 이걸 써야해? 라고 생각할 수 있다.

모노레포를 사용하면 소프트웨어 개발 라이프사이클에서 여러가지 장벽이 줄어들 수 있다. 코드를 찾는데 소요되는 시간이 줄고, 버그를 찾아내고 수정할때까지 시간이 줄어들 수 있다. 그리고 방대한 코드를 찾고 분석하는 것이 훨씬 쉬워진다.

모노레포(Monorepo)는 여러 프로젝트를 하나의 저장소에 저장하는 버전 관리 구성이다.

모노레포를 사용하면 다음과 같은 이점을 얻을 수 있다.

• 단일 저장소를 제공한다.

• 코드 공유가 쉽다.

• 코드 리팩토링이 쉽다.

모놀리스(Monolith)와 다른게 없는거 아닌가?라고 생각할 수 있다.

모노레포는 독립적인 프로젝트를 포함하는 거대한 코드베이스인 반면, 모놀리스는 단일 프로젝트에 집중한다. 물론, 모놀리스도 모노리포에서 관리 할 수 있다. 그러나 모놀리스는 여러 저장소로 분할 될 수도 있다.

<출처: https://www.toptal.com/front-end/guide-to-monorepos>

어쨌든, 본 글은 모노레포에 초점을 맞출 것이다.

“단 하나의 저장소”는 무슨 의미일까?

이는 단일 루트가 있는 Linux 파일 트리와 유사하다. 

이 개념에 익숙하지 않은 사람들은 일반적으로 이 아이디어에 대해 상당히 강한 반응을 보인다. 

“너무 거대한거 아냐?” 

“확장이 가능해?”

다양한 반대 의견이 나온다. 그럴 수 있다. 비교적 생소한 개념이며, 표면적으로는 거대하기에 거대하게 개발하지 말라고 배웠던 것에 어긋난다.

그러나 모노레포는 종속성 관리를 보다 쉽게 하고 여러 개의 저장소를 사용하는 것보다 안정적인 테스트를 가능하게 한다.

모노레포는 좋은 아이디어일까?

모노레포를 사용하는 것은 대부분 회사에 좋은 생각이다. 모든 팀의 모든 소스 코드를 하나의 저장소에 보관할 수 있다. 이렇게 하면 모든 사람과 공유하기 더 쉬워진다.

커밋 후에는 모든 개발자가 새 코드를 보고 사용할 수 있다. 이렇게 하면 많은 개발자가 단일 코드에서 작업하기에 흔히 발생하는 고통스러운 병합을 일부 회피할 수 있다.

모노레포는 모든 데이터에 대한 제한이 거의 없는 협업적 작업이라는 아이디어에 기반을 두고 있다. 하지만 모노레포가 커질수록 느려지게된다. 모든 데이터를 한 곳에 보관하는 것은 매력적이지만, 접근하는데 속도가 느리다면 단일 저장소가 무슨 소용이 있을까?

그럼에도, 구글을 모노레포를 잘 사용한다. 구글을 꽤 오래전부터 모노레포를 사용하기로 결정했고, 회사가 성장함에 따라 규모를 확대했다. 2015년 기준 구글 모노레포 현황이다. (https://cacm.acm.org/research/why-google-stores-billions-of-lines-of-code-in-a-single-repository/)

• 86테라바이트의 데이터

• 20억줄의 코드

• 900만개의 소스 파일

왜 구글이 모노레포를 선택했는지 그리고 계속 고수하고 있는지 이유는 무엇일까? 모노레포를 사용하는 것이 개방적이고 협력적인 문화의 핵심이기 때문이다.

구글외에도 Salesforce, Meta, Uber, Airbnb, X도 모노레포를 사용하는 것으로 유명하다.

모노레포는 종속성의 불일치를 제거한다. 종속 모듈간의 불일치는 정말 어려운 상황이다. 코드를 한곳에 저장하는 것으로서 버전 관리와 종속성 관리에 대한 것이 끝난다. 모노레포는 본질적으로 이 문제를 사라지게 한다. 이것은 내가 가장 좋아하는 문제 해결 종류이다.

그러나, 100% 사실은 아니다. 종속 모듈에 속한 부분이 변경이 되면 모든 것을 배포하고 테스트해야 한다.

<출처: ByteByteGo>

위 표는 모노레포와 마이크로레포(혹은 멀티레포)를 사용하는 회사들을 보여준다. 어느것이 더 나을까? 왜 회사마다 다르게 사용할까? 라는 의문이 생긴다.

모노레포에서는 서비스는 폴더이고, 모든 폴더에는 BUILD 구성과 OWNER 권한 제어가 존재한다. 모든 서비스의 멤버는 자체 폴더를 담당한다.

마이크로레포에서는 각 서비스는 자체 저장소를 가지며, 빌드 구성과 권한은 일반적으로 전체 저장소에 대해서 설정한다.

다시 모노레포로 돌어와서 구글은 모노레포 접근 방식으로 어떤 혜택을 얻고 있을까?

구글이 이런 결정을 한 이유에는 엄청난 규모에서 일관성과 조정을 유지해야 할 필요성에서 비롯되었다. 수천명의 엔지니어가 수많은 프로젝트에서 작업하기에 모노레포를 사용하면 팀이 코드를 공유하고 쉽게 협업할 수 있도록 보장하기 때문이다.

대규모로 작업을 해야 하기에 도구의 혁신이 필요하다. 그래서 Piper(버전 제어 시스템), Bazel(빌드 도구)에 크게 의존한다. 이런 도구를 사용해야 대규모 모노레포를 효과적으로 관리하고 테스트, 종속성 관리 및 배포를 자동화할 수 있다.

처음에 언급했듯이 모노레포 방식을 채택하면 개발 라이프사이클에서 장벽이 줄어든다. 코드를 찾고 어떻게 사용할지 알아내는 데 시간을 덜 쓰게 된다. 저장소를 설정하거나 허가를 요청할 필요도 없다. 이런 문제 대신 고객을 돕기 위한 문제에 더 많은 시간을 할애할 수 있다.

고려 사항

이제까지 언급한 이점에도 모노레포는 다음과 같은 과제를 안고 있다.

• 성능 문제: 모노레포가 커짐에 따라 버전 제어 성능이 느려질 수 있다.

• 손상된 빌드: 메인 브랜치의 실패는 모든 프로젝트에 영향을 미친다.

• 학습 곡선: 익숙하지 못한 개발자는 대규모 통합 저장소의 복잡성에 어려움을 겪을 수 있다.

• 코드 검토: 엄청난 양의 코드 검토와 알림은 압도적이다.

모노레포와 멀티레포 중에서 선택하는 것은 기술적 고려 사항 만큼이나 조직 문화에 관한 것이다. 모노레포는 Silo를 무너뜨리고 더 나은 협업을 촉진하는데 도움이 될 수 있으며, 모든 구성원의 중심 허브 역할을 한다.

결국, 도구를 잘 사용하여 워크플로우를 조정하는 것이 관건이다.

요약

모노레포는 코드 공유를 간소화하고 자산에 대한 가시성을 개선한다. 물론 깨끗한 히스토리, 병합 충돌 위험, 도구 지원 등의 대가를 치뤄야 한다.

모노레포가 가진 투명성이라는 이점은 모든 상황에 적합하지는 않다. 모노레포를 사용할지 여부는 자신의 프로젝트, 프로젝트 간 종속성, 구성원들의 의견에 따라 결정해야 한다.

좋은 코드 문화에는 사용하는 저장소 유형보다 더 많은 요소가 있기에 자발적인 참여가 필요하다.

모노레포는 잘 사용하면 정말 강력한 솔루션이다. 아래는 모노레포에 가장 일반적으로 사용되는 도구 목록이다. 시간이 되면 하나씩 다뤄보겠다.

• Nx: https://github.com/nrwl/nx

• Bazel: https://github.com/bazelbuild/bazel

• Turborepo: https://github.com/vercel/turborepo

• Rush: https://github.com/microsoft/rushstack

• Lerna: https://github.com/lerna/lerna

• 
  

Read More

분산 시스템 이해하기

우리 동네에는 꽤 인기 있는 떡볶이&오뎅&튀김 가게가 있다. 인기가 많은 관계로 포장임에도 웨이팅은 기본이다.

그리고 이렇게 긴 대기시간을 가지는 이유는 계산원이 한 명뿐인점도 한몫한다. 매장에 계산원이 더 많았으면 좋았을 텐데, 그러면 빨리 계산할 수 있지 않을까?

아마도 이 글을 읽는 여러분들도 비슷한 경험을 했을 것이다. 이런 일은 너무 자주 일어나서 이런 상황에서 분산 시스템을 도메인 영역에 어떻게 적용할 수 있는지는 잊어버리기도 한다. 왜 대기 시간이 높지? 왜 처리량이 이렇게 낮지? 등은 중요한 질문이다.

다시 원래 이야기로 돌아와서, 성능을 높이기위해서는 한 명의 계산원이 계산을 하는데 걸리는 시간을 정확하게 측정을 해야 한다. 주문을 받고, 카드를 받고, 계산하기까지의 과정에서 걸리는 시간을 측정해야 한다. 그리고 병렬로 이루어지지 않는다. 계산원은 한 번에 한 사람 이상을 서비스 하지 않는다. 시스템의 단일 CPU도 요청이 얼마나 오던간에 한 번에 하나의 작업 단위를 처리한다.

시간을 측정 했으면, 계산원을 조금 더 관찰해야 한다. 계산이 끝나고 요청한 상품을 담고 물건을 전달하기까지 시간이 필요하다. 혹은 손님이 없을때는 손님을 기다리며 쉬기도 한다.

마찬가지로, 클라이언트가 시스템에 요청하는 부분을 보면 네트워크 왕복 시간을 발생시키고, 낮은 동시성에서는 항상 비용을 지불하게 된다. 이런 유휴 상태를 제거하고 처리량을 높이려면, 단순하게 동시성을 높이면 된다. 처리량이 포화 상태가 되고 대기 시간이 증가하는 시점까지 조금씩 증가시키면서 해당 지점에 도달해야 한다. 이는 시스템의 한계를 아는 것을 의미한다. 시스템의 한계를 알았으니 더 낮은 동시성을 처리하도록 조정해야 한다.

시스템의 한계를 알았고, 처리 가능한 만큼만 처리하도록 세팅했다면, 더 많은 계산원을 고용해야 한다. 분산 시스템의 경우에는 측정한 지연 시간내에서 처리량을 확장하기 위해 아래의 공식을 적용해야 한다.

“작업자 수 = 대상 처리량 / 단일 작업자 제한”

우리는 이미 단일 작업자의 성능 한계를 알기 때문에, 필요한 총 작업자 수를 찾으려면 대상 처리량을 정의된 단일 작업자가 처리할 수 있는 양으로 나누기만 하면 된다.

생각해보자. 주문을 처리하는데 걸리는 총 시간은 상품의 수를 한 명의 계산원의 처리하는 속도로 나눈 값에 따라 결정된다. 한 명의 계산원에게 모든 요청을 하는 대신, 계산할 수 있는 다른 계산원에게 병렬로 분배하는 것이 훨씬 더 효율적이지 않을까?

여러 명의 계산원이 고용된 후에도, 때때로 계산원 뒤에 긴 줄을 선 고객이 있는 경우가 있다. 반대로 모든 계산원이 한가하고 당신은 그들 중 누구라도 선택할 수 있는 상황이 생길 수 도 있다. 당신이 주문한 것을 계산하기전, “순대도 추가해주세요.”라고 말할 수 있다. 그러면 계산원은 순대도 결제 항목에 추가하면서, 다른 사람에게 순대를 포장해달라고 요청할 수 있다.

이렇게 되면 몇 가지 문제가 발생한다.

1. 당신의 계산을 단일 계산원을 통해 하고 있다.

2. 다른 주문을 다른 사람에게 병렬화 했지만, 당신의 앞에 있는 계산원은 그 상품이 오기까지 기다리며 유휴 상태가 되어 지연이 발생한다.

3. 이런 추가 주문이 많아질수록 전체 지연은 가장 느린 응답에 의해 결정된다.

즉, 위의 방식으로 코드를 짜면 대기 시간을 발생시키게 된다.

이글을 읽었다면, 이제는 왜 대기 시간이 높은가? 또는 왜 처리량이 이렇게 낮은가?와 같은 질문에 답할 수 있어야 한다. 성능을 평가할때는 작게 시작해야 한다. 이렇게 하면 비용이 최소화되고 각 단계에서 세부적인 제어가 가능하다.

“동시성 = 처리량 x 대기시간”

항상 동시성을 주시하고 불균형을 주의 깊게 살피면서 필요에 따라 완화하거나 방지해야 한다.

Read More

원숭이가 가르쳐준 프로젝트 관리의 진실

이제 곧 프로젝트가 시작된다. 프로젝트 관리에 대한 경험을 해보지 못한 동료가 리드를 하기에., 그분에게 해주고 싶은 말 중 가장 중요한 것은 무엇일까? 에 대한 고민을 해봤고, 고민의 결과를 글로 남긴다.

프로젝트 관리는 계획을 세우고, 리스크를 관리하고, 참여 멤버들을 이끌어 목표를 달성하면 되는 심플하고 단순한 것이라 생각할 수 있다. 하지만 생각보다 현실은 훨씬 더 복잡하다.

"Sunk cost fallacy(매몰 비용 오류)"가 있다. 예를 들어, 프로젝트 초기에 리스크를 줄이기 위한 조치를 하지 않으면, 나중에 그 비용과 노력이 쌓여 결정을 내리기 더 어려워지는 상황을 의미한다.

그래서 어떤 상황에서는 "포기할 줄 아는 용기"도 필요하다. 하지만 현실에서는 그 용기를 내기 쉽지 않다는 점이 이론과 행동의 간극이다.

예시를 하나 보자.

어느 서커스단에서 쇼를 기획하고 있다. 그 쇼는 원숭이가 받침대 위에서서 횃불을 저글링하는 것이다.

이 쇼를 성공 시킬려면 무엇을 준비해야 할까? 이론적으로는 간단해 보인다.

원숭이를 훈련시키고, 튼튼한 받침대를 만들면 끝이다. 그러나 현실에서는 원숭이가 횃불을 두려워하거나, 떨어뜨리거나 받침대가 흔들릴 수 있다.

그럼, 어떤 것을 먼저 확인해야 할까? 받침대일까? 횃불일까?

위의 이야기를 프로젝트 관리에 적용하면, 초기 리스크를 줄이지 않으면 "원숭이"가 우리의 등에 올라타서 문제를 키운다고 비유될 수 있다. 여기서 "원숭이"는 잘못된 결정, 관리되지 못한 리스크, 계속 쌓이는 부채를 의미한다.

프로젝트나 제품을 개발하거나 투자할때에 대한 결정은 지금까지 들인 노력과 비용을 무시해야 하지만, 무시해서 결정하는 경우는 거의 일어나지 않는다. 그 돈과 시간을 썼다는 사실이 공정하고 객관적으로 결정을 평가하는 능력을 감소시킨다.

다시 원숭이 이야기로 돌아와서, 원하는 쇼를 성공하기 위해서는 어떻게 해야 할까?

우선, 원숭이가 받침대에 올라가서 균형을 잡기전에 횃불을 다룰 수 있는지를 확인하는 것이 필요하다. 즉, 초기에 확인해야 하는 것들이 나중에 큰 문제를 막을 수 있다.

프로젝트를 진행하다보면, 잘못된 결정을 할 수 있다. 하지만 이미 쏟아부은 시간과 돈 때문에 잘못된 방향으로 계속 가는 것은 현명하지 않다. 원숭이가 횃불을 떨어뜨린다면 잠시 중단하고 새로 기획하는게 더 나을 수 도 있다.

프로젝트를 진행하는 도중에는 주변 상황이 변할 수 있다. 상황이 변하면 계획도 유연하게 바꿔야 한다. 원숭이가 받침대에서 떨어질 것 같으면, 새로운 받침대를 준비하는 것도 방법이다.

위에서 언급한 원숭이 사례는 단순한 비유 이상의 의미를 갖는다. 프로젝트 관리 이론을 현실에 적용할 때 마주치는 도전을 상기시킨다. 그리고 실질적인 해결책을 제시한다.

새로운 프로젝트를 준비한다면, 프로젝트에 "원숭이"가 올라타고 있지는 않은지 확인해야 한다. 그리고 그 원숭이를 내려놓을 용기를 내야 한다.

이렇게 해야 이론과 행동의 간극을 좁혀가면서 프로젝트를 진행할 수 있다.

Read More

오픈소스 LLM(Large Language Model)

LLM(Large Language Model)을 선택할 때는 두 가지 경로가 있다. 오픈소스냐 아니냐이다.

본 글에서는 오픈소스 LLM을 선택할 때의 이점을 살펴본다.

생성형 AI가 많이 쓰여짐에따라 방대한 데이터를 분석하고, 비즈니스 전략을 수립하고, 상호작용을 간소화하고, 고객에게 개인화된 응답을 제공할 Needs가 있을 수 있다. 이럴 경우 기술 스택에 대한 고려를 해야 할 시점에 있을 수 있다.

“상용 서비스를 사용해야 할까? 아니면 오픈소스 LLM을 선택해야 할까?”

물론, 처음부터 완전한 맞춤형을 사용하는 것은 매력적일 수 있다. 실제로 LLM은 시간, 돈, 노력을 들일 만한 가치가 없는 대규모 사업일 수 있다. 비용, 확장 및 업데이트의 어려움, 환경적 영향 등 고려해야 할 단점이 존재한다.

많은 리더들은 LLM을 처음부터 완전하게 훈련하지 않고도 사용할 수 있다는 사실을 깨닫지 못한다. 오픈소스 모델에는 이미 기초적인 지식과 기술이 포함되어 있다. 그리고 자체 데이터를 추가하여 정의하고 생성 AI 쿼리에서 훌륭한 결과를 얻는 데 필요한 컨텍스트를 제공할 수 있다.

대부분의 회사는 활용되지 않거나 갇힌 데이터처럼 보물 창고를 가지고 있다. 즉, 여러 팀, 조직 또는 문서에 분산되거나 Silo된 데이터를 의미한다. 이런 데이터는 구조화된 데이터(엑셀, 데이터베이스)와 구조화되지 않은 데이터(로그, 채팅 로그, 이메일)로 구분된다.

에릭 레이몬드의 “성당과 시장”이라는 책을 보면 상용 솔루션과 오픈소스 진영에 대한 이야기가 나온다. AI 시대에도 이런 움직임이 있다. 독점 시스템의 장벽을 허물어 전 세계의 개발자, 연구자, 열광자들이 기초 모델에 기여하고, 수정하고, 개선하도록 노력하고 있다.

이런 커뮤니티 기반의 협력 모델은 해당 분야의 발전을 가속화할 뿐만 아니라 AI 기술의 이점을 더 광범위하게 이용할 수 있도록 보장한다.

나도 이번에 LLM 관련해서 준비해야 할 것이 있고, 접근을 오픈소스 기반으로 하고 있기에., 관련 내용을 정리해본다.

오픈 소스 LLM이란?

오픈소스 LLM은 인간 언어를 이해하고, 생성하고, 조작하도록 설계된 AI 모델의 유형이다. 오픈소스라는 것은 모델의 아키텍처, 코드, 모델 등 누구나 자유롭게 사용, 수정, 배포할 수 있다는 것을 의미한다. 높은 가용성과 낮은 비용은 AI 개발에 대한 협력적이고 투명한 접근 방식을 촉진한다.

오픈소스 LLM은 유일한 LLM은 아니다. 그러나 가장 널리 접근 가능한 모델이다.

오픈 소스 LLM은 독점 LLM과 어떻게 다른가?

오픈 소스 LLM은 주로 접근성과 적응성에서 독점적인 대응 제품과 다르다. 오픈소스 모델은 사용, 수정 및 배포를 위해 무료로 제공된다. 이런 특징은 혁신에 대한 협력적 접근 방식을 장려하고 특정 요구 사항에 대한 수정을 허용한다.

이와 대조적으로 독점적인 LLM은 특정 회사가 통제하고 소유한다. 공급업체는 라이선스 등 LLM에 대한 접근을 제한하고, 특정 요구 사항에 대한 수정을 제한한다.

이런 근본적 차이는 해당 모델을 제공하는데 드는 비용과 유연성에 영향을 미친다.

오픈 소스 LLM의 이점

ChatGPT가 세상에 공개되자마자 OpenAI의 GPT 모델은 빠르게 유명해졌다. 하지만 해당 모델은 많은 비용이 동반되어야 하기에 많은 기업들이 대규모 모델에 투자하는 것의 가치에 의문을 제기하기도 했다.

이에 따라 많은 기업이 소규모의 개방형 LLM을 선택하여 RAG(Retriever-And-Generator) 파이프라인을 활용하여 데이터를 통합하고 비슷하거나 더 뛰어난 효율성을 달성하고 있다.

고려해 볼 만한 폐쇄형 LLM에는 여러가지 장점이 있다.

비용 효율성

오픈소스 LLM은 독점적 모델에 비해 비용 효율적인 대안을 제시하여 기업이 AI 역량을 활용할 수 있는 재정적으로 실행 가능한 수단을 제공한다.

• 라이센스 비용이 필요하지 않기에 초기 비용과 지속적인 비용 절감을 기대할 수 있다.

• 해당 모델을 자유롭게 조직내에 배포할 수 있다.

• 특정 맞춤형 서비스가 가능하기에 효율성이 향상될 수 있다.

데이터 소유권 및 제어

오픈소스 LLM을 활용하는 것은 데이터에 대한 통제력과 소유권을 확보하여 다양한 매커니즘을 통해 보안을 강화한다.

• 데이터 호스팅 제어

• 온프레미스 또는 신뢰할 수 있는 클라우드 공급자의 호스팅을 선택

• 민감한 데이터를 보호하는게 중요하다.

• 내부 데이터 처리

• 민감한 데이터 유출을 방지한다.

• 데이터 침해 위험을 줄이고 개인 정보 보호를 강화한다.

• 투명성

• 오픈 소스 특성으로 인해 코드와 프로세스 감시가 가능하다.

• 내부 규정 준수 기준에 부합하는지 확인이 가능하다.

오픈 소스 LLM을 사용하는 기업

전 세계 다양한 기업이 오픈 소스 LLM을 활용하고 있다.

Shopify

Shopify는 Llama 2를 활용하여 LLM을 채택했다. 이 도구는 소규모 업체가 상거래 관리와 관련된 작업을 자동화하도록 지원한다.

상품 설명을 생성하고, 고객 문의에 답변하고, 마케팅 콘텐츠를 만들어 시간을 절약하고 운영을 간소화하는데 도움이 된다.

Perplexity

Perplexity가 오픈 소스 LLM을 활용하는 방법은 다음과 같다.

응답 생성 프로세스

사용자가 질문을 하면 Perplexity 엔진은 약 6단계를 실행하여 답변을 작성한다. 이 프로세스에는 여러 언어 모델을 사용하여 포괄적이고 정확한 답변을 제공하고자 한다.

Perplexity는 자체적으로 개발한 오픈 소스 LLM을 사용한다. Mistral 및 Llama와 같은 기존 프레임워크를 개선한 이 모델은 사용자의 문의와 관련된 콘텐츠를 간결하게 요약하도록 맞춤화 되어 있다.

오픈 소스 LLM을 활용한 사례 및 가능성

오픈 소스 LLM은 다양한 산업과 애플리케이션에서 수많은 기회를 열어주었다. 다음은 오픈소스 LLM의 잠재력에 대한 일반적인 사용 사례와 가능성이다.

챗봇 및 대화형 에이전트

오픈소스 LLM은 자연스럽고 의미 있는 대화에 참여할 수 있는 정교한 챗봇을 만들 때 사용할 수 있다.

콘텐츠 생성

블로그 게시물과 마케팅 카피 및 스토리텔링까지 오픈소스 LLM은 고품질 콘텐츠를 빠르고 효율적으로 생성할 수 있다. 사용자는 해당 모델을 사용하여 아이디어를 브레인스토밍하고, 기사 초안을 작성하거나, 반복적인 쓰기 작업을 자동화할 수 있다.

코드 생성 및 지원

코드 스니펫을 생성하고 기존 코드를 디버깅함으로써 개발자를 지원할 수 있다. Copilot, Cursor AI등으로 이미 입증되었으며, 오픈소스 대안으로 공급업체에 묶이지 않고도 유사한 기능을 제공할 수 있다.

감정 분석 및 텍스트 분류

내가 중점을 가지고 보고 있는 사안이다. 감정 분석을 위해 오픈 소스 LLM을 활용하여 리뷰 또는 피드백에서 고객 의견을 측정할 수 있다. 텍스트 분류 모델은 대규모 데이터 세트를 구성하는데 도움이 되고 구조화되지 않은 데이터에서 통찰력을 추출하는 것을 쉽게 만들어준다.

교육 도구

LLM은 강력한 교육 도구로 활용될 수 있다. 학습자의 진도와 선호도에 따라 콘텐츠를 조정하는 개인화된 학습 경험, 튜터링등을 제공 할 수 있다.

연구 개발

실험과 가설 검증을 수행할 수 있다. 모델을 수정할 수 있는 능력은 새로운 이론을 시험하고, 방법을 탐구할 수 있게 해준다.

오픈 소스 LLM 시작하기

처음에는 어려울 수 있으나, 과정은 간단할 수 있다. 아래는 LLM에 대해서 시작하기 위한 단계이다.

1단계: 사용 사례 식별

기술적인 측면에 들어가기 전에 LLM으로 무엇을 성취하고 싶은지 정의하는 것이 중요하다.

“LLM을 이용해 무엇을 하고 싶은가?” 에 대한 질문에 답을 할 수 있어야 한다. 그래야 필요에 맞는 올바른 모델과 도구를 선택할 수 있다.

2단계: LLM 선택

사용 사례에 적합한 LLM을 선택하는 것이 중요하다.  성능, 확장성, 커뮤니티 지원 등과 같은 요소를 고려하여 사용 가능한 모델을 조사해야 한다. 현재 인기 있는 오픈소스 LLM은 다음과 같다.

• Llama

• 장점: 성능과 확장성으로 유명하다. 다양한 애플리케이션을 위해 다재다능하게 설계되었다. 속도와 품질 간의 균형을 제공하여 대화형 AI 및 콘텐츠 생성과 같은 작업에 적합하다.

• 응용 분야: 챗봇, 글쓰기 도우미, 교육 도구

• CodeZen

• 장점: 코드 생성에 특별히 맞춤화되어 있다. 고품질 코드 스니펫을 생성하고 개발자에게 제안을 하는데 뛰어나다.

• 응용 분야: 소프트웨어 개발, 디버깅 지원, 코딩 교육

• MIXTRAL

• 장점: 다양한 텍스트 관련 작업에서 성과를 향상시키기 위해 여러 가지 훈련 기술을 결합한다. 다양한 맥락에 적응할 수 있도록 설계되어 많은 사용 사례에서 좋은 결과를 낸다.

• 응용 분야: 텍스트 분류, 감정 분석, 개인화된 콘텐츠 생성

• Falcon

• 장점: 효율성과 속도가 뛰어난 것으로 알려져 있다. 챗봇이나 실시간 콘텐츠 생성과 같은 분야에 적합하다.

• 응용 분야: 고객 지원, 대화형 인터페이스, 실시간 데이터 처리

• GPT-NeoX-20B

• 장점: 200억 개의 매개변수를 갖춘 상업용 LLM에 대한 가장 큰 오픈소스 대안 중 하나이다. 일관되고 맥락적으로 관련성 있는 텍스트를 생성하는데 안정적인 성능을 제공한다.

• 응용 분야: 복잡한 콘텐츠 생성, 학술 연구, 글쓰기

• Ollama

• 장점: 로컬 실행으로 데이터 프라이버시를 보장하며, 비용 효율성과 맞춤화가 뛰어나 개인 장치에서 강력한 LLM을 운영하기에 최적이다.

• 응용 분야: 코드 생성, 의료 데이터 분석, 교육 지원, 고객 서비스 챗봇, 콘텐츠 제작

각 모델은 다양한 분야에 적합한 장점을 지니고 있다.

3단계: 환경 설정

선택한 LLM을 실행하려면 적합한 환경이 필요하다. 로컬 머신이나 클라우드 기반일 수 있다. 진행 방법은 다음과 같다.

• 로컬: 머신에 충분한 연산 능력(가급적으로는 GPU)이 있다면, TensorFlow나 PyTorch와 같은 필수 라이브러리를 설치하여 모델을 로컬에서 실행할 수 있다.

• 클라우드: 하드웨어를 관리하지 않으려는 사람들을 위해 AWS, Google과 같은 다양한 플랫폼이 LLM에 대한 클라우드 기반 접근을 제공한다.

4단계: 모델 액세스

오픈소스 LLM은 모델을 다운로드하고 구현하기 위한 사용자 친화적인 인터페이스를 제공한다.

5단계: 미세 조정 및 정의

모델에 액세스하면 사용 사례와 일치하는 특정 데이터에 대해 모델을 미세 조정할 수 있다. 필요한 데이터 세트에 대해 추가로 학습하여 요구 사항에 맞게 더 나은 성능을 발휘할 수 있도록 하는 것이 포함된다.

6단계: 모델 배포

모델을 훈련하고 테스트한 후 마지막 단계를 배포다. 사용 사례에 따라 모델을 애플리케이션에 통합하거나 웹 서비스로 설정하여 배포할 수 있다.

결론

오픈소스 LLM은 접근성을 개방하여 혁신을 촉진하고 산업 전반에 걸친 다양한 응용을 활성화하고 있다. 오픈소스의 등장은 혁신, 창의성, 생산적 관점에서 AI의 진보가 그 어느 때보다 협력적이고 접근하기 쉬운 새로운 시대를 알리는 신호이다.

여기에 승선하여 몸 담고 있는 곳에서 미래를 향한 길을 밝힐 필요가 있다.

Read More