T3rry T3rry

분산 처리 환경 구축 2 — iperf3로 네트워크 대역폭 테스트여러 노트북을 이용해 분산 연산을 수행하려면노드 간 네트워크 성능이 충분한지 확인해야 한다.예를 들어Spark shuffleHadoop 데이터 전송대용량 데이터 분산 처리등에서는 네트워크 대역폭이 병목이 될 수 있다.그래서 실제로 iperf3를 사용하여 노드 간 네트워크 성능을 측정했다.1. iperf3란?iperf3는 네트워크 대역폭을 측정하는 대표적인 툴이다.특징TCP / UDP 테스트 가능실제 전송 속도 측정네트워크 병목 확인동작 방식은 간단하다.Server (대기) ↑ │ 데이터 전송 ↓ Client (전송)2. 테스트 방법서버 실행한 노드를 서버로 실행한다..\\iperf3.exe \-s출력Server listening on..

분산 처리 환경 구축로컬 네트워크 세팅고정 IP 설정Ping test분산 처리를 하기 위해 여러 대의 노트북을 하나의 네트워크로 묶어야 했다. 이번 프로젝트에서는 여러 노트북을 클러스터처럼 사용하여 분산 연산을 수행하는 환경을 구축하는 것이 목표이다.네트워크 구조SSAFY 내부망 │ │ 공유기 │ │ 스위치 (Netgear) │ ┌────┼────┬────┬────┐노트북1 노트북2 노트북3 ...가장 먼저 해결해야하는 문제는 노트북들의 IP 주소 관리Setting Flow1. 왜 고정 IP가 필요한가?기본적으로 공유기는 DHCP를 통해 IP를 자동 할당한다.하지만 DHCP는 다음 문젝가 있다.일정 시간이 지나면 IP가 변경될 수 있음서버 간 통신 주속..

좋은 설계를 하는 법설계는 항상 어렵다.특히 팀 프로젝트를 하다 보면 이런 상황이 반복된다.회의는 많이 하는데 설계가 잘 정리되지 않는다ERD를 먼저 그리려고 하면 계속 바뀐다아키텍처를 먼저 잡아야 하는지, 데이터 모델을 먼저 잡아야 하는지 헷갈린다결국 한 사람이 설계 문서를 정리한다이런 경험들을 정리하면서 좋은 설계를 하는 사고 흐름을 정리해보았다.1. 설계는 혼자 만드는 것이 아니라 구조화하는 것이다설계는 보통 이런 흐름으로 진행된다.아이디어 생성 → 팀 전체논의 / 방향 결정 → 팀 전체설계 문서 정리 → 담당자 1명리뷰 및 수정 → 팀 전체즉 설계는같이 생각하고→ 한 사람이 구조화하고→ 다시 같이 검증한다여러 사람이 동시에 ERD를 작성하는 경우는 거..

1. 인트로 & 서비스 이해발표 초반 인트로만으로 이 서비스가 무엇을 해결하는지 파악하기 어려웠다문제 정의와 서비스 목적이 명확하게 드러나지 않음청자가 “그래서 이걸 왜 쓰는 건데?”라는 질문을 초반에 갖게 됨개선 포인트인트로에서 반드시:누가어떤 상황에서어떤 문제를 겪고 있고MIKO가 그걸 어떻게 바꾸는지를 한 흐름으로 제시할 필요가 있음미코가 화상회의 서비스라는걸 도입부 가지고 이해가 안되었음2. 시연 구성 & 전달 방식시연이 길고 설명이 없어 지루하거나 오해가 생길 수 있음시연을 “하겠습니다”라고 선언하고 바로 시작해 몰입이 깨짐시연 중 해설 부재로 무엇을 봐야 하는지 알기 어려움개선 포인트시연은 상황극처럼 자연스럽게 진입하는 것이 효과적예: “회의를 해야 하는 상황인데, 한번 써볼까요?”역할 분리가..

발표 피드백실제 현장에서의 가독성을 신경써라노트북 화면이 아니라 프로젝터, 뒷열 청중 등의 입장에서 봐라.어두운 글씨, 어두운 말풍선 등 가독성이 떨어짐정보를 분리해라하나의 장표안에 많은 것들을 한번에 보여주면 눈으로 먼저보고(스포일러) 그 다음으로 오는 설명들은 잘 들리지 않는다. 지루하다.애니메이션, 또는 다른 장표로 분리해라시선을 유도하라발표자가 손으로 이끈다.애니메이션과 하이라이팅으로 이끈다.복잡한 전체를 보여주고 강조할 부분을 확대하거나 새로운 슬라이드에서 보여줘라화면 같은 부분은 gif 를 사용한다.중요하지않은건 제거하라.쿼리 문같은건 중요하지 않으면 제거하라청중입장에서 화면에 읽을게 많으면 집중이 어렵고 피곤하다.발표자의 화법도 중요하다.화법이 정제되지않아 팀미팅같은 분위기였다.한번더 정제해..

약품고 프로젝트 마무리실사, 발표, 그리고 전체 회고이 글은 약품고 프로젝트의 마지막 정리다.실제로 겪었던 실사·발표 경험과 그 이후의 생각을 중심으로 정리한다.1. 실사약품고 소개 영상 약품고 시연 영상실구현 회고“코드는 준비됐는데, 환경이 다르다”실사 준비는기능 점검보다 환경 적응에 가까웠다.사진과 영상 촬영, 전체 흐름 설명까지는 비교적 수월했지만막상 냉장고 내부 장비에서 직접 띄워보니개발 환경과는 다른 문제들이 하나씩 드러났다.리눅스에서의 브라우저 이슈냉장고 내부 장비는 리눅스 환경이었고,브라우저는 Chrome이 아니라 Chromium이었다.이 차이가 생각보다 컸다.Chrome 기반 STT 기능 사용 불가일부 웹 API 동작 차이확장 기능 사용 제약“같은 크롬 계열이니까 되겠지”라는 가정은 통하지..

개요이 글을 읽기 전에,이 프로젝트는 두 가지 아키텍처를 전제로 설계·구현되었다는 점을 먼저 설명하고 싶다.개발용 아키텍처실 서비스(운영) 아키텍처두 환경은 목적이 다르기 때문에구성도 명확히 분리되어 있다.아키텍처 개요개발용 아키텍처개발 단계에서는 EC2 서버 중심 구조를 사용했다.EC2 서버에BackendFrontendDatabase임베디드 보드는네트워크를 통해 서버와 HTTP 통신개발, 테스트, 디버깅을 빠르게 반복하기 위한 구조다.실 서비스 아키텍처실 서비스 환경에서는냉장고 내부 장비 중심 구조로 전환된다.냉장고 내부 Raspberry PiFrontendBackendDatabase임베디드 제어Jetson Orin카메라 인식챗봇 기능외부 서버 의존도를 최소화하고,현장에서 독립적으로 동작하도록 구성했다..

편했던 점, 어려웠던 점, 그리고 처음 체감한 키워드들이번 프로젝트에서 CI/CD는각자의 분야에서 빠르고 쉽게 배포하고 자기것과 연동해서 테스트해 볼 수 있도록하는게 목표였다.개발 서버를 굴리고, 실제 보드에 올려보고,원격으로 붙어서 디버깅까지 하다 보니CI/CD가 잘 되어있으면, 팀의 개발속도가 빨라진다고 느꼈다. 다만, 셋팅이 너무 어렵다... 그리고 팀원들의 로컬 원격 서버 실제 개발 아키텍처 에 대한 이해 없이는 정상적으로 흘러가지 않았다.개발 서버 운영 구성 요약Docker / Docker Compose: 서비스 단위 격리Jenkins: 빌드 & 배포 자동화Nginx Proxy Manager(NPM): 도메인/HTTPS/프록시 관리Tailscale: 서버·개발 PC·임베디드 보드 간 사설 네..