LLM 기반 서비스의 부하테스트
웹 서비스를 준비하는 과정에서 부하테스트는 서비스 운영 중 발생할 수 있는 문제를 미리 파악하는 데 필수적인 단계입니다.특히 LLM(Large Language Model)을 활용하는 서비스는 기존 웹 서비스와는 다른 특성을 가지고 있기 때문에,이에 맞는 지표(Metric)를 정확히 이해하고 적절한 테스트를 진행하는 것이 매우 중요합니다.이 글에서는 LLM 기반 서비스의 부하테스트에서 반드시 확인해야 하는 주요 Metric과 간단한 예제를 함께 정리하여 설명합니다.여기서는 대표적으로 많이 사용되는 프레임워크인 vLLM을 기준으로 설명하나, 다른 프레임워크를 사용하더라도 핵심 원리와 지표 측정 방식은 크게 다르지 않으므로 참고하시면 좋을 것 같습니다.LLM을 이용한 서비스는 일반적으로 대화형(Chat) 기반으로 설계됩니다.기존 API 서비스가 요청 처리 후 최종 데이터를 JSON 형태나 바이너리 등 완결적 결과를 주로 전달하는 반면, LLM 서비스는 생성되는 답변을 실시간으로 스트리밍 형태로 제공합니다.이에 따라 사용자의 첫 번째 응답까지 걸리는 시간(TTFT), 각 토큰 생성 시간, 평균 응답 길이 등과 같이 전통적인 웹 서비스와는 차별화된 Metric을 사용하여 테스트해야 합니다.또한 이 새로운 Metric들을 기존 서비스와 비교하기 위해 다른 형태로 환산하거나 분석하는 경우도 흔히 발생합니다.부하테스트에서 중요하게 측정하는 MetricLLM 서비스를 제공할 때 가장 중요한 두 가지 요소는 지연 시간(Latency)과 처리량(Throughput)입니다. 세부적인 Metric을 살펴보면 다음과 같습니다.• None TTFT(Time To First Token): 사용자가 요청 후 첫 번째 토큰을 받을 때까지 걸리는 시간으로, 체감 응답 속도를 가장 잘 나타냅니다. vLLM에서는 로 측정합니다.• None 총 대기 시간: 요청이 시작되어 최종 응답까지 걸리는 전체 시간으로, 긴 출력이 예상되는 서비스에서는 특히 중요합니다. vLLM에서는 로 확인합니다.• None 토큰당 생성 시간: 각 토큰 생성에 걸리는 평균 시간을 나타내며, vLLM에서 로 측정됩니다.• None 토큰 처리량: 초당 생성되는 토큰 수(tokens per second, TPS)로 서비스의 성능을 평가할 때 가장 흔히 사용하는 지표입니다.• None 요청 처리량: 초당 처리 가능한 요청 수를 의미하며, 시스템 전체 성능을 평가하는 데 매우 중요합니다.만약 vLLM 을 사용해서 서비스를 구성한다면, vLLM 기반 부하테스트는 vLLM에서 제공하는 benchmark_serving.py를 사용해 쉽게 진행할 수 있습니다. 샘플 스크립트는 다음과 같습니다.각 인자의 의미는 다음과 같습니다.• None dataset-name: 사용 데이터셋 유형( 는 Hugging Face 데이터셋 사용 시 지정)부하테스트의 예시 결과는 아래와 같습니다.이 중 주요하게 봐야 할 Metric은 Mean TTFT, Mean ITL, Request throughput, Output token throughput입니다.예를 들어 평균 100 토큰을 생성하는 서비스라면, 사용자가 최종적으로 답변을 받기까지 약 4.5초 정도 소요될 것으로 예상할 수 있습니다(598.11ms + 100 토큰 × 41.94ms).여기서 **TPOT(Time per Output Token)**는 토큰 자체의 순수 생성 시간이고, **ITL(Inter-token Latency)**은 생성된 토큰이 사용자에게 실제 전달될 때까지 걸리는 지연 시간입니다.따라서 ITL이 실질적인 사용자 체감 속도를 더 정확히 나타냅니다.특히, 평균값과 중간값 간 큰 차이가 있을 경우 스파이크 등 외부 요인으로 인한 성능 저하 가능성을 염두에 두고, 추가 분석을 진행해야 합니다.또한, 높은 P99 값(예: TPOT 43.4ms 대비 ITL 326.1ms)이 나타날 경우 네트워크나 시스템 구성에 잠재적 문제가 있는지 점검하는 것이 필요합니다.LLM 서비스를 준비할 때는 기존 웹 서비스와는 차별화된 지표들을 명확히 이해하고, 이를 바탕으로 철저한 부하테스트를 진행해야 합니다.특히 TTFT와 ITL, 토큰 처리량 등의 데이터를 면밀히 분석하여 사용자 체감 성능을 최적화하는 것이 중요합니다.또한 Metric을 통해 도출된 데이터를 토대로 시스템 전반의 문제점을 파악하고, 네트워크 환경을 포함한 다양한 요소를 점검한다면, 보다 견고한 서비스로 발전시킬 수 있을 것으로 생각됩니다.
4/24/2025
LLM 기반 서비스의 부하테스트
웹 서비스를 준비하는 과정에서 부하테스트는 서비스 운영 중 발생할 수 있는 문제를 미리 파악하는 데 필수적인 단계입니다.특히 LLM(Large Language Model)을 활용하는 서비스는 기존 웹 서비스와는 다른 특성을 가지고 있기 때문에,이에 맞는 지표(Metric)를 정확히 이해하고 적절한 테스트를 진행하는 것이 매우 중요합니다.이 글에서는 LLM 기반 서비스의 부하테스트에서 반드시 확인해야 하는 주요 Metric과 간단한 예제를 함께 정리하여 설명합니다.여기서는 대표적으로 많이 사용되는 프레임워크인 vLLM을 기준으로 설명하나, 다른 프레임워크를 사용하더라도 핵심 원리와 지표 측정 방식은 크게 다르지 않으므로 참고하시면 좋을 것 같습니다.LLM을 이용한 서비스는 일반적으로 대화형(Chat) 기반으로 설계됩니다.기존 API 서비스가 요청 처리 후 최종 데이터를 JSON 형태나 바이너리 등 완결적 결과를 주로 전달하는 반면, LLM 서비스는 생성되는 답변을 실시간으로 스트리밍 형태로 제공합니다.이에 따라 사용자의 첫 번째 응답까지 걸리는 시간(TTFT), 각 토큰 생성 시간, 평균 응답 길이 등과 같이 전통적인 웹 서비스와는 차별화된 Metric을 사용하여 테스트해야 합니다.또한 이 새로운 Metric들을 기존 서비스와 비교하기 위해 다른 형태로 환산하거나 분석하는 경우도 흔히 발생합니다.부하테스트에서 중요하게 측정하는 MetricLLM 서비스를 제공할 때 가장 중요한 두 가지 요소는 지연 시간(Latency)과 처리량(Throughput)입니다. 세부적인 Metric을 살펴보면 다음과 같습니다.• None TTFT(Time To First Token): 사용자가 요청 후 첫 번째 토큰을 받을 때까지 걸리는 시간으로, 체감 응답 속도를 가장 잘 나타냅니다. vLLM에서는 로 측정합니다.• None 총 대기 시간: 요청이 시작되어 최종 응답까지 걸리는 전체 시간으로, 긴 출력이 예상되는 서비스에서는 특히 중요합니다. vLLM에서는 로 확인합니다.• None 토큰당 생성 시간: 각 토큰 생성에 걸리는 평균 시간을 나타내며, vLLM에서 로 측정됩니다.• None 토큰 처리량: 초당 생성되는 토큰 수(tokens per second, TPS)로 서비스의 성능을 평가할 때 가장 흔히 사용하는 지표입니다.• None 요청 처리량: 초당 처리 가능한 요청 수를 의미하며, 시스템 전체 성능을 평가하는 데 매우 중요합니다.만약 vLLM 을 사용해서 서비스를 구성한다면, vLLM 기반 부하테스트는 vLLM에서 제공하는 benchmark_serving.py를 사용해 쉽게 진행할 수 있습니다. 샘플 스크립트는 다음과 같습니다.각 인자의 의미는 다음과 같습니다.• None dataset-name: 사용 데이터셋 유형( 는 Hugging Face 데이터셋 사용 시 지정)부하테스트의 예시 결과는 아래와 같습니다.이 중 주요하게 봐야 할 Metric은 Mean TTFT, Mean ITL, Request throughput, Output token throughput입니다.예를 들어 평균 100 토큰을 생성하는 서비스라면, 사용자가 최종적으로 답변을 받기까지 약 4.5초 정도 소요될 것으로 예상할 수 있습니다(598.11ms + 100 토큰 × 41.94ms).여기서 **TPOT(Time per Output Token)**는 토큰 자체의 순수 생성 시간이고, **ITL(Inter-token Latency)**은 생성된 토큰이 사용자에게 실제 전달될 때까지 걸리는 지연 시간입니다.따라서 ITL이 실질적인 사용자 체감 속도를 더 정확히 나타냅니다.특히, 평균값과 중간값 간 큰 차이가 있을 경우 스파이크 등 외부 요인으로 인한 성능 저하 가능성을 염두에 두고, 추가 분석을 진행해야 합니다.또한, 높은 P99 값(예: TPOT 43.4ms 대비 ITL 326.1ms)이 나타날 경우 네트워크나 시스템 구성에 잠재적 문제가 있는지 점검하는 것이 필요합니다.LLM 서비스를 준비할 때는 기존 웹 서비스와는 차별화된 지표들을 명확히 이해하고, 이를 바탕으로 철저한 부하테스트를 진행해야 합니다.특히 TTFT와 ITL, 토큰 처리량 등의 데이터를 면밀히 분석하여 사용자 체감 성능을 최적화하는 것이 중요합니다.또한 Metric을 통해 도출된 데이터를 토대로 시스템 전반의 문제점을 파악하고, 네트워크 환경을 포함한 다양한 요소를 점검한다면, 보다 견고한 서비스로 발전시킬 수 있을 것으로 생각됩니다.
2025.04.24
좋아요
별로에요
Simplicity 25 : 한 번쯤 이상을 꿈꿔본 모두에게
일하면서 한 번쯤, 이상을 꿈꿔본 적이 있나요?빠른 문제해결이 중요한 토스에서도, 그 너머의 이상을 그리는 사람들이 있어요. 디자이너, 리서처, 라이터, 엔지니어링 등 다양한 분야에서 정교하고 아름다운 UX를 실현하기 위해 새로운 시도를 이어가고 있죠.하지만 현실은 쉽지만은 않아요.이번 시즌에서는, 일하는 누구나 꿈꿔본 이상을 현실로 만들기 위해 고군분투한 토스팀의 여정을 들려드려요. 우리는 어떤 고민을 했고, 어떻게 답을 찾았을까요?그래픽, 인터랙션, 엔지니어링, UX 라이팅, 리서치, 플랫폼 디자인까지, 총 14개의 이야기가 준비되어 있어요. 잠깐 들여다보실래요?토스다움을 완성하는 순간들이토록 아름다운 새로고침화면을 아래로 당기면 나오는 그래픽, Pull To Refresh. 그 짧은 찰나에 아름다움을 담기 위한 고민을 들려드려요.인터랙션으로 첫인상 만들기토스를 처음 써보는 외국인에게 토스를 어떻게 소개해야 할까? 모두가 감탄한 온보딩, 그 중심에는 인터랙션이 있었어요.IT 업계에 3D 그래픽이 넘쳐나는 시대. 토스는 어떻게 '토스다움'을 만들어냈을까요? 그 여정을 보여드려요.인터랙션 개발의 매력은 무엇일까요? 아름다움과 감각을 설계하는 세 명의 인터랙션 개발자가 답해드릴게요.2,800만 명이 쓰는 앱에서 7,000명의 스크린 리더 사용자 경험까지 챙기기 위해, 토스는 어떤 노력을 하고 있을까요?시각 장애인이 토스를 더 쉽게 쓰려면, 무엇이 달라져야 할까요? 리서치를 통해 얻은 세 가지 인사이트를 공유할게요.토스가 사용자 경험과 마주하는 법사용자가 원하는 기능을 잘 찾는지, 정성적인 경험도 이제 수치로 말할 수 있어요. 토스만의 새로운 기준으로요.모두가 유저를 만나는 순간까지일하느라 사용자를 만날 시간이 없다면, 점심시간은 어떨까요? 식사하며 사용자의 목소리를 듣는 토스 팀의 이야기를 들려드릴게요.UX가 AI를 만났을 때AI시대에 라이터로 살아남기AI는 UX라이터에게 위기이자 기회예요. 다크패턴을 계기로, 라이터에서 프롬프트 엔지니어로 성장한 이야기를 들려드려요.AI봇을 만들면서 배운 3가지사용자를 만나기 전에 가볍게 의견을 물어볼 수 있는 AI UT봇. ‘휴리봇’ 을 만들면서 배운 3가지들 알려드릴게요.토스 그래픽을 10초 만에 그리는 AI‘토스트’를 소개합니다. 인간이 3일 걸려 만드는 3D 그래픽을 10초 만에 만든다니, 퀄리티까지 따라올 수 있을까요?익숙함 너머, 본질을 보다동의 화면도 간결해질 수 있을까각종 법적 제한 때문에 자유롭지 않은 동의 화면 디자인. 관성을 깨면 얼마나 달라질 수 있을까요?토스가 디자인툴을 만든 이유스케치, 피그마, 프레이머… 모두 써봤지만 우리에게 딱 맞는 건 없었어요. 그래서 만들었습니다. 토스만의 디자인 툴, 데우스.아무도 쓰지 않는 디자인 시스템새로운 컴포넌트를 배포했는데, 왜 아무도 안 쓰지? 컴포넌트를 넘어서, 일하는 방식 자체를 바꿔보기로 했어요.Simplicity 25는 거창한 해답보다는, 현실 속에서도 이상을 놓지 않으려 한 태도에 대해 이야기 하려고 해요. "정말 이런 게 가능할까?
4/24/2025
Simplicity 25 : 한 번쯤 이상을 꿈꿔본 모두에게
일하면서 한 번쯤, 이상을 꿈꿔본 적이 있나요?빠른 문제해결이 중요한 토스에서도, 그 너머의 이상을 그리는 사람들이 있어요. 디자이너, 리서처, 라이터, 엔지니어링 등 다양한 분야에서 정교하고 아름다운 UX를 실현하기 위해 새로운 시도를 이어가고 있죠.하지만 현실은 쉽지만은 않아요.이번 시즌에서는, 일하는 누구나 꿈꿔본 이상을 현실로 만들기 위해 고군분투한 토스팀의 여정을 들려드려요. 우리는 어떤 고민을 했고, 어떻게 답을 찾았을까요?그래픽, 인터랙션, 엔지니어링, UX 라이팅, 리서치, 플랫폼 디자인까지, 총 14개의 이야기가 준비되어 있어요. 잠깐 들여다보실래요?토스다움을 완성하는 순간들이토록 아름다운 새로고침화면을 아래로 당기면 나오는 그래픽, Pull To Refresh. 그 짧은 찰나에 아름다움을 담기 위한 고민을 들려드려요.인터랙션으로 첫인상 만들기토스를 처음 써보는 외국인에게 토스를 어떻게 소개해야 할까? 모두가 감탄한 온보딩, 그 중심에는 인터랙션이 있었어요.IT 업계에 3D 그래픽이 넘쳐나는 시대. 토스는 어떻게 '토스다움'을 만들어냈을까요? 그 여정을 보여드려요.인터랙션 개발의 매력은 무엇일까요? 아름다움과 감각을 설계하는 세 명의 인터랙션 개발자가 답해드릴게요.2,800만 명이 쓰는 앱에서 7,000명의 스크린 리더 사용자 경험까지 챙기기 위해, 토스는 어떤 노력을 하고 있을까요?시각 장애인이 토스를 더 쉽게 쓰려면, 무엇이 달라져야 할까요? 리서치를 통해 얻은 세 가지 인사이트를 공유할게요.토스가 사용자 경험과 마주하는 법사용자가 원하는 기능을 잘 찾는지, 정성적인 경험도 이제 수치로 말할 수 있어요. 토스만의 새로운 기준으로요.모두가 유저를 만나는 순간까지일하느라 사용자를 만날 시간이 없다면, 점심시간은 어떨까요? 식사하며 사용자의 목소리를 듣는 토스 팀의 이야기를 들려드릴게요.UX가 AI를 만났을 때AI시대에 라이터로 살아남기AI는 UX라이터에게 위기이자 기회예요. 다크패턴을 계기로, 라이터에서 프롬프트 엔지니어로 성장한 이야기를 들려드려요.AI봇을 만들면서 배운 3가지사용자를 만나기 전에 가볍게 의견을 물어볼 수 있는 AI UT봇. ‘휴리봇’ 을 만들면서 배운 3가지들 알려드릴게요.토스 그래픽을 10초 만에 그리는 AI‘토스트’를 소개합니다. 인간이 3일 걸려 만드는 3D 그래픽을 10초 만에 만든다니, 퀄리티까지 따라올 수 있을까요?익숙함 너머, 본질을 보다동의 화면도 간결해질 수 있을까각종 법적 제한 때문에 자유롭지 않은 동의 화면 디자인. 관성을 깨면 얼마나 달라질 수 있을까요?토스가 디자인툴을 만든 이유스케치, 피그마, 프레이머… 모두 써봤지만 우리에게 딱 맞는 건 없었어요. 그래서 만들었습니다. 토스만의 디자인 툴, 데우스.아무도 쓰지 않는 디자인 시스템새로운 컴포넌트를 배포했는데, 왜 아무도 안 쓰지? 컴포넌트를 넘어서, 일하는 방식 자체를 바꿔보기로 했어요.Simplicity 25는 거창한 해답보다는, 현실 속에서도 이상을 놓지 않으려 한 태도에 대해 이야기 하려고 해요. "정말 이런 게 가능할까?
2025.04.24
좋아요
별로에요
제 2회 카카오페이 해커톤, 2025 카페톤 뜨거운 현장 이야기
dan.dy 사내 해커톤이 어떻게 진행되는지 궁금하시다면 이 글을 통해 생생한 현장으로 들어가 보시죠!안녕하세요, 카카오페이 Developer Relations 담당자 로라입니다.4월 14일~15일 양일간 두 번째 카카오페이 해커톤, 카페톤을 성공적으로 마쳤습니다. 무려 29개 팀, 138명의 크루와 함께한 이번 카페톤은 크루들의 열정으로 가득했는데요. 이틀 동안 후끈후끈했던 현장 함께 보실까요?카카오페이 해커톤, 카페톤은 2022년 온라인으로 시작했습니다. 사내 슬랙 도입에 맞춰 ‘슬랙봇 만들기’를 주제로 진행했었어요. 2022년 카페톤 수상작 살펴보기3년 만에 진행한 2025 카페톤은 드.디.어 오프라인으로 진행했답니다. 일반적으로 해커톤은 무박 2일로 진행하지만, 첫 오프라인 진행인 만큼 저희는 1박 2일 일정으로 진행했어요.• 예선: 참가 팀이 많아 예선은 팀별로 부스를 꾸려 부스 투어로 진행본격 카페톤 시작 전, 참가자 전원에게 웰컴 키트도 제공했답니다. 웰컴 키트에는 어두운 후드가 대부분인 크루들을 위해 밝은 후드 집업과 보조 배터리, 카페톤 참가 목걸이 3종을 담아 전달드렸어요.이번 카페톤은 AWS Generative AI 서비스를 활용해 크루들의 아이디어를 실현하고, AI 활용 역량을 높이는 것을 목표로 진행했어요. 사전에는 Amazon Bedrock과 SageMaker를 중심으로 한 원데이 교육을 진행했고, 행사 기간 내내 AWS의 아낌없는 기술 지원이 함께했습니다. 덕분에 참가한 모든 크루들이 AWS의 기본적인 활용법은 물론, 생성형 AI 모델 적용 경험까지 함께 얻을 수 있는 기회의 장이 되었답니다.처음으로 오프라인에서 진행해 더욱 특별했던 카페톤에서 크루들의 열정은 어땠을까요?DAY1 기획부터 개발까지 풀가동!막을 수 없는 크루들의 열정 열정 열정🔥DAY1 공식 행사 시간은 오전 10시부터 오후 10시까지였는데요. 크루들의 열정 앞에서 행사 시간은 큰 의미가 없었습니다. 행사 시작쯤 오늘 몇 시까지 계실 거냐는 질문에 자신 있게 ‘10시 전에는 가죠.’ 하던 크루들의 모습은 어디 가고, 공식 행사 시간인 오후 10시 이후부터는 ‘오늘 안에 갈 수 있을까요?’, ‘로라 설마 집에 가시나요?’ 질문만 돌아왔다는 후문이…한 번 시작하면 끝을 봐야 하는, 조금이라도 아쉬움이 없어야 하는 크루들의 열정 하나로 새벽까지 판교를 지킨 팀이 꽤나 되었답니다.빠질 수 없는 식사와 이벤트점심, 저녁 그리고 혹시 모를 밤샘 팀을 위한 CEO 앨런의 치맥 지원까지~~~🍗🍻 끝이 안 보이는 식사 제공으로 크루들이 이제 그만 먹으면 안 되냐고 할 정도였으면, 말 다 했죠?집중력이 흐트러질 타이밍에는 크루들의 집중력을 높이기 위한 카훗(Kahoot!) 퀴즈 이벤트를 진행했습니다. 카훗은 실시간으로 문제를 풀고 순위를 다투는 퀴즈 플랫폼으로, 간단한 클릭만으로도 모두가 함께 참여할 수 있어 짧은 시간에 현장 분위기를 확 띄울 수 있었어요. 재미난 이벤트를 제안하고 진행까지 해주신 AWS 진성님 감사합니다.해당 이벤트에서는 “이번 카페톤 참
4/24/2025
제 2회 카카오페이 해커톤, 2025 카페톤 뜨거운 현장 이야기
dan.dy 사내 해커톤이 어떻게 진행되는지 궁금하시다면 이 글을 통해 생생한 현장으로 들어가 보시죠!안녕하세요, 카카오페이 Developer Relations 담당자 로라입니다.4월 14일~15일 양일간 두 번째 카카오페이 해커톤, 카페톤을 성공적으로 마쳤습니다. 무려 29개 팀, 138명의 크루와 함께한 이번 카페톤은 크루들의 열정으로 가득했는데요. 이틀 동안 후끈후끈했던 현장 함께 보실까요?카카오페이 해커톤, 카페톤은 2022년 온라인으로 시작했습니다. 사내 슬랙 도입에 맞춰 ‘슬랙봇 만들기’를 주제로 진행했었어요. 2022년 카페톤 수상작 살펴보기3년 만에 진행한 2025 카페톤은 드.디.어 오프라인으로 진행했답니다. 일반적으로 해커톤은 무박 2일로 진행하지만, 첫 오프라인 진행인 만큼 저희는 1박 2일 일정으로 진행했어요.• 예선: 참가 팀이 많아 예선은 팀별로 부스를 꾸려 부스 투어로 진행본격 카페톤 시작 전, 참가자 전원에게 웰컴 키트도 제공했답니다. 웰컴 키트에는 어두운 후드가 대부분인 크루들을 위해 밝은 후드 집업과 보조 배터리, 카페톤 참가 목걸이 3종을 담아 전달드렸어요.이번 카페톤은 AWS Generative AI 서비스를 활용해 크루들의 아이디어를 실현하고, AI 활용 역량을 높이는 것을 목표로 진행했어요. 사전에는 Amazon Bedrock과 SageMaker를 중심으로 한 원데이 교육을 진행했고, 행사 기간 내내 AWS의 아낌없는 기술 지원이 함께했습니다. 덕분에 참가한 모든 크루들이 AWS의 기본적인 활용법은 물론, 생성형 AI 모델 적용 경험까지 함께 얻을 수 있는 기회의 장이 되었답니다.처음으로 오프라인에서 진행해 더욱 특별했던 카페톤에서 크루들의 열정은 어땠을까요?DAY1 기획부터 개발까지 풀가동!막을 수 없는 크루들의 열정 열정 열정🔥DAY1 공식 행사 시간은 오전 10시부터 오후 10시까지였는데요. 크루들의 열정 앞에서 행사 시간은 큰 의미가 없었습니다. 행사 시작쯤 오늘 몇 시까지 계실 거냐는 질문에 자신 있게 ‘10시 전에는 가죠.’ 하던 크루들의 모습은 어디 가고, 공식 행사 시간인 오후 10시 이후부터는 ‘오늘 안에 갈 수 있을까요?’, ‘로라 설마 집에 가시나요?’ 질문만 돌아왔다는 후문이…한 번 시작하면 끝을 봐야 하는, 조금이라도 아쉬움이 없어야 하는 크루들의 열정 하나로 새벽까지 판교를 지킨 팀이 꽤나 되었답니다.빠질 수 없는 식사와 이벤트점심, 저녁 그리고 혹시 모를 밤샘 팀을 위한 CEO 앨런의 치맥 지원까지~~~🍗🍻 끝이 안 보이는 식사 제공으로 크루들이 이제 그만 먹으면 안 되냐고 할 정도였으면, 말 다 했죠?집중력이 흐트러질 타이밍에는 크루들의 집중력을 높이기 위한 카훗(Kahoot!) 퀴즈 이벤트를 진행했습니다. 카훗은 실시간으로 문제를 풀고 순위를 다투는 퀴즈 플랫폼으로, 간단한 클릭만으로도 모두가 함께 참여할 수 있어 짧은 시간에 현장 분위기를 확 띄울 수 있었어요. 재미난 이벤트를 제안하고 진행까지 해주신 AWS 진성님 감사합니다.해당 이벤트에서는 “이번 카페톤 참
2025.04.24
좋아요
별로에요
Vibe Coding하는 비개발자는 개발자인가(2)
지난 글에서는 비개발자의 시선에서 ‘바이브 코딩(Vibe Coding)’과 AI Native에 대한 생각을 먼저 나눴습니다. 이번에는 그런 생각의 토대가 되었던 실제 경험을 바탕으로 이야기를 이어가고자 합니다.‘필요한 도구를 찾는 것보다 내가 직접 만들어서 쓰는 것이 더 빠르다’는 것을 깨달으면서 저는 바이브 코딩을 시작하게 되었습니다. HTML 도구를 ‘개발’했다고 소개하려 하니, ‘HTML은 프로그래밍 언어가 아니다’라는 밈이 떠오르네요. 비록 HTML 파일이 주요 결과물이지만 CSS, 자바스크립트, 타입스크립트 등 작은 웹 앱 형태로 구색을 갖추는 경우도 있으니 너그러이 봐주세요. 물론, 실제 개발자 분들이 만드는 제품처럼 견고하고 확장성 있는 결과물은 아니고, 최소 기능 제품(Minimum Viable Product) 수준에서 충분히 유용하게 활용하고 있습니다.사용할 수 있는 AI 개발 도구들이 다양한데요, 제 경험은 크게 아래 두 가지로 나누어 보겠습니다.• LLM으로 만들기 (ChatGPT/Claude/Gemini)• AI 에이전트(agent) 도구로 만들기 (Copilot Agent)➊ LLM으로 만들기ChatGPT, Claude, Gemini 같은 LLM(거대 언어 모델)은 요청할 때마다 결과가 조금씩 달라진다는 특징이 있습니다. 때로는 입력 데이터 중 수정하면 안 되는 부분까지 답변 생성 과정에서 수정되어 버리는 경우도 있습니다. 이런 일이 발생하면 결국 모든 데이터를 일일이 확인해야 하는 번거로움이 따릅니다.그런데 단순히 정해진 규칙대로 반복적인 처리만 필요한 경우도 많습니다. 예를 들어, 텍스트 목록 전체에 동일한 머리말을 추가하거나, 숫자 형식을 규칙에 맞게 한 번에 변환하는 작업처럼 말입니다. 이런 경우에는 결과를 예측하기 어려운 ‘블랙박스’ 같은 LLM에게 직접 작업을 요청하는 것보다, 차라리 그 규칙대로 작동하는 간단한 도구를 만들어 달라고 하는 편이 결과의 신뢰도와 일관성을 높이는 데 훨씬 효과적입니다.예를 들어 다음과 같이 프롬프트를 작성하면 됩니다.위 이미지는 저의 첫 바이브 코딩 작품인 '영어 to 한글 키보드 변환기’입니다. 이 도구를 만들었던 2024년 하반기만 해도, 비교적 간단한 규칙 기반의 작업을 LLM이 제대로 처리하지 못하는 경우가 있었습니다. 제가 발견했던 사례는, 키보드 한/영 키를 잘못 눌러 영문으로 입력된 한글을 다시 한글로 바꾸는 작업이었습니다. (예: → )당시 여러 프롬프트와 언어모델을 사용해 보았지만, 처음 몇 개의 알파벳은 잘 변경해 준 뒤, 그 뒤로는 앞 단어를 기반으로 새로운 문장을 창조하면서 변환 작업을 잊어버리는 것 같았습니다. 그래서 프롬프팅에 능한 동료 로빈(Robin.hwang)에게 자문을 구했고, 로빈의 추천으로 이 키보드 변환 규칙을 직접 수행하는 웹 도구를 LLM에게 프롬프팅 하여 만들게 된 것입니다. 귀여운 고양이 테마 디자인도 (역시 로빈의 아이디어로) 프롬프팅으로 추가했습니다.물론 몇 개월 후에는 LLM 성능이 빠르게 발전했고, 지금은 이런 도구 없이 LLM 채팅창에서도 변환이 곧잘 가능해졌습니다.생각을 시각화하기 위해 저는 가끔 머메이드(Mermaid) 문법으로 다이어그램을 그립니다. 하지만 이를 위해 VS Code를 실행하고 새 파일을 만드는 것이 번거로웠습니다(비개발자인 저는 평소에 IDE를 켜두지 않으니까요). 그래서 ‘그냥 웹에서 바로 쓰고 바로 볼 수 없을까?’ 하는 생각에, 저장 기능은 빼고 라이브 편집 기능만 갖춘 HTML 페이지를 ChatGPT에서 바로 만들었습니다. 이름하여 '머메이드 라이브 에디터’입니다.저는 머메이드를 자주 사용하지 않는 탓에 필요할 때 문법이 기억나지 않는 경우가 많았는데요, 에디터가 로딩될 때 샘플 문법을 입력창에 미리 보여주도록 수정하니 사용이 편리했습니다. 이처럼 도구를 만들 때, 입력 형식이나 예시 데이터를 미리 작성해서 첫 화면에서 보여주는 것이 좋았습니다. 그러면 시간이 흐른 뒤에 다시 사용할 때에도 헤매지 않고 바로 사용할 수 있었습니다.엑셀 함수로도 가능하지만, 매번 수식을 입력하거나 직접 확인하기엔 번거로운 단순 반복 작업들이 있습니다. 이런 작업들 역시 LLM에게 요청하여 규칙 기반으로 작동하는 HTML 파일 하나로 만들어 두면 필요할 때마다 편리하게 사용할 수 있습니다. 예를 들어 ‘중복 텍스트 검출기’, ‘데이터 개수 세기’, ‘랜덤 추첨기’ 같은 것들입니다. LLM에게 명확한 규칙을 알려주면, 이런 자주 쓰는 기능을 빠르고 정확하게 수행하는 도구를 쉽게 만들 수 있습니다.여러분의 업무에서 자주 반복하는 간단한 작업들이 있다면 작은 기능 단위부터 직접 도구를 만들어 활용해 보시길 추천드립니다.➋ AI 에이전트 도구로 만들기에이전트는 사용자가 모든 세부 사항을 지시하지 않아도, 사용자 경험(UX)을 고려하여 전체적인 결과물을 만들어 줍니다. 단 한 줄의 프롬프트로도 수준 높은 결과물을 얻을 수 있는 것이죠. 빠른 기술의 발전 덕분에, 이제는 LLM 도구만으로도 에이전트와 유사한 경험을 할 수 있습니다. 그럼에도 예를 들어, VS Code 환경에서 코드 복사・붙여넣기 조차 직접 하지 않아도 되는 등, 에이전트 개발 도구만의 편리한 특징들이 있는 것 같습니다.앞서 소개한 ‘중복 텍스트 검출기’를 코파일럿(Copilot)의 에이전트로 다시 만들어 보겠습니다.우선 LLM으로 만들 때와 비슷한 프롬프트를 입력했습니다(아래 프롬프트는 ChatGPT가 썼어요).그랬더니 LLM으로 만들었던 것과 유사한 결과물이 일단 나왔습니다.여기서 에이전트가 실력을 발휘할 수 있도록 다음의 프롬프트를 입력했습니다.이렇게 두 번의 대화로 아래의 결과물이 완성되었습니다.위 사례는 단일 HTML 파일 작업이라, 에이전트의 장점이 크게 와닿지 않으실 수도 있습니다. 하지만 여러 파일을 오가며 작업하거나, 오류를 해결할 때 등, 번거로운 작업이 늘수록 에이전트의 편리함을 체감하게 됩니다.이 사례처럼 간단한 도구를 만들 때는 프롬프트가 짧아도 훌륭한 성능을 경험할 수 있습니다. 반면 복잡한 요구사항을 정확히 반영해야 하는 경우에는, 처음부터 최대한 완성도 높은 결과
4/24/2025
Vibe Coding하는 비개발자는 개발자인가(2)
지난 글에서는 비개발자의 시선에서 ‘바이브 코딩(Vibe Coding)’과 AI Native에 대한 생각을 먼저 나눴습니다. 이번에는 그런 생각의 토대가 되었던 실제 경험을 바탕으로 이야기를 이어가고자 합니다.‘필요한 도구를 찾는 것보다 내가 직접 만들어서 쓰는 것이 더 빠르다’는 것을 깨달으면서 저는 바이브 코딩을 시작하게 되었습니다. HTML 도구를 ‘개발’했다고 소개하려 하니, ‘HTML은 프로그래밍 언어가 아니다’라는 밈이 떠오르네요. 비록 HTML 파일이 주요 결과물이지만 CSS, 자바스크립트, 타입스크립트 등 작은 웹 앱 형태로 구색을 갖추는 경우도 있으니 너그러이 봐주세요. 물론, 실제 개발자 분들이 만드는 제품처럼 견고하고 확장성 있는 결과물은 아니고, 최소 기능 제품(Minimum Viable Product) 수준에서 충분히 유용하게 활용하고 있습니다.사용할 수 있는 AI 개발 도구들이 다양한데요, 제 경험은 크게 아래 두 가지로 나누어 보겠습니다.• LLM으로 만들기 (ChatGPT/Claude/Gemini)• AI 에이전트(agent) 도구로 만들기 (Copilot Agent)➊ LLM으로 만들기ChatGPT, Claude, Gemini 같은 LLM(거대 언어 모델)은 요청할 때마다 결과가 조금씩 달라진다는 특징이 있습니다. 때로는 입력 데이터 중 수정하면 안 되는 부분까지 답변 생성 과정에서 수정되어 버리는 경우도 있습니다. 이런 일이 발생하면 결국 모든 데이터를 일일이 확인해야 하는 번거로움이 따릅니다.그런데 단순히 정해진 규칙대로 반복적인 처리만 필요한 경우도 많습니다. 예를 들어, 텍스트 목록 전체에 동일한 머리말을 추가하거나, 숫자 형식을 규칙에 맞게 한 번에 변환하는 작업처럼 말입니다. 이런 경우에는 결과를 예측하기 어려운 ‘블랙박스’ 같은 LLM에게 직접 작업을 요청하는 것보다, 차라리 그 규칙대로 작동하는 간단한 도구를 만들어 달라고 하는 편이 결과의 신뢰도와 일관성을 높이는 데 훨씬 효과적입니다.예를 들어 다음과 같이 프롬프트를 작성하면 됩니다.위 이미지는 저의 첫 바이브 코딩 작품인 '영어 to 한글 키보드 변환기’입니다. 이 도구를 만들었던 2024년 하반기만 해도, 비교적 간단한 규칙 기반의 작업을 LLM이 제대로 처리하지 못하는 경우가 있었습니다. 제가 발견했던 사례는, 키보드 한/영 키를 잘못 눌러 영문으로 입력된 한글을 다시 한글로 바꾸는 작업이었습니다. (예: → )당시 여러 프롬프트와 언어모델을 사용해 보았지만, 처음 몇 개의 알파벳은 잘 변경해 준 뒤, 그 뒤로는 앞 단어를 기반으로 새로운 문장을 창조하면서 변환 작업을 잊어버리는 것 같았습니다. 그래서 프롬프팅에 능한 동료 로빈(Robin.hwang)에게 자문을 구했고, 로빈의 추천으로 이 키보드 변환 규칙을 직접 수행하는 웹 도구를 LLM에게 프롬프팅 하여 만들게 된 것입니다. 귀여운 고양이 테마 디자인도 (역시 로빈의 아이디어로) 프롬프팅으로 추가했습니다.물론 몇 개월 후에는 LLM 성능이 빠르게 발전했고, 지금은 이런 도구 없이 LLM 채팅창에서도 변환이 곧잘 가능해졌습니다.생각을 시각화하기 위해 저는 가끔 머메이드(Mermaid) 문법으로 다이어그램을 그립니다. 하지만 이를 위해 VS Code를 실행하고 새 파일을 만드는 것이 번거로웠습니다(비개발자인 저는 평소에 IDE를 켜두지 않으니까요). 그래서 ‘그냥 웹에서 바로 쓰고 바로 볼 수 없을까?’ 하는 생각에, 저장 기능은 빼고 라이브 편집 기능만 갖춘 HTML 페이지를 ChatGPT에서 바로 만들었습니다. 이름하여 '머메이드 라이브 에디터’입니다.저는 머메이드를 자주 사용하지 않는 탓에 필요할 때 문법이 기억나지 않는 경우가 많았는데요, 에디터가 로딩될 때 샘플 문법을 입력창에 미리 보여주도록 수정하니 사용이 편리했습니다. 이처럼 도구를 만들 때, 입력 형식이나 예시 데이터를 미리 작성해서 첫 화면에서 보여주는 것이 좋았습니다. 그러면 시간이 흐른 뒤에 다시 사용할 때에도 헤매지 않고 바로 사용할 수 있었습니다.엑셀 함수로도 가능하지만, 매번 수식을 입력하거나 직접 확인하기엔 번거로운 단순 반복 작업들이 있습니다. 이런 작업들 역시 LLM에게 요청하여 규칙 기반으로 작동하는 HTML 파일 하나로 만들어 두면 필요할 때마다 편리하게 사용할 수 있습니다. 예를 들어 ‘중복 텍스트 검출기’, ‘데이터 개수 세기’, ‘랜덤 추첨기’ 같은 것들입니다. LLM에게 명확한 규칙을 알려주면, 이런 자주 쓰는 기능을 빠르고 정확하게 수행하는 도구를 쉽게 만들 수 있습니다.여러분의 업무에서 자주 반복하는 간단한 작업들이 있다면 작은 기능 단위부터 직접 도구를 만들어 활용해 보시길 추천드립니다.➋ AI 에이전트 도구로 만들기에이전트는 사용자가 모든 세부 사항을 지시하지 않아도, 사용자 경험(UX)을 고려하여 전체적인 결과물을 만들어 줍니다. 단 한 줄의 프롬프트로도 수준 높은 결과물을 얻을 수 있는 것이죠. 빠른 기술의 발전 덕분에, 이제는 LLM 도구만으로도 에이전트와 유사한 경험을 할 수 있습니다. 그럼에도 예를 들어, VS Code 환경에서 코드 복사・붙여넣기 조차 직접 하지 않아도 되는 등, 에이전트 개발 도구만의 편리한 특징들이 있는 것 같습니다.앞서 소개한 ‘중복 텍스트 검출기’를 코파일럿(Copilot)의 에이전트로 다시 만들어 보겠습니다.우선 LLM으로 만들 때와 비슷한 프롬프트를 입력했습니다(아래 프롬프트는 ChatGPT가 썼어요).그랬더니 LLM으로 만들었던 것과 유사한 결과물이 일단 나왔습니다.여기서 에이전트가 실력을 발휘할 수 있도록 다음의 프롬프트를 입력했습니다.이렇게 두 번의 대화로 아래의 결과물이 완성되었습니다.위 사례는 단일 HTML 파일 작업이라, 에이전트의 장점이 크게 와닿지 않으실 수도 있습니다. 하지만 여러 파일을 오가며 작업하거나, 오류를 해결할 때 등, 번거로운 작업이 늘수록 에이전트의 편리함을 체감하게 됩니다.이 사례처럼 간단한 도구를 만들 때는 프롬프트가 짧아도 훌륭한 성능을 경험할 수 있습니다. 반면 복잡한 요구사항을 정확히 반영해야 하는 경우에는, 처음부터 최대한 완성도 높은 결과
2025.04.24
좋아요
별로에요
UX 라이팅, 텍스트로 사용자 경험을 디자인하다: 카피라이팅, 테크니컬 라이팅과의 차이점
지난 첫 번째 글에서는 UX라이팅 직무의 가시화와 중요성이라는 주제를 중심으로, UX 라이팅이 2017년 Google I/O에서 공식적으로 명명되며 직무로서 가시화된 과정을 살펴봤어요. UX 라이팅은 단순 글쓰기를 넘어 사용자 경험을 개선하는 중요한 직무로, 서비스 전체를 수평적으로 통찰하며 사용자 중심의 커뮤니케이션을 구현하는 직무예요. 아직 국내에서는 그 가치를 충분히 인정받지 못하고 있지만, 사용자 만족을 극대화하는 핵심 역할을 담당하고 있다고 저는 믿고 있어요. 이제 두 번째 글은 UX 라이팅의 개념을 알아보려고 해요. 특히, UX 라이팅과 유사한 직무로 여겨지는 카피라이팅과 테크니컬 라이팅과의 차이를 예를 들어 살펴볼 거예요. 저는 유사하다고 오해하는 상황에서 차이점을 발견했을 때, 더욱 명확한 지식으로 받아들일 수 있다고 보는데요. 왜냐고요? 차이는 그 특성을 도드라지게 만드는 성격을 지니고 있으니까요. 그럼 지금부터 함께 살펴보도록 하시죠!이전 글을 읽었던 분들이라면, 이제 UX 라이팅이라는 단어가 조금은 익숙해졌을 거예요. '조금' 밖에 익숙해지지 않았으니, 이제 UX 라이팅 개념에 완전히 빠져들게 만들 차례인데요. 그 선행이 바로 개념 이해예요. 이 개념이 바로 '기초'라고 할 수 있죠. 그리고 우리가 '마스터'로 나아가기 위해서는 반드시 이 기초를 거쳐가야 해요. 거치지 않는다면 사상누각(沙上樓閣)이 될 것은 자명하죠. 사상누각에 빠지지 않기 위한 그 첫 번째로 UX 라이팅의 개념을 쉽게 혼동하는 다른 직무와의 대조를 통해 알아보는 거예요.UX 라이팅, 그게 뭔데?UX 라이팅, 텍스트로 디자인을 하다.UX 라이팅은 사용자 경험을 개선하기 위해 디지털 제품의 인터페이스에서사용자와 상호작용을 하는 모든 텍스트 요소를 설계하고 최적화해요.킨너렛 이프라의 <마이크로카피>Google I/O 2017 이후, UX 라이팅 관련된 책이 나오기 시작했어요. 대표적으로 UX 라이팅의 교과서라 불리는 <마이크로카피>가 출간됐어요. <마이크로카피>에서 말하는 UX 라이팅 개념을 3가지로 정리하면 다음과 같아요.UX 라이팅은 사용자가 서비스와 상호작용하는 과정에서 사용되는 텍스트 작성을 의미합니다.UX 라이팅은 사용자 경험을 개선하고 사용자가 목표를 달성할 수 있도록 돕기 위해 텍스트를 디자인하고 편집하는 것을 포함합니다.UX 라이팅은 명확하고 간결한 텍스트를 통해 사용자에게 정보를 전달하고, 사용자의 이해를 돕고, 행동을 유도하며, 일관된 사용자 경험을 제공하는 것을 목표로 합니다."UX 라이팅은 텍스트를 디자인하고 편집하는 것이다"위 3가지 개념은 모두 소중해요. UX 라이팅을 이어나가는데 큰 힘이 되는 요소들이죠. 그래도 가장 중요한 요소를 꼽으라고 한다면 '텍스트를 디자인하고 편집'하는 행위라고 할 수 있어요. 이 문장이 함의하는 내용은 UX 라이팅이 윤문(潤文)만 하지 않는다는 사실이죠. 윤문은 글을 읽기 매끄럽게 만든다는 것을 의미해요. 앞 뒤 문장 간의 연결성에 초점을 둘 뿐, 시각적인 것에는 관여하지 않는 거죠.반면 UX 라이팅은 사용자 인터페이스(UI)의 일부로서 텍스트를 다뤄요. 버튼, 레이블, 컴포넌트 등 다양한 컴포넌트와 어우러지도록 텍스트를 디자인하죠. 즉, 시각적 요소와 텍스트가 조화를 이루도록 텍스트를 다루는 작업이에요. 그 안에는 글꼴, 크기, 굵기, 색상 등 전체를 고려해 텍스트의 위계와 의미를 전달하기 위한 고민이 들어가요."또한, 명확하고 간결한 텍스트를 활용해 일관된 사용자 경험을 제공하는 것을 목표로 합니다."디자인은 한 화면에 국한되어 적용되는 요소가 아니에요. 서비스 전체를 꿰뚫으면서 전달하는 요소죠. 서비스 전체를 꿰뚫기 위해서는 간결하고 명확한 텍스트가 필요해요. 수많은 텍스트를 '우리의 말'이 아닌, '사용자의 말'로 전달해야 하는데, 장황하면 할수록 사용자가 이해하기 어려워하기 때문이죠. 그래서 최대한 사용자의 말을 경청하는 방식으로 문구를 작성하죠. (투머치토커가 되지 않기 노력한다는 의미)또한, UX 라이팅은 일방적인 정보를 사용자에게 주입하는게 아니라, 자연스러운 대화의 흐름 안으로 그들을 끌어들여야 하는데요. 문어체 형식 보다는 구어체 형식이 효과적으로 작동하죠. 하지만 구어체가 문어체보다 무조건 좋은 건 아니에요. 구어체를 사용하다보면 마주하게 되는 문제들이 있는데요. 누가 쓰느냐에 따라 '문체의 형태'가 달라져버려요. 예민한 사용자일수록 이 부분을 느껴 어색함을 느끼기도 하죠.이러한 문제를 방지하고 일관된 사용자 경험을 제공하기 위해, UX 라이터는 텍스트 하나를 수정할 때도 서비스 전체에 걸쳐 동일한 보이스, 톤, 용어를 사용해야 해요. 그리고 서비스 곳곳에 존재하는 제품들이 하나의 일관된 이야기를 하고 있는지 점검하고, 동일한 의미를 똑같은 언어로 표현하는지 살펴보는 것이 중요하죠. 이렇게 함으로써 사용자는 서비스 전반에 걸쳐 일관된 경험을 할 수 있고, 우리 브랜드의 정체성도 강화할 수 있어요.한눈에 보는 세 가지 직무의 차이점소니의 헤드폰을 예시로 들어 세 가지 직무가 작성하는 문구의 목적과 접근 방식을 알아볼게요.UX 라이팅, 카피라이팅, 테크니컬 라이팅은 모두 텍스트를 작성하는 분야예요. 하지만 각각의 타깃과 목적이 달라요. 그에 따라 작성하는 방식, 전략적 접근 등이 모두 달라지죠. 한 번 예시를 통해 살펴볼까요?"Sony 헤드폰 하나로 세 가지 직무를 대조해 볼까요"Sony의 WH-1000XM5, 출처: www.Sony.co.kr여기 소니의 유명한 헤드폰이 있어요. '노이즈 캔슬링'의 대명사로 불리는 헤드폰이죠. 저는 이 제품을 가지고 UX 라이팅, 카피라이팅 그리고 테크니컬 라이팅의 차이점을 보여드리고자 해요. 집중해야 하는 문구는 '노이즈 캔슬링'이고, 이 기능을 중심으로 세 가지 직무가 지니는 차이점을 보여드릴게요."UX 라이팅: 노이즈 캔슬링 기능을 활성화하려면 왼쪽 이어컵 위쪽 버튼을 눌러주세요."UX 라이팅 문구는 사용자가 노이즈 캔슬링 기능을 활성화하기 위한 명확한 지침을 제공하고 있어요. 제품을 쉽게 이해하고 사용할 수 있도록 돕기 위한 거죠. 버튼의 위치와 기능을 구체적으로 안내해, 사
4/23/2025
UX 라이팅, 텍스트로 사용자 경험을 디자인하다: 카피라이팅, 테크니컬 라이팅과의 차이점
지난 첫 번째 글에서는 UX라이팅 직무의 가시화와 중요성이라는 주제를 중심으로, UX 라이팅이 2017년 Google I/O에서 공식적으로 명명되며 직무로서 가시화된 과정을 살펴봤어요. UX 라이팅은 단순 글쓰기를 넘어 사용자 경험을 개선하는 중요한 직무로, 서비스 전체를 수평적으로 통찰하며 사용자 중심의 커뮤니케이션을 구현하는 직무예요. 아직 국내에서는 그 가치를 충분히 인정받지 못하고 있지만, 사용자 만족을 극대화하는 핵심 역할을 담당하고 있다고 저는 믿고 있어요. 이제 두 번째 글은 UX 라이팅의 개념을 알아보려고 해요. 특히, UX 라이팅과 유사한 직무로 여겨지는 카피라이팅과 테크니컬 라이팅과의 차이를 예를 들어 살펴볼 거예요. 저는 유사하다고 오해하는 상황에서 차이점을 발견했을 때, 더욱 명확한 지식으로 받아들일 수 있다고 보는데요. 왜냐고요? 차이는 그 특성을 도드라지게 만드는 성격을 지니고 있으니까요. 그럼 지금부터 함께 살펴보도록 하시죠!이전 글을 읽었던 분들이라면, 이제 UX 라이팅이라는 단어가 조금은 익숙해졌을 거예요. '조금' 밖에 익숙해지지 않았으니, 이제 UX 라이팅 개념에 완전히 빠져들게 만들 차례인데요. 그 선행이 바로 개념 이해예요. 이 개념이 바로 '기초'라고 할 수 있죠. 그리고 우리가 '마스터'로 나아가기 위해서는 반드시 이 기초를 거쳐가야 해요. 거치지 않는다면 사상누각(沙上樓閣)이 될 것은 자명하죠. 사상누각에 빠지지 않기 위한 그 첫 번째로 UX 라이팅의 개념을 쉽게 혼동하는 다른 직무와의 대조를 통해 알아보는 거예요.UX 라이팅, 그게 뭔데?UX 라이팅, 텍스트로 디자인을 하다.UX 라이팅은 사용자 경험을 개선하기 위해 디지털 제품의 인터페이스에서사용자와 상호작용을 하는 모든 텍스트 요소를 설계하고 최적화해요.킨너렛 이프라의 <마이크로카피>Google I/O 2017 이후, UX 라이팅 관련된 책이 나오기 시작했어요. 대표적으로 UX 라이팅의 교과서라 불리는 <마이크로카피>가 출간됐어요. <마이크로카피>에서 말하는 UX 라이팅 개념을 3가지로 정리하면 다음과 같아요.UX 라이팅은 사용자가 서비스와 상호작용하는 과정에서 사용되는 텍스트 작성을 의미합니다.UX 라이팅은 사용자 경험을 개선하고 사용자가 목표를 달성할 수 있도록 돕기 위해 텍스트를 디자인하고 편집하는 것을 포함합니다.UX 라이팅은 명확하고 간결한 텍스트를 통해 사용자에게 정보를 전달하고, 사용자의 이해를 돕고, 행동을 유도하며, 일관된 사용자 경험을 제공하는 것을 목표로 합니다."UX 라이팅은 텍스트를 디자인하고 편집하는 것이다"위 3가지 개념은 모두 소중해요. UX 라이팅을 이어나가는데 큰 힘이 되는 요소들이죠. 그래도 가장 중요한 요소를 꼽으라고 한다면 '텍스트를 디자인하고 편집'하는 행위라고 할 수 있어요. 이 문장이 함의하는 내용은 UX 라이팅이 윤문(潤文)만 하지 않는다는 사실이죠. 윤문은 글을 읽기 매끄럽게 만든다는 것을 의미해요. 앞 뒤 문장 간의 연결성에 초점을 둘 뿐, 시각적인 것에는 관여하지 않는 거죠.반면 UX 라이팅은 사용자 인터페이스(UI)의 일부로서 텍스트를 다뤄요. 버튼, 레이블, 컴포넌트 등 다양한 컴포넌트와 어우러지도록 텍스트를 디자인하죠. 즉, 시각적 요소와 텍스트가 조화를 이루도록 텍스트를 다루는 작업이에요. 그 안에는 글꼴, 크기, 굵기, 색상 등 전체를 고려해 텍스트의 위계와 의미를 전달하기 위한 고민이 들어가요."또한, 명확하고 간결한 텍스트를 활용해 일관된 사용자 경험을 제공하는 것을 목표로 합니다."디자인은 한 화면에 국한되어 적용되는 요소가 아니에요. 서비스 전체를 꿰뚫으면서 전달하는 요소죠. 서비스 전체를 꿰뚫기 위해서는 간결하고 명확한 텍스트가 필요해요. 수많은 텍스트를 '우리의 말'이 아닌, '사용자의 말'로 전달해야 하는데, 장황하면 할수록 사용자가 이해하기 어려워하기 때문이죠. 그래서 최대한 사용자의 말을 경청하는 방식으로 문구를 작성하죠. (투머치토커가 되지 않기 노력한다는 의미)또한, UX 라이팅은 일방적인 정보를 사용자에게 주입하는게 아니라, 자연스러운 대화의 흐름 안으로 그들을 끌어들여야 하는데요. 문어체 형식 보다는 구어체 형식이 효과적으로 작동하죠. 하지만 구어체가 문어체보다 무조건 좋은 건 아니에요. 구어체를 사용하다보면 마주하게 되는 문제들이 있는데요. 누가 쓰느냐에 따라 '문체의 형태'가 달라져버려요. 예민한 사용자일수록 이 부분을 느껴 어색함을 느끼기도 하죠.이러한 문제를 방지하고 일관된 사용자 경험을 제공하기 위해, UX 라이터는 텍스트 하나를 수정할 때도 서비스 전체에 걸쳐 동일한 보이스, 톤, 용어를 사용해야 해요. 그리고 서비스 곳곳에 존재하는 제품들이 하나의 일관된 이야기를 하고 있는지 점검하고, 동일한 의미를 똑같은 언어로 표현하는지 살펴보는 것이 중요하죠. 이렇게 함으로써 사용자는 서비스 전반에 걸쳐 일관된 경험을 할 수 있고, 우리 브랜드의 정체성도 강화할 수 있어요.한눈에 보는 세 가지 직무의 차이점소니의 헤드폰을 예시로 들어 세 가지 직무가 작성하는 문구의 목적과 접근 방식을 알아볼게요.UX 라이팅, 카피라이팅, 테크니컬 라이팅은 모두 텍스트를 작성하는 분야예요. 하지만 각각의 타깃과 목적이 달라요. 그에 따라 작성하는 방식, 전략적 접근 등이 모두 달라지죠. 한 번 예시를 통해 살펴볼까요?"Sony 헤드폰 하나로 세 가지 직무를 대조해 볼까요"Sony의 WH-1000XM5, 출처: www.Sony.co.kr여기 소니의 유명한 헤드폰이 있어요. '노이즈 캔슬링'의 대명사로 불리는 헤드폰이죠. 저는 이 제품을 가지고 UX 라이팅, 카피라이팅 그리고 테크니컬 라이팅의 차이점을 보여드리고자 해요. 집중해야 하는 문구는 '노이즈 캔슬링'이고, 이 기능을 중심으로 세 가지 직무가 지니는 차이점을 보여드릴게요."UX 라이팅: 노이즈 캔슬링 기능을 활성화하려면 왼쪽 이어컵 위쪽 버튼을 눌러주세요."UX 라이팅 문구는 사용자가 노이즈 캔슬링 기능을 활성화하기 위한 명확한 지침을 제공하고 있어요. 제품을 쉽게 이해하고 사용할 수 있도록 돕기 위한 거죠. 버튼의 위치와 기능을 구체적으로 안내해, 사
2025.04.23
좋아요
별로에요
웹 QA의 모든 것: 실전 검증 노하우와 Cypress 자동화
이번 글에서는 에이닷 멀티LLM WEB 기반 프로젝트를 진행하며 경험한OS 및 브라우저별 특성, QA 과정에서 마주쳤던 어려움, 그리고 WEB 검증 시 중점적으로 살펴봐야 할 요소 등 전반적인 노하우를 공유하고자 합니다.본 내용은 각 WEB 사이트의 개발 환경, 구현 방식, 로직에 따라 다소 차이가 있을 수 있으니 참고해주시기 바랍니다.WEB 검증은 기기, 운영체제, 브라우저 환경(브라우저 버전 등 포함)등 조합이 다양하여 검증 전 유관부서와 함께 품질을 보장하는 커버리지에 대해 협의 후 진행하는게 좋습니다.에이닷 경우 모바일 브라우저와 PC 브라우저 화면 구성이 달랐고, 화면 크기에 따라 반응형 디자인으로 동작하였습니다.품질 보장 커버리지는 브라우저/OS 시장 점유율, 각 운영체제, 기기의 대표 브라우저 등을 고려하여 협의 후 선정하여 진행하였습니다.브라우저/OS 시장 점유율은 아래 사이트에서 확인 가능합니다.• None 브라우저 / 사용 OS / OS 버전 등 기간/나라 별로 점유율 조회 가능(https://gs.statcounter.com/)• None Chrome / Samsung Internet(Android) / Safari(MAC/iOS) / Whale / Edge : 우리나라 TOP 5 위 브라우저에 한하여 검증 진행 하였으며, 최신브라우저 버전으로 검증 진행하였습니다.• None 브라우저가 하위버전일 경우 최신 표준 규격 적용 시 기능이 정상적으로 동작하지 않는 경우가 있습니다. 브라우저 구버전에 동일 기능을 적용하려면 분기 되어 각 개발 적용이 필요하여 리소스 소요가 증가할 수 있어,서비스 오픈 시기,기간,타겟 등 고려하여 QA 시작 전 논의/협의 후 진행이 필요합니다.앞서 언급한 것처럼, Web 테스트는 테스트 기기, 브라우저, OS에 따라 다양한 조합으로 진행할 수 있습니다.각 조합별로 고유한 특징이 존재하며, 이에 따라 검증 과정에서 기대했던 결과와 실제 결과가 달라지는 경우도 종종 발생하였습니다.실제 테스트 과정에서 경험했던 몇 가지 대표적인 특징들을 정리해보았습니다.• None 다크모드는 WEB 브라우저의 테마 색상을 어둡게 변경하는 것을 의미합니다.• None 다크모드 셋팅은 아래 두가지 영향을 받을 수 있습니다.• None WEB에서 구현한 다크모드 적용을 확인하려면 어떻게 셋팅 되어야 할지 아래와 같이 정리하였습니다.• None WEB 자체 별도 시스템 설정이나, 추가적인 커스텀마이징 되는 경우 동작 상이할 수 있습니다.• None ❗❗) Samsung-internet 경우 기본 브라우저 다크모드 동작은 자체 로직을 통해 컨텐츠의 색상을 변경합니다. 이는 실제 개발에서 구현된 색상과 다르게 표현될 수 있습니다.• None 삼성인터넷에서 각 서비스 개발에서 구현된 색상 확인을 위해서는 삼성인터넷-설정-실험실 "웹사이트 다크 테마 사용" 옵션을 ON 해줘야 합니다.Mobile 이미지 다운로드• None 저희 서비스에서는 이미지를 다운로드 받을 수 있는 기능이 있습니다.• None LLM 응답에 포함되는 이미지
cypress
4/23/2025
웹 QA의 모든 것: 실전 검증 노하우와 Cypress 자동화
이번 글에서는 에이닷 멀티LLM WEB 기반 프로젝트를 진행하며 경험한OS 및 브라우저별 특성, QA 과정에서 마주쳤던 어려움, 그리고 WEB 검증 시 중점적으로 살펴봐야 할 요소 등 전반적인 노하우를 공유하고자 합니다.본 내용은 각 WEB 사이트의 개발 환경, 구현 방식, 로직에 따라 다소 차이가 있을 수 있으니 참고해주시기 바랍니다.WEB 검증은 기기, 운영체제, 브라우저 환경(브라우저 버전 등 포함)등 조합이 다양하여 검증 전 유관부서와 함께 품질을 보장하는 커버리지에 대해 협의 후 진행하는게 좋습니다.에이닷 경우 모바일 브라우저와 PC 브라우저 화면 구성이 달랐고, 화면 크기에 따라 반응형 디자인으로 동작하였습니다.품질 보장 커버리지는 브라우저/OS 시장 점유율, 각 운영체제, 기기의 대표 브라우저 등을 고려하여 협의 후 선정하여 진행하였습니다.브라우저/OS 시장 점유율은 아래 사이트에서 확인 가능합니다.• None 브라우저 / 사용 OS / OS 버전 등 기간/나라 별로 점유율 조회 가능(https://gs.statcounter.com/)• None Chrome / Samsung Internet(Android) / Safari(MAC/iOS) / Whale / Edge : 우리나라 TOP 5 위 브라우저에 한하여 검증 진행 하였으며, 최신브라우저 버전으로 검증 진행하였습니다.• None 브라우저가 하위버전일 경우 최신 표준 규격 적용 시 기능이 정상적으로 동작하지 않는 경우가 있습니다. 브라우저 구버전에 동일 기능을 적용하려면 분기 되어 각 개발 적용이 필요하여 리소스 소요가 증가할 수 있어,서비스 오픈 시기,기간,타겟 등 고려하여 QA 시작 전 논의/협의 후 진행이 필요합니다.앞서 언급한 것처럼, Web 테스트는 테스트 기기, 브라우저, OS에 따라 다양한 조합으로 진행할 수 있습니다.각 조합별로 고유한 특징이 존재하며, 이에 따라 검증 과정에서 기대했던 결과와 실제 결과가 달라지는 경우도 종종 발생하였습니다.실제 테스트 과정에서 경험했던 몇 가지 대표적인 특징들을 정리해보았습니다.• None 다크모드는 WEB 브라우저의 테마 색상을 어둡게 변경하는 것을 의미합니다.• None 다크모드 셋팅은 아래 두가지 영향을 받을 수 있습니다.• None WEB에서 구현한 다크모드 적용을 확인하려면 어떻게 셋팅 되어야 할지 아래와 같이 정리하였습니다.• None WEB 자체 별도 시스템 설정이나, 추가적인 커스텀마이징 되는 경우 동작 상이할 수 있습니다.• None ❗❗) Samsung-internet 경우 기본 브라우저 다크모드 동작은 자체 로직을 통해 컨텐츠의 색상을 변경합니다. 이는 실제 개발에서 구현된 색상과 다르게 표현될 수 있습니다.• None 삼성인터넷에서 각 서비스 개발에서 구현된 색상 확인을 위해서는 삼성인터넷-설정-실험실 "웹사이트 다크 테마 사용" 옵션을 ON 해줘야 합니다.Mobile 이미지 다운로드• None 저희 서비스에서는 이미지를 다운로드 받을 수 있는 기능이 있습니다.• None LLM 응답에 포함되는 이미지
2025.04.23
cypress
좋아요
별로에요
AI ＆ Event Driven 오디오 데이터 LinkedIn 글 자동 발행 (feat. Apache Flink)
본 내용은 Web에 있는 오디오를 텍스트로 변환 후 GPT로 포스트를 자동 생성하는 설명입니다.특히 이벤트 주도 아키텍처(EDA) 를 통해 확장성과 실시간 처리를 구현한 과정을 소개합니다.핵심은 프론트엔드와 AI 워크플로우의 완전한 분리입니다.이를 위해 Confluent Cloud 기반 이벤트 주도 아키텍처 를 채택했습니다.🍑 이벤트 주도 아키텍처(EDA)가 필요한 이유기존 모놀리식 시스템은 확장성과 유연성에 한계가 있었습니다.기술이 발전하고 확장성과 적응성에 대한 요구가 증가함에 따라, 특히 분산 시스템과 마이크로서비스의 등장으로 인해 EDA는 자연스러운 해결책이 되었습니다.• None EDA는 상태 변경, 사용자 작업 또는 시스템 트리거와 같은 이벤트를 상호작용의 핵심 단위로 처리함으로써 시스템이 구성 요소를 분리하고 비동기적으로 통신할 수 있도록 합니다.• None 이 접근 방식은 데이터 스트리밍을 사용하며, 생산자와 소비자는 공유되고 변경 불가능한 로그를 통해 상호작용합니다.• None 이벤트는 보장된 순서대로 유지되므로 시스템은 동적이고 독립적으로 변경 사항을 처리하고 대응할 수 있습니다.사용자 중심 애플리케이션을 AI에서 분리하기 위해 Confluent Cloud의 데이터 스트리밍 플랫폼을 사용합니다.이 플랫폼은 Kafka, Flink 를 활용하고 확장 가능한 AI 애플리케이션을 쉽게 구축할 수 있게 해줍니다.사용자가 오디오 목록을 클릭하면 앱은 서버에 백엔드 캐시에서 기존 LinkedIn 게시물을 확인하도록 요청합니다.LinkedIn 게시물을 데이터베이스에 저장할 수도 있지만, 저는 오랫동안 보관할 필요가 없으므로 임시 캐시를 선택했습니다.LinkedIn 게시물이 없는 경우, 백엔드는 MP3 URL과 에피소드 설명을 포함하는 이벤트를 Kafka 토픽에 기록합니다.이를 통해 LinkedIn 게시물을 생성하는 워크플로가 시작됩니다.Apache Flink는 실시간으로 대량의 데이터를 처리하도록 설계된 오픈소스 스트림 처리 프레임워크입니다.높은 처리량과 낮은 지연 시간을 요구하는 환경에서 탁월한 성능을 발휘하여 실시간 AI 애플리케이션에 매우 적합합니다.데이터베이스에 익숙하다면 Flink SQL이 표준 SQL과 유사하다고 생각할 수 있지만, 데이터베이스 테이블을 쿼리하는 대신 데이터 스트림을 쿼리합니다.Flink를 사용하여 오디오를 LinkedIn 게시물로 변환하려면 외부 LLM을 통합해야 했습니다.Flink SQL을 사용하면 널리 사용되는 LLM 모델을 정의할 수 있어 이 작업이 간편해집니다.아래와 같이 작업(예: text_generation)을 지정하고 시스템 프롬프트를 제공하여 출력을 안내할 수 있습니다.LinkedIn 게시물을 만들기 위해 먼저 MP3 URL을 기반으로 LinkedIn 게시물 요청 주제와 주제를 연결하여 에피소드 설명과 대본을 프롬프트 값으로 결합하고 이를 뷰에 저장합니다.뷰를 사용하면 가독성과 유지 관리성이 향상됩니다. 문자열 연결을 ml_predict 호출에 직접 포함할 수도 있지만, 그렇게 하면 워크플로
flink
4/23/2025
AI ＆ Event Driven 오디오 데이터 LinkedIn 글 자동 발행 (feat. Apache Flink)
본 내용은 Web에 있는 오디오를 텍스트로 변환 후 GPT로 포스트를 자동 생성하는 설명입니다.특히 이벤트 주도 아키텍처(EDA) 를 통해 확장성과 실시간 처리를 구현한 과정을 소개합니다.핵심은 프론트엔드와 AI 워크플로우의 완전한 분리입니다.이를 위해 Confluent Cloud 기반 이벤트 주도 아키텍처 를 채택했습니다.🍑 이벤트 주도 아키텍처(EDA)가 필요한 이유기존 모놀리식 시스템은 확장성과 유연성에 한계가 있었습니다.기술이 발전하고 확장성과 적응성에 대한 요구가 증가함에 따라, 특히 분산 시스템과 마이크로서비스의 등장으로 인해 EDA는 자연스러운 해결책이 되었습니다.• None EDA는 상태 변경, 사용자 작업 또는 시스템 트리거와 같은 이벤트를 상호작용의 핵심 단위로 처리함으로써 시스템이 구성 요소를 분리하고 비동기적으로 통신할 수 있도록 합니다.• None 이 접근 방식은 데이터 스트리밍을 사용하며, 생산자와 소비자는 공유되고 변경 불가능한 로그를 통해 상호작용합니다.• None 이벤트는 보장된 순서대로 유지되므로 시스템은 동적이고 독립적으로 변경 사항을 처리하고 대응할 수 있습니다.사용자 중심 애플리케이션을 AI에서 분리하기 위해 Confluent Cloud의 데이터 스트리밍 플랫폼을 사용합니다.이 플랫폼은 Kafka, Flink 를 활용하고 확장 가능한 AI 애플리케이션을 쉽게 구축할 수 있게 해줍니다.사용자가 오디오 목록을 클릭하면 앱은 서버에 백엔드 캐시에서 기존 LinkedIn 게시물을 확인하도록 요청합니다.LinkedIn 게시물을 데이터베이스에 저장할 수도 있지만, 저는 오랫동안 보관할 필요가 없으므로 임시 캐시를 선택했습니다.LinkedIn 게시물이 없는 경우, 백엔드는 MP3 URL과 에피소드 설명을 포함하는 이벤트를 Kafka 토픽에 기록합니다.이를 통해 LinkedIn 게시물을 생성하는 워크플로가 시작됩니다.Apache Flink는 실시간으로 대량의 데이터를 처리하도록 설계된 오픈소스 스트림 처리 프레임워크입니다.높은 처리량과 낮은 지연 시간을 요구하는 환경에서 탁월한 성능을 발휘하여 실시간 AI 애플리케이션에 매우 적합합니다.데이터베이스에 익숙하다면 Flink SQL이 표준 SQL과 유사하다고 생각할 수 있지만, 데이터베이스 테이블을 쿼리하는 대신 데이터 스트림을 쿼리합니다.Flink를 사용하여 오디오를 LinkedIn 게시물로 변환하려면 외부 LLM을 통합해야 했습니다.Flink SQL을 사용하면 널리 사용되는 LLM 모델을 정의할 수 있어 이 작업이 간편해집니다.아래와 같이 작업(예: text_generation)을 지정하고 시스템 프롬프트를 제공하여 출력을 안내할 수 있습니다.LinkedIn 게시물을 만들기 위해 먼저 MP3 URL을 기반으로 LinkedIn 게시물 요청 주제와 주제를 연결하여 에피소드 설명과 대본을 프롬프트 값으로 결합하고 이를 뷰에 저장합니다.뷰를 사용하면 가독성과 유지 관리성이 향상됩니다. 문자열 연결을 ml_predict 호출에 직접 포함할 수도 있지만, 그렇게 하면 워크플로
2025.04.23
flink
좋아요
별로에요
강좌를 통해 살펴본 프롬프트 엔지니어링의 기초
안녕하세요. 상용개발센터 CV AI LAB 윤재욱 책임입니다. CV AI LAB은 AI, LLM 기술의 PoC를 inhouse로 개발 및 검증하는 그룹입니다.이번 포스팅은 국내 1호 프롬프트 엔지니어 강수진 박사의 강의를 소개하겠습니다.이 영상을 추천 드리는 이유는, 프롬프트에 대한 기본적인 설명뿐만 아니라 최신 트랜드인 Reasoning model 을 수행할 때 어떤 방식의 프롬프트 전략이 유효한지 자세히 설명하고 있다고 생각해서 인데요. 특히, 강수진 박사의 경우 언어학 전공으로 프롬프트 엔지니어링에 대해 언어학적인 관점으로 어떤 전략으로 대응할 것인지에 설명하고 있기 때문에, 개발자들에게는 조금 부족할 수 있는 언어학적 관점이 자연어 처리인 프롬프트 전략 수립에 도움이 될 것이라고 생각하여 영상을 추천드립니다.# 영어에 1~5형식이 있듯이, 프롬프트에도 4형식이 있다.영어에 1~5형식 문장 있듯, 프롬프트에도 4형식 문장이 있다 (강수진 박사)1. 프롬프트 구성의 기본 요소프롬프트를 효과적으로 구성하기 위해서는 네 가지 기본 요소가 필요합니다. 네 가지 기본 요소는 지시 (Instructions), 입력 데이터(Input Data), 문맥 (Context), 출력 지시문 (Output Indicatior) 구성됩니다. 각 구성 요소에 대한 설명은 아래와 같습니다.명령문: 사용자가 원하는 행동을 지시하는 문장. 예) HMG Developer 블로그 작성을 위한 글을 작성해줘.문맥: 추가적인 정보나 배경 설명. 예) HMG Developer 블로그는 HMG 개발자들이 정보를 공유하기 위한 공간입니다.입력 데이터: 언어 모델이 참고해야 할 정보. 예) 이번 작성글은 국내 1호 Prompt Engineer인 강수진 박사에 대한 설명과 prompt engineering에 대한 기본 정보에 다루려고 합니다.출력 지시문: 응답 형식이나 포맷을 지정하는 문장. 예) 출력을 블로그 발행 text에 맞게 제목, 소제목, 내용 기준으로 작성하고, bullet point로 문장 구분해서 작성해줘.2. 맥락의 중요성언어 모델에서 맥락은 매우 중요합니다. 이는 사람의 대화와 비슷하다고 판단할 수 있는데요. 예를 들자면 오늘 지인과 점심식사에 대한 메뉴 이야기를 하고 있다가, 갑자기 이와 관계없는 주제에 대해서 이야기한다면 상대방이 이에 대해 알아듣지 못하는 경우가 발생할 수 있습니다. 언어모델에게도 배경설명이 중요하고, 이를 기준으로 질문했을 때 이전에 했던 질문이나 대화의 흐름을 기억하여 더 나은 응답을 제공할 수 있습니다.3. 프롬프트 유형 A, B, C, D사용자는 사용하는 LLM의 유형이나 필요로하는 정보에 따라 프롬프트의 유형을 나누어서 선택하는 것이 효과적인 응답을 얻을 수 있습니다. 강수진 박사는 프롬프트의 유형을 총 4가지로 나눌 수 있다고 이야기하고 제시한 유형은 아래와 같습니다.타입 A: 지시문 + 출력문 - 가장 기본적인 질문 형식입니다. 질문의 내용과 원하는 출력의 양식만 제안하는 형식입니다. 예) 2024년 12월에 OpenAI가 발표한 핵심 내용이 뭐야?타입 B:지시문 + 맥락 + 출력문 - 추가적인 맥락을 제공하는 질문 형식입니다. 예) 2024년 12월에 OpenAI가 발표한 핵심 내용이 뭐야? 언어 모델의 '추론 성능'과 관련된 내용으로만 답변해줘.타입 C: 지시문 + 맥락 + 예시 +출력문 - 타입 B에 예시를 포함한 질문 형식입니다. 예) 2024년 12월에 OpenAI가 발표한 핵심 내용이 뭐야? 언어 모델의 '추론 성능'과 관련된 내용으로만 아래 예시의 구조처럼 답변해줘.타입 D: 지시문 + 입력값 + 출력문 - 입력값을 변수로 지정하여서 동일 질문의 형식을 활용해서 다양한 답변을 받을 수 있습니다. 예) 2024년 12월에 OpenAI가 발표한 핵심 내용이 뭐야? 아래 {입력값}을 활용해서, 내용을 보충해줘. 한 문단으로 완성해4. 결론프롬프트 엔지니어링은 AI와의 상호작용에서 중요한 역할을 수행합니다. 프롬프트 엔지니어링은 수학공식과 같이 정확한 공식이 있는 것이 아니라 문학적인 관점과 같이 다양한 형태에 따라 결과값이 달라질 수 있습니다. 강수진 박사가 제안한 형식을 기본으로 사용하되, 사용자가 원하는 결과물을 얻기 위해 다양한 요소를 조합하여 효과적인 프롬프트를 작성하는 것이 필요할 것으로 판단됩니다.# 김훈처럼 써라. ChatGPT도 단문, 두괄식, 명쾌한 동사 좋아한다. 김훈처럼 써라. 챗GPT도 단문, 두괄식, 명쾌한 동사 좋아한다 (강수진 박사)이 컨텐츠의 핵심 주제는 효과적인 프롬프트 제작법으로, 간단하고 명확한 언어 사용이 중요하다는 점을 강조합니다. 강수진 박사는 단문, 명확한 동사, 그리고 일상어를 활용하여 AI와의 소통을 개선하는 방법을 제시하며, 이러한 요소들이 결과물의 질을 높이는 데 기여한다고 설명합니다. 따라서, 프롬프트를 작성할 때는 간결하고 직관적인 표현이 필수적임을 강조합니다.1. 효과적인 프롬프트 제작법첫 번째 : 간단하고 명확한 단어의 프롬프트 AI와 잘 대화하기 위한 가장 간단한 방법은 간단하고 짧은 프롬프트로 시작하는 것입니다. 특히 명확한 동사를 사용하는 것이 중요하고, 뜻이 하나인 동사를 써야 사용자가 원하는 결과를 얻는데 도움이 됩니다. 예) "체중을 줄이다" 보다는 "체중을 감소시키다"의 단어를 사용하는 것이 명확한 의도를 전달하는데 좋습니다. 또한 일상어를 사용하는 것이 원하는 결과를 얻는데 도움이 될 수 있습니다. 이는 언어모델이 학습한 데이터가 web base를 기반으로 학습되었기 때문에 대부분의 단어들이 일상어로 구성되어 있기 때문입니다.두 번째 : 지시하는 문장을 처음 또는 끝에 배치 프롬프트 문장에서 위치도 중요합니다. 일부 언어 모델의 경우 지시문이 마지막에 들어가는 경우 정확한 답변을 제공합니다. 이러한 문제가 생기는 이유는 프롬프트가 긴 경우 중간에 내용을 언어모델이 이를 놓치는 경우가 발생 (Lost in the middle 현상이라고 부름)하여, 지시문에 따라 정확한 답변을 수행하지 못하는 경우가 있습니다.세 번째 : 기호를 활용 기호를 사용하면 AI가 정보를 더 잘 이해하고
4/22/2025
강좌를 통해 살펴본 프롬프트 엔지니어링의 기초
안녕하세요. 상용개발센터 CV AI LAB 윤재욱 책임입니다. CV AI LAB은 AI, LLM 기술의 PoC를 inhouse로 개발 및 검증하는 그룹입니다.이번 포스팅은 국내 1호 프롬프트 엔지니어 강수진 박사의 강의를 소개하겠습니다.이 영상을 추천 드리는 이유는, 프롬프트에 대한 기본적인 설명뿐만 아니라 최신 트랜드인 Reasoning model 을 수행할 때 어떤 방식의 프롬프트 전략이 유효한지 자세히 설명하고 있다고 생각해서 인데요. 특히, 강수진 박사의 경우 언어학 전공으로 프롬프트 엔지니어링에 대해 언어학적인 관점으로 어떤 전략으로 대응할 것인지에 설명하고 있기 때문에, 개발자들에게는 조금 부족할 수 있는 언어학적 관점이 자연어 처리인 프롬프트 전략 수립에 도움이 될 것이라고 생각하여 영상을 추천드립니다.# 영어에 1~5형식이 있듯이, 프롬프트에도 4형식이 있다.영어에 1~5형식 문장 있듯, 프롬프트에도 4형식 문장이 있다 (강수진 박사)1. 프롬프트 구성의 기본 요소프롬프트를 효과적으로 구성하기 위해서는 네 가지 기본 요소가 필요합니다. 네 가지 기본 요소는 지시 (Instructions), 입력 데이터(Input Data), 문맥 (Context), 출력 지시문 (Output Indicatior) 구성됩니다. 각 구성 요소에 대한 설명은 아래와 같습니다.명령문: 사용자가 원하는 행동을 지시하는 문장. 예) HMG Developer 블로그 작성을 위한 글을 작성해줘.문맥: 추가적인 정보나 배경 설명. 예) HMG Developer 블로그는 HMG 개발자들이 정보를 공유하기 위한 공간입니다.입력 데이터: 언어 모델이 참고해야 할 정보. 예) 이번 작성글은 국내 1호 Prompt Engineer인 강수진 박사에 대한 설명과 prompt engineering에 대한 기본 정보에 다루려고 합니다.출력 지시문: 응답 형식이나 포맷을 지정하는 문장. 예) 출력을 블로그 발행 text에 맞게 제목, 소제목, 내용 기준으로 작성하고, bullet point로 문장 구분해서 작성해줘.2. 맥락의 중요성언어 모델에서 맥락은 매우 중요합니다. 이는 사람의 대화와 비슷하다고 판단할 수 있는데요. 예를 들자면 오늘 지인과 점심식사에 대한 메뉴 이야기를 하고 있다가, 갑자기 이와 관계없는 주제에 대해서 이야기한다면 상대방이 이에 대해 알아듣지 못하는 경우가 발생할 수 있습니다. 언어모델에게도 배경설명이 중요하고, 이를 기준으로 질문했을 때 이전에 했던 질문이나 대화의 흐름을 기억하여 더 나은 응답을 제공할 수 있습니다.3. 프롬프트 유형 A, B, C, D사용자는 사용하는 LLM의 유형이나 필요로하는 정보에 따라 프롬프트의 유형을 나누어서 선택하는 것이 효과적인 응답을 얻을 수 있습니다. 강수진 박사는 프롬프트의 유형을 총 4가지로 나눌 수 있다고 이야기하고 제시한 유형은 아래와 같습니다.타입 A: 지시문 + 출력문 - 가장 기본적인 질문 형식입니다. 질문의 내용과 원하는 출력의 양식만 제안하는 형식입니다. 예) 2024년 12월에 OpenAI가 발표한 핵심 내용이 뭐야?타입 B:지시문 + 맥락 + 출력문 - 추가적인 맥락을 제공하는 질문 형식입니다. 예) 2024년 12월에 OpenAI가 발표한 핵심 내용이 뭐야? 언어 모델의 '추론 성능'과 관련된 내용으로만 답변해줘.타입 C: 지시문 + 맥락 + 예시 +출력문 - 타입 B에 예시를 포함한 질문 형식입니다. 예) 2024년 12월에 OpenAI가 발표한 핵심 내용이 뭐야? 언어 모델의 '추론 성능'과 관련된 내용으로만 아래 예시의 구조처럼 답변해줘.타입 D: 지시문 + 입력값 + 출력문 - 입력값을 변수로 지정하여서 동일 질문의 형식을 활용해서 다양한 답변을 받을 수 있습니다. 예) 2024년 12월에 OpenAI가 발표한 핵심 내용이 뭐야? 아래 {입력값}을 활용해서, 내용을 보충해줘. 한 문단으로 완성해4. 결론프롬프트 엔지니어링은 AI와의 상호작용에서 중요한 역할을 수행합니다. 프롬프트 엔지니어링은 수학공식과 같이 정확한 공식이 있는 것이 아니라 문학적인 관점과 같이 다양한 형태에 따라 결과값이 달라질 수 있습니다. 강수진 박사가 제안한 형식을 기본으로 사용하되, 사용자가 원하는 결과물을 얻기 위해 다양한 요소를 조합하여 효과적인 프롬프트를 작성하는 것이 필요할 것으로 판단됩니다.# 김훈처럼 써라. ChatGPT도 단문, 두괄식, 명쾌한 동사 좋아한다. 김훈처럼 써라. 챗GPT도 단문, 두괄식, 명쾌한 동사 좋아한다 (강수진 박사)이 컨텐츠의 핵심 주제는 효과적인 프롬프트 제작법으로, 간단하고 명확한 언어 사용이 중요하다는 점을 강조합니다. 강수진 박사는 단문, 명확한 동사, 그리고 일상어를 활용하여 AI와의 소통을 개선하는 방법을 제시하며, 이러한 요소들이 결과물의 질을 높이는 데 기여한다고 설명합니다. 따라서, 프롬프트를 작성할 때는 간결하고 직관적인 표현이 필수적임을 강조합니다.1. 효과적인 프롬프트 제작법첫 번째 : 간단하고 명확한 단어의 프롬프트 AI와 잘 대화하기 위한 가장 간단한 방법은 간단하고 짧은 프롬프트로 시작하는 것입니다. 특히 명확한 동사를 사용하는 것이 중요하고, 뜻이 하나인 동사를 써야 사용자가 원하는 결과를 얻는데 도움이 됩니다. 예) "체중을 줄이다" 보다는 "체중을 감소시키다"의 단어를 사용하는 것이 명확한 의도를 전달하는데 좋습니다. 또한 일상어를 사용하는 것이 원하는 결과를 얻는데 도움이 될 수 있습니다. 이는 언어모델이 학습한 데이터가 web base를 기반으로 학습되었기 때문에 대부분의 단어들이 일상어로 구성되어 있기 때문입니다.두 번째 : 지시하는 문장을 처음 또는 끝에 배치 프롬프트 문장에서 위치도 중요합니다. 일부 언어 모델의 경우 지시문이 마지막에 들어가는 경우 정확한 답변을 제공합니다. 이러한 문제가 생기는 이유는 프롬프트가 긴 경우 중간에 내용을 언어모델이 이를 놓치는 경우가 발생 (Lost in the middle 현상이라고 부름)하여, 지시문에 따라 정확한 답변을 수행하지 못하는 경우가 있습니다.세 번째 : 기호를 활용 기호를 사용하면 AI가 정보를 더 잘 이해하고
2025.04.22
좋아요
별로에요
LY Corporation의 프런트엔드 기술 동향을 알아보자! State of LY Frontend 2024 실시 보고서
LY Corporation에서는 2024년 10월에 사내 웹 프런트엔드 개발에 관여하는 사내 구성원을 대상으로 본인이 생각하는 2024년의 웹 프런트엔드 관련 근황 및 관련 툴 이용 현황을 알아보는 설문 조사, 'State of LY Frontend 2024'를 실시했습니다. 이와 유사한 설문 조사로 State of JavaScript나 State of CSS가 많이 알려져 있는데요. 이런 설문 조사의 LY Corporation 사내 버전이라고 생각하시면 이해하기 쉬울 것 같습니다.이번 설문 조사는 합병 후 1년여의 시간이 흐르며 새로 탄생한 회사의 체제가 정비된 후 처음으로 전사적으로 실시된 설문 조사입니다. 그 덕분에 웹 프런트엔드 개발자만 342명이 참여하는 등 단독 그룹사 직원을 대상으로는 드물게 대규모 조사 결과를 얻을 수 있었습니다.이례적으로 많은 응답을 받은 만큼 설문 조사 결과 내역을 더 자세히 살펴볼 수 있는 웹페이지도 제작했습니다(아쉽지만 사내에서만 접근 가능해 이 글에서 공유하지는 않겠습니다). 이를 통해 서로 관련 있는 각 문항의 응답을 연관 짓고 비교해 볼 수 있었고, State of JavaScript 및 State of CSS의 결과와 비교해 LY Corporation의 웹 프런트엔드 동향은 어떠한지 그 특징을 자세히 살펴볼 수 있었습니다. 이번 글에서는 그 중에서 특히 흥미로웠던 점을 골라 살펴보겠습니다.• 대상: LY Corporation 그룹 프런트엔드 엔지니어(한국, 일본, 베트남, 대만 조직 소속)다음은 응답자의 소속 조직을 살펴본 결과입니다. 응답자 비율을 살펴보면 일본(LY Corporation) 외에도 베트남 거점(LINE VIETNAM COMPANY LIMITED/LINE TECHNOLOGY VIETNAM CO., LTD)과 한국 거점(LINE Plus Corporation), 대만 거점(LINE Taiwan Limited) 등 다양한 지역의 구성원이 설문 조사에 참여했습니다.다음은 응답자들의 현재 회사에서의 근무 기간을 조사한 결과입니다. 입사한 지 5년 미만인 임직원의 비율이 가장 높았으며 10년 이상 근무한 임직원도 상당수 있었습니다. 또한 조직에 따라 응답자들의 근무 기간 구성 비율에 편차가 있다는 것도 알 수 있었습니다.다음은 현재 어떤 분야의 업무를 맡고 있는지 조사한 결과입니다. 복수 응답이 가능했는데요. 백엔드 개발에 참여하고 있다고 답한 응답자 중 77%가 프런트엔드 개발에도 참여하고 있다고 응답했습니다. 특히 Yahoo Japan Corporation 출신 구성원 중 상당수가 프런트엔드를 담당하면서 백엔드 나 디자인 분야를 함께 담당하고 있는 것으로 나타났는데요. 이는 구 LINE Corporation에서는 웹 프런트엔드 개발이 비교적 독립적인 개발 조직이었던 반면, 구 Yahoo Japan Corporation에서는 백엔드 개발자나 디자이너가 웹 프런트엔드 개발을 겸하는 경우가 많았기 때문입니다.또한 위 조사 결과에서는 응답자 342명 중 웹 프런트엔드 개발을 담당한다고 응답
javascript
nextjs
reactjs
vuejs
4/22/2025
LY Corporation의 프런트엔드 기술 동향을 알아보자! State of LY Frontend 2024 실시 보고서
LY Corporation에서는 2024년 10월에 사내 웹 프런트엔드 개발에 관여하는 사내 구성원을 대상으로 본인이 생각하는 2024년의 웹 프런트엔드 관련 근황 및 관련 툴 이용 현황을 알아보는 설문 조사, 'State of LY Frontend 2024'를 실시했습니다. 이와 유사한 설문 조사로 State of JavaScript나 State of CSS가 많이 알려져 있는데요. 이런 설문 조사의 LY Corporation 사내 버전이라고 생각하시면 이해하기 쉬울 것 같습니다.이번 설문 조사는 합병 후 1년여의 시간이 흐르며 새로 탄생한 회사의 체제가 정비된 후 처음으로 전사적으로 실시된 설문 조사입니다. 그 덕분에 웹 프런트엔드 개발자만 342명이 참여하는 등 단독 그룹사 직원을 대상으로는 드물게 대규모 조사 결과를 얻을 수 있었습니다.이례적으로 많은 응답을 받은 만큼 설문 조사 결과 내역을 더 자세히 살펴볼 수 있는 웹페이지도 제작했습니다(아쉽지만 사내에서만 접근 가능해 이 글에서 공유하지는 않겠습니다). 이를 통해 서로 관련 있는 각 문항의 응답을 연관 짓고 비교해 볼 수 있었고, State of JavaScript 및 State of CSS의 결과와 비교해 LY Corporation의 웹 프런트엔드 동향은 어떠한지 그 특징을 자세히 살펴볼 수 있었습니다. 이번 글에서는 그 중에서 특히 흥미로웠던 점을 골라 살펴보겠습니다.• 대상: LY Corporation 그룹 프런트엔드 엔지니어(한국, 일본, 베트남, 대만 조직 소속)다음은 응답자의 소속 조직을 살펴본 결과입니다. 응답자 비율을 살펴보면 일본(LY Corporation) 외에도 베트남 거점(LINE VIETNAM COMPANY LIMITED/LINE TECHNOLOGY VIETNAM CO., LTD)과 한국 거점(LINE Plus Corporation), 대만 거점(LINE Taiwan Limited) 등 다양한 지역의 구성원이 설문 조사에 참여했습니다.다음은 응답자들의 현재 회사에서의 근무 기간을 조사한 결과입니다. 입사한 지 5년 미만인 임직원의 비율이 가장 높았으며 10년 이상 근무한 임직원도 상당수 있었습니다. 또한 조직에 따라 응답자들의 근무 기간 구성 비율에 편차가 있다는 것도 알 수 있었습니다.다음은 현재 어떤 분야의 업무를 맡고 있는지 조사한 결과입니다. 복수 응답이 가능했는데요. 백엔드 개발에 참여하고 있다고 답한 응답자 중 77%가 프런트엔드 개발에도 참여하고 있다고 응답했습니다. 특히 Yahoo Japan Corporation 출신 구성원 중 상당수가 프런트엔드를 담당하면서 백엔드 나 디자인 분야를 함께 담당하고 있는 것으로 나타났는데요. 이는 구 LINE Corporation에서는 웹 프런트엔드 개발이 비교적 독립적인 개발 조직이었던 반면, 구 Yahoo Japan Corporation에서는 백엔드 개발자나 디자이너가 웹 프런트엔드 개발을 겸하는 경우가 많았기 때문입니다.또한 위 조사 결과에서는 응답자 342명 중 웹 프런트엔드 개발을 담당한다고 응답
2025.04.22
javascript
nextjs
reactjs
vuejs
좋아요
별로에요
AI는 어디까지 나를 대체할 수 있나?
'나’는 누구인가?카카오에서 내부플랫폼을 개발을 하고있는 hook.jeong입니다. 제가 AI를 처음 개발자로서 접하게 된건 사내 설명서 서비스에 챗봇을 도입하는 일이었습니다. 이후 AI Native TF에서 사내 지식베이스 에이전트를 개발했고, 사외 교육에서 AI 프로젝트 멘토와 심사위원으로 활동하며 AI 분야에 대한 경험을 쌓아왔습니다. 현재는 AIOps와 관련된 개발을 진행하고 있으며, 일상적인 개발 업무에서도 LLM을 적극 활용하고 있습니다.'나’는 왜 "Vibe"를 해보게 되었나?최근 AI를 활용한 Vibe Coding이 개발자들 사이에서 주목받고 있습니다. 이는 자연스럽게 "AI가 개발자를 대체할 수 있을까?"라는 논쟁으로 이어지고 있습니다. 이러한 논쟁을 지켜보며 한 가지 궁금증이 생겼습니다. "지금의 AI는 과연 '내’가 하는 일을 어디까지 대신할 수 있을까? 개발 업무 중, AI가 실제로 대체 가능한 영역은 어디까지일까?"라는 호기심을 해결하기 위해, AI의 개발자 대체 가능성을 직접 검증해보는 토이 프로젝트를 진행하기로 결정했습니다.'나’는 무엇을 검증하고자 했나?플랫폼 개발자로서 수행하는 주요 업무를 요구사항 분석, 시스템 설계, 데이터 설계, 코딩, 서비스 운영으로 크게 다섯 가지로 분류해보았습니다. 이 중에서 AI의 개발자 대체 가능성을 검증하기 위해 코딩 영역에 초점을 맞추기로 했습니다. 구체적인 검증 항목은 다음 세 가지입니다:• 코드 없이 구어체만으로 웹 프로젝트를 구현할 수 있는가?• 가능하다면 어느 정도의 속도로 개발할 수 있는가?• 정말 개발자의 개입 없이 구현이 가능한가?어떤 기준으로 검증을 해보았나?• 등록된 MCP를 Elasticsearch를 통하여 검색• 완전히 빈 프로젝트에서 시작• 는 Cursor 디렉터리 내 인기 설정 기준으로 선택• 모든 개발은 구어체 입력 후 accept 방식으로 수행• 에러 발생 시 검색 없이 copy & paste로 해결• 오류 없이 기능이 수행되는 것은 완성이라고 정의1. 코드 없이 구어체만으로 구현 가능한가?구현은 가능합니다. 오류 없이 기능이 정상적으로 수행되는 수준을 기준으로 보았을 때, 구어체만으로도 웹 프로젝트를 충분히 구현할 수 있었습니다. 실제로 단 한 줄의 코드도 직접 작성하지 않고, 프로젝트의 핵심 기능을 구현하는 데 성공했습니다.2. 구현 속도는 어느 정도인가?개발 속도 측면에서는 기존 방식과 비교할 수 없을 정도로 빠릅니다. 사내 콘솔, 외부 인증 페이지, 설명서 사이트 등 다양한 웹 프로젝트를 설계하고 개발한 경험이 있는 저의 기준으로도, 일반적인 개발 방식으로는 최소 3일 이상의 개발 기간이 필요할 것으로 예상됩니다. 그러나 이번 실험에서는 단 6시간 만에 4개의 페이지(24개 파일, 1,500줄 이상의 코드)를 구현할 수 있었습니다. 완전히 처음부터 만든 경우라는 점을 고려했을 때, AI 도구를 활용하면 얼마나 빠르게 목표에 도달할 수 있는지 알 수 있었습니다.3. 개발자의 개입 없이 가능한가?현재 수준에서는 개발자의 개입 없이 진행하는 것은
4/22/2025
AI는 어디까지 나를 대체할 수 있나?
'나’는 누구인가?카카오에서 내부플랫폼을 개발을 하고있는 hook.jeong입니다. 제가 AI를 처음 개발자로서 접하게 된건 사내 설명서 서비스에 챗봇을 도입하는 일이었습니다. 이후 AI Native TF에서 사내 지식베이스 에이전트를 개발했고, 사외 교육에서 AI 프로젝트 멘토와 심사위원으로 활동하며 AI 분야에 대한 경험을 쌓아왔습니다. 현재는 AIOps와 관련된 개발을 진행하고 있으며, 일상적인 개발 업무에서도 LLM을 적극 활용하고 있습니다.'나’는 왜 "Vibe"를 해보게 되었나?최근 AI를 활용한 Vibe Coding이 개발자들 사이에서 주목받고 있습니다. 이는 자연스럽게 "AI가 개발자를 대체할 수 있을까?"라는 논쟁으로 이어지고 있습니다. 이러한 논쟁을 지켜보며 한 가지 궁금증이 생겼습니다. "지금의 AI는 과연 '내’가 하는 일을 어디까지 대신할 수 있을까? 개발 업무 중, AI가 실제로 대체 가능한 영역은 어디까지일까?"라는 호기심을 해결하기 위해, AI의 개발자 대체 가능성을 직접 검증해보는 토이 프로젝트를 진행하기로 결정했습니다.'나’는 무엇을 검증하고자 했나?플랫폼 개발자로서 수행하는 주요 업무를 요구사항 분석, 시스템 설계, 데이터 설계, 코딩, 서비스 운영으로 크게 다섯 가지로 분류해보았습니다. 이 중에서 AI의 개발자 대체 가능성을 검증하기 위해 코딩 영역에 초점을 맞추기로 했습니다. 구체적인 검증 항목은 다음 세 가지입니다:• 코드 없이 구어체만으로 웹 프로젝트를 구현할 수 있는가?• 가능하다면 어느 정도의 속도로 개발할 수 있는가?• 정말 개발자의 개입 없이 구현이 가능한가?어떤 기준으로 검증을 해보았나?• 등록된 MCP를 Elasticsearch를 통하여 검색• 완전히 빈 프로젝트에서 시작• 는 Cursor 디렉터리 내 인기 설정 기준으로 선택• 모든 개발은 구어체 입력 후 accept 방식으로 수행• 에러 발생 시 검색 없이 copy & paste로 해결• 오류 없이 기능이 수행되는 것은 완성이라고 정의1. 코드 없이 구어체만으로 구현 가능한가?구현은 가능합니다. 오류 없이 기능이 정상적으로 수행되는 수준을 기준으로 보았을 때, 구어체만으로도 웹 프로젝트를 충분히 구현할 수 있었습니다. 실제로 단 한 줄의 코드도 직접 작성하지 않고, 프로젝트의 핵심 기능을 구현하는 데 성공했습니다.2. 구현 속도는 어느 정도인가?개발 속도 측면에서는 기존 방식과 비교할 수 없을 정도로 빠릅니다. 사내 콘솔, 외부 인증 페이지, 설명서 사이트 등 다양한 웹 프로젝트를 설계하고 개발한 경험이 있는 저의 기준으로도, 일반적인 개발 방식으로는 최소 3일 이상의 개발 기간이 필요할 것으로 예상됩니다. 그러나 이번 실험에서는 단 6시간 만에 4개의 페이지(24개 파일, 1,500줄 이상의 코드)를 구현할 수 있었습니다. 완전히 처음부터 만든 경우라는 점을 고려했을 때, AI 도구를 활용하면 얼마나 빠르게 목표에 도달할 수 있는지 알 수 있었습니다.3. 개발자의 개입 없이 가능한가?현재 수준에서는 개발자의 개입 없이 진행하는 것은
2025.04.22
좋아요
별로에요