🔍 소프트웨어의 본질: 코드는 전부가 아닙니다​

우리는 흔히 소프트웨어의 중심이 ‘코드’라고 생각하지만, 실제로 코드가 만들어지기까지의 전 과정을 들여다보면 진짜 핵심은 '커뮤니케이션' 에 있음을 알 수 있습니다.
무엇을 만들지, 왜 만들지, 어떻게 만들지, 그리고 만들어진 것이 의도한 대로 작동하는지까지. 이 모든 것은 사람 사이 또는 사람과 인공지능 사이에 구조화된 커뮤니케이션을 통해 이루어집니다.

🤖 LLM 시대의 전환점: 컴파일러에서 모델로​

LLM이 본격적으로 등장하면서, 프로그래머가 코드를 직접 작성하지 않고 모델에게 자연어로 설명하는 방식(바이브 코딩)이 점차 늘어나고 있습니다.
LLM이라는 매개체를 통해 사람의 의도를 컴퓨터에게 입력하는 것은 사실 새로운 컨셉이 아닙니다. 우리는 항상 코드를 통해 우리의 의도를 컴퓨터에게 전달하고 있었습니다. 개발자가 의도를 담아 코드를 작성하면, 컴파일러가 이를 번역해서 컴퓨터가 수행할 수 있는 기계어로 전환합니다. LLM은 단지 코드를 사람의 언어(자연어)로 확장했을 뿐이라고 볼 수 있습니다.
그렇다면, 여기서 한 가지 고민해볼 점은 지금까지처럼 코드를 보존하고 관리하는 것이 여전히 적절한 방식인지, 아니면 프롬프트나 명세와 같은 인간의 의도를 담은 표현을 중심으로 보존해야 하는지에 대해서입니다.

**사람이 작성한 코드** - [컴파일러] -> 기계어
**사람이 작성한 프롬프트와 명세** - [LLM] -> 코드

이런 논리라면, 컴파일러가 작성한 기계어가 아니라, 의도가 좀 더 명확한 프롬프트와 명세(specification) 를 보존하는 것이 더 타당하지 않을까요?

Sean Grove는 이 프롬프트와 명세를 '모델 스펙' 이라고 정의합니다.

📄 모델 스펙: AI가 이해하는 인간의 언어​

Sean Grove는 앞으로의 소프트웨어 개발에서 가장 중요한 자산은 코드가 아니라 명확한 명세(model spec) 가 될 것이라고 말합니다.

모델 스펙은 다음과 같은 특징을 가집니다:
• Specs compose: 조합 가능하며 모듈화될 수 있습니다.
• Specs are executable: 실행 가능한 명령 구조를 가집니다.
• Specs are testable: 테스트가 가능하며 검증 기준을 포함할 수 있습니다.
• Specs have interfaces: 외부와 소통할 수 있는 인터페이스를 가집니다.

이러한 스펙은 단순한 설명을 넘어서, 사람의 의도를 일관되게 전달할 수 있는 추상화된 형식입니다. 말 그대로 자연어가 새로운 코드(The New Code)인 셈입니다. LLM 시대에는 이 명세가 자연어로 작성되기 때문에, 기존 코드보다도 명확한 의사소통의 도구로 기능할 수 있습니다.

⚖️ 법조 시스템과 스펙 기반 개발의 유사성​

모델 스펙의 개념은 법조 시스템과도 매우 유사합니다.
사회가 사람의 행동을 정렬하기 위해 헌법과 법률을 만들듯, AI 모델 역시 명확한 스펙을 통해 행동을 정렬 하게 됩니다.

• 헌법 · 법률 (written text) → written specification 모델이 따라야 할 기준이 되는 문서. 명확하고 모호하지 않아야 함.

• 개정 조항 (amendments) → pull request / version bump 명세를 업데이트하는 절차. 코드의 버전 관리와 유사.

• 판례 (case law) → regression tests 기존 동작을 유지하는 테스트. 과거의 기준을 반복해서 검증함.

• 사법적 검토 (judicial review) → grader model 모델의 결과물이 명세에 부합하는지 자동 평가.

• 권한 계층 (supremacy clause / hierarchy) → spec hierarchy 명세 간 우선순위를 설정하는 구조. 충돌 방지를 위함.

• 집행 기관 (enforcement by executive) → reinforcement loop 명세에 맞는 행동을 하도록 학습을 유도하는 강화 루프.

이러한 비교는 AI 엔지니어의 역할이 단순한 기술 구현자 를 넘어, AI 시스템의 ‘입법자’ 혹은 ‘정책 설계자’ 로 진화하고 있음을 보여줍니다.

🧭 직업의 본질은 ‘정렬’입니다​

Sean Grove의 스피치는 정렬(alignment) 에 대한 통찰로 마무리됩니다.
우리의 직업은 각기 다르지만, 본질적으로는 ‘무언가를 정렬시키는 일’을 수행 하고 있습니다. 정렬이란 단순히 "일치시키는 것"이 아닙니다. 의도를 명확히 정의하고 최소 법칙 아래에서 구성원들(컴포넌트들)이 자유롭지만 의도한대로 동작할 수 있도록 설계 하는 일 입니다. 아마 이 과정을 얼마나 명확히 할 수 있는지가 미래의 핵심 역량 이 될 것이라고 조심스럽게 예측해봅니다.

역할별 정렬 대상을 정리해본다면 다음과 같습니다.

프로그래머

• 정렬 대상: 컴퓨터(실리콘)
• 정렬 수단: 코드 명세 (code spec)

제품 매니저(PM)

• 정렬 대상: 팀
• 정렬 수단: 제품 명세 (product spec)

법률가

• 정렬 대상: 사회 구성원
• 정렬 수단: 법률 명세 (legal spec)

AI 엔지니어

• 정렬 대상: 인공지능 모델
• 정렬 수단: 모델 명세 (model spec)

20분짜리 짧은 영상이였지만, 많은 내용이 담겨 있어 미처 담지 못한 내용들도 있습니다. 좋은 영상인 것 같아 직접 영상을 보시는 것도 추천드립니다.

MCP란 무엇인가?​

MCP는 대규모 언어 모델(LLM)이 외부 데이터와 시스템을 효과적으로 활용할 수 있도록 설계된 개방형 표준 프로토콜입니다. Anthropic은 MCP를 USB-C 포트에 비유하는데, USB-C가 다양한 기기와 주변 장치를 표준화된 방식으로 연결하듯이, MCP는 AI 모델이 다양한 데이터 소스와 도구에 표준화된 방식으로 연결될 수 있도록 합니다.

MCP의 주요 특징​

1. 개방형 표준: 누구나 자유롭게 사용하고 개선할 수 있습니다.
2. 양방향 연결: AI 모델과 데이터 소스 간의 지속적인 통신을 지원합니다.
3. 범용성과 표준화: 다양한 데이터 소스와 도구를 하나의 프로토콜로 연결합니다.
4. 보안 및 신뢰성: 안전하고 신뢰할 수 있는 연결을 제공합니다.

MCP의 동작 방식​

MCP는 다음과 같은 프로세스를 거칩니다.

1. 연결 설정​

• 호스트 애플리케이션(예: Claude Desktop, Cursor)이 필요한 기능을 가진 MCP 서버에 대한 클라이언트를 생성합니다.

2. 초기화 프로세스​

• 클라이언트가 서버와 연결되면 JSON-RPC 기반 메시지를 통해 프로토콜 버전과 지원 가능한 기능을 확인합니다.
• 이 과정에서 서버의 능력과 제약 사항이 결정됩니다.

3. 기능 탐색​

• 클라이언트는 서버에 tools/list 등의 요청을 보내 사용 가능한 도구, 리소스, 프롬프트 목록을 수집합니다.
• 이 정보는 호스트를 통해 LLM에게 전달됩니다.

4. 요청 처리 과정​

1. 사용자가 호스트에 질문을 입력하면 LLM이 이를 분석합니다.
2. LLM은 적절한 서버와 도구를 선택해 구조화된 요청을 생성합니다.
3. 호스트는 해당 요청을 관련 클라이언트에 전달합니다.
4. 클라이언트는 요청을 서버가 이해할 수 있는 형식으로 변환하여 전송합니다.
5. 서버는 요청된 작업을 수행하고 결과를 반환합니다.
6. 결과는 클라이언트를 통해 호스트로 전달되며, 최종적으로 LLM에게 제공됩니다.

5. 통신 형식​

• JSON-RPC 2.0 프로토콜을 기반으로 데이터 교환이 이루어집니다.
• 텍스트 데이터는 UTF-8 인코딩, 이미지 및 바이너리 데이터는 Base64 인코딩을 사용하여 전송됩니다.

MCP 구조​

MCP는 호스트(Host), 클라이언트(Client), 서버(Server) 세 개의 컴포넌트로 이루어져 있습니다.

1. 호스트(Host)​

호스트는 AI 애플리케이션의 컨테이너이자 조정자 역할을 합니다.

호스트의 주요 역할​

• 여러 클라이언트 인스턴스를 생성하고 관리
• 클라이언트 연결 권한과 생명 주기 제어
• 보안 정책과 동의 요구사항 시행
• AI/LLM 통합 및 샘플링 조정
• 대화 컨텍스트 관리 및 클라이언트 간 컨텍스트 집계

2. 클라이언트(Client)​

클라이언트는 호스트에 의해 생성되며 서버와의 독립적인 1:1 연결을 유지합니다.

클라이언트의 주요 역할​

• 서버당 하나의 상태 유지 세션 설정
• 프로토콜 협상 및 기능 교환 처리
• 양방향으로 프로토콜 메시지 라우팅
• 구독 및 알림 관리
• 서버 간 보안 경계 유지

3. 서버(Server)​

서버는 특정 컨텍스트와 기능을 제공하는 독립적인 프로그램입니다.

서버의 주요 역할​

• 리소스, 도구, 프롬프트 등의 기능 노출
• 독립적으로 작동하며 특정 책임 수행
• 클라이언트 인터페이스를 통해 샘플링 요청 처리
• 보안 제약 준수
• 로컬 프로세스 또는 원격 서비스로 구현 가능

클라이언트가 서버를 호출하는 방식​

1. stdio 방식 (표준 입출력)​

• 클라이언트가 서버를 하위 프로세스로 실행합니다.
• 서버는 표준 입력(stdin)으로 명령을 받고 표준 출력(stdout)으로 응답합니다.
• JSON-RPC 2.0 형식으로 메시지를 주고받습니다.
• 로컬 환경에서 설정이 간단하고 빠르게 실행 가능합니다.

2. HTTP+SSE 방식 (Server-Sent Events)​

• 클라이언트는 HTTP POST 요청으로 명령을 서버에 보냅니다.
• 서버는 SSE(Server-Sent Events)를 사용하여 클라이언트에게 응답이나 이벤트를 스트리밍합니다.
• 웹 애플리케이션 및 분산 시스템에서 유용합니다.

마무리​

MCP는 AI 모델이 외부 데이터와 도구에 접근할 수 있는 표준화된 방법을 제공함으로써 AI 애플리케이션의 가능성을 크게 확장시키고 있습니다. 호스트, 클라이언트, 서버로 구성된 아키텍처는 복잡한 시스템을 효율적으로 관리할 수 있도록 돕습니다.

• 리눅스 설치
• ssh 설치
• 서버용 설정
• docker-registry 설정
• github-action runner 설정
• 쿠버네티스 환경 구성

리눅스 설치​

macos의 버젼이 오래 돼서 도커 데스크탑 설치가 안 된다. os를 업데이트하려고 했지만, 왠지 모르는 이유로 소프트웨어 업데이트 버튼 클릭 시, 무한로딩에 걸려버려서 리눅스를 설치했다.

ssh 설치​

다음은 외부에서 홈서버의 콘솔에 접속할 수 있도록 ssh를 설치한다. ssh는 컴퓨터 간 암호화되어 안전한 통신을 가능하게 해주는 프로토콜이다. ssh에 대해 처음 들어본다면, 검색해보자. 자세히 잘 설명해준 글들이 많다.

id_rsa를 발급받고 id_rsa.pub을 서버에 심는다. 그리고, 공유기 관리자 페이지에서 포트 포워딩을 해준다.
이제 외부에서 로컬 서버로 접속이 가능하다.
현재는 내부 네트워크에서 접속하는 거지만, 외부에서 접속하고 싶다면, 마찬가지로 ssh key를 발급받고, 서버에 심은 다음, 이전 글에서 설정한 dDNS 주소로 접속하면 된다.

서버용으로 노트북 설정 변경하기​

이 노트북은 24/7 돌아가기에 적합한 서버용은 아니지만, 필요한 설정들을 해주자. 절전 모드를 비활성화하고, 덮개가 닫혀도 돌아갈 수 있도록 설정한다.

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

이제 이 서버(노트북이였던)는 더 이상 절전모드에 들어가지 않는다. 그리고 이어서 노트북 덮개를 덮어도 꺼지지 않도록 설정한다. etc 디렉토리의 logind.conf 에 들어가서 그림 아래 두 설정들을 ignore로 바꿔준다.

sudo nano /etc/systemd/logind.conf

노트북이 덮여도 꺼지지 않도록 구성한다.

그리고 서버가 재부팅되었을 때, 시작할 프로그램들을 설정해준다.

systemd 서비스에 직접 등록하거나, systemctl enable [your-service]로 설정할 수 있다. 나는 docker registry와 github action runner가 자동으로 시작되도록 설정했다.

docker-registry 구성​

다음은 docker-registry 구성했다. docker-registry는 도커 이미지 저장소이다. docker-registry를 처음 들어봤다면, AWS의 ECR이나 dockerhub를 생각하면 된다. 도커 컨테이너로 docker-registry를 띄우고, 컨테이너가 내려가도 이미지들은 그대로 저장되어 있을 수 있도록 volume을 지정해두었다.

github action runner 구성​

그리고 github action runner를 local-hosted runner로 구성했다. github action은 CI/CD를 무료로 제공하는 편리한 서비스다. github action은 기본적으로 github에서 제공하는 runner를 사용하는데, 이 runner는 무료인만큼 속도가 비교적 느리다는 단점과 따로 캐시를 설정하지 않는다면, 매번 CI/CD에 설정된 빌드 과정을 처음부터 실행하여 시간이 오래 걸린다는 단점이 있다. 이 또한, 설정하는 방법은 github action 페이지의 local-hosted runner 섹션에 친절히 설명되어 있으므로 자세한 과정은 생략한다.

github action 페이지에 local-hosted runner를 프로젝트별로 설정해야하길래, 나는 Organization을 만들어 사이드 프로젝트들을 다 옮기고, 이 organization을 관리하는 local-hosted runner로 등록했다.

쿠버네티스 환경 구축하기​

쿠버네티스가 과연 필요한가?​

마지막은 대망의 쿠버네티스 환경 구축이다. 사실 이 부분은 환경적으로 정말 필요해서라기보다는 쿠버네티스 운영을 맛보고 싶어서다.

보통 쿠버네티스 환경 구성은 최소 3개의 마스터 노드와 여러 개의 워커 노드들로 이루어져있다. 나는 단지 맥북 하나 있을 뿐이고, 이 환경이 얼마만큼의 부하를 견딜 수 있을지도 모른다.

그리고 쿠버네티스의 기능은 컨테이너 오케스트레이션, 즉 여러 개의 컨테이너들을 한 번에 관리하는 것이다.이 여러 개의 컨테이너가 필요한 이유는 서버가 받는 트래픽을 분산시키기 위해서(또는 아키텍쳐 구성상 예를 들면 MSA)인데, 내가 진행하고 있는 사이드 프로젝트들 중에서 서버량이 여러 개의 인스턴스가 필요할 정도의 트래픽은 있는 건 아니다.

정리하자면 노드도 한 개이고 서비스 규모도 크지 않아서 쿠버네티스의 필요성은 의문이다. 하지만, 뭐 이렇게 시간이 남아돌 때 해봐야지 언제 해보겠나. 간단한 서비스를 띄워보고, 실제 트래픽이 많은 서비스 구성과는 어떻게 다를지 가늠하는 식으로 진행해보자.

쿠버네티스를 어떻게 구성하면 좋을까?​

쿠버네티스에는 여러 종류의 배포판이 있다. 단일 노드 환경에 적합한 경량화된 쿠버네티스 배포판에는 minikube, k3 , kind 등이 있는데, 그 중에 k3를 선택했다. k3를 선택한 이유는 상태와 구성 정보를 저장하는 키-값 저장소인 etcd 대신 sqlite3를 사용하여 리소스를 절약할 수 있기 때문이다. minikube와 kind는 etcd를 사용한다. 우리는 단일 노드를 사용하기 때문에 etcd의 분산 시스템이 필요가 없다.

내 서버는 i5-7360U, cpu 4코어, 8gb RAM, 228gb 디스크를 가지고 있다. 이 노드 안에서 구성을 어떻게 할지 고민됐다.

서버 안에 가상 머신으로 노드들을 몇 개 구성하면, 좀 더 실제와 가까운 쿠버네티스 셋팅을 맛볼 수 있을 것 같다는 생각이 들었다. 예를 들어, taint나 tolerate 같은 노드 라벨링, 노드 간의 네트워크 통신 설정, 드레이닝이나 코든 같은 노드 유지보수 과정들을 실습해볼 수 있을 것 같다.

하지만 결과적으로는 가상 머신으로 분리하지 않고, 단일 노드에서 마스터 노드가 워커 노드 역할을 겸하는 구성으로 가기로 했다. 왜냐하면, 첫번째로 가상 머신을 여럿 띄울만큼의 리소스가 없다는 점. 그리고 두번째로 마스터 노드와 워커 노드의 분리 목적이 애초에 클러스터의 안정성을 위해서라는 점에서, 가상머신을 띄운 맥북이 다운되면 노드 전부가 꺼져버릴 게 당연하기 때문이다.

앱을 띄워보자​

이 단일 노드에 쿠버네티스에 띄울 앱과 상태를 적은 쿠버네티스 manifest를 작성했다. 최대한 간단하게 앱을 구성했다. fastapi, react, mysql, 그리고 nginx로 돌아가는 앱이다. 이름을 등록하면, '이름 hello world'를 리턴하는 간단한 앱이다.(코드는 여기)

이 앱은 이름도 프린트해준다!

그리고 k8s에 올리기 위해 필요한 manifest들을 작성한다. 앱의 라벨링을 담당할 namespace, 각 요소(backend, frontend, nginx)의 deployment와 서비스, 그리고 각종 config들을 담을 configmap과, secret, 그리고 요청의 라우팅을 처리해줄 ingress(이쪽은 손을 더 봐야할듯)를 작성한다. 이후에는 self-hosted runner에서 돌아갈 workflow를 작성해준다. (몇 문장으로 정리가 가능하지만, 이 과정에 거의 세시간 정도 소요된 것 같다…) 드디어 이제, 로컬 서버 쿠버네티스에서 실행되는 앱을 확인할 수 있다….!

이번 시간에는 홈 서버에 작성한 앱을 배포하기 위한 배포 환경을 구성했다.

양이 생각보다 길어져서 다음 편으로 이어서 쓰겠다. 다음 편에는 이 앱을 가지고, 여러 설정을 추가(ingress 설정, 파드 증설 등)하고 실험을 해보면서 모니터링을 해보려고 한다.

이 맥북을 서버로 사용하기 위해 필요한 작업을 크게 세가지로 정리했다.

1. 서버 셋팅
2. 외부에서 접속 가능하도록 네트워크 설정
3. 앱 배포

서버 셋팅과 앱 배포 부분은 우선 네트워크를 구성해놓은 후 천천히 진행해도 될 것 같아서, 이번 글에서는 2번 네트워크 설정한 후기에 대해서 적어보려고 한다.

진행 방식은 다음과 같다.

1. 홈 네트워크 구성 파악하기
2. 외부 IP와 내부 IP 파악하기
3. DHCP 서버에서 고정 IP 할당받기
4. 포트 포워딩하기
5. dDNS 등록하기

홈 네트워크 구성 파악하기​

우선 맥북이 연결된 네트워크의 구성을 파악할 필요가 있었다.

네트워크 구성을 살펴보면 이렇게 그림으로 정리될 수 있다.

외부 IP와 맥북 IP 파악하기​

외부에서 바라보는 내 네트워크(맥북이 연결된)의 공인 IP를 우선 파악한다.

이렇게 되면

ip.pe.kr에 접속하면 내 공인 IP를 확인할 수 있다.

그리고 이제 맥북의 IP를 파악해야한다. 공유기 관리자 페이지(?)에서 확인할 수도 있고, ifconfig 를 통해 확인할 수도 있다.

DHCP 서버에서 고정 IP 할당받기​

지금 맥북 주소는 공유기의 DHCP 서버로부터 할당받은 동적 IP이기 때문에, 공유기 관리자 페이지에서 DHCP 서버가 이 맥북에게 고정 IP를 제공할 수 있도록 설정해줘야 한다.

포트 포워딩하기​

맥북에서 실행되는 앱을 외부에서 접근할 수 있도록 하려면, 포트 포워딩이 필요하다.

실제로 앱이 접속가능한지 테스트해보기 위해 간단한 fastapi 앱을 작성해준다.

그리고, 공유기 관리자 페이지에서 외부에서 해당 포트로 접속했을 경우 맥북 IP의 로컬 포트로 연결받을 수 있도록 설정을 추가해준다.

그럼 이제 외부 IP의 8000번 포트로 접속이 성사되는 걸 확인할 수 있다.

dDNS 등록하기​

마지막으로 한가지 문제가 남았다.

맥북은 와이파이를 통해 연결이 되고, 가정용 인터넷 서비스는 대부분의 경우 동적 IP를 할당한다.(고정 IP를 할당받기 위해서는 추가적인 비용이 필요하다.) 왜 동적 IP를 할당하냐면, 인터넷 서비스 업체들(ISP)이 수익을 최대화하기 위해서라고 할 수 있다. 접속을 끊은 사용자들의 IP는 거둬들이고, 접속한 사용자들에게 다시 할당하는 방식으로 한정된 IP주소들을 최대한 활용하는 방법이다.

외부에서 계속해서 바뀌는 동적 IP 주소를 접근하도록 하기 위해서는 동적 DNS가 필요하다. DNS(Domain Name System)는 서버의 이름과 IP를 매칭해서 관리하는 시스템이라고 보면된다. 서버의 이름을 설정해놓고, 서버에 DNS가 제공하는 소프트웨어를 설치해놓으면 지속적으로 변경되는 IP를 DNS에서 추적해서 업데이트해준다. (무료로 DNS를 활용할 수 있는 사이트들이 있다.)

나는 noip.com이라는 사이트를 이용했다. 내 공인 IP와 hostname을 매칭해서 설정해준다.

이제 dDNS에서 할당받은 hostname으로 맥북에 실행시켜둔 앱이 정상적으로 동작하는 걸 확인할 수 있다.

마무리​

이렇게 외부에서 접근가능한 개인서버의 네트워크 설정이 완료되었다. 이 맥북 프로를 팔았을 때 중고가격(서버로 운용한다면 사용가능한 수명이 확 떨어지지 않을까…), 24시간 운용했을 때 발생하는 전기비 등 클라우드 서비스 비용과 비교해봤을 때 개인 서버 운용이 과연 경제적인가 하는 질문에 대해서는 좀 더 지켜봐야겠지만, 서버를 구성하면서 나름 네트워크 공부도 하고 나만의 서버를 구성한다는 것 자체가 즐거웠다.

정상적으로 동작하긴 하지만, 아직 추가할 부분들이 많다. 도메인 구매, SSL설정, 도커 레지스트리 구성, CI/CD 설정 그리고 쿠버네티스 환경 구성, 모니터링, 백업 설정 등 앱 올려보면서 진행해보려고 한다. 다음 글은 여기에서 확인 가능하다!

내가 월간 데이터노트에 참여하게 된 계기​

참여중인 개발자 글쓰기 모임(글또)에서 월간 데이터노트 홍보글을 봤다.

월간 데이터노트는 호기심을 데이터로 구현하여 1-2장의 결과물을 기록하는 모임이다. 예를 들어, 계절별 과일 가격은 추석이나 설날 같은 명절에 어떻게 변동하는지 추적하거나, 한강의 노벨문학상 수상을 통해 종이책 구매량은 어떻게 변했는지와 같은 일상 주제들을 데이터로써 분석해볼 수 있다.

예전부터 자주 이런 일상 주제들에 대해서 머릿속으로 나름의 가설을 세우고, 증명하기 위해서는 어떤 데이터들이 필요할지 상상해보곤 했다. 예를 들어, 퇴근시간과 같이 교통량이 몰리는 시기에 신호 패턴이 어떤 식으로 바뀌는지, 그에 따른 영향은 어떤 식으로 수치화할 수 있는지와 같은 상상.. 그래서 이런 상상을 직접 데이터를 수집해보고 결과물을 뽑아보는 실천으로 옮겨보면 재밌을 거라는 생각에 참여하게 되었다.

분석 주제 및 목적​

• 초등학교 시절 자주 하던 메이플스토리. 그 시절 메이플스토리가 최근에 다시 ‘메이플랜드’ 라는 이름으로 런칭되었다. 반가운 마음에 유튜브에 뜬 메이플스토리 플레이 영상을 보다보면 아련한 옛 추억에 잠기곤 한다.

• 찾아보니 게임머니를 현금처럼 사용하고, 아이템을 구매하기 위해 적지 않은 금액을 기꺼이 지불하는 걸 알게 되었다.

• 아이템 매니아(25.01.09) 기준 현재 100만메소당 5000-9000원 정도의 가격에 거래되는 것을 확인할 수 있다. 정말 비싼 아이템은 몇백만원에 거래되기도 한다.

• mapleland.gg같은 사이트에 팝니다, 삽니다 정보를 알아보기 쉽게 정리되어있다.

  

분석 결과​

“아이템 시세에 영향을 미치는 요소에는 뭐가 있을까?”

• 시세를 어떻게 측정할 수 있을까?

  매수희망 가격을 내림차순, 매도희망 가격을 오름차순으로 정렬함.

  파는 사람은 최대한 비싸게, 사는 사람은 최대한 싸게

  순서대로 매수/매도 금액을 매칭하여 거래가 성사될 수 있는 건들에 대한 평균값을 시세로 측정.

  

  업그레이드 없는 순정 레드 크리븐을 기준으로 시세는 2억 4889만 메소로 형성 되어있음.

  *발표 후 질문 중에 ‘실제 성사된 거래 내역을 확인해볼 수도 있을까요?’라는 질문에 깨닫게 되었는데, 시세를 확인하기 위해 먼저 고려해볼 부분은 실제 거래가 성사된 내역이라는 걸 간과하고 있었다.

• 어떤 아이템의 시세를 살펴보면 좋을까?

  현시점(2025-01-25) 직업군 중 가장 쎈 도적의 엔드 아이템(가장 좋은 아이템) 레드 크리븐

  옵션이 좋은 매물을 기준으로 5억 메소에 매수가가 형성되어 있음. 5억 메소는 자그마치 현금 450만원(100만 메소=9000원 가정)

  

• 아이템 스탯별 시세의 상승률을 시각화해보자

  

  • 메이플랜드에는 “주문서” 시스템이 있음. 주문서를 사용해서 아이템의 스탯을 업그레이드할 수 있는 시스템임

  • 아이템에는 보통 업그레이드횟수가 7번 정도 주어짐.

  • 주문서는 성공 확률에 따라 10%, 60%, 100%로 나뉘는데, 성공확률이 낮을수록 업그레이드할 수 있는 스탯 비중이 높아짐.

  • 공격력별 성공확률 시각화

    

  • 공격력별로 매수/매도 데이터를 그룹화한 후, 시세를 구한다.

  

  === 시세 분석 ===
  공격력과 시세의 상관계수: 0.776
  매도 있는 최대 공격력: 12
  매수 있는 최대 공격력: 18
  
  === 공격력 구간별 가격 상승률 ===
  공격력 3 → 4: 0.0%
  공격력 4 → 5: 122.2%
  공격력 5 → 6: 80.0%
  공격력 6 → 7: 144.4%
  공격력 7 → 8: 11.4%
  공격력 8 → 90: 69.4%
  공격력 9 → 10: 137.3%
  공격력 10 → 11: 39.1%
  공격력 11 → 12: 9.5%
  공격력 12 → 13: 216.7%
  공격력 13 → 14: 47.4%
  공격력 14 → 15: 42.9%
  공격력 15 → 16: 6.1%
  공격력 16 → 17: 88.6%
  공격력 17 → 18: 75.0%
  

진행하면서 배우게 된 것/ 더 보충할 수 있을 것 같은 부분​

• 분석면에 있어서 한 문장으로 정의내릴 수 있는 명확한 결론은 나지 않은 것 같다.
• 시세를 어떻게 정의내릴지에 대해 알아본 것은 유용했다.
• 업그레이드 수준에 따른 시세 변화 같은 경우에 결론은 결국 ‘업그레이드가 잘 될 수록 시세는 비싸진다’ 정도에서 그친 것 같아서 좀 아쉽다. 업그레이드 횟수와 성공확률에 따라 ‘기회비용’이 얼마정도 되는지(과연 추가로 주문서 작을 하는 게 나을지에 대한 판단을 위한 수치)와 같은 분석을 추가로 진행하면 좋을 것 같다는 생각이 들었다.
• 한 아이템에 대해서만 분석을 진행했는데, 크롤링 범위를 전체 아이템 또는 API 형식으로 확장하고 범용적으로 분석이 가능한 대쉬보드를 작성한다면 좀 더 유용한 결과물이 될 수 있을 것 같다는 생각이 들었다.

데이터출처 & 코드

• mapleland.gg - 셀레니움으로 크롤링(코드는 chatGPT로 작성)

django를 학습 중이다. django에서는 웹 서비스 개발에 필요한 편리한 도구들을 제공한다. 그 중 Signal은 이벤트 기반 아키텍쳐에서 강력한 도구로 활용될 수 있다. 이번 글에서는 Django Signal이란 무엇인지, 어떻게 동작하는지, 그리고 어떤 상황에서 Signal을 사용하는 것이 적절한지에 대해 심층적으로 알아보려고 한다.

Signal이 뭔가요?​

signal은 django 시스템 실행 중 이벤트가 발생했을 때 실행되는 콜백 메커니즘이다. 이 시그널은 이벤트를 알리는 publisher와 알림을 받는 subscriber로 이루어진 pub/sub 구조를 통해 동작한다. publisher가 이벤트의 특정 동작 시점을 알리면, 대기하고 있던 subscriber는 그에 맞춰서 필요한 동작들을 수행한다. 이 pub/sub 구조의 장점은 느슨한 결합을 유지할 수 있다는 점인데, 예를 통해 어떤 의미인지 살펴보자.

Pub/Sub 구조​

신호등이 없는 나라에 새로 부임받은 교통경찰이 있다. 이 교통경찰은 차량들이 지체없이 통행할 수 있도록 해야한다. 이 교통경찰은 지나가는 차량들을 일일이 붙잡고 멈춰야할 시점과 출발해야하는 시점을 알려준다. 열심히 뛰어다녔지만 혼자서는 버겁다. 그리고 간혹 말이 통하지 않는 외국인이 있는 경우에는 정보 전달을 위해 더 많은 시간이 걸렸다. 차량 퇴근시간이 되어 차량이 많아지자, 교통경찰 혼자서 차량들을 통제하는 일은 점점 더 버거워졌고, 결국은 3중 추돌 사고가 나고 말았다.

이렇게는 안 되겠다 싶었던 경찰은 신호등을 설치하기로 마음먹는다. 빨강, 노랑, 초록 싸인에 대한 설명 글귀를 큼지막하게 적어 운전자들이 확인할 수 있도록 하고, 차량들이 신호등의 신호에 따를 수 있도록 통제했다. 색깔 사인은 언어가 달라도 이해할 수 있었기 때문에 외국인도 별 무리 없이 운전이 가능했다. 만약 신호등 통제를 따르지 않는다면, 벌금을 부과하도록 단속했다. 이제 모든 차량들이 신호등의 신호에 집중해서 악셀을 밟을지 브레이크를 밟을지 결정했고, 교통 경찰은 더 이상 차량들을 하나하나 통제하지 않아도 됐다.

이 스토리에서 교통경찰이 일일이 차량을 통제하는 건 강한 결합, 그리고 신호등을 통해 통제하는 건 느슨한 결합이라고 볼 수 있다. SRP 원칙에 따라 한 앱(모델 또는 앱)은 자신이 맡은 역할만 수행하는 게 기본적이지만, 로직상 다른 앱의 처리과정과 연관되어 있을 경우도 자주 발생한다. (예를 들어 온라인 쇼핑몰에서 상품 결제 처리 시 재고 처리, 결제 처리, 알림 처리 등이 동작해야한다.)

pub/sub 구조는 로직을 같은 컨텍스트 안에 작성하여 강하게 결합된 코드를 만드는 대신, ‘분리되어야하는 동작을 발동시키는 로직’을 ‘이벤트’로 정의하고 큐에 넣어서 처리한다. 이렇게 하면, 모델은 본 컨텍스트에 관련된 로직만 처리하고, 신호등과 같은 역할인 큐에서 컨슈머들(차량)이 알아서 가져가서 처리할 수 있도록 할 수 있다. 퍼블리셔는 자신의 행동 외에 컨슈머가 어떤 행동을 할지에 대해서 모르고, 컨슈머도 발생한 이벤트에 맞춰 자신이 어떤 행동을 해야할지만 알 뿐이다.

정리하자면, signal을 사용함으로써 얻을 수 있는 이점은

“독립적인 컴포넌트들이 독립적으로 구분되어 서로를 모르고 동작할 수 있도록 한다.”

한 가지 주의할 점은 일반적인 pub/sub 구조는 publisher와 subscriber 가운데에 queue 또는 broker를 두어 느슨한 결합을 이루지만, django signal 같은 경우 따로 queue없이 publisher, 즉 signal 자체가 브로커 역할을 한다는 점이다.

django에서 signal을 사용하는 대표적인 예는 유저 정보를 처리할 때다. django에서 제공하는 User 모델로는 충분한 정보를 담지 못 하기 때문에 일대일 대응되는 UserProfile 같은 모델로 추가 정보를 담는 경우가 일반적인데, User 생성시에 UserProfile도 함께 생성될 수 있도록, User 생성 이벤트에 UserProfile이 생성되는 시그널을 만들어 처리한다.

@receiver(post_save, sender=User) 
def create_user_profile(sender, instance, created, **kwargs):
	if created:
		UserProfile.objects.create(user=instance)

receiver 데코레이터는 아래 함수가 이벤트 콜백 함수임을 명시하고, 어떤 이벤트에 동작하는지 정의한다. create_user_profile이 User 모델의 post_save 시에 동작하는 콜백함수인 것을 확인할 수 있다.

signal 종류​

이벤트 종류에 따라 시그널 종류가 나뉜다.

크게 ORM관련, Request와 Response 사이클 관련, Authentication 관련, 그리고 데이터베이스 연결, 테스트, 매니지먼트(manage.py 실행 관련), Admin관련, 미들웨어 관련 등으로 나눌 수 있다. 다양한 종류들이 존재하지만, ORM, Request/Response, 그리고 Authentication 관련 시그널이 많이 쓰인다고 볼 수 있다. pre, post와 같이 세부적으로 이벤트 시점 조정이 가능하고, 필요하다면 Custom Signal을 만들어 특정 이벤트에 동작할 수 있도록 구성할 수도 있다.

아래 표를 통해 어떤 signal 종류가 있는지 알아보자.

ORM 관련

Request/Response 관련

Authentication 관련

어떤 식으로 사용할 수 있나요?​

1. Decorator 방식 (@receiver 사용)

가장 일반적이고 권장되는 방식이다.

# signals.py
from django.db.models.signals import post_save
from django.dispatch import receiver
from django.contrib.auth.models import User

@receiver(post_save, sender=User)
def user_created_signal(sender, instance, created, **kwargs):
    if created:
        print(f'New user created: {instance.username}')

1. connect 메서드 사용하기

python
# signals.py
from django.db.models.signals import post_save
from django.contrib.auth.models import User

def user_created_signal(sender, instance, created, **kwargs):
    if created:
        print(f'New user created: {instance.username}')

post_save.connect(user_created_signal, sender=User)

차이점:

• connect는 동적으로 Signal을 연결할 수 있다.

c. Custom Signal 만들기

python
코드 복사
# signals.py
from django.dispatch import Signal

# Signal 정의
order_completed = Signal()

# Signal 수신기
def notify_order_completed(sender, **kwargs):
    print(f"Order completed for: {kwargs['user']}")

# Signal 연결
order_completed.connect(notify_order_completed)

# Signal 발행
order_completed.send(sender=None, user='John Doe')

그럼 signal은 디렉터리 구조 중 어디에 위치하는 게 좋을까?

일반적으로 다음과 같은 구조를 사용한다.

myapp/
├── __init__.py
├── models.py
├── views.py
├── signals.py   <-- Signal 정의
├── apps.py      <-- Signal 등록
└── admin.py

(apps.py에 시그널을 등록해야만 활성화된다는 점도 잊지말자)

# apps.py
from django.apps import AppConfig

class MyAppConfig(AppConfig):
    default_auto_field = 'django.db.models.BigAutoField'
    name = 'myapp'

    def ready(self):
        import myapp.signals  # Signal import

어떻게 동작하나요?​

signal의 동작 방식은 생각보다 단순하다. django.dispatch.dispatcher.py의 Signal의 connect 함수를 통해 확인 할 수 있다.

with self.lock:
    self._clear_dead_receivers()
    if not any(r_key == lookup_key for r_key, _, _ in self.receivers):
        self.receivers.append((lookup_key, receiver, is_async))
    self.sender_receivers_cache.clear()

lock이 걸린 상태에서 connect함수가 호출될 경우, Signal 인스턴스에 정의된 receivers를 순회하며 해당 signal에 대해 어떻게 반응해야할지 찾는다. 그리고 기본값으로 설정되어 있는 weak=True는 receiver가 호출 후, garbage collector에 의해 수거되어 메모리를 낭비하지 않아도 될 수 있도록 약한 참조를 할 수 있게 돕는다.

if weak:
    ref = weakref.ref
    receiver_object = receiver
    # Check for bound methods
    if hasattr(receiver, "__self__") and hasattr(receiver, "__func__"):
        ref = weakref.WeakMethod
        receiver_object = receiver.__self__
    receiver = ref(receiver)
    weakref.finalize(receiver_object, self._remove_receiver)

어떨 때 사용하면 좋을까요?​

장점과 단점을 알고 상황에 맞게 사용하는 것이 중요하다. 위에서 언급한 것처럼 signal을 사용하면서 얻을 수 있는 장점은 느슨한 결합이다. 책임이 분리되어있기 때문에 코드가 깔끔해지고, 유지보수가 쉬워진다는 장점이 있다. 하지만 물론 단점도 있다. 코드 흐름을 알기 어렵다. two scoops of django 책에는 “그러므로 시그널을 받는 리시버가 어떤 것인지조차 알 필요가 없는 경우라면 그 때 시그널을 활용하라”라는 조언이 있다. 그리고, signal은 “동기화되고 블로킹을 일으키는 무거운 프로세스를 호출한다. 확장과 성능 면에서 어떤 장점도 찾아볼 수 없다”라는 단점이 있기도 하다. 그러므로 signal을 과도하게 사용하기보다는 정말 필요한 경우에만 사용하도록 하고, 무거운 작업일 경우, celery를 사용하는 등 비동기 처리로 옮기는 게 더 바람직하다.

Outro​

이번 글에서는 django Signal에 대해 알아보았다. signal이 어떤 장점을 가지고 있는지, 어를 통해 어떤 기능을 구현할 수 있는지, 그리고 어떻게 동작하는지와 언제 사용하면 적합한지에 대해 살펴보았다. 모쪼록 django를 공부하는 분들께 도움이 되었으면 좋겠다.

2024년이 끝나간다. 연초에 이루고 싶은 여러 목표들을 적어두었었는데, 그 중 하나는 '오픈소스 기여하기'였다. 미루고 미루다가 24년이 얼마 안 남은 시점에 그 목표를 시도해보려고 한다. 전에 해본 적이 없으니 어디서부터 시작해야할지 막연한 마음이 컸고, 이런 오픈소스 기여같은 작업은 뭔가 대단한 작업이라 내가 할 수 있을까 하는 생각 때문에 미루게 된 것 같은데, 우선 해보는 게 중요하지 않을까. 이번 글은 그래서 PR을 제출하는 과정에 있어서 어떤 생각의 흐름을 가지고 진행했는지에 대해서 써보았다.

오픈소스란?​

소스 코드가 공개되어 있어 누구나 자유롭게 사용, 복사, 수정, 배포할 수 있는 소프트웨어를 말한다. 오픈소스의 장점은 모두에게 수정할 기회가 열려있다보니, 코드에 대해서 활발하게 의견 교류가 이뤄지고, 더 좋은 코드로 발전할 가능성이 높아진다는 점이다. 오픈소스 코드 작성에 기여하면서 얻을 수 있는 점은 다른 개발자들의 코드를 읽고 배우면서 개발 실력을 기를 수 있다는 점이다.

오픈소스 기여 팁​

본격적으로 시작하기 전, 오픈소스 기여 관련 다양한 자료를 얻을 수 있었다. 다음과 같은 조언을 얻었다.

• 어떤 오픈소스를 고를 것인가? => 대단한 게 아니여도 된다. 비교적 코드가 복잡하지 않은 리포지토리부터 시작해보자
• 시작을 어떻게 하면 좋을까? => 자주 사용하는 라이브러리 또는 프레임워크
  => 리포지토리의 이슈 항목을 살펴보자. 보통 오픈소스는 컨트리뷰트를 어디서부터 시작하면 좋을지 안내하는 good first issue 라벨이 있다.
  => 전체 코드를 한 번에 이해하려 하지 말고, 관심있는 컴포넌트를 하나 선택해서 거기서부터 시작하는 게 좋다.
• 어떻게 코드를 읽어야할지? => 우선 README부터 읽기
  => 시작 포인트를 찾아서 거기서부터 타고들어갈 것
  => 한줄 한줄 다 읽어볼 것
  => 리포지토리의 TODO 부분을 확인하고 기여할 수 있는 부분을 확인해볼 것
  => 테스트 코드 활용하기
  => 코드를 읽다가 이해가 안되는 부분이 있다면, 관련 PR을 찾아보는 것도 방법
  (배두식님의 PyCon KR 2023 오픈소스와 함께 성장하기를 참고했다.)

오픈소스 선정하기​

위 팁들을 기반으로 요새 사용중인 웹 프레임워크인 django의 라이브러리 중 django-faker라는 라이브러리에 기여해보기로 마음먹었다.
django-faker는 django model의 값들을 랜덤으로 생성해주는 역할을 한다.
로직이 자료형에 알맞는 랜덤값만 생성하면 된다는 점에서 코드 파악을 위한 피로감이 다른 리포지토리보다 덜 하지 않을까하는 생각이 들었다. 한 가지 문제는 마지막 update가 2016년... 무려 8년전... 거의 업데이트가 더 이상 없는 라이브러리라는 점이였다. 하지만, 목표가 '오픈소스 기여하기'인만큼 이 또한 좋은 경험이 될 거라는 생각이 들었다. PR에 대한 피드백이 늦을 수 있다는 점만 감안하면 될 듯 했다.

코드 파악하기​

README.md를 우선 한 번 훑었다. README에는 어떻게 모듈을 사용할지에 대한 예제가 있어서 이해가 조금 더 수월해졌다. 그리고 테스트 코드를 보면서 어떻게 동작하는지 파악할 수 있었다. django-faker는 django Model의 field 타입을 예측하는 Guessor, 타입에 맞춰 값을 랜덤하게 생성하는 Generator, 생성한 값의 포맷팅을 담당하는 Formatter, 모델에 생성한 랜덤값을 주입하는 Populator로 이루어져 있다. 이에 맞춰서 테스트 코드도 각 부분들을 테스트하는 것을 확인할 수 있었다.

기여 목표 선정하기​

django-faker는 업데이트된지 꽤 오래되었다. 하지만 해당 모듈이 의존하는 django와 faker는 계속 업데이트가 이뤄지고 있었다. 그래서 django-faker가 현재 버젼이 커버하지 못하는 새로운 django의 model field들이 있을 거라고 가정을 세우고, 이 부분에 코드를 추가해보기로 마음먹었다. 그리고 다음과 같이 목표를 세웠다.

• django-faker에서 정해놓은 PR checks를 우선적으로 통과할 것.
• 메인테이너 또는 오너가 내가 올린 PR을 merge시켜주는 것. (워낙 오래된 라이브러리라 리액션이 늦게 돌아올 수도 있지만, 우선은 해보자)

기여할 부분 찾기​

우선 보통 기여할 부분을 찾는 방법은 이슈를 살펴보거나, 모듈 사용중에 불편함을 겪은 부분에 대해 개선방법을 제시하는 식으로 진행한다는 점을 기억하자. (우리는 전략적으로 django-faker가 업데이트가 오랫동안 이뤄지지 않았다는 점을 이용하는 거다.) django-faker의 마지막 업데이트 일자인 2015년을 기점으로 django에는 어떠한 모델 관련 업데이트가 있었는지 확인해보았다.(https://docs.djangoproject.com/en/5.1/releases/) 여러 변경사항들중에 2.0을 기준으로 시간 간격을 저장하는 DurationField 필드가 추가된 것을 확인할 수 있었다! 우선 내 계정으로 리포지토리를 fork하고 로컬에 clone했다.

실제로 django-faker가 DurationField를 처리하지 못하는지 확인할 필요가 있었기 때문에, DurationField를 사용하는 모델을 하나 만들고, 테스트 코드를 작성해준다.

class GamePlayTime(models.Model):
	game = models.ForeignKey(Game, on_delete=models.CASCADE)
	player = models.ForeignKey(Player, on_delete=models.CASCADE)
	duration = models.DurationField()

class TestDurationField(unittest.TestCase):
	def testGamePlayTime(self):
		generator = fake
		populator = Populator(generator)
		populator.addEntity(Game, 10)
		populator.addEntity(Player, 10, {
		'game': lambda x: Game.objects.order_by('?').first()
		})
		populator.addEntity(GamePlayTime, 10, {
		'game': lambda x: Game.objects.order_by('?').first(),
		'player': lambda x: Player.objects.order_by('?').first()
		})
		insertedPks = populator.execute()
		self.assertEqual(len(insertedPks[GamePlayTime]), 10)

테스트가 django-faker에서 발생하는 AttributeError로 테스트를 통과하지 못 하는 걸 확인했다.

새로운 코드를 반영하기 위한 브랜치를 생성한다. 브랜치 이름은 나름 비장하게 eature/enhance-django-support 그리고, 테스트 코드를 통과하기 위해 FieldTypeGuesser에 DurationField를 처리할 수 있도록 코드를 추가해주었다. (django와 faker의 버젼에 맞춰 코드를 업데이트해줄 필요가 있었는데, 이 부분에서 의외로 시간을 많이 사용했다.)

이렇게 작성한 코드를 바탕으로 테스트를 다시 실행시켜준다.
테스트를 잘 통과한다..!
테스트를 내가 임의로 바꾸는 건 좋지 않은 방법이지만, 오랫동안 관리되지 않은 부분에 대한 업데이트를 적용하기 위한 테스트이기 때문에 우선 적용하기로 했다.

Pull Request 작성하기​

테스트도 무사히 잘 통과하니, 이제 마지막으로 메인 리포지토리에 풀리퀘스트를 날려준다!! PR에는 어떤 문제를 찾았고, 그 문제를 해결하기 위해 어떤 변경사항을 적용했는지 코드를 보지 않더라도 의도와 변경사항이 명확히 전달될 수 있도록 작성하는 게 중요하다. 작성한 PR은 여기에서 확인 가능하다.

Outro​

이렇게 첫 오픈소스 기여하기를 진행해보았다. 나름 단순한 코드 리포지토리였지만, 소스코드를 살펴보는 과정, 업데이트 릴리즈 노트를 확인하는 과정, 라이브러리 호환성을 맞추는 과정, PR을 잘 작성하는 과정 등 생각보다 신경쓸 것이 많았다. 하지만, 오픈소스 기여라는 것이 내가 엄두조차 못 낼 정도로 대단한 건 아니라는 걸 알게 되었다. 다음에는 버그를 찾고, 픽스해보는 PR을 날려보자! 2024년도 며칠 안 남았다. 연초에 다짐했던 목표 중 하나를 이렇게 글을 쓰면서 달성할 수 있어서 다행이다!

주제는 'AI를 통해 삶과 일의 균형을 찾아라'였다. 금요일 저녁 7시부터 다음날 오후 2시까지 진행되었다. 우리팀은 AI 개발자 1명, 백엔드 3명, 그리고 프론트 2명으로 구성되었다. 다들 의견 제시와 역할 분담에 적극적이여서 초반부터 끝날 때까지 신나게 진행할 수 있었다.

우리 팀이 정한 서비스 주제는 '채용담당관 입장에서 수많은 이력서를 검토하면서 느낄 수 있는 피로감을 줄이기 위해 이력서 정보를 LLM으로 요약정리해주는 서비스'였다.

메인 기능은 요약하자면 다음과 같다.

1. 이력서 정보 추출 및 벡터DB에 저장(input: PDF file, output: 벡터DB저장 정보)
2. 엠베딩 기반 질문 생성 기능(input: 이력서 ID, output: 이력서 관련 생성 질문)
3. 자연어 기반 벡터DB 쿼리 기능(input: 프롬프트, output: list[이력서ID])

좀 더 자세히 설명하자면,

1. 이력서 정보 추출 및 벡터DB에 저장

• PDF 이력서 업로드 시, 텍스트를 추출하여 요약정리 후 벡터DB에 저장한다. 이력서에서 뽑을 수 있는 공통된 정보들을 정형화하여(지원자 이름, 직군[백엔드, AI, 프론트, 풀스택], 연차, 사용 언어) 벡터DB의 메타정보에 저장해두었다. Pydantic으로 만든 스키마가 있다면, 이에 맞춰 정보를 뽑아주는 langchain의 with_structured_output 함수를 사용했다.

2. 엠베딩 기반 질문 생성 기능

• 미리 저장해둔 이력서의 엠베딩 정보를 기반으로 질문을 생성한다. 질문의 종류는 직군별, 컬쳐핏, 경험, 프로젝트 질문으로 나뉜다. 예를 들자면, 이력서에 OCR 프로젝트에 대한 내용이 있다면, 해당 프로젝트에 대해 어떤 기여를 했는지, 어떤 어려움이 있었는지에 대한 질문을 생성해준다.

3. 자연어 기반 벡터DB 쿼리 기능

• 채용담당관이 적은 요구사항(프롬프트)을 기반으로 매칭되는 이력서ID들을 반환한다. 요구사항에 있는 메타정보로 우선적으로 필터링한 후, similarity search를 진행한다. (langchain에서는 이 과정을 query-construction chain이라고 명칭되어있다.)

생각보다 밤을 새면서 개발하는 과정은 쉽지 않았지만, 팀원들이 다 열심히 해준 덕분에 해가 뜰 무렵, 가시적인 결과물인 나오기 시작했다. 미리 MockAPI를 작성해둔 덕분에 각 도메인(프론트, 백엔드, AI)에서 따로 작업을 하긴 했지만, API 연동도 나름 순탄하게 진행되었다. 11월달에 들어 개발하면서 가장 뿌듯한 순간이였다. 그리고 해커톤 일주일이 지난 시점, 만약 시간이 더 주어진다면 어떤 부분을 더 개선해볼 수 있을까 고민했다. 구현한 기능은 LLM을 활용한다는 점에서 특수할 수는 있으나, 결국 데이터를 저장하고, 잘 읽어오는 과정이다. Store와 Retriever 객체로 추상화하여 틀을 만들어 변경사항에 유연하게 대처할 수 있도록 한 다음에 LLM을 활용해서 할 수 있는 여러 가지 시도들을 해볼 수 있을 거라는 생각이 들었다.

여러 가지 시도들을 하기 전에 가장 먼저 해야할 일들은 평가 지표를 설정하는 것이다. 시도들에 대한 객관적인 지표가 있어야만 서비스에 알맞는 선택을 할 수 있기 때문이다.

평가 프로세스 구축​

현재 시스템의 성능을 객관적으로 측정할 수 있는 평가 체계가 필요하다. 현재 프로세스는 이력서를 요약하고 저장하고 쿼리하여 읽어오는 방식이다. 요약, 저장, 쿼리 각각의 과정에 대해 평가 지표를 구성할 수 있다. 그리고, 이 과정에서 사용자의 피드백을 반영할 수 있도록 한다면 더욱 좋을 거라고 생각한다.

• 이력서 요약의 정확성 평가
• 생성된 질문의 품질 평가
• 검색 결과의 정확도 및 관련성 평가
• 사용자 피드백 시스템 구축

이 밖에도 찾아보니 LLM관련 개선할 부분들이 굉장히 많았다. 시간은 좀 걸리겠지만, 천천히 이 부분들에 대해서도 알아보려고 한다.

임베딩 최적화​

현재는 이력서 내용을 요약한 후 임베딩을 수행하고 있는데, 이는 중요한 정보의 손실을 초래할 수 있다.

• 전체 이력서 내용에 대한 섹션별 임베딩 수행
• 주요 키워드와 문맥 정보를 보존하는 청크 단위 임베딩
• 다중 임베딩 모델의 앙상블 적용

검색 성능 향상​

프롬프트 기반 검색의 정확도를 높이기 위한 방안:

• 하이브리드 검색 구현 (키워드 + 시맨틱 검색)
• 검색 결과 재순위화(Reranking) 도입
• 사용자 피드백을 반영한 검색 결과 개선

데이터 저장소 최적화​

메타데이터 저장 및 관리 전략:

• RDB와 벡터DB의 하이브리드 구조 검토(어디까지 메타정보로 저장해도 될까? 어디서부터 RDB를 활용하는 게 좋을까?)
• 메타데이터의 인덱싱 전략
• 캐싱 레이어 도입 검토

데이터 검증 및 예외처리​

안정적인 서비스 운영을 위한 개선사항:

• 입력 데이터 유효성 검사 강화
• PDF 파싱 예외상황 대응
• 정형화된 데이터 스키마 검증 로직 추가
• 에러 로깅 및 모니터링 시스템 구축

이번 글에서는 11월 15일부터 16일까지 무박 2일로 참여한 항해 AI 해커톤 회고 글을 작성해보았다. LLM을 활용한 실제 서비스를 구현해보면서, LLM의 활용 가능성에 대해 다시 한 번 감탄하지 않을 수 없었다. 그리고, 실제 사용자들이 사용하는 서비스를 만들기 위해서 많은 부분들을 개선할 수 있을 거라는 생각이 들었다.

• Muze라는 음악 SNS를 개발하고 있다.
• 노래 정보 검색 기능이 필요한데, 데이터가 부족한 상황이라 검색 결과가 좋지 않다.
• 필요한 데이터를 바로 검색 후 수집할 수 있도록 외부 API를 활용한다.
• 이 외부 API에 문제가 생기면, 앱에도 문제가 생긴다. 그리고, API에는 Rate Limit이 걸려있어서 요청 수가 제한된다.
• 외부 API의 의존성을 최소화하기 위해 fallback으로 사용할 API를 여러 개 두고, Token Bucket 알고리즘을 사용하여 요청을 분산시킨다.

서비스를 개발하면서 A-Z까지 전부 다 구현하기란 어렵다. 구현의 난이도 뿐만 아니라 효율면에서 부적절하다. 그래서 우리는 외부 API를 호출한다. 원하는 기능을 편리하게 사용이 가능하다. 한 가지 문제점이라면, 외부의 의존성이 생김으로써 내부의 문제가 아닌 외부의 문제로 서비스의 결함이 발생할 수도 있다는 점이다. 예를 들어, 쇼핑몰 서비스에서 외부 결제 시스템의 문제로 상품 결제가 이루어지지 않는다면, 실질적인 손해로 이어질 수 있다.

진행중인 사이드 프로젝트 Muze는 음악 취향을 공유하는 웹서비스이다. 자신이 좋아하는 노래를 게시하고 공유하는 기능이 메인 서비스다. 이 서비스를 위해서는 노래 정보들을 데이터베이스에 저장하고 검색하는 기능이 필요한데, 프로젝트의 규모상 '검색이 가능한 노래'의 범위를 정하기가 애매했다. 물론 적당히 구할 수 있는 노래들을 읽어와서 저장하는 방법도 있겠지만, 실제 사용자들이 사용하기에 매끄러운 서비스를 만들고 싶었다.

그래서 생각한 방법은 사용자가 검색 시에 음악 플랫폼(Spotify, Shazam 등)의 검색 API를 활용해서 결과를 리턴해준다. 음악 정보가 서버 내에 당장 없더라도, 정보를 반환해줄 수 있게 되는 것이다. 하지만 이런 처리는 외부 API에 대한 서버의 의존성이 생기게 된다. 우리 서버가 정상적으로 동작한다고 해도, Spotify의 서버에 문제가 생기면 고스란히 그 문제가 우리 서버의 문제로 돌아온다.

외부 API를 활용하는 것은 이미 결정된 사항이기 때문에 이 상황에서 내릴 수 있는 차선의 선택을 하는 것이 중요하다. Spotify 서버에 문제가 생긴다면, Shazam 서버를 활용하는 건 어떨까? 두 플랫폼 모두 문제가 생길 일은 극히 드물 것이다. 인풋 형식과 아웃풋 형식을 맞춰서 추상화된 RequestHandler 클래스를 작성한다.

from abc import ABC, abstractmethod

class RequestHandler(ABC):
	def __init__(self, api_client):
		self.api_client = api_client

	@abstractmethod
	def search(self, keyword, category):
		return 노래정보

class SpotifyAPIRequestHandler(RequestHandler):
	...

class ShazamAPIRequestHandler(RequestHandler):
	...

class YoutubeAPIRequestHandler(RequestHandler):
	...

노래 검색을 위해 활용할 API가 세 개나 생겼다. 그럼 이제 들어오는 요청들을 이 API들에게 어떻게 분배해줄지 설정해주어야한다. 요구사항은

1. 결과가 나오지 않을 경우(response.status_code !=200), 다른 API로 요청을 넘긴다.
2. 각각의 API의 Rate Limit을 초과하지 않는다.
3. 사용자 경험을 고려하여 최대한 빠른 속도로 결과를 리턴해준다. 로 정리가 가능하다.

이 요구사항을 충족시키는 방법은 Token Bucket알고리즘을 활용하여 Rate Limiting을 적용하는 방법이다.

토큰 버킷 알고리즘은 토큰을 기록하여 사용량을 조절한다. 토큰은 시간에 따라 일정량씩 채워지고, 등록된 함수의 호출 시점에 토큰을 사용한다. 만약 시간당 채워지는 토큰보다 더 많은 호출이 이뤄지면 잠시동안 함수 호출이 멈추는 원리이다.

TokenBucket 클래스와 이를 관리하는 APIManager 클래스를 만들어 토큰 버킷 알고리즘을 구현해준다. 각 API당 할당된 Rate Limit 정보를 기반으로 rate(초당 버킷에 채워지는 토큰 수)과 capacity(버킷이 담을 수 있는 토큰의 최대수)을 설정한다.

그리고, 서버 접속 사용자 수에 따라 프로세스가 추가된다는 점을 상기해야한다. 프로세스 간의 APIManager 인스턴스는 독립적인데, API 호출은 공유하기 때문에 이를 인스턴스 간 정보들을 공유할 수 있도록 설정해주어야한다. 인메모리의 Redis를 사용해서 rate, capacity, token 정보를 공유하도록 설정한다.

rate, capacity 설정을 위해서 API 문서에서 Rate Limit에 대한 정보들을 살펴보았다. Spotify같은 경우에는 Rate Limit을 30초동안 쌓인 요청수를 기준으로 잡는다는 이야기만 있고 최대 요청량은 적혀있지 않았다(내가 못 찾았을수도...). 그래서 concurrent.future 모듈을 활용하여 30초동안 보낼 요청 수를 조정하여 실험한 후 최대 요청량을 가늠하였다.

# num_worker=1,2,3,4,5, ...,9,10
[{'num_requests': 158, 'num_success': 158, 'num_failures': 0}, {'num_requests': 302, 'num_success': 301, 'num_failures': 1}, {'num_requests': 533, 'num_success': 307, 'num_failures': 226}, {'num_requests': 774, 'num_success': 311, 'num_failures': 463}, {'num_requests': 992, 'num_success': 342, 'num_failures': 650}, {'num_requests': 1208, 'num_success': 356, 'num_failures': 852}, {'num_requests': 1474, 'num_success': 414, 'num_failures': 1060}, {'num_requests': 1659, 'num_success': 390, 'num_failures': 1269}, {'num_requests': 1973, 'num_success': 405, 'num_failures': 1568}, {'num_requests': 2243, 'num_success': 402, 'num_failures': 1841}]

스포티파이 API는 30초동안 대략 300 - 400개 정도의 요청을 받아준다. 대체 API인 Shazam과 Youtube도 비슷한 수량의 요청을 받아준다고 할 때, 대략 우리 서버는 30초동안 1000개의 검색 요청을 처리할 수 있다는 이야기이다. 이 얘기는 Muze 앱 운영 중에 1001명의 유저가 검색을 한 번씩 하는 경우가 30초의 시간동안 한 번이라도 발생할 경우, 다운타임이 발생할 수도 있다는 이야기이다. (물론 300명의 유저가 생길지 안 생길지조차 모르는 상황이긴 하지만, 30초동안 검색 한 번은 너무 짜다. 보통 한 유저당 한번 이상의 검색을 한다.)

이런 문제는 검색이 호출될 때 백그라운드로 해당 노래 정보를 데이터베이스에 저장하는 식으로 구성한다면, 시간이 지남에 따라 이런 문제들은 해결될 수 있을 거라고 생각했다. 한 번 이상 검색된 정보는 데이터베이스에서 호출되는 방식이기 때문에, 시간이 지날수록 외부 API에 대한 의존도가 낮아질 것이라고 기대했다. 여기에다가 추가적으로 백그라운드 스케쥴러로 최신곡에 대한 크롤링을 주기적으로 수행한다면, 외부 검색 API의 의존성을 최소화하고, 괜찮은 사용자 경험을 제공해줄 수 있게 된다.

이번 글에서는 Rate Limit이 설정되어있는 API를 다루기 위해 고려해야할 부분들과 안정적으로 처리할 수 있는 Rate Limit 기법에 대해서 알아보았다. 검색 기능은 Muze에서 꽤 중요한 기능이다. 이런 중요한 기능을 외부 API에 의존해야한다는 점이 고민되긴 했지만, 부족한 데이터를 다 커버할 수 없는 초기 개발 상황에서 차선의 선택이 필요했다. 외부 API에 의존하되, 운영 시 생길 수 있는 의존성을 최소한으로 줄이고, 데이터가 쌓임에 따라 그 의존성을 아예 없앨 수 있다면, 꽤 괜찮은 시나리오라고 생각한다.

지난 10월 7일, 파이썬 3.13이 릴리즈되었습니다. 변경사항 중 가장 주목할만한 내용은 GIL을 키고 끌 수 있도록 변경한 부분이였습니다. 정식으로 GIL이 완전 제거 결정을 내리기까지는(제거하지 않기로 결정할 수도 있음) 약 5년정도의 시간이 걸린다고 하지만, 멀티쓰레딩이 어려웠던 기존의 파이썬을 생각하면 엄청난 변화라고 할 수 있을 것 같습니다. 이번 글에서는 GIL이 무엇인지, 왜 등장했고 왜 제거하기로 한 건지에 대해 알아보겠습니다.

GIL이 무엇일까요?​

GIL이 무엇인지 이해하기 위해서 우선 우리가 작성한 파이썬 코드가 어떤 식으로 돌아가는지 알아야합니다. 컴퓨터의 기본 동작 방식은 다음과 같습니다. 보조기억장치(하드 드라이브)에 저장된 코드를 읽어 메모리 공간(RAM)에 프로세스로써 올리고, CPU는 레지스터의 도움을 받아 RAM에 있는 명령어들을 처리합니다. RAM에 적재된 코드는 컴퓨터가 이해할 수 있는 언어로 번역(소스코드 ->바이트코드->기계어)되어야합니다. 언어마다 다르지만, 파이썬은 작성한 코드를 메모리에 올릴 때마다 인터프리터가 코드 한줄 한줄 이 번역을 수행해주는 인터프리터 언어입니다. 인터프리터는 사람이 작성한 코드를 CPU에서 수행할 수 있게 번역해주는 역할을 한다고 보면 됩니다. 그리고, GIL(Global Interpreter Lock)은 프로세스당 하나의 쓰레드만이 이 인터프리터의 제어권을 갖고 명령을 수행할 수 있게 하는 락(Mutex)입니다. 동일한 프로세스라면, 여러 쓰레드가 존재해도, 이 락을 소유하기 전까지는 명령을 수행할 수 없습니다. GIL은 멀티코어로 구성되어있는 최근 CPU들을(2024년 기준 인텔 i7은 최대 20개의 코어, 애플 M3는 최대 40코어 보유) 멀티 쓰레딩으로 활용할 수 있는 이점을 제약합니다.

GIL은 왜 등장한 것일까요?​

그렇다면 왜 파이썬에 GIL이 등장한 걸까요? 정답은 다수의 쓰레드를 사용하면서 생길 수 있는 Race Condition을 예방하기 위해서입니다. 더 자세히는 파이썬의 메모리 관리 방법과 연관되어있습니다. 파이썬에서는 Garbage Collection에 (Heap영역에서 더이상 사용되지 않는 객체들을 삭제) Reference Counting을 사용합니다. 어떤 객체의 Reference Count가 0이상이라면, Garbage Collection 대상에서 제외하고, 0에 도달한다면, 더 이상 사용하지 않는다고 판단하고 제거하는 식입니다. 그런데 이런 Reference Counting 방식은 같은 메모리 공간을 공유하는 쓰레드들끼리 같은 자원에 접근하는 Race Condition이 발생했을 때 문제가 생길 수 있습니다. Reference Counting에 대한 동시 접근으로 인해 삭제되어야할 객체가 삭제되지 않거나 유지되어야할 객체가 삭제되는 경우가 발생할 수 있습니다. 이런 Race Condition을 방지하기 위해 GIL이 탄생한 것입니다. (Java같은 경우, 특정 시점을 기준으로 garbage collection을 수행합니다.)

파이썬이 멀티코어를 활용하는 방법​

GIL이 있다고 해서 파이썬이 멀티코어를 아예 활용하지 못 하는 건 아닙니다. 파이썬은 웹 프레임워크나 머신러닝 등 다양한 분야에서 활용되는 언어입니다. 파이썬이 멀티코어를 활용하는 방법은 크게 세 가지로 나뉠 수 있습니다.

1. 멀티 프로세싱
2. C나 C++로 작성한 코드
3. CPython이 아닌 다른 인터프리터(PyPy, Jython과 같은) 사용 (추가로 GIL때문에 멀티쓰레드가 아예 의미가 없는 건 아닙니다. I/O작업시에 GIL은 자동으로 해제되기 때문에 I/O bounded 작업에서는 멀티 쓰레드가 동작한다고 볼 수 있습니다.)

파이썬 멀티코어 활용법1. 멀티프로세스​

멀티프로세싱을 활용하면 멀티 코어를 온전히 사용할 수 있습니다. 그림으로 그리면 이런 식입니다. GIL에 의해 제약받지 않을 수 있도록 각 프로세스마다 별도의 인터프리터를 둡니다. 웹 게이트웨이 인터페이스인 gunicorn은 일반적으로 위에 보는 것과 같이 멀티 프로세싱 방식으로 동작합니다. 여기서 한 가지 알아야할 점은 프로세스는 개별적인 메모리 공간을 요구하기 때문에 멀티쓰레드에 비해서 메모리 공간을 더 차지합니다. 그리고 이 메모리 공간 때문에 메모리를 공유하는 쓰레드에 비해 컨텍스트 스위칭 비용이 발생합니다.

파이썬 멀티코어 활용법2. C,C++ 작성 코드​

파이썬에서는 C나 C++로 작성된 코드를 수행할 수 있도록 C API를 제공합니다. 파이썬 인터프리터가 C 코드를 확인하면 제어권을 넘기는 방식입니다. 이렇게 되면 GIL 상관없이 C나 C++ 코드에서 사용하는 것처럼 멀티쓰레딩을 사용할 수 있습니다. 대표적으로 numpy나 pandas와 같은 데이터과학 모듈이 이 방법을 활용합니다. C 작성 코드의 빠름과 유연함을 활용할 수 있다는 점이 장점이지만, C, C++ 데이터 구조에서 Python 구조체로 변경하기 위해 어느 정도의 오버헤드는 발생할 것입니다.

파이썬 멀티코어 활용법3. CPython이 아닌 다른 인터프리터 사용하기​

CPython이 표준 인터프리터이긴 하지만, PyPy나 Jython, IronPython 등 다른 인터프리터들도 존재합니다. GIL은 CPython 안에 존재하는 락으로, 만약 다른 인터프리터를 사용한다면 쓰레드 제약에 대해 더 이상 신경쓰지 않아도 됩니다. (물론, 다중 쓰레드 사용에 따른 공유 자원의 Race Condition을 직접 신경써줘야하겠죠) CPython이 아닌 다른 인터프리터를 직접 사용해본 적은 없지만, 필요하다면 인터프리터의 장단점을 확인하여 상황에 맞게 적절히 사용해볼 수 있을 것 같습니다.

3.13은 GIL 없이 어떻게 동작하는 걸까?​

그럼 여기서 떠오르는 궁금증은 이미 잘 돌아가고 있는데, 왜 이제서야 바꾸는 걸까 입니다. 2007년에 파이썬의 창시자 귀도 반 로썸이 게시한 글에는 멀티 코어가 등장하면서, GIL을 제거하는 방안을 고민해보았지만, 딱히 성능적으로 이점이 없었다는 얘기가 있습니다. GIL을 제거하면 CPU위주의 태스크를 수행하는 멀티 쓰레딩 프로그램에서는 확실히 이점이 있겠지만, 기존의 싱글쓰레드 프로그램에서 성능적으로 손실이 있었기 때문에 정식으로 반영되지 않았다고 합니다. 실제로 GIL을 제거하려는 여러 프로젝트(대표적으로 Giletomy)들이 있었지만, 3.13까지는 정식적으로 반영될 정도로 효과적이진 않았던 것 같습니다. 하지만 GIL 없이 멀티 쓰레딩을 사용가능하다면, 확실히 개선할 수 있는 포인트들이 있을 것입니다. 쓰레드 간 메모리를 공유한다는 점을 활용하면 메모리 공간을 더 효율적으로 사용할 수 있고, 멀티프로세스 사용시 프로세스 간에 자원을 공유해야하는 부담도 덜 수 있습니다. 이 GIL 제거는 기존의 reference counting을 biased referencing, immortialization을 통해 가능해졌다고 합니다. 자세한 사항은 글이 길어져 생략하지만, 락을 걸지 않고, 어떻게 쓰레드 간의 Race Condition을 해결할지에 초점을 두고 키워드들을 살펴보시면 좋을 것 같습니다.

Outro​

지금까지 GIL이 무엇인지, 왜 파이썬에 GIL이 생긴 건지, 그리고 파이썬에서는 이런 제약을 어떻게 해결해왔는지에 대하여 알아보았습니다. 기존의 파이썬 생태계에서 어느정도의 최적화가 이루어진 상황이지만, no gil 도입을 통해 어떤 식으로 더 개선될 수 있을지 기대됩니다.

유튜브 추천 동영상에 흥미로운 영상이 올라왔다.

"ML/AI 개발자를 위한 단계별 Python 최적화 가이드라인"

네이버 파파고 OCR팀 문주혁 님의 DEVIEW 2023 영상이다.

OCR, 이미지에서 텍스트를 탐지하는 단계에서, 텍스트 박스 갯수가 많아지면 속도가 느려지는 이슈를 어떻게 해결했는지에 대해 이야기한다. 전에 일했던 회사에서 똑같이 겪었던 이슈였기 때문에 집중해서 봤다. 영상을 보고 내 나름대로 문제 해결을 위해 발표자분이 어떤 식으로 접근했는지 정리해보았다. 기술적인 부분보다는 문제를 해결하기 위한 자세에 초점을 두고 글을 작성했다.

1. 문제 배경
2. 문제 해결 방법
3. 내가 시도해볼 것(Takeaway)

문제 배경​

파이썬은 딥러닝 모델을 개발하기 위한 생태계가 잘 구성되어있다. GPU를 활용하여 딥러닝 모델을 학습/평가/서빙할 수 있는 pytorch, tensorflow 등 여러 프레임워크들과 고차원의 행렬 데이터들을 처리할 수 있는 pandas나 numpy와 같은 라이브러리들이 있다.

문제는 파이썬이 다른 언어들보다 느리다는 점이다. 모델 개발이 끝난 후, 딥러닝 모델의 앞단과 끝단에서 데이터를 처리하는 전처리나 후처리 또는 다른 부분들에서 속도가 느린 걸 발견할 수도 있다.

데이터 사이언티스트들은 보통 CS 백그라운드가 다른 개발자들보다 강한 편은 아니다. (물론 케바케겠지만) 내 첫번째 컴퓨터 언어는 파이썬이고, 비교적 최근에야 C나 C++ 같은 언어에 관심을 갖게 되었지만, 개인적으로 생각하기에 코드를 보고 '이런 부분을 고치면 조금 더 속도가 개선되겠는걸? 아 여기서 병목현상이 발생하는구나' 같은 컴퓨터 내부 동작 원리를 건드리는(또는 컴퓨터 내부 동작 원리를 알아야만 가능하다고 생각한) 생각은 많이 해보지 못한 것 같다.

그래도 완성된 딥러닝 알고리즘이 작동하는 방식을 제일 잘 이해하는 개발자는 모델을 담당한 데이터 사이언티스트 본인일 것이고, 속도가 개선되어야만 한다면 그건 데이터 사이언티스트의 임무일 것이다.

영상에서는 요새 핫한 모델 최적화 기법, 상당히 높은 지식 수준을 요구하는 고난이도 기술 대신, 우리가 시도해볼 수 있는 것 그리고 실질적인 결과물을 낼 수 있는 방법에 대해서 이야기한다.

문제 해결방법​

측정 => {문제 개선방법 시도 => 측정 => 결과 분석} x repeat => 문제 개선

측정​

문제를 해결하기 위해서는 우선 문제가 있다는 사실부터 인정해야한다는 말이 있다.

'속도가 느리다'라는 이슈를 해결하기 위해, 우선 속도 프로파일링을 진행한다. 문제 해결을 위한 가장 첫번째 단계는 문제 개선 여부를 측정할 수 있는 지표 설정이다.

파이썬에서 제공하는 timeit함수도 있지만, 코드 곳곳에 일일히 입력해야한다는 단점이 있다. timeit 대신 line_profiler라는 라이브러리를 사용했다고 한다. 전체 코드에 대해서 줄줄이 얼마만큼의 시간이 걸렸고, 몇 퍼센트의 비중을 차지하는지 알 수 있다고 한다.

문제 개선방법 시도​

해결해야하는 문제가 '속도가 느리다'에서 '우리 코드 중 어느 부분이 특히 느리다'로 문제의 범위가 좁아졌다. 이제는 문제를 개선할 수 있는 방법들을 나열한다. 무작정 이 방법, 저 방법 해보자 보다는 여러 측면/레벨에서 시도해볼 수 있는 것들을 체계화하는 것이 중요하다. 영상에서는 속도 개선을 위해 python level, semi-c level, c/c++ level 세 가지로 나누어 접근했다.

문제 개선방법 - python Level

문제 해결 방법들을 나열했다면, 가장 시도해보기 쉬운 것부터 시도해본다. 실패했을 때 비용이 적고, 가볍게 직접 시도해보면서 해결하고자 하는 문제가 조금 더 구체화된다는 장점이 있다. 문제 정의 시에 알지 못했던 부분에 대해 새롭게 알게 된다거나, 새로운 해결방법들을 추가해볼 수도 있다.

numpy나 opencv는 c와 c++로 작성된 라이브러리로 파이썬에서 작동할 수 있는 최적 속도를 어느정도 보장받는다. 그렇다고 해서 해당 라이브러리로 작성된 코드가 작성할 수 있는 최적의 속도라는 의미는 아니다. 개선할 수 있는 부분이 있을지도 모른다.

다시 한번, 문제 해결 방법은 여러가지가 있겠지만, 가장 시도해보기 쉬운 것부터 시도하는 것이 중요하다. numpy나 opencv에서 개선할 수 있는 부분을 찾으라고 해서, 안에 구동되는 동작원리를 파악하고, c++ 코드를 재작성하라는 의미가 아니다. 가장 쉽게 시도해볼 수 있는 방법은 '같은 라이브러리 내에서 코드 문맥에 조금 더 적합한 함수가 있을 수 있다. 더 알맞은 함수로 변경해보자'이다.

문제 개선방법 - Semi-c Level

파이썬 속도 개선을 위해 검색을 하다보면 항상 나오는 키워드가 있다. cython이나 numba. 결론만 말하자면, "pure python, 즉 라이브러리를 사용하지 않은 파이썬 자체 코드일 경우 눈에 띄는 성능 개선을 확인할 수 있지만, 다른 언어로 작성되어 이미 빠른 라이브러리를 사용할 경우, 그다지 좋은 성능 개선은 기대하기 힘들다"고 한다. 여기서 내가 생각하기에 중요한 부분은 '좋다고 해서 써봤는데?"라는 생각으로 시도한 방법에 대한 대응 방식이다.

시도한 방법은 생각보다 결과가 좋을 수도 있고, 좋지 않을 수도 있다. 하지만, 결과의 퀄리티를 떠나, 결과를 분석하는 단계는 항상 있어야한다. cython이나 numba를 시도하는 방법에 있어서, '파이썬 자체 코드 => 성능 개선 우수, 라이브러리 코드 => 성능 개선 미미'라는 결론에 다다르기까지는 여러번의 실험과 분석이 있었을 것이다(추측이긴 하지만). 한 번에 이런 결론에 다다르면 정말 좋겠지만, 배경지식이 없는 상태에서 실험 후에 명료한 결론을 내리는 것은 생각보다 쉬운 일이 아니라고 생각한다. 여러번 걸릴 수도 있겠지만, 각 시도마다 결과를 분석하고, 나름의 결론과 경험치를 쌓아서 실용적인 결론에 다다르는 것이 중요하다.

('시도해봤는데 결과가 잘 안나왔다. 이 방법은 구리다' 같은 결론이 아니라, 영상에서처럼 '이 방법은 이럴 때는 잘 작동하지만, 저럴 때는 잘 작동하지 않을 수도 있으니 참고하세요.' 같은 실용적인 결론이다.)

문제 개선방법 - C/C++ Level

만약 C/C++ implementation을 적용하기로 결정했다면, '시도해보기 쉬운 것부터 시도' 원칙이 다시 한번 적용된다. 전체 코드를 바꾸는 대신, 시간이 오래 걸리는 병목 함수를 찾고 해당 부분만 C/C++ 구현을 적용한다. 여기서 내가 생각하기에 중요한 부분은 두 가지였다.

첫째는 새로운 코드 적용이 항상 공식 문서에 제공된 example과 같이 딱 들어맞지는 않을 것이기 때문에, 내 상황에 맞게 활용하는 유연성이 필요하다는 점이다. 영상에서는 numpy의 ndarray를 C에서 지원하는 cv::Mat 형식으로 변환하기 위해 Numpy C api에서 제공하는 PyArray_FromAny와 c++에서 제공하는 PyArrayObject를 거친다. '어? 내가 원하는 기능을 지원 안 하네?'하고 바로 포기해버리기보다는 조금 돌아가더라도 어떻게 해결할 수 있을지 고민해볼 필요가 있다.

두번째는 직접 해봐야 안다는 점이다. 위에서 언급했다시피, numpy와 opencv 같은 라이브러리들은 C/C++로 구현되어 있기 때문에 어느정도 최적의 속도를 보장한다. 그렇다면, 해당 라이브러리로 작성한 코드 속도가 무조건 C/C++로 구현한 속도와 동일할까? 아니다. 영상에서는 라이브러리로 작성한 파이썬 코드를 동일한 로직의 C/C++로 변환했을 때, 50%에 가까운 속도 향상을 얻었다고 한다. 개발을 하다보면 이론과는 다른 결과가 발생하기도 한다. 이론을 맹신하지말고, 직접 시도해보는 과정이 필요하다.

(문제 해결을 위해 돌아서 풀어가는 과정(workaround)에 길을 잃지 않기 위해서는 기초지식과 다루고 있는 문제의 본질에 대한 이해가 필요하다. 또, 이론이 전부가 아니다. 직접 시도해보는 과정이 필요하다.)

내가 시도해볼 것들(Takeaway)​

영상을 보고 배운 점을 정리하자면 다음과 같다.

• 최적화를 위해 컴퓨터 내부 동작 원리를 알아야만 가능한 것은 아니다.
• 문제 해결은 측정 -> 해결 방법 시도 -> 측정 -> 결과 분석 의 반복으로 이루어진다.
• 문제 개선 여부를 측정할 수 있는 지표 설정하기
• 문제 범위를 좁히기
• 여러 측면/레벨에서 시도해볼 수 있는 것들을 체계화하기
• 각 시도마다 결과를 분석하고, 나름의 결론과 경험치를 쌓아서 실용적인 결론 내리기
• 새로운 방법을 내 상황에 맞게 활용하는 유연성 기르기
  • 기초지식 갈고닦기
  • 해결하고자하는 문제를 이해하기
• 이론을 맹신하지 말고, 직접 시도해보기

(어플리케이션은 http://3.39.105.35:8090/에서 확인할 수 있다.)

아직 추가해야할 내용도 많고, 개선해야할 내용도 많지만, 한 번에 하기보다는 하나씩 작업하는 게 중요하다. 개선과정에 있어서 중요한 것은 자동화할 수 있는 부분은 최대한 자동화해서 개발 싸이클을 개선하는 것이다. 작업하는 내용에만 집중하고, 코드를 관리하기 위해서 Github Issue에 작업할 내용을 기록하고, 브랜치를 파서 작업했다.

현재 AWS LightSail에다가 어플리케이션을 배포하였는데, 이 배포 과정을 Github Action을 사용해서 자동화하려고 한다.

서칭해보니 AWS의 다른 서비스들에서는 배포를 위해 CodeDeploy라는 배포 서비스를 제공하는데, AWS-LightSail은 해당사항이 없다고 한다. 그럼 LightSail은 배포를 자동화를 할 수 없는 걸까?

AWS-LightSail Instance가 EC2와 비슷하다면, AWS-LightSail Container Service는 ECS(container service)와 비슷하다.

aws-cli에서 lightsail로 이미지를 푸쉬하고 배포하는 기능을 제공한다.

EC2를 사용하면 S3에 빌드한 소스를 넘기고, S3에서 CodeDeploy가 변경내용을 가져와서 인스턴스에 적용하는 방식이였는데, LightSail Container Service는 바로 이미지를 푸쉬하고 배포하면 되니 더 간편한 것 같다. (왜 CodeDeploy가 S3를 통해야만 하는지는 아직 잘 모르겠다.)

다시 본론으로 돌아와서,

LightSail Container Service에 배포하기 위해서는 Github Action이 다음과 같은 과정을 거쳐야한다. 여기서 action runner는 깃헙 액션에서 워크플로를 실행하기 위해 제공하는 임시 서버이다.

1. 깃헙 체크아웃 - 마스터 브랜치의 변경사항을 action runner에 반영한다.
2. aws-cli 중 lightsailctl을 사용할 것이므로, action runner에 aws-cli lightsail 플러그인을 설치한다.
3. 도커 이미지를 빌드한다.
4. 빌드한 이미지를 컨테이너 서비스로 푸쉬한다.
5. 푸쉬한 서버를 배포한다.

name: lightsail-deploy
on:
  push:
    branches: ['master']
  pull_request:
    branches: ['master']
permissions:
    contents: read

env:
  LIGHTSAIL_SSH_KEY: ${{ secrets.LIGHTSAIL_SSH_KEY }}
  LIGHTSAIL_HOST: ${{ secrets.LIGHTSAIL_HOST }}
  OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY}}
  LIGHTSAIL_USERNAME: ubuntu
  LIGHTSAIL_SERVICE_NAME: llmsummarizer-container
  AWS_REGION: ap-northeast-2

jobs:
  buildfastapi:
    name: Building FastAPI app
    runs-on: ubuntu-latest
    
    steps:
			# 1. 깃헙 체크아웃 - 마스터 브랜치의 변경사항을 action runner에 반영한다. 
      - name: Getting Code from Github
        uses: actions/checkout@v4
      - name: Updating to the latest versions
        run: |
          sudo apt-get update
          sudo apt-get install -y jq unzip
			# 2. aws-cli 중 lightsailctl을 사용할 것이므로, action runner에 aws-cli lightsail 플러그인을 설치한다.
      - name: Install Amazon Client
        run: |
          curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
          unzip awscliv2.zip
          sudo ./aws/install || true
          aws --version
          curl "https://s3.us-west-2.amazonaws.com/lightsailctl/latest/linux-amd64/lightsailctl" -o "lightsailctl"
          sudo mv "lightsailctl" "/usr/local/bin/lightsailctl"
          sudo chmod +x /usr/local/bin/lightsailctl
      
			# 3. 도커 이미지를 빌드한다.
      - name: Build a Docker Container
        run: docker build -t llmsummarizer:latest .
      
			#4.빌드한 이미지를 컨테이너 서비스로 푸쉬한다.
      - name: upload image to Lightsail container service
        run: |
          service_name=${{ env.LIGHTSAIL_SERVICE_NAME }}
          aws lightsail push-container-image \
            --region ${{ env.AWS_REGION }} \
            --service-name ${{ env.LIGHTSAIL_SERVICE_NAME }} \
            --label llmsummarizer \
            --image llmsummarizer:latest
      
      - name: AWS authentication
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-region: ${{ env.AWS_REGION }}
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{secrets.AWS_SECRET_ACCESS_KEY }}
      
      - name: AWS Lightsail 연결 확인
        run: aws configure list
        
      #5.푸쉬한 서버를 배포한다.
      - name: Launching the Containers
        run: |
          aws lightsail create-container-service-deployment --service-name ${{ env.LIGHTSAIL_SERVICE_NAME }} \
          --containers file://aws-lightsail/deploymentconfig.json \
          --public-endpoint file://aws-lightsail/publicendpoint.json1

물론 액션이 한 번에 성공하지는 못했다. 예기치 못한 실패를 몇십번 거치고 나서야 액션이 잘 실행된 걸 확인할 수 있었다.

그렇다면 이번엔 라이트세일 페이지에서 배포가 성공적으로 되는 걸 확인한다.


서버도 무사히 잘 동작하는 걸 확인했다.

배포를 자동화하는 개발환경을 셋팅했으니, 개발속도와 피드백 주기가 조금 더 빨라질 것을 기대해본다. 그럼 이제 추가 기능과 성능을 개선해보자.

같은 프로젝트를 다시 진행하기 전에 우선 왜 그만두었는지 이유를 곰곰히 고민해보고, 똑같은 실수를 반복하지 않도록 하고싶다.

이전 프로젝트를 그만두게 된 원인을 몇가지 꼽아보자면 다음과 같다.

1. 코드 구조를 미리 설계하고 시작했다.

   프로젝트를 진행하기 위해서 미리 설계하고 시작하는 것은 중요하다. 코드 구조가 잡혔는데 새로운 기능들을 추가하다보면, 코드가 금방 지저분해질 것 같다는 생각이 들었다. 그래서 디렉토리 구조를 미리 나눠놓고, 거기에 코드들을 끼워맞췄다. 틀을 정해놨으니, 그 안에 맞추면 된다는 생각이였다. 하지만, 이상하게도 코드 라인이 많아지면 많아질수록, 관리하기 힘들어졌고, 뭐 하나 쉽사리 변경하기 어려워졌다.

   코드 구조는 정해져있는 절대적인 답이 있는 것이 아니라, 그 쓰임새에 맞게 합리적으로 조금씩 변화해가는 과정을 통해 결정된다. 구조에 대한 고민은 프로젝트 초기에 한 번 하고 마는 것이 아니라, 코드를 작성하면서 끊임없이 고민해야된다는 것이였다. 코드가 돌아간다고 괜찮다 생각하지말고, 나중에 다시 봤을 때, 혹은 전체 구조에서 알맞는 코드인지 가독성이 좋은지 주기적으로 검토하는 것이 중요하다. 마틴 파울러의 ‘클린 아키텍쳐’는 확장성이 좋고, 유지 보수성이 좋은 코드를 작성하기 위한 해법들을 잘 알려준다. 그리고 테스트 코드를 작성하면, 변경사항에도 안전성을 확보할 수 있다고 한다. 이번 프로젝트에서는 테스트 코드를 작성하고, 클린 아키텍쳐에서 말하는 내용을 잘 숙지하면서 진행해보려고 한다.

2. 프로젝트에서 샛길로…

   진행하면서 초기단계에서는 미처 생각하지 못 했던 사항들이 발생했다. 예를 들면, 음성파일을 텍스트파일로 변환하는 whisper 모델 같은 경우에는 직접 서빙을 목표로 했었는데, 서빙을 위한 클라우드 비용을 알아보니, 운영이 도저히 힘든 가격이였다. 이럴 때는 조금 찝찝하더라도, 애초에 계획한 목표에 도달하기 위해 우선 가장 빠르고 쉬운 방법을 택하는 게 맞지 않을까 라는 생각을 지금에서라도 해본다. 그 당시에는 어떻게든 이 문제를 해결해야만 다음 단계로 넘어갈 수 있을 거라는 생각이였다. 결과적으로 GPU이던 CPU이던 whisper를 로컬로 서빙할 수 있는 방법은 찾지 못하였고, 계획한 목표에도 달성하지 못했다. 결과만 봤을 때는 시간만 낭비한 셈이다. 우선은 openai에서 제공하는 api로 목표한 요약 기능을 구현하고, 추가 개선을 하는 상황에서 다시 접했다면 어땠을까 하는 생각이 든다. 심리적으로도 결과물이 이미 있으니, 조금 덜 부담을 가지고 문제를 해결할 수 있지 않았을까 아쉬운 마음이다. 기술부채가 나쁜 것만은 아니다. 상황에 맞게 현명한 판단을 하는 게 중요하다. 이번 프로젝트에서는 미흡하더라도 우선은 완성을 하고, 조금씩 개선해나가는 것이 목표이다.

그래서 우선 돌아가는 어플리케이션을 작성했다. 이미 이전 프로젝트에서 작성해놓은 코드들을 가지고와서 확장성을 고려하여 작성했다. 인풋에 대한 전처리와 요약 과정이 혹시 변경될 수 있을지 모르니, Inputhandler와 mapreducer를 추상화하여 변경 사항에 대처할 수 있도록 했다. 어플리케이션 배포는 AWS의 lightsail 인스턴스에다가 했다. 3개월 무료라는 점과 lighsail이 제공하는 간편성 그리고 서버 규모가 커지면 EC2로 손쉽게 옮길 수 있다는 점에서 채택했다.

어플리케이션은 http://3.39.105.35:8090/ 여기에서 확인할 수 있다.

물론 고칠 점이 많다. 하나하나씩 개선해나갈 예정이다.

카카오 개발자 컨퍼런스 if(kakao) dev 2022가 12월 7일부터 9일까지 열렸다. 이번에도 역시 흥미로운 주제들을 다룬 세션들이 많았는데(얼마전에 있었던 카카오 서버 다운 사건에 대해서도), 그 중 내 관심을 가장 끈 주제는 ‘실험을 잘한다는 것은 무엇일까’. 카카오 추천팀의 개발자 분께서 발표한 세션이였다.

업무에 딥러닝을 활용하는 개발자로써(딥러닝 개발자, 딥러닝 엔지니어, 딥러닝 리서치 사이언티스트 등등 다양한 텀이 있지만, 정확히 내가 어떤 범주에 속하고, 그리고 또 속하고싶은지는 아직 잘 모르겠다.) 성장하기 위해서 어떤 역량들이 필요한지 항상 고민하곤 한다.

빠른 구현을 위한 프로그래밍 능력, 당면한 문제 해결을 위해 딥러닝을 적절히 활용하는 창의성, 매번 업데이트되는 최신 트렌드를 잘 반영하여 코드와 모델의 성능을 기록하고 정리하는 능력 등등 정말 다양한 분야의 역량이 필요한 딥러닝이지만, 그 중 실무에서 가장 중요한 덕목은 아무래도 ‘실험을 잘하는 것’이라는 생각을 한 적이 있다. 그래서 많은 세션들 중 단연 ‘실험을 잘한다는 것은 무엇일까’라는 타이틀은 더욱 눈에 띄었다.

불확실성을 전제로 하는 머신러닝 특성상 100%의 정확도, 100%의 효율은 없다. 다만, 전세계에서 부리나케 연구되는 학문이라 빠른 페이스로 트렌드가 바뀌고 새로운 기술들이 세상에 나온다. 기존 솔루션이 조금은 부족했던 부분 플러스 ‘더 좋은 게 나왔다던데?’라는 소식을 들으면, 이제 개발자는 실험 모드에 들어가게 된다. 새로운 모델(여기선 모델이라고 뭉뚱그렸지만, 학습 방법, 데이터 처리 등 머신러닝에 관련된 다양한 기술을 말한다)이 ‘기존 모델보다 실제로 나은지’를 실험으로 입증해야하는 것이다.

물론 실험 결과가 기존 솔루션보다 낫다라는 결론이 나면 해피엔딩이다. 문제는 새로운 모델의 결과가 애매할 때이다. (원래 있던 문제는 해결하는데, 없던 문제가 생겼다거나. 분명 정확도는 좋은데, 모델 연산이 너무 무거워 해결하고자하는 문제에는 투머치라거나. 정말 다양한 방면에서 애매할 수 있다.) 그럴 때는 두 가지 옵션으로 정리가 가능하다고 한다. 솔루션을 포기하거나 아니면 보완하거나.

옵션1. 솔루션 포기​

솔루션을 포기하기로 결정했다는 것은 그동안 해당 솔루션을 위해 투자한 시간을 (어떤 의미에서는) 확실한 성과가 없이 버려야하는 것과 마찬가지다. 확실한 성과가 없으면 실험자 본인이 지치기는 물론이고, 실적을 내야하는 회사에서 살아남기는 힘들다. 그렇다고 해서 솔루션 포기가 그동안 했던 것들이 아예 티끌로 사라지는 것은 아니다. 진행한 실험 결과로부터 어떤 교훈을 얻을 수 있을지, 즉 ‘어떻게 다음 실험에도 도움이 될 수 있을까‘를 남기는 것이 중요하다고 한다. 실험을 반복할수록 경험이 쌓이고, ‘이 방향은 아니야’, ‘이 방향은 더 파볼만 한데?’하는 소위 말해 짬(?)이 생긴다. 이런 경험들을 어떻게 본인의 발전 뿐만 아니라 팀원들에게 도움이 될 수 있는 방향으로 기록하여 ‘팀의 발전’으로 기여할 수 있는지가 ‘실험을 잘 하는 기준’의 하나가 될 수 있지 않을까 싶다.

또한, 성능을 개선하기 위한 다른 솔루션을 찾아야한다. 다른 솔루션을 찾아야한다는 것은 지금 투자한만큼의 시간이 다시 필요할 수도 있음을 의미하고, 더욱 최악인 것은 다음 솔루션이 이번 솔루션처럼 ‘포기’로 돌아갈 수도 있음을 인지해야한다는 것이다. 또, 해당 솔루션을 애초에 선택한 이유는 ‘성능이 좋다더라’하는 이유에서였을텐데, 이렇게 두세번 찾은 솔루션의 성능이 애매한 것을 확인하게 되면, 어느 기준으로 새로운 다른 솔루션을 찾아야하는지 막막해지기도 한다. (나도 논문을 볼 때, ‘이 퍼블릭 데이터셋에 대해서 이만큼 엄청난 성능을 보였다!’ 하는 부분에 대해서는 연차가 쌓일수록 무덤덤해지는 것 같다. 이렇게 연구결과를 믿기 힘든 부분은 머신러닝의 특성상 아마도 실험 셋팅이 회사, 기관, 연구소마다 다른 탓과, 실무에서 사용되는 데이터와 학회에서 사용되는 데이터 간의 격차가 커서일 듯 싶다.)

포기한 솔루션은 내가 해결하지 못하였다고 접는 것이 아니라, 남들에게도 매력적인 솔루션으로 느껴진다면 계속해서 시도될 것이라고 한다. 마치 원탁의 기사에서 나오는 ‘엑스칼리버’처럼. (효율이 중요하고 영업이익을 내야하는 회사이지만, 구성원들이 매력적인 솔루션들을 충분히 시도해볼 수 있도록 하고, 실패하더라도 커뮤니케이션을 통해 팀 전체의 성장을 위해 교훈을 남기는 회사가 정말 좋은 회사가 아닐까 싶다.)

옵션2. 솔루션 보완​

솔루션을 보완하기로 마음먹었다면, 어떤 부분들을 보완할지 리스트업하게 될 것이다. 때때로 주어진 시간에 비해 보완해야할 부분이 너무 많아 어디서부터 시작해야할지조차 모를 때가 있는데, 그럴 때일수록 우선 순위를 설정하고 그에 맞게 하나하나 차근차근 고쳐나가는 것이 중요하다고 한다. 그렇게 우선순위를 설정하면, 보완하고 실험하고 실패하고를 반복하며 솔루션을 보완해나간다. 한 번만에 원하는 결과가 나올수도 있고, 수십번해도 안 될 수도 있다. 뚝심있게 실험을 풀어나가는 것도 중요하지만, 실험이 반복될수록 ‘매몰 비용이 발생’한다는 것을 인지해야한다고 한다. 어떻게 될 것 같은데… 될 것 같은데… 싶은 마음은 알겠지만, 물러서야할 때를 알아야한다는 것이다. 이 물러서야할 때를 알기 위해, 실험 전 ‘마무리 조건’을 설정해놓으라고 한다. (이 ‘마무리 조건’을 어떻게 정해야할지는 아직 잘 모르겠다. 사실 실험이 원하는 방향으로 진행이 안되면 찜찜하고 될 때까지 해내고 싶은데, 어떻게 마무리 조건을 설정해야 이만큼 했으면 할만큼 했다 싶은 생각이 들지 잘 모르겠다.)

결론적으로 실험을 하면서, 아래와 같은 질문들에 대한 대답이 물흐르듯이 나온다면 아마 실험을 잘 진행하고 있는 걸 거라고 한다.

Q1. 실험 결과를 어떻게 남겨야 다음 실험에 도움이 될 수 있을까?

Q2. 보완 실험은 어디서부터 진행하는 게 좋을까? (보완하면 좋을 점이 너무 많이 보인다.)

Q3. 마무리 조건을 어떻게 세우는 게 좋을까?

실험을 잘한다는 것​

실험을 잘 한다는 것은 ‘승부수’가 있다는 것이라고 한다. 그리고 이 승부수는 이 실험이 성공할 거라고 생각하는 이유라고 한다. 단지 ‘이번에 나온 논문의 성능이 좋다던데?’라는 이유보다는 ‘학습용 데이터가 부족한 우리 문제에 소량의 데이터만으로도 이 정도 성능을 뽑는 논문이 나왔대’라는 이유라면, 실험이 성공할 확률이 높다는 것이다. 좀 더 일반화하자면, ‘문제 환경(Environment)과 문제 해결의 핵심이 되는 특징(Key Feature)이 들어맞을 때, 솔루션이 적합하다.’라고 한다.

승부수에 따른 실험 결과 분석

1. key feature 구현을 제대로 했는지 확인
2. key feature가 실제로 문제 해결에 도움이 되는지 확인

승부수가 있으면, 실험 결과 분석이 쉬워진다고 한다. ‘승부수가 되는 key feature 구현이 제대로 되었는지 확인한다’와 ‘key feature가 실제로 문제 해결에 도움이 되는지 확인한다.’라는 두 가지 가이드라인이 생겼기 때문이다. 이 다음 스텝은 두 가지 가이드라인으로부터 차근차근 밟아나가면 된다. 만약 key feature 구현은 제대로 되었는데, 문제 해결에 도움이 되지 않는다면, 내 가설과 실제 상황이 다르다는 것을 의미함으로, 어떻게 다른지 비교 분석해나가다보면, 다른 실마리가 보일 것이라고 한다. 승부수는 실험을 위해 어느 부분에 집중해야할지 알기 때문에, 실험 사이클도 짧게 가져갈 수도 있다고 한다. 또 승부수는 위의 세가지 질문들에 대한 답변도 될 수 있다고한다. 예를 들어, 마무리 조건을 어떻게 설정해야할지 모를 때는 ‘key feature’를 올바르게 구현하고, ‘key feature’가 실제 문제 해결에 도움이 되는지 확인하는 것으로 마무리 조건을 설정하면 된다고 한다.

Q1. 실험 결과를 어떻게 남겨야 다음 실험에 도움이 될 수 있을까?

Q2. 보완 실험은 어디서부터 진행하는 게 좋을까? (보완하면 좋을 점이 너무 많이 보인다.)

Q3. 마무리 조건을 어떻게 세우는 게 좋을까?

⇒ Key Feature에 기반해서 판단하면 된다!

승부수를 잘 세우려면?​

1. 내가 풀려는 문제(+환경)를 이해해야한다.
2. 기존 솔루션에 대해 이해해야한다.
3. 내가 구현하려는 솔루션에 대해서도 깊이 있게 이해해야한다.

가장 중요한 것은 내가 풀려고 하는 문제와 환경에 대해서 잘 이해하는 것이다. 아무리 솔루션이 좋아도, 내 문제에 맞지 않다면, 틀린 솔루션이다. 이 좋은 솔루션을 내 문제에 맞게 활용하는 것 또한 문제와 환경에 대한 이해가 필요하다. 두번째는 기존 솔루션에 대해 이해해야한다고 한다. 기존 솔루션을 모르면, 내가 구현한 새로운 솔루션이 아무리 좋다고 해도, 어떻게 기존 솔루션과 다른지, 그래서 어떻게 새로운 솔루션이 더 나은 건지 모르게 된다. 세번째는 내가 구현하려는 솔루션에 대해서도 깊이 있게 이해해야한다는 것이다. 무얼 중점적으로 구현해야하는지, 어떠한 부분이 내 문제 해결에 적합한지 알아야 실험의 진행 방향도 알 수 있다.

추가 조언​

번외로 실험에는 파이프라인 결함과 같은 엔지니어링적인 요소가 성능에 큰 영향을 미친다고 한다. 이럴 때는 단순하게 시작해서 점점 하나씩 추가해가는 식으로 개발을 하면, 예기치 않은 결함을 피할 수 있다고 한다.

또, key feature가 잘 작동하지 않을 때에는 솔루션 자체가 아닌 환경이 원인일 때도 있다고 한다. 실험이 실패했을 때, key feature가 잘 동작할 수 있는 환경이었는지도 검토해보라고 한다.

마지막으로, 실험 과정에서 많은 실패를 경험하게 될 텐데, 그저 실패에서 끝내기보단 하나하나 교훈을 얻어가면서 실험을 진행하다보면 결국에는 좋은 결과가 나올 수 있을 것이라고 한다.

마치며​

좋은 딥러닝 개발자(또는 딥러닝 리서치 사이언티스트, 딥러닝 연구원)로써 내가 길러야할 역량은 무엇일까 하는 고민을 자주 하곤 했다. 딥러닝 문제를 근본적으로 잘 해결할 수 있는 수학, 프로그래밍 능력, 최신 트렌드를 따라가는 부지런함, 당면한 문제 해결을 위해 딥러닝 기술을 잘 활용하는 창의성 등등 많은 역량들이 중요하겠지만, 그 중 실험을 잘 하는 것이 실무 문제 해결을 위해 정말 중요하다는 생각을 했다. 카카오 if 세션 ‘실험을 잘한다는 것’에서 어떻게 하면 실험이 잘 진행되지 않아도 실패로부터 교훈을 남길 수 있는지, 솔루션을 보완하기로 했다면 어디서부터 보완해나갈지, 그리고 얼마만큼 했을 때 멈춰야할지에 대해서 배웠다. 무엇보다 실험을 할 때에는 찾은 솔루션이 어떻게 당면한 문제에 적합한지 아는 승부수가 필요하다고 한다. 실험 결과가 안 나올 때면, 다음 스텝은 어디로 가야하지? 그냥 포기해야하나? 더 잡고 있어야하나? 하고 고민할 때가 많았는데, 그동안 있었던 고민들에 정말 중요한 단서가 된 세션이였다. 역시 개발자 컨퍼런스는 시간을 내서 봐야되는 듯 싶다. 그럼 이번 글도 좋은 자양분으로 삼아 정진하자.

소프트웨어 2.0​

나는 사람들이 뉴럴넷을 ‘머신러닝 툴박스 중 하나’라고 소개하는 것을 가끔씩 보곤한다. 뉴럴넷은 그만의 장점과 단점이 존재하고, 여기 저기에 쓰이며, 캐글 컴피티션 우승을 위해 사용되기도 한다. (지금은 캐글 컴피티션에 뉴럴넷을 사용하는 것이 보편적인 일이지만, 2017년 당시에는 그다지 보편적이진 않았나보다.)

불행히도, 그들의 이해는 나무만 보고 숲은 보지 못하는 것과 같다. 뉴럴넷은 그저 또 다른 분류기가 아니라 우리가 소프트웨어를 개발하는데 있어서 근본적인 변환을 일으킬 시작점이다. 뉴럴넷은 소프트웨어 2.0이다.

소프트웨어 1.0의 전통적인 “기술 스택”은 모두가 잘 알고 있다. 파이썬, C++과 같은 언어로 작성되어있으며, 프로그래머에 의해서 직접적인 명시로 이루어져있다. 코드의 라인들을 한줄 한줄 작성하면서 프로그래머는 자신의 의도를 프로그램 스페이스에 명시해야한다.

반면에, 소프트웨어 2.0은 뉴럴넷의 가중치들과 같이 훨씬 추상적이고 인간에게 친화적이지 않은(human-unfriendly) 언어로 작성된다. 뉴럴넷은 너무나 많은 가중치로 이루어져 있기 때문에 (보통 수백만 개의 가중치로 구성된다) 어떤 인간도 이런 코드를 작성하는 것은 불가능하다.(필자가 시도해봄)


대신에, 우리는 의도한 프로그램의 행동에 어떠한 목표를 상세해주고(e.g. ‘인풋 아웃풋예시를 충족하는’, 또는 ‘바둑 게임을 이기는’ 등의), 서칭할 프로그램 스페이스의 부분집합(subset)을 명시하는 코드 골격(rough skeleton)을 작성하며(i.e. 뉴럴넷 아키텍쳐와 같은), 또 이 프로그램 스페이스를 찾는데 연산 리소스들을 사용하여 프로그래밍 목표를 달성한다. 뉴럴넷의 경우, 이 서칭 과정을 역전파와 SGD(stochastic gradient descent)와 함께 효과적으로 이루어질 수 있는 프로그램 스페이스의 연속적인 부분집합을 찾는 것으로 제한한다.


이 비교를 더 구체적으로 하기 위해서, 사람이 직접 소스코드를 엔지니어링하는 소프트웨어 1.0(e.g. .cpp 파일들)에서는 바이너리 파일로 컴파일된다. 소프트웨어 2.0에서는 소스코드는 1)목표하는 행동 양상을 정의하는 데이터셋들과 2)대략적인(많은 디테일이 채워져야하는) 코드 골격을 제공하는 뉴럴넷 아키텍쳐로 이루어져있다. 최종적인 뉴럴넷을 컴파일하기 위해서는 데이터셋을 학습시켜 뉴럴넷에 녹여내야한다. 오늘날 가장 실용적인 적용사례에서, 뉴럴넷 아키텍쳐들과 학습 시스템들은 **원자재(commodity)**로써 입지를 굳혀가고, 대부분의 액티브한 ‘소프트웨어 개발’은 라벨링되있는 데이터들을 선별하고 가공 정제하는데(curating, growing, massaging and cleaning) 집중되어 있다. 그리고 이것은 우리의 소프트웨어에 반복해 적용하는 프로그래밍 패러다임을 본질적으로 전환시키고 있다. 개발 팀은 이에 따라 데이터셋을 수정하고 키우는 2.0 프로그래머들(데이터 라벨러들)과, 모델 학습코드 인프라, 분석, 시각화, 라벨링 인터페이스들을 감싸고 있는 코드들을 유지보수하고 반복하는 소수의 1.0 프로그래머들로 나뉜다.

파고들어보니, 대부분의 현실 문제들에서 직접 프로그램을 짜는 것보다 데이터를 수집하는 것(또는 더 일반적으로 말하자면, 목표하는 행동을 정의하는 것)이 더 쉬웠다. 데이터 수집이 직접 코딩보다 쉽다는 이유와 아래에서 설명할 소프트웨어 2.0 프로그램들의 장점들 때문에, 우리는 산업들이 1.0 코드에서 2.0 코드로 전환되는 것을 목격하고 있다. 소프트웨어 (1.0)은 세상을 먹어치웠고, 이제 AI(소프트웨어 2.0)은 소프트웨어를 먹어치우고 있다.

지금 일어나고 있는 전환(Ongoing Transition)​

지금 일어나고 있는 전환들의 몇몇 예들을 간단하게 살펴보자. 각 예들은 직접 코드로 작성하기에는 너무 복잡해 포기하고 있다가 2.0으로 스택 전환이 되면서 근 몇 년 사이에 발전을 보인 분야들이다.

**Visual Recognition(시각 인식)**은 ****머신러닝(e.g. SVM)이 살짝 가미된(sprinkled on top at the end) 엔지니어된 피쳐들로 구성되어있었다. 그리고 우리는 큰 데이터셋(e.g. ImageNet과 같은)과 CNN 구조들의 스페이스 서칭을 통해 좀 더 강력한 visual feature들을 찾았다. 최근에는 해당 뉴럴넷 구조를 직접 서칭하지 않고, 서칭 자체를 뉴럴넷에 맡기게 되었다.

**Speech Recogntion(음성 인식)**은 ****수많은 전처리와 gaussian mixture 모델들과 hidden markov 모델들로 수행되었지만, 오늘날에는 완전히 뉴럴넷으로 수행된다. Fred Jelinek이 1985년에 쓴 인용에 따르면, ‘언어학자를 자를 때마다, 우리의 음성인식 시스템은 더 좋아질 것이다.’

Speech Synthesis(음성 합성)는 다양한 봉합 메커니즘(stitching mechanism)에 의해 시도되었으나, 오늘날에 최신 모델들은 오디오 시그널 아웃풋 그 자체를 생성하는 큰 ConvNet(e.g. WaveNet)들로 대체되었다.

**Machine Translation(기계번역)**은 어절 기반의 통계 기술들(phrase-based statistical techniques)로 시도되었었지만, 이것 또한 뉴럴넷으로 대체되었다. 필자가 좋아하는 구조는 weakly supervised 또는 아예 unsupervised한 환경에서 소스 언어에서 학습된 단일 모델이 다른 타겟 언어로 번역되는 다국어 셋팅이다.

Games. 룰 기반의 바둑 프로그램은 예전에 개발되었었지만, 어떤 프로그램도 AlphaGo Zero를 이기진 못한다. 필자는 DOTA2나 Starcraft 또한 그러리라 믿는다.

Databases. AI 밖의 전통적인 시스템들은 이미 서서히 전환을 겪고 있었다. ‘The Case for Learned Index Structures’는 기존의 cache-optimized B-Trees 알고리즘을 메모리에서는 10배가량(order-of-magnitude) 절약하고 속도 측면에서는 70% 이상 앞지르는 뉴럴넷으로 데이터 관리 시스템의 코어 부분을 대체하였다.

소프트웨어 2.0의 이점들​

왜 우리는 소프트웨어 2.0으로 복잡한 프로그램들을 이동시켜야할까? 가장 쉬운 답은 실전에서 더 잘 작동하기 때문이다. 하지만, 이 스택을 선호하는데에는 다른 많은 편한 이유들이 있다. 소프트웨어 2.0(예시 ConvNet)과 소프트웨어 1.0(예시 제품 레벨의 C++ 코드 베이스)을 비교하여 소프트웨어 2.0의 이점들을 몇 개 살펴보자.

계산적으로 동질적이다(Computationally homongeneous)

표준적인 뉴럴넷은 본질적으로 행렬곱과 ReLU와 활성화 함수(thresholding at zero), 이 두 가지 연산으로 이루어진다. 훨씬 더 이질적이고(heterogeneous) 복잡한 전통적인 소프트웨어의 요소들(instruction set)과 비교해본다면?

적은 수의 코어 연산 단위(core computational primitives. e.g. 행렬곱)를 위해 소프트웨어 1.0만 적용하면 되기 때문에, 소프트웨어 2.0이 훨씬 정확도/퍼포먼스 개런티 측면에서 훨씬 쉽다.

연산에 담아내기 수월하다(Simple to bake into silicon)

결과적으로 뉴럴넷을 돌리기위한 기초 셋팅(명령어 집합; instruction set)이 비교적 간단하기 때문에, 이 뉴럴넷들을 실리콘(연산장치)에 담기는 훨씬 수월하다. e.g) 커스텀 ASICs, 뉴로모픽 칩 (인간의 두뇌와 유사한 컴퓨터 칩) 등등. 세상은 저전력으로도 돌아가는 지능이 보편화될 때 바뀔 것이다. e.g) 기학습된 ConvNet, 음성 인식기, WaveNet 음성 합성 네트워크 등을 전부 다 합친 작은 인공지능(protobrain)을 담을 수 있는 작고 저렴한 칩이 나올 수도 있다.

지속적인 러닝 타임(Constant running time)

뉴럴넷 전파의 모든 반복은 FLOPS의 정도와 동일하다. C++ 코드 베이스를 사용했을 때, 생길 수 있는 다양성(variability)은 0이다. 물론, 다이내믹 연산 그래프(dynamic compute graphs)를 가질 수는 있겠지만, 그럼에도 실행 플로우(execution flow)는 보통 굉장히 제한적이다. 그런 관점에서 소프트웨어2.0에서 우리는 의도치 않은 무한 루프에 빠질 일은 거의 없다고 보면 된다.

지속적인 메모리 사용(Constant memory use)

위 특징들과 비슷한 맥락으로 다이내믹하게 할당되는 메모리는 없기 때문에 디스크가 스와핑될 확률은 거의 없고, 코드를 뒤지면서 메모리 누수를 확인할 필요가 없다.

휴대하기 편하다(It is highly portable)

매트릭 연산들로 이루어진 이 시퀀스는 클래식한 바이너리 코드들이나 스크립트들과 비교했을 때 어떤 연산 구성이든 실행하기 훨씬 쉽다.

애자일하다(It is very agile)

만약 당신이 C++코드가 있고, 누군가 그 코드를 두배 더 빠르게 돌릴 수 있길 원한다면(퍼포먼스 손실을 감안하더라도), 새로운 스펙에 시스템을 튜닝하는 일은 결코 쉬운 일이 아니다. 하지만, 소프트웨어 2.0에서 우리는 뉴럴넷에 채널의 반을 삭제하거나 재학습해서 조금의 퍼포먼스 손실으로만 스피드를 두 배 이상 빠르게 만들 수 있다. 이건 마술이다. 거꾸로, 데이터나 컴퓨팅 파워가 더 생겼다고하면, 뉴럴넷의 사이즈를 더 키우거나 재학습함으로써 당신의 프로그램을 개선할 수 있다.

모듈들이 이상적인 전체로 녹아들 수 있다(Modules can meld into an optimal whole)

우리 소프트웨어는 보통 공공 함수들, API들, 엔드포인트들을 통해 통신하는 모듈들로 쪼갤 수 있다. 하지만, 따로 학습된 두 개의 소프트웨어 2.0 모듈들이 상호작용한다면, 우리는 쉽게 전체(whole)에 대해 역전파할 수 있다. (한 개 이상의 태스크가 다른 뉴럴넷들도 역전파를 통해 가중치 업데이트를 공유할 수 있다는 뜻) 만약 당신의 웹브라우저가 자동으로 low-level 시스템 명령어들(low level system instructions)을 10 스택 다운 재 디자인해서 웹페이지들을 로딩하는데 훨씬 더 높은 효율을 냈다고 생각해보라. 얼마나 멋진 일인가. 아니면 컴퓨터 비전 라이브러리(e.g. OpenCV)에서 너의 특정한 데이터를 자동으로 튜닝해준다면? 소프트웨어 2.0에서 이런 건 기본이다.

당신보다 낫다(It is better than you)

그리고 마지막으로 가장 중요한 것은 뉴럴넷은 사람들이 만들어낸 어떠한 코드들보다(지금도 이미지/비디오와 소리/음성에서 사람의 코드가 차지하는 비율은 극히 적다) 좋은 코드이다.

소프트웨어 2.0의 한계​

2.0 스택은 단점들도 있다. 최적화 후에 결과물로 나온 거대한 네트워크들은 분명 잘 작동하긴 하지만, 어떻게 작동하는지에 대해서는 알지 못한다. 많은 응용 분야들에서 우리는 이해하지(설명하지) 못한 99% 정확도의 모델 또는 이해 가능한(설명 가능한) 90% 정확도의 모델을 선택할지 결정해야한다.

2.0 스택은 비직관적이고 당황스러운 방법으로 실패할 수도 있다. 아니면 더 쵝악은 ‘조용히 실패'하는 것이다. e.g) 학습 데이터 중 bias(편향, 여기서는 학습목표와 다른 데이터 특징이라고 이해하면 될 듯하다.)를 조용히 반영하는데, 이는 대부분의 경우 데이터가 수십만 개에 다다르기 때문에 정확히 분석하거나 평가하기 힘들다.

마지막으로, 우리는 이 스택의 이상한 특징들에 대해서 아직 알아가는 중이다. 예를 들어, adversarial examples와 adversarial attacks는 이 스택의 비직관적이 성향을 나타낸다. (여기서 adversarial이란 의도적으로 뉴럴넷에 학습목표와 다른 데이터를 학습에 적용하여 학습목표로부터 벗어나게하는 것을 말한다. 더 알아보고 싶다면 링크 참조)

2.0 스택에서의 프로그래밍​

소프트웨어 1.0은 우리가 쓰는 코드다. 소프트웨어 2.0은 평가 기준(’학습 데이터를 올바르게 분류해줘’와 같은)에 근거한 최적화에 의해 쓰여진 코드다. 최적화는 사람이 작성한 코드들보다 훨씬 더 나은 코드를 찾을 수 있기 때문에, 어떤 셋팅에서던 프로그램 자체는 분명하진 않지만, 반복해서 퍼포먼스를 평가할(e.g. 이미지 분류 잘했어? 바둑 게임 이겼어?) 수 있는지가 이번 전환(Transition)에서 중요한 주제가 될 것이다.


트렌드를 살펴보는 관점(lens)은 중요하다. 만약 당신이 소프트웨어 2.0을 단순히 ‘분류를 꽤 잘하는 뉴럴넷 또는 머신러닝 기술 중 하나'로 인식하기보다, 새롭고 떠오르는 프로그래밍 패러다임으로 인식한다면, 더 많은 예측들(extrapolations)이 뚜렷해질 것이고 더 할 수 있는 것들이 보일 것이다.

1.0 코드를 적기 위해 사람을 도울 어마어마한 양의 툴들을 만들어냈다.(IDE 구문 강조 기능, 디버거, 프로파일러, 함수 서칭, 깃 통합 등등) 2.0 스택은 데이터셋들을 축적하고, 마사징하고 정제하는 프로그래밍으로 이루어질 것이다. 예를 들어, 뉴럴넷이 몇몇의 어렵거나 흔하지 않은 케이스들에서 실패한다면, 우리는 코드를 적기보단 더 많은 라벨링 샘플을 적용하여 문제를 해결할 것이다. 데이터셋들을 축적하고, 시각화하고, 정제하고, 라벨링하고, 소싱하는 워크플로우를 돕는 소프트웨어 2.0 IDE를 누가 만들 것인가? IDE가 데이터 예시 단위 손실함수에 근거하여 잘못 라벨링된 이미지들을 띄워주거나, 예측을 통해 라벨링(프리라벨링)하는 것을 돕거나, 아니면 뉴럴넷 예측의 불확실성에 근거하여 라벨링할만한 데이터 예시를 제시해줄지도 모른다.

같은 맥락에서, 깃허브도 소프트웨어 1.0 코드를 위한 아주 성공적인 플랫폼(home)이다. 소프트웨어 2.0에도 깃허브와 같은 공간이 있을까? 2.0의 경우 저장소는 데이터셋이 되고 커밋들은 라벨들의 추가 및 수정이 되겠다.

전통적인 패키지 매니져들과 pip, conda, docker 등과 같은 서빙 인프라는 우리가 바이너리를 더 잘 배포하고 구성할 수 있도록 돕는다. 소프트웨어 2.0 바이너리를 효과적으로 배포하고, 공유하고, 임포트하고, 더 잘 작동하게 하기 위해서 우리는 어떻게 해야할까? 뉴럴넷에서도 conda와 비슷한 게 있을까?

짧게 말해서, 반복적인 평가가 가능하고 저렴하며, 알고리즘 자체가 명시적으로 디자인하기 어렵지 않다면, 어떤 도메인이던 소프트웨어는 점차 널리 퍼질 것이다. 소프트웨어 개발 생태계와 이 새로운 프로그래밍 패러다임이 어떻게 적응할지. 많은 기회들이 널려있다. 그리고 장기적으로 봤을 때, 이 패러다임의 미래는 우리가 AGI를 개발할 때, 소프트웨어 2.0으로 작성될 것이 점점 명확해지고 있기 때문에 밝다.

Takeaway​

Andrew Karpathy가 이 글을 낸 2017년은 구글 딥마인드에서 이세돌을 이겼던 알파고의 바둑실력을 초월하는 알파고 제로가 출시된 년도이다. 그리고 뉴럴넷의 획기적인 성능향상을 일구어낸, 이제는 자연어 처리부터 이미지, 음성 인식, 강화학습 등 거의 모든 분야에서 사용되는 Transformer가 세상에 알려진 년도기도 하다. 2022년 현재 돌이켜봤을 때, 위에 적어놓은 Andrew Karpathy의 모든 말들은 어쩌면 너무나 당연한 말일지도 모르겠다. 그의 말 중 많은 부분이 현실로 이뤄졌고 이뤄지는 중이다. 마치 높은 언덕에 올라가 저 멀리를 내다보는 선구자처럼. 가끔은 기술만 파고들다가 시야가 좁아지는 경우가 있다. 그럴 때에는 한걸음 물러서서 시대적 흐름으로써 ‘내가 하고 있는 일이 가지는 의미와 내가 사회에 기여할 수 있는 바는 어떤 것이 있는지’ 한 번쯤 생각해볼 여유가 필요하다.

• Image Segmentation Model(이미지 분할 모델)은 픽셀 단위의 클래스 분류를 통해 이미지 내 물체를 탐지하는 모델이다.

Image Segmentation Model 중 하나인 DeepLabV3. 픽셀별 값을 예측해 물체를 탐지한다.

• segmentation model의 대표적인 모델 UNet. 2015년에 생명공학 분야에서 MRI나 전자현미경 이미지의 탐지를 위해 처음 나온 논문이다. (UNet: Convolutional Networks for Biological Image Segmentation) 벌써 7년이나 된 모델이고, 현재는 segmentation 태스크에서도 적용되기 transformer와 같은 다른 우수한 성능을 내는 모델들이 많지만, UNet은 여전히 segmentation 태스크를 가장 직관적인 방법으로 설계한 구조라고 할 수 있다.

• 이 UNet에 대해서 이렇게 글을 쓰게 된 계기는 현재 참여하고 있는 kaggle competition(UW-Madison GI Tract Image Segmentation)에서 UNet을 다시 공부하게 되었기 때문이다. 정확히는 2차원 이미지를 처리하는 vanilla UNet에서 변형된 3차원 MRI 이미지를 처리하는 2.5D UNet이다.

  참고 : UNet으로부터 파생된 UNet 구조들

  • Eff-UNET
  • UNET+, ++, 3+ (NestedUNet)
  • 3D UNet
  • 2.5D UNet

포켓몬 이브이는 품고 있는 돌의 속성에 따라 다양한 종류로 진화하게 된다. UNet이 이브이라면, 2.5D UNet과 다른 UNet 변형 모델들은 그 진화형 쯤 되지 않을까 싶다.

• 이번 글은 UNet에 대해서 간단하게 설명하고, UNet의 변형 모델인 2.5D UNet에 대해서 설명하고자 한다.

UNET​

모델 구조​

이름 그대로 인풋 이미지가 왼쪽에서 오른쪽으로 U자형 곡선을 타고 내려갔다가(contracting path;downstream;downsampling;encoder 등 다양한 이름으로 불린다) 올라가는 것(expanding path; upstream;upsampling;decoder)을 확인할 수 있다.

높이로 봤을 때 총 5개의 층으로 구분되는데, 층이 한 칸씩 낮아질 때마다 featuremap의 hxw 사이즈는 반으로 줄어든다.(갈색 화살표;2x2 max pool). 반대로 층이 한 칸씩 높아질 때에는 featuremap의 hxw 사이즈는 두 배가 된다(초록색 화살표;2x2 up-conv).

각 층에서 featuremap은 두 번의 3x3 conv과 ReLU를 거치는데, 각 연산마다 hxw 사이즈는 2씩 줄어들고(패딩이 없기 때문에 커널 사이즈(3x3)에서 하나 작은 2만큼의 사이즈가 줄어든다), 채널 수는 64부터 2배씩 증가한다.

e.g) 첫번째 레이어 피쳐맵 사이즈 $(L_{featuremap} - L_{kernelsize}+2L_{padding}) / L_{stride} + 1 = (572 - 3 + 2*0)/1 + 1 = 570$

그리고 한가지 주목할 점은 내려갈 때(downstream) 각 층의 마지막 피쳐맵이 보존되었다가, U자 모양에서 마주보고 있는 올라갈 때(upstream)의 featuremap과 결합(skip architecture)된다는 점이다. 예를 들어서, 첫번째 층의 마지막 피쳐맵(hxwxc = 568x568x64)은 동일한 높이의 맨 마지막 층의 피쳐맵(hxwxc=392x392x128)과 합쳐진다. 피쳐맵의 크기가 서로 다르기 때문에 더 큰 왼쪽의 피쳐맵 사이즈를 오른쪽의 피쳐맵 사이즈와 맞게 잘라준다. (e.g 568 ⇒ 392) 이렇게 서로 먼 위치의 피쳐맵을 더해주는 것은 초기 연산 단계(얕은 층, low-level)의 피쳐맵이 후기 연산 단계(깊은 층, high level)에까지 골고루 영향을 미치도록 설계한 구조이다. ResNet에서 residual layer(skip connection)로 가중치 소실 문제를 해결한 것과 비슷한 맥락이라고 생각하면 된다.

residual layer; layer를 거치면서 소실될 수도 있는 가중치를 identity layer로 뒷단에 다시 한번 더함으로써 gradient vanishing 문제를 어느정도 해소한다.

손실함수(loss function)​

손실함수로는 cross-entropy를 사용한다. 분류 모델이 인풋으로 들어온 이미지 한 장에 대해서 softmax값을 도출한다면, segmentation 모델인 UNet의 경우, 이미지를 이루는 각 픽셀에 대해서 softmax값을 갖는다.

이미지 분류 모델 기본적인 형태. softmax값(각 클래스에 대한 예측확률을 담은 아웃풋)을 도출한다.

이미지를 이루는 픽셀들 각각에 대해서 softmax값을 도출한다. prediction의 색깔은 클래스를 의미한다. e.g)갈색 : 소| 분홍색 : 나무|초록색 : 잔디| 파랑색 : 하늘

2.5D UNet​

• 의학 데이터에는 3D 데이터(volumetric)가 많이 존재한다. MRI는 대표적인 3D 데이터이다. 3D 데이터를 2D로 자르지 않고, 3D 자체로 사용해야하는 이유는 2D로 자르면 중복되는 정보가 많고, 3D 데이터로 구성되어 있을 때여야만 의미있는 데이터일 경우가 많기 때문이다. 예를 들어서, MRI로 촬영한 복부 사진의 단면 이미지들보다 온전한 3D 이미지 한 장일 때 더 유용한 정보인 것과 같다.

MRA(Magnetic Resonance Angiography)로 스캔한 동맥 3D 이미지.

• 3D 이미지의 세번째 차원값은 volume과 pixel을 합친 voxel이라고 부른다.
• 모델을 거친 3D 이미지 인풋의 voxel은 해당 위치에 타겟이 있을 확률값이 된다. 2D 이미지에서 UNet의 픽셀 결괏값이 해당 클래스에 대한 확률인 것과 같은 맥락이다.
• 이 3D 이미지를 핸들하기 위해서 2D에 차원을 하나 더 붙인 3D 컨볼루션을 사용할 수 있지만, 3D 컨볼루션은 연산 비용이 굉장히 큰 편이다.
• 그래서 2.5D UNet에서는 3D 컨볼루션을 사용하지 않고 효율적으로 3D 데이터를 핸들하고, 3D 차원에서 타겟값을 예측하는 3D image segmentation을 소개한다.

방법​

1. 3D 이미지를 다양한 방향에서 투영시켜 이미지 시퀀스로 만든다. 투영시키는 방법은 보통 Maximum Intensity Projection이나 Radon Transform을 사용한다.
2. 이미지 시퀀스로 만든 이 프로젝션 이미지들에 2D 컨볼루션을 다시 적용하고, 학습가능한 3D 재구축 알고리즘을 적용하여 3D 이미지로 다시 만든다.
3. 이미지 시퀀스를 타겟 오브젝트에 다시 투사해서 복원하는 과정에서 그림자와 같은 얼룩이 발생하는데, 이를 학습가능한 filtration(여과 연산)으로 개선한다.
4. 학습가능한 재구축(learnable reconstruction algorithm) 알고리즘을 통해 3D 이미지로 아웃풋을 도출한다. 다양한 방향에서 선형 backprojection을 적용한다.

이미지 재구축 연산자

모델 구조​

• M : MIP(maximum Intesity Projection)
• U : 2D Unet
• F : learnable filtration
• R : reconstruction operator using p linear backprojections for directions
• T : fine-tuning operator (average pooling followed by a learnable normalization followed by the sigmoid activation)

모델 구조

논문에서는 위의 3D 이미지 학습 방법론에, m개의 projection 이미지들에 대해서 전부 학습시키기엔 메모리 소모가 크니, 두가지 path를 사용한 random 2.5D 기법을 추가한다. projection 이미지 전체가 아닌 랜덤으로 일부를 뽑아 학습 효율을 극대화하는 방식이다.

path1. $\hat{y}_{aux}$

path1에서는 projection 이미지들의 각도를 랜덤으로 일부분 뽑아 UNet에 태우고, learnable filtration과 reconstruction 과정을 거쳐 3D 아웃풋을 뽑는다. UNet, learnable filtration, reconstruction 과정 모두 학습된다.

path2. $\hat{y}$

path2에서는 3D 인풋 x에서 나온 MIP 이미지들의 모든 프로젝션 방향을 생성한다. 그리고 UNet을 태운 후, m개의 프로젝션 이미지에 적용한다. 여기서 UNet은 학습되지 않고 고정된(frozen) 상태이다. m개의 UNet 아웃풋을 가지고, filtration F와 파인튜닝 T를 학습할 수 있게 된다.

손실함수​

이렇게 아웃풋으로 나온 $\hat{y}_{aux}$ 와 $\hat{y}$ 는 정답지 y와 dice-loss로 학습에 반영된다.

마무리​

• 복부를 찍은 MRI 영상 이미지에서 대장, 소장, 위장을 찾는 캐글 컴피티션에 참여하게되었다. 이 MRI 데이터는 복부의 여러 단면(slice)들로 이루어진 3D 이미지들이다. 이 3D 이미지로부터 물체를 탐지하는 태스크는 3D Image Segmentation이라고 한다.
• 3D Image Segmenetation 문제를 해결하기 위해 kaggle Discussion을 살펴보다, 2.5D UNet이라는 모델을 찾게 되었다.
• 2.5D UNet은 3D 컨볼루션을 사용하지 않고, 다양한 각도에서 타겟을 2D로 투사해(MIP;Maximum Intesity Projection) 이미지 시퀀스를 만들어 UNet에 태운 후, 다시 3D로 복원해서 3차원 내의 타겟 위치를 탐지하는 방식을 사용한다.
• 3D 컨볼루션을 사용하지 않기 때문에 연산량 부담이 적고, 여기에 논문은 다양한 각도를 랜덤 샘플링하여 UNet과 3D 재구축 웨이트들을 학습시키는 path1과 모든 프로젝션 방향에 대해 프리즈된 UNet과 3D 재구축 웨이트를 학습시키는 path2, 이 두 개의 방법으로 모델을 학습시킨다.
• MIP나 reconstruction operator, filtration operator와 같은 방법에 대한 자세한 설명이 없어서 조금 더 서칭 후, 업데이트하도록 하겠다.

MultiModal​

불과 5년 전만 해도 컴퓨터가 글을 읽는 일은 무리였다. 물론 단어 몇 개나 미리 지정해둔 트리거 신호를 사용해서 글자를 인식하는 경우는 있었지만, 한 이미지에 몇 백개가 넘는 글자를 오탈자 하나 없이 다 맞추는 것은 불가능에 가까웠다. 게다가 몇 백개의 글자를 포함한 이미지가 몇 만장이라면? 정확도는 현업에서 사용할 수 있는 수준이 아니였다. 하지만, 딥러닝의 발전과 함께 글자를 읽는 OCR(Optical Character Recognition) 특성 모델들이 발전하면서 이제 AI는 글자를 꽤 잘 본다. 꽤 높은 정확도와 사람이 따라올 수 없는 속도로 문서 이미지를 보고 그 안에 포함된 글자들을 내뱉는다.

네이버 OCR 결과 예시

보고 읽는다는 것​

하지만, 한 가지 아쉬운 점은 ‘**읽다’**는 것은 ‘본다’와는 다르다는 점이다. ‘읽다’라는 행위는 문장 성분 하나하나를 독립적으로 보는 것 뿐만 아니라 문맥(context)을 함께 이해하는 것이다. 대상이 단어라면, 단어를 구성하는 글자들을 유기적으로 이해하는 과정이 필요하고, 대상이 문장이라면, 문장을 구성하는 단어들 각각과 그 단어들이 서로 맺는 관계를 이해하여 문장을 인식하는 과정이 필요하다. (그런 의미에서 책을 읽는 건 우리가 생각한 것보다 훨씬 어려운 일일지도 모른다) 아래 그림을 한 번 살펴보자.

본다 ≠ 읽는다

사진의 간판에 뭐라고 적혀있는걸까? 이 사진을 ‘보기'만 했을 때, 추출해낼 수 있는 단어는 ‘보’, ‘설’, ‘렁'이다. 나무에 어렴풋이 가려진 글자가 두 개정도 더 있는 것 같지만, 해당 이미지를 기존의 OCR프로세스에 돌렸을 때, 나올 수 있는 결과는 ‘보', ‘설', ‘렁' 뿐일 것이다. 하지만, 사람은 이 이미지를 보고 나무에 가려져 보이지 않는 ‘탕'까지 유추해낼 수 있다. 보이는 글자 ‘설렁'을 보고 ‘탕’까지 읽어낸 것이다. 이것이 문맥을 이해했을 때 나올 수 있는 결과이다. 이처럼 사람은 ‘보고 읽는' 반면에, 현재(어쩌면 이미 과거의) OCR 프로세스는 ‘보는' 행위에 그친다는 단점이 있다.

이런 단점을 해결하고자 다른 데이터 도메인을 함께 활용하는(e.g: text + vision, vision + speech) multi-modal 연구들이 진행되고 있다. multi-modal 모델의 예로는 문장이 말한대로 그려주는 OpenAI의 Dall-E나 LG에서 개발중인 엑사원 등이 있다.(아래는 직접 뽑아본 Dall-E 이미지 아웃풋들이다.)

white horse face with carrot on the forehead, oil painting

van gogh style armored cat

armored maltese in battlefield

한 이미지에는 픽셀뿐만 아니라, 텍스트로써 이해할 수 있는 문맥들이 존재한다. 컴퓨터 비전과 자연어 처리를 융합한 이번 페이퍼의 모델 SemiMTR(Semi-Supervised Multimodal Text Recognition)은 이미지로 한 번, 그리고 텍스트로 다시 한 번 이미지를 인식한다.

Semi-Supervised​

딥러닝과 빅데이터 시대가 도래하면서 무엇보다 데이터의 중요성이 강조되었고, 그만큼 방대한 양의 데이터가 공개되었다. CNN과 같은 지도학습 모델은 데이터와 상응하는 답안지(라벨링)를 필요로 한다. 문제는 데이터의 양이 커질수록, 자연스럽게 컴퓨터가 답안지로 사용할 라벨링 비용 또한 커진다는 것이다. 쉴새없이 쏟아지는 데이터의 양에 비해 라벨링은 턱없이 부족하기만 하다. 그럼 어떻게 해야할까? SemiMTR모델은 1)가지고 있는 데이터를 더 효율적으로 활용하여 모델을 학습시키는 방법과, 2)모델을 사용해서 라벨링을 대체하는 방법을 활용한다.

1. 가지고 있는 데이터를 더 효율적으로 활용하여 모델을 학습시키는 방법

데이터를 더 효율적으로 활용하기 위해서 컴퓨터만 이해할 수 있는 공간에다가 가지고 있는 데이터들을 나열시킨다. 데이터를 나열시키면서 데이터 간의 관계(거리)를 하나씩 학습해나간다. 예를 들어, 학습이 제대로 이뤄졌다면, 단어 ‘king’과 ‘queen’ 간의 관계(거리+방향)는 ‘man’과 ‘woman’의 관계와 비슷하다는 걸 알게 된다. 독립적인 데이터 포인트 하나에 대해서 하나의 라벨링으로 학습하는 것이 아니라, 두 개 이상의 데이터 간의 관계를 학습해나가는 것인데, 이를 contrastive learning 기법이라고도 한다.

1. 모델을 사용해서 라벨링을 대체하는 방법

모델이 일정 이상의 성능을 확보했다고 가정하자. 99.999% 맞출 거라는 확신이 있는 데이터들만 따로 모아놓는다. 그리고 그 데이터들을 모델이 인식하지 못하지만 사람은 인식할 수 있는 수준의 변형(augment)시킨다. 그렇게 되면, 결과물로 모델이 생성한 99.999% 확신할 수 있는 라벨링과 모델이 아직 학습하지 못한(사람은 인식하지만) 패턴을 가진 데이터 먹거리가 생긴다. 라벨링이 없어도 모델이 자급자족할 수 있는 수단이 생긴 것이다.

아래는 논문을 읽고 요약한 내용이다.

Abstract​

• 최근까지 텍스트 인식기를 학습시키기 위한 실제 텍스트 이미지 데이터셋이 부족했었음
• 학습을 위해 합성 데이터를 사용한 지도 학습에 초점을 뒀었음
• 라벨링 없는 실제 텍스트 이미지들이 대량 방출됨
• 이 리소스들을 활용하기 위해, semi-supervised 방법들이 나오기 시작함
• 아주 소수의 방법들만 vision/language를 활용한 multi-modal 구조를 가지고 있음.
• 이 간극을 메꾸기 위해, multimodal 방식의 텍스트 인식기를 소개함 (SemiMTR)
• 해당 방법은 추가적인 학습 절차를 삼가하고, 현 3단계 multi-modal 학습 방식을 유지함
• 우선 vision 모델을 사전학습 시켜 self-supervised 학습과 supervised-학습을 합침
  • 더 자세히는, 기존의 visual representation learning algorithm을 확장시키고 글자인식을 위한 contrastive-based 방식을 소개함.
• 텍스트 뭉치들(corpus)를 사용해서 language 모델을 학습한 후에는 전체 네트워크를 약(weakly)과 강(strongly) 증강(augmented)된 텍스트 이미지들 간의 시퀀셜, 글자레벨, consistency regularization을 활용하여 파인튜닝함
• 새로운 셋업에서, consistency는 각 modality에서 각각 시행됨
• 추가 실험에서는 우리의 방법이 현 학습 스키마들의 정확도를 넘어서고, 텍스트 인식 벤치마크에서 최신 성능을 보여주는 것을 확인할 수 있었음

Introduction​

• ABINet이라는 모델 사용
  • 세 단계로 이루어져있는데, 이 단계들로 라벨링이 없는 실제 데이터들을 학습에 활용할 수 있음
    • supervised vision model pretraining
    • bidrectional language representation learning of the language model
    • supervised fine-tuning of the fusion model and entire
  • vision model을 학습시키기 위해서 label과 unlabel 데이터들을 contrastive learning으로 활용하는데,
    • contrastive learning의 핵심 아이디어는 같은 이미지이지만 다르게 증강된 이미지들의 representation 간의 동의율과 다른 이미지들 간의 분리율을 최대화하는 것
  • 더 정확히는 SeqCLR 기법을 적용함.
    • SeqCLR은 seq2seq contrastive learning 기법임 (원래는 손글씨 인식용으로 나옴)
    • 이 기법 적용을 위해, 더 로버스트한 transformer-based 백본을 채택했고, 더 강한 색깔-텍스쳐 증강기법을 적용했다.
  • 파인튜닝 단계에서는
    • 약증강과 강증강된 텍스트 이미지로부터 증강된 실제 텍스트 이미지 간 시퀀셜, 글자-레벨, consistency regularization을 진행한다.
    • 약증강 이미지로부터 인공 가짜-라벨시퀀스를 생성하고, 같은 이미지의 강증강 버젼을 전체 모듈을 학습시킬 때 라벨 시퀀스로 사용한다.
  • 실험을 통해, 각 모덜리티가 스스로 자급자족 학습(teacher of itself)하고, 각각의 학습을 위한 psuedo-label을 생성할 때, 가장 학습이 잘 진행된 것을 확인했다.

Related Work​

• Vision-language multimodal text recognizer
  • SCATTER - custom decoders for vision and language
  • SRN - global semantic reasoning module
  • SEED - offered a semantics enhanced encoder-decoder framework
  • VisionLAN - provide vision model w/ language capability
  • ABINET - vision-language multimodal architecture that possesss an explicit language model which can be pretrained on text corpus
• Semi-supervised learning for text recognition
  • case1. seq2seq domain adaptation techniques between labeled and unlabeld datasets
  • case2. seq2seq contrastive learning for visual representations learning
  • psuedo-labeling methods to utilize unlabeled images
  • confidence-based criterion for filtering noisy pseudo-labels
• Consistency Regularization
  • self-supervised learning에 널리 쓰이는 기술
  • core idea : model predictions should remain the same under each semantic-preserving perturbations of the same image
  • case1. enforces the network to be agnostic to some transformations and disturbances
  • case2. proposes a consistency regularization in semi-supervised settings by using noise injections and augmentations on the unlabeled examples
  • FixMatch : classification task에서 unlabeled 데이터에 대해 psuedo-labeling을 한 consistency regularization함.
    • strongly augmented version으로부터 나온 predictions와, 같은 이미지지만 weakly augmented version으로부터 나온 pseudo-label과 매칭하도록 학습한다.

Architectural Background​

1. pretrain vision model
2. pretrain language model via a version of masked language modeling
   • mask the attention maps instead of input characters
3. end2end fine tuning stage via supervised cross-entropy losses on the vision, language, and fusion predictions

SemiMTR: Multimodal Semi-Supervised Learning​

vision model ⇒ vision features ⇒ vision prediction ⇒ (gradient stop) ⇒ language model ⇒ contextual features ⇒ combine visual + contextual features ⇒ fusion prediction

Vision Model Pretraining​

• 사전학습에 unlabeled real data 포함
• 마지막 학습 phase에 unlabeled data만 사용하는 competitive semi-supervised methods가 vision model의 성능을 개선하였다
• SeqCLR + Transformer-based backbone

• 각 이미지를 두 번 augment ⇒ 각 visual backbone 과 projection head에 feed
• instance-mapping 함수 적용 ⇒ 각 증강된 이미지의 representation 시퀀스를 만들어 sub-word 단위의 contrastive learning이 가능하게 함
• 각 평행한 브랜치에서 라벨링 데이터의 visual prediction의 supervised loss 계산

사전학습은 6개의 빌딩 블럭으로 이루어져있음.

stochastic data augmentation

• 인풋 이미지에서 두 개의 augmented view 생성

Visual backbone

• ResNet + Transformer units

Projection head

• optional auxiliary network
• transforms the visual backbone features into a lower dimensional space

Instance-mapping function

• unique block for seq2seq predictions divides each feature map into a sequence of separate representations over which the contrastive loss is computed
• 기존 contrastive 방법과 달리, 전체 이미지들이 아닌 시퀀스를 이루는 개별 성분들 간의 contrasting이 가능하게 합니다.
• window-to-instance mapping 방식을 사용

  • feature map들의 배치가 NxFxHxW ⇒ NxH*WxF가 되도록 펴고,

  • adpative average pooling 적용해서

  • flatten된 각 featuremap으로부터 T개의 독립된 representation 추출하여 Z 세트로 모음

    $Z=AdaptiveAvgPool2d(Flatten(P))$

  • 이 함수는 두번 호출되어 각 augmented view로 적용

Contrastive Loss

• 같은 인풋은 augmentation과 상관없이 더 가깝게, 다른 인풋은 더 멀게 학습하기 위한 손실함수
• Noise Contrastive Estimation(NCE) loss function

cosine distance

Vision decoder and supervised loss

• SeqCLR 과 contrastive learning methods에서 supervised training phase는 self-supervised stage가 끝나고 진행됩니다. 하지만, semiMTR은 학습 스테이지들이 늘어나는 걸 막고, 통합된 semi-supervised training scheme을 진행합니다.

Consistency Regularization for Fusion Model Training​

• pseudo labeling을 사용하여 추가 재학습 과정이 필요한 다른 semi-supervised learning 방법과는 다르게
• self-supervised learning을 위해서, 파인튜닝에 더 적합한 sequential, character-level, consistency regulaization을 진행
• weakly-augmented version에서 라벨 추출
• strongly-augmented version에다가 추출한 라벨 적용해서 학습

Stochastic strong and weak augmentations

• 여러 color-texture augmentation method를 실험함
• 그중 가장 효과있는 방법 채택

Sequential consistency regularization loss

• 첫번째 padding token location (denoted by $N^{weak}$)에서 먼저 teacher’s sequential prediction을 prune하고,
• 각 글자들에 독립적으로 consistency regularization 적용

• 1(*>t) = threshold operator ⇒ teacher label의 신뢰도가 일정이상일 때만 학습에 반영
• L은 cross-entropy 또는 KL-divergence
• 6.2에선 threshold, label값 종류(prob vector or one-hot)의 영향에 대해서 실험

Teacher and Student Modalities

• 보통 teacher student decoder에서 consistency regularization을 계산하는 방법은 전체 네트워크의 단일 디코더를 통해서이지만,
• multimodal text recognition scheme에서는 각 modality가 각각의 decoder를 가지고 있으므로, 각각이 teacher 또는 student가 될 수 있음.
• 6.2에서는 각 configuration을 실험해 각 modality가 pseudo label을 생성하는 teacher가 되어야하는지 유무를 체크함

Experiments​

1. analyze capability of current synthetic and real-world datasets
2. compare our method with leading semi-supervised methods

Datasets

Comparison to State-of-the-Art Methods

Ablation Studies​

6.1 Vision Model Pretraining

Two-stage vs unified training

• 기존 contrastive learning ⇒ contrastive-based pretraining & fully-supervised fine-tuning 2 stages 였음
• contrastive learning objective와 supervised cross-entropy loss를 합치는 unified training stage로 진행

6.2 Consistency Regularization

Sequnetial consistency regularization loss

• cross-entropy vs KLDivergence
• soft label vs one hot label
• stopping the teach gradients and using a threshold

Teacher-student modalities

• 각 modality가 teacher 또는 student가 될 수 있는데, 각 modal끼리 teacher-student 관계가 가장 높은 성능을 보였다.

Conclusions and Future Work​

• SemiMTR은 첫번째 multimodal이자 semi-supervised learning 알고리즘을 사용한 text recognition 모델이다
• contrastive-based visual representation learning과 sequential, character-level consistency regularization을 적용했다.
• label 데이터 뿐만 아니라 unlabel 데이터도 활용하지만, 기존 모델의 3 스테이지를 그대로 유지했다.
• 다른 모델들보다 높은 성능을 보여준다
• 다른 리서처들에게 unlabel 데이터를 어떻게 활용할지에 대한 생각을 열어줬다.

OCR에 대한 설명과 카카오에서 구성하고 있는 OCR파이프라인을 소개했다. Text Detection과 Text Recognition 사이에 Script identification 을 두어 인식하는 이미지가 어떤 언어인지 구별한다고 한다. 이렇게 언어를 구별하는 단계를 두면, 언어별 특화된 모델 웨이트를 사용해서 더 광범위한 데이터 범위와 언어별 더 정확한 예측이 가능해진다.

그 후에, 인식한 단어들을 기반으로 해당 단어가 어떤 개체(entity; 사람, 조직, 시간 등 일반화할 수 있는 범주)에 속하는지 인식하는 NER(Named Entity Recognition) 과 텍스트 간 알맞게 묶어주는 Text Clustering , 그리고 등록된 템플릿에 단어들을 매칭하는 Template Matching 으로 후처리를 했다고 한다.

이 글은 어떻게 OCR 파이프라인을 AS-IS(현재 상태)에서 TO-BE로 개편하기 위해 어떤 점들을 고쳤는지에 대해 주목하고, 개편 전과 후의 모델 구조를 살펴보려고 한다.

(개인적으로 조금(보통은 1~2% 이내의) 나은 성능 향상을 위해 이미 성능이 어느정도 나오는 파이프라인을 과감히 놓아주고 새로운 체크포인트에서 출발을 하는 것은 결코 쉬운 일이 아니었을 거라고 생각한다. )

OCR 개편 목표​


새로운 시도를 위해 목표를 확실하게 정의하는 과정은 필수다. 텍스트 탐지 모델의 목표는 높은 정확도, 글자 레벨 박스, 모델을 통한 텍스트 클러스터링, 텍스트 방향 예측, 그리고 간단한 후처리였고, 텍스트 인식 모델의 목표는 마찬가지로 높은 정확도, 병렬 예측(더 빠른 연산을 위해서), 더 적은 리소스, 그리고 간단한 후처리였다고 한다. 그럼 텍스트 탐지 모델부터 어떤 식으로 개편했는지 알아보자.

텍스트 탐지 모델(STD)


AS-IS​

• 나열한 as-is 조건 중에 부합하는 모델 중 가장 유명한 모델은 아무래도 CRAFT인듯하다.

Object Detection

• 이미지 내에 물체의 영역을 탐지하는 물체 탐지 모델은 박스 좌표를 추출하는 방식에 따라, Segmentation-based와 Regression-based로 나뉠 수 있다.

1. Segmentation-based

• Segmentation-based는 원본이미지에 대응되는 Featuremap을 뽑아서 pixel 단위 처리로 물체 영역을 뽑는 방식이다.
• Segmentation-based Text Detction의 대표적인 모델, CRAFT는 적절한 파라미터 조절로 word-level과 character-level 텍스트 탐지가 가능하다.
• 아래 그림처럼 모델을 거친 각 글자들은 heatmap(아보카도처럼 생긴 동그라미)으로 표현된다. 정 가운데 빨강이 1에 가까운 값, 가운데에 멀어질수록 0에 가까운 파랑색 값을 갖게 된다. 이는 글자가 실제로 위치할 확률(probability)로도 해석이 가능하다.

[출처] : CRAFT: Character-Region Awareness For Text detection

• 뽑은 heatmap 위에 일정값 이상을 갖는 픽셀들끼리 합치고, 그 합친 영역을 구분하는 박스를 그리면 텍스트 영역 탐지가 완성된다.
• regression-based 방식처럼 박스 형태에 얽매이지 않고, pixel 단위로 텍스트 영역을 탐지하기 때문에 다양한 물체 형태를 예측 가능하다는 장점이 있다.
• 모델에서 나온 결과로부터 물체 영역을 탐지하는 후처리가 시간이 오래 걸린다는 단점이 있다.
• 한 이미지에 텍스트가 오밀조밀 모여 있을 가능성이 높은 문자 탐지 태스크의 특성상, segmentation-based 기법을 사용할 경우, 한 텍스트 그룹이 다른 텍스트 그룹과 겹치게 되는 경우가 생길 수 있다. 아래 그림처럼 'PLEASE', 'TURN', ... 등의 텍스트들은 개별의 텍스트 박스로 잡혀야 마땅하지만, heatmap 영역 간격이 가까우면 하나의 박스 형태로 잡히는 단점이 있다.


1. Regression-based

TO-BE​

• 그렇다면 to-be는?
• 조건별로 나열해서 모델을 추측해보자.
• TO-BE 조건들

  • one-shot anchor-free model

    • anchor free는 카카오에서 어떤 모델을 사용하는지 추측하는 데에 가장 큰 단서였다.
    • 물체 탐지(object detection) 모델은 크게 regression-based와 segmentation-based로 나뉜다.
    • regression-based는 다시 anchor-based와 anchor-free로 나뉜다. 그 중 anchor-based는 이미지 인풋을 격자 셀로 나누고, 각 격자마다 미리 정의해둔 k개의 앵커 박스들을 할당해서 물체의 박스 좌표를 표현한다.

      • 아래 그림을 예로 들면, 4x4 격자 셀에 2개의 앵커박스가 존재한다.

      • 박스 좌표는 보통 4개로 표현하기 때문에 아웃풋 형식은 4x4x(4*2)의 행렬이 된다.

      • 격자 셀 각각에 대해서 2개씩의 앵커박스, 그리고 각 앵커박스는 4개의 좌표로 구성

      • 한 격자 셀에 같은 클래스가 두 개 이상 존재하는 경우와 같은 앵커박스 형태가 두 개 이상 존재하는 경우는 이 anchor box구조가 커버하지 못하는 예외케이스이긴 하지만, 격자 셀 개수가 많아질수록 언급한 경우들을 드물다.

      • 학습을 위한 라벨링의 경우, 각 격자셀에 대해서 정답 박스 영역(gt box)과 앵커박스별 IoU를 구해서 positive 또는 negative, 아예 겹치지 않는 경우 background로 설정한다.

    

    • anchor-based detection는 사전정의된 앵커박스의 정보에 따라 성능이 바뀌는 문제와, 정확한 박스영역 탐지를 위해서는 더 많은 앵커박스가 필요하다는 문제, 그리고 각 그리드셀의 앵커박스 수만큼 (예: 50x50 grid x 80 anchor boxes=200k) gt를 포함하는지 안 하는지(positive인지 negative인지) IoU를 일일히 계산해야한다는 연산적 부담이 있다.
    • 이를 보완하기 위해 나온 것이 anchor-free model. anchor free의 대표적인 모델 FCOS(Fully Convolutional One Stage Object Detection) 모델을 살펴보자.

    FCOS

    	anchor-based	anchor-free
    격자 셀 라벨링	정답 박스와의 IoU 계산해서 positive 또는 negative 설정	정답 박스 안에 속하면 positive, 정답 박스가 여럿일 경우 ambiguous
    regression loss	L1 Loss	IoU loss
    classification loss	Binary Cross Entropy Loss	Focal Loss
    박스 좌표 regression 방법	anchor box와의 중심으로부터 박스값 보정	gt box 경계값으로부터의 거리

    • Centerness라는 개념 도입. heatmap과 유사
    • anchor based는 anchor box와의 offset을 계산하지만, FCOS는 중심점으로부터 거리를 계산한다.
    • L_cls는 focal loss, L_reg는 IoU loss
    • anchor box scale 대신 FCOS는 bounding box regression의 범위를 제한

  • Direct Regression

    • Indirect Regression은 앵커박스로부터 박스좌표를 보정하는 과정
    • Direct Regression은 중점으로부터 박스좌표를 바로 보정하는 과정
    • Segmentation-based에서 Direct Regression. 이는 박스를 구한 후, offset으로 박스 영역을 텍스트 영역에 좀 더 fit하게 깎는 과정이 있을 것 같다.

  • No NMS

    • Non-Maximum-Suppression을 빼고도 정확한 박스 후보군을 뽑을 수 있는 방법?

    • centerness라는 개념을 사용하면, 텍스트 영역 내의 모든 픽셀값이 다 같은 값을 갖는 것이 아니라, 중앙에 가까울수록 더 높은 값, 멀수록 더 낮은 값을 갖게 된다. min(l*, r*)와 max(l*, r*) 간 격차가 적다는 것은 중앙에 가깝다는 의미이다.

      

    • MT는 NMS 제거

  • Both Word & Character prediction

    

    • 사실 이 과정이 가장 궁금했다. CRAFT도 나온 heatmap으로부터 heatmap이나 affinity threshold를 조정하면 단어에서 글자 단위 탐색이 가능하지만, 정확하다고 하기엔 조금 무리가 있다.
    • Direct Regression이 character 단위로 결과를 뽑으면, offset으로 텍스트 영역을 깎는 과정에서 character들을 word로 합치는 과정이 있을 것 같다..?


• centerness
• offset
• regression

텍스트 인식 모델(STR)


AS-IS​

• CNN + Self-Attention + CTC
• NO TPS
• Variable Length Input
• Full Floating Point Precision

TO-BE​


• 이 구조는 사실 ViTSTR과 동일한 구조다.
• 한 가지 인상적이였던 것은 이미지 패치를 16x16이 아닌 텍스트 방향에 맞춰서 (보통 왼쪽에서 오른쪽으로 예상) column-wise하게 잘랐다는 점이다.
• STD 단계에서 orientation 방향을 구하는데, 이 값을 STR 단계에서 어떤 식으로 활용하는지 궁금하다.
  • 딱 떠오르는 방법은 orientation 방향에 맞게 왼쪽에서 오른쪽으로 회전.
• 듣고 보니 당연한 얘기인 것 같다.(훌륭한 논문의 개념을 다 읽고 나면, 마치 너무나도 당연해서 여태껏의 다른 방법들은 틀린 듯 느껴지는 것처럼)

학습 방법

STD​


• L1 Loss(예측값과 GT 차이를 절대값으로 계산) : 아마 STD에 들어가는 값 중, [Regression(박스 좌표), Offset] 에 사용될 듯

• BCE(Binary Cross Entropy Loss) : orientation과 centerness

• OHEM : Online Hard Example Mining의 약자. 학습 이미지의 픽셀 loss값 기준 임계값보다 큰 픽셀들을 hard sample, loss 값이 작은 픽셀들을 easy sample로 구별한다. negative pixel(easy sample) 양이 positive pixel의 양이 3배(조절 가능한 값)보다 많을 경우, negative pixel의 값은 전체가 아닌 top n개만큼(n < #negative pixel)만 반영한다.

  hard sample는 학습에 상대적으로 많이 반영하고, easy sample은 적게 반영한다는 컨셉.

  • OHEM이 사용된 예 (CRAFT)

    # 해당 코드는 [CRAFT-Reimplementation](https://github.com/backtime92/CRAFT-Reimplementation/blob/craft/loss/mseloss.py)에서 가져온 코드
    import numpy as np
    import torch
    import torch.nn as nn
    
    class Maploss(nn.Module):
        def __init__(self, use_gpu = True):
    
            super(Maploss,self).__init__()
    
        def single_image_loss(self, pre_loss, loss_label):
            batch_size = pre_loss.shape[0]
            # sum_loss = torch.mean(pre_loss.view(-1))*0
            # pre_loss = pre_loss.view(batch_size, -1)
            # loss_label = loss_label.view(batch_size, -1)
    
            positive_pixel = (loss_label > 0.1).float()
            positive_pixel_number = torch.sum(positive_pixel)
            positive_loss_region = pre_loss * positive_pixel
            positive_loss = torch.sum(positive_loss_region) / positive_pixel_number
    
            negative_pixel = (loss_label <= 0.1).float()
            negative_pixel_number = torch.sum(negative_pixel)
    
            if negative_pixel_number < 3*positive_pixel_number:
                negative_loss_region = pre_loss * negative_pixel
                negative_loss = torch.sum(negative_loss_region) / negative_pixel_number
            else:
                negative_loss_region = pre_loss * negative_pixel
                negative_loss = torch.sum(torch.topk(negative_loss_region.view(-1), int(3*positive_pixel_number))[0]) / (positive_pixel_number*3)
    
            # negative_loss_region = pre_loss * negative_pixel
            # negative_loss = torch.sum(negative_loss_region) / negative_pixel_number
    
            total_loss = positive_loss + negative_loss
            return total_loss
    
        def forward(self, region_scores_label, affinity_socres_label, region_scores_pre, affinity_scores_pre, mask):
            loss_fn = torch.nn.MSELoss(reduce=False, size_average=False)
    
            assert region_scores_label.size() == region_scores_pre.size() and affinity_socres_label.size() == affinity_scores_pre.size()
            loss1 = loss_fn(region_scores_pre, region_scores_label)
            loss2 = loss_fn(affinity_scores_pre, affinity_socres_label)
            loss_region = torch.mul(loss1, mask)
            loss_affinity = torch.mul(loss2, mask)
    
            char_loss = self.single_image_loss(loss_region, region_scores_label)
            affi_loss = self.single_image_loss(loss_affinity, affinity_socres_label)
            return char_loss + affi_loss
    

STR​


SeqSimCLR​

실제 라벨된 데이터로부터 Data Augmentation을 진행하면서 SeqSimCLR 기법을 사용했다고 한다.

SimCLR의 개념은 이렇다.

1. 인풋 이미지에 서로 다른 데이터 증강 기법을 적용한다. (예를 들어, 하나는 색 변환, 하나는 rotation)
2. 두 이미지를 네트워크에 태워서 Representation으로 표현한다.
3. 다시 조그만 네트워크에 태워서 Projections로 뽑은 후, Contrastive Loss로 유사도 손실함수로 계산한다.

![[출처] : https://zablo.net/blog/post/understanding-implementing-simclr-guide-eli5-pytorch/](Untitled 12.png)

https://deep-learning-study.tistory.com/731

seqfixmatch​

https://github.com/google-research/fixmatch

https://ainote.tistory.com/6

Reference

if(kakao) 2021 : OCR 모델 개편 진행기

Sequence-to-Sequence Contrastive Learning for Text Recognition

PlugNet: Degradation Aware Scene Text Recognition Supervised by a Pluggable Super-Resolution Unit

AE TextSpotter: Learning Visual and Linguistic Representation for Ambiguous Text Spotting

MT: Multi-Perspective Feature Learning Network for Scene Text Detection

What's wrong with the Bottom-up Methods in Arbitrary-shape Scene Text Detection?

https://neverabandon.tistory.com/m/60

PAN++와 기존 STD 모델 간의 Precision, Recall, F1 Measure 비교

PAN++와 기존 End2End text spotting 모델 간의 F-measure와 Inference Speed 비교

PAN++ 모델의 탄생 배경​

텍스트 탐지가 어려운 이유는 탐지해야하는 텍스트의 형태가 매번 다르기 때문이다. 빳빳한 A4용지 위에 또렷하게 프린트된 텍스트는 탐지가 쉬운 반면, 종이가 구겨져있다거나, 잉크가 흐릿하다거나, 아니면 글자가 일직선이 아닌 다른 형태(폴리곤)로 적혀져있거나 하는 예외케이스들이 존재하기 때문이다.

텍스트 탐지 방법은 크게 1)예측값을 텍스트 탐지 박스 좌표로 잡는 regression-based와 2)텍스트 탐지 영역을 픽셀단위로 예측하는 segmentation-based로 나뉜다. 텍스트 형태가 일정한 사각형이 아닌 폴리곤의 형태일 때, 아래 그림 (b)처럼 탐지 박스의 네 좌표를 결괏값으로 갖는 regression based는 폴리곤 영역을 제대로 잡기가 힘들다. 좀 더 다양한 텍스트 형태를 탐지하기 위해서 고안된 segmentation based 방법은 아래 그림 (c)처럼 형태 자체는 잘 잡지만, 구분되어야할 텍스트 라인이 합쳐져서 잡힌다는 문제점이 있다. ‘we won’t go back,’ 과 ‘we will fight back!’ 텍스트는 각각 다른 텍스트 인스턴스로 분리되어 잡혀야 맞지만, 텍스트 간의 간격이 가깝다보니, 여러 개의 텍스트 인스턴스들을 하나의 텍스트 박스로 인식(conglutination)하는 문제점이 발생한다.

PAN++(선행연구 PSENet, PAN)는 위 문제점을 해결하기 위해 고안된 모델로, 서로 다른 텍스트 인스턴스를 구분짓기 위해서 텍스트 영역 라벨링을 텍스트 영역, 텍스트 커널, 그리고 텍스트 인스턴스, 총 세 가지로 구분하여 모델학습을 진행하고, Pixel Aggregation 기법을 사용해서 텍스트 인스턴스들을 구분한다.

** Regression-based와 Segmentation-based가 궁금하다면 이 링크 참조

(a) 원본 이미지 (b) regression based 탐지 결과 (c) segmentation based 탐지 결과 (d) PAN++(segmentation based) 탐지 결과

Model Architecture

PAN++ 모델의 모델 구조는 크게 backbone, neck, head 세 단계로 이루어져있다.

PAN++ 모델 구조

1. backbone​

인풋 이미지로부터 featuremap을 추출하는 백본망으로는 resnet18, 50, 101을 제공한다.

백본망의 결과값으로는 인풋 이미지에 상응하는 featuremap이 총 4판이 나오는데, 각각 인풋 이미지 해상도의 1/4, 1/8, 1/16, 1/32를 갖는다. (다운샘플링하는 컨볼루션(kernel_size = 1, stride = 2)를 여러번 거칠수록, 해상도는 줄어들고, feature level은 높아진다. 해상도 1/32 featuremap은 해상도 1/4 featuremap보다 해상도는 낮지만, 더 high-level feature를 갖는다.)

이렇게 4가지의 해상도로 나누어서 featuremap을 추출하는 이유는 다양한 feature-level의 표현력(representation)을 학습에 잘 반영하기 위함이다.

백본 인풋 (a)과 아웃풋 (b). 결괏값은 왼쪽부터 오른쪽으로 인풋이미지의 1/4, 1/8, 1/16, 1/32 해상도를 갖는다.

2. neck​

4개의 featuremap은 컨볼루션 레이어를 거쳐 채널수를 128개로 고정되고(그림의 Reducing Channel 단계), N_stk개의 FPEM 모듈을 거쳐 인풋의 1/4 해상도와 512개의 채널을 갖는 아웃풋으로 변환된다. FPEM(Feature Pyramid Enhancement Module)은 마찬가지로 다양한 feature-level의 표현력을 학습에 반영하고, 신경망 층이 깊어짐에 따라 학습되어야할 값들이 희미해지는(gradient vanishing) 문제를 보완하기 위한 모듈이다.

** FPEM에 대해서 좀 더 궁금하다면 이 링크를 참조

3. head​

neck에서 받은 $H/4*W/4*512$ 형태의 featuremap(위 그림 (e) $F_f$ )을 활용해서 Text Region, Text Kernel, Instance Vector에 대한 세 가지 아웃풋을 예측한다. 세 가지 아웃풋을 종합해서 Pixel Aggregation 기법으로 최종 아웃풋에 해당하는 Text Masks를 도출한다. 그리고 Text Masks로 얻은 텍스트 영역(Masked RoI; $F_f$ 위 Text Masks 영역을 투영(reflect)시킴)에서 텍스트가 어떤 문자인지 예측하는 텍스트 인식(STR) 단계를 수행한다. 이 중 우리는 Text Region, Text Kernel, Instance Vector가 무엇인지 그리고 어떻게 Pixel Aggregation을 통해 최종 아웃풋을 도출하는지 집중해서 살펴볼 것이다.

PAN++의 아웃풋 형식

텍스트 이미지를 라벨링(또는 어노테이션)하는 방법은 여느 이미지 라벨링과 비슷하다. 텍스트 인스턴스의 단위를 어떻게 설정할지나 라벨링에 [UNK]와 같은 특수한 태그를 추가해서 데이터 처리에 활용하는 등 세부적인 사항에서 그 편차가 있을 수 있겠지만, 텍스트 영역에 4점 이상의 박스를 그리고, 텍스트 내용으로 라벨링하는 것이 일반적이다. 원하는 결과를 도출하기 위해서 이 보편적인 라벨링을 PAN++에서는 어떤 식으로 활용하는지 주목하자. (라벨링 형태 자체를 변환하기 위해서는 많은 비용이 들기 때문에, 딥러닝 모델들은 기존의 라벨링을 잘 활용해서 독창적인 기법을 만들어내곤 한다.)

PAN++는 이 보편적인 라벨링을 Text Region, Text Kernel, 그리고 Instance Vector, 총 세 가지의 값을 활용한다.

• Text Region : 라벨링된 텍스트 박스와 동일하다. Segmentation map에 cv2.drawContours 함수로 마킹한다. 형태는 원본 이미지 기준 $H/4*W/4*1$ 형태다.
• Text Kernel : 서로 다른 텍스트 인스턴스들이 가까워서 하나의 인스턴스로 잡히는 문제(conglutination)를 해결하기 위해서 고안되었다. 아래의 그림처럼 Text Region을 텍스트 박스 중심으로 응축(shrink)시킨다. shrink 구현은 pyclipper 모듈을 활용한다. 형태는 원본 이미지 기준 $H/4*W/4*1$ 형태다.
• Text Instance : Text Kernel과 마찬가지로 위 conglutination 문제를 해결하기 위해서 고안되었다. 각 텍스트 박스는 고유한 Text Instance이다. Segmentation map에 cv2.drawContours 함수, for loop와 enumerate 함수로 서로 다른 픽셀값으로 색칠하여 고유한 인스턴스를 마킹한다. (영역이 겹칠 경우, 뒤에 오는 인스턴스 넘버로 마킹?) 형태는 원본 이미지 기준 $H/4*W/4*D$ 형태다. (코드 상에는 $D=4)$

텍스트 라벨링에서 text kernel을 도출하는 방법

아래는 PAN++의 아웃풋 예시이다.

원본 이미지

Text Region

Text Kernel(Text Region보다 중심으로 응축된 영역)

Text Instance (고유한 텍스트 박스 마스킹)

손실 함수

이제 우리에게 Text Region, Text kernel, 그리고 Text Instance에 대한 정보가 생겼다. 이 정보를 Train 단계에서 어떻게 활용해야 가까운 두 개의 텍스트가 겹치지 않고 서로 다른 텍스트 인스턴스로 구분되면서 텍스트 영역을 충분히 커버할 수 있을까?

text kernel i(ki; 파랑)는 text region만큼 확장하지만, 다른 커널(주황색)과 겹치지 않아야한다.

탐지 손실함수는 text loss, kernel loss, 그리고 emb loss 총 세 종류의 loss의 합으로 이루어진다.

• text loss : 텍스트 영역에 대해서 dice loss 적용. dice loss는 예측값과 정답값 간 겹치는 영역을 2로 곱한 후, 예측값과 정답값을 더한 값을 나누는 손실함수로 segmentation based 모델에서 자주 쓰인다.

• kernel loss : 텍스트 커널에 대해서도 마찬가지로 dice loss를 적용한다.

• emb loss : Text kernel은 Text Region이 응축된 영역이기 때문에, 다른 인스턴스와 겹칠 일은 거의 없다. 이 텍스트 커널에서 픽셀 영역을 조금씩 확장해나가면 어느 지점에서는 Text Region을 충분히 커버하지만, 거기서 더 나아가게되면 다른 Text Instance와 겹치게 된다. 모델의 학습방향은 Text Kernel이 1) 다른 인스턴스 영역과는 구분(discrimination loss)되면서, 2) Text Region만큼은 확장(aggregation loss)하는 것이다.

  aggregation loss

  

  F(p) = instance vector, g(K) = instance vector of text kernel. D1은 instance vector와 instance kernel 간의 거리를 나타낸다

  discrimination loss

  

  background와 인스턴스 간의 거리와 서로 다른 인스턴스 간의 거리를 나타낸다. 서로 다른 인스턴스 간의 거리를 계산하기 위해서 torch.repeat 과 torch.eye 를 활용한 것이 주목할만 하다.

Pixel Aggregation

위 손실함수를 잘 반영해서 학습하면, 꽤 정교한 아웃풋(text region, kernel, instance)을 얻을 수 있다. 더 정교한 결과를 위해서 PAN++는 inference단계에서는 pixel aggregation 기법을 사용한다.

1. 결괏값(코드상 kernels, emb)에 대해서 connected component 기법을 적용한다. (connected component 기법은 같은 값을 갖는 인접한 픽셀들을 그룹화해주는 기법이다) 그룹화된 pixel들은 text kernel과 같은 의미를 갖는다.
2. 각각의 kernel은 4방향으로 픽셀을 확장해나간다(BFS와 같은 방식). 탐색하는 픽셀의 instance vector 간의 유클리디언 거리가 d보다 작을 경우에만 확장하여, 다른 instance들과 겹치는 일이 없도록 한다
3. 근접 픽셀이 없을 때까지 두번째 스텝을 반복한다.

해당 pixel aggregation 코드는 Cython으로 짜여있다. 파이썬에서 cv2나 numpy 라이브러리를 활용해도 충분히 구현이 가능하지만, 속도가 느린 편인데, 해당 코드는 정말 빠르다. Cython으로 다른 python code들과 함께 구동가능하다는 점도 주목할만하다.

Outro

End2End Text Spotting 모델 PAN++의 텍스트 탐지(STD) 부분에 대해서 살펴보았다. PAN++는 실제로 다른 우수한 텍스트 탐지 모델들(CRAFT)과 비교했을 때, 굉장히 성능도 잘 나오고 빠른 편이다. 모델 구조, 라벨링을 활용하는 방법, 커스텀한 손실함수, 그리고 inference 시 후처리까지 아주 꼼꼼하게 설계되어 있기 때문에 가능한 성능이지 않나 싶다.

해당 논문과 모델 코드까지 천천히 뜯어보면서 논문 하나(모델 하나)를 만들기 위해서 저자들이 얼마나 많은 실험과 머리를 쥐어짜는 고심을 했을지 생각해보았다. 모델을 구성하는 단계마다 최신/최선의 기법들을 적용해서 0.001%의 정확도라도 더 끌어올리려고한 노고가 느껴졌다. 이 글에 논문의 최대한 많은 내용을 담으려고 노력했지만, 모델의 STR 부분, 모듈 구성 시의 builder 패턴, 학습 시의 ohem 기법, pixel aggregation의 cython 익스텐딩 등 커버하지 못한 부분도 많다. (누락된 부분에 대해서는 차차 살펴보면서 머릿속에 익히려고 한다)

한편으로 코드를 천천히 뜯어보고 정리하면서 배운 점 또한 많다.

• 모델을 구성하는 모듈들은 어떻게 정리하는 게 깔끔한지 알게 되었다. (CRAFTS 코드 구현할 때, 가장 힘들었던 부분이 코드가 지저분한데, 방대한 양을 어떻게 정리해야할지 모르겠었다는 것)
• 가지고 있는 데이터를 활용해서 원하는 아웃풋을 만들어내는 것도 모델 성능을 높이기 위한 하나의 방법이라는 것을 알게 되었다. (높은 정확도까지 보장된다면 새로운 논문이 나올지도..?)
• 그 외에 자잘한 함수들(torch.Conv2d 의 groups 인자, torch.repeat 과 torch.eye 로 두 개의 for문 처리 등등..)

OCR(Optical Character Recognition)은 이미지 속의 글자를 읽는 기술이다. 조금 생소할 수도 있는 이름인 OCR은 생각보다 우리의 일상 속 깊숙이 자리하고 있다. OCR은 신용카드, 사업자등록증이나 주민등록증, 또는 영수증 등 필요한 서류 정보를 촬영만 하면 전자 정보로 변환 가능하게 해준다. 또, 차량번호판 정보를 추출해서 불법 주차나 속도 위반 차량을 파악하기도 한다. 그리고 아직 종이 문서에서 전자 문서로의 전환이 진행중인 기업들이 한 장씩 문서 내용을 직접 체크해야하는 부담을 줄여 업무 자동화를 가속화해준다. 유입되는 데이터의 크기가 커지고 있는 빅데이터 시대에 사는 우리에게 '사람의 눈을 일일히 거치지 않고 이미지에서 필요한 텍스트 정보만을 추출할 수 있게 되었다'라는 것은 빅데이터를 우리의 편의에 맞게 더 잘 활용할 수 있는 옵션이 생겼음을 의미한다.

2019년, AI 자동차수리비 산출시스템 프로젝트를 진행중이였을 때였다. 파손된 차량의 사진을 휴대폰 촬영해서 앱에 업로드하면 수리 금액이 얼마가 나올지 예측하는 이미지 딥러닝 모델을 개발 중이였다. 여느때처럼 퇴근하고 집에 돌아가는 길, 같은 지하철을 타는 팀장님에게 이런 질문을 했었다.

'저희 프로젝트처럼 사물 자체가 아닌 사물의 손상 심도까지 파악할 정도로 이미지 모델의 성능이 좋다면, 글자들을 인식하는 것도 상품화가 가능하지 않을까요?'

그 때 팀장님의 답변은 아직도 기억에 남는다.

"이미지 모델의 형태가 점점 발전하고 있기는 하지만, 결국 이미지 안의 물체의 영역을 탐지하고, 해당 물체가 미리 정의해놓은 클래스의 범주 내에서 분류되는 이미지 모델의 틀은 쉽게 변하기 힘들어요. 한글로 나올 수 있는 한 글자짜리 조합만 생각해도 대략 6, 7천개(링크)쯤은 될 거고, ****거기다 종이 한장에 보통 글자가 못해도 300개 400개 쯤은 될 거예요. 그럼 그 문서 한 장에 나오는 글자들을 모두 올바르게 맞출 확률은 얼마나 될까요? 그리고 이 글자 읽는 태스크를 컴퓨터로 대체하려면 적어도 100장 이상, 아니 10,000장 정도는 거뜬히 처리할 줄 알아야 현장에 사용이 가능할 텐데, 그렇게 된다면 정확도는 얼마 정도가 보장될까요? 그런데 또 모르죠. 나중에는 그 정확도를 확 올릴 수 있는 기술들이 나올수도..."

자고 일어나면 최신 기술들이 뒤바뀔만큼 미친 속도로 새로운 기술들이 쏟아져 나왔고, 왜 문서를 AI 이미지 모델로 처리해서 정확도를 뽑는 게 힘든지 설명을 해주셨던 팀장님과 우리 팀은 2년째 OCR 제품을 개발중이다.

OCR. 컴퓨터가 사람 대신 글을 읽어주는 일.​

OCR. 이미지를 보고 컴퓨터가 인식할 수 있는 문자로 변환하는 일.

OCR은 어떻게 이뤄질까?

회사마다 어떤 모델을 쓰고, 어떤 단계에 기준을 두고 모델을 설계하는지는 조금씩 다르겠지만, 보통 OCR은 2단계 또는 3단계로 이루어진다. 2단계는 이미지 중 텍스트 영역을 탐지하는 1)문자 영역 탐지(STD)단계와, 탐지한 영역의 텍스트를 인식하는 2)문자 인식(STR)단계, 그리고 문서 이미지의 경우 인식한 텍스트 정보를 분류하고 구조화하는 3)문서 이해(Document Understanding) 단계까지 3단계로 구성된다.

1. 문자 영역 탐지 (Scene Text Detection;STD)​

이미지에는 한 개 이상의 문자 영역이 존재할 수 있다. 정확한 문자 인식을 위해 문자가 속하는 영역을 탐지한다. 잘못 잘린 문자 영역은 문자 인식의 성능을 떨어트리지만, 반대로 알맞게 잘린 문자 영역은 문서 이해(Document Understanding) 단계의 알맞은 단위로 작용한다.

Scene Text Detection 관련 최신 모델들의 정보는 **여기**에서 찾을 수 있다.

2. 문자 인식 (Scene Text Recognition;STR)​

STD(문자 영역 탐지)단계에서 잘라낸 문자 이미지로부터 컴퓨터 문자로 인식하는 단계이다. 보통 글자 하나 하나를 개별로 인식하는 것이 아니라, 1개 이상의 글자로 이루어진 단어 단위로 인식한다. 글자가 1개 이상이다 보니, 글자와 글자 간의 순차적 종속성(sequential dependency)이 존재한다. 예를 들어, 앞에 두 글자가 '아이스크'였다면 그 다음에 오는 글자는 '림'일 확률이 높다. 이런 순차적인(sequential) 특성을 활용하기 위해서, Bi-LSTM, Attention, 그리고 최근에는 Transformer 모델을 활용한다. (이 글에서 Sequential Data를 처리하기 위한 모델들에 대해서 읽을 수 있다.)

STR 관련 최신 모델들의 정보는 여기에서 찾을 수 있다.

3. 문서 이해 (Document Understanding)​

STD와 STR 단계를 무사히 거쳐 원하는 컴퓨터 문자를 추출해냈다고 하자. 다음엔 뭐가 필요할까? 추출해낸 문자들을 컴퓨터가 이해할 수 있는 방식으로 정리하는 작업이 필요하다.

아래 표 이미지를 중앙에 위치한 글자들로 추출해냈다고 하자. 사람은 맨 윗쪽 행이 각 열들을 나타내는 열이름(column name)이라는 것, 그리고 맨 왼쪽의 열은 행이름(row name), 그리고 옆의 행들은 각 행들의 정보를 나타낸다는 사실을 쉽게 알아차릴 수 있다. (Matt의 수학 점수는 60점, 물리학 점수는 65점) 하지만, 컴퓨터는 그렇지 않다. 중앙 글자들(정보)로부터 구조화하는 과정이 필요하다. 올바른 문서 이해 과정을 거친다면, 아래 그림의 세번째 표를 뽑아낼 수 있을 것이다. 참고로, 테이블화한다는 것은 [('Name' : 'Matt', 'Math' : 80, 'Physics' : 65, 'History' : 80, 'English' : 74), ...]와 같이 json, xml 등과 같은 포맷으로 구조화할 수 있음을 의미한다. 여기서 중요한 점은 글자에 대한 정보 뿐만 아니라, 글자의 위치, 그리고 그 글자 주변의 표 성분, 즉 사람이 문맥에 맞춰 글자를 읽기 위해 시각적으로 사용하는 정보들이 문서 이해 과정에서 고려되어야 한다는 것이다.

문서 이해 관련 최신 모델들의 논문 정보는 **여기**에서 찾을 수 있다.

OCR을 하면서 생길 수 있는 문제들​

물론 위 3단계를 문제없이 진행하면 이상적이겠지만, AI 모델에 99.9999%의 정확도는 있더라도 100% 정확도는 없다. 각 단계별 인식 측면에서 다양한 문제들이 발생한다.

1. 문자 영역 탐지(STD) 단계​

목적 : 인식 대상 텍스트를 이미지로부터 캡쳐

1. 글자 미탐지/오탐지

   1. 오탈자 발생 ⇒ 문서 이해 단계에서 정보가 빠지는 경우 발생

   2. 오탐지(글자가 아닌 오점을 문자로 인식한 경우)

      ⇒ 인식 단계에서 잘못된 글자로 인식

2. 탐지 박스 단위

   1. 원래 하나의 박스를 두 개 이상의 박스로 잡는 경우
   2. 반대로 두 개 이상의 박스를 하나로 잡는 경우

   ![$10,000를 ['$10', '000']으로 탐지했다. 상금 만 달러가 10달러로 줄어든다면 아무도 좋아하지 않을 거다.](misdetection-example.png)

2. 문자 인식(STR) 단계​

목적 : STD단계에서 캡쳐한 텍스트 이미지를 전자 문자로 알맞게 변환

1. 글자 방향에 따른 오인식

   • 왼쪽에서 오른쪽으로 나열된 단어들만 학습하다가 다른 방향으로 나열(수직이나 오른쪽에서 왼쪽 나열)된 단어 이미지가 들어오는 경우

     

     

2. 학습 데이터에 기반한 인식 오류

   • 학습한 폰트와 아예 다른(인식이 불가능할 정도의) 폰트를 사용한 텍스트인 경우

   • 숫자 '0'과 자음 'ㅇ', 숫자 '1'과 모음 'ㅣ' 처럼 문맥을 고려하지 않으면 구분하기 힘든 단일 문자들

     

3. 문서 이해 단계 (Rule-Based일 경우)​

목적 : 이미지에서 추출한 정보들을 구조화

1. 기존 유형과 다른 문서 구조에 대한 인식 오류
   1. 같은 문서 유형이지만 문서 구성이 다른 경우
2. 앞에 STD와 STR에서 오류가 발생한 경우

Outro​

OCR 진행 시 위에 적어놓은 문제 외에도 많은 문제들이 존재한다. 그 중, 현재 OCR 모델 구조 상 해결이 불가능한 문제들이 생기면 머리가 아파진다. 예를 들어, STD모델의 학습 데이터 탐지 단위가 '단어'였는데, '글자' 단위의 탐지가 필요한 경우라거나 Wild-Scene 이미지 인식 시에 사용중인 STR모델의 아웃풋에는 없는 '글자 방향'이 필요한 경우. 그럴 때면, '현재 모델 구조를 유지한 채로 성능을 고도화한다' 첫번째 옵션과 '새로운 모델을 사용한다' 두번째 옵션 중에 갈팡질팡하게 되는데, 이는 결코 쉬운 과정이 아니다.

뭐가 맞을지는 아무도 모른다. 기간 안에 에러를 감안하고도 도달할 수 있는 최고 성능을 뽑아내는 것 외에 정해진 건 없다. 몇 년 전만 해도 내가 OCR제품을 개발하고 있으리라곤 상상도 못 했던 것처럼. 다만, 한 가지 모델만 오래 사용하다보면, 그 모델이 이미지를 처리하는 방식과 뽑는 아웃풋에 사고 구조가 굳어지는 경우가 있는데, 사고가 굳지 않도록 계속해서 새로운 모델 구조를 공부해나가는 과정이 필요하다.