Lighthouse Dev

Python 3.10 추가 기능 - 괄호로 둘러싸인 Context Manager Python 3.10부터 아래와 같이 Context Manager사용 시 괄호 안에서 여러 줄을 사용하는 것이 가능해졌다. Python 3.10에 반영된 이유 아래 사진과 같이 Github Issue에서 귀도 반 로섬은 PEG-based parser가 도입(Python 3.9)된 이후인 3.10에서 해당 기능을 구현하는 것을 제안하다. Python 3.10은 20.5.18에 개발이 시작되서 21.10.4 final 버전이 배포된다. Python 3.9는 19.6.4에 개발이 시작되서 20.10.5에 final 버전이 배포된다. Parser변경 Migration 계획 3.9 alpha 6 버전에서 PEG 기반의 parser를 command-line flag와 환경 변수와 같이 포함한다. 이는 이전 Parser로 전환하는 것이 가능하다. 모든 Python API(ast.parse와 compile)은 설정된 flag와 환경변수를 사용할 것이고 deafult parser는 신규 PEG기반의 Parser로 지정된다. 3.10 이 배포될 때까지 이전 parser와 그와 관련된 코드들은 유지될 것이다. 이전 Parser가 제거될 때까지 PEG Parser를 요구하는 새로운 문법이 추가되지 않을 것이다. 3.10 에서 이전 Parser와 commnad-line flag, 환경변수, parser모듈 및 그와 관련된 코드는 삭제 될 것이다. Parser가 변경된 이유(LL(1) → PEG)? LL(1) Parser와 PEG Parser에 대해서 간략히 살펴보고, LL(1) Parser가 갖는 문제점을 통해서 CPython의 Parser가 LL(1) Parser에서 PEG Parser로 변경된 이유에 대해서 확인해본다. Parser의 종류 이름 LL(1) PEG 설명 Left to Right Left Most Derivation Tree

파이썬을 주로 사용하는 나는, Async라는 단어가 항상 낯설다. 하지만 트래픽이 늘어남에 따라, Async는 필연적으로 따라오며, DB에서도 적용하는 것이 좋다. Async Engine에 대해 알아보자. 오늘도 썸네일 만들어준 DALL-E 땡큐 ! 0. 동기 / 비동기에 대한 설명 동기(Sync): 작업이 순차적으로 실행. 앞선 작업이 끝나야 다음 작업 실행 가능. 비동기(Async): 작업이 독립적으로 실행. 대기 시간이 발생할 때 다른 작업을 처리할 수 있음. 해당 부분에서 말하는 “동기”는 블락킹 동기 이고, “비동기”는 논블락킹 비동기 이다. 동기와 비동기에 대한 개념은, 올해초 발표했던 내용을 참고하면 좋을 것 같다. 한마디로? 동기 - “순서대로” / “차근차근” / “순서에 연연” 비동기 - “각개전투” / “뒤죽박죽” 0-1. 조금 더

팀원들과 대화를 하는 도중에, "DB에 데이터가 Commit 되기 전에, 해당 데이터를 가지고 비즈니스 로직을 돌리고 싶다 !" 라는 주제가 툭 튀어 나왔다. 여러 의견이 나왔지만, Flush 키워드로 대화가 흘러갔고, 팀원 대부분이 잘 쓰지 않기 때문에 (아마도 데이터의 무결성 때문이겠지 ..? 나는 그렇다 😀 ) 기본적인 내용이라 얕게는 알지만, 딥하게 알지는 못해보였다. 그래서 아주 아주 아주~ 간략하게 Flush가 뭔지에 대해서 알아보았다. 김원준 김원준2만 존재하는 데이터 베이스에, 아래 코드와 같이 “새로운 원준”의 User객체를 Session1에 add & Flush하였다면 결과는?? 아래의 코드로 동작시켜 보았다. add & flush를 한 session1에는 새로운 원준 이 적재되어있고, 동시에 오픈되어있던 session2에는 새로운 원준이 없다. 아하 ! Flush는, Commit되지 않은 데이터라면 Flush가 이뤄진 Session 안에서만 보여지는구나 !! 하지만, Flush의 격리수준을 "READ UNCOMMITTED" 로 설정한다면? add & flush하지 않은 session2에도 “새로운 원준”이 적재되어 있는걸 확인할 수 있다.

안녕하세요, 오늘은 TDD(Test-Driven Development)에 대해 이야기하려 합니다. TDD 소프트웨어 개발 방법론 중 하나로, 개발 과정에서 테스트를 우선하여 작성하고 이를 통과시키는 것에 초점을 두는 방법론입니다. 코드를 작성하기 이전에 테스트 케이스를 작성하고, 이를 통과하기 위한 그에 맞는 기능을 작성하는 작업을 반복하여 개발합니다. TDD의 장점과 한계 TDD의 장점: 품질 향상: 개발자는 코드의 동작을 확실히 이해하고 테스트 케이스를 통해 코드의 정확성을 검증할 수 있어, 더 견고하고 안정적인 코드를 작성할 수 있습니다. 리팩토링 지원: 코드를 작은 단위로 분리하고 테스트 가능한 형태로 작성하여 코드의 구조와 설계를 개선하기 쉽게 합니다. 빠른 피드백: 작은 단위의 테스트를 빠르게 실행하고 결과를 확인하여 버그를 빠르게 발견하고 수정할 수 있으며, 코드 변경에 대한 피드백을 신속하게 받을 수 있습니다. 협업 강화: 테스트 코드가 개발 프로세스의 일부로 문서화되어 있어 다른 개발자들과의 협업을 용이하게 하며, 코드의 동작을 이해하고 검증하는 데 도움이 됩니다. TDD의 한계: 시간과 노력: 테스트 코드를 작성하기 위해 추가적인 시간과 노력이 필요하며, 개발 시간이 늘어날 수 있습니다. 설계에 대한 이해: 테스트 케이스를 작성하기 위해 개발자는 코드의 설계에 대한 깊은 이해가 필요하며, 이를 갖추지 않으면 테스트 케이스가 미흡해질 수 있습니다. 복잡한 시나리오의 테스트: 복잡한 시나리오나 UI, 성능 테스트 등은 TDD로 테스트하기 어려울 수 있습니다. 변동이 많은 요구사항: 요구사항이 자주 변경되는 경우, 테스트 케이스를 계속 수정해야 하는 상황이 발생할 수 있습니다. 출처: https://semaphoreci.com/wp-content/uploads/2022/02/tdd-vs-waterfall.webp 이러한 장점과 한계로 인해 TDD는 초기에는 추가 비용이 들 수 있지만, 시간이 지남에 따라 비용을 절감할 수 있는 특징을 지녔습니다. TDD의 사이클 Lifecycle of the Test-Driven Development method 출처: https://ko.wikipedia.org/wiki/테스트_주도_개발 Write Test: 기능을 검증할 테스트 케이스를 작성 Test Fails: 작성한 테스트 케이스를 실행하여 실패하는 것을 확인

안녕하세요, 여러분! 오늘은 개발자와 IT 전문가에게 필수적인 두 가지 도구인 모바엑스텀(MobaXterm)과 소나큐브(SonarQube)에 대해 깊이 있게 다뤄보려 합니다. 이 두 도구는 각각의 강력한 기능을 통해 개발 및 코드 품질 관리에 큰 도움을 줍니다. 이제 각 도구의 사용법과 장점을 자세히 살펴보겠습니다. 모바엑스텀(MobaXterm) 모바엑스텀은 원격 컴퓨팅을 위한 올인원 솔루션으로, SSH, RDP, VNC 등 다양한 프로토콜을 지원합니다. 또한, X 서버와 탭 기반 터미널을 제공하여 여러 세션을 효율적으로 관리할 수 있습니다. 모바엑스텀의 주요 기능 다양한 프로토콜 지원: SSH, RDP, VNC, FTP, SFTP 등 다양한 프로토콜을 지원하여 원격 서버와의 연결이 매우 용이합니다. 탭 기반 터미널: 여러 터미널 세션을 하나의 창에서 관리할 수 있어 작업 효율이 높아집니다. X 서버 내장: 리눅스 GUI 애플리케이션을 윈도우 환경에서 실행할 수 있습니다. 플러그인 지원: 다양한 플러그인을 통해 기능을 확장할 수 있습니다. 파일 전송: 드래그 앤 드롭으로 파일을 쉽게 전송할 수 있습니다. 모바엑스텀 사용법 설치: MobaXterm 공식 웹사이트에서 최신 버전을 다운로드하고 설치합니다. 세션 생성: 프로그램을 실행하고 'Session' 버튼을 클릭합니다. 원하는 프로토콜(예: SSH)을 선택하고 연결할 서버 정보를 입력합니다. 탭 관리: 새로운 세션을 생성하면 탭이 추가됩니다. 여러 세션을 동시에 열어 작업할 수 있습니다. 파일 전송: 터미널 창에서 원격 서버와 로컬 시스템 간의 파일을 드래그 앤 드롭으로 쉽게 전송할 수 있습니다. 플러그인 설치: 필요에 따라 다양한 플러그인을 설치하여 기능을 확장할 수 있습니��. 소나큐브(SonarQube) 소나큐브는 코드 품질 관리 도구로, 코드의 버그, 취약점, 코드 스멜 등을 자동으로 분석하여 보고합니다. 이를 통해 코드의 품질을 향상시키고 유지보수를 용이하게 합니다. 소나큐브의 주요 기능 다양한 언어 지원: 자바, C#, 파이썬 등 다양한 프로그래밍 언어를 지원합니다. 자동 분석: 코드의 버그, 취약점, 코드 스멜 등을 자동으로 분석합니다. 품질 게이트: 코드 품질 기준을 설정하고, 이를 기준으로 빌드 통과 여부를 결정할 수 있습니다. 통합: Jenkins, Azure DevOps 등 다양한 CI/CD 도구와 통합할 수 있습니다. 대시보드: 코드 품질 상태를 시각적으로 확인할 수 있는 대시보드를 제공합니다.

Lighthouse에서 개발되는 모든 Product 모니터링 시스템을 갖춥니다. 모니터링이 필요한 부분은 잘 아시다 시피 시스템 영역 그리고 사용자 영역으로 구분될 수 있지요. 시스템 영역에서는 서버 상태, 데이터베이스 성능, 네트워크 트래픽, API 응답 시간 등을 실시간으로 모니터링하여 장애 발생 시 신속하게 대응할 수 있도록 합니다. 이를 통해 가용성, 신뢰성, 성능 등을 지속적으로 최적화하며, 문제 발생 시 그 원인을 빠르게 파악하고 해결할 수 있는 환경을 조성합니다. 또한 로그 분석 및 자동 알림 기능을 통해 예측 가능한 문제를 미리 식별하고 사전에 대응할 수 있도록 합니다. 사용자 영역에서는 사용자 행동 분석, 사용 패턴 추적, 인터페이스 반응 시간 등을 모니터링하여 사용자 경험(UX)을 극대화하는 데 중점을 둡니다. 이를 통해 사용자의 요구를 정확히 이해하고, 서비스 개선을 위한 데이터를 축적할 수 있습니다. 사용자의 피드백을 실시간으로 수집하고 분석하여, 즉각적인 조치와 더불어 장기적인 발전 계획에 반영합니다. 이와 같은 모니터링 시스템은 제품의 전체적인 품질 향상은 물론, 비즈니스 목표 달성에도 크게 기여할 것입니다. Kibana의 강력한 시각화 도구를 활용해, 이러한 데이터를 직관적이고 이해하기 쉬운 형태로 제공함으로써, 제품 개발 및 개선에 필요한 핵심 인사이트를 얻을 수 있습니다. 또한, 사용자 피드백을 자동으로 수집하고 분석하여, 제품에 대한 사용자의 반응을 실시간으로 파악하고 즉각적으로 대응할 수 있는 체계를 갖춥니다.

0. 들어가며 이번 시간에는, 파이썬의 데코레이터에 대해서 발표해보도록 하겠다. 1. Decorator 란? 파이썬을 사용하다보면, 함수 혹은 메서드 위에 “@” 골뱅이가 붙은 특이한 이름을 본 적이 있을 것이다. 이러한 특이한 문법을 decorator라고 하는데, 영어 사전에서 decorator는 “장식자”이라는 뜻을 가지고 있다. 파이썬의 decorator 역시 동일한 의미로 사용된다. 어떤 함수가 있을 때, 해당 함수를 직접 수정하지 않고, 함수에 기능을 추가 /변경 / 확장 하고자 할 때 decorator를 사용한다. decorator는 함수를 인자로 받고, 또 다른 함수를 반환하는 고차함수 이다. 고차함수 ? 함수를 인자로 받아서, 함수를 반환하는 함수 파이썬에서 함수는 일급 객체로 취급되기 때문에 가능하다. 일급객체 ? → 아래에서 살펴보자. 그렇다면, 도대체 어떤 기능 이길래 추가 /변경 / 확장 모두 가능한 것일까? 지금부터 알아보자. 1.1. 데코레이터 기본 예시

시작 하면서 최근 KRM ver2.0 프로젝트를 시작하면서 웹서버를 구현하기 위해 SQLAlchemy를 사용하면서 모델링을 했습니다. 작업을 하면서 SQLAlchemy에 대해 공부한 내용을 공유해 보겠습니다. SQLAlchemy? SQLAlchemy는 파이썬을 위한 SQL 툴킷 및 Object-Relational Mapping(ORM) 라이브러리로, 데이터베이스와의 상호작용을 보다 쉽고 직관적으로 할 수 있게 도와줍니다. SQLAlchemy는 데이터베이스 연결 관리, 트랜잭션 관리, 스키마 정의 및 관리 등 다양한 기능을 제공합니다. SQLAlchemy 구조 크게 Core와 ORM으로 나뉘어져 있습니다. Core (SQL Expression Language): SQLAlchemy의 Core는 SQL 표현 언어를 사용하여 데이터베이스 쿼리를 생성하고 실행하는 데 중점을 둡니다. SQLAlchemy Core는 SQL을 직접 작성하고 데이터베이스와 상호작용할 수 있는 저수준 인터페이스를 제공합니다. Engine 데이터베이스와의 연결을 관리하는 핵심 구성 요소입니다. Engine 객체는 데이터베이스와의 상호작용을 위한 연결 풀(Connection Pool) 및 데이터베이스 드라이버를 포함하여 SQLAlchemy의 다른 부분과의 통신을 조정 Engine의 주요 기능 데이터베이스 연결 설정: Engine은 데이터베이스 URL을 통해 데이터베이스 연결 정보를 설정합니다. 연결 풀 관리: Engine은 연결 풀을 관리하여 데이터베이스 연결의 효율성을 높이고 성능을 최적화합니다. 연결 풀은 데이터베이스 연결을 재사용하여 연결 생성 및 소멸에 따른 오버헤드를 줄입니다. 트랜잭션 관리:

안녕하세요! 오늘은 제가 Airflow를 사용하면서 겪었던 몇 가지 트러블슈팅 경험을 공유하고자 합니다. 제 경험이 여러분의 Airflow 작업에 도움이 되기를 바랍니다. 디렉토리 구조 제가 구성한 Airflow의 디렉토리 구조는 다음과 같습니다. 추가한 디렉토리에서 import 시 에러 발생 새로운 디렉토리인 config와 db에서 import하려고 시도했을 때 import 오류가 발생했습니다. 이는 프로젝트 경로를 path에 추가하여 해결했습니다. path를 추가하며 운영 환경과 개발 환경의 경로가 다르기 때문에 다른 문제가 발생했는데 이는 아래에서 다시 설명드리겠습니다. plugins와 dags/utils 처음에는 azure_conn과 slack_message 두 개의 스크립트를 plugins 디렉토리에 저장했습니다. 하지만 GCP Composer 서비스에서는 dags 폴더 하위에 폴더를 생성하도록 권장하기 때문에 코드 재사용성을 위해 두 스크립트를 dags/utils 디렉토리로 이동했습니다. plugins 디렉토리는 Airflow 시스템의 기본 기능 확장에 사용합니다. 출처: https://cloud.google.com/composer/docs/how-to/using/installing-python-dependencies?hl=ko#use_packages_that_depend_on_shared_object_libraries API 호출 에러 사례 스케줄러나 웹 UI를 통해 DAG를 실행할 때 Negsignal.SIGSEGV 오류가 발생하여 requests 호출이 중단되었습니다. 로컬에서 테스트 실행해 보니 문제 없이 동작했지만, 이 오류는 이미 GitHub 디스커션에 등록되어 있었습니다. 출처: https://github.com/apache/airflow/discussions/24463#discussioncomment-4404542 원인은 명확하게 밝혀지지 않았지만, macOS에서는 프록시 정보를 가져오는 시스템 호출이 특정 조건 하에서 예상치 못한 방식으로 작동하여 메모리 접근 오류인 SIGSEGV(세그먼테이션 폴트)를 발생시키는 것으로 추측됩니다. 해결방법은 dag에 아래의 코드를 추가해 프록시 설정을 초기화하였습니다. 실행 환경 차이로 인한 코드 불일치 위 에러들로 인해 실행 환경과 개발환경 간 코드가 불일치했습니다. 이를 해결하고자 config/airflow_config/config.json을 두어 실행 환경을 읽어 환경에 따라 같은 코드로 다르게 동작하도록 수정했습니다. Connections 등록 후 PW를 까먹은 경우

0. 들어가며 저번 시간에는 동시성. 즉, 제어권에 대한 Blocking/NonBolocking. 또 작업의 순서를 논하는 Sync/Async에 대해 간단하게 살펴보았다. 그렇다면 이번 시간에는 다음 순서로 파이썬의 GIL 및 스레드 환경에 대해 살펴보자. 0-1. 들어가기 앞서 ! 오늘 발표를 조금 더 잘 이해할 수 있도록 하기 위해, 몇가지 용어에 대한 설명을 준비하였다. 메모리란 ? 메모리는 컴퓨터가 프로그램과 데이터를 저장하고 처리하는 데 사용되는 저장 공간이다. 프로그램의 실행 중에 생성되는 데이터는 물리적인 메모리에 저장 되며(주로 RAM), 이 데이터는 스레드가 실행되면서 읽고 쓰게 된다. 프로세스란 ? 실행 중에 있는 프로그램을 의미한다. 작업(Task)과 같은 의미로 쓰인다. 프로세스는 최소 하나의 스레드를 가지는데, 실제로 작업(Task)이 스레드 단위로 동작한다. 스레드란 ? 스레드는 프로그램 내에서 실행되는 흐름의 단위. 일반적으로 한 프로그램은 하나의 스레드를 가지고 있지만, 프로그램의 환경에 따라 둘 이상의 스레드를 동시에 실행할 수 있다. 이것이 바로 멀티스레딩이다. 프로세스 구조 프로세스의 데이터와 명령어가 있는 영역은 Code(Text), Data, Stack, Heap이다. 💡각 프로세스는 별도의 공간(독립된 메모리)에서 실행되고 프로세스끼리는 자원의 공유를 하지 않는다. 그렇다보니, 프로세스 간의 자원을 공유하기 위해서는 별도의 통신이 필요하다. 스레드 구조 스레드는 Stack만 따로 할당받고, Code(Text), Data, Heap 영역은 프로세스의 자원을 공유한다. 💡자원을 공유하다보니, 시스템의 자원과 처리 비용이 멀티 프로세싱에 비해 적다. (통신의 부담X) 하지만 자원을 공유하고 있다 보니, 멀티 스레딩 환경에서 동기화의 문제가 발생할 수 있다.

0. 들어가기 앞서 지난 시간에는 파이썬의 GIL 제약과 그 제약으로 인해 “찐”효율을 내지 못하는 멀티 스레드 프로그래밍에 대해서 알아보았다. 이번 시간에는 파이썬 비동기의 핵심 키워드 네이티브 코루틴인 Asyncio, async, await를 이해하기 전 이것들의 근간이라 불리는 코루틴(Corutine)에 대해서 알아보자. 들어가기 앞서, 복습 차원에서 지난 시간 내용을 간략하게 정리하자 1. 제네레이터 1.1. 제네레이터 제네레이터는 쉽게 말해서, 여러개의 데이터를 미리 만들어 놓지 않고 필요한 때마다 즉석에서 하나씩 만들어낼 수 있는 객체를 의미한다. 일반적인 함수와 달리 상태를 유지할 수 있다. 즉, 제네레이터는 yield 표현식을 사용하여 값을 반환하고, 다음 호출 시 마지막으로 실행된 yield 표현식 이후부터 실행을 재개한다. 일반함수는 return을 만나면 실행이 끝나버린다. 하지만 제네레이터는 yield 구문에서 “일시정지”의 상태로 값을 외부로 내보낸다. 그 이후에 필요할 때 다시 실행 흐름을 이어나갈 수 있다. 함수 내부에서 사용된 지역 변수등이 메모리에 그대로 유지되어 있기 때문이다. 아래 코드를 살펴보자. 함수 return_abc()는, 알파벳을 1초마다 하나하나 리스트에 적재하는 코드이다. print를 찍어본다면 어떻게 될까? 너무 당연한 결과이다. 그렇다면 해당 함수를 for loop에 돌려보면 어떻게 될까? 이 결과 역시 너무나도 쉽게 예상할 수 있다. 여기서 3초라는 시간을 잘 기억해주길 바란다. 위에서 제네레이터는 데이터를 미리 만들어두지 않고, 필요할 때마다 하나씩 만들어내는 객체를 뜻한다 했다. 이것도 코드를 통해 알아보자. 뭔가 위의 코드랑 별로 달라진게 없어보인다. print를 찍어보자. !! 예상했던 것과는 달리 제네레이터가 출력 되었다 !! 위에서 언급했던 것처럼 제네레이터는 “필요할 때마다” “하나씩” 만들어 낸다고 했으니, 한번 for문을 통해서 “하나씩” 값을 받아와 보자.

이번 글에서는 python FastAPI의 특징과 FastAPI내에서 Pydantic을 사용한 코드를 확인해 보겠습니다. Fast API Fast API란? FastAPI는 Python 프레임워크 중 하나입니다. Python 프레임워크들 중 django, flask 와 같이 비교를 많이 하며, 빠른 속도로 인해 인기가 많아진 프레임워크입니다. FastAPI에서 제공하는 기능들을 간략히 보면 아래와 같습니다. API 문서 자동 생성 (Swagger와 ReDoc 스타일 동일) 의존성 주입 위주의 설계를 통한 DB 등에 대한 관리 편리 비동기 동작으로 빠른 성능 보장 (Starlette) Pydantic을 사용한 Validation 체크 뛰어난 공식문서 가이드 Python Framework 깃허브 스타 github star history 그래프를 보면 FastAPI(노란색)의 스타가 급격히 증가하는 것을 확인 할 수 있습니다. 그래프를 통해 FastAPI를 많이 사용한다는 의미는 될 수 없겠지만, 개발자들 사이에서 관심을 많이 갖고 있는것은 확인 할 수 있을것 같습니다. FastAPI의 특징 특징들을 Fast API 공식문서를 통해 자세하게 확인해 보겠습니다. 파이썬 3.8+ 버전의 Type hint를 사용하는 트랜디하고 높은 성능을 가진 파이썬 프레임워크 빠름: NodeJS 및 Go와 동등한 매우 높은 성능을 제공 실제 파이썬 기반의 프레임워크들을 비교한 내용을 확인해 보면 성능이 상위에 존재하는 것을 확인 할 수 있습니다. 빠른 코딩: 기능 개발 속도를 약 200%~300% 향상 버그 감소: 인간(개발자)이 유발한 오류의 약 40% 감소 직관적: 뛰어난 편집기 지원. 디버깅 시간이 줄어듭니다.

0. 개요 아무것도 모르는 대학생 시절에, 학부 인턴을한 적이 있다. 그때 팀장님이 신입 면접을 보고 오신 뒤, 나에게 질문을 하신 적이 있다. “oo아 동기와 비동기 차이를 설명해 봐” 동기 - “하나하나 순차적으로 실행하는 것 !” 비동기 - “동시에 실행되는 것 !” 이라고 대답한 기억이 있다. 아마 이렇게 대답한 나는 그 당시에 동기 / 비동기를 아래 사진과 같이 이해하고 있었던 것 같다. 내가 이해한 "동기" 내가 이해한 "비동기" 얼핏 보기엔 맞는 대답이기도 하다. 하지만 지금 와서 생각해 보면 “하나하나 순차적으로 실행하는 것 !”의 대답은, Blocking Sync에 대한 설명일 수도 있고, Blocking Async에 대한 설명일 수도 있다. 또, “동시에 실행되는 것 !” 의 대답은, NonBlocking Sync일 수도 있고 NonBlocking Async일 수도 있다. 물론, 이론적으론 그렇다. 해당 개념을 잘 모르는 사람에게는, Sync와 Async의 단어 자체는 익숙할 수 있어도, Blocking과 NonBlocking이 앞에 붙는 순간 머리가 아파올 수 있다.

개요 개발을 하면서 과거에 작업했던 코드를 다시 봐야 하는 상황이 종종 있다. 과거에 깨끗하지 않게 코드를 작성했다면, 코드를 다시 이해하고 원인을 찾는 부분에서 시간을 소요 할 가능성이 높다. 특히, 서비스 중인 프로그램에서 버그가 발생해 빠르게 이슈 대응을 해야 한다면, 머리가 새하얘질 것 이다. 또한, 이런 경험을 한 적이 있을 것이다. 시간이 부족해서 빠르게 개발하고, ‘아.. 나중에 리팩토링 해야겠다.’ 라고 생각한 경우도 있을 것이다. 하지만, 리팩토링을 하는 Task를 따로 추가하는 경우는 매우 희박한 경험들이 있을 것이다. 이런 경험을 하면서 개발 초기 부터 이해가 잘되는 코드를 만들기 위한 방법을 찾아 보게 되었고, 클린 코드에 대해 알게 되면서 학습을 진행했다. 클린 코드를 알기 전 개발에 급급해서 만들었던 과거의 코드 클린 코드란? 한 개발자는 클린 코드에 대해 다음과 같이 말했다. 그래디 부치(Grady Booch) ”클린 코드는 단순하고 직접적이다. 클린 코드는 잘 쓴 문장처럼 읽힌다. 클린 코드는 설계자의 의도를 숨기지 않는다. 오히려 명쾌한 추상화와 단순한 제어문으로 가득하다." 이 외에도 여러 개발자들의 말을 정리하면 다음과 같다. 다른 사람이 읽기 쉬운 코드 유지 보수가 쉬운 코드 간단 명료하고, 의도가 분명한 코드 클린 코드에 대해 많은 말들이 있지만 개인적으로 클린코드의 핵심은 라고 생각 된다. “누구에게나” 라고 생각한 이유는 프로젝트는 팀원들과 같이 진행을 하기 때문에 내가 작성한 코드를 팀원들이 읽기 때문이다.

아파치 프로젝트 아파치 프로젝트는 오픈 소스 소프트웨어 개발을 위한 비영리 조직입니다. 하둡은 아파치 프로젝트의 핵심 프로젝트 중 하나입니다. 아파치 프로젝트는 하둡의 개발, 유지 관리, 보급을 담당하고 있습니다. 아파치 프로젝트는 하둡의 안정성과 성능을 향상시키기 위해 지속적으로 노력하고 있습니다. 또한, 하둡의 사용을 지원하기 위한 다양한 도구와 리소스를 제공하고 있습니다. KHP(카카오하둡) KHP는 카카오가 자체 개발한 하둡 배포판입니다. KHP는 하둡의 최신 버전을 기반으로 개발되었으며, 카카오의 요구 사항에 맞게 최적화되어 있습니다. KHP는 다음과 같은 특징을 가지고 있습니다. 높은 확장성: KHP는 대규모 클러스터 환경에서의 안정적인 운영을 지원합니다. 높은 성능: KHP는 하둡의 성능을 향상시키기 위한 다양한 최적화 기술을 적용하고 있습니다. 쉽고 편리한 관리: KHP는 하둡의 관리를 단순화하기 위한 다양한 기능을 제공합니다. KHP는 카카오의 빅데이터 플랫폼의 기반으로 사용되고 있습니다. 또한, 카카오 외에도 다양한 기업과 기관에서 KHP를 사용하고 있습니다.

MapReduce는 대규모 데이터를 분산 환경에서 처리하기 위한 프로그래밍 모델입니다. MapReduce는 입력 데이터를 키-값 쌍으로 변환하는 Map 단계와, 동일한 키를 가진 데이터를 집계하는 Reduce 단계로 구성됩니다. MapReduce는 다음과 같은 특징을 가지고 있습니다. 병렬 처리: MapReduce는 입력 데이터를 여러 노드에 분산하여 처리합니다. 이를 통해 대규모 데이터를 효율적으로 처리할 수 있습니다. 간결한 프로그래밍: MapReduce는 단순한 프로그래밍 모델을 제공합니다. 이를 통해 개발자가 대규모 데이터를 쉽게 처리할 수 있습니다. 확장성: MapReduce는 확장성이 뛰어납니다. 이를 통해 대규모 데이터 처리 환경에 쉽게 적용할 수 있습니다. MapReduce의 구조 MapReduce는 다음과 같은 구조로 구성됩니다. JobTracker: JobTracker는 MapReduce 작업을 관리하는 서버입니다. JobTracker는 MapReduce 작업을 분배하고, 작업의 진행 상황을 추적합니다. TaskTracker: TaskTracker는 MapReduce 작업을 수행하는 서버입니다. TaskTracker는 JobTracker의 명령에 따라 MapReduce 작업을 수행합니다. MapReduce의 작동 방식 MapReduce는 다음과 같은 방식으로 작동합니다. 사용자는 MapReduce 작업을 생성합니다. JobTracker는 MapReduce 작업을 분배합니다. TaskTracker는 MapReduce 작업을 수행합니다. JobTracker는 작업의 진행 상황을 추적합니다. 사용자는 JobTracker를 통해 MapReduce 작업을 생성할 수 있습니다. JobTracker는 MapReduce 작업을 여러 TaskTracker에 분배합니다. TaskTracker는 JobTracker의 명령에 따라 MapReduce 작업을 수행합니다. JobTracker는 작업의 진행 상황을 추적합니다. MapReduce의 단계 MapReduce는 다음과 같은 두 단계로 구성됩니다. Map 단계: Map 단계는 입력 데이터를 키-값 쌍으로 변환합니다. Map 단계는 입력 데이터를 한 줄씩 읽어 키-값 쌍으로 변환합니다. Reduce 단계: Reduce 단계는 동일한 키를 가진 데이터를 집계합니다. Reduce 단계는 Map 단계의 출력을 키-값 쌍으로 받고, 동일한 키를 가진 데이터를 집계합니다. MapReduce는 다양한 분야에서 활용되고 있습니다. 예를 들어, 빅데이터 분석, 디지털 아카이빙, 미디어 스트리밍 등에서 MapReduce가 사용되고 있습니다. MapReduce의 장점 MapReduce는 다음과 같은 장점을 가지고 있습니다. 병렬 처리: MapReduce는 입력 데이터를 여러 노드에 분산하여 처리합니다. 이를 통해 대규모 데이터를 효율적으로 처리할 수 있습니다. 간결한 프로그래밍: MapReduce는 단순한 프로그래밍 모델을 제공합니다. 이를 통해 개발자가 대규모 데이터를 쉽게 처리할 수 있습니다. 확장성: MapReduce는 확장성이 뛰어납니다. 이를 통해 대규모 데이터 처리 환경에 쉽게 적용할 수 있습니다. MapReduce의 단점 MapReduce는 다음과 같은 단점을 가지고 있습니다. 복잡성: MapReduce는 복잡한 구조를 가지고 있습니다. 따라서 MapReduce를 사용하려면 충분한 이해가 필요합니다. 성능: MapReduce의 성능은 네트워크 대역폭에 따라 제한될 수 있습니다. MapReduce의 활용 사례 MapReduce는 다음과 같은 분야에서 활용되고 있습니다.

HDFS(Hadoop Distributed File System)는 하둡 에코시스템의 핵심 구성 요소 중 하나로, 대용량 데이터를 저장하고 관리하기 위한 분산 파일 시스템입니다. HDFS는 수백 대 또는 수천 개의 서버에 분산된 데이터를 저장하여 대규모 데이터 처리를 가능하게 합니다. HDFS는 다음과 같은 특징을 가지고 있습니다. 분산: HDFS는 데이터를 여러 서버에 분산하여 저장합니다. 이를 통해 대규모 데이터를 저장하고 관리할 수 있습니다. 내결함성: HDFS는 데이터의 손실을 방지하기 위해 내결함성을 갖추고 있습니다. 데이터는 여러 서버에 복제되어 저장되며, 서버 하나가 고장나더라도 데이터를 복구할 수 있습니다. 효율성: HDFS는 데이터를 효율적으로 저장하고 관리합니다. 데이터는 블록 단위로 저장되며, 블록의 크기는 64MB에서 128MB 사이로 조정할 수 있습니다. HDFS는 다음과 같은 용도로 사용될 수 있습니다. 대규모 데이터 저장: HDFS는 수백 TB 또는 수 PB 이상의 데이터를 저장할 수 있습니다. 대규모 데이터 분석: HDFS는 대규모 데이터를 분석하기 위한 플랫폼으로 사용될 수 있습니다. 디지털 아카이빙: HDFS는 디지털 아카이빙을 위한 플랫폼으로 사용될 수 있습니다. HDFS의 구조 HDFS는 다음과 같은 구조로 구성되어 있습니다. NameNode: NameNode는 HDFS의 메타데이터를 저장하는 서버입니다. 메타데이터에는 파일의 이름, 크기, 위치 등이 포함됩니다. DataNode: DataNode는 실제 데이터를 저장하는 서버입니다. DataNode는 NameNode의 명령에 따라 데이터를 저장하고 관리합니다. HDFS의 작동 방식 HDFS는 다음과 같은 방식으로 작동합니다. 사용자가 파일을 생성하면 NameNode는 파일의 메타데이터를 저장합니다. NameNode는 DataNode에 파일을 저장할 위치를 지시합니다. DataNode는 NameNode의 지시에 따라 파일을 저장합니다. 사용자는 NameNode를 통해 파일을 생성, 수정, 삭제할 수 있습니다. NameNode는 DataNode에 파일을 저장할 위치를 지시하며, DataNode는 NameNode의 지시에 따라 파일을 저장하고 관리합니다. HDFS의 장점 HDFS는 다음과 같은 장점을 가지고 있습니다. 대규모 데이터 저장: HDFS는 수백 TB 또는 수 PB 이상의 데이터를 저장할 수 있습니다. 내결함성: HDFS는 데이터의 손실을 방지하기 위해 내결함성을 갖추고 있습니다. 효율성: HDFS는 데이터를 효율적으로 저장하고 관리합니다. HDFS의 단점 HDFS는 다음과 같은 단점을 가지고 있습니다.

오늘은 대용량 데이터 처리를 위한 프레임워크인 Hadoop에 대해 간단히 소개해드리려고 합니다. Hadoop이란? Hadoop은 Apache Software Foundation에서 개발한 오픈소스 프레임워크로, 대용량 데이터 처리를 위한 분산 처리 시스템입니다. Hadoop은 MapReduce와 HDFS라는 두 가지 주요 기술을 기반으로 합니다. MapReduce는 대용량 데이터를 처리하기 위한 분산 처리 프레임워크입니다. MapReduce는 데이터를 작은 단위로 나누어 병렬 처리하는 방식으로 대용량 데이터를 효율적으로 처리할 수 있습니다. HDFS는 대용량 데이터를 저장하기 위한 분산 파일 시스템입니다. HDFS는 데이터를 여러 대의 서버에 분산 저장하여 대용량 데이터를 효율적으로 저장하고 관리할 수 있습니다. Hadoop의 특징 Hadoop의 주요 특징은 다음과 같습니다. 분산 처리: Hadoop은 대용량 데이터를 처리하기 위해 분산 처리 방식을 사용합니다. 확장성: Hadoop은 클러스터 규모를 쉽게 확장할 수 있습니다. 내구성: Hadoop은 데이터의 손실을 방지하기 위해 다양한 내구성 기능을 제공합니다. 오픈소스: Hadoop은 오픈소스 소프트웨어로, 누구나 무료로 사용할 수 있습니다. Hadoop의 적용 Hadoop은 다양한 분야에서 대용량 데이터 처리를 위해 사용되고 있습니다. Hadoop의 주요 적용 분야는 다음과 같습니다.

오늘은 디자인 패턴 중 하나인 Observer 패턴에 대해 간단히 소개해드리려고 합니다. Observer 패턴이란? Observer 패턴은 객체의 상태 변화를 관찰하는 객체들을 등록하고, 객체의 상태가 변경될 때마다 등록된 객체들에게 알림을 보내는 패턴입니다. 즉, 객체의 상태 변화를 관찰하고 싶은 객체들을 객체에 등록하고, 객체의 상태가 변경될 때마다 등록된 객체들에게 알림을 보내는 방식으로 객체의 상태 변화를 관리합니다. Observer 패턴의 장점 Observer 패턴을 사용하면 다음과 같은 장점이 있습니다. 객체의 상태 변화를 관찰하고 싶은 객체들을 쉽게 관리할 수 있습니다. 객체의 상태 변화를 관찰하는 객체들을 쉽게 추가하거나 제거할 수 있습니다. 객체의 상태 변화를 관찰하는 객체들 간의 결합도를 낮출 수 있습니다. Observer 패턴의 예시 Observer 패턴의 예시로 게임의 캐릭터를 생각해 볼 수 있습니다. 게임의 캐릭터는 자신의 상태가 변경될 때마다, 이를 관찰하고 있는 다른 캐릭터들에게 알림을 보냅니다. 다음은 Observer 패턴을 사용하여 게임의 캐릭터를 구현한 예시입니다. Python Code 위 코드에서 Character 클래스는 observers라는 리스트를 사용하여 Observer 객체들을 관리합니다. notifyObservers() 메서드는 observers 리스트에 등록된 모든 Observer 객체들에게 알림을 보냅니다. Enemy 클래스는 Character 클래스를 상속받아 구현됩니다. Enemy 클래스는 hp 필드를 사용하여 적의 체력을 관리합니다. changeState() 메서드는 적의 체력이 0 이하가 되면, notifyObservers() 메서드를 호출하여 플레이어에게 알림을 보냅니다. Player 클래스도 Character 클래스를 상속받아 구현됩니다. Player 클래스는 attack_power 필드를 사용하여 플레이어의 공격력을 관리합니다. update() 메서드는 notifyObservers() 메서드를 호출하여 적에게 알림을 보냅니다.

오늘은 디자인 패턴 중 하나인 Singleton 패턴에 대해 간단히 소개해드리려고 합니다. Singleton 패턴이란? Singleton 패턴은 클래스에 단 하나의 인스턴스만 생성되도록 하는 패턴입니다. 즉, 클래스의 인스턴스를 생성하는 방법을 제한하여 클래스에 단 하나의 인스턴스만 생성되도록 합니다. Singleton 패턴의 장점 Singleton 패턴을 사용하면 다음과 같은 장점이 있습니다. 클래스에 단 하나의 인스턴스만 생성되도록 보장할 수 있습니다. 클래스의 인스턴스를 공유할 수 있습니다. 클래스의 인스턴스를 캡슐화할 수 있습니다. Singleton 패턴의 예시 Singleton 패턴의 예시로 게임의 주인공을 생각해 볼 수 있습니다. 게임의 주인공은 항상 하나만 존재해야 합니다. 따라서 게임의 주인공을 Singleton 패턴으로 구현할 수 있습니다. 다음은 Singleton 패턴을 사용하여 게임의 주인공을 구현한 예시입니다. Python Code 위 코드에서 Hero 클래스는 __instance라는 클래스 변수를 사용하여 Singleton 패턴을 구현합니다. __instance 변수는 Hero 클래스의 인스턴스를 참조합니다. Hero 클래스의 getInstance() 메서드는 __instance 변수가 None이면 새로운 Hero 인스턴스를 생성하고, None이 아니면 __instance 변수에 저장된 인스턴스를 반환합니다.