들어가며

새로운 모델을 찾아 복잡한 깃헙 레포를 읽고 계신가요? 어지러운 파일 확장자들 사이에서 헤메고 있진 않으신가요? 미궁같은 디렉토리 안에서 한눈에 보이는 지도가 필요하진 않으신가요? 내가 만든 서비스를 사람들이 편하게 드나들게 하기 위해선 어떻게 하면 될까요? 항상 쳇바퀴도는 상황에 지친 당신을 이제부터 GPT 가 도와줄 겁니다. GPT 코드 분석 으로 복잡하게 얽혀있는 스크립트들을 한 눈에 지도처럼 펼쳐보는 방법 함께 보시죠!

GPT 코드 분석 살펴보기

이 글을 위해 깃헙 레포지토리를 활용해보겠습니다. 머신러닝 시스템을 위한 디자인 패턴을 게시해 둔 레포입니다. 예시로 사용된 패턴 이외에도 각 상황에 맞는 다양한 코드 예시들도 살펴보세요.

실행 파일은 어디있지?

우선 CLI를 통해 tree 명령어로 간단하게 디렉토리 구조를 한번 살펴보겠습니다.

.
├── Dockerfile.api
├── Dockerfile.batch
<strong>├── README.md
</strong>├── __init__.py
├── docker-compose.yml
├── makefile
├── manifests
│   ├── cron_jobs.yml
│   ├── deployment.yml
│   ├── mysql.yml
│   └── namespace.yml
├── models
│   ├── data.json
│   ├── iris_svc.onnx
│   └── label.json
├── requirements.txt
<strong>├── run.sh
</strong>└── src
    ├── __init__.py
    ├── api
    ├── configurations.py
    ├── constants.py
    ├── db
    ├── ml
    ├── task
    └── utils

보통의 경우 root 위치의 README.md 파일을 통해 해당 프로그램의 사용 방법에 대해 기록해둡니다. 때문에 파일 안의 Introduction 을 빠짐없이 읽어봐야겠죠.

하지만 대부분의 코드들은 서로 다양하게 얽힌 비선형적인 디렉토리 구조를 가지고 있습니다. 이로 인해 작업자가 변경되거나, 다른 사람의 작업물을 처음 접할 경우 내용을 파악하기 쉽지 않죠. 때문에 통합 개발 환경 등의 다양한 플러그인들을 활용하기도 합니다.

해당 레포를 파악해보니 가장 상위 디렉토리에 위치한 run.sh 파일이 눈에 띕니다. 정해진 규칙은 아니지만 실행 파일의 이름으로 자주 사용되는 예시는 다음과 같을 수 있습니다.

Python 스크립트:
- run.py , main.py, app.py, server.py, manage.py (Django 프로젝트에서 자주 사용)
Shell 스크립트:
- run.sh, start.sh, deploy.sh, build.sh, setup.sh, install.sh, service.sh, env.sh…

이러한 이름 규칙은 프로젝트나 팀 별로 다소 차이가 있을 수 있지만, 일반적으로 run, main, app, server와 같이 실행 또는 서버 실행과 관련된 단어를 사용하는 경향이 있습니다.

또한 manage.py는 Django 프레임워크에서 많이 사용되며, 프로젝트 관리와 관련된 다양한 명령을 실행할 수 있습니다.

쉘 스크립트의 경우 run, start, deploy, build, setup, install, service 등의 단어를 조합하여 스크립트의 목적을 나타내는 이름을 사용합니다.

여기서 GPT 코드 분석 이 나선다면? 해당 파일 run.sh 이 어떻게 작동하는지, GPT 에게 업로드하여 한번 물어보겠습니다.

GPT 는 파일을 잘근잘근 씹어

GPT 야, 업로드한 파일이 어떻게 구성되어있는지 분석해줘

네, 제공된 run.sh 파일에는 다른 파일에 대한 직접적인 참조가 없습니다. 하지만 이 스크립트가 실행하는 Gunicorn 서버는 다음과 같은 파일들과 연결되어 있을 것으로 추정할 수 있습니다:

애플리케이션 코드 파일: 스크립트의 마지막 줄에서 src.api.app:app를 실행하도록 지정되어 있습니다. 이는 아마도 src/api/app.py 파일일 것입니다. Gunicorn은 이 파일에 정의된 WSGI 애플리케이션을 실행할 것입니다.
로깅 설정 파일: -log-config ./src/utils/logging.conf 옵션에서 참조하는 src/utils/logging.conf 파일이 있을 것입니다. 이 파일에는 로그 출력 형식, 로그 레벨 등의 로깅 관련 설정이 들어 있습니다.
환경 변수 파일(옵션): 환경 변수를 별도의 파일(예: .env)에 저장한 경우 해당 파일이 필요할 것입니다.
Gunicorn 의존성 파일: Gunicorn 서버를 실행하려면 Python 및 Gunicorn 패키지와 관련 종속성 패키지가 설치되어 있어야 합니다. 이러한 종속성은 일반적으로 requirements.txt와 같은 파일에 정의됩니다.
기타 설정 파일: 어플리케이션이 사용하는 데이터베이스, 캐시 서버 등의 설정 파일이 있을 수 있습니다.

실제로 연결된 파일은 애플리케이션의 구조와 구현 방식에 따라 다를 수 있습니다. 제공된 정보만으로는 정확한 파일 목록을 판단하기 어렵습니다.

아주 중요한 정보를 알려주는군요. 실행파일과 함께 연결된 [app.py](<http://app.py>) 있다는 사실을 통해, 실제 디렉토리를 한번 살펴보겠습니다. 실제로 ./src/api/app.py 경로에 동일한 파일이 있는 것을 발견할 수 있었네요.

코드 분석 잘했어, GPT!

app.py 파일도 이어서 분석을 요청해볼까요?

이 파일은 FastAPI 웹 프레임워크를 사용하는 Python 애플리케이션의 주요 진입점(entry point)입니다. 다음과 같은 작업을 수행합니다:

로깅 설정: logging 모듈에서 getLogger 함수를 사용하여 로거를 가져옵니다. 이를 통해 애플리케이션의 로그 메시지를 기록할 수 있습니다.
FastAPI 인스턴스 생성: FastAPI 클래스의 인스턴스를 생성합니다. 이 인스턴스는 API 제목, 설명, 버전 등의 메타데이터를 APIConfigurations 클래스에서 가져옵니다.
데이터베이스 초기화: src.db.initialize 모듈의 initialize_database 함수를 호출하여 데이터베이스를 초기화합니다. 이 함수는 engine 객체와 checkfirst 플래그를 인수로 받습니다.
라우터 포함: src.api.routers 모듈에서 router 객체를 가져와 app.include_router 메서드를 사용하여 FastAPI 애플리케이션에 포함시킵니다. 이렇게 하면 라우터에 정의된 경로(routes)가 API에 추가됩니다.

전반적으로 이 파일은 FastAPI 애플리케이션을 초기화하고 설정하는 역할을 합니다. 데이터베이스 연결을 설정하고, API 메타데이터를 정의하며, 라우터를 추가하여 API 엔드포인트를 정의합니다.

이 파일은 애플리케이션의 시작점이므로, 다른 모듈과 함수를 가져와 사용합니다. 예를 들어, src.api.routers에서 API 라우트를 정의하고, src.configurations에서 API 설정을 가져오며, src.db에서 데이터베이스 초기화 함수를 가져옵니다.

또 하나 중요한 routers.py 파일이 연결되어있다는 사실을 알았습니다. 실제로도 동일 디렉토리 안에 저장되어있네요. 이런 방식으로 각 파일에 구성된 기능과 연관되어있는 다른 코드들을 살펴볼 수 있습니다. 하지만 전체적인 그림을

GPT 코드 분석 , 구조를 사이사이 뜯어보기

이번엔 세 파일 run.sh , app.py , routers.py 을 프롬프트에 함께 넣고, 파일들이 어떤 식으로 연결되어 작동하는지 GPT 코드 분석 통해 살펴보겠습니다.

이번에는 글보다는 지도와 같은 그림을 통해 분석을 요청해보겠습니다. mermaid 문법을 활용하면 아래와 같은 보기좋은 그림을 코드로도 손쉽게 작성할 수 있습니다. 프롬프트는 아래와 같이 구성했습니다. 작성된 결과물을 온라인 편집기를 통해서 곧바로 결과물을 확인해볼 수도 있습니다.

'''
(파일 1)
'''
'''
(파일 2)
'''
'''
(파일 3)
'''
위 파일 1(app.py) 과 파일 2(router.py), 파일 3(run.sh)을 연결해서 mermaid 형식으로 UML 을 그려줘

GPT야, 세 파일이 작동하는 흐름을 플로우 차트로 그려줘

플로우 차트

파일 구조 – 플로우 차트

이렇게 보니 프로그램이 작동하는 방식이 한 눈에 들어오네요. 실행 시 조건에 따라 DB 를 초기화하는 작업이나, 상황에 따라서 서로 다른 기능을 수행하는 것이 보입니다. 하지만 아직 실제로 어떤 파일안에서 어떤 작동을 하는지까지는 파악하지 못했습니다. 이번엔 다른 양식으로 바꿔볼까요?

GPT야, 세 파일의 관계를 시퀀스 다이어그램 형태로 그려줘

시퀀스 다이어그램

파일 구조 – 시퀀스 다이어그램

이번에는 실제 파일과 기능들이 실행되는 순서들을 잘 표현해주고 있습니다. 특히 위, 아래, 왼쪽, 오른쪽으로 화살표를 따라가면 프로그램의 흐름이 마치 머릿속에서 재생되는 느낌이 나지 않나요? 내가 변경하고 싶은 부분이 전체 시퀀스에서 어디에 해당하는지 짚어보기에도 적합할 것 같습니다.

클래스 다이어그램

이번에는 실제 코드 편집 또는 작성 작업을 위해 필요한 상세 정보들을 불러와보겠습니다.

GPT 야, 각 코드들의 관계를 클래스 다이어그램으로 그려줘!

파일 구조 – 클래스 다이어그램

클래스 다이어그램에서는 특정 파일 안에 담겨있는 클래스들의 이름(위), 해당 파일에서 활용되는 변수 이름(중간), 그리고 작동할 수 있는 메소드(아래)들을 한번에 표시해줍니다. 좀 더 상세한 내용을 볼까요?

파일 구조 – 클래스 다이어그램

위 그림을 통해 어떤 기능을 위해 어떤 코드로 이동하는지, 어떤 함수를 불러와 작동시킬 수 있는지 표현해주고 있습니다. 또한 +,- 기호 등의 표현으로 전역(+), 지역(-) 변수 등의 추가 정보도 기록되어있어 전체 내용을 빠르게 파악할 수 있습니다.

정리하며

지금까지 GPT 와 함께 만들어본 자료들은 개발 경험이 있으신 분들에게는 익숙하게 느껴지실 겁니다. 현재까지 UML 다이어그램(Unified Modeling Language Diagram)이라는 표현법을 코드에서 추출해주는 툴들이 프로그래밍 언어 별로 존재하고있습니다. 부득이한 경우 직접 손으로도 열심히 그려가며 소스코드 전반적인 내용을 파악하기 위해 노력하기도 하죠. 하지만 소스 코드의 내용이 조금 변경되면 해당 내용을 찾아 반영하기 위해 많은 노력이 들고, 프로그램 구조를 다이어그램 그리기용으로 맞춰야하는 번거로움이 있다보니 많이 활용되지 못한 것 같습니다.

따라서 이번 시간은 GPT 를 활용하여 간편하게 UML 다이어그램을 그리는 방법에 대해 알아보았습니다. 이번 경험을 통해 굉장히 손쉽게 해당 작업을 수행할 수 있었고, 앞으로 다양한 작업에 반영할 수 있겠다는 생각이 들었습니다.

중요한 점은 생성모델이 만들어준 결과물에 대해 사실인지 확인하는 작업과 결과물을 나의 것으로 만드는 과정이라고 생각합니다. 직접 프롬프트로 넣어준 코드들 덕분인지 다행히 환영적인 사실들은 거의 발견하지 못했습니다. 또 내 머릿속에도 이 다이어그램들이 비슷하게 떠오를 수 있으면 좋겠다는 생각을 했습니다. 오늘 글의 내용을 만약 본인의 작업에 적용한다면, 한 쪽에 빈 종이와 연필을 준비해서 직접 손으로 그려보면서 수정이 필요한 부분 혹은 미흡한 부분을 점검할 수 있겠다는 생각이 들었습니다. 생성 모델에게 종속되지 않고 기능적으로만 건강한 활용법을 연습하실 수 있으면 좋겠습니다.

뇌과학계 “성공하려면 아침 습관에 반드시 이걸 포함시켜라“