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

나를 만들어준 소프트웨어 에세이들  

https://refactoringenglish.com/blog/software-essays-that-shaped-me/

• 20년간 수천 개의 소프트웨어 블로그 글을 읽었지만, 소수의 에세이만이 사고방식을 근본적으로 변화시켰으며, Joel Spolsky의 "Joel Test"부터 Julia Evans의 순수 JavaScript 옹호까지 10개의 핵심 에세이 소개
• Joel Spolsky의 "Joel Test"는 고용주가 개발자를 존중하는지 평가하는 12개 질문을 제시하며, 소스 관리, 일일 빌드, 버그 우선 수정 등을 통해 개발자의 시간과 집중을 우선시하는지 확인
• Alexis King의 "Parse, don't validate"는 데이터 검증 시 새로운 타입으로 변환하는 기법을 소개하여, 타입 시스템이 애플리케이션 보안과 신뢰성 향상에 기여할 수 있음을 보여줌
• Fred Brooks의 "No Silver Bullet"은 소프트웨어 작업을 본질적 복잡성과 우발적 복잡성으로 구분하며, 도구와 하드웨어 발전으로는 10배 생산성 향상 불가능하다고 주장했으나 AI는 이 이론에 변수를 던짐
• Julia Evans의 순수 JavaScript 에세이는 프레임워크 없이도 ES2018 JavaScript만으로 충분하다는 깨달음을 주었고, 이후 2020년부터 어떤 프로젝트에도 JavaScript 프레임워크나 빌드 스텝을 통합하지 않음

Joel Spolsky의 "Joel Test" (2000)

• Joel Spolsky는 역대 최고의 소프트웨어 블로거이며, 그의 에세이들이 필자의 소프트웨어 접근 방식에 많은 영향을 미침
• "Joel Test"는 고용주가 소프트웨어 팀에 얼마나 잘 투자하는지 평가하는 12개 질문 세트
• 12개 질문 목록
  • 소스 관리 사용 여부
  • 한 단계로 빌드 가능 여부
  • 일일 빌드 수행 여부
  • 버그 데이터베이스 보유 여부
  • 새 코드 작성 전 버그 수정 여부
  • 최신 일정 보유 여부
  • 스펙 보유 여부
  • 프로그래머가 조용한 작업 환경을 가지는지
  • 돈으로 살 수 있는 최고의 도구 사용 여부
  • 테스터 보유 여부
  • 신규 후보자가 인터뷰 중 코드 작성 여부
  • 복도 사용성 테스트 수행 여부
• 핵심 메시지
  • 일부 질문은 시대에 뒤떨어졌지만, 질문 자체가 아니라 질문의 메타 포인트가 중요
  • Joel이 실제로 묻는 것: 개발자를 존중하는가?
  • 모든 질문은 고용주가 저렴한 사무 공간과 단기 마감일보다 개발자의 시간과 집중을 우선시하는지 평가
  • 닷컴 붐 정점에 게시되었으며, 숙련된 개발자가 귀중한 자원이었지만 모두가 이를 깨닫지는 못한 시기
  • Joel의 블로그는 항상 프로그래머를 희귀하고 섬세한 천재로 제시하여 고용주가 추구하고 아껴야 할 대상으로 묘사
  • 필자는 경력 내내 Joel Test에서 높은 점수를 받는 고용주를 찾았으며, 그 지도를 제공한 Joel에게 감사

Alexis King의 "Parse, don't validate" (2019)

• Haskell의 타입 시스템 활용에 관한 에세이이지만, 타입 시스템이나 Haskell에 관심이 없어도 소프트웨어 사고방식을 근본적으로 변화시킴
• Go, C++, Rust 등 정적 타입을 지원하는 모든 언어에서 Alexis의 기법 사용 가능
• 핵심 개념
  • 데이터를 검증할 때마다 새로운 타입으로 변환해야 함
  • 예시: 사용자 이름을 최대 20자 영숫자로 제한하는 규칙이 있을 때, 순진한 솔루션은 validateUsername(username string) error 함수
• 문제점
  • 코드가 기본적으로 안전하지 않음
  • 수신한 모든 사용자 이름을 검증해야 하므로, 실수로 검증 없이 사용자 이름을 처리하는 코드 경로 생성 쉬움
  • 악의적 사용자가 실수를 발견하면 사용자 이름 필드에 악성 코드 삽입하거나 수십억 문자로 채워 서버 리소스 고갈 가능
• Alexis의 솔루션
  • parseUsername(raw string) (Username, error) 함수 사용
  • 코드베이스의 나머지 부분에서 "username"이라는 string 대신 커스텀 타입 Username 사용
  • Username을 생성할 수 있는 유일한 함수는 parseUsername이며, 이는 Username 인스턴스를 반환하기 전에 검증 규칙 적용
  • Username 인스턴스가 있으면 유효한 사용자 이름을 포함해야 함
  • 신뢰할 수 없는 입력은 항상 string이므로, Username을 예상하는 함수에 string 전달 불가능
• 영향
  • 이 에세이 이전에는 타입 시스템이 언어 너드를 산만하게 하는 재미있는 방법이라고 생각
  • "Parse, don't validate"는 컴파일러 기능이 애플리케이션의 보안과 신뢰성 향상에 얼마나 가치 있는지 눈을 뜨게 함

Fred Brooks의 "No Silver Bullet" (1986)

• 대학에서 Fred Brooks의 The Mythical Man-Month 읽음
• IBM의 OS/360 프로젝트 지휘 경험을 바탕으로 한 소프트웨어 엔지니어링 에세이 모음집
• 본질적 복잡성과 우발적 복잡성
  • 본질적 복잡성: 도구와 하드웨어에 관계없이 반드시 수행해야 하는 작업
    • 예: 영업 사원 보너스 계산 소프트웨어에서 보너스 공식 정의 및 모든 엣지 케이스 커버
    • $5B 슈퍼컴퓨터든 $1 마이크로컨트롤러든 동일한 작업
  • 우발적 복잡성: 그 외 모든 것
    • 메모리 누수 처리, 코드 컴파일 대기, 제3자 라이브러리 사용 방법 파악
    • 도구와 하드웨어 리소스가 좋을수록 우발적 복잡성에 소비하는 시간 감소
• Brooks의 결론
  • 도구나 하드웨어의 발전이 개발자 생산성에 10배 향상을 만들어내는 것은 불가능
  • 모든 우발적 활동을 제로 시간으로 줄여도 전체 노력의 9/10 이상이 아니면 규모 향상 불가능
• 적용 사례
  • 경력 내내 사람들이 소프트웨어에서 프로그래머를 제거하려고 시도
  • 노코드 플랫폼이 비프로그래머에게 숙련된 웹 개발자의 모든 권한을 약속하며 화제 생성
  • Brooks의 에세이는 최신 버즈워드 플랫폼이 개발자를 대체할 수 없다고 항상 안심시킴
  • 플랫폼은 우발적 복잡성에 집중하며, 본질적 복잡성에는 집중하지 않음
  • 플랫폼이 기능 사양에서 마법처럼 작동하는 코드를 만들 수 있어도, 여전히 사양을 작성할 누군가가 필요
• AI의 영향
  • 현대 AI는 Brooks의 이론에 렌치를 던짐
  • AI는 실제로 본질적 복잡성을 줄임
  • 불완전하거나 모순된 사양을 AI에 전달하면, AI가 유사한 사양에서 차용하여 공백 채움
  • AI가 알려진 프로그래밍을 제거하더라도, Brooks의 에세이는 결국 어떤 추상화 수준에서든 본질적 복잡성을 관리할 사람이 여전히 필요하다는 희망 제공

Joel Spolsky의 "Choices" (2000)

• 좋아하는 Joel Spolsky 에세이를 하나만 선택하기 어려워 두 개 선택
• "Choices"는 사용자 인터페이스 생성과 사용자에게 권한을 부여하는 미묘한 비용에 관한 것
• 핵심 메시지
  • 옵션을 제공할 때마다 사용자에게 결정을 요청하는 것
  • 사용자가 무언가에 대해 생각하고 결정해야 함을 의미
  • 반드시 나쁜 것은 아니지만, 일반적으로 사람들이 내려야 하는 결정의 수를 최소화하려고 노력해야 함
• Windows 98 예시
  • Joel은 Windows 98에서 도움말 문서 검색 시 나타나는 황당한 대화상자 공유
  • 대화상자가 Joel을 분노하게 만든 이유:
    • 사용자가 도움을 받으려고 할 때 중단
    • 데이터베이스 최적화에 대한 정보 없는 결정을 내리도록 요청
    • Windows가 결정을 회피하고 사용자에게 떠넘김
• 적용 범위
  • Joel의 에세이는 그래픽 사용자 인터페이스에 초점을 맞추지만, 필자는 명령줄이나 작성한 함수를 호출하는 다른 개발자를 포함하여 코드를 접할 수 있는 모든 곳에서 이를 고려
  • 사용자를 대신하여 유용한 결정을 내릴 수 있는지, 동시에 그들이 관심 있는 것에 대한 권한을 제공할 수 있는지
  • Joel의 에세이는 내가 직접 내릴 수 있는 결정을 사용자에게 떠넘기는 것을 무수히 막아줌

Raymond Chen의 "“Application compatibility layers are there for the customer, not for the program” (2010)

• Raymond Chen은 Microsoft Windows 팀에서 가장 오래 근무한 개발자 중 한 명
• 블로그에는 Windows 프로그래밍 역사에 대한 수천 개의 유익하고 재미있는 이야기가 있음
• 고객 요청 사례
  • Windows Vista 호환성 모드에 관한 고객 요청:
    • Windows XP 및 Windows Server 2003용으로 설계된 프로그램이 Windows Vista에서 어려움 겪음
    • Windows XP 호환성 모드로 설정하면 Vista에서 잘 작동
    • Vista에서 실행 시 자동으로 XP 호환성 모드로 실행되도록 설치 프로그램에 어떤 변경 필요한지 질문
• Raymond의 비유
  • "나는 일반적으로 애완동물 가게 앞 보도에 쓰레기를 버리고, 매일 아침 가게가 열리면 누군가 쓰레기를 쓸어 쓰레기통에 버립니다. 하지만 애완동물 가게는 일요일에 열지 않아서, 일요일에는 쓰레기가 그냥 거기 있습니다. 일요일에도 애완동물 가게를 열게 하려면 어떻게 해야 하나요?"
• 교훈
  • 비유가 너무 재미있어서 Raymond가 틀렸다는 것을 이제야 알아챔
  • 단일 릴리스 후 Windows가 앱을 깨뜨리지 않을 것으로 기대한 개발자의 죄를 조롱
  • 세부 사항에는 동의하지 않지만, Raymond의 글은 매우 재미있고 날카로워 결함을 넘어설 수 있음
  • 훌륭한 사용자 행동 영향 교훈:
    • 사용자가 당신을 돕는 무언가를 하도록 유도하려면, 사용자 관점에서 저항이 가장 적은 경로를 신중히 생각해야 함
    • 보도에 쓰레기를 버리는 것이 문제를 완전히 해결한다고 보여주면, 계속 그렇게 할 것

Erik Kuefler의 "Don’t Put Logic in Tests" (2014)

• 필자는 항상 단위 테스트를 좋아했고 테스트 코드에 큰 자부심을 가짐
• 이 에세이가 화장실에 나타나 경력 내내 끔찍한 테스트를 작성해왔음을 폭로해 충격
• 문제가 있는 테스트 예시
• @Test public void shouldNavigateToPhotosPage() { String baseUrl = "http://plus.google.com/";; Navigator nav = new Navigator(baseUrl); nav.goToPhotosPage(); assertEquals(baseUrl + "/u/0/photos", nav.getCurrentUrl()); }
• 발견한 문제점
  • 처음 에세이를 읽었을 때 "내가 단위 테스트를 작성하는 방식과 정확히 같다!"고 생각
  • http://plus.google.com/ 문자열을 두 곳에 중복하는 이유는? 프로덕션 코드처럼 단일 진실 소스 생성
  • 필자는 테스트에서 중복을 제거하기 위해 헬퍼 함수, 변수, 루프를 추가하는 것을 항상 했음
  • 문제는 이 접근 방식이 미묘한 버그를 가림: 실제로는 http://plus.google.com//u/0/photos를 assert(슬래시 두 개)
• 깨달음
  • Erik의 에세이는 테스트 코드를 프로덕션 코드처럼 취급하지 말아야 함을 보여줌
  • 두 가지는 완전히 다른 목표와 제약 조건을 가짐
  • 좋은 테스트 코드는 무엇보다도 명확해야 함
  • 테스트 코드에는 자체 테스트 코드가 없으므로, 정확성을 검증하는 유일한 방법은 검사
  • 테스트는 어떤 동작을 assert하는지 독자에게 눈이 멀 정도로 명백해야 함
  • 이 목표를 위해 복잡성을 줄이기 위해 중복 허용 가능

Julia Evans의 “A little bit of plain Javascript can do a lot” (2020)

• 소프트웨어 엔지니어로서 웹에 당혹스럽게도 늦게 입문
• 경력 첫 10년간 데스크톱 앱과 백엔드 서버용 코드만 작성
• 2017년까지 HTML이나 JavaScript를 신경 쓰지 않음
• 프레임워크에 대한 오해
  • 프론트엔드 개발 학습을 진지하게 시작했을 때, JavaScript는 10일 만에 만들어진 엉망인 언어이며 브라우저마다 동작이 크게 다르다는 인상
  • 웹 앱을 작성하려면 JavaScript의 모든 담즙과 결점으로부터 보호해주는 현대적이고 세련된 무언가가 필요
  • Angular, React, Vue 같은 인기 있는 웹 프레임워크 시도
  • Vue를 충분히 학습했지만 여전히 의존성 문제와 프레임워크 함정에 엄청난 시간 소비
  • 이 모든 프론트엔드 프레임워크가 JavaScript를 수정하기 위해 한 작업 후에도 웹 프로그래밍은 여전히 형편없었음
• Julia의 에세이가 준 깨달음
  • JavaScript가 수정이 필요하다고 너무 확신한 나머지 기회를 주지 않았음을 깨달음
  • TinyPilot 프로토타입 작업 중이었고, Vue로 웹 인터페이스를 구현할 계획
  • Julia의 에세이가 순수 JavaScript로 얼마나 갈 수 있는지 보도록 영감을 줌
  • 프레임워크, 래퍼 라이브러리, 빌드 스텝, Node.js 없이, 그냥 일반 JavaScript(ES2018)만 사용
  • 프레임워크나 빌더로 전환해야 할 문제에 부딪힐 것으로 계속 예상했지만 결코 일어나지 않음
  • WebComponents 관련 몇 가지 함정은 있었지만, Vue와 Angular로 겪은 고통에 비하면 아무것도 아님
• 프레임워크 없는 자유
  • 프레임워크에서 자유로워지는 것을 좋아함
  • 런타임 오류가 있을 때, 스택 트레이스가 축소되고 변형되고 트리 쉐이크된 코드의 열악한 꿈이 아님
  • 작성한 대로 내 코드를 디버깅하는 것
  • JavaScript에 대한 편견이 틀렸음
  • 현대 JavaScript는 꽤 좋으며, 래퍼 라이브러리의 많은 아이디어를 흡수하여 이제 래퍼가 필요 없음
  • 브라우저들이 플랫폼과 디바이스 간 일관된 동작을 보장하기 위해 정신을 차림
  • 2020년 이후 어떤 새 프로젝트에도 JavaScript 프레임워크나 빌드 스텝을 통합하지 않았으며 뒤돌아보지 않음
  • 순수 JavaScript로 프레임워크 이점의 90%를 5%의 골칫거리로 얻음

Dan McKinley의 “Choose Boring Technology” (2015)

• 이 목록에 포함하기 이상한 에세이인 이유는 실제로 읽어본 적이 없기 때문
• 사람들이 이 에세이를 인용했고, 아이디어를 이해하자 너무 직관적이어서 읽을 필요를 느끼지 못함
• 핵심 아이디어
  • 새 프로젝트를 시작할 때 화제가 많은 최첨단 기술을 사용하고 싶은 유혹
  • Google이 엑사바이트까지 확장되는 새 데이터베이스를 발표했고, Postgres보다 40% 빠르고 비용은 20%
  • 이 섹시한 새 대안이 바로 거기 있을 때 Postgres를 사용하면 바보
  • 실제로 새 기술에는 버그와 약점이 있지만, 아직 명백하지 않음
  • 이에 부딪히면 막막함
  • Postgres는 문제가 있지만, 30년의 현장 경험 후 직면할 가능성이 있는 모든 문제에 대한 검증된 솔루션 보유
• 혁신 토큰 개념
  • Dan은 가끔 새 기술을 사용해야 한다고 인정하지만 전략적으로 그리고 제한된 수량으로만
  • 모든 비즈니스는 소비할 세 개의 "혁신 토큰" 을 얻음
  • 화려한 새 데이터베이스를 원하면 토큰 중 하나를 소비해야 함
  • Dan의 에세이는 Julia의 에세이와 자연스럽게 맞물림
  • 프론트엔드 프레임워크로 그 모든 시간을 낭비하기 전에 둘 중 하나라도 읽었으면 좋았을 것

Terence Eden의 “I’ve locked myself out of my digital life” (2022)

• Terence Eden은 유쾌하고 절충적인 기술 블로거
• 매주 여러 새 글을 쓰지만, 가장 큰 영향을 준 것은 "디지털 생활에서 나 자신을 잠갔다"
• 재난 시나리오
  • 번개가 Terence의 집을 치고 모든 소유물을 파괴하면 어떻게 될지 시뮬레이션
  • 비밀번호 관리자에 모든 것에 대한 비밀번호 보관
  • 모든 디바이스가 파괴되면 비밀번호 관리자에 액세스 불가능
  • 하드웨어 패스키로 대체할 수 없는 이유는 그것들도 집에 있었기 때문
• 깨달음
  • 필자는 중복 드라이브에 모든 것을 저장하고 두 벤더로 세 대륙에 오프사이트 백업을 가지고 있어 데이터에 대해 꽤 안전하다고 느낌
  • Terence의 글은 모든 디바이스를 동시에 없앨 수 있는 많은 신뢰할 수 있는 위협에 대해 생각하게 함: 화재, 홍수, 전기 서지, 범죄 수사
  • 모든 데이터는 머릿속에 있는 비밀번호로 암호화되어 있으므로, 기억 상실, 무능력, 사망도 목록에 추가
• 온라인 서비스의 문제
  • 온라인 서비스는 사용자가 재난에서 복구하는 데 도움을 주는 데 취약
  • 전화를 잃는 것이 불가능하다고 가정하는 여러 서비스 사용, 이메일 계정과 소유한 모든 디지털 디바이스는 말할 것도 없이
• 영향
  • Terence의 에세이를 읽은 이후 어떤 서비스와 디바이스가 중요한지, Terence가 설명한 시나리오에서 어떻게 복구할 수 있는지 더 많이 고려
  • 다음 노트북을 구입했을 때 도서관에서 설정하여 집에 있는 디바이스 없이 비밀번호 관리자와 중요한 계정에 대한 액세스를 복구할 수 있는지 테스트
  • 여전히 디지털 재난 대비를 더 잘할 수 있지만, Terence의 글은 디바이스와 데이터 보안 방법을 생각할 때마다 머릿속에서 울림
  • 모든 것이 갑자기 파괴되면 어떻게 될까?

보너스: Brad Fitzpatrick의 "parsing user input" (2009)

• 기술적으로 에세이는 아니지만, 소프트웨어 인터뷰의 인용문을 지속적으로 생각
• 2009년 Joel Spolsky의 극찬 리뷰 결과로 Coders at Work 읽음
• 성공한 프로그래머들과의 인터뷰 모음집
• Brad Fitzpatrick의 명언
  • LiveJournal과 Memcached 창시자 Brad Fitzpatrick이 인터뷰이 중 한 명으로 등장
  • 당시 28세로 책에서 가장 어린 프로그래머이자 가장 욕이 많고 재미있는 사람
  • 소프트웨어 엔지니어링 윤리에 대한 질문에 입력 검증에 대한 열정적인 발언:
    • "모두가 신용카드 양식에서 공백이나 하이픈을 입력할 수 있게 일관되게 해주기를 요청하고 싶습니다. 컴퓨터는 그런 것들을 제거하는 데 능숙합니다. 내 숫자를 어떻게 포맷할지 말하지 마세요."
• 적용
  • 웹 양식에 전화번호를 붙여넣으려고 할 때마다 이 인용문을 떠올림
  • 괄호나 공백이 허용되지 않는다고 투덜거리거나, 더 나쁜 경우 괄호 때문에 전화번호를 잘라내고 괄호가 허용되지 않는다고 불평
  • 소프트웨어에서 입력 필드를 만들고 예상치 못한 문자에 대해 생각할 때마다 Brad Fitzpatrick이 "컴퓨터는 그런 것들을 제거하는 데 능숙합니다" 라고 말하는 것을 들음

[python] I'm Switching to Python and Actually Liking It  파이썬으로 전향중이고, 생각보다 꽤 마음에 들어요  

https://www.cesarsotovalero.net/blog/i-am-switching-to-python-and-actually-liking-it.html

• 최근 AI 개발의 트렌드로 인해 본격적으로 파이썬 학습 및 사용을 시작했고, 이제는 그 생태계에 큰 만족을 느끼고 있음
• Python은 과거보다 훨씬 빠르고 현대적인 언어로 발전했고, Cython을 통한 성능 향상 등 급격한 발전을 체감함
• uv, ruff, pytest, Pydantic 등 최신 개발 도구와 라이브러리를 본인의 워크플로우에 적극 도입하여 개발 생산성을 높이고 있음
• 프로덕션 환경과 Jupyter 노트북/스크립트 기반 개발 간의 차이를 줄이기 위한 프로젝트 구조 및 자동화 방안도 적용
• GitHub Actions, Docker 등을 활용해 CI/CD, 테스트, 인프라 관리를 효율적으로 구축함.

I’m Switching to Python and Actually Liking It 요약

왜 파이썬으로 전향했는가

• AI 중심의 개발 환경에서는 Python이 사실상의 표준 언어로 자리잡고 있음
• 과거에는 단순한 스크립트 작성에만 사용했지만, 최근에는 RAG, 에이전트, 생성형 AI 등의 “실전용 앱”을 만들기 위해 진지하게 사용하게 되었음
• 그 과정에서 Python 생태계가 과거에 비해 매우 진화했다는 사실을 체감하게 되었음

Python의 강점 3가지

1. 풍부한 라이브러리와 도구 생태계: 데이터 처리, 분석, 웹, AI에 특화
2. Cython 등으로 인한 성능 개선: 컴파일 기반 최적화 가능
3. 개선된 문법 가독성: __init__, __new__ 같은 레거시 문법은 감춰지고, 더 직관적인 문법 제공

주요 도구 및 설정

• uv
  • Astral에서 제공하는 최신 파이썬 패키지 매니저 및 빌드 도구
  • 의존성 관리, 가상환경 생성, 프로젝트 초기화 등 대부분의 작업을 빠르게 처리함
  • pyproject.toml이 핵심 설정 파일로, 모든 메타데이터 및 의존성 정보가 통합됨
  • uv init, uv add, uv sync 명령어로 빠르게 프로젝트 환경 구성 가능
• ruff
  • 초고속 파이썬 린터 및 코드 포매터
  • isort, flake8, autoflake 등을 통합한 도구
  • ruff check, ruff format 으로 린팅 및 자동 수정
  • PEP 8 코딩 스타일 가이드 기본 지원
• ty
  • Astral이 만든 Python용 정적 타입 검사기
  • typing과 조합해 정적 분석, 초기 버그 방지에 효과적
  • 초기 개발 단계임에도 안정적으로 사용할 만한 수준임
• pytest
  • 단위테스트 및 확장 가능한 테스트 환경을 제공하는 대표적인 파이썬 테스트 프레임워크
  • 간단한 파일 네이밍 규칙과 명령어 한 줄로 바로 통합 테스트 가능함
    • test_*.py로 테스트 구성 후 uv run pytest로 실행
  • 간결한 문법, 풍부한 플러그인 생태계
• Pydantic
  • 데이터 검증 및 환경 설정 관리 라이브러리
  • .env 환경변수 기반 설정 로딩 및 타입 검증
  • BaseSettings 클래스를 통해 API 키나 DB URL 등을 안전하게 관리
• MkDocs
  • 파이썬 프로젝트의 정적 웹사이트 및 문서 생성을 간편하게 지원
  • 오픈소스 프로젝트 스타일의 미려한 디자인 빠른 적용 가능
  • GitHub Pages 연동도 용이
• FastAPI
  • 빠른 RESTful API 구축 프레임워크
  • 자동 검증 및 문서화, 빠른 성능, 쉬운 Pydantic 통합 장점
  • Starlette 및 Pydantic 기반으로 높은 타입 안정성과 성능 제공
• Dataclasses
  • 파이썬 표준 기능으로 데이터 중심 클래스를 간편하게 정의할 수 있음
  • 특별 메소드 자동 생성으로 보일러플레이트 코드 대폭 감소

버전 관리 및 자동화

• GitHub Actions
  • project-api와 project-ui 각각에 대해 별도 CI 파이프라인 구성
  • 다양한 OS에서 CI 파이프라인 구축에 최적화된 워크플로우 제공
  • 도커 기반 테스트 환경으로 프로덕션과 동일한 환경에서 테스트 시행 가능
• Dependabot
  • 자동 의존성 최신화 및 보안 패치 관리를 자동화함
• Gitleaks
  • 민감 정보(비밀번호, API 키 등) 유출 방지 도구로 git 커밋 전에 보안 검사를 수행함
• Pre-commit Hooks
  • 커밋 전 자동 린팅, 포매팅, 보안 검사를 위한 도구임
  • ruff, gitleaks 등과 함께 사용해 코드 일관성과 품질 유지

인프라 자동화

• Make
  • make test, make infrastructure-up 등의 명령어로 일관된 개발 워크플로우 지원
  • 프로젝트 루트와 project-api에 각각 Makefile 존재
• Docker & Docker Compose
  • project-api, project-ui 각각을 컨테이너로 분리 실행
  • docker compose up --build -d 한 줄로 전체 앱 실행 가능
  • Dockerfile에는 uv 설치, FastAPI 앱 실행 명령어 포함

마무리

• 위와 같이 최신 파이썬 개발 환경에서는 효율적이고 견고한 프로덕션 워크플로우를 구성할 수 있음
• AI, 데이터, 웹 개발 등 다양한 영역에 걸쳐 파이썬 생태계의 성장과 도구 발전으로부터 많은 이점을 경험 가능
• 모노레포 구조, 자동화 도구, 린터 및 타입 검사기, 즉각적인 테스트 환경, 문서화, 인프라 오케스트레이션까지 하나의 통합된 개발 문화를 구현할 수 있음

https://news.hada.io/topic?id=22028&utm_source=weekly&utm_medium=email&utm_campaign=202529

https://blog.alexewerlof.com/p/when-a-team-is-too-big

• 전문가 중심의 대형 팀은 내부 의존성, 전달 오류, 병목, 책임 분산 등으로 인해 생산성과 협업 효율이 급격히 저하됨
• 일일 스탠드업 미팅에서 대부분의 내용이 불필요하거나 지루해지는 등, 팀 규모 증가와 전문화가 소통 단절과 무관심을 불러일으킴
• 기술별(프론트/백엔드) 분리, 임시 피처팀, 외부 컨설턴트 활용 등 여러 실험이 있었으나, 결국 범용적 역할(제너럴리스트)로 전환이 가장 실질적 효과를 냄
• Mob프로그래밍 등 집단 협업은 지식 공유와 자기주도성, 책임감, 동기 부여를 촉진하며, 단일 분야 고집보다 결과 중심의 협업과 성장에 유리함
• 단, 범용화의 부작용(전문성 저하, 번아웃 위험)도 존재하며, 지속적인 실험과 문화적 개선이 필수적임

팀이 너무 클 때의 문제

• 14명 규모의 대형 팀에서 시작된 문제: 스탠드업에서 대부분의 대화가 불필요하며, 업무 전달 누락과 비공식 작업 발생 빈번
• 비동기 스탠드업(Slack 등) 으로 전환해도 핵심적인 대화와 협업 기회가 사라지고 단순 보고서로 변질

다양한 분할/운영 실험

• 기술별(Task Force) 분리: 프론트엔드/백엔드로 나눴으나, 즉시 상호 의존성 문제와 추가 스탠드업 참여로 시간 증가
• 임시 피처팀: 특정 기능 구현에 따라 인력 임시 재배치, 유지보수/자원 관리 이슈 발생
• 외부 컨설턴트 투입: 이미 팀이 큰데도 비효율, 상위 경영진의 자원 활용 압박

최종적으로 효과적이었던 해법

• 스페셜리스트 대신 제너럴리스트(범용가) 모델 도입
  • 프론트엔드, 백엔드, QA, DevOps 등 역할 분리 없이 한 목표/제품을 중심으로 전체 스킬셋을 나눠 가짐
  • 지식 공유, 책임 분산 감소, 병목 해소, 더 빠른 전달/고품질 실현
  • Mob 프로그래밍 등 집단 협업으로 소통/자율성/소유권 강화

왜 제너럴리스트가 효과적이었나

• 공통 맥락과 목적: 새로운 분야라도 동일 제품/목표를 기준으로 학습 곡선 완화
• 한정된 필요: 특정 도구(CI/CD 등)만 익혀도 충분, 깊은 전문성보다 생산성·유지보수성을 중시
• 동기 부여 3요소(자율성, 숙련, 목적) 를 모두 충족, 팀의 주인의식과 성장 지원
• Egalitarian 문화: 평등한 접근권, 자율적 지식 습득, 권한과 책임 분산, 집단 학습
• 책임의 3요소(지식, 권한, 책임) 가 명확, 소유권 기반의 빠르고 높은 품질의 결과 도출

부작용 및 한계

• 전문가의 이탈: 범용화가 모든 사람에게 맞지 않음, 특정 인력의 번아웃·리소스 과열 발생
• 전문성의 깊이 부족: 다양한 스택을 얕게 다루는 만큼, 한 분야의 깊은 숙련은 저해될 수 있음

결론 및 교훈

• 일률적 해법은 없으며, 실험과 개선의 문화가 더 중요
• 스페셜리스트 모델의 단점(병목, 소통 단절, 페이크 워크, 맥락 단절)을 제너럴리스트와 집단 협업으로 해소 가능
• 궁극적으로는 목표, 인력, 예산, 제품 특성에 따라 최적화된 모델이 달라질 수 있음
• 핵심은 열린 실험, 피드백, 지속적 개선의 문화

AI(인공지능)는 광범위한
윤리적, 사회적 질문과 도전을 제기한다.
AI의 의사결정 과정의 투명성, 프라이버시 보호,
직업 시장에서의 변화, AI 시스템의 공정성과 편향 문제 등은
과거의 기술에서는 고려되지 않았던 새로운 차원의 고민을
가져온다. 과거 기술은 작동 원리와 결과가 상대적으로
예측 가능하고 이해하기 쉬웠다. 반면 AI, 특히 심층학습과
같은 고급 기술은 내부 작동 메커니즘이 복잡해 때때로
블랙박스로 여겨진다. 이는 AI 시스템의 결정과 행동을
예측하고 이해하는 것을 어렵게 만들며,
윤리적, 법적 책임의 문제를
복잡하게 한다.


- 변형균의 《통찰하는 기계 질문하는 리더》 중에서 -


* AI 기술은
빛의 속도로 진화하고 있습니다.
챗GPT를 이용해 본 사람은 무섭게 실감합니다.
어마어마한 자본, 기술, 두뇌가 요구되는 사안입니다.
그런 점에서 우리나라는 분명 한계가 있습니다. 하지만
그 한계를 넘어설 수 있는 것이 콘텐츠입니다. 특히
'AI 윤리' 부분은 세계를 선도할 수 있습니다.
'AI 윤리'가 장착된 '한국형 챗GPT'도
개발할 수 있습니다.

https://zarar.dev/good-software-development-habits/

• 
  이 글은 조언이 아닌, 저자가 현재 적용하고 있는 개발 습관들에 대해 작성한 내용
• 나쁜 습관을 피하고 좋은 습관을 만들기 위해 노력한 경험을 정리한 글로, 생산성 향상과 품질 유지에 도움이 되었던 10가지 습관을 다룸

1. 작은 커밋 유지

• 커밋을 최대한 작게 유지해야 함. 작은 커밋은 버그 발생 시 특정 커밋만 되돌릴 수 있게 하여, 복잡한 병합 충돌을 피할 수 있음
• "소프트웨어가 컴파일될 때 커밋할 수 있어야 한다"는 것을 규칙으로 삼음

2. 지속적인 리팩토링

• Kent Beck의 조언: "변화를 원할 때, 먼저 변화를 쉽게 만들고, 그런 다음 쉽게 변화를 만드세요."
• 최소 절반의 커밋은 리팩토링이 포함되도록 함. 작은 리팩토링이 큰 요구사항이 들어올 때 큰 도움이 됨
• 큰 리팩토링은 피해야 함. 대신 10분 이내의 작은 개선 작업을 지속적으로 수행

3. 코드 배포의 중요성

• 코드 자체는 잠재적 부채이며, 배포되지 않은 코드는 가장 큰 부채임
• 테스트는 신뢰감을 주지만, 실제 배포는 진정한 승인을 의미함
• 배포 빈도가 높아질수록 호스팅 비용이 증가할 수 있지만, 최신 작업이 실제로 작동함을 확인하는 것은 중요한 이점임

4. 프레임워크의 기능 테스트하지 않기

• 프레임워크의 기능을 테스트하지 않음. 프레임워크는 이미 충분히 검증되어 있음
• 컴포넌트를 작게 유지하면 프레임워크가 대부분의 작업을 처리하게 되어 테스트가 줄어듦
• 큰 컴포넌트는 복잡성을 추가하고, 이에 따라 많은 테스트가 필요해짐

5. 새로운 모듈 생성

• 특정 기능이 기존 모듈에 맞지 않는다면, 새 모듈을 생성하는 것이 좋음
• 기존 모듈에 억지로 기능을 추가하는 것보다 독립적인 모듈로 남겨두는 것이 나음

6. 테스트 주도 개발(TDD)의 유연한 적용

• API 설계가 명확하지 않을 경우 테스트를 먼저 작성하여 "고객"의 입장에서 생각함
• TDD는 종교적인 원칙으로 따르지 않음. 필요한 경우 더 큰 단위로 작업 후 테스트할 수 있음
• 작은 단위의 코드를 실패 상태로 만들지 않아도 되며, 생산성을 저해하는 교조주의에 얽매이지 않음

7. 복붙은 한 번만 허용

• 한 번의 복사는 괜찮지만, 두 번째 복사부터는 중복이 생김
• 이 시점에서 적절한 추상화를 통해 중복을 제거해야 함. 파라미터화가 약간 이상해 보여도, 여러 구현을 합치는 것보다는 나음

8. 디자인의 변화 수용

• 디자인은 시간이 지나면서 낡아짐. 리팩토링을 통해 노화를 늦출 수 있지만 결국에는 바뀔 수밖에 없음
• 이전의 디자인을 너무 집착하지 말고, 변화를 받아들여야 함
• 완벽한 디자인은 없으며, 변화에 잘 대처하는 능력이 소프트웨어 개발의 핵심임

9. 기술 부채의 세 가지 유형

• 기술 부채는 세 가지 유형으로 분류할 수 있음:
  1. 현재 작업을 방해하는 것
  2. 미래 작업을 방해할 가능성이 있는 것
  3. 방해할 가능성이 있을지도 모르는 것
• 첫 번째 유형의 부채는 최소화하고, 두 번째 유형에 집중하며, 세 번째 유형은 무시해야 함

10. 테스트 가능성과 좋은 설계의 관계

• 테스트하기 어렵다면 설계에 문제가 있을 가능성이 높음
• 테스트 설계 또한 개선의 대상이 될 수 있음. 예를 들어, em.getRepository(User).findOneOrFail({id})의 목(Mock) 작성을 어렵게 느낀다면, 별도의 함수로 분리하거나 테스트 유틸리티를 사용하는 것이 좋음
• 테스트가 작성되지 않는 이유는 테스트하기 어렵기 때문이며, 이는 설계의 문제일 수 있음

https://www.itworld.co.kr/numbers/82001/338846

아태지역 AI 시장에서 생성형 AI의 비중이 더 커질 것이라는 전망이 나왔다. 중국이 앞서가는 가운데 일본과 인도 시장이 빠르게 성장하리라는 분석이다.

30일 시장조사업체 한국IDC가 ‘전 세계 AI 및 생성형 AI 지출 가이드’ 보고서를 발표했다. 중국과 일본을 포함한 아시아 태평양 지역의 AI 시장을 조사했다. AI 기반 시스템을 위한 소프트웨어, 서비스, 하드웨어를 포함한다. 보고서에 따르면, 아태 지역 생성형 AI 지출은 연 평균 95.4% 성장해 2027년에는 260억 달러 규모가 될 전망이다. 생성형 AI의 비중은 더 커진다. 생성형 AI는 2024년 전체 AI 시장의 15%를 차지하지만, 2027년에는 29%까지 늘어날 것으로 업체는 예상했다.
 

IDC 아태지역에서 빅데이터 및 AI 리서치 헤드 디피카 기리는 "아시아 태평양 지역에서 생성형 AI의 도입이 급증하며 향후 2년 이내에 투자가 정점에 도달한 후 안정화 기간을 거칠 것으로 예상된다. 중국은 생성형 AI 기술 관련 지배 시장 위치를 유지할 것이며, 일본과 인도는 향후 몇 년 동안 가장 빠르게 성장하는 시장이 될 것이다"라고 말했다.

산업별로 보면, 금융, 소프트웨어 및 IT, 정부, 리테일, 내구재 등의 부문에서 성장이 두드러진다. 금융 서비스 산업의 AI 지출은 2027년까지 연평균 96.7%씩 성장해 43억 달러 규모를 형성할 전망이다. 사내 운영 효율성 개선, 반복 작업 자동화, 사기 탐지 및 복잡한 문서 작성과 같은 백오피스 프로세스 최적화에 생성형 AI를 주로 활용하는 추세라고 보고서는 분석했다.
 

소프트웨어 및 IT 산업은 마케팅, 데이터 분석, 소프트웨어 개발 등 다양한 분야에서 생성형 AI를 활용한다. 생성형 AI는 콘텐츠 제작을 간소화하여 마케팅 전략을 최적화하고 오디언스 참여를 극대화하며, 소프트웨어 개발 분야에서는 코딩 작업을 자동화하고 프로토타입을 생성해 개발자의 생산성과 효율성을 높이는 데 기여하는 것으로 나타났다.

정부 부문에서는 생성형 AI 기술 교육과 훈련을 발전시켜 새로운 일자리를 창출하고 기술 혁신 허브의 성장을 촉진하는 데 활용하고, 리테일 산업에서는 개인 맞춤화 경험 제공을 위해 AI 기술을 활용하는 것으로 보고서는 분석했다.