1 6월 2014

弘益人間 (홍익인간)

사용자의 삶의 만족도를 높이고 불쾌함과 짜증을 감소시키는 견고하고 에러없는 소프트웨어 개발을 목표로 세월이 지나도 혁신적인 활동을 “에스 테크 스타 닷컴”은 이어갑니다.  좋은 소프트웨어 창출로 정보기술의 弘益人間 (홍익인간)을 구현합니다.

 


 

 

 

 

 

혼자가 아닌 나!


 

Loading

1 6월 2014

comphy’s profile

2014년
대한민국 공군 사이버전실습 및 대응체계 개발:평택공군제7전대
에스테크스타닷컴 에스천사게임즈 오픈
ebook 출판 예정

2013년
KT BIT OSS 프로젝트

2012년
삼성전자 가전사업부 표준화파트너 시스템 개발 (Java,JSP,Oracle)
행안부 종합장애대응체계 / 복지부 행복e음 유지보수

2011년
삼성전자 스마트그리드 서버 및 스마트TV 앱 검증 서버
삼성bada 2.0 검증 어플리케이션 개발 (MWC2011출품)

2010년
[LGU+] 패킷관련 프로젝트
[수원,구미] 삼성전자 MMP 프로젝트 (터치모바일플랫폼) : 피쳐폰의 스마트화

2009년
[천안] 삼성코닝 정밀유리 : S-Contour 프로젝트

2008년
삼성전자 소프트웨어연구소 QMO과제 수행

 

 

 

 

Loading

19 4월 2012

네 시작은 미약하였으나 네 나중은 심히 창대하리라.

네 시작은 미약하였으나 네 나중은 심히 창대하리라.

Your beginnings will seem humble, so prosperous will your future be….

나라장터 조달업체 등록 : 2014-07-04

한국SW산업협회 소프트웨어사업자등록 : B14-87964

출판업 신고 : 수지구청 제 123호

통신판매업 신고 : 제2012-용인수지-0185호

사업자 신고 : 용인 142-07-27414

sjkim_cc

 

 

Loading

13 5월 2999

Web Cloud & mobile App Business working Link

Web Cloud & mobile App Business working Link

  1. Biz Design Workplace
  2. Biz marketing tools Workplace
  3. Biz reference datas
    1. 프리렌서 업무 [크몽] : https://kmong.com/
    2. 모바일 앱 시장조사 [와이즈앱] : https://www.wiseapp.co.kr/
    3. 프리렌서 업무 [위시켓] : https://www.wishket.com
    4. 프리랜서 업무 [프리모아] : http://www.freemoa.net/
    5. 프리렌서 업무 [이렌서] : http://www.elancer.co.kr/
  4. Biz online Developing tool
  5. cloud developer console
    1. microsoft azure : https://azure.microsoft.com/ko-kr
    2. google developer console : https://console.cloud.google.com/?hl=ko
    3. amazon AWS : https://aws.amazon.com/ko/console/
  6. Mobile App Biz market
    1. android developer console : https://play.google.com/apps/publish/?hl=ko
    2. onestore (T Store) : http://dev.onestore.co.kr/devpoc/index.omp
    3. apple app store : https://developer.apple.com/app-store/
  7. 지적재산권 등록
    1. 특허정보검색(KIPRIS) : http://www.kipris.or.kr/khome/main.jsp
    2. 특허로(특허출원) : http://www.patent.go.kr/portal/Main.do

 

 

 

Loading

13 5월 2999

매일 들르는 곳 : nooksurfer : ホームページの閲覧えつらん者しゃ

매일 들르는 곳 : nooksurfer : ホームページの閲覧えつらん者しゃ

 

 

자주 들르는 곳 : Frequent stop :

 

모바일 (게임)개발툴 사이트

 

 

 웹 (사이트) 개발

 

 

디지털 마켓

 

 

멀티미디어 리소스 (마켓)

 

인문학과 사회와 재경학에 관심을 가져보자

 

오프라인 교육 기관

 

Loading

10 12월 2025

[인공지능 개발자] Spring AI로 LLM 연결하기(Feat: ollama)

[인공지능 개발자] Spring AI로 LLM 연결하기(Feat: ollama)

들어가면서

올해 초 LLM에 관심이 생겨 이것저것 찾아보다가 Spring AI를 알게 되었고, 최근 정식 버전인 1.0.0이 출시되면서 본격적으로 공부하게 되었습니다.
제가 느끼기에 Spring AI는 LLM 연결을 매우 쉽게 도와주며, 다음과 같은 다양한 기능을 제공합니다:

  • 프롬프트 전처리/후처리를 위한 Advisor
  • JSON → DTO 구조화 출력 지원
  • LLM이 메서드를 직접 호출하는 Function Calling
  • RAG, MCP, 멀티모달 등 다양한 고급 기능 지원

덕분에 이제는 Python 기반 도구가 아니더라도, Java 환경에서도 LLM을 효과적으로 활용할 수 있게 되었습니다.
이 블로그 시리즈는 총 3편으로 구성될 예정이며, 각 주제는 다음과 같습니다:

  1. Spring AI로 LLM 연결하고 구조화된 출력하기
  2. Advisor로 LLM에 추가 정보 제공 및 응답 가공하기 (feat. RAG)
  3. Function Calling으로 LLM에게 메서드 제공하기 (feat. AI Agent)
    이번 포스팅은 그 첫 번째 주제인 “Spring AI로 LLM 연결하고 구조화된 출력하기”입니다.

기본적인 설정법

Spring AI는 다양한 LLM 제공자(OpenAI, Azure, Ollama 등)와 연동할 수 있습니다.
저는 이 포스팅에서 로컬에서 실행 가능한 오픈소스 플랫폼인 Ollama를 기준으로 설명하겠습니다.

  • 참고: Spring AI는 Java 17 이상부터 지원됩니다.

Ollama는 다양한 오픈소스 LLM을 PC에 직접 다운로드하여 실행할 수 있는 플랫폼입니다.
따라서 외부로 유출되면 안 되는 개인정보나 대외비 문서를 처리할 때 적합한 선택이 될 수 있습니다.

 - 의존성 추가 (Maven 기준)
<dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-starter-model-ollama</artifactId>
</dependency>
 - 설정 파일 기본적인 설정
 # Ollama 서버 주소
spring.ai.ollama.base-url=http://localhost:11434 
# 모델 다운로드 전략(always, when_missing, never)
spring.ai.ollama.init.pull-model-strategy=when_missing
# 기본 셋팅 llm모델
spring.ai.ollama.chat.model= qwen3:1.7b 
# 창의성 조절: 높을수록 자유로운 응답
spring.ai.ollama.chat.temperature= 0.8
# 최대 응답 토큰 수
spring.ai.ollama.chat.max-tokens= 1024
# Embedding 모델
spring.ai.ollama.embedding.model=bona/bge-m3-korean

추가적인 설정에 대해서는 url에서 확인 가능합니다.
https://docs.spring.io/spring-ai/reference/api/chat/ollama-chat.html#_chat_properties


예제 코드

Spring AI에서는 LLM의 응답을 두 가지 방식으로 받을 수 있습니다.

  1. 단일 출력 방식: 한 번에 전체 응답을 받아 처리
  2. 스트리밍 출력 방식 (Flux): LLM 응답을 실시간으로 조각 단위로 받기
    예제를 통해 두 방식의 사용법과, JSON 구조화된 출력 방식까지 함께 살펴보겠습니다.

???? ChatModel과 ChatClient의 차이

Spring AI에는 ChatModel과 ChatClient라는 두 개의 주요 구성 요소가 있습니다.

  • ChatModel: LLM과의 저수준 통신 역할을 합니다.
  • ChatClient: ChatModel을 래핑한 상위 레벨 API로, 프롬프트 구성, 응답 처리, Advisor, RAG 등 다양한 확장 기능을 제공합니다.

단일 출력 방식

@AllArgsConstructor
@RestController
public class ModelClient {

    // Spring이 OllamaChatModel 구현체 자동 주입
    private final ChatModel chatModel;

    @GetMapping("/v1/model-client")
    public ChatResponse modelClientV1(@RequestParam("text") String text) {

        // 시스템 메시지는 LLM이 반드시 지켜야 할 지침
        // 유저 메시지는 사용자의 입력
        Prompt prompt = new Prompt(
                List.of(
                        new SystemMessage("너는 친절한 AI 비서야. 절대 추론 과정을 보여주지 말고 요약만 응답해."),
                        new UserMessage(text)
                ));

        return ChatClient.create(chatModel)
                .prompt(prompt)
                .call()
                .content(); // 전체 응답을 한 번에 반환
    }
}

스트리밍 출력 방식 (Flux)

스트리밍 방식은 채팅처럼 실시간으로 응답이 필요한 UI에 적합합니다.

@AllArgsConstructor
@RestController
public class ModelClient {

  private final ChatModel chatModel;

  @GetMapping(value = "/v2/model-client", produces = "text/plain;charset=UTF-8")
  public Flux<String> getModelClientV2(@RequestParam("text") String text) {

      // 시스템 메시지는 LLM이 반드시 지켜야 할 지침
      // 유저 메시지는 사용자의 입력
      Prompt prompt = new Prompt(
              List.of(
                      new SystemMessage("너는 친절한 AI 비서야"),
                      new UserMessage(text)
              ));

      return ChatClient.create(this.chatModel)
              .prompt(prompt)
              .stream() // 스트리밍 응답 시작
              .content(); // Flux<String>으로 실시간 조각 응답 수신
    }
}

구조화된 출력 받기 (JSON → DTO)

내부적으로는 LLM에게 “이런 구조로 응답해줘”라고 명시한 후 결과를 DTO에 바인딩합니다.
하지만 LLM이 해당 형식대로 정확하게 응답하지 않으면 파싱 에러가 발생할 수 있습니다.
안정성을 높이기 위해 시스템 메시지에 형식을 반복적으로 명확히 명시하거나, 구조 유도 프롬프트 예제를 함께 제공하는 것이 좋습니다.

@AllArgsConstructor
@RestController
public class ModelClient {

    private final ChatModel chatModel;

    @GetMapping("/v3/model-client")
    public ActorFilms modelClientV3(@RequestParam("text") String text) {

        // 사용자 입력을 이용해 프롬프트 템플릿 구성
        String template = """
            Generate the filmography of 5 movies for {actor}.
        """;

        Prompt prompt = new Prompt(
                List.of(
                        new SystemMessage("너는 친절한 AI 비서야. 절대 추론 과정을 보여주지 말고 요약만 응답해."),
                        new UserMessage(new PromptTemplate(template).render(Map.of("actor", text)))
                ));

        ChatModel gemma = OllamaChatModel.builder()
                .ollamaApi(OllamaApi.builder().build())
                .defaultOptions(
                        OllamaOptions.builder()
                                .model("gemma3n:e4b")
                                .temperature(0.4)
                                .build())
                .build();

        return ChatClient.create(gemma)
                .prompt(prompt)
                .call()
                .entity(ActorFilms.class); // 결과를 DTO로 구조화
    }

    record ActorFilms(String actor, List<String> movies) {}
}

프롬프트 요청 예시 (내부 동작 확인용)
Spring AI가 구조화 출력을 위해 내부적으로 LLM에게 다음과 같이 요청을 구성합니다.

request: ChatClientRequest[
- 저희가 입력한 명령 프롬프트 입력입니다.
prompt=Prompt{
    messages=[SystemMessage{textContent='너는 친절한 AI 비서야. 절대 추론과정을 보여주지 말고 요약만 응답해', messageType=SYSTEM, metadata={messageType=SYSTEM}}, 
    UserMessage{content='Generate the filmography of 5 movies for 하정우.', properties={messageType=USER}, messageType=USER}], modelOptions=org.springframework.ai.ollama.api.OllamaOptions@48e29a2c}, 

- 여기에 해당 DTO 객체의 정의가 들어갑니다.
context={spring.ai.chat.client.output.format=Your response should be in JSON format.
Do not include any explanations, only provide a RFC8259 compliant JSON response following this format without deviation.
Do not include markdown code blocks in your response.
Remove the ```json markdown from the output.
Here is the JSON Schema instance your output must adhere to:
```{
  "$schema" : "https://json-schema.org/draft/2020-12/schema",
  "type" : "object",
  "properties" : {
    "actor" : {
      "type" : "string"
    },
    "movies" : {
      "type" : "array",
      "items" : {
        "type" : "string"
      }
    }
  },
  "additionalProperties" : false
}```
}]

마치며

AI를 실제 프로젝트에 도입하는 것은 어렵고 복잡할 것 같다는 막연한 생각이 있었지만,
Spring AI를 통해 Java 환경에서도 LLM을 손쉽게 연결하고 활용할 수 있다는 가능성을 확인할 수 있었습니다.

물론 성능, 속도, 프롬프트 설계, 적절한 모델 선택 등 실무에서 고려할 요소들은 많지만,
이번 실습을 통해 LLM을 실제 서비스에 적용하는 출발점을 잡을 수 있었습니다.

다음 포스팅에서는 Advisor 기능을 활용해 LLM 응답을 가공하고,
간단한 RAG(Retrieval-Augmented Generation) 기능을 구현해보겠습니다.

이 기능은 Logging, 크롤링된 문서, RDBMS 정보 등 다양한 외부 지식 소스를 LLM과 연결해
더 정확하고 신뢰도 높은 응답을 생성하도록 도와주는 방식입니다.

해당 예시는 github에 있습니다.
url: https://github.com/Zero-Human/springAi

참고자료

[출처] https://zero-human.tistory.com/9

Loading

8 12월 2025

[인공지능 기술]  AI 시대의 비판적 사고 

[인공지능 기술]  AI 시대의 비판적 사고 

47P by neo 7일전 | ★ favorite | 댓글과 토론
  • AI가 코드와 설계, 답변을 만들어주는 환경에서도 올바른 질문을 던지고 가정을 의심하는 비판적 사고가 엔지니어와 팀의 성과를 좌우하는 핵심 역량임
  • 문제 해결 전 과정에서 Who·What·Where·When·Why·How 여섯 가지 질문을 활용해 사람·문제·맥락·타이밍·원인·실행 방식을 체계적으로 점검해야 함
  • AI의 답변은 인턴이 제안한 초안처럼 검증 대상으로 다루고, 실제 문제 정의·증거 수집·맥락 파악·원인 분석·의사소통은 사람이 책임지는 구조가 필요함
  • 시간 압박·편향·그럴듯한 AI 답변 때문에 성급한 결론과 땜질식 해결책으로 흐르기 쉬우며, 이를 막기 위해 5 Whys·실험·데이터 검증 등 증거 기반 사고를 반복해야 함
  • 비판적 사고는 겸손한 호기심과 증거를 중시하는 팀 문화에서 강화되며, AI가 아무리 발전해도 “옳은 문제를, 옳은 이유로, 옳은 방식으로 푸는 것”은 여전히 인간의 고유한 장점임

AI 시대 비판적 사고 개요

  • AI가 코드·디자인·답변을 만들어주는 시대에 사람의 비판적 사고 능력이 예전보다 더 중요해지고 있음
    • 자동화가 아무리 정교해져도, 올바른 질문을 던지고 가정을 의심하며 독립적으로 사고하는 역할은 사람 몫으로 남아 있음
    • 잘못된 질문과 잘못 정의된 문제 위에 쌓인 AI 출력은 프로젝트를 더 빠르게 잘못된 방향으로 밀어붙이는 결과로 이어질 수 있음
  • 비판적 사고를 위해 Who·What·Where·When·Why·How 프레임워크를 사용해 구체적인 실천 지침을 제시함
    • 각 질문은 문제 정의, 이해관계자, 맥락, 타이밍, 원인 분석, 실행·커뮤니케이션 방법을 점검하는 도구로 활용됨
    • AI 보조 환경에서 이 여섯 가지를 놓치지 않는 것이 프로젝트 실패를 줄이고 다운스트림 문제를 예방하는 핵심임

tl;dr: AI 팀을 위한 비판적 사고 체크리스트

  • Who: AI를 전지적 존재가 아닌 검증이 필요한 입력으로 간주하고, 누가 답을 내고 있는지 항상 확인해야 함
    • LLM의 답변을 사람의 견해와 동일시하지 않고, 출처와 책임 소재를 분리해 보는 시각이 필요함
  • What: 솔루션으로 달려가기 전에 진짜 문제 정의와 성공 기준을 분명히 해야 함
    • 표면적인 요구사항 대신, 사용자 경험과 데이터를 바탕으로 실제로 풀어야 할 문제를 명확히 규정해야 함
  • Where: 해결책이 적용될 맥락과 환경(샌드박스·프로덕션·사용자 기기 등) 을 고려해야 함
    • 한 환경에서 잘 작동하는 해결책이 다른 환경에서 부작용을 낳을 수 있음을 항상 염두에 두어야 함
  • When: 간단한 휴리스틱으로 충분한 상황과 깊이 있는 분석이 필요한 상황을 구분해야 함
    • 응급 땜질과 근본 원인 분석의 시점을 나누어, 시간 제약 속에서도 최소한의 엄밀함을 확보해야 함
  • Why / How: 5 Whys로 근본 원인을 추적하고, 의견이 아닌 데이터·증거 중심으로 커뮤니케이션해야 함
    • 주장보다 근거, 직감보다 실험·측정 결과를 우선하는 태도가 필요함

Who: 참여 주체·책임·영향 범위

  • 문제를 정의하고 해결에 참여하는 사람과 관점의 구성(누가 포함되고 누가 빠져 있는지) 이 비판적 사고의 출발점임
    • 엔지니어·PM·사용자·도메인 전문가 등 이해관계자를 파악하고, 의사결정 과정에 적절히 포함해야 함
    • 문제는 대부분 여러 팀과 사용자에게 영향을 미치므로, “누구와 상의해야 하는가, 누구에게 알려야 하는가”를 먼저 묻는 태도가 필요함
  • 한 목소리로만 의견이 모이는 groupthink(집단사고) 위험을 줄이기 위해 다양한 시각을 의도적으로 끌어들여야 함
    • 반대 의견이나 다른 관점을 가진 사람을 배제하면, 데이터와 가정의 타당성 검증 없이 정답처럼 굳어지는 위험이 커짐
    • 외부 시각이나 팀 밖 사람을 불러 “새 눈”으로 문제를 보게 하는 것도 객관성을 높이는 방법임
  • AI가 등장한 뒤에는 “누구의 답인가, 인간인가 AI인가” 를 분리해서 보는 시각이 필수임
    • LLM은 통계적 엔진에 불과하므로, “누가 말했다”보다 “무엇을 근거로 말했는가” 를 따져야 함
    • AI 코드를 인턴의 코드처럼 취급해, 리뷰·테스트·맥락 적합성 검증을 사람이 책임져야 함
  • 최종적으로는 책임과 영향 범위(누가 책임지고, 누가 영향을 받는가) 까지 포함해 생각해야 함
    • 급한 패치가 당장은 관리자 요구를 충족해도, 이후 유지보수·장애 대응 부담은 다른 엔지니어나 사용자에게 돌아올 수 있음
    • API 변경이 모바일 앱·다른 마이크로서비스에 미치는 영향처럼, “누가 이 결정의 결과를 떠안게 되는가”를 항상 함께 고려해야 함

What: 진짜 문제 정의와 증거 수집

  • 비판적 사고의 핵심은 “무엇이 실제 문제인가”를 정확히 정의하는 일
    • “AI 요약 기능을 넣자” 같은 요청이 오면, 먼저 목표가 데이터 이해 향상인지, 피로도 감소인지, 다른 것인지를 따로 물어야 함
    • 사용자가 느끼는 어려움이 데이터 과잉인지, 시각화 부족인지, 설명 부재인지에 따라 솔루션이 전혀 달라질 수 있음
  • Harvard Business Review 등에서 강조하듯 문제 정의에 충분한 시간을 쓰면 잘못된 문제에 자원을 쓰는 위험을 줄일 수 있음
    • 요구사항과 성공 기준을 명시적으로 적고, “어떤 상태가 되면 문제가 해결된 것인가”를 합의하는 과정이 필요함
    • “문제 해결 모드”로 바로 뛰어드는 plunging-in bias(성급하게 뛰어드는 편향) 을 의식적으로 경계해야 함
  • 증상보다 구체적 사실을 모으는 증거 기반 문제 정의가 중요함
    • “서비스가 느리다”라는 말은 모호하므로, 어느 페이지·어떤 쿼리·어떤 요청이 느린지 데이터를 통해 좁혀야 함
    • “무엇이 느린가, 무엇이 언제부터 달라졌는가, 무엇이 최근에 변경되었는가” 같은 질문으로 로그·메트릭 등을 확인해야 함
  • 솔루션이나 결론에 대해 “이 결론을 뒷받침하는 증거는 무엇인가” 를 반복해 확인해야 함
    • AI가 null pointer를 원인으로 지목하면, 로그·테스트·재현 실험으로 이를 직접 검증해야 함
    • 성능 개선이라고 주장할 때는 여러 환경·여러 실행에서 일관된 지표 향상이 있는지 확인해야 함
  • LLM의 답변은 대부분 그럴듯해 보이지만, 정확성 보장은 없는 가설로 다루어야 함
    • 사람은 “충분히 그럴듯해 보이는 답”을 들으면 추가 탐색을 멈추는 경향이 있어, 이 조합이 특히 위험함
    • 비판적 사고는 AI·동료·본인의 아이디어를 모두 “테스트해야 할 가설”로 취급하고, 틀릴 수도 있다는 전제에서 시작함

Where: 맥락·환경·범위 인식

  • 해결하려는 문제와 솔루션이 어디에서 발생하고, 어디에 적용되는지(맥락) 를 파악하는 것이 중요함
    • 특정 마이크로서비스의 CPU 스파이크가 전체 시스템 장애로 오인되는 일을 막기 위해, 이슈가 발생하는 정확한 위치를 찾아야 함
    • 사용자 스마트폰·에지 디바이스·클라우드 서버 등 실행 환경에 따라 같은 코드도 전혀 다른 제약 조건을 갖게 됨
  • 디버깅 시에는 요청 흐름·컴포넌트 간 경계를 따라 “어디에서 실패가 발생했는가” 를 좁혀 가야 함
    • 클라이언트·API 게이트웨이·백엔드·데이터베이스 중 어떤 지점에서 문제가 생기는지 로그와 모니터링으로 분리해야 함
    • 기능 아이디어 논의 시에도, 사용자 여정 중 어느 단계에 영향을 주는지, 사용 빈도가 어느 구간에 집중되는지 같이 보는 것이 필요함
  • 실험과 배포에서도 어디에서 시험해 볼 것인가가 중요한 결정 요소임
    • 스테이징·사내용 환경·프로덕션 일부 트래픽 등 실험 위치에 따라 얻을 수 있는 신뢰도와 리스크가 달라짐
    • 실사용자 일부에 A/B 테스트로 노출하면 실세계 이슈를 빨리 발견할 수 있지만, 영향 범위를 제한하는 방어 장치도 필요함
  • “어디에서 부작용이 생길 수 있는가, 어디까지 파급될 수 있는가”를 미리 상상하는 것이 숙련된 엔지니어의 특징임
    • 공용 라이브러리 변경 시, 이를 사용하는 다른 서비스·팀을 목록화하고, 릴리즈 전에 알림·테스트 계획을 세워야 함
    • 특정 모듈의 최적화가 다른 모듈의 복잡도 증가·데이터 포맷 변경을 요구하는지 등 시스템 전반의 파장을 함께 검토해야 함

When: 시간 축과 깊이 선택

  • 문제 발생 시점·행동 시점 등 “언제”에 대한 정보가 원인 분석의 핵심 단서가 됨
    • “마지막으로 정상 동작하던 때가 언제인지, 그 이후 무엇이 변경되었는지”를 타임라인으로 정리하면 원인을 빠르게 좁힐 수 있음
    • 새 배포·야간 배치·설정 변경 등 특정 시간대 이벤트와 장애 발생 시간을 연결해 보는 습관이 중요함
  • 의사결정에서 언제 깊게 파고들고, 언제 휴리스틱으로 충분한지를 구분하는 것이 비판적 사고의 한 축임
    • 모든 문제에 완전한 분석을 시도하면 일정과 리소스를 감당할 수 없으므로, 리스크와 영향도에 따라 분석 깊이를 조절해야 함
    • 심야 장애 대응에서는 서비스 재시작 같은 단기 완화 조치로 복구한 뒤, 일과 시간에 루트 원인을 탐구하는 방식이 현실적인 전략임
  • NASA 사례에서처럼 스트레스와 시간 압박 속에서 인간의 판단 오류 가능성이 급격히 높아짐이 지적됨
    • 빠른 판단이 필요한 상황일수록, 오히려 “어디까지는 임시 조치, 어디부터는 반드시 재검토해야 하는 지점인지”를 미리 표시해두는 것이 중요함
    • “지금은 임시 해결이고, 나중에 반드시 원인 분석과 근본 조치를 한다”는 메모·티켓을 남겨두는 것만으로도 장기적인 품질에 도움이 됨
  • 제한된 시간 안에서 엄밀함을 유지하기 위해 우선순위와 삼각 측량(트리아지) 을 활용해야 함
    • 가장 위험한 가정을 먼저 시험하고, 덜 중요한 결정은 이후로 미루는 방식으로 시간을 배분해야 함
    • 새 기능 설계에서 알고리듬의 타당성과 리스크가 더 크다면, UI 세부보다 알고리듬 검증에 시간을 먼저 쓰는 식의 선택이 필요함
  • 비판적 사고는 “도움을 청할 타이밍”과 “멈추고 재고할 타이밍” 을 인식하는 능력과도 연결됨
    • 일정 시간 이상 진전이 없으면 다른 사람의 시선을 끌어들이고, 스프린트 마감·릴리즈 전 등 의도적으로 멈춰 검토하는 지점을 설정해야 함
    • 분석 마비와 성급한 결론 사이에서, 현재 결정에 충분한 정보가 있는지 스스로 체크하는 습관이 중요함

Why: 동기·원인·근거 파고들기

  • “왜 이 일을 하는가”를 반복해서 묻는 것은 무의미한 유행·모방을 걸러내고, 실질적 가치에 집중하는 필터 역할을 함
    • 새로운 AI 도구 도입·기능 추가 요청 등에서, 경쟁사 따라잡기인지, 실제 사용자 문제 해결인지 명확히 구분해야 함
    • “왜 중요한가”에 대한 설득력 있는 답이 있어야, 구현 과정에서 수많은 세부 의사결정이 일관성을 가질 수 있음
  • 문제가 발생했을 때는 5 Whys 기법으로 표면적 원인에서 더 깊은 원인까지 내려가는 과정이 중요함
    • 모델 정확도 하락을 예로 들면, 데이터 분포 변화·새 데이터 소스 추가·검증 부재·모니터링 부족 등 연쇄 원인을 한 단계씩 추적해야 함
    • 최종 원인이 데이터 파이프라인 검증 부족·모니터링 부재라면, 재학습만으로는 문제를 근본적으로 해결할 수 없다는 점이 드러남
  • “왜” 질문에서 인간은 확증 편향·성급한 결론에 빠지기 쉬움
    • 예전에 겪은 메모리 누수처럼 익숙한 원인에 생각이 고정되면, 새로운 설정 변경·데이터 변경 같은 다른 가능성을 무시하기 쉬움
    • 처음 떠오른 설명에 안주하지 않도록, 스스로 “다른 가능한 원인이 있는가, 이를 부정하는 증거는 없는가”를 묻는 태도가 필요함
  • 과거 기업 사례처럼 잘못된 “왜” 이해는 시장점유율 하락·전략 실패를 오랫동안 고치지 못하게 만드는 요인이 될 수 있음
    • 외부 요인 탓으로만 돌리고 내부 프로세스·품질·문화 문제를 보지 못하면, 엉뚱한 처방을 반복하게 됨
  • 좋은 엔지니어는 겸손한 호기심으로 “왜”를 묻고, 자신의 가정이 틀릴 수 있음을 열어두는 태도를 유지함
    • 아이디어가 성공할 것이라고 믿을 때도 “왜 그렇게 생각하는지, 데이터인지 직감인지”를 분리해서 본다음 검증 방향을 잡음
    • 의사결정 후에는 이유를 문서화·공유해, 나중에 상황이 바뀌었을 때 근거부터 다시 점검할 수 있게 함

How: 실천 방법과 커뮤니케이션

  • 비판적 사고를 일상에서 실천하는 방법은 질문 방식·증거 검증·커뮤니케이션 구조화 세 가지 축으로 정리됨
    • 막연한 “좋냐·나쁘냐” 대신, “어떤 사용자 니즈를 어떻게 다루며, 어디에서 실패할 수 있는가” 같은 구체적·개방형 질문을 던져야 함
    • 알고 있는 것과 모르는 것을 목록으로 분리하고, 모르는 것을 어떻게 실험·측정할지 계획하는 습관이 중요함
  • 증거를 다룰 때는 대안 해석 가능성·편향 유입 여부를 함께 확인해야 함
    • 한 번의 성능 테스트 결과가 우연인지 반복 가능한지, 다른 지표와 모순되지는 않는지 교차 검증해야 함
    • 자신의 이론을 뒷받침하는 데이터뿐 아니라, 반박할 수 있는 데이터도 일부러 찾는 태도가 필요함
  • 팀 차원에서는 프리모텀(premortem) 같은 기법으로 미리 실패 시나리오를 가정해 보는 방식도 소개됨
    • 프로젝트가 실패했다고 가정하고 그 이유를 적어보면, 계획 단계에서 간과했던 리스크와 숨은 가정을 드러낼 수 있음
  • 해결책을 전달할 때는 문제 정의(What·Why) → 제안 솔루션(How) → 근거 데이터·가정 순서로 논리를 구성하는 것이 효과적임
    • 전제와 트레이드오프를 명시하면, 다른 사람들이 아이디어를 검증·보완하기 쉬워지고, 스스로도 논리의 구멍을 발견하기 쉬움
    • “페이지 로드 시간이 대시보드 기준 평균 25% 개선되었다”처럼 의견보다 계량적 사실을 우선 제시하는 태도가 신뢰를 높임
  • 비판적 사고가 잘 작동하는 환경에서는 질문과 반론을 환영하는 커뮤니케이션 문화가 형성됨
    • 제안 뒤에 “이 논리에서 빠진 부분이 없는지, 우려되는 점이 있는지”를 동료에게 적극적으로 물으며 아이디어를 다듬음
    • 일방적 발표가 아니라, 여러 사람이 함께 논리를 검증하는 과정 자체가 솔루션의 품질을 끌어올리는 장치가 됨
  • 개인 차원에서는 회고와 학습을 통한 지속적인 사고 개선이 중요함
    • 서둘러 내린 결정으로 버그가 생겼다면, 이후 “어디서 무엇을 놓쳤는지, 다음에는 무엇을 다르게 할지”를 정리하는 미니 회고를 수행해야 함
    • 다른 회사의 포스트모텀·인지 편향 자료를 읽으며, 미래에 피해야 할 사고 함정을 미리 학습하는 것도 도움이 됨

결론: 인간 고유의 장점으로서의 비판적 사고

  • AI 활용도가 높아질수록, 비판적 사고는 선택이 아니라 필수 역량으로 자리 잡고 있음
    • Who·What·Where·When·Why·How를 통해 사람·문제·맥락·타이밍·원인·실행 방식을 체계적으로 점검해야 함
  • 건강한 팀 문화에서는 독립적인 사고와 질문하는 태도가 당연한 것으로 받아들여짐
    • “이게 진짜 해결책인지, 땜질인지”, “사용자가 정말 이 기능을 원하는지”, “데이터가 정말 개선을 보여주는지”를 누구나 물어볼 수 있어야 함
  • 비판적 사고는 빠른 땜질식 해결책의 유혹에서 팀을 보호하는 역할을 함
    • 당장 문제를 덮는 대신, 근본 원인을 확인하고 검증한 뒤 행동하는 것이 장기적으로 시간과 비용을 절약하는 길임
  • AI와 자동화가 반복 작업과 초안을 담당하는 시대에도, “옳은 문제를 옳은 이유로 옳은 방식으로 푸는 일”은 인간의 역할로 남아 있음
    • 겸손한 호기심과 증거 중심 사고를 유지하는 팀이 AI 시대에도 꾸준히 좋은 결과를 내는 팀이 될 것

[출처] https://news.hada.io/topic?id=24743&utm_source=weekly&utm_medium=email&utm_campaign=202549

Loading

2 12월 2025

Ollama 설치부터 모델 커스텀까지, 비개발자도 이해하는 이용 가이드

Ollama 설치부터 모델 커스텀까지, 비개발자도 이해하는 이용 가이드

 
개발자 PC에 로컬 LLM을 구축하는 가장 쉬운 방법, Ollama 설치 및 사용법을 소개합니다. Windows, Mac, Linux 설치부터 Modelfile 커스텀, REST API 연동까지 실용적인 예제를 통해 로컬 AI 개발의 첫걸음을 안내합니다.
 
Sep 18, 2025
 
Ollama 설치부터 모델 커스텀까지, 비개발자도 이해하는 이용 가이드
 

클라우드 API를 호출할 때마다 드는 비용 걱정, 사내 코드를 외부 AI 서비스에 보내는 찜찜함, 인터넷이 불안정할 때마다 멈춰버리는 개발 환경. 생성형 AI를 적극적으로 활용하고 싶은 개발자라면 누구나 한 번쯤 겪어봤을 불편함입니다. 만약 이 모든 제약 없이, 내 PC 안에서 자유롭게 LLM을 실행하고 테스트할 수 있다면 어떨까요?

이러한 개발자들의 갈증을 해소해 주는 최고의 솔루션으로 ‘Ollama’가 부상하고 있습니다. Ollama는 Llama 3, Mistral 등 강력한 오픈소스 LLM을 단 몇 줄의 명령어로 내 컴퓨터에 설치하고 실행할 수 있게 해주는 놀라운 도구입니다. 데이터는 내 PC 밖으로 절대 나가지 않으며, 비용도, 인터넷 연결도 필요 없습니다.

이 글에서는 개발자의 관점에서 Ollama를 설치하고, 핵심 기능을 익히고, 나만의 모델로 커스터마이징하여 최종적으로 내 애플리케이션과 연동하는 기초까지, 로컬 LLM 개발의 전체적인 그림을 완벽하게 마스터할 수 있도록 안내합니다.

Ollama 공식 홈페이지
Ollama 공식 홈페이지

1. Ollama, 3분 만에 설치하고 시작하기

Ollama의 가장 큰 장점은 압도적으로 간단한 설치 과정입니다. 복잡한 환경 설정 없이 각 운영체제에 맞는 방법으로 설치를 진행하세요.

1-1. Windows에 설치하기

  1. Ollama 공식 홈페이지에 접속하여 ‘Download for Windows’ 버튼을 클릭해 설치 파일을 다운로드합니다.
  2. 다운로드한 OllamaSetup.exe 파일을 실행하고 안내에 따라 설치를 완료합니다.
  3. 설치가 완료되면 Ollama는 백그라운드 서비스로 자동 실행됩니다. 터미널(CMD 또는 PowerShell)을 열고 다음 명령어를 입력해 보세요.
ollama --version

버전 정보가 정상적으로 출력된다면 설치에 성공한 것입니다.

1-2. macOS에 설치하기

  1. Ollama 공식 홈페이지에서 ‘Download for macOS’를 클릭합니다.
  2. 다운로드한 Ollama-darwin.zip 파일의 압축을 풀고 Ollama 앱을 ‘응용 프로그램’ 폴더로 옮깁니다.
  3. 앱을 실행하면 메뉴 막대에 Ollama 아이콘이 나타나며 백그라운드에서 실행됩니다. 터미널을 열고 동일하게 버전 확인 명령어를 실행합니다.
ollama --version
MacOS 터미널에서 Ollama 실행 화면
MacOS 터미널에서 Ollama 실행 화면

1-3. Linux에 설치하기

Linux에서는 터미널에 아래 명령어 한 줄만 입력하면 설치가 완료됩니다.

curl -fsSL <https://ollama.com/install.sh> | sh

이제 모든 준비가 끝났습니다. 본격적으로 LLM을 다뤄볼 시간입니다.

2. 터미널에서 LLM 조련하기: Ollama 핵심 명령어

Ollama는 직관적인 CLI(Command-Line Interface)를 통해 모델을 관리합니다. 가장 중요한 명령어 4가지만 기억하면 됩니다.

2-1. 모델 실행 및 다운로드: run

가장 기본이 되는 명령어입니다. 원하는 모델을 지정하여 실행하면, 해당 모델이 로컬에 없는 경우 자동으로 다운로드한 후 실행합니다. 가장 인기 있는 Meta의 Llama 3 모델을 실행해 보겠습니다.

ollama run llama3

명령을 실행하면 모델 다운로드가 시작되고, 완료되면 >>> Send a message (/? for help) 라는 프롬프트가 나타납니다. 이제 자유롭게 질문을 던져보세요.

llama3 설치 화면
llama3 설치 화면

2-2. 모델 미리 다운로드: pull

run 명령어는 다운로드와 실행을 한 번에 처리하지만, 미리 필요한 모델을 받아두고 싶을 때도 있습니다. 이때 pull 명령어를 사용합니다.

# 코딩에 특화된 codellama 모델을 미리 다운로드
ollama pull codellama

2-3. 설치된 모델 목록 확인: list

내 PC에 어떤 모델들이 설치되어 있는지 확인하고 싶다면 list 명령어를 사용하세요. 모델 이름, ID, 크기, 수정 시간 등의 정보를 한눈에 볼 수 있습니다.

ollama list

2-4. 모델 삭제: rm

더 이상 사용하지 않는 모델을 삭제하여 디스크 공간을 확보하려면 rm 명령어를 사용합니다.

ollama rm codellama
Ollama로 llama3 설치 및 대화
Ollama로 llama3 설치 및 대화

3. 나만의 AI 비서 만들기: Modelfile 커스터마이징

Ollama의 진정한 강력함은 모델을 내 입맛에 맞게 커스터마이징할 수 있다는 점에서 드러납니다. Docker 사용 경험이 있다면 Dockerfile과 매우 유사한 Modelfile을 통해 이 작업을 수행할 수 있습니다.

Modelfile은 기반이 될 모델을 지정하고, 시스템 프롬프트나 파라미터 등을 사전에 설정하여 새로운 커스텀 모델을 만드는 설계도입니다. 예를 들어, 파이썬 코드 리뷰만 전문적으로 수행하는 ‘리뷰어 봇’을 만들어 보겠습니다.

1단계: Modelfile 개념 이해

Modelfile을 ‘AI를 위한 맞춤 설정 레시피’ 또는 ‘AI 캐릭터 설정집’이라고 생각하면 완벽합니다.

  • 기존 방식: ollama run llama3를 실행하면, 우리는 매번 대화를 시작할 때마다 “너는 이제부터 친절한 개발자 비서야. 한국어로만 대답해.” 와 같은 지시사항을 반복해서 입력해야 합니다.
  • Modelfile 방식: 이 ‘캐릭터 설정집’ 파일 안에 “너의 기본 모델은 llama3이고, 너의 역할은 친절한 개발자 비서이며, 항상 한국어로만 대답해야 해” 라는 설정을 미리 저장해 둡니다. 그리고 이 설정집을 바탕으로 **나만의 AI 모델*을 새로 만드는 것입니다.

핵심 장점: 한번 만들어두면, 매번 긴 지시사항을 입력할 필요 없이, 내가 만든 AI를 불러내기만 하면 항상 똑같은 설정으로 작동합니다.

2단계: Modelfile 만들기 (실제 파일 생성)

이제 ‘레시피’를 담을 빈 파일을 만들어 보겠습니다.

  1. 프로젝트 폴더로 이동: 터미널에서 현재 작업 중인 프로젝트 폴더로 이동합니다.
  2. 빈 파일 생성: 아래 명령어를 터미널에 입력하여 Modelfile이라는 이름의 빈 파일을 만듭니다. (가장 중요: 확장자가 없습니다. Modelfile.txt가 아니라 그냥 Modelfile 입니다.)
    touch Modelfile

    (또는 VS Code와 같은 코드 에디터에서 직접 ‘새 파일 만들기’로 Modelfile을 생성해도 됩니다.)

Modelfile 실행화면
Modelfile 실행화면

3단계: Modelfile 안에 내용 작성하기

Modelfile이 있는 폴더 혹은 VS Code로 Modelfile을 열고, 그 안에 AI에게 내릴 지시사항을 적어줍니다. 가장 기본적이고 필수적인 3가지 명령어가 있습니다.

A. FROM (기반 모델 지정)

  • 의미: “어떤 기본 AI 모델을 커스텀할 것인가?”를 정합니다. 레시피의 가장 기본 재료와 같습니다.
  • 작성법: (이것은 ‘최신 버전의 llama3 모델을 기반으로 만들겠다’는 뜻입니다.)
    FROM llama3:latest

B. SYSTEM (역할 및 지시사항 부여)

  • 의미: AI에게 영구적으로 적용될 기본 지시사항이나 역할을 부여합니다. AI의 ‘성격’이나 ‘세계관’을 정해주는 것과 같습니다.
  • 작성법: (따옴표 세 개(""")를 사용하면 여러 줄의 긴 지시사항을 쓸 수 있어 편리합니다.)
    SYSTEM """
    You are a professional front-end developer assistant.
    Your primary role is to help users with React, TypeScript, and Git.
    Always provide answers in Korean.
    Provide clear, concise code examples when necessary.
    """

C. PARAMETER (세부 설정 조정)

  • 의미: AI의 행동을 미세하게 조정하는 ‘설정값’입니다. 예를 들어 AI의 ‘창의성’ 수치를 조절할 수 있습니다.
  • 작성법 (가장 많이 쓰는 temperature 예시):
    PARAMETER temperature 0.7
    • temperature (온도): AI의 답변이 얼마나 창의적이고 무작위적일지를 결정합니다.
      • 0에 가까울수록: 매우 사실적이고 결정론적인 답변을 합니다. (보고서 작성 등)
      • 1에 가까울수록: 매우 창의적이고 예측 불가능한 답변을 합니다. (소설 쓰기 등)
      • 보통 0.5 ~ 0.7 사이를 많이 사용합니다.
Modelfile 내 내용 입력 화면
Modelfile 내 내용 입력 화면

4단계: ‘나만의 AI’ 생성하기

이제 완성된 Modelfile을 저장 후 Ollama에게 주고, 새로운 모델을 만들어달라고 요청할 차례입니다.

  • 명령어:
    ollama create {my-assistant} -f ./Modelfile
  • 명령어 분석:
    • ollama create: “새로운 모델을 만들어줘!”
    • my-assistant: 내가 새로 만들 AI 모델의 이름입니다. (원하는 대로 지으면 됩니다.)
    • f ./Modelfilef는 file을 의미하며, “이 레시피(Modelfile)를 사용해서 만들어줘!” 라는 뜻입니다.

이 명령어를 실행하면, 터미널에 진행 상태가 표시되면서 새로운 모델이 생성됩니다.

터미널에서 Modelfile 실행 화면
터미널에서 Modelfile 실행 화면

5단계: ‘나만의 AI’ 사용하기 (모델 실행)

이제 모든 준비가 끝났습니다! 터미널에 아래 명령어를 입력해 보세요.

ollama run my-assistant

이제 나타나는 채팅창에서 AI에게 말을 걸면, Modelfile에 저장했던 모든 지시사항(개발자 비서 역할, 한국어 사용, 창의성 0.7 등)이 자동으로 적용된 상태로 대답할 것입니다. 더 이상 매번 긴 프롬프트를 입력할 필요가 없습니다.

Modelfile 적용 시 대화 화면
Modelfile 적용 시 대화 화면

이제 당신의 아이디어를 펼칠 시간

지금까지 Ollama를 통해 로컬 PC에 강력한 LLM을 설치하고, 터미널 명령어로 자유롭게 다루며, Modelfile로 나만의 AI를 만드는 첫걸음까지 내디뎠습니다.

Ollama는 데이터 프라이버시, 비용, 인터넷 제약으로부터 개발자를 해방시키는 강력한 도구입니다. 개인용 코드 조수부터 복잡한 자연어 처리 기능이 필요한 애플리케이션의 프로토타이핑까지, 이제 여러분의 손에는 상상하는 무엇이든 만들어볼 수 있는 강력한 ‘엔진’이 쥐어졌습니다.

물론 오늘 다룬 내용은 로컬 LLM의 무한한 가능성을 향한 시작점일 뿐입니다. 이 강력한 엔진을 활용해 실제 프로덕션 수준의 시스템을 구축하는 여정에는 더 많은 기술적 과제들이 기다리고 있을 것입니다.

이제 여러분의 아이디어를 로컬 LLM 위에서 마음껏 펼쳐보세요.

Happy Hacking!

[출처] https://peekaboolabs.ai/blog/ollama-installation-guide

Loading

1 12월 2025

[인공지능 기술] AI 스타트업 200곳을 역공학해 보니, 73%가 단순한 프롬프트 엔지니어링에 불과

[인공지능 기술] AI 스타트업 200곳을 역공학해 보니, 73%가 단순한 프롬프트 엔지니어링에 불과 

15P by GN⁺ 6일전 | ★ favorite | 댓글 4개
  • 200개의 AI 스타트업을 리버스 엔지니어링한 결과, 다수의 기업이 자체 기술을 보유했다고 주장하면서 실제로는 외부 API를 호출하는 형태로 운영됨
  • 조사된 기업 중 73%가 OpenAI나 Claude API를 그대로 사용하며, 여기에 단순한 UI나 기능을 덧붙인 수준으로 확인됨
  • 자사 “고유 LLM” 을 내세우는 스타트업 상당수가 실제로는 api.openai.com에 요청을 보내는 GPT-4 래퍼에 불과했고, 단순 시스템 프롬프트만 얹은 구조로 수십~수백 배 마진을 붙여 판매하고 있음
  • RAG 아키텍처를 강조하는 서비스 대부분도 OpenAI text-embedding-ada-002 · Pinecone/Weaviate · GPT-4를 조합한 표준 40줄짜리 스택을 “고유 인프라”로 포장하고 있었으며, 1M 쿼리 기준 월 약 3만 달러 비용에 15만~50만 달러 매출로 80~94% 마진 구조를 보이는 상황
  • 반대로 전체의 27% 는 “Built on GPT-4”처럼 스택을 투명하게 밝히는 래퍼 회사, 실제로 자체 모델을 학습하는 빌더, 멀티모델 투표·에이전트 프레임워크 등 실제 기술적 차별점을 가진 팀들로 구성됨
  • 조사 결과, 많은 AI 스타트업이 API 기반 서비스 비즈니스임에도 “고유 AI 인프라”를 내세우는 구조가 드러났고, 투자자·고객·개발자 모두가 DevTools로 네트워크 탭만 열어도 검증 가능하다는 점을 강조하며 AI 생태계에 정직한 기술 공개가 필요하다는 걸 강조

개요

  • 외부 투자를 받은 AI 스타트업 200곳의 웹 애플리케이션을 대상으로, 네트워크 트래픽·코드·API 호출을 추적해 마케팅 주장과 실제 기술 스택의 차이를 분석함
    • 출발점은 “고유 딥러닝 인프라”를 주장하는 한 회사가 실제로는 OpenAI API만 콜하고 있다는 의심에서 시작
    • 이 회사는 4.3M 달러 투자를 받았고, “근본적으로 다른 인프라를 구축했다”는 스토리로 자금 조달을 진행한 상태였음
  • 조사 결과 73% 회사에서 주장하는 기술과 실제 구현 간에 의미 있는 괴리가 발견되었고, 상당수가 서드파티 모델 API를 단순 래핑한 구조였음
    • 조사 대상은 YC·Product Hunt·LinkedIn “We’re hiring” 포스트 등에서 수집한 AI 스타트업 200곳이며, 설립 6개월 미만 회사는 제외했고 외부 자금 유치와 구체적 기술 주장이 있는 곳에 집중함
    • 조사 방식은 패시브한 브라우저 개발자 도구 수준에서 이뤄졌으며, 비공개 시스템 접근·인증 우회·TOS 위반 없이 진행되었음

조사 방법(Methodology)

  • Playwright·aiohttp 등을 이용해 자동화된 분석 파이프라인을 구성하고, 각 스타트업 사이트에 대해 공통적으로 세 가지를 수집함
    • capture_network_traffic(url)로 네트워크 헤더와 요청 패턴을 캡처
    • extract_javascript(url)로 JS 번들 디컴파일 및 분석
    • monitor_requests(url, duration=60)으로 60초 간 API 호출 패턴을 추적
  • 각 사이트별로 다음 정보를 구조화해 기록함
    • claimed_tech: 마케팅 카피·웹 문구에 나타난 기술 주장
    • actual_tech: HTTP 헤더·JS 번들·API 호출로 확인한 실제 스택
    • api_fingerprints: 호출 도메인·헤더·지연 시간 등으로 추출한 서드파티 API 지문
  • 크롤링 기간은 3주였으며, 모든 패턴은 공개 웹·브라우저 DevTools로 관찰 가능한 공개 데이터만을 활용했음

주요 결과: 73%에서 드러난 괴리

  • 전체 200곳 중 73% 회사에서 마케팅 카피에 적힌 “고유 모델·커스텀 인프라·딥러닝 플랫폼” 등의 주장과, 실제로 동작하는 코드·API 스택 사이에 큰 차이가 확인됨
    • 이 비율은 “고유 LLM”을 내세우지만 OpenAI/Anthropic/Cohere API만 사용하는 회사, “자체 벡터 DB”를 주장하지만 Pinecone/Weaviate를 쓰는 회사 등을 모두 포함한 수치임
  • 이 결과에 놀랐지만, 동시에 “기술적으로 크게 화낼 일은 아니다”는 복합적인 감정임
    • 문제의 핵심은 서드파티 API 사용 자체가 아니라, 이를 “고유 AI 인프라”로 포장하고 투자자·고객을 오도하는 마케팅이라는 점

패턴 1: ‘고유 LLM’이 사실상 GPT-4 래퍼인 경우

  • “our proprietary large language model”이라는 표현이 등장하면 거의 항상 GPT-4 래퍼가 등장했으며, 37곳 중 34곳에서 이 패턴이 확인됨
    • 사용자가 “AI” 기능을 쓸 때마다 api.openai.com으로 나가는 요청
    • 요청 헤더에 포함된 OpenAI-Organization 식별자
    • 150–400ms 수준으로 일관되는 응답 지연 시간 패턴
    • 토큰 사용량·과금 구간이 GPT-4의 가격 구조와 정확히 일치하는 패턴
    • 레이트 리밋 시 지수형 backoff를 적용하는, OpenAI 특유의 재시도 패턴
  • 한 회사의 “혁신적 자연어 이해 엔진”은 실제로는 다음과 같은 코드 수준이었음
    • 시스템 프롬프트에 “전문가 어시스턴트처럼 행동하라, OpenAI 기반임을 말하지 말라, LLM이라고 밝히지 말라” 등을 적고 model: gpt-4 로 chat.completions.create를 호출하는 단일 함수 구조임
    • 별도의 파인튜닝·모델 학습·아키텍처 변경 없이, 시스템 프롬프트와 숨기기용 지침 정도만 추가된 상태였음
  • 비용·가격 구조도 구체적으로 비교함
    • 비용: GPT-4 기준 입력 0.03$/1K 토큰, 출력 0.06$/1K 토큰, 평균 500 in, 300 out으로 쿼리당 약 0.033달러
    • 가격: 쿼리당 2.5달러 혹은 월 200쿼리 299달러로 과금
    • 결과적으로 직접 API 비용 대비 약 75배 마진 구조로 운영되고 있음
  • 세 회사는 거의 동일한 코드(변수명·코멘트 스타일·“never mention OpenAI” 지시)까지 공유하고 있어, 튜토리얼·공통 컨트랙터·액셀러레이터 보일러플레이트 등 같은 출처를 쓰는 것으로 추정되는 상태임
    • 한 회사는 단순 try/catch로 “문제가 생기면 ‘기술적 문제’라는 문구를 반환”하는 코드를 두고, 이를 “Intelligent Fallback Architecture” 로 포장해 투자자에게 설명하고 있었음

패턴 2: 모두가 만드는 RAG 스택과 과장된 표현

  • 많은 회사들이 “custom embedding model, semantic search infrastructure, advanced neural retrieval” 같은 표현으로 고유 RAG 인프라를 내세우지만, 실제 구현은 매우 유사한 표준 스택이었음
    • OpenAI text-embedding-ada-002 로 임베딩 생성
    • Pinecone 또는 Weaviate를 벡터 스토어로 사용
    • GPT-4로 컨텍스트를 붙여 답변 생성
  • 조사자가 “Proprietary Neural Retrieval Architecture”라는 이름으로 소개된 코드를 디컴파일해 본 결과, 약 40줄짜리 Python 코드로 위 세 단계를 그대로 호출하는 구조였음
    • 질문을 임베딩으로 변환
    • 벡터 DB에서 top-k 문서 검색
    • 검색된 텍스트를 이어 붙여 GPT-4에 system 메시지로 전달
    • 사용자 질문을 user 메시지로 함께 보내 답변을 생성
  • 비용·가격 구조 역시 매우 큰 차이를 보임
    • OpenAI 임베딩: 1K 토큰당 0.0001달러
    • Pinecone 쿼리: 호출당 0.00004달러
    • GPT-4 completion: 1K 토큰당 0.03달러
    • 합산 시 쿼리당 약 0.002달러 수준 비용
    • 실제 고객 과금은 쿼리당 0.5~2달러로, API 비용 대비 250~1000배 마진이 발생하는 구조임
  • 42개 회사가 이와 거의 동일한 스택과 코드 구조를 사용했고, 추가 23개 회사는 90% 이상 비슷한 패턴을 공유함
    • 차이점은 주로 Pinecone vs Weaviate 선택 여부, 변수명, Redis 캐시 추가 여부 정도였음
    • Redis 캐시를 붙이고 이를 “optimization engine”, 재시도 로직을 붙이고 이를 “Intelligent Failure Recovery System” 같은 이름으로 마케팅하는 사례도 등장
  • 월 100만 쿼리 수준의 스타트업 경제성도 계산해봄
    • 비용: 임베딩 약 100달러, Pinecone 호스팅 약 40달러, GPT-4 completion 약 3만 달러, 총 약 3만140달러/월
    • 매출: 15만~50만 달러/월
    • 80~94% 수준의 높은 매출 총이익률을 갖는 비즈니스 구조

패턴 3: ‘우리가 직접 파인튜닝했다’의 실제 의미

  • “우리가 직접 모델을 파인튜닝했다”는 표현을 쓰는 회사들에 대해 인프라를 추적한 결과, 크게 두 부류로 나뉨
    • 소수(약 7%)는 실제로 AWS SageMaker, Google Vertex AI 등을 통해 자체 학습 잡을 돌리고, S3 버킷에 모델 아티팩트를 저장한 뒤, 별도 인퍼런스 엔드포인트와 GPU 인스턴스 모니터링을 운영하고 있는 경우임
    • 다수는 OpenAI의 fine-tuning API를 사용하고 있었고, 사실상 “OpenAI에 예시 데이터와 프롬프트를 넘겨 저장하는 수준”에 가까운 구조였음
  • 전자(실제 자체 학습)는 학습 인프라와 배포 파이프라인이 브라우저에서 관찰되는 수준으로도 어느 정도 드러나지만, 후자는 대부분 단일 OpenAI 엔드포인트 호출로 표현되는 차이가 있음

래퍼 회사를 빠르게 구분하는 방법

  • 네트워크 트래픽 패턴

    • 브라우저에서 DevTools(F12) → Network 탭을 열고, 서비스의 AI 기능을 사용하는 동안 나가는 요청을 보면 간단한 구분이 가능
      • api.openai.com
      • api.anthropic.com
      • api.cohere.ai
      • 등과 같은 도메인이 직접 등장하면, 기본적으로 서드파티 모델 API 래퍼로 볼 수 있음
    • 응답 지연 시간도 지문 역할을 함
      • 특히 OpenAI API의 경우 200~350ms 구간에 응답이 몰리는 특유의 레이턴시 패턴이 있어, 이를 통해 백엔드 모델을 추정할 수 있음
  • 자바스크립트 번들과 키 노출

    • 페이지 소스 및 JS 번들 검색에서 다음 키워드를 찾아보는 것도 간단한 방법
      • openaianthropicclaudecoheresk-proj-(OpenAI 프로젝트 키 프리픽스) 등
    • 조사 과정에서 12개 회사가 API 키를 프런트엔드 코드에 그대로 포함한 채 배포하고 있었고, 이에 대해 제보 메일을 보냈지만 어떤 회사도 답하지 않았음
  • 마케팅 언어 매트릭스

    • 마케팅 카피에 나타나는 언어와 실제 기술 구현 간의 패턴을 표 형태로 정리해 “Marketing Language Matrix”라고 표현
      • “GPU 인스턴스 유형, 서빙 아키텍처, 모델 크기” 등 구체적인 기술 용어가 등장하는 경우, 실제로 어느 정도 독자적인 인프라를 갖고 있을 가능성이 더 높았음
      • 반대로 “advanced AI”, “next-gen intelligence”, “proprietary neural engine”처럼 추상적 버즈워드만 반복될수록, 내부는 서드파티 API 래퍼일 가능성이 높았음

인프라 현실 지도와 AI 스타트업 지형

  • 글에서는 여러 다이어그램을 통해 현재 AI 스타트업의 인프라 현실 지도를 정리함
    • 다수의 스타트업이 OpenAI·Anthropic·Cohere 등 모델 제공자 위에 얇은 애플리케이션 레이어를 얹은 형태로 존재하는 구조
    • 각 레이어 위에 “워크플로우·UX·도메인 데이터·파이프라인” 등에서 차별화를 시도하는 서비스들이 쌓여 있는 구조임
  • 이러한 구조를 바탕으로, AI 스타트업의 상당 부분이 실질적으로는 서비스/플랫폼 비즈니스이며, “고유 AI 인프라 기업”이라는 자기 인식과 괴리가 있는 상태

왜 이 문제를 신경 써야 하는가

  • “잘 동작한다면 상관없지 않냐”는 질문에 대해, 조사자는 네 가지 이해관계자 관점에서 이유를 정리함
    • 투자자: 현재 상당수 회사에 투자되는 자금은 AI 연구·모델 개발이 아니라, 실질적으로는 프롬프트 엔지니어링과 워크플로우 레이어에 투입되고 있음
    • 고객: 실제 API 비용에 10배 이상 프리미엄을 얹은 가격을 내고 있으며, 비슷한 기능을 주말 프로젝트 수준으로 직접 구현할 수 있는 경우가 많음
    • 개발자: 겉으로 보이는 “AI 스타트업”의 화려함에 비해, 실제로는 낮은 진입 장벽의 래퍼 서비스인 경우가 많아, 스스로도 비슷한 것을 단기간에 만들 수 있음을 인식할 필요가 있음
    • 생태계: “AI 회사”의 73%가 기술을 과장·오도하는 상황은, 전체적으로 버블에 가까운 상태를 의미하며 건강하지 않은 인센티브를 만듦

래퍼 스펙트럼: 모든 래퍼가 나쁜 것은 아님

  • “Wrapper Spectrum”이라는 도표를 통해, 래퍼 회사에도 질적으로 다른 층위가 있음을 설명함
    • 한쪽 끝에는 단순히 서드파티 API에 얇은 UI만 입힌 수준의 래퍼가 있음
    • 다른 한쪽 끝에는 도메인 특화 워크플로우·우수한 UX·모델 오케스트레이션·가치 있는 데이터 파이프라인 등을 제공하는 고급 래퍼가 있음
  • 핵심 메시지는 “래퍼인지 여부”가 아니라 정직성·가치 제공 방식에 있음
    • 서드파티 API를 쓰면서도 이를 투명하게 공개하고, 문제 해결·경험·데이터에서 차별화를 만드는 회사는 긍정적으로 평가됨

제대로 하고 있는 27%

  • Category 1: 투명한 래퍼(Transparent Wrappers)

    • 이 그룹의 회사들은 홈페이지에 “Built on GPT-4” 같은 문구를 명시적으로 적고, 자신들이 판매하는 것은 워크플로우·UX·도메인 지식이라는 점을 분명히 함
      • 예: GPT-4 + 법률 템플릿 조합으로 법률 문서 자동화를 제공하는 서비스
      • 예: Claude 기반으로 고객 지원 티켓 라우팅에 특화한 서비스
      • 예: 여러 모델과 휴먼 리뷰 프로세스를 결합한 콘텐츠 워크플로우 서비스
  • Category 2: 실제 빌더(Real Builders)

    • 이 그룹은 실제로 자체 모델을 학습하고 있는 회사들임
      • 의료 분야에서 HIPAA 준수를 위해 셀프 호스팅 모델을 운영하는 헬스케어 AI
      • 금융 분석에 커스텀 리스크 모델을 학습·운영하는 서비스
      • 산업 자동화에서 특수한 컴퓨터 비전 모델을 개발·배포하는 서비스
  • Category 3: 혁신적 조합(Innovators)

    • 여기에는 서드파티 모델을 사용하지만, 그 위에 실질적으로 새로운 구조를 쌓은 회사들이 포함됨
      • 여러 모델의 출력을 조합해 투표 기반 정확도 향상을 구현한 시스템
      • 메모리·에이전트 프레임워크를 만들어 복잡한 태스크를 수행하는 시스템
      • 새로운 형태의 리트리벌 아키텍처를 도입한 사례 등
    • 이들 회사는 자신들의 아키텍처를 자세히 설명할 수 있으며, 실제로 스스로 구축한 구조를 가지고 있다는 공통점이 있음

배운 점: 스택보다 문제, 그리고 정직성

  • 3주간의 조사 결과, 다음과 같이 요약 가능
    • 기술 스택 자체보다 해결하려는 문제가 더 중요하며, 실제로 가장 뛰어난 제품들 중 상당수는 “단지 래퍼”라고 부를 수 있는 구조였음
    • 다만, 정직함은 별도의 차원으로 중요하고, 스마트한 래퍼와 사기성 래퍼의 차이는 투명성에 있음
    • AI 골드러시는 “고유 AI”를 요구하는 투자자·고객의 기대 때문에 거짓된 주장을 하도록 압박하는 인센티브를 만들고 있음
    • 그리고 API 위에서 구축하는 것 자체는 부끄러운 일이 아니며, 문제는 이를 숨기고 “고유 신경망 아키텍처”로 포장하는 행위임

평가 프레임워크와 실질적 조언

  • 48시간 복제 가능성 테스트

    • 모든 “AI 스타트업”을 평가하는 간단한 기준을 제안함
      • “그들의 핵심 기술을 48시간 안에 복제할 수 있는가?”
      • 그럴 수 있다면, 기술적으로는 래퍼에 해당하며,
        • 스택을 솔직하게 밝힌다면 괜찮은 회사
        • “고유 AI 인프라”를 주장하며 숨긴다면 피해야 할 회사로 봐야 한다는 구조임
  • 창업자를 위한 조언

    • 창업자에게는 다음과 같은 원칙을 제안함
      • 스택에 대해 정직하게 공개할 것
      • UX·데이터·도메인 전문성으로 경쟁할 것
      • 만들지 않은 것을 만들었다고 주장하지 않을 것
      • “Built with GPT-4”는 약점이 아니라 정직한 설명이라는 점을 받아들일 것
  • 투자자를 위한 조언

    • 투자자에게는 다음과 같은 검증 포인트를 제시함
      • 아키텍처 다이어그램을 요구할 것
      • OpenAI·Anthropic 등 API 청구서를 요청해 실제 의존도를 확인할 것
      • 래퍼 회사는 래퍼 회사로서 적절히 가치평가할 것
      • 정직하게 스택을 공개하는 팀을 인센티브로 보상할 것
  • 고객을 위한 조언

    • 고객에게는 아래와 같은 실천 항목을 제안함
      • 브라우저에서 네트워크 탭을 열고 나가는 요청을 확인할 것
      • 인프라와 모델 사용 방식에 대해 직접 질문할 것
      • API 호출에 불필요한 10배 이상의 마크업을 내고 있지 않은지 검토할 것
      • 기술 주장보다 실제 결과와 문제 해결 능력 기준으로 평가할 것

‘AI 스타트업’의 실체 한 줄 요약

  • “대부분의 ‘AI 스타트업’은 직원 비용 대신 API 비용을 쓰는 서비스 비즈니스에 가깝다”
    • 이는 잘못된 비즈니스 모델이 아니라, 그 자체로 인정하고 정직하게 설명해야 할 현실

조사 이후 전개와 반응

  • 1주 차: 원래는 20~30% 정도가 서드파티 API를 사용할 것이라고 예상했으나, 결과가 훨씬 컸음을 언급함
  • 2주 차: 한 창업자는 조사자에게 “어떻게 우리 프로덕션 환경에 들어왔냐”고 물었고, 조사자는 브라우저 네트워크 탭만 본 것이라고 설명함
  • 3주 차: 두 회사는 조사 결과를 내려달라고 요청했지만, 기사에서는 특정 회사 이름을 공개하지 않았고 지금도 그 상태를 유지 중이라고 밝힘
  • 어제: 한 VC가 다음 이사회 전에 포트폴리오 회사들을 감사(audit) 해 달라고 요청했고, 조사자는 이를 수락했다고 언급함

데이터·도구 공개 계획

  • 이번 연구를 바탕으로 방법론과 도구를 공개할 계획임
  • GitHub에 공개 예정인 내용(무료)

    • 완전한 스크래핑 인프라 코드
    • API 지문(fingerprint)을 추출하는 기법들
    • 누구나 실행해볼 수 있는 감지 스크립트
    • 주요 AI API별 응답 시간 패턴 모음
  • 심화 분석(멤버 전용)

    • 월 3,300만 달러 가치평가를 받은 “AI 유니콘” 이 실제로는 월 1,200달러 OpenAI 비용만 쓰고 있는 케이스
    • “1억 파라미터 모델”이라고 소개하면서 실제로는 시스템 프롬프트 3개로 구성된 구조
    • 공개적으로 서빙되는 프로덕션 코드(클라이언트 측, 익명화된 스니펫)
    • 래퍼를 즉시 드러내는 5가지 질문 프레임워크
    • 투자자 프레젠테이션과 실제 인프라를 비교한 사례 연구

마지막 메시지와 ‘정직한 AI 시대’ 필요성

  • 조사는 회사 이름을 공개하지 않고 패턴만 공유하는 방식으로 진행되었으며, 시장은 결국 투명성을 보상할 것이라는 믿음을 강조함
  • 실제로 18개 회사는 진정한 의미에서 새로운 기술을 만들고 있는 것이 확인되었고,
    • 이들에 대해서는 “당신들은 스스로 누구인지 알고 있다, 계속 만들라” 는 응원의 메시지를 보냄
  • 조사 이후 7명의 창업자가 개인적으로 연락을 취했으며,
    • 일부는 방어적이었고, 일부는 감사해했고, 세 명은 “proprietary AI”에서 “best-in-class APIs 위에 구축”으로 마케팅 전환을 돕는 방법을 요청함
    • 한 창업자는 “우리가 거짓말한다는 걸 알고 있었다, 투자자들이 그걸 기대했고, 다들 그러고 있다, 이제 어떻게 멈춰야 하느냐”라고 털어놓았다고 전함
  • 기사 말미에서, AI 골드러시는 끝나지 않겠지만 정직의 시대가 시작돼야 한다는 메시지를 재차 강조하며, 누구나 DevTools의 Network 탭(F12) 만 열어보면 스스로 진실을 확인할 수 있다고 정리

[출처] https://news.hada.io/topic?id=24586&utm_source=weekly&utm_medium=email&utm_campaign=202548

Loading

30 11월 2025

[인공지능 서비스 보안] 탈옥 공격으로부터 LLM을 보호하는 방법 , How to Protect LLMs from Jailbreaking Attacks

[인공지능 서비스 보안] 탈옥 공격으로부터 LLM을 보호하는 방법 , How to Protect LLMs from Jailbreaking Attacks

탈옥 공격으로부터 LLM을 보호하는 방법

노아 플라이슈만, 에이미 와고너 박사, 앙드레 응우옌 박사

Loading

29 11월 2025

[사회과학] [박진영의 사회심리학] 외로움을 줄이는 작은 용기

[사회과학] [박진영의 사회심리학] 외로움을 줄이는 작은 용기

[박진영의 사회심리학] 외로움을 줄이는 작은 용기

입력
게티이미지뱅크 제공

게티이미지뱅크 제공

외로움이 하루에 담배를 15개비 피는 것만큼 해롭다는 이야기가 나올 만큼 외로움이 행복과 건강(심혈관 질환, 뇌졸중, 치매, 수명 등)에 미치는 악영향은 널리 알려져 있다. 문제는 어떻게 하면 외로움을 줄일 수 있느냐다.

데이지 브랜드 조지아대 연구자 등은 콘서트, 피트니스 클래스, 워크숍 등 다양한 모임과 이벤트에 참여한 사람들을 대상으로 모임의 어떤 특성들이 모임 전에 비해 모임 이후 사람들의 외로움을 줄여주고 다른 사람들과 연결되었다는 느낌을 주는지에 대해 살펴보았다.

그 결과 우선 온라인보다는 오프라인 이벤트에 참여하는 것이, 또 수동적이기보다 능동적으로 참여하는 것이(가만히 있기보다 다른 사람들과 이야기를 나누는 등) 사람들과 연결되어 있다는 느낌을 더 많이 주는 것으로 나타났다. 특히 모임에서 주변 사람들과 능동적으로 교류하려고 애쓰는지 여부가 외향성보다도 더 사회적 연결감을 잘 설명하는 것으로 나타났다.

그 외에도 이벤트에 혼자 참여하기보다는 다른 사람들과 함께 참여하는 것, 일회성보다는 다회성 이벤트에 반복해서 참여하는 것이 외로움 감소와 관련을 보였다.

무엇보다 사람들과 적극적으로 이야기를 나누고 공통점을 발견하는 능동적인 과정들이 사회적 연결감은 높이고 외로움을 줄이는 것으로 보인다는 데에서 결국 외로움을 줄이는 데에 간편한 방법은 없고 ‘시간’과 서로를 알아가려는 ‘노력’이 가장 중요함을 재차 확인한 듯 보인다.

그도 그럴 것이 외로움은 심심함이나 쓸쓸함과는 달리 간단한 자극으로 쉽게 해소되지 않는 ‘깊은 유대감’에 대한 배고픔이다. 예를 들어 외로움과 큰 관련을 보이는 지표들은 인간관계의 ‘양’이 아니라 ‘질’이다. 친구가 백 명, 천 명 있어도 그중에 단 한 명이라도 마음을 나누고 의지할 수 있는 사람이 없다면 외로움을 느끼는 반면 친구가 많지 않더라도 진짜 마음을 터놓고 의지할 사람이 한두 명 있으면 외롭지 않을 수 있다.

그렇다 보니 외로움을 해소하는 데 피상적인 교류보다 시간과 노력이 많이 들어가는 능동적인 교류 방식이 효과적이라는 것은 당연한 발견인 것 같기도 하다. 누군가를 알아가고 마음 깊이 통한다는 사실을 확인하는 데까지는 많은 시간과 노력이 필요하기 때문이다.

물론 수동적으로 많은 시간을 함께 보낸다고 해서 서로를 더 잘 알게 되는 것도 아니다. 평생을 부대껴온 가족이라고 해서 서로의 생각과 마음을 속속들이 아는 ‘가까운 사이’인 것은 아닌 것처럼 옆에 있어도 능동적으로 대화하고 다가가는 시도들을 하지 않으면 가깝고도 먼 사이로 남을 수밖에 없다. 중요한 것은 조금이라도 더 다가가려고 하고 조금이라도 더 마음을 나누려고 하는 시도일 것이다.

물론 만나는 모든 사람들과 깊은 관계가 되는 것은 불가능하고 만약 가능하다고 해도 꼭 가까워져야 하는 것은 아니다. 하지만 지금 외롭다면 적어도 깊은 관계에 대한 허기를 느끼고 있음을 인식하는 것은 좋을 것 같다. 내 마음이 깊은 관계를 갈망하고 있다는 것을 알면 적어도 놓치면 후회할 것 같은 사람들이 있을 때 조금 더 다가가려는 노력을 하게 될지도 모르니까.

Brand, D. R., Proctor, A. S., Harvey, M. W., Abney, D. H., Slatcher, R. B., & Holt-Lunstad, J. (2025). Actively participating in live events as an avenue for social connection. Social Psychological and Personality Science. Advance online publication. https://doi.org/10.1177/19485506251360041

※필자소개
박진영 《나, 지금 이대로 괜찮은 사람》, 《나를 사랑하지 않는 나에게》를 썼다. 삶에 도움이 되는 심리학 연구를 알기 쉽고 공감 가도록 풀어낸 책을 통해 독자와 꾸준히 소통하고 있다. 온라인에서 ‘지뇽뇽’이라는 필명으로 활동하고 있다. 현재 미국 듀크대에서 사회심리학 박사 과정을 밟고 있다.

[출처] https://n.news.naver.com/article/584/0000035522?sid=110

Loading

28 11월 2025

[인공지능 기술] “LLM 버블 내년 붕괴…범용거대모델 아닌 버티컬 AI 뜰 것”

[인공지능 기술] “LLM 버블 내년 붕괴…범용거대모델 아닌 버티컬 AI 뜰 것”

“LLM 버블 내년 붕괴…범용거대모델 아닌 버티컬 AI 뜰 것”

김민석 기자2025. 11. 25. 15:59
 
오픈소스 AI 1위 플랫폼 CEO “거대범용 AI 집착 비효율적”
최상위 모델 독식 우려도…”오픈AI·앤트로픽 최대주주 MS·구글”

제미나이 모델 이미지 생성 요청 이미지

(서울=뉴스1) 김민석 기자

“인공지능(AI) 버블이 아닌 LLM 버블이 내년 붕괴할 수 있습니다.”

26일 IT 업계에 따르면 세계 최대 AI 오픈소스 플랫폼 허깅페이스의 클렘 델랑그 CEO가 “범용 거대 모델에 자금과 관심이 지나치게 집중돼 비효율적인 상황”이라며 이같이 말했다.

델랑그는 18일(현지시간) Axios BFD 서밋에서 “범용 거대 모델로 모든 기업·사람의 문제를 해결할 수 있다는 아이디어에 관심과 자금이 모두 집중돼 있다”며 “현실에선 막대한 연산 자원을 투입한 하나의 모델이 아닌 분야별 특화 모델이 문제를 해결하게 될 것”이라고 지적했다.​

이어 “지금 많은 사람들이 서둘러(또는 심지어 패닉에 빠져) 아주 단기적인 접근을 하고 있다고 생각한다”며 “AI 업계에 15년 종사하면서 이런 사이클들을 봐왔다”고 했다.

델랑그가 강조한 버티컬 AI(의료·법률·금융 등 특정 산업에 특화한 AI) 성장 추세는 시장조시기관의 분석 보고서에서도 확인된다. 글로벌마켓인사이츠에 따르면 버티컬 AI(의료·법률·금융 등 특정 산업에 특화한 AI) 시장 규모는 2024년부터 2034년까지 연평균 21.6% 성장할 것으로 전망했다.

베세머벤처파트너스는 버티컬 AI 시장 규모가 기존 버티컬 SaaS의 최소 10배에 달할 것으로 내다봤다. 버티컬 AI 스타트업 경우 기존 SaaS 시스템 연간계약가치(ACV)의 약 80%에 달하는 금액을 받으며 연 400% 성장하고 있다고 분석했다.

델랑그는 이를 토대로 LLM 버블이 붕괴하더라도 허깅페이스는 건재할 것으로 자신했다.

그는 “AI 산업은 충분히 다각화돼 있어 LLM 같은 일부 영역이 과대평가됐더라도 전체 AI 분야나 우리 회사에 큰 영향을 미치진 않을 것”이라고 했다.

퍼플렉시티 AI 이미지 생성 요청 이미지

반면 미래 소프트웨어 비즈니스는 독립 앱·플랫폼이 아닌 AI 에이전트에 탑재되는 형태의 버티컬 AI 구조로 재편될 것이란 전망도 나온다.

앞서 사티아 나델라 MS CEO 등을 비롯한 IT 기술 리더들은 AI 에이전트 기술아 고도화할수록 기존 독립 플랫폼·앱 체제는 점차 붕괴할 것으로 예상했다.

반면 AI 소프트웨어 기업들은 버티컬 AI와 기존 SaaS 체제가 공존할 것으로 전망하고 있어 논쟁이 현재 진행형이다.

이와 관련 베인앤컴퍼니는 “파괴는 필수지만 파괴 대상일지 아닐지는 상황에 따라 다를 것”이라며 “AI 에이전트가 기존 시장의 영역을 통합하는 측면이 있지만, 일부는 별도 상품화가 지속되고 기존 빅테크에게 유리한 때도, 스타트업에 유리할 때도 있을 것”이라고 했다.

오픈AI는 AI 에이전트 서비스에 적합한 단말기를 직접 개발하고 있다. 올해 3월엔 AI 에이전트 전용 소프트웨어 개발 플랫폼 ‘리스폰스 API’를 출시했다. 리스폰스 API는 기존 ‘어시스턴트 API’를 내년 8월 26일까지 순차적으로 대체할 예정이다.

스타트업 CEO인 자인 재퍼는 “버티컬 AI 시장을 겨냥한 우리 모두 오픈AI·앤트로픽·MS·구글이 만들어 놓은 플랫폼 위에서 모델을 구축하고 있다”며 우려했다.

타임지는 “오픈AI 최대 투자자는 MS, 앤트로픽의 최대주주는 아마존과 구글”이라며 “빅테크 기업들이 AI 인프라부터 앱까지 수직 통합을 추구하고 있다”고 했다.

ideaed@news1.kr

<용어설명>

■ LLM
Large Language Model. 대규모 언어 모델. 자연어 처리(NLP) 작업을 수행할 수 있는 머신 러닝 모델을 말한다. 자연어의 복잡성을 이해할 수 있어 기존 기계 학습 알고리즘보다 정확하다.

■ SaaS
SaaS(서비스형 소프트웨어·Software as a Service)는 소프트웨어를 인터넷 서비스 형태로 제공하는 클라우드 기반 소프트웨어 모델이다. 이용자는 별도 프로그램 설치 또는 서버 구축 없이 웹 브라우저로 소프트웨어를 활용할 수 있다.

■ 리스폰스 API
리스폰스 API(Responses API)는 오픈AI가 2025년 3월 11일 출시한 AI 에이전트 구축을 위한 새로운 API 인터페이스입니다. Chat Completions API의 진화 버전으로 에이전트 애플리케이션 개발에 특화됐다.

[출처] https://v.daum.net/v/20251125155911706

 
 
 
 
 

Loading