안녕하세요, 서안입니다 👋

궁금한 것을 직접 만들어 보고, 실행 결과를 확인하며 배우는 개발자입니다.

요즘은 한국어 언어 모델과 모델을 학습·평가·배포하는 전체 과정을 공부하고 있습니다.

저는 코딩을 취미로 시작해, 궁금한 것을 작은 프로그램으로 만들어 확인하는 일을 즐깁니다. 처음부터 모든 개념을 알고 시작하기보다 필요한 것을 하나씩 배우고, 작성한 코드를 직접 실행해 결과를 살피는 편입니다. 예상과 다른 결과가 나오면 그 차이가 어디에서 생겼는지 찾아보고, 다음 실험에서 바꿀 조건을 정합니다.

현재 가장 큰 관심사는 한국어 언어 모델입니다. 모델이 문장을 생성하는 원리만 살펴보는 데 그치지 않고, 토크나이저와 데이터 준비, 학습 루프, 체크포인트, 추론, 평가, 내보내기까지 한 흐름으로 연결해 이해하려고 합니다. 이런 관심을 바탕으로 Korean-llm 프로젝트를 발전시키고, 구조를 정돈한 Hanok LLM을 만들고 있습니다.

저는 완성된 결과물만큼 그것이 만들어지는 과정을 중요하게 생각합니다. 학습이 잘 진행되는 것처럼 보여도 데이터가 제대로 전달되는지, 체크포인트를 다시 불러올 수 있는지, 평가가 같은 조건에서 반복되는지 확인해야 결과를 믿을 수 있다고 배웠습니다. 잘못된 실험을 알아차리면 그 결과를 무리하게 포장하기보다 원인을 찾아 기록하고, 신뢰할 수 있는 상태부터 다시 시작하는 것이 더 낫다고 생각합니다.

AI 도구는 학습과 개발 과정에서 자주 활용합니다. 다만 제게 중요한 것은 답변이나 코드 조각을 받는 데서 끝나지 않는 것입니다. 코드를 실행하고, 동작을 살펴보고, 로그와 오류를 읽으며 이해한 내용을 확인합니다. 도구가 제안한 내용도 프로젝트의 실제 동작과 맞는지 검토하려고 합니다. AI를 활용하는 과정 자체를 더 나은 학습 기회로 만들고 싶습니다.

• 직접 확인하기: 설명을 읽는 데서 멈추지 않고 실행 결과나 데이터로 확인합니다.
• 작게 나누기: 큰 목표를 모델, 데이터, 학습, 평가처럼 점검 가능한 단위로 나눕니다.
• 실패를 기록하기: 잘못된 결과도 원인을 이해하면 다음 설계에 도움이 됩니다.
• 재현 가능성: 어떤 설정과 데이터로 결과가 나왔는지 남기고 다시 확인할 수 있게 합니다.
• 읽을 수 있는 코드: 지금의 저와 나중의 다른 사람이 흐름을 따라갈 수 있도록 정리합니다.
• 과장하지 않기: 실험에서 확인한 내용과 앞으로 해보고 싶은 일을 구분해 설명합니다.

한국어는 조사와 어미가 다양하고, 띄어쓰기나 문맥에 따라 단어의 의미가 달라질 수 있습니다. 그래서 한국어 데이터를 어떤 기준으로 정리하고 토큰으로 나누는지가 모델 결과에 어떤 영향을 주는지 궁금합니다. 한국어에 적합한 토크나이저와 학습 데이터, 평가 방법을 직접 살펴보고 작은 실험으로 차이를 확인하고 있습니다.

제가 관심을 두는 것은 특정 숫자의 파라미터를 가진 모델을 만드는 일만이 아닙니다. 모델이 어떤 데이터를 보고 학습했는지, 학습 중 손실이 어떻게 변했는지, 생성 결과가 어떤 유형의 질문에서 나아지거나 나빠지는지 이해하는 것이 중요합니다. 모델 크기와 실행 환경이 달라질 때 메모리와 속도, 품질 사이의 균형이 어떻게 바뀌는지도 함께 살펴봅니다.

모델 코드는 전체 시스템 중 한 부분입니다. 데이터를 읽는 단계에서 샘플이 빠지거나, 라벨과 입력의 대응이 어긋나거나, 평가 데이터가 학습에 섞이면 모델 구조가 좋아도 결과를 믿기 어렵습니다. 그래서 데이터 로딩과 전처리, 배치 구성, 손실 계산, 저장과 복구, 평가 단계를 각각 점검할 수 있는 구조에 관심이 있습니다.

실험을 비교할 때는 변경한 조건을 분명히 하려고 합니다. 여러 설정을 한꺼번에 바꾸면 결과가 달라졌을 때 원인을 찾기 어렵습니다. 가능한 경우 한 번에 하나의 요소를 바꾸고, 같은 입력과 평가 기준으로 비교합니다. 이런 방식은 빠른 성과를 보장하지는 않지만 어떤 선택이 도움이 되었는지를 배우는 데 유용합니다.

큰 모델을 학습하거나 실행하려면 계산 자원과 메모리를 신중하게 다뤄야 합니다. 혼합 정밀도, 그래디언트 누적, 그래디언트 체크포인팅, 최적화된 옵티마이저 같은 기법은 각기 다른 방식으로 메모리와 속도에 영향을 줍니다. 저는 기법의 이름을 나열하는 것보다 실제 코드에서 어떤 비용을 줄이는지, 어떤 제약이나 속도 저하가 따라오는지 확인하는 데 관심이 있습니다.

작은 메모리 사용량만으로 모델의 품질이나 효율성이 입증되는 것은 아닙니다. 메모리 측정 조건, 배치 크기, 시퀀스 길이, 정밀도, 하드웨어와 소프트웨어 버전을 함께 기록해야 수치를 올바르게 해석할 수 있습니다. 그래서 향후 실험에서는 숫자와 함께 측정 맥락도 남기는 것을 목표로 합니다.

언어 모델을 사용하다 보니 모델을 직접 만들어 보면 내부에서 무슨 일이 일어나는지 더 잘 이해할 수 있겠다는 생각이 들었습니다. 처음에는 모델의 크기와 이름 정도만 익숙했고, 학습 데이터가 어떻게 모델의 매개변수로 이어지는지, 한 번의 학습 단계가 무엇을 계산하는지 충분히 알지 못했습니다. 작은 실험을 시작하고 나서야 개념과 구현이 얼마나 많이 연결되어 있는지 보이기 시작했습니다.

그 과정은 단순히 모델을 크게 만드는 일이 아니었습니다. 모델 정의가 입력과 출력의 크기에 맞는지, 토크나이저가 학습 때와 생성 때 동일하게 사용되는지, 데이터셋의 각 샘플이 실제로 학습에 들어가는지 확인해야 했습니다. 학습이 끝난 뒤에는 체크포인트를 저장하고 다시 읽는 과정도 검증해야 했습니다. 하나라도 틀리면 학습 시간이 길어도 쓸 수 있는 결과가 나오지 않을 수 있습니다.

이 경험은 제가 프로젝트를 바라보는 방식을 바꿨습니다. 출력이 그럴듯해 보이는지만 확인하는 대신, 그 결과를 만든 입력과 코드 경로를 살펴보게 되었습니다. 속도나 파라미터 수 같은 한 가지 숫자만으로 성공을 선언하지 않고, 반복해서 확인할 수 있는 증거를 모으려고 합니다.

아래 내용은 공개 저장소의 프로젝트 기록과 현재 README에 적힌 실험 메모를 바탕으로 요약한 것입니다. 버전 이름과 설정은 개발 과정에서 달라질 수 있으므로, 구체적인 학습 방법과 실행 조건은 각 저장소의 최신 문서를 기준으로 확인해 주세요.

처음에는 작은 모델로 언어 모델 학습의 기본 흐름을 살펴봤습니다. 데이터가 토큰으로 바뀌고, 모델이 다음 토큰을 예측하고, 손실이 계산되는 과정을 직접 실행해 보는 것이 목적이었습니다. 작은 모델은 대규모 모델의 능력을 보여 주기 위한 결과라기보다 시스템의 기본 동작을 이해하기 위한 실험이었습니다.

초기 실험을 통해 모델이 문장을 이어 쓰는 모습만으로 학습이 올바르게 진행됐다고 판단할 수 없다는 점을 알게 됐습니다. 짧은 프롬프트에 대한 한두 번의 응답은 데이터 누락이나 과적합, 잘못된 설정을 드러내지 못할 수 있습니다. 다양한 입력을 넣어 보고, 손실과 생성 결과를 함께 확인해야 했습니다.

이후에는 수억에서 약 10억 규모의 모델을 실험하는 단계로 확장했습니다. 규모가 커지면 모델 정의뿐 아니라 데이터 파이프라인과 학습 환경의 작은 문제도 더 큰 비용으로 이어집니다. 실제 개발 기록에서 데이터셋 일부가 기대한 방식으로 사용되지 않는 문제와 출력 이상을 확인했고, 그 결과를 정상적인 학습 성과로 간주하지 않기로 했습니다.

실험 결과가 기대와 다를 때는 모델 자체가 부족한지, 데이터가 잘못 전달됐는지, 학습 설정이 적절하지 않은지 구분해야 합니다. 데이터 로딩 과정과 실제 학습 배치를 확인하지 않고 구조를 바꾸면 문제를 해결하지 못한 채 복잡성만 늘릴 수 있습니다. 그래서 신뢰하기 어려운 학습 결과를 보존하는 데 집착하기보다 데이터 처리 과정을 다시 점검하는 방향을 택했습니다.

이 과정에서 얻은 교훈은 분명합니다. 학습 스크립트가 오류 없이 끝났다는 사실은 올바른 학습의 증거가 아닙니다. 데이터의 개수와 분포, 샘플 내용, 손실 변화, 생성 결과, 체크포인트의 복구 여부를 함께 살펴야 합니다. 실패한 시도도 원인을 찾을 수 있도록 기록해야 다음 시도가 더 나아집니다.

약 1B 규모의 모델을 다루면서 GPU 메모리가 중요한 제약이라는 점을 직접 경험했습니다. 기존 실험 기록에는 학습 메모리를 약 23GB에서 10GB 미만으로 줄이는 데 성공했다고 적혀 있습니다. 이 수치는 특정 구성과 실행 조건에서 얻은 기록이며, 모든 GPU나 설정에서 같은 결과가 나온다는 뜻은 아닙니다.

메모리를 줄이는 과정에서는 정밀도, 배치 크기, 시퀀스 길이, 옵티마이저 상태, 중간 활성값을 각각 고려해야 합니다. 기법은 서로 영향을 주므로 한 설정을 바꾸면 속도나 안정성, 결과 품질도 달라질 수 있습니다. 메모리 사용량을 낮춘 뒤에도 학습이 제대로 수렴하는지, 평가 결과가 유지되는지 확인하는 작업이 필요합니다.

제가 이 경험에서 배운 것은 최적화가 단순히 숫자를 낮추는 경쟁이 아니라는 점입니다. 무엇을 절약하고 어떤 비용을 치르는지 알아야 합니다. 예를 들어 재계산으로 메모리를 절약하는 방법은 연산 시간을 늘릴 수 있고, 낮은 정밀도는 하드웨어 지원과 수치 안정성에 영향을 받을 수 있습니다. 그러므로 실행 조건과 측정 방식을 함께 기록해야 합니다.

Korean-llm은 한국어 LLM을 직접 구현하고 학습해 보려는 연구의 출발점입니다. Hanok LLM은 그 경험을 바탕으로 모델과 데이터, 학습, 추론, 평가, 내보내기 기능을 보다 분명하게 나누어 정리하려는 프로젝트입니다. 두 저장소의 관계와 최신 구현은 Korean-llm과 Hanok-LLM에서 확인할 수 있습니다.

Hanok의 공개 설명은 PyTorch 기반 디코더 Transformer 스택을 소개하며, RMSNorm, RoPE, SwiGLU, 가중치 공유, KV 캐시를 포함한 구성 요소를 기록하고 있습니다. 또한 사전 학습과 지도 미세 조정, 체크포인트, 추론, 평가, 모델 내보내기 흐름을 다루고 있습니다. 자세한 옵션과 실제 지원 범위는 프로젝트 README와 코드에 따라 달라질 수 있으므로, 이 프로필에서는 기능을 과도하게 보장하지 않고 방향을 설명합니다.

프로젝트를 모듈화하는 이유는 기능을 늘리기 위해서만이 아닙니다. 데이터 로더만 따로 확인하거나, 학습 설정을 비교하거나, 추론 코드를 독립적으로 살펴보기가 쉬워집니다. 작은 단위로 경계를 만들면 문제가 발생한 지점을 좁히고 변경의 영향을 이해하는 데 도움이 됩니다. 반대로 구조를 나누는 데만 집중해 실제 사용 흐름이 복잡해지지 않도록 균형을 잡는 것도 중요합니다.

Hanok LLM은 제가 배운 내용을 하나의 실행 가능한 프로젝트로 연결하는 작업입니다. 모델 구조를 구현하는 것으로 끝내지 않고, 데이터를 불러와 학습하고, 체크포인트를 남기고, 추론과 평가를 실행하고, 필요하면 다른 형식으로 내보내는 과정까지 이어 보려고 합니다.

모델 코드를 읽을 수 있게 구성하고, 각 구성 요소의 입출력과 역할을 이해하는 것이 목표입니다. 디코더 Transformer의 블록, 정규화, 위치 정보, 어텐션, 피드포워드 계층이 어떻게 이어지는지 살펴봅니다. 구성 요소를 직접 구현하면 추상화된 라이브러리를 쓰는 것만으로는 놓치기 쉬운 텐서 크기와 데이터 흐름을 배울 수 있습니다.

모델의 설정은 파라미터 수 하나로 설명되지 않습니다. 레이어 수, 은닉 차원, 헤드 수, 어휘 크기, 임베딩 공유 여부 등에 따라 전체 크기와 실행 특성이 달라집니다. 토크나이저의 어휘 크기가 달라지면 임베딩 파라미터 수도 변할 수 있습니다. 그래서 프로필에서는 확인되지 않은 수치를 고정된 사양처럼 반복하지 않고, 저장소의 모델 카드와 설정을 기준으로 보도록 안내합니다.

언어 모델의 결과는 데이터의 영향을 크게 받습니다. 텍스트를 어떤 출처에서 모았는지, 어떤 라이선스 조건이 있는지, 중복이나 손상된 샘플을 어떻게 처리하는지, 어떤 필드를 입력과 정답으로 사용하는지에 따라 학습 결과가 달라집니다. 데이터 준비는 모델 학습의 사전 작업이 아니라 결과의 신뢰성과 사용 가능성을 결정하는 핵심 부분입니다.

데이터 파이프라인을 살펴볼 때는 샘플이 기대한 수만큼 로드되는지, 전처리 이후에도 의미 있는 텍스트가 남는지, 학습과 평가가 의도한 대로 분리되는지 확인하려고 합니다. 예시 몇 개를 눈으로 읽어 보는 일도 중요합니다. 자동 검사는 구조적인 오류를 찾는 데 도움이 되지만, 데이터의 의미와 적합성을 모두 판정해 주지는 않습니다.

공개 데이터셋이나 모델을 사용한다면 라이선스와 사용 조건을 확인해야 합니다. 프로젝트에 포함된 문서가 설명하는 조건을 따르고, 학습 데이터의 출처와 처리 방식이 공개된 범위 안에서 이해되도록 기록하는 것을 목표로 합니다. 데이터와 관련된 구체적인 정책은 프로젝트의 최신 DATA_CARD와 라이선스 문서를 확인해 주세요.

학습 단계에서는 모델이 다음 토큰 예측을 통해 파라미터를 조정하는 기본 과정을 이해하고, 이를 실행 환경에 맞게 구성합니다. 학습률, 배치 크기, 시퀀스 길이, 그래디언트 누적과 같은 설정은 학습 안정성과 실행 비용에 함께 영향을 줍니다. 따라서 기본값을 그대로 두기보다 어떤 의미인지 알고 실험 기록에 남기려 합니다.

체크포인트는 학습 상태를 저장하고 이어서 실행하거나 결과를 검토하기 위한 중요한 경계입니다. 모델 파라미터만 저장할지, 옵티마이저와 스케줄러 상태도 함께 저장할지에 따라 재개 동작이 달라집니다. 파일이 저장되었다는 사실만으로 충분하지 않으며, 실제로 불러와 이전 작업을 이어갈 수 있는지 점검해야 합니다.

훈련 중에는 손실값과 로그를 살펴보되, 손실 하나를 전체 품질로 해석하지 않으려 합니다. 손실이 낮아져도 생성 결과가 반복적이거나, 학습 데이터에만 잘 맞거나, 일부 입력 형식에서 문제가 생길 수 있습니다. 학습 진행 상황을 판단할 때는 정량 평가와 생성 예시, 데이터 점검을 함께 사용해야 합니다.

사전 학습과 지시문에 맞는 응답을 학습하는 과정은 목적이 다릅니다. 지도 미세 조정을 사용한다면 입력과 응답이 어떻게 표시되는지, 손실이 어떤 토큰에 적용되는지, 데이터가 목표 작업에 적합한지 확인해야 합니다. 예시의 포맷을 바꾸면 모델이 학습하는 행동도 달라질 수 있으므로 데이터 포맷은 단순한 문자열 처리 문제가 아닙니다.

대화 데이터는 질문과 답변의 경계를 명확하게 해야 합니다. 응답 부분만 학습하도록 마스킹하는 경우에는 실제 마스크가 의도한 위치에 적용됐는지 확인해야 합니다. 잘못된 마스크는 입력을 정답으로 학습하거나 응답을 놓치는 문제를 만들 수 있습니다. 구현 설명만 믿지 않고 배치 하나를 직접 확인하는 습관을 기르려 합니다.

추론은 학습된 모델에 입력을 전달하고 다음 토큰을 차례로 생성하는 과정입니다. 온도, top-k, top-p, 반복 패널티 같은 생성 설정은 출력의 다양성과 반복성에 영향을 줍니다. 파라미터를 조정할 때는 한두 개의 예시만 보고 결론을 내리지 않고, 같은 프롬프트 모음에서 결과를 비교하는 편이 낫습니다.

KV 캐시는 이전 토큰의 키와 값 계산을 재사용해 생성 과정의 반복 계산을 줄이는 방식입니다. 캐시 사용은 메모리와 속도 사이의 선택에 영향을 주며, 캐시의 형태와 길이를 잘못 관리하면 결과 오류나 메모리 문제가 발생할 수 있습니다. 따라서 기능이 있다는 소개와 다양한 조건에서 올바르게 동작한다는 검증은 구분해야 합니다.

모델을 로드할 때는 학습 때 사용한 설정과 토크나이저가 추론에서도 맞는지 확인해야 합니다. 체크포인트의 모델 구조가 다르거나 토큰 ID가 달라지면 정상적인 결과를 기대하기 어렵습니다. 추론 테스트는 단순히 코드가 실행되는지뿐 아니라 짧은 입력, 긴 입력, 빈 입력에 가까운 경계 상황도 고려해야 합니다.

평가는 모델을 더 잘 이해하고 변경을 비교하기 위한 과정입니다. 단일 점수는 모델의 모든 능력을 요약하지 못하므로 평가 목적을 명시해야 합니다. 언어 모델의 다음 토큰 손실, 정해진 문제에 대한 정답률, 사람이 읽는 생성 예시 등 서로 다른 관점을 함께 사용할 수 있습니다.

재현 가능한 비교를 위해서는 평가 데이터와 프롬프트, 생성 설정, 모델 체크포인트를 함께 기록하는 것이 좋습니다. 무작위 생성 설정이 결과에 영향을 줄 수 있다면 시드를 고정하거나 반복 실행 결과를 함께 보는 방법을 고려합니다. 평가 데이터가 학습 데이터와 겹치는지도 살펴야 결과의 의미를 더 잘 해석할 수 있습니다.

평가에서 기대만큼 좋아지지 않았다고 해서 실험 전체가 무의미한 것은 아닙니다. 어떤 항목에서 변했는지, 무엇이 그대로였는지 기록하면 다음 가설을 세우는 근거가 됩니다. 반대로 몇 가지 인상적인 예시만 골라서 모델이 전반적으로 좋아졌다고 주장하지 않으려 합니다.

모델을 다른 도구에서 사용하도록 내보내는 일은 설정과 가중치를 호환되는 형식으로 변환하고, 변환 뒤의 결과를 확인하는 과정입니다. 파일 생성만 성공했다고 배포가 완료된 것은 아닙니다. 토크나이저 파일, 모델 설정, 생성 설정이 함께 전달되는지, 변환된 모델이 실제 추론에서 읽히는지 확인해야 합니다.

Hanok LLM 저장소는 내보내기와 로컬 실행을 다루는 방향으로 구성되어 있지만, 실제 제공 범위는 해당 저장소의 코드와 문서에 따라 달라집니다. 모델 가중치가 저장소에 포함되어 있는지, 사용자가 별도로 준비해야 하는지, 변환 명령이 현재 버전에서 작동하는지 최신 README를 확인해 주세요. 이 프로필은 배포 가능성을 과장하지 않고 개발 방향을 설명합니다.

실험을 시작할 때는 먼저 알고 싶은 질문을 한 문장으로 적습니다. 예를 들면 “시퀀스 길이를 바꾸면 메모리와 손실이 어떻게 달라지는가?”와 같이 관찰 가능한 형태가 좋습니다. 질문이 분명하면 필요한 측정값과 바꿀 설정을 정하기 쉬워집니다.

그다음에는 기준이 될 설정을 남기고 한 번에 바꾸는 요소를 제한합니다. 모든 변수를 한꺼번에 바꾸면 결과 차이를 설명하기 어렵기 때문입니다. 실험 규모가 작더라도 실행한 코드 버전, 설정, 데이터 처리 방식, 하드웨어와 결과를 함께 적으면 나중에 비교하는 데 도움이 됩니다.

결과를 볼 때는 기대와 실제를 나눠 기록합니다. 기대와 다르게 나온 점은 실패라기보다 다음 점검의 출발점이 될 수 있습니다. 예를 들어 메모리를 줄였는데 속도가 크게 느려졌다면 두 지표의 교환 관계를 확인할 수 있고, 손실이 낮아졌는데 생성이 나빠졌다면 데이터나 평가 방식에 대한 다른 질문을 만들 수 있습니다.

마지막으로 결과가 유효한지 확인합니다. 데이터가 실제로 공급됐는지, 손실이 정상 범위를 보이는지, 체크포인트가 다시 로드되는지, 평가가 동일한 조건에서 반복되는지 점검합니다. 확인하지 못한 항목은 완료된 사실처럼 쓰지 않고, 다음에 확인할 일로 남깁니다.

오류가 발생하면 우선 오류 메시지와 그 직전의 입력, 설정을 살펴봅니다. 막연히 코드를 크게 바꾸기보다 문제가 시작된 경계를 찾는 편이 빠른 경우가 많습니다. 데이터 로드, 토크나이저, 텐서 크기, 모델 순전파, 손실 계산, 역전파, 저장, 추론 중 어느 단계인지 좁힙니다.

차원 오류가 생기면 각 텐서의 모양과 축의 의미를 확인합니다. 메모리 오류가 생기면 모델 가중치뿐 아니라 활성값, 옵티마이저 상태, 캐시, 배치와 시퀀스 길이를 함께 고려합니다. 학습이 불안정하면 데이터 샘플과 학습률, 정밀도, 그래디언트 크기 등 여러 가능성을 차례로 점검합니다.

수정 뒤에는 같은 문제가 해결됐는지 재현 조건에서 확인합니다. 오류가 사라졌더라도 다른 기능이 깨지지 않았는지, 학습과 추론의 연결이 유지되는지 확인할 필요가 있습니다. 작은 수정과 명확한 기록은 원인을 추적하기 쉽게 해 줍니다.

공개 프로젝트에서 확인되는 주요 기술은 Python과 PyTorch를 중심으로 한 머신러닝 개발입니다. 모델과 데이터 작업에 필요한 라이브러리를 사용하고, GitHub에서 코드를 관리합니다. C 언어도 학습하고 있으며, 새로운 도구는 필요한 문제를 해결하는 과정에서 익혀 나가고 있습니다.

도구를 많이 나열하는 것보다 실제로 어떤 문제를 해결하는 데 썼는지가 더 중요하다고 생각합니다. 예를 들어 PyTorch는 모델과 학습 루프를 구현하고 실험하기 위해 사용합니다. Git은 변경을 기록하고 이전 상태와 비교하는 데 사용합니다. 각 라이브러리의 버전과 설치 방식은 실행 환경에 따라 달라질 수 있으므로 프로젝트별 설정 파일을 참고해 주세요.

공개 저장소의 실행 문서와 실험 기록에서 확인되는 환경을 한곳에 정리했습니다. 아래 내용은 모든 프로젝트에 항상 고정된 사양이라는 뜻이 아니라, 공개된 학습 실험에서 사용되었거나 요구 사항으로 문서화된 구성입니다. 실제 실행 전에는 해당 저장소의 최신 README, requirements.txt, 설정 파일을 확인해 주세요.

모델의 학습 시간과 GPU 메모리 사용량은 모델 크기만으로 정해지지 않습니다. GPU의 메모리와 연산 능력, CPU와 시스템 메모리, CUDA·PyTorch 버전, 배치 크기와 시퀀스 길이가 함께 영향을 줍니다. 그래서 “10GB로 실행된다”와 같은 표현은 측정한 장비와 설정을 함께 적을 때만 의미가 있습니다.

현재 공개된 개발 환경은 RTX 5090 Laptop 24GB VRAM, Intel Core Ultra 9 275HX, 64GB RAM, CUDA 12.1, PyTorch 2.4.0 구성입니다. Intel 공식 사양에 따르면 Core Ultra 9 275HX는 24코어(Performance 8개, Efficient 16개), 최대 5.4GHz, 36MB Intel Smart Cache를 갖춘 모바일 프로세서입니다. 실제 측정값은 GPU 전력·냉각 설정과 프로젝트별 소프트웨어 버전에 따라 달라질 수 있습니다.

앞으로는 새 기능을 빠르게 추가하는 것보다 기존 흐름을 더 잘 이해하고 검증하는 데 시간을 쓰고 싶습니다. 데이터에서 평가까지 이어지는 경로를 점검하고, 같은 설정으로 다시 실행했을 때 결과를 비교할 수 있도록 문서와 도구를 개선하는 것이 우선입니다.

데이터의 출처와 라이선스, 전처리 규칙을 더 명확히 정리하고, 파이프라인이 의도한 데이터를 사용하는지 확인하는 방법을 익히고 싶습니다. 평가에서는 단순한 인상이나 몇 개의 예시가 아니라, 반복해서 비교할 수 있는 기준을 만들고 싶습니다. 각 지표가 무엇을 측정하고 무엇을 놓치는지도 함께 공부할 계획입니다.

하드웨어 자원이 제한된 환경에서 모델을 학습하고 실행하는 여러 방법을 더 깊이 이해하고 싶습니다. 어떤 최적화가 메모리를 줄이고 어떤 비용을 더하는지 수치로 확인하는 것이 목표입니다. 여러 정밀도와 배치 조건을 비교할 때 품질과 실행 시간도 같이 살펴보려고 합니다.

프로젝트가 커지면 코드 구조와 사용 설명서가 실제 기능만큼 중요해집니다. 처음 접하는 사람이 설치와 실행 흐름을 이해할 수 있도록 예제를 정리하고, 기능이 제공되는 조건과 제한을 분명하게 적는 방향으로 개선하고 싶습니다. 설명과 구현이 서로 어긋나지 않도록 코드 변경 시 문서도 함께 확인하는 습관을 기르겠습니다.

한국어 모델을 중심에 두면서도 언어별 토크나이저와 데이터 처리 방식의 차이를 배우고 싶습니다. 멀티모달 입력이나 도구 사용 같은 주제도 장기적인 관심사입니다. 다만 아직 진행하지 않은 작업을 완료한 기능처럼 소개하지 않고, 현재 프로젝트의 기반을 다진 뒤 작은 실험으로 확인해 나가려 합니다.

파라미터 수는 모델의 규모를 설명하는 여러 값 중 하나입니다. 모델이 더 많은 파라미터를 가졌다고 해서 데이터와 학습, 평가가 자동으로 좋아지는 것은 아닙니다. 더 큰 모델은 더 많은 자원과 더 신중한 검증을 필요로 합니다. 작은 실험에서 배운 원칙을 규모가 커져도 유지하는 것이 중요합니다.

프로그램이 오류 없이 종료되어도 데이터가 잘못 처리됐거나 체크포인트가 사용할 수 없는 상태일 수 있습니다. 실행 완료와 결과의 타당성은 다른 질문입니다. 학습 경로를 여러 지점에서 확인해야 하고, 샘플과 지표를 직접 점검해야 합니다.

잘못된 입력이나 파이프라인으로 만들어진 결과를 계속 개선하려고 하면 잘못된 전제를 더 오래 유지할 수 있습니다. 결과를 폐기하는 일은 시간을 낭비한 것처럼 보일 수 있지만, 문제를 일찍 발견했다면 이후의 더 큰 비용을 줄일 수 있습니다. 무엇을 확인했고 왜 신뢰하기 어려웠는지 기록하면 그 경험은 다음 실험에 남습니다.

“빠르다”, “효율적이다”, “잘 작동한다” 같은 표현은 조건 없이 쓰면 의미가 모호합니다. 어떤 장치와 설정에서 측정했는지, 어떤 작업에서 결과가 좋았는지 함께 설명해야 합니다. 앞으로 프로젝트 문서와 이 프로필에서도 관찰한 결과, 설계 의도, 미완료 목표를 구분하려고 합니다.

AI는 아이디어를 정리하고 코드의 선택지를 탐색하는 데 도움을 줄 수 있습니다. 하지만 제 프로젝트의 실행 결과와 목적에 맞는지 확인하는 책임은 여전히 개발자에게 있습니다. 생성된 코드의 입출력, 오류 처리, 의존성, 영향 범위를 살펴보고 제가 설명할 수 있는 상태로 만드는 것이 중요합니다.

지금은 모델과 학습 시스템을 이해하는 데 필요한 여러 주제를 연결해서 보고 있습니다. 어텐션은 입력 토큰 사이의 관계를 계산하는 방식이고, 위치 정보는 순서가 중요한 텍스트를 표현하는 데 필요합니다. 정규화와 잔차 연결은 깊은 네트워크의 학습 흐름에 영향을 주며, 피드포워드 계층은 각 토큰 표현을 변환합니다. 이런 개념을 공식만 외우기보다 코드의 텐서 흐름과 함께 확인하고 싶습니다.

토크나이저도 중요한 학습 주제입니다. 단어 단위, 문자 단위, 서브워드 단위처럼 토큰을 구성하는 기준은 어휘 크기와 시퀀스 길이, 희귀 단어 표현에 영향을 줍니다. 한국어에서는 형태와 띄어쓰기, 조사·어미의 조합을 어떻게 다루는지가 특히 흥미롭습니다. 토큰화 방식의 차이를 비교할 때는 어휘 크기뿐 아니라 실제 문장이 몇 토큰으로 분할되는지, 모델의 입력 길이에 어떤 영향을 주는지 확인해야 합니다.

최적화 알고리즘과 학습률 스케줄도 공부하고 있습니다. 학습률은 파라미터를 얼마나 크게 갱신할지를 조절하고, 워밍업이나 코사인 스케줄 같은 방식은 학습 과정에 따라 그 값을 바꿉니다. 배치 크기와 그래디언트 누적은 한 번의 업데이트에 반영되는 샘플 수와 메모리 요구량에 관계됩니다. 설정을 바꾸면 속도뿐 아니라 수렴과 안정성도 달라질 수 있어 실험으로 확인해야 합니다.

또한 생성 모델의 평가와 한계에 관심이 있습니다. 다음 토큰 예측 손실은 유용하지만 실제 사용자의 질문에 대한 답변 품질 전체를 나타내지는 않습니다. 모델이 학습에서 본 내용을 기억하거나, 프롬프트에 민감하게 반응하거나, 그럴듯하지만 사실과 다른 문장을 만들 수도 있습니다. 모델의 성능을 설명할 때는 무엇을 평가했고 어떤 한계가 있었는지 함께 적는 편이 정직합니다.

공개 저장소는 코드를 보관하는 곳이면서 다른 사람이 같은 문제를 살펴볼 수 있는 기록이라고 생각합니다. 설명이 부족하거나 실행 방법이 모호하면 처음 보는 사람이 프로젝트의 목적을 이해하기 어렵습니다. 그래서 README에는 프로젝트가 무엇인지, 어디까지 구현되었는지, 어떤 문서를 보면 되는지 알기 쉽게 적고 싶습니다.

다른 사람이 남긴 의견이나 버그 보고는 코드를 개선할 기회가 될 수 있습니다. 제안이 들어오면 먼저 재현 가능한지 확인하고, 문제가 맞다면 원인을 이해한 뒤 수정하는 것이 좋습니다. 아직 모든 기여 절차나 응답 체계가 갖춰진 것은 아니므로, 기여 전에 해당 저장소의 CONTRIBUTING 문서와 이슈 안내를 확인해 주세요.

오픈소스 프로젝트를 사용할 때는 코드를 가져오는 것만큼 라이선스와 데이터 조건을 이해하는 일도 중요합니다. 코드, 가중치, 토크나이저, 학습 데이터가 각각 다른 조건을 가질 수 있습니다. 프로젝트별로 공식 문서를 확인하고, 조건이 불분명하면 허용 범위를 추측하지 않는 태도를 지키고 싶습니다.

한국어 언어 모델을 연구하고 학습·추론·평가하는 모듈형 PyTorch 프로젝트입니다. 모델 구조와 학습 파이프라인, 데이터 처리, 체크포인트, 추론 도구 등을 살펴보고 싶다면 Hanok-LLM 저장소를 확인해 주세요. 저장소의 README, 모델 카드, 데이터 카드가 구체적인 구성과 사용 조건을 설명합니다.

한국어 LLM 구현과 학습을 시작하며 쌓은 연구 기반입니다. Hanok LLM이 어떤 경험에서 출발했는지 보고 싶다면 Korean-llm 저장소를 둘러볼 수 있습니다. 버전별 실험 기록은 시도와 변경의 맥락을 이해하는 데 도움이 됩니다.

개발 중인 프로젝트의 README에는 목표와 현재 구현, 과거 실험이 함께 기록될 수 있습니다. 설치 명령이나 지원 기능은 코드 변경과 함께 달라질 수 있으므로 마지막 커밋과 최신 설정 파일을 확인해 주세요. 프로필의 요약은 전체 사용 설명서나 성능 보증을 대신하지 않습니다.

저는 이미 모든 것을 알고 있는 전문가로 자신을 소개하려는 것이 아닙니다. 궁금한 것을 배우고, 직접 구현하고, 잘못된 결과를 다시 점검하는 과정을 공개적으로 쌓아 가는 학생 개발자입니다. 한국어 LLM 프로젝트는 그 과정에서 가장 많은 시간과 호기심을 쏟고 있는 작업입니다.

저장소를 살펴볼 때는 완성된 제품인지, 학습용 구현인지, 실험 중인 코드인지 각 문서에서 현재 상태를 확인해 주세요. 특히 학습 데이터와 모델 가중치, 하드웨어 요구 사항, 실행 명령은 저장소마다 다를 수 있습니다. 확인된 내용과 계획을 구분해 이해하는 것이 프로젝트를 올바르게 평가하는 데 도움이 됩니다.

이 프로필이 보여 주고 싶은 것은 거창한 약속보다 꾸준한 탐구입니다. 작은 모델에서 시작해 데이터와 학습의 문제를 발견하고, 구조를 정리하고, 검증 가능한 실행 흐름을 만들려는 과정입니다. 앞으로 더 나은 실험과 문서로 지금의 배움을 이어가겠습니다.

• GitHub 프로필
• Hanok LLM
• Korean-llm
• Hanok LLM 모델 카드

만들고, 배우고, 확인하고, 다시 개선하기.