분산 시스템 이해하기

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

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

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

다시 원래 이야기로 돌아와서, 성능을 높이기위해서는 한 명의 계산원이 계산을 하는데 걸리는 시간을 정확하게 측정을 해야 한다. 주문을 받고, 카드를 받고, 계산하기까지의 과정에서 걸리는 시간을 측정해야 한다. 그리고 병렬로 이루어지지 않는다. 계산원은 한 번에 한 사람 이상을 서비스 하지 않는다. 시스템의 단일 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

DB 설계: 축약어 vs 풀네임, 어떤 것을 선택할까?

프로젝트 진행을 준비중인데., 함께 일하는 동료가 질문을 했다.

“레거시 시스템들은 모두 축약어로 되어 있던데., 새로 생성하는 디비 설계 시 축약어를 써야 할까요?”

“그 축약어가 사람이 인지하기 쉽던가요? 어렵던가요?”

“어렵죠. ERD 논리모델로 봐야 이해가 되는데., 이게 현행화가 안되어 있는 경우가 많아요.”

이런 대화를 나누다가 문득 궁금해졌다. Gen AI가 활발하게 사용되고 있는 2025년 왜 우리는 이런 이야기를 해야 하는가? 그래서 찾아본 내용을 글로 정리한다.

데이터베이스(DB) 설계는 모든 프로덕트의 뼈대다. 그러나 테이블명과 컬럼명을 정할 때, 축약어를 사용할지 풀네임을 사용할지 의견이 갈린다. 현재 트렌드는 무엇이고, 왜 이런 논쟁이 생겼는지 살펴보자.

축약어의 기원과 이유

과거에는 시스템 자원의 한계와 데이터베이스 성능 최적화가 중요한 이슈였던 시절이 있었다. 특히 초기 컴퓨터 환경에서는 저장 공간이 부족했고, 네트워크 속도나 처리 능력이 제한적이었기 때문에, 테이블이나 컬럼 이름을 짧게 줄여서 사용하는 것을 선호했다.

예를 들어, cust(customer), addr(address), emp(employee)와 같은 축약어가 널리 사용되었다. 이렇게 축약어를 사용함으로써 데이터베이스의 공간을 절약하고 코드의 길이를 줄일 수 있었던 것이다.

하지만 이 방식에는 문제가 있었다. 축약어가 지나치게 많거나 모호하게 사용되면, 새로 투입되는 사람은 이를 이해하기 어려워지는 문제가 있다. 또한, 데이터베이스의 구조가 점점 복잡해지고 많은 데이터가 관리되는 상황에서 직관적인 이름이 더욱 중요한 요소로 떠오르게 되었다.

즉, 축약어는 효율성을 상징했지만, 가독성을 희생시켰다.

현재 트렌드

현재는 데이터베이스 테이블과 컬럼 이름을 지을 때, 명확하고 직관적인 이름이 중요시되고 있다. 이는 소프트웨어 개발의 전반적인 변화와 관련이 있다. 코드가 길어지고 복잡해지는 만큼, 개발자들은 가독성 높은 코드 작성을 추구한다. 데이터베이스 설계도 마찬가지로 직관적인 이름을 통해 사람들이 편의를 고려하는 방향으로 바뀌고 있다.

예를 들어, cust_name, usr_addr 처럼 축약어를 사용하기 보다는, customer_name과 user_address 처럼 풀네임을 사용하는 것이 일반적이다. 이렇게 하면 컬럼이나 테이블을 이해하는데 더 직관적으로 파악할 수 있어 유지보수와 디버깅이 훨씬 수월하다.

이렇게 바뀐 이유는 아래와 같다.

• 가독성 우선: 현대 개발은 협업과 유지보수가 핵심이라, 사람이 쉽게 이해하는 이름이 선호된다. 더군다나 Gen AI의 시대에서 말이다.

• 기술 진화: PostgreSQL은 63자, 오라클은 30자까지 식별자를 지원하며, 성능 차이는 미미하다. 축약의 필요성이 줄었다.

• 문서화 감소: 풀네임은 자체 설명적이기에 별도 명세서 없이도 이해가 가능하다.

• 클린 코드 철학의 확산: “클린 코드” 철학은 코딩 시 직관적이고 읽기 쉬운 코드를 작성하는데 초점을 맞추고 있다. DB 설계도 예외는 아니다.

• 협업 및 확장성: 프로덕트가 점점 커짐에 따라 다른 사람이 이해하기 쉬운 이름이 더욱 중요해졌다. 축약어가 많으면 혼란을 초래할 수 있다.

그러나 레거시 시스템이 많은 곳은 아직도 축약어의 잔재가 남아있다. 혹은 도메인별 관습이 강한 경우에도 축약어가 남아 있는 경우가 있다.

결론

데이터베이스 설계에서 이름 짓기는 단순히 개인적인 취향의 문제가 아니다. 시간과 기술의 발전에 따라 더 이상 축약어만을 고집하기보다는 직관적이고 명확한 이름을 사용하는 것이 더욱 중요해졌다.

물론, 간단한 약어는 여전히 유용할 수 있지만, 그 사용은 줄어들고 대신 풀네임을 사용하여 가독성과 유지 보수성을 높이는 것이 꽤 오래전부터 트렌드로 자리잡고 있다.

끝으로,

이 글을 읽는 분들은 https://vertabelo.com/blog/database-naming-convention/ 링크를 참고해서 최악을 피했으면 좋겠다.

Read More

Cursor AI 사용해보고 느낀 점

 

처음에는 Cursor AI IDE를 그저 또 다른 AI 코딩 도구로 간주했었다.

Cursor AI, Windsurf, Cline등 다양한 것을 써보고, 지금 시점에는 관점이 상당히 바뀌었기에 이에 대해 글을 쓰기로 결정 했다.

AI 코딩 도구에 대한 나의 핵심 철학은 방대한 양의 코드를 생성하는 것이 아니다.

대신, 진부하고 지루한 작업을 처리하고, 반복적인 코딩 작업을 가속화하여, 비즈니스 로직, 아키텍처, 문제 해결등에 집중할 수 있게 해주는 비서를 찾는 개념이다.

Cursor AI에 대한 현재까지의 나의 느낌은 빠른 프로토타입 개발에서 빛을 발하고, 반복적인 코딩 블록에 대한 인지 부하를 줄여준다고 생각된다. 같이 사용하고 있는 동료도 나와 같은 생각을 하고 있고, 현재는 리팩토링 관점에서 접근해보고 있다.

기능

Cursor는 AI 기반 IDE 이다.

Cursor AI는 Visual Studio Code의 포크이다. LLM(Large Language Model)기능을 사용자 인터페이스에 통합했다. 개인적인 취향으로는 Active bar가 왼쪽 사이드에 위치하지 않는게 아쉽긴 하다. (이건 익숙해지면 되니까…)

Cursor는 무료와 유료 구독이 있고, 현재 회사의 지원으로 비즈니스 구독 모델을 사용중이다. Cursor는 개발자가 IDE 환경과 LLM 사이의 상호 작용하는 방식을 혁신하고자 한다. 실제로 사용해보면 코딩 경험이 꽤 좋고, 재미가 생긴다.

이런 기능은 인지적 부하를 줄이도록 해주며, 개발을 가속화하기 위한 Concept이라고 생각한다. Cursor를 사용하면 브라우저에서 검색하거나 ChatGPT에서 질문하고 코드를 복사하여 붙여넣을 필요가 없다.

이제 주요 특징을 살펴보자.

탭 완성

탭 완성 기능은 자동 완성과 다르게 코드를 예측하고 권장되는 코드를 탐색하는데 도움이 된다. 간단하게 탭을 누르면 된다. 옆에서 숙련된 개발자가 다음 코드를 언급해주는 것과 비슷하다.

일반적으로 대화 방식의 인터페이스에 주로 의존하는 것과 다르게, Cursor의 탭 완성 기능은 개발자의 작업 흐름을 자연스럽게 확장해주는 느낌이다.

맥락을 이해하고 있으며, 다음 코드를 추천해주는 것이 생각보다 똑똑하다.

인라인 편집

인라인 편집은 코드 수정을 위한 채팅 기반 인터페이스를 제공한다. 코드 블록을 선택하고 AI가 개선 사항이나 리팩토링을 제안하기에 다른 관점에서 도움을 받을 수 있다. 코드를 선택하고 Cmd/Ctrl-K을 누르면 기존 코드의 컨텍스트 내에서 변경 사항을 제안한다.

Diff 뷰를 생성하여 Accept 전에 제안된 수정 사항을 즉시 시각화할 수 있다. 이 기능은 특히 작은 코드 세그먼트를 구현하거나 특정 기능 내에서 사소한 리팩토링 작업을 실행하는데 유용하다.

채팅

채팅을 통해 개발자는 코드에 대해 AI와 논의를 할 수 있고, 복잡한 리팩토링 시나리오를 시뮬레이션 해 볼 수 있다.

AI와 “페어 프로그래밍”을 하면서 코드에 대한 전체 맥락을 이해할 수 있다. 또한 특정 파일에 태그를 지정하고 질문을 할 수 있다.

채팅 사이드바는 더 포괄적인 상호작용을 위한 대화 공간이다. Cmd/Ctrl-L 을 누르면 AI와의 대화를 위한 공간을 제공한다.

Composer

이건 정말 강력한 기능이다. 여러 파일에 걸쳐 diff을 생성하고 개발자가 체계적으로 변경 사항을 보면서 승인을 할 수 있는 인터페이스다.

여러 파일에 걸쳐 순차적으로 수정 사항을 검토하고 적용하기 위한 체계적인 워크플로우를 제공한다. 또한 사용자는 모델을 변경할 수 있다. 참고로 나는 Claude 3.5 Sonnet 모델을 사용한다.

결론

IDE에 AI를 통합하는 것은 매우 훌륭한 작업이라고 생각한다. Text를 다루는 것은 LLM이 잘하는 일이고 코딩은 그저 “텍스트” 데이터라고 볼 수 있기에 코딩에 엄청난 영향을 미칠 것으로 생각된다. 당분간은 인간의 작업을 도와주고 개선시켜주는 도구로써 활용하는 것으로 생각하고 있다. 아마도 인간을 대체한다는 목표보다는 개선 관점에 더 발전할 것이다.

Cursor를 사용하는 것은 나뿐만 아니라 주변 동료들에도 엄청난 생산성 향상을 가져다주었다. Cursor를 이용하여 MVP를 만들기전까지는 예상하지 못했던 일이었는데, 상당한 코딩 경험이 있는 개발자분들께는 추천하고 싶다. 주니어 개발자의 경우는 AI를 써도 나쁘진 않지만, 본인 생각과 경험도 매우 중요하기에 학습 경험을 방해하지 않는 선에서 사용했으면 좋겠다.

어제인가? Okky에서 생성형 AI와 주니어 개발자 채용 관련 인터뷰 요청이 있었다. 아직 인터뷰를 진행 하진 못했지만 생각 일부를 정리해본다.

“프로그래밍” 이라는 용어는 실제로는 공통된 목표를 향해 나아가는 몇 가지 활동이다. 즉, “컴퓨터”가 특정 프로세스를 시뮬레이션하도록 하는 것이다. “프로그래밍”은 아이디어를 인간 중심 언어에서 기계 중심 언어로 번역하는 과정이며, 이것은 다시 기계어로 번역된다.

사람들이 컴퓨터로 하기를 원하는 대부분은 누군가의 머릿속에 있다. 이를 꺼내기 위해서는 “분석”이 필요한데, 누군가를 인터뷰하여 프로세스화 하는 것과 비슷하다. 혹은 시니어 개발자가 설계 문서를 작성하는 것과 같다.

아마도 이 관점에서 AI는 코딩 부분을 대부분 사라지게 할 것이라고 생각한다. 아쉽지는 않다. 더 창의적인 일에 몰두 할 수 있기 때문이다. 이유는 코딩은 “프로그래밍” 프로세스에서 가장 비효율적인 부분이라고 생각하기 때문이다. 아이디어 혹은 로직을 코드로 표현하는 것은 식물을 키우는 과정과 비슷하기 때문이다. 이 작업은 꽤 지루하기도 하고, 반복되는 부분에서는 즐겁지 않다.

AI에게 무엇을 할지 알려주는 일은 지금도 어느 정도는 인간의 몫이고, 적어도 소프트웨어를 전공한 사람들이 이 일을 하는데 가장 적합하다고 생각한다. AI는 컴퓨터가 우리가 원하는 것을 시뮬레이션하도록 하는 전반적인 프로세스를 변화시킬 것이고, “코딩” 부분에서 인간의 역할은 점점 작아질 것이고, “분석” 부분은 크게 변화할 것이라고 생각한다.

물론, AI가 올바른 코드를 생성했는지는 사람이 보긴해야 한다. AI가 생성한 코드를 신뢰만 하고, 코드가 잘못되었는지를 이해하지 못하면 문제가 발생할 수 있다.

주변 동료들의 이야기를 언급하며, 글을 마친다.

“룰 세팅하고, 요구 사항을 명확히하여 지시하니, 생각보다 훌륭한데요?”

“얘는 쉬지도 않고, 불만도 없어요.”

“제가 힌트를 주니깐, 동의하며 바로 이해하는데요? 재미가 있어요.”

“상황에 따라, 주니어 개발자 혹은 시니어 개발자가 옆에 있는 느낌이에요.”

“레거시 인터페이스에 대해서는 아직 약한것 같아요. 한편으로는 컨트롤 및 분석 역할을 제가 할 수 있어서 다행이에요.”

Read More