8 2월 2026

[인공지능 개발자] [알아봅시다] AI로 고품질 코드를 효과적으로 작성하는 방법

[인공지능 개발자] [알아봅시다] AI로 고품질 코드를 효과적으로 작성하는 방법

4P by GN⁺ 5시간전 | ★ favorite | 댓글 1개
  • AI와 협업하는 개발 환경에서는 인간이 프로젝트의 방향과 의사결정을 명확히 정의해야 품질을 유지할 수 있음
  • 정확한 문서화를 통해 AI와 다른 개발자 모두가 요구사항과 제약을 명확히 이해하도록 해야 함
  • 디버그 시스템과 코드 리뷰 체계를 구축해 AI가 생성한 코드의 신뢰성과 검증 과정을 강화함
  • 보안 위험 함수 표시, 테스트 분리, 엄격한 린팅 규칙 등으로 코드의 안정성과 일관성을 확보함
  • 작업 단위 분할과 복잡도 최소화를 통해 AI 코드 생성의 통제력을 유지하고 효율성을 극대화함

1. 명확한 비전 수립

  • 인간은 세계와 팀, 사용자 행동을 이해하지만 AI는 경험이 없으므로 명시적 지침이 필요함
    • 프로젝트에서 문서화되지 않은 결정은 AI가 대신 내리게 됨
  • 아키텍처, 인터페이스, 데이터 구조, 알고리듬을 사전에 논의하고 테스트 방법을 정의해야 함
  • 장기적이고 변경이 어려운 결정은 반드시 인간이 직접 관리해야 함

2. 정확한 문서 유지

  • AI가 목적에 맞는 코드를 생성하려면 세부적인 요구사항 전달이 필수임
  • 다른 개발자도 동일한 정보를 AI에 제공해야 하므로, 표준화된 형식의 문서를 코드 저장소에 포함해야 함
    • 요구사항, 제약, 아키텍처, 코딩 표준, 디자인 패턴 등을 상세히 기록
    • UML 다이어그램, 플로우차트, 의사코드 등을 활용해 복잡한 구조를 시각적으로 표현

3. AI를 지원하는 디버그 시스템 구축

  • 효율적인 디버그 시스템을 마련해 AI가 코드 기능을 빠르게 검증할 수 있도록 해야 함
    • 예: 분산 시스템의 모든 노드 로그를 수집해 “데이터가 모든 노드로 전송됨” 등 요약 정보를 제공
  • 이를 통해 명령어 실행 비용 절감과 문제 식별 속도 향상이 가능함

4. 코드 리뷰 수준 표시

  • 코드의 중요도에 따라 리뷰 강도를 구분해야 함
    • 예: AI가 작성한 함수 뒤에 //A 주석을 추가해 인간 검토 여부를 표시
  • 이 체계는 검토되지 않은 코드의 식별과 관리를 용이하게 함

5. 고수준 명세 작성 및 직접 테스트

  • AI는 테스트 통과를 위해 모의 객체나 하드코딩 값으로 속임수를 쓸 수 있음
  • 이를 방지하기 위해 속성 기반 테스트(property-based testing) 를 직접 작성해야 함
    • 예: 서버를 재시작하고 데이터베이스 값의 일관성을 검증
  • 테스트 코드는 AI가 수정하지 못하도록 별도 영역에 분리해야 함

6. 인터페이스 테스트의 분리

  • AI가 다른 코드 맥락을 모른 채 인터페이스 테스트를 작성하도록 해야 함
    • 구현 AI의 영향을 받지 않아 테스트의 객관성이 유지됨
  • 이 테스트 역시 AI가 임의로 수정하지 못하도록 보호해야 함

7. 엄격한 린팅 및 포맷팅 규칙

  • 일관된 코드 스타일과 린팅 규칙은 품질 유지와 오류 조기 발견에 필수적임
  • AI와 인간 모두가 코드 품질을 쉽게 점검할 수 있음

8. 컨텍스트별 코드 에이전트 프롬프트 활용

  • 프로젝트별 CLAUDE.md 등 프롬프트 파일을 사용해 AI의 초기 이해 비용을 줄임
  • 코딩 표준, 디자인 패턴, 요구사항 등을 포함해 AI의 코드 생성 품질과 효율성을 높임

9. 보안 위험 함수 식별 및 표시

  • 인증, 권한, 데이터 처리 등 보안 민감 함수를 명시적으로 표시해야 함
    • 예: //HIGH-RISK-UNREVIEWED//HIGH-RISK-REVIEWED 주석 사용
  • AI가 해당 함수를 수정하면 리뷰 상태를 자동 변경하도록 설정해야 함
  • 개발자는 항상 이 상태가 정확한지 확인해야 함

10. 코드 복잡도 최소화

  • 불필요한 코드 한 줄도 AI의 컨텍스트 창을 차지하고 비용을 증가시킴
  • 가능한 한 단순한 구조로 유지해 AI와 인간 모두의 이해도를 높여야 함

11. 실험과 프로토타입을 통한 문제 탐색

  • AI 코드 생성의 저비용 특성을 활용해 다양한 해결책을 실험할 수 있음
  • 최소한의 명세로 여러 프로토타입을 만들어 최적의 접근법을 탐색

12. 무분별한 대규모 생성 금지

  • 복잡한 작업은 작은 단위로 분할해 AI가 단계적으로 처리하도록 해야 함
    • 예: 전체 프로젝트 대신 개별 함수나 클래스를 생성
  • 각 구성요소가 명세에 부합하는지 검증해야 하며,
    코드의 복잡성을 통제하지 못하면 프로젝트를 초기 상태로 되돌려야 함

[출처] https://news.hada.io/topic?id=26491

Loading

28 12월 2025

 [一日30分 인생승리의 학습법] [알아봅시다] 50대 시니어 개발팀장이 읽으면 좋은 추천도서 [두번째]

 [一日30分 인생승리의 학습법] [알아봅시다] 50대 시니어 개발팀장이 읽으면 좋은 추천도서 [두번째]

50대 IT 시니어 개발자이자 팀장 역할을 수행하시는 분들께는 단순히 기술적인 전문성을 넘어, 조직 관리의 지혜, 인생의 철학, 그리고 급변하는 AI 시대의 통찰을 균형 있게 다루는 책들이 필요합니다.

현장의 풍부한 경험을 더 깊은 통찰로 승화시켜 줄 교양서 20권을 네 가지 카테고리로 나누어 추천해 드립니다.


1. 리더십과 조직의 본질 (팀장을 위한 지혜)

실무자에서 관리자로, 또는 관리자에서 리더로 진화할 때 마주하는 인간관계와 조직의 문제를 다룹니다.

  1. 실리콘밸리의 팀장들 (Radical Candor) | 킴 스콧

    • ‘완전한 솔직함’이 어떻게 팀의 성과를 만드는지 보여주는 현대 리더십의 교과서입니다.

  2. 하이 아웃풋 매니지먼트 | 앤디 그로브

    • 전 인텔 CEO가 쓴 경영의 정석입니다. ‘중간 관리자’의 성과를 어떻게 측정하고 극대화할지 다룹니다.

  3. 매니징 휴먼 (Managing Humans) | 마이클 롭

    • 애플, 구글 등에서 근무한 저자가 기술직군 특유의 문화를 바탕으로 쓴 유머러스하고 날카로운 관리 지침서입니다.

  4. 데일 카네기 인간관계론 | 데일 카네기

    • 고전은 이유가 있습니다. 세대 차이를 넘어 사람의 마음을 움직이는 기본 원칙을 되새기게 합니다.

  5. 겸손한 리더십 | 에드거 샤인

    • 권위가 아닌 ‘질문’과 ‘관계’를 통해 팀원들의 잠재력을 끌어내는 법을 제안합니다.

2. IT 철학과 시스템 사고 (시니어 개발자를 위한 통찰)

기술 그 너머의 아키텍처와 엔지니어링의 본질을 깊이 있게 통찰하게 돕는 도서들입니다.

  1. 맨먼스 미신 (The Mythical Man-Month) | 프레더릭 브룩스

    • 50년 전의 책이지만 소프트웨어 공학의 난제는 변하지 않았음을 보여주는 필독서입니다.

  2. 피닉스 프로젝트 | 진 킴 외

    • 소설 형식으로 IT 운영과 개발의 갈등, 그리고 DevOps가 왜 필요한지를 흥미진진하게 풀어냅니다.

  3. 구글 엔지니어는 이렇게 일한다 | 타이터스 워터스 외

    • 단순 코딩이 아닌 ‘시간에 따라 지속 가능한’ 엔지니어링이 무엇인지 구글의 사례로 보여줍니다.

  4. 생각에 관한 생각 | 대니얼 카너먼

    • 인간의 인지 편향을 다룬 행동경제학 명저로, 기술적 의사결정 시 범하기 쉬운 오류를 방지해 줍니다.

  5. 시스템 사고의 기술 | 도넬라 메도즈

    • 복잡한 조직과 소프트웨어 시스템을 전체적인 관점에서 바라보는 통찰을 제공합니다.

3. 인생의 후반전과 철학 (50대를 위한 위로와 성찰)

커리어의 정점에서 인생의 의미와 품격을 고민하는 시기에 읽기 좋은 책들입니다.

  1. 마흔에 읽는 쇼펜하우어 | 강용수

    • 고통과 고독을 긍정하고 자신만의 행복을 찾는 철학적 조언을 담고 있습니다.

  2. 백년을 살아보니 | 김형석

    • 100세 철학자가 들려주는 인생의 황금기(60~75세)에 대한 이야기는 50대에게 큰 위안이 됩니다.

  3. 도둑맞은 집중력 | 요한 하리

    • 정보 과잉 시대에 리더로서 어떻게 본질에 집중할 것인가에 대한 깊은 질문을 던집니다.

  4. 장자 (또는 장자 관련 해설서)

    • 비움과 여유의 미학을 통해 조직 내 갈등이나 커리어의 압박에서 벗어나는 지혜를 줍니다.

  5. 나이 들어가는 내가 좋습니다 | 요시모토 바나나 외

    • 나이 듦을 쇠퇴가 아닌 ‘익어감’으로 받아들이는 태도를 가르쳐 줍니다.

4. 기술 트렌드와 미래 통찰 (AI와 비즈니스 환경)

후배들과 대화하고 미래 전략을 세우기 위한 거시적인 시각을 제공합니다.

  1. AI 이후의 세계 | 헨리 키신저, 에릭 슈미트 외

    • AI가 인류의 정치, 사회, 철학에 미칠 영향을 거물급 인사들이 논합니다.

  2. 불변의 법칙 | 모건 하우절

    • 세상은 변해도 변하지 않는 인간의 본성과 돈의 흐름에 대해 이야기합니다.

  3. 제로 투 원 | 피터 틸

    • 경쟁이 아닌 ‘독점적 가치’를 창출하는 기술 비즈니스의 본질을 꿰뚫습니다.

  4. 코드 너머, 회사보다 오래 남을 개발자 | 김상기 외

    • 시니어 개발자가 회사의 부품이 아닌 독립된 전문가로 살아남기 위한 전략을 담았습니다.

  5. 수축사회 | 홍성국

    • 인구 감소와 저성장 시대, 리더로서 미래 환경을 어떻게 대비해야 할지 거시 경제적 안목을 줍니다.


Tip: 한꺼번에 다 읽기보다는, 현재 팀 내에서 겪는 고민이 있다면 **1번(리더십)**이나 2번(시스템) 카테고리에서 한 권을, 마음의 여유가 필요하시다면 3번(철학) 카테고리에서 한 권을 골라 병행해 보시는 것을 추천드립니다.

Loading

30 11월 2025

[인공지능 서비스 보안] 탈옥 공격으로부터 LLM을 보호하는 방법 , How to Protect LLMs from Jailbreaking Attacks

[인공지능 서비스 보안] 탈옥 공격으로부터 LLM을 보호하는 방법 , How to Protect LLMs from Jailbreaking Attacks

탈옥 공격으로부터 LLM을 보호하는 방법

노아 플라이슈만, 에이미 와고너 박사, 앙드레 응우옌 박사

Loading

9 10월 2025

[一日30分 인생승리의 학습법] ▲ 2025년 가장 인기 있는 프로그래밍 언어 (spectrum.ieee.org)

[一日30分 인생승리의 학습법] ▲ 2025년 가장 인기 있는 프로그래밍 언어 (spectrum.ieee.org)

  • Python > Java > C++ > SQL > C# > JavaScript > TypeScript > C > Shell > Go > R > PHP > Kotlin > Rust > Dart > Swift
  • IEEE Spectrum 조사 결과 Python이 올해도 1위를 차지, JavaScript는 3위에서 6위로 떨어짐
  • 이 변화는 웹 개발에 많이 쓰이는 JavaScript가 AI 기반 코딩(예: vibe coding)으로 대체되는 흐름과 연관된 것으로 분석됨
  • 전통적으로 사용되던 Stack Exchange 질문 수, GitHub 활동 같은 지표는 AI 도입 이후 급감하여, 언어 인기 측정의 기존 방법이 흔들리는 상황
  • AI 코드 생성이 보편화되면서 언어의 문법·구조 차이 중요성이 줄고, 특정 언어에 집착하지 않는 흐름이 뚜렷해짐
  • 이는 새로운 언어 등장과 생태계 확산을 막고, 결국 프로그래밍 언어 인기도의 개념 자체가 사라질 가능성을 보여줌

개요

  • IEEE Spectrum이 2025년 주요 프로그래밍 언어와 트렌드를 종합적으로 분석한 결과를 발표
  • 이 순위는 취업 시장, 오픈소스 생태계, 학계 및 업계 활용도 등 다양한 관점을 반영
  • 주요 언어별 특징, 성장 배경, 그리고 기술 분야별로 특화된 언어에 대한 정보도 함께 제공

올해의 언어 순위

  • 2025년 Spectrum 기본 순위에서 Python이 1위 유지, JavaScript는 6위로 하락함
  • Jobs 순위에서도 Python이 1위로 올라섰고, SQL은 여전히 채용 시장에서 강력한 경쟁력을 보유함
  • 전체 언어 관련 Stack Exchange 질문 수는 2024년 대비 22% 수준으로 감소했음

순위 산정 기준

  • 인기도: 다양한 온라인 포럼, 소프트웨어 저장소, 구인 구직 데이터, 검색 트렌드 등을 활용해 산정함
  • 현업 활용도: 기업 채용 공고와 오픈소스 프로젝트 참여도를 기준으로 실제 시장에서 많이 쓰이는 언어를 분석함
  • 분야별 분석: AI, 임베디드, 웹, 모바일 등 기술 세부 분야에서 두드러진 언어 선정 기준을 반영함
  • 인기도 측정을 위해 Google 검색량, Stack Exchange 질문, GitHub 활동, 논문 언급 등 다양한 지표를 활용했음
  • 하지만 개발자들이 LLM(ChatGPT, Claude 등)과의 대화로 문제를 해결하면서 공개된 데이터 신호가 줄어듦
  • AI 도구(Cursor 등) 덕분에 질문 자체가 줄어 기존 지표의 유효성이 약화됨

AI와 언어의 경계 희미화

  • 숙련된 개발자부터 초보자까지 AI에 의존하면서 언어의 문법, 제어 구조에 대한 신경이 줄어듦
  • AI는 충분한 학습 데이터만 있으면 어떤 언어로도 코드 생성이 가능함
  • 이에 따라 언어 선택은 하드웨어의 CPU 명령어 차이처럼 부차적인 요소로 전락할 수 있음
  • 향후 언어 인기도 논쟁은 철도 궤간 비교 수준의 비주류 화제로 밀려날 수 있음

새로운 언어의 등장이 더욱 어려워 질 것

  • 과거에는 책, 데모, 샘플 코드만으로도 언어 생태계가 퍼질 수 있었음 (예: The C Programming Language)
  • 그러나 AI는 대량의 학습 데이터를 요구하기 때문에 신생 언어는 지원이 불리함
  • 실제로 덜 사용되는 언어에서 AI가 더 나쁜 결과를 내는 현상이 보고됨
  • 이는 새로운 언어가 임계 질량을 확보하기 어려운 환경을 만들 수 있음

프로그래밍의 미래

  • 현대 언어는 본질적으로 데이터 처리 추상화와 개발자 오류 방지 두 가지 역할을 수행함
  • 그러나 AI 발전은 언어 구조보다 프롬프트 → 중간 언어 → 실행이라는 새로운 흐름을 가능케 함
  • 이 경우 소스 코드를 유지·수정하기보다 프롬프트를 조정해 재생성하는 방식이 자리잡을 수 있음
  • 미래 프로그래머의 역할은 언어 문법보다는 아키텍처 설계, 알고리듬 선택, 시스템 통합 능력에 집중될 전망임

결론과 전망

  • 프로그래밍은 1950년대 컴파일러 등장 이후 최대 변혁기를 맞이하고 있음
  • AI 거품이 일부 꺼지더라도 코드 작성을 돕는 LLM 활용은 지속될 가능성이 높음
  • 따라서 2026년 이후에는 “인기 언어”라는 개념 자체가 의미를 잃을 수 있으며, 인기도를 측정하는 새로운 지표가 필요함

[출처] https://news.hada.io/topic?id=23330

Loading

6 9월 2025

[python 데이터분석] [jupyter] 주피터 노트북에 이미지 삽입

[python 데이터분석] [jupyter] 주피터 노트북에 이미지 삽입

python ide로 많이 사용하는 jupyter notebook에 이미지를 삽입하는 방법입니다!

방법은 두가지가 있습니다

먼저 패키지를 설치하고

# !pip install IPython 
from IPython.display import Image  # 주피터 노트북에 이미지 삽입

1. 코드블럭 안에 삽입하는 법

Image(“파일경로/파일명.확장자명”)

ex) Image(“img/picture.png”)

2. markdown 안에 삽입하는 법

![이미지이름?](파일경로/파일명.확장자명)

ex) ![nn](img/99.01_01.png)

[출처] https://ssoondata.tistory.com/87

 

Loading

26 8월 2025

[一日30分 인생승리의 학습법] 유능한 리더들은 어떤 능력으로 불확실성을 헤쳐나가는가

[一日30分 인생승리의 학습법] 유능한 리더들은 어떤 능력으로 불확실성을 헤쳐나가는가

유능한 리더들은 어떤 능력으로 불확실성을 헤쳐나가는가

67.유능한-리더들이-불확실성을-어떻게-헤쳐나가는가.png

복잡하고 어려운 상황을 유연하게 헤쳐 나갈 줄 아는 리더들은 무엇을 알고, 어떻게 다르게 행동할까? 그런 능력이 있는 리더를 본다면 어떤 모습이 보일까?

이 질문은 Innovation Tactics 카드 덱의 저자 톰과 존이 최근 대화에서 던진 화두다. 보통 이런 역량들은 ‘소프트 스킬’이나 ‘문화 적합도’ 같은 포괄적인 개념으로 치부되곤 한다.

그런데 만약 이 능력들을 명확하게 정의한다면 어떨까?

우리는 먼저 “무엇이 보일까?”라는 질문으로 일반적인 행동들을 묘사했고, 이어서 ‘~할 수 있는 능력’(the ability to…)이라는 형식으로 정의를 작성했다. 설명은 되도록 전문 용어 없이 쉽게 풀어쓰려 노력했다.

또한, 이러한 능력을 가진 사람을 채용하거나, 회사에서 그런 능력을 요구하는 면접을 준비할 때 참고할 수 있도록 인터뷰용 샘플 질문도 포함했다.

참고로 여기서 ‘역량(capabilities)’이라는 단어를 쓴 이유는, 개인이 자신의 환경을 만드는 면도 있지만, 많은 능력은 단순 개인이 아니라 여러 사람의 집단에서 나타나는 특성이나 행동, 능력으로 이해해야 하기 때문이다.

우리가 문제의 일부임을 인정하기 (Accept We Are Part of the Problem)

자신이 현재 상황을 만들거나 악화시키는 데 어떤 역할을 했는지 인지하고 받아들이는 능력.

인터뷰 질문: 문제에 자신이 일조했다는 걸 깨달았던 구체적인 경험을 알려주세요. 그 깨달음에 도달한 과정과 그 후에 행동이 어떻게 달라졌는지 말씀해 주세요.

새로운 상호작용 방식을 장려하기 (Encourage New Interaction Patterns)

개인을 바꾸거나 제거하는 데만 집중하지 말고, 환경 속에서 새로운 소통과 협력의 방식을 촉진하는 능력. 사람들이 서로 관계를 맺고 새로운 정보와 경험에 접할 수 있도록 돕는 역할을 말한다.

인터뷰 질문: 사람들이 새로운 방식으로 소통하거나 정보를 공유하도록 이끈 경험이나, 사람들이 전에 접하지 못한 새로운 정보나 경험을 접하게 한 사례를 이야기해 주세요. 변화의 필요성을 느끼게 된 계기와 그 결과도 함께 알려주세요.

인내하며 다양성을 존중하기 (Patient Divergence)

해답이나 앞으로 나아갈 길을 서두르지 않고 생산적인 다양성을 장려하는 능력. 창의적 탐색을 위한 환경을 조성하고 여러 가지 ‘실마리’를 따라가면서도 강제로 일치시키지 않고 자연스럽게 조율이 일어나도록 하는 것이다.

인터뷰 질문: 복잡한 문제를 다루면서 팀이 서두르지 않고 해결책을 찾아갈 수 있도록 이끈 경험이 있나요? 그 과정을 어떻게 관리했고, 결국 어느 지점에서 방향을 정하게 되었나요?

가능한 요인 다각도로 파악하기 (Identify Plausible Contributors / Multiple “Causes”)

문제에 기여할 법한 여러 요인을 파악하고, 서로 상충하는 듯해도 모두 염두에 두는 능력. 단일 원인만을 찾으려는 충동을 억제하는 것도 포함된다.

인터뷰 질문: 여러 복합적인 원인이 얽힌 문제를 경험한 적 있나요? 그 문제를 어떻게 다루었고, 다음 행동을 어떻게 결정했나요?

현재의 힘 (Power of the Present)

이상적이고 미래지향적인 ‘목표 상태’나 ‘격차’를 개선의 유일한 길로 보기보다는, 지금 이 순간과 현재 상황 속에 잠재된 가능성을 활용하는 능력. 지금 여기에서 출발해, 현재 작동하고 있는 것들을 찾아내고 인접한 여러 선택지를 탐색하는 것에 초점을 맞춘다.  문제가 있거나 힘든 부분에만 집중하는 대신, 현재 잘 작동하는 점들을 찾아 배우고 증폭시켜 장애물을 극복한다.

인터뷰 질문: 리더로서 우리는 종종 두 극단 사이에서 고민한다. 한쪽은 우리가 도달하고자 하는 뚜렷한 비전을 향해 큰 도약을 추진하는 것이고, 다른 쪽은 바로 지금 있는 곳에서 시작해 잘 돌아가는 부분을 파악하고 작은 변화를 꾸준히 시도하는 것이다. 이런 긴장을 탐색해야 했던 상황이 있나요? 그때 어떻게 대처했는지 설명해 주세요.

다양한 관점 융합하기 (Blend Diverse Perspectives)

특히 자신의 신념이나 기본값에 도전하는 다양한 관점을 찾아내고 수용하는 능력. ‘가장 많이 아는 사람이 되는 것’을 추구하는 태도를 경계하며, 모든 상황에서 가장 틀린 사람은 자신이 가장 전체적인 시각을 가지고 있다고 믿는 사람임을 인지한다. 대신 여러 관점의 융합을 다수 가능성의 원천으로 보아, 다양한 경로가 나타날 수 있게 한다.

인터뷰 질문: 다양한 관점, 특히 당신이 도전적으로 느꼈던 시각들까지 포용할 필요가 있었던 경험을 이야기해 주세요. 그 경험이 공동의 결정과 이후 행동에 어떤 영향을 미쳤나요?

인내심과 회복 탄력성 (Patience and Self-Repair)

반복적으로 개입하기보다, 특정 상황이 자연스럽게 진행되고 시간이 지나면서 스스로 해결되도록 인내하며 지켜보는 능력.

인터뷰 질문: 어떤 상황에서 개입하지 않고 스스로 해결되도록 둔 경험이 있나요? 그런 결정을 내리게 된 이유와 그 결과는 어땠는지 이야기해 주세요.

영향 예측 (Anticipate Effects)

새롭게 나타나는 행동이나 결과, 그리고 그로 인한 여러 차례의 예상치 못한 파급 효과들을 예견하는 능력(반드시 예측하는 것은 아님). 예상치 못한 결과가 예외가 아니라 규칙임을 받아들이고 끊임없이 상황 신호를 살피는 자세가 필요하다.

인터뷰 질문: 어려운 결정을 내릴 때 예상치 못한 부작용을 미리 점검해야 했던 경험이 있나요? 어떤 점을 특히 주의 깊게 봤나요?

호기심과 가벼운 접근 (Curiosity and Light Touch)

판단하거나 즉시 행동하려는 충동을 억제하고, 마음속에 떠오르는 생각과 감정을 여유롭게 탐색할 공간을 만드는 자세로, 호기심 어린 마음가짐으로 상황에 접근하는 능력.

인터뷰 질문: 즉각적인 판단을 내리려다 스스로 멈추고 호기심을 선택했던 순간을 이야기해 주세요. 그 마음가짐의 변화는 어떻게 일어났나요?

양쪽 모두 인정하기 (Both/And)

서로 반대되는 힘이나 생각들이 상호 의존적임을 인식하고 존중하는 능력. 많은 상황이 어느 하나를 선택하는 ‘양자택일’이 아니라, 겉으로는 모순되는 요소들이 공존하는 ‘양자 모두’를 잘 조율해 나가는 과정임을 이해하는 것이다. 복잡한 문제를 단순한 선택지로 줄여서 해결하려 하지 않는다.

인터뷰 질문: 표면적으로는 단순한 선택 문제처럼 보였던, 양자택일 상황에 직면했지만 실제로는 ‘둘 다’인 상황을 경험한 적 있나요? 그때 어떻게 상황을 해결했나요?

안전하게 개입하기 (Intervene Safely)

부작용이나 해를 최소화하면서 동시에 긍정적인 행동이나 신호, 패턴이 나타나도록 개입하는 능력. 부정적 영향이 나타나면 빠르게 완화하고, 긍정적 효과가 생기면 증폭하고 지속시키는 것이다. 이 기술을 갈고닦아도 항상 성공하거나 옳은 판단만 하는 것은 아니지만, 발전시키면 도움이 된다.

인터뷰 질문: 팀과 함께 새로운 일하는 방식이나 상호작용, 행동 방식을 시도해 본 적 있나요? 무엇을 시도할지 어떻게 결정했고, 계속 강화할지 아니면 바꿀지 어떻게 판단했나요?

직관과 추론의 균형 맞추기 (Abduction and Intuition)

한정된 데이터 안에서 논리적 추론과 직관적 추론(가설추론)을 조화롭게 활용하는 능력. 논리적이고 명확한 결론에만 갇히지 않고, 복잡하고 불명확한 패턴 속에서 직관적으로 도약하는 인간 고유의 능력을 발휘하는 것이다.

인터뷰 질문: 논리와 직관을 함께 활용해야 했던 경험을 이야기해 주세요. 과정과 결과는 어땠나요? 그 과정에서 다른 사람들은 어떻게 참여했나요? 그 과정에서 데이터는 어떻게 활용되었나요, 또는 활용되지 않았나요?

다양한 강점과 역량 수용하기 (Accept Diverse Strengths and Skills)

우리가 개인적으로 갖지 않았거나 중요하게 여기지 않는 강점과 관점을 인정하고 존중하는 능력. 스킬과 영향력을 인지하는 데 있어 전지전능하지 않다는 점을 이해하며, 무심코 개인이나 팀의 중요한 부분을 저평가할 위험이 있음을 인지하는 것이다.

인터뷰 질문: 잘 알지 못하는 강점이나 역량을 평가해야 했던 경험이 있나요? 그 역량이 당신의 가치관과 달라 평가절하될 위험이 있을 때 어떻게 접근했나요?

협력적으로 상황을 파악하고 환경을 만들어 가기 (Collaboratively Sense and Shape)

문제를 단순화하거나(“그냥 ~하면 된다”) 상황 해석을 독점하거나 통제하려는 충동을 억제하며, 다른 사람들과 함께 문제를 이해하고 상황을 개선할 방향을 만들기 위해 협력하는 능력.

인터뷰 질문: 다른 사람들과 함께 문제의 의미를 파악하고, 그들과 협력해 환경을 조성하여 실제 변화를 이끌어낸 경험에 대해 이야기해 주세요.

일치가 아닌 일관성 추구하기 (Coherence vs. Alignment)

모든 세부 사항의 완전한 일치를 강요하기보다는, 경계를 설정하고 ‘넘지 말아야 할 선’은 지키면서도 그 안에서 사람들 스스로 다양한 방향을 폭넓게 탐색하도록 권장하는 능력. 강요된 일치는 취약하다는 점을 인정하고, 일반적으로 일관성 있는 행동이 더 탄탄하고 지속 가능함을 이해한다.

인터뷰 질문: 사람들을 행동하게 해야 하는 상황에서 모두가 세세한 부분까지 완벽히 일치하도록 강요하지 않고도 일을 진행한 경험이 있나요? 이상적인 최종 상태를 정의하지 않고 대략적인 일관된 방향을 어떻게 정했나요?

씨앗을 심고 성장시키기 (Plant Seeds—Help Them Grow)

산출물을 미리 계획하고 완성하는 구조적인 결과물이 아니라, 심고 자라며 진화하는 유기체처럼 바라보는 능력. 범위를 엄격하게 잡기보다는 가볍게 두고, 시간을 엄격한 제한조건이 아닌 가능성을 열어주는 제약으로 활용한다.

인터뷰 질문: 요구사항의 확실성과 타임박스 및 일정 활용을 적절히 조화시키고, 예상치 못한 새로운 가치가 등장할 가능성을 열어 두는 당신의 방식을 보여주는 사례가 있나요?

업무 방식 맞춤 조정하기 (Tailor Ways of Working)

과제의 성격과 상황에 맞게 업무 방식을 조정하는 능력. 상황에 따라 다음 방식을 조합해 활용한다:

  • 단순하게 바로 실행하기
  • 체계적이고 큰 계획 세우기
  • 특정 결과를 목표로 실험하기
  • 비교적 느슨하고 다양한 실험으로 새로운 가능성 관찰하기

 …인간이 관여할 때는 후자의 방법을 선호하는 경향이 있다는 점을 이해한다.

인터뷰 질문: 과제의 특성에 따라 본인과 팀의 업무 방식을 어떻게 달리 적용했는지 대비되는 사례를 공유해 주세요. 계획 수립과 실행 접근 방식을 어떻게 바꾸었나요?

불확실성에 맞서기 (Facing Uncertainty)

A) 상황에서 가장 불확실한 부분으로 적극 다가가되, B) 익숙하고 잘 알고 있는 부분에서 ‘빠른 성과(quick win)’를 얻는 것 사이에서 균형을 맞추는 능력. 불확실성을 난관이 아니라 기회의 신호로 보고, 복잡한 도전을 환영하는 문화를 만드는 것이다 (단순화하려 하지 않고).

인터뷰 질문: 빠른 성과와 주요 불확실성 영역 해결 사이에서 균형을 맞춰야 했던 경험을 이야기해 주세요. 어떤 방식으로 접근했고, 팀에 어떤 지원을 했으며 학습과 성장을 어떻게 이끌었나요?

참고 사항

  1. 실제 면접에서 이 질문들을 사용하기 전에는 반드시 내부적으로 이 역량들에 대해 논의하고 스스로 답변을 준비해 보시길 권합니다. 회사에서 이 역량들이 얼마나 중요하게 여겨지고 있는지, 이 역량을 가진 사람들이 잘 성장하는지 아니면 어려움을 겪는지, 회사 문화가 이런 역량이 발현되는 방식을 어떻게 형성하는지, 그리고 이 역량들을 어떤 단어로 표현하는지 등을 점검해 보십시오.
  2. 이 글에는 아마도 너무 많은 전문 용어와 이론을 사용했을 겁니다. 죄송합니다. 이해하기 쉬운 언어와 현장에서 실제로 적용할 수 있도록 이 역량들을 효과적으로 전달하는 능력을 키우기 위해 계속 노력하고 있습니다!
  3. 명확한 역량을 정의하는 일은복잡성을 고려할 때는 다소 단순화한 측면이 있을 수 있습니다. 이 역량들은 개인 고유의 것이 아니라 환경과 관계에 깊이 얽혀 있습니다. 커뮤니티 내 깊이 있는 분들이 이에 대해 지적하실 수 있음을 알고 있으며, 피드백을 환영합니다.
  4. 모든 일에 이런 접근법을 다 적용할 수 있는 경우는 매우 드뭅니다. 그렇게 하면 팀이 지칠 수 있기 때문입니다. ‘업무 방식 맞춤 조정하기’ 역량 설명에서도 이 점을 언급했습니다. 본 글에서는 복잡한 문제와 환경에 초점을 맞췄지만, 결과는 항상 다양하게 나타난다는 점을 기억하세요.
  5. 많은 조직들은 복잡성을 직접적으로 언급하거나 전문 용어를 사용하지 않더라도, 복잡성을 효과적으로 다루는 방식을 발전시켜 왔습니다. 위에 나열된 역량들이 여러분이나 회사 내 다른 사람들에게는 익숙하지 않거나 낯설게 들릴 수 있다는 점을 인지하며 이 글을 살펴보시기 바랍니다. “우리 회사는 이런 걸 안 한다”고 결론 내리기 전에, 여러분만의 방식과 맥락 속에서 어떻게 이런 역량을 실현하고 있는지 자문해 보시길 바랍니다.

원문: How Capable Leaders Navigate Uncertainty and Ambiguity

[출처] https://blogbyash.com/translation/how-capable-leaders-navigate/

Loading

29 5월 2025

[인공지능 기술] [알아봅시다] 개발자의 chatGPT 활용법

[인공지능 기술] [알아봅시다] 개발자의 chatGPT 활용법

25931365-b065-467e-bd43-44127efdf182.png

서론

현대 소프트웨어 개발 환경에서 AI 비서로 자리 잡은 ChatGPT는 단순한 문답을 넘어 다양한 개발 단계에서 생산성을 크게 향상시켜 줍니다. 이 포스트에서는 코드 작성부터 테스트, 문서화, CI/CD 파이프라인 통합까지 개발자가 ChatGPT를 활용할 수 있는 대표적인 방법들을 살펴봅니다.


1. 코드 스캐폴딩(Scaffolding) 및 초기 구조 생성

  • 프로젝트 템플릿 생성

    • “새로운 Django 프로젝트 기본 설정 코드를 생성해줘”

  • CRUD 엔드포인트 초안

    • “Express.js로 users CRUD API 라우터 코드를 짜줘”

  • 디렉터리 구조 제안

    • “React + TypeScript 프로젝트 구조를 어떻게 잡는 게 좋을까?”

 
javascript
// 예시: Express.js CRUD 스캐폴딩 const express = require('express'); const router = express.Router(); // GET all users router.get('/users'async (req, res) => { // ChatGPT가 제안한 기본 로직 }); // POST create user router.post('/users'async (req, res) => { // ... }); module.exports = router;

2. 디버깅 및 오류 해결

  • 에러 메시지 분석

    • “이 Node.js 에러 스택을 보고 원인과 해결 방법을 알려줘”

  • 코드 리뷰를 통한 버그 찾기

    • “다음 함수에서 잠재적인 null 참조 버그가 있을까?”

  • 리팩터링 제안

    • “이 파이썬 함수의 가독성을 높이도록 리팩터링해줘”


3. 코드 문서화 및 주석 작성

  • 함수/클래스 설명 자동 생성

    • “이 함수의 역할을 한 문장으로 요약해줘”

  • README.md 작성 보조

    • “이 프로젝트의 README 템플릿을 작성해줘”

  • 주석 일관성 유지

    • “이 자바스크립트 코드에 JSDoc 스타일 주석을 추가해줘”

 
markdown
/** * @function addTwoNumbers * @param {number} a - 첫 번째 숫자 * @param {number} b - 두 번째 숫자 * @returns {number} 두 수의 합 */ function addTwoNumbers(a, b) { return a + b; }

4. 테스트 케이스 및 자동화 스크립트 생성

  • 유닛 테스트 템플릿

    • “Jest를 이용한 add 함수 테스트 코드를 작성해줘”

  • 통합 테스트 시나리오

    • “API 엔드포인트 /login에 대한 통합 테스트 계획을 제안해줘”

  • 테스트 커버리지 개선 아이디어

    • “이 모듈의 경로 커버리지를 높이려면 어떤 테스트가 필요할까?”


5. 코드 리뷰 및 최적화 제안

  • 성능 병목 분석

    • “이 SQL 쿼리가 느린 원인과 인덱스 최적화 방안을 알려줘”

  • 비효율적 로직 리팩터링

    • “이 루프를 더 효율적인 함수형 스타일로 바꿔줄래?”

  • 보안 취약점 점검

    • “이 PHP 코드에서 SQL 인젝션 취약점이 있나?”


6. 새로운 기술 학습 및 예제 생성

  • 라이브러리 사용 예제

    • “Pandas에서 groupby와 pivot 테이블을 사용하는 예제를 보여줘”

  • 비교 분석

    • “Django와 Flask 중 어느 것을 선택해야 할까?”

  • 공식 문서 요약

    • “React 공식 문서에서 useEffect 훅 사용법을 요약해줘”


7. CI/CD 파이프라인 및 DevOps 자동화

  • GitHub Actions 워크플로우 생성

    • “Node.js 프로젝트용 GitHub Actions 워크플로우 YAML을 생성해줘”

  • Dockerfile 최적화

    • “이 Dockerfile을 멀티스테이지 빌드로 최적화해줘”

  • 배포 스크립트 작성

    • “AWS EC2에 배포하는 Bash 스크립트를 작성해줘”


8. 커밋 메시지 작성 및 이슈 템플릿

  • 의미 있는 커밋 메시지

    • “다음 변경 내용을 설명하는 커밋 메시지를 작성해줘: 사용자 로그인 로직 수정, JWT 토큰 방식으로 변경”

  • 이슈 템플릿 자동 생성

    • “버그 리포트용 GitHub 이슈 템플릿을 만들어줘”


결론

ChatGPT는 단순히 대화형 AI를 넘어, 개발 생산성을 높여주는 올인원 도구로 발전했습니다.
코드 스캐폴딩에서부터 디버깅, 테스트, 문서화, DevOps 자동화에 이르기까지 일련의 개발 과정을 ChatGPT와 협업함으로써 더 빠르고, 더 안정적이며, 더 효율적인 소프트웨어를 구현할 수 있습니다.
오늘 바로 ChatGPT를 개발 워크플로우에 통합해 보세요!


이 글이 도움이 되었다면, 댓글과 공유 부탁드립니다!

Loading

25 5월 2025

[一日30分 인생승리의 학습법] [Git] 다중 리모트를 사용하여 여러 Git 연동하기(Gitea, GitHub)

post-thumbnail


Git 다중 리모트를 사용하여 Gitea와 GitHub 연동하기

 

한 프로젝트에서 Gitea와 GitHub를 동시에 관리하려면, Git의 다중 리모트(remote) 기능을 사용하면 된다. 다중 리모트를 설정하면, 동일한 로컬 저장소에서 두 개 이상의 원격 저장소로 데이터를 주고받을 수 있게 된다.

여기서 진행할 순서는 다음과 같다:

  1. Gitea와 GitHub 레포지토리 리모트 설정.
  2. 각 리모트를 구분하여 push/pull하는 방법.
  3. 다중 리모트 관리 시 주의사항.

1. 사전 준비: 프로젝트 리포지토리 설정

  • 현재 Gitea의 레포지토리 (wbapp)는 master 브랜치로 연결되어 있다.
    • Gitea의 URL 예시: http://gitea-ip/your-username/app.git
  • GitHub에도 동일한 프로젝트(wbapp)를 만들고, 이를 main 브랜치로 관리하려고 한다.
    • GitHub의 URL 예시: https://github.com/nyaongdev/app.git

먼저 GitHub에 새로운 레포지토리를 생성하고, 여기에 다중 리모트를 설정하도록 하자.


2. 다중 리모트 설정하기

2.1 기존 리모트 상태 확인

로컬 저장소에서 리모트 설정을 확인하려면 터미널이나 명령 프롬프트에서 다음 명령어를 사용한다.


git remote -v

이 명령어를 입력하면 현재 연결된 리모트 목록이 나타난다. 예를 들어:


origin  http://gitea-ip/your-username/app.git (fetch)
origin  http://gitea-ip/your-username/app.git (push)

현재 origin이라는 이름으로 Gitea 리모트가 연결된 상태다.

2.2 GitHub 리모트 추가하기

이제 GitHub 리모트를 추가해야 한다. GitHub 리모트를 추가할 때는 리모트의 이름을 다르게 설정하여, 두 개의 리모트를 구분할 수 있도록 해야 한다. 여기서는 github-nyaong이라는 이름으로 GitHub 리모트를 추가할 것이다.


git remote add github-nyaong https://github.com/nyaongdev/app.git

이제 git remote -v 명령어를 다시 실행하면 다음과 같은 출력이 나올 것이다.


origin         http://gitea-ip/your-username/app.git (fetch)
origin         http://gitea-ip/your-username/app.git (push)
github-nyaong  https://github.com/nyaongdev/app.git (fetch)
github-nyaong  https://github.com/nyaongdev/app.git (push)

이제 origin은 Giteagithub-nyaong은 GitHub를 가리키고 있다.


3. 리모트를 구분하여 Push/Pull 사용하기

이제 각각의 리모트로 push와 pull 작업을 할 수 있는 방법을 살펴보자.

3.1 Gitea와 GitHub에 Push

  • *Gitea (origin)**에 push:
    
    git push origin master
    
  • *GitHub (github-nyaong)**에 push:
    
    git push github-nyaong main

각 리모트를 지정해 브랜치를 푸시(push)할 수 있다. 여기서는 Gitea에는 master 브랜치로, GitHub에는 main 브랜치로 푸시하는 방식이다.

3.2 각각의 리모트에서 Pull

  • *Gitea (origin)**에서 pull:
    
    git pull origin master
  • *GitHub (github-nyaong)**에서 pull:
    
    git pull github-nyaong main

이를 통해 각각의 원격 저장소에서 변경 사항을 로컬 저장소로 가져올 수 있다.

3.3 두 리모트에 동시에 Push하기

Gitea와 GitHub 두 리모트에 동시에 변경 사항을 push하고 싶다면, 두 리모트를 한 번에 지정하여 푸시할 수도 있다.


git push origin master
git push github-nyaong main

이렇게 명령어를 두 번 실행하여 두 곳에 동시에 변경 사항을 적용할 수 있다. 더 자동화하고 싶다면, Git 훅(hook)이나 스크립트를 작성해 한 번의 명령어로 여러 리모트로 푸시하도록 만들 수 있다.


4. 다중 리모트 사용 시 주의사항

4.1 브랜치 관리

  • Gitea에서는 master 브랜치를 사용하고, GitHub에서는 main 브랜치를 사용하는 상황이므로, 브랜치 간의 동기화가 중요하다. 이를 위해 로컬에서 적절히 checkout하고 변경 사항을 푸시해야 한다.
  • 예를 들어, master 브랜치에서 작업한 후 main 브랜치에도 동일하게 반영하려면, 브랜치 병합(merge)을 하거나 리베이스(rebase)를 사용해야 할 수 있다.

# master 브랜치에서 작업 후 main 브랜치로 병합
git checkout main
git merge master
git push github-nyaong main

이와 같이, 각 브랜치가 서로 다르게 유지되지 않도록 주기적으로 병합하여 두 리모트의 코드가 일관되도록 관리하는 것이 좋다.

4.2 충돌 관리

  • 같은 프로젝트를 여러 리모트에 동기화하다 보면, 가끔 충돌(conflict)이 발생할 수 있다. 이 경우, Git은 충돌을 해결해야 푸시할 수 있도록 하며, 이를 해결한 후에 다시 푸시하면 된다.
  • 만약 Gitea와 GitHub 양쪽에서 모두 병렬적으로 작업하고 있다면, 주기적으로 pull을 통해 양쪽의 변경 사항을 확인하고 반영해야 한다.

4.3 협업 시 고려사항

  • 만약 팀원들과 Gitea를 통해 협업하고, 개인적으로 GitHub에도 저장하고 싶다면, Gitea에서 작업한 후 GitHub에 백업하는 형식으로 생각하면 된다.
  • 모든 작업이 Gitea를 기준으로 이루어지고, 완료된 작업을 GitHub에 푸시하는 순서를 정하면 충돌을 줄이고 관리하기 쉽다.

5. 마무리

이제 하나의 프로젝트에서 Gitea와 GitHub 두 리모트를 동시에 관리할 수 있게 되었다. 다중 리모트를 사용하면 하나의 로컬 저장소에서 여러 원격 저장소로 쉽게 데이터를 동기화할 수 있어, 사내의 Git 서버와 외부의 GitHub를 동시에 사용하는 것이 가능해진다.

  • Gitea는 사내 협업을 위한 주요 원격 저장소로 사용하는 형태
  • GitHub는 개인 백업이나 외부 프로젝트 관리용으로 사용하는 형태

[출처] https://velog.io/@nyaong/Git-%EB%8B%A4%EC%A4%91-%EB%A6%AC%EB%AA%A8%ED%8A%B8%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EC%97%AC-%EC%97%AC%EB%9F%AC-Git-%EC%97%B0%EB%8F%99%ED%95%98%EA%B8%B0Gitea-GitHub

Loading

8 4월 2025

[一日30分 인생승리의 학습법] [알아봅시다] 블록체인 게임들의 가능성과 미래

[一日30分 인생승리의 학습법] [알아봅시다] 블록체인 게임들의 가능성과 미래

ChatGPT Image 2025년 4월 8일 오후 07_26_42.png

학습 차원에서 틈틈이 해외 전문가들이 블로그나 미디어 그리고 책에서 쓴 글을 번역 또는 요약 정리하고 있습니다. 이번 포스팅도 그중 하나고요. 거칠고 오역된 부분이 있을 수 있습니다. 제대로 번역되지 않은 부분은 확인 주시면 반영토록 하겠습니다. 이번글은 뱅크리스에 올라온 글을 정리한 것입니다.

2087년 이더리움이 마침내 주류가 되고 연준이 더 이상 존재하지 않게 되면, 역사학자들은 암호화폐의 기원을 2011년 블리자드가 비탈릭 부테린의 월드 오브 워크래프트 캐릭터에 ‘생명을 빨아들이는’ 주문을 너프(nerf)했던 운명적인 순간으로 거슬러 올라갈 것이다.

이 이야기는 15살의 비탈릭이 ‘중앙 집중식 서비스의 공포’에 눈을 뜨게 했고, 마침내 중앙 집중식 비디오 게임의 광기를 종식시킨 이더리움이 탄생하게 된 계기가 됐다.

적어도 우리는 그 방향으로 가고 있다.

안타깝게도 대부분의 기존 블록체인 게임들은 마케팅 페이지를 장식하는 무허가(permissionless) 상호 운용성과 진정한 소유권이라는 멋진 약속에도 불구하고 여전히 위의 검열 사례에 적용을 받을 수 있다.

현재 블록체인 게임들의 (거짓) 약속(The (false) promises of today’s blockchain games)

잠시 시간을 거슬러 올라가 블록체인의 목적을 다시 떠올려 보자. 블록체인은 분산된 데이터베이스에 대한 공유 합의를 촉진하는 역할을 한다. 사람들이 동의하지 않을 때 전체 암호화폐 커뮤니티가 체인 분할을 진행하기 위해 많이 노력하는 것도 이 때문이다. 포킹( Forking)은 화해할 수 없는 차이들 사이에서 합의를 재조정한다.

그렇다면 도대체 왜 블록체인을 기반으로 게임을 개발할까?

같은 이유:비탈릭이 자신이 사랑하던 흑마법사를 약화시키기로 한 블리자드의 결정에 동의하지 않았던 것처럼, 사람들은 게임 세계를 어떻게 구축해야 하는지에 대해 근본적으로 동의하지 않는다. 따라서 블록체인을 통한 게임의 진정한 가능성은 분열된 게임 커뮤니티가 서로의 차이를 해결할 수 있도록 하는 것이다.

문제는 대부분의 블록체인 게임이 여기에 미치지 못한다는 것이다. 액시 인피니티나 크립토키티와 같은 게임은 최소한의 온체인 게임이다. 자산은 온체인 데이터로 존재하지만, 게임의 기본 로직(게임 규칙)과 상태(게임 내 행동 기록)는 중앙화된 게임 서버, 오프체인에 있다.

물론 개인 키를 안전하게 보관하는 한, 당신의 액시(Axie) NFT와 토큰은 불변하는 스마트 컨트랙트 내 데이터로 영원히 존재한다. 하지만 엑시를 개발한 스카이 마비스가 문을 닫는다면, 당신의 엑스 자산 가치도 사라질 것입니다. 소유권은 단순히 지갑에 데이터를 보호하는 것 이상의 의미를 갖는다. 소유권은 해당 데이터가 어디에 있는지, 즉 게임 규칙을 통제하고 발언권을 가질 수 있는 힘이기도 하다.

이들 자산의 금전적 가치는 전적으로 스카이 마비스가 엑스 인피니티 생태계를 상업적인 제품으로 성공적으로 제공할 수 있는 능력에 달려 있다. 웹 3.0으로 광고되지만 플레이어는 오프체인과 중앙에서 계획된 게임의 기본 규칙을 거의 제어할 수 없기 때문에 웹 2.5에 더 가깝다.

실제 웹 3 게임들의 아키텍처(The architecture of actually Web3 games)

검열이 불가능하고 막을 수 없는 블록체인 게임을 만들려면 어떻게 시작해야 할까? 구브시프의 ‘가장 강력한 크립토 게임 논문’에 따르면: 

게임의 로직과 상태는 온체인에 있다. 게임의 규칙(이동, 전투, 채집, 소비 방법)은 오픈소스 및 온체인 스마트 컨트랙트에 규칙으로 포함되어야 한다.

모든 게임 데이터는 블록체인에 있으므로 상호 운용이 가능하다. 게임은 클라이언트에 구애받지 않는다. 

핵심 개발자가 내일 사라져도 플레이어는 게임을 계속 플레이하기 위해 개발자에게 의존할 필요가 없으며, 커뮤니티에 있는 사람들이 플레이어 움직임을 온체인으로 전송하는 자체 클라이언트를 만들 수 있다.

위의 조건들이 충족되면 몇 가지 중요한 일이 일어나기 시작한다.

퍼미션리스 혁신(Permissionless Innovation)

온체인 게임 로직은 첫째 회사가 파산하거나 개발을 포기하더라도 디파이 프로토콜이 영구적으로 실행되는 것과 같은 방식으로 게임 세계는 영속성을 확보하고 계속 존재한다. 로난 샌드포드의 말처럼, 온체인 게임은 ‘현실 독립성'(reality independence)을 제공한다.

둘째, 퍼미션리스 혁신에 문이 열려 있다. 모든 플레이어는 기본 게임 규칙(즉, 디지털 물리를 참조하는 스마트 컨트랙트 형태로 두 번째 레이어 규칙(큐리오는 이를 사용자 생성 로직이라고 부름)을 도입해 게임을 창의적으로 ‘모드'(mod: 게이머가 게임에 새로운 기능을 추가하는 것)할 수 있다.

이것은 혼란스럽게 들일 수 있지만 그렇지 않다. 이것은 간단히 말해 개발자가 기존 프로토콜 위에서 허가 없이 새로운 프로토콜을 구축하는 디파이 결합성 101((one-oh-one으로 발음, 모든 분야의 초보자 대상으로 준비된 과정)이다.

세컨드 레이어 규칙들이 기본 규칙을 위반하지 않는 한, 허용된다. 세컨드 레이어 규칙은 개인 사용자 인터페이스와 로컬 경험만 변경하는 기존 게임들의 애드온/모드와 달리, 다른 모든 플레이어와 공유하는 가상 게임 경험에 영향을 미치는 온체인 스마트 컨트랙트에 내장된다는 것을 주목할 필요가 있다.

예를 들어, 체스 말의 고전적인 움직임을 유지하기로 결정한 완전 온체인 체스 게임은 핵심 개발자의 스마트 컨트랙트에 고전적인 규칙을 협상할 수 없고 변경할 수 없는 것으로 명시할 것이다. 기사는 L자 모양으로만 움직일 수 있고 비숍은 대각선으로만 횡단할 수 있다.

하지만 누구나 이러한 변경 불가능한 디지털 물리학 위에 새로운 세컨드 레이어 규칙을 만들 수 있다. 토큰, 길드 시스템, 상대방의 왕을 점령해 게임에서 승리하는 대신 내 왕을 보드 반대쪽 끝으로 이동시켜야 승리하는 RPG와 같은 퀘스트 라인이 될 수 있다. 토큰 화폐를 통해 죽은 왕을 다시 사거나 상대방과 왕을 교환하는 거래 시스템을 도입할 수도 있다. 기본 규칙의 논리가 허용하는 한 무엇이든 가능하다.

진정한 상호 운용성(True Interoperability)

온체인 게임에서 자산은 하나의 엄격한 게임 로직에 얽매이지 않으며, 가장 넓은 의미에서 최대한 상호 운용이 가능하다. 디파이에서 수천 개 토큰이 자체 규칙 세트, 즉 토큰노믹스 모델을 기반으로 서로 경쟁하는 것과 마찬가지로, 게임 자산은 지속적으로 확장되는 게임 세계에서 또 다른 토큰으로 존재하기도 한다.

반면, 에픽은 포트나이트 게임 자산을 게임 라이브러리 내에서 상호 운용할 수 있도록 허용할 수 있지만, 개발자가 허용하는 경우에만 상호 운용이 가능하다. 웹 2.5 블록체인 게임의 게임 자산도 마찬가지다.

강력한 인센티브(High-Powered Incentives)

이제 퍼즐의 마지막 조각인 인센티브에 대해 알아보자. 기존 게임에는 매우 활발한 모딩 커뮤니티가 많지만, 핵심 개발자의 의지에 따라 운영된다. 마인크래프트 역사가 대표적인 사례다.

경제적인 측면에서 보면 모더들(modders) 재산권은 약하기 때문에 창작에 대한 인센티브가 약하다. 따라서 모드는 일반적으로 이타주의에 기반한 애호가나 취미로 운영되는 경우가 많다.

완전한 온체인 게임은 이 문제를 해결한다. 온체인 게임에서는 생성된 모드가 검열할 수 없고 영구적인 창작물(앞서 언급한 두 번째 레이어 규칙)이 불변의 스마트 컨트랙트에 코드화되므로 플레이어가 모드를 만들려는 인센티브가 더 강력해진다.

토큰, 게임 메커니즘, 사회적 제도, 게임 내에서 플레이어가 만든 규칙의 근간이 되는 소유권 규칙은 플레이어가 완전히 통제할 수 있으며, 허가된 게임 로직과 규칙의 기본 세트에 구속되지 않는다. 가장 중요한 것은 게임 경제 내에서 플레이어가 만든 다른 창작물과 경쟁한다는 것이다.

따라서 온체인 게임 세계에서는 핵심 게임 개발자가 일방적으로 바뀌는 게임 기본 규칙에 대해 스스로 손을 묶는 것을 약속한다. 이것이 바로 비탈릭의 월드 오브 워크래프트 툰(toon)을 살릴 수 있는 방법이다. 게임 독재의 시대는 지나갈 것이다. 이론은 충분했으니 이제 온체인 게임의 몇 가지 예를 살펴보자.

온체인 게임들 살펴보기(Looking at on-chain games)

다크 포레스트는 아마도 온체인 게임의 최고 예일 것이다. 0xPARC 재단의 Gubsheep이 개발한 다크 포레스트는 2019년부터 그노시스(Gnosis)  체인에 배포된 우주를 테마로 한 멀티플레이어 전략 게임이다.

다크 포레스트의 전체 게임 로직과 상태는 온체인에 포함돼 있다.  기존 온라인 게임과 달리 게임 동작을 처리하거나 게임 상태를 저장하는 중앙화된 서버나 데이터베이스가 없다.

앞서 설명한 것처럼, 온체인 게임의 마법은 플레이어가 온체인 속성을 활용해 자발적으로 생성할 수 있는 새로운 주문에 있다. 다크 포레스트에는 이러한 예가 무궁무진하다. 다크 포레스트 플레이어들은 핵심 개발자가 거래 시스템이나 경매장을 위한 패치를 도입하지 않고도 게임 내 자원을 거래할 수 있는 게임 내 마켓플레이스를 만들었다.

다크 포레스트에는 길드 시스템이 내장돼 있지 않기 때문에, 몇몇 플레이어(DFDAO)는 외부 스마트 컨트랙트를 통해 자체적으로 퍼미션리스 온체인 길드 시스템을 구축했다. 이를 통해 많은 소규모 플레이어가 완전히 무신뢰(trustless) 방식으로 자원을 조정하고 모을 수 있었고 숙련된 플레이어가 지배하는 리더보드에서 경쟁력을 갖추기 위한 의도로 사용됐다. DFDAO 블로그에 설명된 대로

DFDAO는 또한 다크 포레스트 게임을 완전히 다른 체인으로 포크했다. 다크 포레스트 아레나라는 포크 버전은 다양한 새로운 게임 모드를 도입했다. 다른 MMORPG에서는 이러한 모든 행위가 불법, 암시장 거래 또는 “해킹”으로 간주될 것이다.  다크 포레스트와 같은 온체인 게임에서는 모든 것이 허용되고 코드 상에서 실행된다.

커뮤니티가 주도한 긴급 명령의 예는 Lattice 팀이 만든 마인크래프트 온체인 버전인 OPCraft에서도 찾아볼 수 있다.  OPCraft의 초기 테스트 출시에서 플레이어들은 자원 수집을 자동화하고, 서로 채팅하고, 맵을 텔레포트하고, 월드 색상을 변경하는 플러그인을 만들었다.

SupremeLeaderOP라는 이름의 한 플레이어는 온체인 스마트 컨트랙트를 배포해 일련의 규칙이 포함된 공산주의 공화국을 만들었다. 자발적으로 공화국에 가입한 모든 플레이어는 사회주의 철학에 따라 기존의 모든 재산을 포기하고 재고를 공동의 국고로 통합해야 했다.

물론 게임에서 긴급 명령의 예는 새로운 것이 아니다. 이브(eve) 온라인 플레이어들은 게임 제작자가 게임 내 길드 도구를 만들지 않았을 때 디스코드(Discord)에서 오프라인 소셜 동맹을 조직했다. 에버퀘스트와 월드 오브 워크래프트 플레이어들은 비공식적인 소셜 화폐 시스템인 ‘DKP(드래곤 킬 포인트)’를 개발해 게임 내 공격대에 투입한 시간에 따라 플레이어를 관리하고 보상을 제공했다.

완전 온체인 게임들에 장애물들(Obstacles to fully on-chain games)

온체인 게임이 그렇게 훌륭하다면 왜 더 널리 보급되지 않았을까? 온체인 게임이 직면한 가장 명백한 장애물은 확장성이다. 모든 플레이어 행동을 온체인으로 전송하는 것은 연산 집약적이기 때문에 대부분의 온체인 게임은 이더리움 메인넷이 아닌 턴 기반(turn-based) 게임이다. 온체인에 영구적으로 존재하는 변경 불가능한 코드는 개발자 부주의로 인해 발생하는 익스플로잇을 패치하기 어렵다는 것을 의미한다.

퍼미션리스 게임은 또한 기회주의적인 플레이어와 봇에게 문호를 개방하는 것을 수반한다. 기존 블록체인 게임인 엑시(Axie)나 페가시(Pegaxy)는 비용이 많이 드는 진입 장벽을 통해 이를 어느 정도 완화하고 있으며, 기존 게임들은 KYC 방법과 선별적 차단을 통해 이러한 문제를 해결하지만, 퍼미션리스 온체인 게임에서는 이러한 중앙화된 수단을 사용할 수 없다.

어떤 면에서 온체인 게임의 문제는 사회적 고착화와 집단 행동 문제로 인해 변화하기 어려운 불완전한 현실 세계 제도(제국주의 체제나 민주주의 정치를 생각해보라)와 매우 유사하다. 커뮤니티와 핵심 개발자 모두가 이러한 문제에 직면해 나쁜 행동을 노골적으로 검열하기보다는 기업가적인 해결책과 창의적인 메커니즘 설계를 통해 나쁜 행동을 억제해야 한다.

이러한 창작물이 다른 점은 게임의 개방적인 구성 덕분에 허가 없이 생성되고 온체인에 내장된다는 점이다.. OPCraft 공산주의 공화국 플레이어들은 그가 누구인지 몰랐지만, 그가 약속을 지킬 것이라는 믿음을 가질 필요는 없었다.

그노시스 체인 기반 외교 전략 게임인 Conquest에서 플레이어는 xDAI 토큰을 스테이킹해 우주선을 생산하고, 동맹을 맺고, 문명 방식으로 서로를 공격한다. 다시 말하지만, 온체인 스마트 컨트랙트를 생성할 수 있다는 것은 플레이어 동맹이 실제 가치가 있는 자산에 묶여 있다는 것을 의미하며, 플레이어 동맹 간 신뢰 없는 상호작용을 보여준다.

온체인 게임에 대한 간단한 참고 사항(A quick note on on-chain game)

온체인 게임은 아직 개념 증명 단계에 머물러 있다. 개발자들은 여전히 최적의 확장 방법을 찾기 위해 노력하고 있으며, 용어 또한 산재되어 있다. 래티스(Lattice)는 이를 자율 세계(Autonomous Worlds)라고 부르고, 비블리오테카(Bibliotheca ) DAO에서는 영원한 게임, 이터널 게임스(Eternal Games) 플레이에서는 무한 게임, 토폴로지에서는 온체인 현실(on-chain realities)이라고 부릅니다. 당신은 아이디어를 얻을 수 있다.

위의 예시는 온체인 게임에서 떠오르는(emergent orders )  몇 가지 사례들일 뿐이지만, 가능성은 무궁무진하다. 모든 디앱의 루트가 블록체인에 공유 상태로 존재하기 때문에 디파이의 오픈소스 구성성을 통해 토큰이 상호 운용되고 다양한 방식으로 잘게 쪼개질 수 있는 것처럼, 블록체인을 완전히 수용하는 게임도 마찬가지일 것이다.

게임 내 통화로 나만의 ERC20 토큰을 발행하라. 종교, 국가, 파벌 등 상상할 수 있는 모든 사회 구조를 형성하고 이를 체인에 올려보라. 보상이나 처벌이 포함된 퀘스트 라인을 토큰으로 작성하고 이를 변경 불가능한 스마트 컨트랙트에 연결해 보라.

기존 게임처럼 현실 세계와 분리되어 있지 않기 때문에 이를 ‘게임 내 경제’라고 부르는 것은 잘못된 명칭이다. 이는 크리에이터와 플레이어 간 경계를 허무는 현실 세계의 가치 경제이고 블록체인에 영구적으로 존재한다. 블록체인은 개인이 자발적으로 내리는 수많은 결정에서 새로운 생산과 거래 방식을 자유롭게 실험하며 지속적으로 발전할 수 있는 역량을 갖추고 있으며, 플레이어가 경제적 가치를 포착할 수 있는 무한한 길을 제공한다.

마무리하며

이 글에서 기존 블록체인 게임에 대해 혹평했지만, 웹 2.5 게임이 여전히 기존 게임보다 더 강력한 소유권을 제공한다는 점은 주목할 가치가 있다. 웹 2.5 게임은 적어도 플레이어가 자유롭게 게임을 종료할 수 있다. 자산이 지적 재산으로 보호되어 판매할 수 없는 기존 게임과 달리, 플레이어는 게임 내 토큰을 판매하고 자신의 시간에 대한 보상을 받을 수 있다.

하지만 웹 2.5 게임이 기존 게임보다 나은 점은 완전한 온체인 게임과 비교했을 때 미치지 못하는 것이기도 하다.

오프체인 게임 로직은 게임이 블록체인 기술의 잠재력을 충분히 활용하지 못하도록 방해한다. 완전한 온체인 게임만이 개방적이고 퍼미션리스 블록체인 인프라가 허용하는 인간의 독창성을 제대로 활용할 수 있다.

가장 위대한 비디오 게임 타이틀과 장르 중 일부는 ‘창발적 질서(emergent order)’의 부산물이다. 이 게임들은 게임 애호가와 취미로 게임을 즐기는 사람들이 “일단 해보고 보자”라는 공통된 패턴을 보여준다. 선풍적인 인기를 끌었던 MOBA(도타)와 타워 디펜스 장르는 모두 워크래프트 3 커스텀 게임 모딩 커뮤니티의 창작물에서 비롯됐다. 배틀그라운드: 배틀그라운드는 원래 FPS 슈팅 게임인 DayZ의 모드로, 다른 FPS 슈팅 게임인 아르마 2의 모드였다. 카운터 스트라이크는 90년대 가장 인기 있었던 게임 중 하나인 하프라이프의 모드였다. 온체인 게임은 이를 한 단계 더 발전시킨 것이다.

[출처] https://brunch.co.kr/@delight412/538

Loading

30 3월 2025

[인공지능 기술]  [Pytorch] Pytorch & LLM Training Pipeline (pytorch로 chatgpt만들기, 기본예제)

[인공지능 기술]  [Pytorch] Pytorch & LLM Training Pipeline (pytorch로 chatgpt만들기, 기본예제)

Pytorch

Pytorych

What

Pytorch는 Opensource Machine Learning(ML) Framework로, Python 언어와 Torch Library를 기반으로 한다. Torch는 Opensource ML Library로, Deep learning을 이용하기 위해서 Lua Scripting으로 작성되었다. 현재, DL 연구를 위해서 가장 선호되는 플랫폼이다.

How to use?

Tools

Pytorch는 클라우드와 로컬, 두 가지 환경에서 활용할 수 있다.

  • In the cloud: Pytorch를 접근하기 가장 쉬운 방법으로, Microsoft를 통해서 접근하거나 Google Colab에서 실행해 볼 수 있다. 링크에만 접근한다면 Microsoft와 Colab에 작성된 Notebook에서 코드를 실행할 수 있다.
  • Locally: 로컬에서는 PyTorch and TorchVision 등을 우선 설치해야한다. 설치 가이드(installation instructions)를 따라서 설치할 수 있다. 다양한 버전이 홈페이지에 게재되어있다. Notebook을 활용하거나 IDE()에서 코드를 작성하여 실행하면 된다.

Pipieline

01 Prerequisites

Pytorch는 python 프로그래밍을 통해,딥러닝과 트랜스포머 개념을 구현해야한다.

02 Library installation

trl : Transformer language odel을 Reinforcement Leanring으로 학습하는데 사용한다.
peft : Prameter-effiecient Fine-tuning(PEFT)방법을 통해서 효율적으로 pre-treined model을 조정한다.
torrch : Opensource ML library
datasets : ML datasets을 로딩(loading) 또는 다운로딩(downloading)하기 위해 하용한다.
Trasformers : Hugging Face가 개발한 라이브러리로, 분류/요약/번역 등과 같은 다양한 텍스트를 위한 task를 수행하기 위해 수천 개의 PLM(pre-trained model)모델을 제공한다.

02-1 pip 를 통해서 pythong package 다운로드한다.

%%bash
pip -q install trl
pip -q install peft
pip -q install torch
pip -q install datasets
pip -q install transformers

02-1 import 통해서 pythong package를 가져온다

import torch
from trl import SFTTrainer
from datasets import load_dataset
from peft import LoraConfig, get_peft_model, prepare_model_for_int8_training
from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments

03 Data Loading and Preparation

03-01 Data loading

허깅페이스의 공개 데이터셋을 로드한다.
load_dataset : 데이터 로드
dataset_name : 로드하기 위한 데이터셋 이름
split parameter를 “train“로 설정하여 학습(traing)데이터로만 설정된 데이터 로드

dataset_name="tatsu-lab/alpaca"
train_dataset = load_dataset(dataset_name, split="train")
print(train_dataset)

03-02 Converting the dictionary into a pandas dataframe

로드한 데이터는 dictionary 타입으로, pandas의 dataframe으로 변환한다.

.to_pandas() : train_dataset을 pandas dataframe으로 변환

pandas_format = train_dataset.to_pandas()
display(pandas_format.head())

04 Model Training

  • Pre-trained Model : Pretrained 모델
  • Tokenizer : 데이터의 토큰화(tokenization)를 위해 사용하며, PLM과 tokenizer를 가져옴
  • AutoModelForCausalLM :
    • from_pretrained 메서드로 PLM을 가져오기 위해 사용
    • pretrained_model_name은 PLM 모델을 지정하며, data type은 모델의 tensor를torch.bfloat16로 설정

*AutoTokenizer:

  • from_pretrained : 가 PLM에 맞는 tokenizer를 가져오기 위해 사용하는 메서드
  • pretrained_model_name과 trust_remote_code를 true로 설정
pretrained_model_name = "Salesforce/xgen-7b-8k-base"
model = AutoModelForCausalLM.from_pretrained(pretrained_model_name, torch_dtype=torch.bfloat16)
tokenizer = AutoTokenizer.from_pretrained(pretrained_model_name, trust_remote_code=True)

05 Training configuration

Training을 위해 training arguments(인수)와 training configurations(구성)이 필요하다. 이는 TrainingArguments로 구성하며, LoraConfig model과 SFTTrainer model의 인스턴스이다.

06 TrainingArguments

output_dir 학습 모델 저장 위치
per_device_train_batch_size 한 학습에 사용하기 위한 학습 샘플의 사이즈
optim 옵티마이저
logging_steps 로깅을 위한 빈도로, n번의 스텝마다 기록
learning_rate 옵티마이저의 learning rate 설정
warmup_ratio
lr_scheduler_type
num_train_epochs
save_strategy

model_training_args = TrainingArguments(
       output_dir="xgen-7b-8k-base-fine-tuned",
       per_device_train_batch_size=4,
       optim="adamw_torch",
       logging_steps=80,
       learning_rate=2e-4,
       warmup_ratio=0.1,
       lr_scheduler_type="linear",
       num_train_epochs=1,
       save_strategy="epoch"
   )

07 LoRAConfig

LoRa(Low-Rank Adaptation)은 Hugging Face가 개발한 PEFT이다. peft 라이브러를 통해서 사용할 수 있다.
현재의 파이프라인에서는 하위 변환 행렬을 16으로 설정한다. LoRa의 매개변수의 스케일링 계수는 32로 서렁한다. 드롭아웃 비율은 0.05로 설정되었다.
CASULA_LM은 인과적 언어 모델(causual lanauge model)의 속성을 초기화한다.

08 SFTTrainer

training data, tokenizer, 모델의 추가 정보를 이용하여 학습한다.

아래는 로드한 텍스트 칼럼의 길이를 컬럼을 추가하여 저장하는 것이다. 이 데이터셋은 0~1000 크기의 텍스트 분포가 크다. (분포를 보여주는 표는 생략)
1024보다 큰 값의 비율을 구한다.

pandas_foramt은 특정 칼럼의 크기가 1024보다 큰것을 찾아 mask로 저장
percentage에 mask가 ‘texst_length’컬럼에서 차지하는 비율을 구함

pandas_format['text_length'] = pandas_format['text'].apply(len)

mask = pandas_format['text_length'] > 1024
percentage = (mask.sum() / pandas_format['text_length'].count()) * 100

print(f"The percentage of text documents with a length greater than 1024 is: {percentage}%")
  • 아래 코드는 SFTTrainer 의 인스턴스를 만들고 있다.
    model=model PLM을 SFTTrainer에 전달
    train_dataset=train_dataset train dataset을 SFTTrainer에 전달
    dataset_text_field="text" 텍스트 데이터를 포함하는 dataset 필드 지정
    max_seq_length=1024 모델 력의 최대 시퀀스 길이를 설정
    tokenizer=tokenizer tokenizer를 SFTTrainer에 전달
    args=model_training_args 모델 트레이닝을 위한 인수를 SFTTrainer에 전달
    packing=True효율적인 훈련을 위한 시퀀스 패킹 설정
    peft_config=lora_peft_config PEFT에 loraConfig 설정
SFT_trainer = SFTTrainer(
       model=model,
       train_dataset=train_dataset,
       dataset_text_field="text",
       max_seq_length=1024,
       tokenizer=tokenizer,
       args=model_training_args,
       packing=True,
       peft_config=lora_peft_config,
   )

09 Training execution

tokenizer.pad_token =tokenizer.eos_token padding token을 eos_token으로 설정(eos, end of sequence)
model.resize_token_embeddings(len(tokenizer)) 모델의 토큰 임베딩 계층을 tokenizer 길이로 설정
model=prepare_model_for_int8_training(model)) 양자화처럼, INT8 정밀도로 트레이닝할 수 있도록 준비
model = get_peft_model (model, lora_peft_config) 주어진 모델을 PEFT 구성에 따따 조정
training_args = model_training_args training_args에 미리 정의된 training 인수를 할당
trainer =SFT_Trainer SFTTrainer 인스턴스를 trainer에 저장
trainer.train() (위의) 설정에 따라 모델을 학습

tokenizer.pad_token = tokenizer.eos_token
model.resize_token_embeddings(len(tokenizer))
model = prepare_model_for_int8_training(model)
model = get_peft_model(model, lora_peft_config)
training_args = model_training_args
trainer = SFT_trainer
trainer.train()

Reference
[1] https://pytorch.org/tutorials/beginner/basics/intro.html
[2] https://www.datacamp.com/tutorial/how-to-train-a-llm-with-pytorch
[3] https://github.com/keitazoumana/Medium-Articles-Notebooks/blob/main/Train_your_LLM.ipynb

[출처] https://velog.io/@jasmine_s2/Pytorch-Pytorch-LLM-Training-Pipeline

Loading