긍정적 사고, 음식의 절제, 규칙적인 운동

https://www.samsungsds.com/kr/insights/gitops.html

“개발과 운영의 벽을 허물어 더 빨리 더 자주 배포하자”
데브옵스(DevOps)의 핵심 개념을 나타내는 문장입니다. 2020년 소프트웨어 업계 종사자라면 데브옵스의 영향을 직접 혹은 간접적으로라도 받고 있을 것 입니다.(받고 있어야 합니다!)

데브옵스 개념이 등장한 지 10년이 흐른 지금, 가치를 따지는 것은 무의미한 일이 되었습니다. 그 동안 축적된 긍정적인 결과들은 데브옵스를 더이상 유행이 아니라 소프트웨어 개발과 운영에 꼭 필요한 표준의 영역으로 이끌었습니다.

개인적으로 데브옵스가 널리 사랑 받게 된 이유는 커다란 목표와 원칙을 공유할 뿐 상세한 규칙이나 절차는 비어 있다는 점, 즉 유연성과 확장성에 있다고 생각합니다. 이는 급변하는 시장에서 살아 남을 수 있는 원동력이 되었고 지금도 여러가지 방식으로 또 데브섹옵스(DevSecOps), 깃옵스(GitOps), AI옵스(AIOps) 등의 다양한 이름으로 진화를 계속해 나가고 있습니다.

이들 중에서 개인적으로 많은 공감을 하였고 최근에 진행한 프로젝트에 직접 적용해 본 “깃옵스(GitOps)”에 대해 설명드리고자 합니다. 깃옵스의 기본 원칙과 패턴에 대해 알아본 다음 구현체 중 하나인 아르고CD(ArgoCD)를 활용하여 샘플 프로젝트에 적용하는 과정을 보여 드리겠습니다.

깃옵스란?

깃옵스는 위브웍스(Weaveworks Inc.)에서 처음 사용한 용어로 프로젝트에 데브옵스를 적용하는 실천 방법 중 하나입니다. 그 중에서도 클라우드 네이티브 애플리케이션을 대상으로 한 지속적 배포(Continuous Deployment)에 초점을 두고 있습니다.

※ 클라우드 네이티브 애플리케이션이 아니어도 깃옵스를 적용할 수 있으나 아래에서 설명드릴 선언형 모델(Declarative Model)을 지원하는 최근 도구들이 클라우드 네이티브에 중점을 두기 때문에 어려움을 겪을 수 있습니다. 위브웍스는 아예 쿠버네티스 대상이라고 못박고 있습니다.

이름에서 나타나듯 애플리케이션의 배포와 운영에 관련된 모든 요소를 코드화하여 깃(Git)에서 관리(Ops)하는 것이 깃옵스의 핵심입니다. 기본 개념은 코드를 이용하여 인프라를 프로비저닝 하고 관리하는 IaC(Infrastructure as Code)에서 나온 것으로 깃옵스는 이를 인프라에서 전체 애플리케이션 범위로 확장하였습니다.

▲Guide to GitOps

깃옵스의 핵심 아이디어는 다음과 같습니다.

1) 배포에 관련된 모든 것을 선언형 기술서(Declarative Descriptions) 형태로 작성하여 Config Repository(혹은 Environment Repository)에서 관리한다.
2) Config Repository의 선언형 기술서와 운영 환경 간 상태 차이가 없도록 유지시켜주는 자동화 시스템을 구성한다.

깃옵스 환경에서 새로운 버전의 애플리케이션을 배포하거나 기존의 운영 환경을 바꾸고 싶다면 선언형 기술서를 수정한 뒤 Config Repository에 반영하기만 하면 됩니다. 나머지 과정은 자동화된 시스템이 알아서 수행할 것입니다.

깃옵스를 움직이는 핵심 개념들

1) 선언형 모델(Declarative Model)

여러분이 원격에 위치한 대상(서버)에 작업(애플리케이션 배포, 설정 관리 등)을 자동화 한다고 했을 때 가장 먼저 떠오르는 방법은 명령어를 순서대로 나열하는 명령형 모델(Imperative Model)일 것입니다.
“ssh로 접속 → cd로 이동 → mkdir로 디렉토리 생성”

간단한 방법인 만큼 단점도 명확합니다. 우선 예외 상황을 모두 관리(이미 디렉토리가 존재한다면? 권한은? 등)해야 하며 원격 대상에 대한 지식(OS 종류에 따른 명령어 차이 등)도 필요합니다.
다른 방법으로 선언형 모델이 있습니다. 대상이 무엇이 되어야 하는지만 기술하면 됩니다. 이해 하기 쉽도록 예를 들어 보겠습니다.

원격 서버에 ‘/etc/some_directory’ 디렉토리가 필요한 상황입니다. 선언형 모델에서는 아래와 같이 코드 형태로 세부 내용을 작성하기만 하면 됩니다.

디렉토리가 이미 존재하는지 확인하거나 OS에 따라 바뀌는 명령어를 사용자가 알아야 할 필요가 없습니다. 이는 선언형 모델 구현체의 몫입니다. 이 중 가장 대표적인 것이 쿠버네티스이며 깃옵스와도 궁합이 잘 맞습니다. 무엇보다도 가장 큰 장점은 인프라를 포함한 애플리케이션 배포와 운영에 관련된 모든 것을 코드로 관리할 수 있다는 점과 이 코드를 이용하여 언제든 똑같은 환경을 다시 만들어내거나 부분 소실 시 복원할 수 있다는 점입니다.

2) 단일 진실 공급원(Single Source Of Truth, SSOT)

같은 데이터가 여러 곳에 있을 경우 문제를 일으킬 수 있습니다. 데이터의 중복은 당연하고 수정 시 한 곳이라도 빠지게 된다면 비정합성까지 발생합니다. 때문에 한 곳에 두고 관리하고 다른 곳에서 필요 시 참조만 하도록 하여 문제를 해결합니다.

대표적으로 데이터 정규화 작업에 이용됩니다. 예를 들어 보겠습니다. “Employee”와 “Employees' Skills” 테이블이 있습니다. 각 레코드들은 Employee Name, Employee Email 정보를 중복해서 포함 하고 있습니다. ‘Tom’의 이메일 주소가 변경되었습니다. 여러 개의 테이블의 레코드를 수정해야 합니다만 하나라도 수정이 이루어지지 않을 경우 모순 상태가 됩니다. 조회하는 테이블에 따라 ‘Tom’ 이메일이 다르게 조회되기 때문입니다.

이런 경우 “Employees’ Skills” 테이블에서 Employee Email을 제거하고 employee_name를 이용해 “Employee” 테이블을 참조하도록 합니다. Employee Email 정보는 오직 “Employee”라는 하나의 테이블에서만 관리하도록 하는 것입니다.

깃옵스에서도 마찬가지입니다. 깃을 단일 진실 공급원으로 지정하고 오직 이 곳에서만 관리하도록 합니다. 모든 운영 활동의 시작은 깃이므로 사람 혹은 시스템 간의 혼선을 최소화 할 수 있습니다. 그리고 개발 단계에서만 누릴 수 있었던 깃의 강력하고 익숙한 기능을 운영 단계에서도 활용할 수 있게 됩니다. (History, Commit, Merge Request/ Review, Revert 등)

깃옵스 구현

실제로 깃옵스를 프로젝트에 적용할 때 고려해야 할 점들을 알아보겠습니다. 깃옵스는 어디까지나 방법론이기 때문에 정해진 도구가 따로 없습니다. 각자 익숙한 도구를 이용하면 됩니다.
그리고 깃옵스는 빌드와 테스트가 끝난 바이너리(이미지)를 저장소에 등록한 이후의 단계를 다루고 있기 때문에 지속적 통합(Continuous Integration) 부분은 생략하겠습니다.

1) 저장소 전략

최소 2개 이상의 Git 저장소를 사용하는 것을 권장합니다.
• 애플리케이션 저장소: 애플리케이션 소스 코드와 애플리케이션 배포를 위한 배포 매니페스트(예: kubernetes yaml)를 포함합니다.
• 배포 환경 구성 저장소: 배포 환경에 대한 모든 매니페스트를 포함합니다. 애플리케이션과 인프라 서비스(모니터링, 메시지 브로커 등)가 어떤 버전으로 어떻게 구성되어야 하는지에 대한 정보가 들어있습니다.

애플리케이션 배포 매니페스트를 별도의 깃 저장소에 보관해도 되고 템플릿 형태로만 가지고 있다가 배포 시 배포 환경 구성 저장소와 합쳐서 매니페스트를 생성하는 방식으로도 사용이 가능합니다.

2) 배포 전략

깃옵스에서는 푸시 타입(Push Type)과 풀 타입(Pull Type), 두 가지의 배포 전략을 가이드 하고 있습니다. 두 옵션 간의 차이점은 저장소에 있는 매니페스트와 배포 환경의 상태를 일치시키는 방법입니다. 무엇을 선택해도 상관없으나 깃옵스는 보안상의 이유로 풀 타입 배포 전략을 권장하고 있습니다. 각각에 대해 간략히 알아보겠습니다.

▲ Push Type

■ 푸시 타입(Push Type)
저장소에 있는 매니페스트가 변경되었을 때 배포 파이프라인을 실행시키는 구조입니다. 아키텍처가 단순하여 인기 있는 방법이며 젠킨스(Jenkins), 서클CI(CircleCI) 등의 구현에 사용할 수 있는 도구들도 다양합니다. 가장 큰 특징으로 배포 환경(Environment)의 개수에 영향을 받지 않습니다. 접속 정보를 추가하거나 수정하는 것만으로도 간단하게 배포 환경을 추가하거나 변경할 수 있습니다.

그러나 항상 연결되어 있는 상태가 아니라서 실제 배포 작업이 수행되는 시점에 실패할 수도 있습니다. 그리고 배포 환경이 손상되어 배포 환경 구성 저장소의 내용과 다를 경우 차이를 감지하고 배포 파이프라인을 다시 실행시키거나 알림을 줄 수 있는 별도의 모니터링 시스템이 필요합니다.

▲ Pull Type

■ 풀 타입(Pull Type)
배포 환경에 위치한 별도의 오퍼레이터가 배포 파이프라인을 대신합니다. 이 오퍼레이터는 저장소의 매니페스트와 배포 환경을 지속적으로 비교하다가 차이가 발생할 경우 저장소의 매니페스트를 기준으로 배포 환경을 유지시켜 줍니다. 만약 누군가가 직접 손으로(허가 받지 않은 작업) 배포 환경을 변경했을 때도 다시 되돌려지게 되는데 이는 배포 환경의 변경은 저장소의 매니페스트를 통해서만 유효하다는 것을 보장해줍니다. 다시 말해 배포 환경에 대한 모든 이력은 배포 환경 구성 저장소 즉, 깃에 존재한다는 것을 의미합니다. 이런 방식을 지원하는 도구로는 아르고CD, 젠킨스X(JenkinsX), 그리고 깃옵스라는 용어를 만든 위브웍스에서 제작한 플럭스(Flux)가 있습니다.

앞에서 보안상의 이유로 깃옵스는 풀 타입 배포 전략을 권장한다고 언급했습니다. 이는 구조적 차이에서 발생하는 것으로 푸시 타입의 경우 배포 환경에 대한 자격 증명 정보를 외부에서 관리할 수 밖에 없습니다. 배포 환경 입장에서는 배포 파이프라인 자체가 외부 도메인이기 때문입니다. 그리고 일반적으로 배포 파이프라인에게 배포 환경에 대한 읽기?쓰기 권한을 부여하기 때문에 만의 하나 노출된다면 큰 피해를 볼 수도 있습니다.

반면 풀 타입의 경우 오퍼레이터가 애플리케이션과 동일한 환경에서 동작 중이어서 자격 증명 정보가 외부에 노출될 일이 없습니다. 그리고 배포 환경에 대한 자격 증명 정보도 오퍼레이터 관리를 위한 최소한의 인력으로 한정 지을 수 있습니다. 신경 써야 할 것은 배포 환경에서 깃 저장소와 이미지 저장소로의 접근 정도입니다.

깃옵스 장점

배포 빈도 및 속도 상승, 생산성 향상, 오류 감소 등 여러 장점들이 있지만 이들 대부분은 다른 데브옵스 구현 방법을 사용해서도 달성할 수 있는 것들입니다. 그렇기 때문에 깃옵스만의 장점을 설명드리겠습니다.

1) 신뢰할 수 있는 정보의 공유

“스테이지 환경에 배포된 A 서비스의 설정 값이 뭐지?”
필자가 개발과 운영을 하던 당시 적지 않게 묻고 대답했던 것 같습니다. 적어도 깃옵스를 사용한다면 누군가의 희미한 기억에 의존하거나 제때 업데이트를 하고 있는지 파악하기 위해 문서를 찾아 본다거나 직접 서버에 접속하기 위해 힘겹게 ssh 명령어를 입력할 필요가 없습니다. 깃 이력을 보면 현재 상태는 물론 누가, 언제, 왜, 어느 곳을 수정했는지 쉽게 알 수 있기 때문입니다. 지금까지의 모든 이력을 포함하고 있는 이 시스템은 부가적인 문서 작업을 없애는 좋은 수단이기도 합니다.

※ 에러 복구 시간 감소
새롭게 서비스를 배포했는데 장애가 발생했을 때 해야 할 일은 ‘git revert’ 명령어, 그리고 배포 환경이 이전 버전으로 롤백될 때까지 기다리는 것입니다.

2) 익숙한 절차

“git commit → push → merge request → review → merge”
개발자에게 굉장히 익숙한 절차입니다. 그렇기 때문에 애플리케이션 배포를 위한 별도의 절차를 만들거나 교육시킬 필요가 없습니다. 그리고 리뷰 절차를 통해 휴먼 에러를 조기에 발견하고 책임을 나눌 수 있습니다.

GitOps 적용

풀 타입 구현체 중 하나인 아르고CD를 이용하여 깃옵스 시스템을 구축하겠습니다.
그리고 저장소에 있는 배포 관련 디스크립션을 수정했을 때 아르고CD가 배포 환경(Kubernetes)에 변경 사항을 잘 반영하는지도 확인해 보겠습니다.

1) Config Repo 생성

깃허브(GitHub)에 개인 프로젝트를 생성하고 쿠버네티스용 디스크립션을 작성합니다.

2) 애플리케이션 생성

이제 아르고CD에게 일을 시켜보겠습니다. 로그인 후 왼쪽 상단의 “+NEW APP” 혹은 중앙의 “CREATE APPLICATION” 클릭 하고 생성에 필요한 정보를 입력 합니다.

작성 후 “Create” 버튼을 누르면 내부적인 검증 작업을 거친 뒤 신규 애플리케이션이 생성되며, SYNC POLICY 값을 Automatic으로 설정했다면 아래처럼 배포까지 진행됩니다.

애플리케이션 카드를 클릭하면 아래와 같이 각각의 쿠버네티스 리소스에 대한 정보는 물론 동작 상태에 대한 상세 정보가 제공됩니다.

3) 감시 기능 확인

마지막으로 아르고CD의 감시 기능이 제대로 동작하는지 확인하기 위해 깃에서 Deployment-replicas 값을 1에서 2로 수정하고 커밋하겠습니다.

잠시 후 아르고CD에서 “nginx-deployment” pod가 두 개로 늘어난 것을 확인할 수 있습니다.

마치며

데브섹옵스, 깃옵스, AI옵스 등 데브옵스를 확장하거나 특정 기술 혹은 업무에 특화된 모델들이 몇 해 전부터 등장하고 있습니다. 이는 데브옵스가 도입기를 넘어 모델의 다양성이 가속화 되는 성장기 혹은 그 다음 단계로 진입했음을 보여주는 것이라고 생각합니다.

깃옵스도 지금까지 소개된 많은 모델 중 하나지만 대상과 장점이 아주 명확합니다. 그렇기 때문에 클라우드 네이티브 대상, 그 중에서도 쿠버네티스로의 배포를 고려 중이거나 보안에 민감하여 권한과 정보를 엄격하게 관리하는 프로젝트일 경우 깃옵스는 좋은 선택지가 될 것입니다.

새롭게 데브옵스 환경을 구축할 계획을 가지고 있거나 기존의 것이 아쉬운 개발자 분들에게 본 아티클이 조금이나마 도움이 되기를 바랍니다.



References
[1] https://www.gitops.tech/
[2] https://www.weave.works/technologies/gitops/
[3] https://www.cloudbees.com/gitops/what-is-gitops
[4] https://aws.amazon.com/ko/blogs/korea/building-a-modern-ci-cd-pipeline-in-the-serverless-era-with-gitops/
[5] https://www.atlassian.com/git/tutorials/gitops
[6] https://www.red-gate.com/simple-talk/sysadmin/powershell/powershell-desired-state-configuration-the-basics/
[7] https://docs.ansible.com/ansible/latest/collections/ansible/builtin/file_module.html
[8] https://www.powershellmagazine.com/2013/08/26/pstip-create-an-empty-folderfile-using-desired-state-configuration-file-resource/
[9] https://argoproj.github.io/argo-cd/

YouTube 또는 기타 지원되는 웹사이트의 영상 URL에 대해 **사용 가능한 모든 다운로드 형식(Format)**의 목록을 세부 정보와 함께 출력하는 데 사용

설치 : pip install yt-dlp

yt-dlp --list-formats

yt-dlp --list-formats [오류가 발생한 YouTube URL]

[python] 유튜브 영상 경로로 다운받기 youtube_downloader.py

import yt_dlp
import os

def download_youtube_video():
    """사용자 입력 URL을 기반으로 YouTube 영상을 다운로드하는 함수"""
    
    url = input("다운로드할 YouTube 영상 URL을 입력하세요: ").strip()
    
    if not url:
        print("경고: 유효한 URL을 입력해야 합니다.")
        return

    # 📌 수정 1: 다운로드 폴더 경로 설정 
    current_dir = os.getcwd() # 현재 스크립트가 실행되는 디렉토리
    download_dir = os.path.join(current_dir, 'downloads') # 'downloads' 하위 폴더 경로 생성
    
    # 📌 수정 2: 'downloads' 폴더가 없으면 생성
    if not os.path.exists(download_dir):
        os.makedirs(download_dir)
        print(f"[알림] 'downloads' 폴더를 생성했습니다: {download_dir}")

    # 2. 다운로드 옵션 설정
    ydl_opts = {
        #'format': 'bestvideo[ext=mp4]+bestaudio[ext=m4a]/best[ext=mp4]/best', 
        'format': 'bestvideo+bestaudio/best',
        
        # 📌 수정 3: outtmpl 옵션에 'download_dir' 경로 추가
        # outtmpl 옵션: 저장될 파일의 템플릿 (경로 포함)
        'outtmpl': os.path.join(download_dir, '%(title)s.%(ext)s'), 
        
        'postprocessors': [{
            'key': 'FFmpegMetadata',
            'add_metadata': True,
        }],
    }

    # 3. 다운로드 실행
    try:
        print(f"\n[알림] 다운로드를 시작합니다: {url}")
        
        with yt_dlp.YoutubeDL(ydl_opts) as ydl:
            ydl.download([url])
            
        print("\n🎉 다운로드가 성공적으로 완료되었습니다!")
        print(f"저장된 위치: {download_dir}")
        
    except yt_dlp.utils.DownloadError as e:
        print(f"\n[오류] 다운로드 중 오류가 발생했습니다: {e}")
    except Exception as e:
        print(f"\n[오류] 예상치 못한 오류가 발생했습니다: {e}")


if __name__ == "__main__":
    download_youtube_video()

랜덤 워크(Random Walk)를 사용하여 **아트적인 노이즈 트레일(Artistic Noise Trail)**을 만드는 것은 제너레이티브 아트(Generative Art)에서 매우 흔하고 흥미로운 기법입니다. 이는 각 단계에서 **무작위성(Stochasticity)**을 이용해 경로를 결정함으로써 예측 불가능하면서도 유기적인 움직임을 만들어냅니다.

파이썬에서는 주로 turtle 또는 **matplotlib**을 사용하여 시각화할 수 있지만, 여기서는 제너레이티브 아트에 자주 사용되는 접근 방식인 랜덤 증분을 이용해 구현해 보겠습니다.

"""
랜덤 워크(Random Walk)를 사용하여 **아트적인 노이즈 트레일(Artistic Noise Trail)**을 만드는 것은 제너레이티브 아트(Generative Art)에서 매우 흔하고 흥미로운 기법입니다. 이는 각 단계에서 **무작위성(Stochasticity)**을 이용해 경로를 결정함으로써 예측 불가능하면서도 유기적인 움직임을 만들어냅니다.

파이썬에서는 주로 turtle 또는 **matplotlib**을 사용하여 시각화할 수 있지만, 여기서는 제너레이티브 아트에 자주 사용되는 접근 방식인 랜덤 증분을 이용해 구현해 보겠습니다.

"""


import numpy as np
import matplotlib.pyplot as plt

def generate_random_walk_trail(steps, noise_strength=1):
    """
    주어진 단계 수만큼 랜덤 워크 트레일 데이터를 생성합니다.
    
    :param steps: 랜덤 워크를 진행할 단계 수
    :param noise_strength: 노이즈/이동 강도 (클수록 경로가 거칠어짐)
    :return: x, y 좌표 배열
    """
    # 각 단계에서의 x, y 변화량 (랜덤 증분)을 생성합니다.
    # -noise_strength부터 +noise_strength 사이의 균일 분포 난수
    dx = np.random.uniform(-noise_strength, noise_strength, steps)
    dy = np.random.uniform(-noise_strength, noise_strength, steps)

    # 누적합을 계산하여 경로(트레일)를 만듭니다.
    # 각 지점은 이전 지점에서의 변화량을 누적한 결과입니다.
    x_trail = np.cumsum(dx)
    y_trail = np.cumsum(dy)
    
    return x_trail, y_trail

# --- 시각화 설정 ---
STEPS = 5000  # 경로 길이
NOISE_LEVEL = 1.5 # 노이즈 강도 조절

x_coords, y_coords = generate_random_walk_trail(STEPS, NOISE_LEVEL)

# Matplotlib으로 트레일 시각화
fig, ax = plt.subplots(figsize=(10, 10))
ax.plot(x_coords, y_coords, 
        color='white',      # 선 색상
        linewidth=0.5,      # 선 두께
        alpha=0.8)          # 투명도

# 배경 및 축 설정
ax.set_facecolor('black')
ax.set_xticks([])
ax.set_yticks([])
ax.set_title(f"Random Walk Artistic Noise Trail ({STEPS} steps)", color='white')

# 축 비율을 같게 설정하여 왜곡 방지
ax.set_aspect('equal', adjustable='box')

plt.show()

 

import numpy as np
import matplotlib.pyplot as plt

steps = np.random.choice([1, -1], size=(2,1000))
pos = np.cumsum(steps, axis=1)
plt.plot(pos[0], pos[1], color='lime')
plt.axis('off')
plt.title("Random walk path", color='green')
plt.show()

turtle 로 전체화면에서 임의로 선그리기 

import turtle
import random

# 화면 설정
def setup_screen():
    """창을 설정하고 전체 화면과 유사하게 최대화합니다."""
    screen = turtle.Screen()
    screen.setup(width=1.0, height=1.0) # 화면 크기를 최대화합니다.
    screen.title("무작위 선 그리기 (전체 화면)")
    screen.colormode(255) # RGB 색상 모드를 0-255로 설정합니다.
    screen.bgcolor("black") # 배경색을 검은색으로 설정합니다.
    screen.tracer(0) # 그리기 속도를 높이기 위해 자동 화면 업데이트를 끕니다.
    return screen

# 거북이 설정
def setup_turtle():
    """선을 그릴 거북이를 설정합니다."""
    t = turtle.Turtle()
    t.hideturtle() # 거북이 아이콘을 숨깁니다.
    t.speed(0) # 최고 속도로 설정합니다.
    t.pensize(2) # 펜 두께를 설정합니다.
    return t

# 무작위 색상 생성
def get_random_color():
    """무작위 RGB 색상 튜플을 반환합니다."""
    r = random.randint(0, 255)
    g = random.randint(0, 255)
    b = random.randint(0, 255)
    return (r, g, b)

# 메인 그리기 루프
def draw_random_lines(t, screen):
    """화면이 종료될 때까지 무작위 선을 계속 그립니다."""
    while True:
        # 무작위 색상 및 위치 설정
        color = get_random_color()
        t.pencolor(color)
        
        # 펜을 든 상태로 무작위 위치로 이동 (현재 위치에서 그리기 시작)
        t.left(random.randint(-180, 180)) # 무작위로 방향을 돌립니다.
        
        # 무작위 길이만큼 앞으로 이동 (선을 그림)
        distance = random.randint(50, 300)
        t.forward(distance)

        # 화면 가장자리를 벗어났는지 확인하고, 벗어났다면 펜을 들고 중앙 근처로 이동
        # 이 과정이 없으면 거북이가 화면 밖으로 나가버려 그림이 멈춘 것처럼 보일 수 있습니다.
        current_x, current_y = t.position()
        screen_width = screen.window_width()
        screen_height = screen.window_height()
        
        if abs(current_x) > screen_width / 2 or abs(current_y) > screen_height / 2:
            t.penup() # 펜 들기
            t.goto(0, 0) # 중앙으로 이동
            t.left(random.randint(-180, 180)) # 방향을 다시 무작위로 설정
            t.pendown() # 펜 내리기
            
        # 화면 업데이트 (tracer(0)를 사용했으므로 수동으로 업데이트)
        screen.update()

# 프로그램 실행
if __name__ == "__main__":
    screen = setup_screen()
    t = setup_turtle()
    
    try:
        draw_random_lines(t, screen)
    except turtle.Terminator:
        # 창 닫기 버튼을 눌렀을 때 발생하는 예외 처리
        print("프로그램이 종료되었습니다.")
    except Exception as e:
        print(f"예외 발생: {e}")
        
    # 창을 닫을 때까지 프로그램이 대기하도록 함 (실제 draw_random_lines 루프에서는 필요 없음)
    # turtle.done()

https://news.hada.io/topic?id=23845

https://hojberg.xyz/the-programmer-identity-crisis/

• 프로그래머의 정체성이 최근 AI와 LLM 도구의 등장으로 위협받고 있음
• 프로그래밍 문화는 1950년대 MIT의 해커 윤리에서 시작되어 코드 작성 그 자체를 깊이 있는 기술(craft)로 여기며, 정밀한 논리와 문제 해결의 몰입을 핵심 가치로 삼아왔음
• 그러나 현재 AI 산업과 LLM 도구들은 개발자를 단순 명세 작성자나 오퍼레이터로 전환시키려 하며, 직접 코드를 작성하는 대신 자연어로 지시만 내리는 "vibe-coding" 방식을 강요하고 있음
• LLM 생성 코드는 비결정적이고 부정확하며, 개발자가 직접 코드를 읽고 작성하는 과정에서 얻는 깊은 이해와 몰입을 제거하여 코드베이스와의 연결을 단절시킴
• 기업들은 생산성 증대를 명분으로 도구 사용을 강제하고, 팀 내 협업과 멘토링 문화를 AI와의 상호작용으로 대체하면서 개발자 간 인간적 연결을 약화시키고 있음
• 프로그래밍을 단순 산출물이 아닌 사고와 이해의 과정으로 보는 본질적 가치가 상실되고 있으며, 개발자들은 자신의 기술과 즐거움, 그리고 직업적 정체성을 지키기 위해 이러한 변화에 저항해야 함

프로그래머의 본질과 전통

• 코드 작성은 단순한 업무가 아니라 개발자의 정체성 그 자체이며, 에디터는 작업장이자 성소로서 기술을 연마하고 몰입 상태(flow)에 들어가는 공간임
  • Vim과 같은 도구를 통해 생각과 코드 사이의 장벽 없이 작업하며, 현실 세계에 영향을 미치는 비물질적 세계를 창조함
  • 퍼즐을 푸는 과정 자체가 완성된 그림보다 중요하며, 손가락에서 버퍼로 이어지는 기술의 흐름 속에서 시간이 사라짐
• 1950년대 후반 MIT에서 새로운 프로그래밍 문화가 탄생했으며, 실험적이고 반체제적인 성향을 가진 해커들이 Flexowriter와 TX-0 컴퓨터를 사용하며 완벽한 프로그램을 추구함
  • "The Right Thing"이라는 개념을 중심으로 우아하고 간결한 코드를 작성하는 것을 목표로 삼음
  • Tech Model Railroad Club 멤버들은 기계 언어에 몰두하며 디지털 마법을 익혔고, 발견한 지식을 다른 학생들과 공유하는 문화를 확립함
• Building 26의 컴퓨팅 도가니에서 코딩 기술이 단련되었으며, 약 70년 전 확립된 이 문화는 현재까지 이어져 개발자들의 마음과 기계에 여전히 존재함
  • 고대 해커들의 유산은 깊고 운동적인 기술로 남아있으며, 이를 기반으로 열정적인 산업이 구축됨
  • 개발자들은 여전히 동일한 경이로움, 성취감, 퍼즐 해결의 우아함에 의해 동기부여되고 있음
• 그러나 프로그래머의 정체성을 구성하는 이러한 핵심 가치들이 위협받고 있으며, 한때 밝고 명확했던 프로그래밍의 미래가 이제는 불길한 어둠과 사기, 불확실성으로 가려져 있음

AI 산업의 새로운 정체성 강요

• 수십억 달러 규모의 AI 산업, Hacker News 커뮤니티, LinkedIn의 LLM 지지자들은 소프트웨어 개발의 미래가 프로그래밍과 거의 닮지 않았다고 주장하며, 1년 전 밈처럼 보였던 "vibe-coding"이 주류가 되고 있음
  • 개발자들은 코드 대신 Markdown으로 명세를 작성해야 하며, 코드베이스의 구석구석을 탐험하고 퍼즐을 풀며 비밀을 발견하는 깊은 몰입과 기술의 깊이가 사라짐
  • 대신 개발자를 위해 에이전트들이 사고하는 동안, 산만한 인지와 컨텍스트 스위칭을 받아들여야 하며, 창의적 문제 해결은 기계에 맡기고 개발자는 단순 오퍼레이터가 됨
• 일부 개발자들은 이러한 변화와 "Specification Engineering"이라는 새로운 정체성을 환영하며, 오퍼레이터가 되어 Steve Jobs처럼 "오케스트라를 지휘"하는 것에 흥분함
  • 코딩에 대한 관심이 없는 것으로 보이는데도 왜 프로그래머가 되었는지 의문이며, Woz와 Jobs를 혼동한 것이 아닌가 생각됨
  • Prompt, Context, Specification "Engineering"이 프로그래머에게 밝고 번영하는 직업을 가져다줄 것으로 보이지 않음
• 이는 기술, 숙련도, 노동의 가치 하락을 의미하며, 개발자의 고유한 추상적 사고 능력이 더 이상 필요하지 않은 영역으로 이동하여 이미 제품 매니저와 디자이너가 차지하고 있는 공간으로 들어가게 됨

기업 내 권력 역학의 변화

• 기업 내에서 이 새로운 정체성이 강요되면서 권력 역학이 변화하고 있으며, 잘못된 곳에서 생산성을 높이려는 광적인 시도로 개발자들은 점점 더 구체적인 방식으로 LLM을 사용하도록 강제됨
  • 순응하지 않으면 쫓겨나고, 자신의 쓸모없음을 알리는 제품을 사용하거나 사직해야 함
  • 과거에는 경영진이 개발자의 도구를 이렇게 구체적으로 지시한 적이 거의 없었음
• 개발자들은 셰프나 목수처럼 자신의 도구를 큐레이팅하고 연마하는 데 큰 자부심을 가져왔으며, 에디터의 세심한 설정, 닷 파일 조정, 개발 환경 구성 등을 통해 자신의 사고방식에 맞게 도구를 개인화해왔음
  • 기술의 일부로서 도구 세트를 개인화하는 데 헌신해왔으나, 일상 업무와 거의 연결되지 않은 경영진이 이를 명령하는 것은 침해처럼 느껴짐
  • 수십 년간 기업 내에서 우대받았던 프로그래머들에게, 이러한 내러티브는 경영진이 균형을 다시 자신들에게 유리하게 기울일 새로운 방법을 제공함

LLM과 프로그래밍 언어의 본질적 차이

• 일부는 LLM의 영향을 저수준 언어에서 고수준 언어로의 전환에 비유하지만(Assembly에서 Fortran으로), 이는 여러 측면에서 잘못된 비유임
  • Fortran은 프로그래밍에 뿌리를 두고 기술을 제거하려 하지 않고 그 위에 구축했으며, 프로그래밍의 정밀성과 표현력을 제거하지 않고 확장함
  • Fortran은 입력에 대해 항상 올바른 결과를 성공적으로 생성했지만, LLM의 세계에서는 이 중 어느 것도 사실이 아님
• 컴퓨터와 프로그래밍은 매우 좌절스러울 수 있지만, 적어도 정밀성에 대해서는 항상 신뢰할 수 있었으며, 프로그래밍을 통해 지시한 대로 정확히 수행함
  • 컴퓨터의 정밀성에 대한 의존과 신뢰 때문에, 챗봇이 요청한 작업을 수행했다고 가스라이팅할 때 이를 믿기 쉬움
• LLM과 그 작업은 본질적으로 부정확하며, 대형 언어 모델의 속성과 자연어로 지시하는 방식 모두에서 오해의 여지가 있음
  • 비결정성을 싫어하는 프로그래머들이 이러한 접근 방식을 선택한 것은 흥미로우며, 예측 가능성, 조합성, 멱등성, 불안정하지 않은 통합 테스트를 선호함
  • LLM 코드는 그 반대인 일관성 없는 혼돈을 나타냄
• Dijkstra는 "자연어 프로그래밍의 어리석음에 대하여"에서 자연어가 작업을 단순화할 것이라는 가정에 도전해야 한다고 지적했으며, 형식적 텍스트의 장점은 합법적이기 위해 몇 가지 간단한 규칙만 충족하면 된다는 점이라고 강조함

깊은 이해와 몰입의 상실

• AI 보조 개발을 엄격함과 관료주의로 vibe-coding과 구분하려는 움직임이 있지만, 이는 근본적인 본질을 무시함
  • LLM이 생성한 코드를 자신이 작성했거나 PR에서 리뷰했을 때만큼 면밀히 읽지 않게 되며, LLM 코딩에는 눈을 멍하게 만드는 본질적인 무언가가 있음
  • 대충 훑어보게 되고 압도당하고 지루해하며, CI가 통과하고 프로그램이 컴파일되면 위험한 함정을 맹목적으로 받아들임
  • 테스트가 실행되도록 설정되었는지, 존재하지 않는 라이브러리를 가져왔는지, 전체 라이브러리를 스스로 구현했는지 확인하지 않음
• 책의 리뷰나 요약은 직접 읽는 경험을 대체할 수 없으며, 수백 페이지에 걸쳐 각 문장을 신중하게 소비하며 아이디어를 숙고하는 과정이 필요함
  • 마찬가지로 AI가 완료한 작업의 요약을 훑어보는 것은 도메인, 문제, 가능한 솔루션에 대한 깊은 이해를 형성하는 것을 빼앗으며, 코드베이스와의 연결을 차단함
  • 무지의 심연에 뛰어들어 주제와 그 함의를 드러내고 배우고 이해하는 것은 만족스럽고 좋은 소프트웨어에 필수적임
  • 소유권, 주체성, 깊고 만족스러운 작업은 에이전트 탭 사이의 산만한 주의로 대체됨
• Joan Didion은 "나는 내가 무엇을 생각하고 있는지, 무엇을 보고 있는지, 무엇을 보고 그것이 무엇을 의미하는지 알아내기 위해 글을 쓴다"고 말했으며, Peter Naur는 "Theory Building으로서의 프로그래밍"에서 동일한 개념을 탐구함
  • Naur의 "Theory"는 코드베이스의 이해를 구현하며, 작동 방식, 형식주의, 현실 세계의 표현을 포함함
  • 이러한 맥락과 통찰은 오직 몰입을 통해서만 얻어지며, Naur는 "Theory"를 소프트웨어보다 프로그래밍의 주요 결과물이자 실제 제품으로 설명함
  • 잘 발달된 "Theory"가 있어야만 코드베이스에 확장과 버그 수정을 효과적으로 적용할 수 있음
• 좋은 디자인은 몰입에서 나오며, 텍스트 버퍼에서의 왔다 갔다 하는 작업과 종종 키보드에서 떨어진 곳에서의 작업을 통해 나타남
  • 전체 코드베이스를 마음속에 담을 수 없기에, 모듈, 클래스, 함수에 뛰어들어 흐릿한 정신 모델을 선명하게 해야 함
  • 코드를 읽고 작성하여 인지를 확장하고, 익숙함과 문제 도메인에 대한 이해를 회복해야 함
• 맥락의 일부가 구축되고 많은 부족한 시도를 통해 마침내 해결책을 발견할 수 있으며, 나쁜 디자인의 불협화음을 느껴야 함
  • 혐오스럽고 반복적인 코드를 작성할 때만 더 나은, 더 간결하고 우아하며 조합적이고 재사용 가능한 방법이 있다는 것을 깨달음
  • 이는 문제에 대해 깊이 생각하기 위해 멈추게 하고, 한 걸음 물러서서 처음부터 다시 시작하게 함
  • 반대로 AI 에이전트 작업은 마찰이 없어 대안적 솔루션을 피하게 되며, 수락하는 것이 완벽한지, 평범한지, 끔찍한지, 심지어 해로운지 알 수 없음

팀 협업과 인간 연결의 붕괴

• LLM 중심 코딩의 인지적 부채는 기술 이탈을 넘어 확장되며, 주의 집중 시간이 짧은 "slop-jockey"들이 풀 리퀘스트와 디자인 문서에 자신의 작업물을 던지며 협업을 저해하고 팀을 방해함
  • 코드 리뷰를 하는 동료들은 자신이 이제 마지막 품질 관리 레이어가 아니라 첫 번째 레이어라는 충격적인 깨달음에 정신을 잃어가고 있음
  • 새로 추가되었지만 호출되지 않는 함수, 환각된 라이브러리 추가, 명백한 런타임 또는 컴파일 오류를 지적해야 함
  • 자신의 코드를 명백히 훑어보기만 한 작성자는 책임을 지지 않으며, "Claude가 그렇게 작성했어요. 바보 같은 AI, 하하"라고 말함
• 간섭하는 관리자와 돈을 아끼려는 임원들은 팀에서 인간 상호작용을 줄이도록 (희망컨대 무의식적으로) 압박하고 있음
  • 고립되고 연결이 박탈된 상태에서, 이제 작업 경험 주위에 벽을 쌓도록 권한을 부여받고 장려됨
  • 페어 프로그래머가 필요하거나, 솔루션을 주고받으며 논의하거나, 프로토타입을 만들거나, 아키텍처를 스케치하거나, 코드베이스의 난해한 부분에 대한 전문가 질문에 답하는 데 도움이 필요할 때 사람 대신 LLM에 의존함
  • 더 이상 온보딩 버디, 멘토, 동료가 필요하지 않으며, 대신 기계와 대화할 수 있음
  • LLM으로 인간 접촉을 피하는 것이 너무 쉬워져 이것이 표준이 될 수 있음

프로그래머 정체성의 방어

• 우리가 AI 과대광고 내러티브에 얼마나 순응적이며, 기술의 계획된 삭제에 적극적으로 참여하고, 사고 수단을 기꺼이 포기하는지가 충격적임
  • 취미로 생계를 꾸릴 수 있었던 행운아들이었는데, 슬롭에 대응하기 위해 엄격하고 꼼꼼한 프로세스를 만들더라도 여전히 일의 재미있는 부분을 아웃소싱하고 이를 지시적 고역으로 대체한 것임
• LLM은 소프트웨어의 복잡성에 대한 궤도에서 핵폭탄을 투하하는 솔루션처럼 보이며, 실제 문제를 해결하는 대신 증상을 치료하기 위해 훨씬 더 복잡하고 모호한 것에 손을 뻗음
  • sed를 Claude로 대체하거나, 문서를 수 시간 동안 검색한 후에도 명확성을 찾는 라이브러리나 프레임워크에 대한 답변을 요청하는 것은 괜찮음
  • 그러나 단순히 오퍼레이터나 코드 리뷰어가 되어 재미있고 흥미로운 작업에서 뒷자리를 차지하는 것은 원하지 않음
• 반복적인 작업을 돕고, 코드베이스를 이해하고, 올바른 프로그램을 작성하는 데 도움이 되는 도구를 선호하며, 나를 위해 생각하도록 설계된 제품에는 불쾌감을 느낌
  • 내가 생산하는 소프트웨어에 대한 자신의 이해의 주체성을 제거하고, 동료와의 연결을 끊는 제품을 거부함
  • LLM이 과대광고에 부응하더라도, 우리는 여전히 이 모든 것과 기술을 잃게 될 것임
  • 인간은 기계와 그들을 지원하는 기업보다 중요하며, 나머지 우리가 그들이 판매하는 새로운 아메리칸 드림을 쫓는 동안 그들은 이익을 얻고 있음
  • 대가로 우리는 비판적 사고 능력, 재미, 기술, 프라이버시, 그리고 아마도 지구를 제공하고 있음