SOFT GROUND Blog
블로그 목록
SW 개발 연대기

2023년 개발 연대기: 생성형 AI가 도구를 호출하고 동시성은 가벼워지다

GPT-4, function calling, Llama 2, Java 21과 virtual thread, passkey 확산, 국내 지방행정전산서비스 장애로 2023년의 개발 흐름을 살펴봅니다.

2026년 7월 24일약 16분
#2023#GPT-4#Function Calling#Llama 2#Java 21#Virtual Threads#Passkey#행정전산망#개발 연대기

2023년에는 생성형 AI가 문장을 만들어 주는 대화 상대에서 application의 일부로 빠르게 이동했다. GPT-4는 image와 text input을 받는 multimodal model로 공개됐고, function calling은 model이 외부 API에 전달할 structured argument를 생성하도록 했다. Llama 2는 내려받을 수 있는 weight와 상업 이용 license를 제공해 자체 infrastructure에서 language model을 실행하려는 생태계를 넓혔다.

기존 platform도 오랜 문제를 새 방식으로 풀었다. Java 21은 virtual thread를 정식 기능으로 제공해 thread-per-request code의 이해하기 쉬운 구조를 유지하면서 많은 동시 작업을 처리할 길을 열었다. Apple·Google과 주요 service는 passkey 지원을 확대하며 password와 phishing에 의존하는 인증을 기기 기반 공개 키 방식으로 옮기기 시작했다.

국내에서는 11월 지방행정전산서비스 장애로 지방자치단체 민원 업무와 정부24가 영향을 받았다. 초기에는 L4 switch의 OS update가 의심됐지만 최종 조사에서는 router module의 port 불량에 따른 packet loss가 원인으로 발표됐다. 장애의 첫 설명과 검증된 원인을 구분해 기록해야 하는 사례였다.

2023년을 보여주는 장면

분야주요 변화개발자에게 생긴 의미
생성형 AIGPT-4 공개text와 image input을 다루는 더 강력한 model을 API와 ChatGPT에서 사용
AI applicationfunction calling자연어 의도를 JSON argument로 바꾸고 외부 tool과 연결
공개 weight AILlama 2 공개cloud API 외에 자체 hosting·fine-tuning 선택지가 확대
JavaJava 21 LTS·virtual threadblocking code 구조로 많은 I/O 동시 작업을 처리
인증passkey 확산site별 공개 키 자격 증명으로 password와 phishing 위험을 축소
국내 행정지방행정전산서비스 장애부분 고장 탐지, network observability와 원인 검증 절차의 중요성 부각

GPT-4, 더 강력한 model과 더 엄격해진 평가 과제

OpenAI는 3월 14일 GPT-4를 공개했다. text와 image를 input으로 받고 text를 output으로 내는 large multimodal model이었다. 공개 시점에는 ChatGPT Plus와 API waitlist를 통해 text 기능을 제공했고 image input은 제한적으로 시험됐다. 따라서 모든 이용자가 그날부터 image API를 사용했다고 쓰면 정확하지 않다.

OpenAI는 모의 변호사 시험 등 여러 benchmark에서 GPT-3.5보다 높은 결과를 제시했다. 그러나 system card는 hallucination, harmful advice, bias와 jailbreak 가능성이 여전히 남아 있다고 설명했다. benchmark 점수가 실제 product의 정확성과 안전성을 그대로 보장하지 않았다.

개발팀에는 model evaluation이라는 새 test 층이 필요해졌다. 동일한 질문에도 표현이 달라질 수 있고 model version이 바뀌면 behavior가 변할 수 있으므로, 대표 input set과 expected criterion을 정하고 factuality·format·latency·cost를 함께 측정해야 했다.

prompt injection도 application security 문제로 떠올랐다. 사용자가 입력한 text뿐 아니라 검색 문서나 외부 tool response 속의 instruction이 system rule을 무시하도록 model을 유도할 수 있었다. 신뢰하지 않는 content와 instruction을 구분하고 model output을 권한 있는 command로 곧바로 실행하지 않는 설계가 필요했다.

Function calling, 대화 model과 실제 system 사이의 계약

OpenAI는 6월 13일 Chat Completions API에 function calling을 발표했다. 개발자가 function의 이름, 설명과 parameter를 JSON Schema로 제공하면 model이 적절한 function과 argument를 JSON object로 제안했다. application이 그 function을 실행하고 결과를 다시 model에 전달하는 구조였다.

{
  "name": "get_post",
  "description": "연도별 개발 연대기를 조회합니다.",
  "parameters": {
    "type": "object",
    "properties": {
      "year": { "type": "integer", "minimum": 1995 }
    },
    "required": ["year"]
  }
}

model이 function을 ‘호출한다’는 표현은 실제 network나 database 권한을 model이 직접 가졌다는 뜻이 아니었다. model은 호출 의도를 나타내는 structured data를 만들고, 실행 여부와 권한 검사는 application code가 담당했다. argument가 schema에 맞더라도 값이 안전하거나 사실이라는 보장은 없었다.

email 발송, 구매와 data 삭제처럼 현실에 영향을 주는 작업에는 사용자 확인과 authorization, idempotency와 audit log가 필요했다. tool의 output도 prompt injection을 포함할 수 있으므로 신뢰 경계를 유지해야 했다. function calling은 LLM을 기존 software에 연결하기 쉽게 했지만, 자연어를 권한 있는 행동으로 바꾸는 security gateway도 함께 만들었다.

Llama 2, 공개 weight와 상업 이용 생태계

Meta는 2월 연구자용 LLaMA를 공개한 뒤 7월 18일 Microsoft와 함께 Llama 2를 발표했다. pretrained model과 conversation용 fine-tuned model의 weight와 시작 code를 제공했고 research와 commercial use를 허용했다. Azure, AWS, Hugging Face와 Windows 등 여러 경로로 배포됐다.

Llama 2는 7B, 13B와 70B parameter 규모로 제공돼 조직이 latency, hardware와 quality 사이에서 model을 선택할 수 있었다. 자체 server나 private cloud에서 inference하고 domain data로 fine-tuning하는 방식이 확산됐다. quantization과 local inference tool도 빠르게 발전했다.

Meta가 ‘open source’라고 표현했지만 Llama 2 Community License에는 월간 active user가 매우 큰 service에 대한 별도 허가 등 OSI license와 다른 조건이 있었다. 따라서 정확한 분류에서는 open weight 또는 source-available model이라고 구분하는 견해가 존재한다. weight를 받을 수 있다는 사실과 제한 없는 open source license는 같지 않다.

자체 hosting도 data가 외부 API로 나가지 않는 장점만 있는 것은 아니었다. GPU provisioning, model serving, patch, safety filter와 abuse monitoring을 운영자가 책임져야 했다. 2023년은 proprietary API와 공개 weight model을 cost·privacy·control 기준으로 조합하는 AI architecture가 본격화된 해였다.

Java 21, virtual thread가 정식 기능이 되다

Java 21은 9월 19일 출시된 LTS version이다. Project Loom에서 개발한 virtual thread가 Java 19와 20의 preview를 거쳐 JEP 444로 정식화됐다. 운영체제 thread와 일대일로 묶이는 platform thread보다 훨씬 가벼운 Java thread를 runtime이 scheduling했다.

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    var futures = urls.stream()
        .map(url -> executor.submit(() -> fetch(url)))
        .toList();

    for (var future : futures) {
        System.out.println(future.get());
    }
}

network나 file I/O에서 virtual thread가 blocking되면 JVM은 carrier thread를 다른 작업에 사용할 수 있었다. callback chain이나 reactive pipeline으로 모든 code를 바꾸지 않고도 요청마다 thread 하나를 쓰는 직관적인 구조로 높은 concurrency를 다룰 수 있었다.

virtual thread는 CPU 연산을 더 빠르게 하거나 무제한 resource를 만드는 기능이 아니다. database connection pool, external API rate와 memory는 여전히 제한돼 semaphore와 backpressure가 필요하다. synchronized block 안의 일부 blocking operation이나 native code가 carrier를 붙잡는 pinning도 관찰해야 했다.

Java 21에는 record pattern과 switch pattern matching도 정식 기능으로 들어왔다. structured concurrency와 scoped value는 preview였다. LTS에 포함됐다는 이유로 preview API까지 안정 기능으로 기록해서는 안 된다.

Passkey, 공유 secret 대신 기기와 공개 키로

2022년 Apple, Google과 Microsoft가 FIDO Alliance·W3C 표준 기반 passkey 지원 계획을 발표한 뒤, 2023년에는 주요 account service가 실제 login 선택지로 확대했다. Google Account는 5월 passkey를 지원했고 GitHub은 9월 일반 제공했다. Apple의 iCloud Keychain과 Google Password Manager 등은 같은 ecosystem의 기기 사이에서 credential을 동기화했다.

passkey는 WebAuthn 공개 키 credential을 사용한다. server에는 공개 키만 저장되고 private key는 authenticator나 보호된 동기화 system에 남는다. credential이 site domain에 묶이므로 가짜 login page가 password를 빼앗는 전형적인 phishing에 강했다.

‘passwordless’가 account recovery 문제까지 자동으로 해결하지는 않았다. 사용자가 모든 device를 잃었을 때의 복구, ecosystem 간 이동, shared device와 기업 관리 정책을 설계해야 했다. SMS나 email recovery가 약하면 passkey가 강해도 account 전체의 보안은 가장 약한 경로에 제한된다.

개발자는 registration과 authentication ceremony, challenge의 일회성 검증, origin과 relying party ID, counter와 credential metadata를 올바르게 처리해야 했다. browser API를 직접 구현하기보다 검증된 library를 사용하되 recovery와 fallback UX까지 threat model에 포함해야 했다.

국내: 지방행정전산서비스 장애와 바뀐 원인 설명

11월 17일 오전 공무원이 지방행정정보 system에 로그인하는 데 필요한 통합인증 영역에서 접속 지연과 장애가 발생했다. 주민센터의 민원 서류 발급과 정부24 service가 영향을 받았다. 정부24는 다음 날 오전 재개됐고 지방행정 service도 주말 동안 안정화 작업을 거쳤다.

복구 초기에는 L4 switch를 교체한 뒤 service가 정상화돼 해당 장비의 OS update가 원인으로 추정됐다. 그러나 rollback과 반복 test에서 같은 문제가 확인되지 않았다. 민관 합동 원인분석반은 network 구간을 좁혀 부하 test를 수행했고 router module의 한 port에서 packet loss를 발견했다.

11월 25일 발표는 장애 당시와 유사한 환경에서 해당 router를 사용했을 때 packet loss가 재현됐다고 밝혔다. 최종 원인은 software update가 아니라 router port의 물리적 불량으로 정리됐다. 장비 전체가 완전히 down된 것이 아니라 일부 module만 비정상이라 기존 이중화가 장애 상태로 인식해 전환하지 못했다.

이 사례는 ‘교체 후 정상화된 부품’과 root cause가 반드시 같지 않음을 보여준다. incident 중에는 복구를 위해 여러 변경을 동시에 수행하므로 correlation만으로 원인을 확정해서는 안 된다. time-aligned log, packet capture, dependency map과 재현 test가 필요하다.

정부 발표에 따르면 문제 router는 2016년 도입돼 내용연수가 지나지 않았으며 물리적 손상의 구체적 발생 원인은 밝히기 어려웠다. 같은 시기 다른 공공 service 장애는 각각 다른 원인으로, 이 router 문제와 연결되지 않는다고 설명했다. 하나의 큰 서사로 묶기보다 incident별 evidence를 분리해야 한다.

재발 방지 방향에는 오래된 장비 전수점검, 통합 monitoring, 상설 장애대응반과 위기 대응 체계가 포함됐다. 기술적으로는 장비 전체의 up/down만 보는 health check를 넘어 port별 packet loss와 end-to-end transaction을 관찰하고, partial failure에서도 traffic이 우회하도록 설계하는 과제가 남았다.

2023년의 의미

2023년의 생성형 AI는 답변 생성에서 action 연결로 이동했다. GPT-4의 능력과 function calling의 structured output, Llama 2의 자체 hosting 선택지는 LLM을 product architecture의 한 component로 만들었다. 동시에 hallucination, prompt injection, license와 model version 변화 때문에 evaluation과 권한 경계가 새 engineering discipline이 됐다.

Java 21 virtual thread는 복잡성을 application callback에서 runtime scheduler로 옮기는 다른 방향의 혁신이었다. passkey는 인증 secret을 사람이 기억하고 입력하는 방식에서 device가 site별 공개 키를 증명하는 방식으로 전환했다.

국내 행정전산망 장애는 완전한 장비 고장보다 탐지하기 어려운 부분 고장이 더 큰 영향을 줄 수 있음을 보여줬다. 초기 추정은 복구에 유용할 수 있지만 역사에는 재현과 검증을 거친 결과를 기록해야 한다. 2024년에는 AI model이 text를 넘어 더 긴 context와 실시간 multimodal interaction으로 확장되고, 전 세계는 AI 법·안전 표준과 software supply chain 규제를 구체화한다.

참고 자료

블로그 목록으로 돌아가기