Gophercon 2025 올해 처음으로 고퍼콘에 참여하여 여러 세션을 들으며 다양한 인사이트를 얻을 수 있었습니다. 웰컴 티셔츠도 무료로 주셔서 감사한 마음으로 받고 관련 굳즈들(후드티, 뱃지, 키캡)과 스티커들을 왕창 얻을 수 있었네요. Gophercon 2025 세션은 다음과 같았어요 Go 로 만든 AI 주식 추천 및 자동매매 시스템 동시통역 Go로 만들기 - 실시간 AI 인퍼런스, WebRTC 프레임워크냐, 아니냐: 그것이 net/http로다 Effect-ive Go: 완전히 Go 다운 함수형 프로그래밍 Test Reality Not Mocks: Reliable Go Tests in the AI Era Dev in Go way (Go스러움) Go로 밑바닥부터 맨 땅에 헤딩하듯 만드는 P2P 블록체인 네트워크 sync 패키지를 활용해서 강력한 버퍼링 만들기 / 부제: 실제 사례로 살펴보는 Go의 간편한 동시성 프로그래밍 이 중에서 몇 개는 QnA를 하느라 못 들은 점이 아쉽네요. 들은 세션중에 인상 깊었던 것을 정리하면 아래와 같아요. ...

문제 상황 프로젝트 배경 지금 다루고 있는 서비스는 안과의사 PC에서 돌아가는 온프레미스 서비스입니다. 장비 들에서 찍은 데이터들을 토대로 의사들이 정확한 진료를 내릴 수 있도록 도와주는 온프레미스 의료 데이터 통합 웹 툴이죠. 이 서비스에서 장비와의 데이터 통신 부터 받은 데이터에 대한 파이프라인, 프론트 작업과 퍼블리싱 작업까지 넓게 맡고 있습니다. 해당 글에서 다룰 이슈는 다음과 같습니다. 특정 장비에서 부터 일정 양 이상의 데이터를 받으면 데이터베이스가 죽어버린다는 문제가 발생하였습니다. 장비의 데이터를 안정적으로 수신하여 의사한테 정확한 데이터를 보여줘하는 서비스 특징 상 매우 큰 이슈였습니다. ...

Go언어 프로젝트 가이드 A-Z 주된 내용 프로젝트의 크기가 Feather 단위에서 Enterprise 단위까지를 이룰 때 Application 개발을 GoLang으로 할 경우 어떻게 접근하는지에 대한 구조도 규모에 맞춰 아래와 같이 나눠서 접근 초기(스타트업/MVP 단계) 사용자 검증을 위한 빠른 개발에 집중 불필요한 라이브러리 최소화, 표준 라이브러리 활용 기능 단위로 간단히 구현, HandlerFunc 중심의 빠른 개발 패턴 활용 서비스 확장 단계(유니콘/중간 규모) 기능이 많아지고 의존성이 복잡해지므로 이 시기부터 패턴의 중요성 커짐 단순 HandlerFunc에서 Handler 패턴으로 전환하는 시기로 특히 상태 관리, 의존성 명확화가 필요 Handler 패턴: 구조체에 의존성을 주입할 수 있게 하고, ServeHTTP를 구현하게 해서 어디든 사용 가능하게 해서 확장성을 챙김 type PingHandler struct { DB *sql.DB } func (h *PingHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) { // DB 같은 의존성 명확하게 사용 가능 w.Write([]byte("pong with DB")) } 기능 단위에서 서비스 단위 아키텍처로 확장 엔터프라이즈 단계 DDD(Domain-Driven Design) 적용을 통해 기능 중심에서 비즈니스 도메인 중심으로 분리 Bounded Context로 경계 정의 데이터 흐름을 확실히 나눔 API 모델과 내부 도메인 분리 (Presenter 패턴 활용) 각 레이어 분리로 테스트 용이 (Fake 구현 활용) 운영 필수 도구 ...

기본 지식 Gno.Land가 무엇인지 알기 위해서는 몇 가지 사전 지식을 알아야 이해할 수 있습니다. 블록체인 블록체인과 암호화폐를 혼동하기 쉬운데, 블록체인은 기술이고 암호화폐는 그 기술 위에서 돌아가는 서비스입니다. 인터넷과 이메일의 관계가 블록체인과 암호화폐의 관계와 같다고 볼 수 있죠. 이메일도 인터넷 위에서 돌아가는 서비스잖아요. 블록체인 = 인터넷 암호화폐 = 이메일 블록체인은 중앙 기관 없이 개인끼리 거래를 하고, 거래 내역을 안전하게 기록하고 검증하기 위해 개발된 것으로, 자연스럽게 다음과 같은 특징을 지닙니다. 탈중앙화 (Decentralization) 중앙 서버나 은행 없이 네트워크 참여자 모두가 거래 기록을 공유. 특정 기관이 데이터를 조작하기 어려움. 변경 불가성 (Immutability) 한 번 기록된 블록은 뒤의 블록들과 연결되어 변경이 사실상 불가능. 데이터 위변조를 막을 수 있음. 투명성 (Transparency) 거래 내역이 누구에게나 공개됨. (예: 비트코인 블록 탐색기에서 모든 거래 확인 가능) 신뢰를 코드와 시스템으로 확보. 보안성 (Security) 암호학 기술(해시 함수, 공개키 암호화 등)을 이용해 안전하게 거래 기록을 보호. 합의 알고리즘 (Consensus Algorithm) 누가 새로운 블록을 만들 자격이 있는지, 어떤 블록이 진짜인지를 정하는 규칙. 비트코인: 작업증명(PoW, Proof of Work). PoW: 노드들이 어려운 수학 문제(해시 퍼즐)를 풀어서 블록 생성 권리를 획득. 이후: 지분증명(PoS, Proof of Stake), BFT 등 다양한 방식이 발전. PoS: 지분(코인 보유량)을 기반으로 블록 생성자 선택. 후에 이더리움이 등장하며 단순한 거래 시스템에서 벗어나 프로그램을 실행할 수 있게 되었고, 지금은 Gno.land를 통해 GitHub와 같은 오픈소스 협업 플랫폼을 블록체인에서 구현하려는 시도들이 이어지고 있습니다. ...

0. 개요 CMS는 대부분의 개발자가 가장 먼저 접하는 친숙한 구조입니다. CRUD를 기반으로 한 패턴으로 어떤 기술을 배우든 자연스럽게 마주하게 되죠. 라프텔, 넷플릭스, 네이버 쇼핑, 다음 웹툰, 링크드인까지 우리가 쓰는 대부분의 서비스도 사실상 CMS의 확장 버전이라 볼 수 있습니다. 가장 단순해 보이지만, 그만큼 끝 없이 파고들 수 있는 구조로 그동안 당연하게 써왔지만 정리를 해본 적이 없었네요. 이번에 처음으로 쭉 정리해봤습니다, 부족한 점이 있다면 가감 없이 피드백 부탁 드려요 1. 콘텐츠 CRUD 1.1 생성 (Create) SEO용 slug 자동 생성 (핵심 키워드, stop word 제거, 소문자 사용, 특수문자 제거) XSS, SQL Injection 검증 캐시 데이터에 추가 스케줄링 처리: 작은 작업은 cron을, 대용량은 메시지 큐(Kafka, BullMQ)를 사용하여 백그라운드 작업 자동화 테스트: CRUD API가 정상적으로 작동하는 지를 CI/CD 파이프라인에 포함하여 매번 체크 다양한 플랫폼 지원: 부 모바일/TV 앱이 동일 API 사용 가능 형태로 설계 요금제 플랜: Redis를 이용해서 계정마다 현재 접속 수 체크해서 요금제 플랜에 맞게 관리 모니터링: 업로드 실패율, 렌더링 지연, 승인 리뷰 대기 시간, 서버 리소스 등 수치 트래킹 sentry: 모니터링 도구로 실시간 에러 트래킹과 프론트, 백엔드에서 발생하는 예외, 로그, 버그 정보를 수집하여 UI로 시각화 해줌 datadog: 서버, 애플리케이션, 로그, 메트릭, 인프라를 통합 모니터링 툴로 sentry보다 범용적이며 DevOps에서 많이 사용됨 리소스 파일 업로드: 리소스 파일들을 Multipart Upload Protection, 즉 chunk 단위로 업로드해서 악성파일, 과도한 용량문제 해결, 보안 룰 적용 (확장자, MIME 타입, 바이러스 검사) API 문서화: drf-spectacular 같은 걸로 자동 문서화 1.2 읽기 (Read) 상태, 태그와 같은 조건에 따라 필터링된 대용량 데이터에 대한 쿼리 캐시 지원 공개된 데이터는 Redis / Memcached로 select list를 캐싱 변경시는 수동으로 캐시를 지우거나 TTL이 짧다면 자동 갱신 비디오/이미지/정적 리소스는 CDN으로 읽기 비용 감소 발행이 Draft로 콘텐츠여도 미리보기 링크로 확인 가능 1.3 수정 (Update) 업데이트 충돌 방지를 위해, Optimistic Concurrency로 글을 수정을 진행할 때와 가져온 글 버전과 저장할 떄 글 버전이 같아야 함 slug나 파일 링크 변경시 유효한지 검사 변경전 슬러그도 지원하기 위한 alias 기능 콘텐츠 변경시 이전 버전들을 저장해서 글의 버전 관리 비디오 파일이 바뀌면 자동으로 썸네일 재생성 콘텐츠가 업데이트되면 관련 select 캐시나 cdn 캐시 데이터 수정 콘텐츠 수정 시 어떤 Text가 바뀐지를 Diff 뷰로 보여줌 1.4 삭제 (Delete) Deleted At 또는 Disabled로 soft 삭제를 하고, 추후에 관리자나 유저가 DB에서 완전 삭제후 자동 purge soft 삭제로 db 리소스 접근을 최소 화하는 방법으로 좋아요나 이모지 같이 사용자가 장난 칠 수 있는 기능에 적합 연관 데이터, 댓글, 조회수/통계 테이블, 썸네일, 원본 정적 리소스 파일간의 관계 제거 soft 삭제의 경우 복원 가능 누가, 언제, 어떻게 삭제했는 지를 기록 삭제된 콘텐츠로 접근 시 301로 리디렉트하거나 404로 반환 2. 콘텐츠 관리 2.1 콘텐츠 상태 관리 발행 관리: Draft, Published, Scheduled 시간 관리: Updated At, Created At 2.2 동영상 콘텐츠 실시간 방송 스트리밍 (단방향 실시간 통신) 장르, 태그, 시리즈, 년도(분기), 현재 방영 여부, 출시타입(TAV,극장판 OVA)로 영상 콘텐츠 분리 현재 방영 작은 요일별 신작으로 확인 가능하게 분리 원할한 스트리밍 서비스를 위한 캐싱이나 인코딩 처리 필요 2.3 콘텐츠 일정 설정 예약 게시일 등록 콘텐츠에 유효기간이 있다면 만료일도 등록 2.4 팀 기반 콘텐츠 작성자 관리 (PD, 편집자, 운영자) 권한별로 접근할 수 있는 메뉴, 페이지 분리 3. 데이터 보안 3.1 데이터 암호화 암호화 대상: 개인정보 (주민등록번호, 이름, 이메일, 비밀번호 등) 암호화 방법 대칭키 암호화: 암복호화에 같은 키 사용, 빠르고 효율적 대상: 이메일, 주소, 이름 등 자주 조회 및 수정이 필요한 데이터 암호화: AES-256, AES-GCM 비대칭키 암호화: 공개키로 암호화, 개인키로 복호화하고 느리지만 공개 키 배포 가능 대상: 민감한 서명, 토큰, 공개키 기반 인증 구조 (JWT, OAuth, SSH 등) 암호화: RSA 비밀번호는 복호화가 불가능한 해시 알고리즘 채택 (bcrypt, scrypt) 암호화 레이어 별 특징 애플리케이션 레벨: 코드에서 작업하므로 필드 단위로 세밀한 제어가 되지만 코드의 복잡잡도 증가 DB 레벨 (TDE): 전체 테이블/디스크를 설정만으로 암호화가 되지만 필드 제어가 불가능하고 느림 하이브리드: 민감한 데이터는 앱단에서 나머지는 TDE로 진행하면 성능과 보안의 밸런스를 조절할 수 있지만 설정에 복잡도 증가 키 관리: 암호화 키는 별도의 키 시스템으로 관리 ex: AWS KMS 참고 사항: 암호화된 데이터는 로그에 찍으면 안됨 잦은 검색 조건이 있는 건 인덱스 때문에 암호화 지양하고 민간함 정보만 암호화화 환경에 맞게 코드 컨밴션 툴 사용해서 코드 스타일 유지 Python의 black, PEP8 스타일 가이드 준수 Python의 isort, import 정렬기로 black과 같이 사용 4. 동영상 업로드 및 변환 4.1 동영상 업로드 시나리오 업로드 → 인코딩 → 썸네일 생성 → 배포 4.2 인코딩 포맷 MP4: 범용 포멧으로 대부분의 브라우저에서 지원하지만 스트리밍에서 성능이 제한적 HLS(HTTP Live Streaming): Apple 주도로 ios 친화적 스트리밍에 적합하고 현재는 다양한 장치에서 지원 DASH (MPEG-DASH): MPEG 표준, 크롬/안드로이드 친화적이고 유연한 확장성 제공 보통 두 가지 스트리밍 포맷(HLS & DASH)을 생성하고 클라이언트에서 상황에 맞춰 제공 4.3 Resumable Upload (중단 후 다시 업로드) tus(open protocol, 업로드 중단/복원 대응 강력), multipart upload, chunked upload 방식 사용 AWS S3 multipart upload도 해당 기능을 제공하니 클라우드를 활용 클라이언트에서 chunk 관리를 위해 JS 기반 상태 저장 로직 필요 4.4 자동 해상도 변환 (240p~4K) 하나의 동영상을 다양한 해상도 변환해서 저장 (360p, 480p, 720p, 1080p, 1440p, 4K) 자동 트랜스코딩 워크플로우는 큐 기반으로 비동기 처리 4.5 썸네일 자동 생성 프레임 수 기준 중간 지점이나 가장 밝은 장면 등 다양한 조건으로 썸네일 생성 AI 기반 썸네일 추출 기능 관리자 수동 업로드도 지원 4.6 FFmpeg + Redis + Worker 기반 트랜스코딩 큐 업로드된 파일은 곧바로 트랜스코딩하지 않고 큐에 등록 후 비동기 처리 ...

고등학교 모교로 가게 된 이유 저번 구글 I/O 후기 글에서 나왔던 구글 I/O Exteneded를 갔다오고 문뜩 든 생각이 현업의 있는 개발자들도 AI로 고민을 하는데 개발자를 준비하는 사람들은 어떻게 고민할지가 궁금했습니다. 이런 부분에서 학교에서 어떻게 가르치는 지도 궁금해졌고, 세미나 있던 다음 날에 바로 고등학교 선생님께 이점을 묻게 되었는습니다. 점점 이야기를 하다 보니 선생님께서 관련 주제로 학교로 와서 이야기하면 좋을 것 같다고 하셔서 이번 기회에 고등학교로 가서 작게 세미나를 하게 되었습니다. ...

Google I/O Extended 이번에 개인 스터디 모임에서 알게 된 인연으로 덕분에 2025년 7월 26일 인하대에서 열린 컨퍼런스에 참여하게 되었습니다. 단체가 아닌 개인이 오프라인으로 참여한 컨퍼런스는 이번이 처음이었는데, 생각 이상으로 인사이트를 얻을 수 있고 요즘 있던 개발에 대한 가치관 확립과 동기 부여를 받을 수 있었습니다. 다른 분들에게 작게나마 도움이 되길 바라며 적은 Google IO 인천 후기입니다. 목적 현재 다니고 있는 회사에서 AI 툴 적용을 드디어 장려하기 시작했습니다. IT 기업이 아닌 제조 업체다 보니 같은 개발자 직군인데도 불구하고 소극적으로 AI를 업무에 활용하시는 분이 있었습니다. ...