대학생분들이 모여서 운영하다보니 항상 금전적인 측면에서 힘든 상황을 겪고 있습니다. 그나마 여러분들의 성원과 도움으로 만들어진 AWS 크레딧과 후원금으로 운영되고 있습니다.

하지만 이또한 지속가능하다고 하기엔 불확실성이 짙기 때문에 서비스 운영에 들어가는 비용 자체를 줄일 필요성을 많이 느끼게 된것같아요 그중에 운영비용 중 AWS 서버비가 가장 많은 금액을 차지했었습니다.

피플을 사용하신 분들 중 공지사항을 한번이라도 보셨다면 저희 서버비용이 상당히 많이 나오는데요 비용 최적화 이전 평균 370~380달러 정도로 지출되고 있었습니다. 원화로 480,000원 정도로 매우 부담스러운 금액이었습니다.

저희 서비스는 AWS에서 운영되며 실제 운영서버는 다음의 서비스들로 구성되어 있었습니다.

• ECS Fargate
• NAT Gateway
• Elastic Load Balancer
• CloudFront
• RDS
• S3

ECS Fargate와 ELB를 통해서 고가용성을 보장해주었고 NAT Gateway로 보안성을 높였습니다.

이러한 구성으로 운영환경에는 총 150~200 달러가 지출되고 있었습니다. 하지만 가장 큰 문제는 개발에 활용하게되는 개발서버들이었습니다.

크레딧이 있고 시간이 없다는 이유로 Elastic Beanstalk, Amplify 등을 막 생성하다보니 개발환경에 들어가는 돈이 운영환경보다 더 많아져버리는 배보다 배꼽이 더 큰상황이 와버린거죠

이를 해결하기 위해 AWS 서비스 중 저렴하고 금액이 일정하게 발생하는 서비스를 찾고 있던 도중

Lightsail이라는 서비스를 발견하게 됩니다.

아마존 Lightsail은 AWS에서 만든 가상 프라이빗 서버로 프로젝트를 빠르게 시작하는 데 필요한 가상머신, 스토리지, Networking, 로드밸런서, DNS, 고정IP, OS 등 모두 포함하고 있어 웹서비스를 빠르고 쉽게 구축하는데 특화되어 있는 서비스 입니다.

즉 EC2와 비슷하지만 애플리케이션에 대한 구성을 빠르게 할 수 있고 금액또한 제일 저렴한 모델로 1달 고정 3.5달러에 구성할 수 있는 매우 저렴한 이용할 수 있는 서비스입니다.

사이드 프로젝트나 개발 환경을 구성할 때 둘도 없는 서비스라고 볼 수 있습니다.

자 일단 어떤 서비스를 이용할지는 정해졌습니다. 이제 뿔뿔이 흩어져 있는 서버들을 Lightsail로 옮겨야 합니다.

저는 이를 위하여 Nginx와 Docker를 사용하기로 했습니다.

Nginx는 적은 자원을 갖고 고성능, 고가용성을 자랑하는 웹 서버 소프트웨어 입니다.

리버스 프록시, 로드밸런서, 캐싱, SSL등 여러 기능을 최소한의 자원을 사용하기 때문에 현재 가장 사랑받는 웹 서버 중 하나 입니다.

저희는 여러 서버를 하나로 옮기기 위하여 Nginx의 리버스 프록시 기능과 SSL을 사용하기로 결정했습니다.

리버스 프록시: 웹 서비스의 핵심 요소

오늘날의 복잡한 웹 환경에서 리버스 프록시는 중요한 역할을 합니다. 이 기술은 웹 서비스의 성능, 보안, 그리고 확장성을 크게 향상시킬 수 있는 도구로 널리 사용되고 있습니다. 이 글에서는 리버스 프록시가 무엇인지, 어떻게 작동하는지, 그리고 왜 중요한지에 대해 살펴보겠습니다.

리버스 프록시란?

리버스 프록시는 클라이언트와 서버 사이에서 요청과 응답을 중계하는 역할을 하는 서버입니다. 클라이언트가 서버에 직접 요청을 보내는 대신, 리버스 프록시 서버를 통해 요청이 전달됩니다. 이는 일반적인 프록시 서버와 반대 방향으로 작동하며, 여러 가지 이유로 매우 유용합니다.

리버스 프록시의 주요 기능

1. 로드 밸런싱: 리버스 프록시는 네트워크 트래픽을 여러 서버에 분산시켜 서비스의 부하를 줄이고 안정성을 높입니다.
2. 보안 강화: 서버의 실제 IP 주소를 숨기고, 외부 공격으로부터 서버를 보호합니다.
3. SSL 암호화: 클라이언트와의 통신을 암호화하여 보안을 강화합니다.
4. 캐싱 및 압축: 자주 요청되는 콘텐츠를 캐시하여 응답 속도를 향상시키고, 데이터 압축을 통해 대역폭을 절약합니다.

리버스 프록시의 작동 방식

클라이언트가 웹 페이지나 서비스에 접속을 시도할 때, 리버스 프록시 서버가 이 요청을 받아 실제 서버로 전달합니다. 그 후 서버의 응답을 다시 클라이언트에게 전달합니다. 이 과정에서 리버스 프록시는 요청을 조절하고, 필요한 보안 조치를 취하며, 캐싱 정책에 따라 콘텐츠를 저장합니다.

물론 리버시 프록시는 여러대의 서비스를 한 웹서버내에서 컨트롤 할 수 있다는 점에 대해서 MSA 아키텍처에서 많이 사용되는 기술입니다.

하지만 저희는 개발 서버의 단일화를 위한 작업이기 때문에 리버스 프록시와 함께 쓸 기술로 도커를 선정하였습니다.

Docker란?

도커란 컨테이너 가상화 기술을 사용하여 응용프로그램을 더 쉽게 배포, 실행 할 수 있도록 설계된 툴이며 컨테이너 기반의 기술 및 오픈소스라는 특징을 갖고있습니다.

서버에서의 컨테이너 기술은 자신이 필요한 프로그램 혹은 실행환경 등 여러 리소스들을 한곳에 모아놓고 관리 할 수 있습니다.

VM(Virtual Machine) 보다 경량화 되고 Docker Engin을 통해 커널 등 컴퓨터 리소스를 공유하기 때문에 서버 하나에 자원을 공유하기 때문에 어플리케이션 배포에 있어서는 거의 표준이 된 기술이라고 할 수 있습니다.

물론 배포가 끝이 아니기 때문에 이 컨테이너를 관리하기 위해선 k8s,Docker Swarm 등 추가적인 라이브러리, 프레임워크를 조합하여 사용하여야 하지만 저희는 개발 환경을 구성하는 것이기 때문에 오버엔지니어링 이라는 판단하에 멀티 컨테이너를 구성하기 위해 가장 간단한 Docker-Compose를 사용하였습니다.

Docker Compose란?

Docker Compose는 여러 컨테이너로 구성된 애플리케이션을 정의하고 실행하기 위한 도구입니다. 하나의 YAML 파일(docker-compose.yml)을 사용하여 서비스, 네트워크, 볼륨과 같은 애플리케이션의 모든 컴포넌트를 구성할 수 있습니다.

주요 특징

1. 간편한 설정: docker-compose.yml 파일을 통해 복잡한 설정을 간단히 정의할 수 있습니다.
2. 일관된 환경 제공: 개발, 테스트, 프로덕션 환경에서 일관된 실행 환경을 제공합니다.
3. 서비스 관리: 여러 컨테이너를 쉽게 빌드, 시작, 정지, 재시작할 수 있습니다.

Docker Compose의 장점

1. 개발 효율성: 여러 컨테이너를 한 번에 관리하므로 개발 프로세스가 효율적입니다.
2. 구성의 간소화: 복잡한 구성을 한 곳에서 관리할 수 있어, 오류를 줄이고 유지보수가 쉬워집니다.
3. 이식성: Docker Compose 파일 하나로 어디서나 같은 환경을 구축할 수 있습니다.

version: '3.8'  # Docker Compose 파일 버전

services:
  api-server:
    container_name: api-server  # 컨테이너 이름 설정
    build:                      # 빌드 설정
      context: ./pple-api       # 빌드 컨텍스트(도커 파일 위치)
    image: api-server           # 생성될 이미지 이름
    restart: unless-stopped     # 컨테이너가 정지되지 않는 한 재시작
    env_file:                   # 환경 변수 파일 지정
      - ./pple-api/.env

  redis-master:
    container_name: redis-master  # 컨테이너 이름 설정
    image: 'emibgo/redis'         # 사용할 이미지
    ports:                        # 포트 매핑
      - '6379:6379'               # 호스트의 6379 포트를 컨테이너의 6379 포트에 연결

  admin:
    container_name: admin       # 컨테이너 이름 설정
    build: ./pple-admin2        # 빌드 경로
    image: admin                # 생성될 이미지 이름
    restart: unless-stopped     # 컨테이너가 정지되지 않는 한 재시작

  pple-web:
    container_name: pple-web    # 컨테이너 이름 설정
    build: ./pple-main-web-v2   # 빌드 경로
    image: pple-web             # 생성될 이미지 이름
    restart: unless-stopped     # 컨테이너가 정지되지 않는 한 재시작

networks:
  default:
    external:
      name: nginx_default       # 외부 네트워크에 연결, nginx_default 네트워크 사용

저희 개발환경에서 돌아갈 service 들을 docker-compose.yml 파일에 작성해줍니다. docker-compose.yml에 있는 컨테이너들은 컨테이너의 이름에 따라 서로 통신이 가능하게 되며 docker network를 추가로 생성하고 newtorks external을 통해서 연결시켜 주면 다른 yml에 적혀있는 컨테이너와도 통신이 가능하게 됩니다. 이를 통하여 nginx 등 기반이 되는 몇몇 애플리케이션과 직접 개발하는 애플리케이션을 분리 시켜 관리의 용이성 또한 증대 시킬 수 있습니다.

이후 nginx.conf 파일을 수정 해줍니다.

http {
    server {
        listen 80;

        location /api/ {
            proxy_pass http://api-server:8080; # api-server 서비스의 포트
        }

        location /admin/ {
            proxy_pass http://admin:3000; # admin 서비스의 포트
        }

        location / {
            proxy_pass http://pple-web:3000; # pple-web 서비스의 포트
        }
    }
}

이런식으로 설정해주게 되면 서브 도메인으로 api가 요청으로 들어오면 api 컨테이너에 요청이 가도록 구성할 수 있습니다.

※ Docker에서 각 컨테이너는 독립된 네트워크 네임스페이스를 가지고 있습니다. 이는 각 컨테이너가 마치 별도의 물리적 호스트인 것처럼 자신만의 IP 주소, 포트, 네트워크 스택을 가질 수 있음을 의미합니다. 따라서, 서로 다른 컨테이너는 동일한 포트 번호(예: 80, 8080)를 사용해도 서로 간섭하지 않습니다.

이렇게 해서 저희는 nginx & docker-compose로 개발환경을 구축해서 Lightsail에 배포하였는데요

이를 통해서 기존의 400$ 정도 나가던 AWS 비용을 50~60% 절감하여 200$ 정도로 축소 시킬 수 있었습니다.

운영 환경에 대한 최소 비용을 18090$ 잡고 있었기 때문에 운영 환경의 510%에 해당하는 비용만으로도 개발환경을 구성할 수 있게 되었습니다.

결론

간혹 백엔드 개발자 분들 중 개발까지만을 본인의 역할로 치부하고 배포 및 AWS 관리에 대해서는 소홀히 하는 경우가 있는데요 (과거의 본인 포함..) 인프라 구성을 어떻게 하는지에 따라 큰 금액차가 나는 만큼 인프라에 대한 학습도 빠지지 않고 하시는것을 권장드립니다. 저도 이번에 비용 최적화를 하면서 본인의 예산,구성해야할 환경에 따라 알맞는 아키텍처로 구상하는지에 따라 비용이 천차 만별이라는 것을 느낀 계기가 된것 같습니다.

ps

2024년 새해가 밝았는데 모두 새해복 많이 받으시고 즐거운 한해 보내시길 바라겠습니다! 감사합니다! 😊

저는 6월 피플에 UI 디자이너로 처음 들어와 팀 내에서 앱과 웹의 ui 디자인을 담당하게 되었고 그 외에도 굿즈나 행사물품 등 다양한 디자인도 맡는 중입니다.

학교다니며 디자인하면서 진행했던 프로젝트와 달리 개발자와 협력해야하는 과정, 개발 단계에서 실현 가능한 디자인인지 등을 고려해야하는 것이 큰 차이였습니다. 오늘 포스팅은 실무경험이 전무했던 제가 겪었던, 웹 디자인 작업 과정에서 발생한 어려움과 이를 해결했던 경험을 써보려고 합니다

웹 개발때 쓰일 디자인 소스들은 주로 백터 형식인 svg로 추출하여 쓰입니다. 레스터 형식의 JPEG와 PNG 이미지 파일과 달리 ai와 svg는 이미지의 형태를 수학 함수로 표현합니다. 원하는 모양, 위치, 크기, 색깔 등을 함수로 구성하기 때문에 확대해도 손상되지 않는답니다. 이 때문에 그래픽 작업에서 많이 쓰이는 방식이구요

웹 개발에서도 svg로 추출하여 쓴다고 했는데요, 피그마에서 작업한 이미지를 웹 개발자분이 svg로 내보냈을때, 웹에 적용 시키면 깨지는 현상이 발생했습니다.

피그마에서 픽셀이미지가 포함된 사진을 svg로 추출한 뒤, 웹 개발자분께서 적용하면 저렇게 깨지게 되는 문제점이... 내보낸 파일을 확인해보고자 svg파일을 어도비 일러스트레이터로 열었을 때는 아예 이미지가 날아가 보이지 않았습니다.

아무래도 svg가 백터단위, 이미지 픽셀단위이므로 단위가 다르므로 이미지가 날아가게 된다는 것은 알고 있었습니다.

그럼 svg로 어떻게 내보내? ㅠㅠ 치를 해봐도 이리저리 해봐도 해결되지 않고 png로 내보낼수도 없는 상황이었습니다. (png로 추출하면, 1배율로 추출하면 깨지고 애초에 크게 추출해도 개발 시 크기 조절도 불가하다는 개발자님의 말씀)

그럼 그냥 애초에 일러스트레이터로 작업해서 svg로 내보내는 최후의 수단을 써보았습니다.

설마 이게 되겠어? 걍 해보자 하는 마음으로요. 노가다이긴 하지만 우선 이미지를 불러 온 뒤 일일이 이미지 크기에 맞춰서 대지 크기를 똑같이 맞추는 작업을 진행했습니다.

근데.... 이게 되더라구요. (이게 왜 됨????)

저장된 파일을 열 때부터 확실히 피그마에서 만든 거와 다르게 깔쌈하게 잘 보였습니다.

웹에 적용시켜도 깔끔-하게 보이는 비타민 친구들이 보이시나요? 이 화면을 보고서 조금은 해방감을...느꼈달까요..?

결론은 피그마가 문제였다는 이상한(?) 결론을 짓긴 했지만 저도 아직은 공부가 많이 필요하다는 것을 깨달았습니다. 아무래도 협업이니 디자인 뿐만 아니라 개발에 대한 부분도 이해해야 서로 더 원활한 작업을 할 수 있다는 것을요.

앞으로도 더 멋지고 똑똑하고 프로패셔널한 디자이너가 되기 위해서, 한없이 부딪치는 방법이 가장 좋다고 생각합니다 ㅎㅎ 제 욕심인 것 같지만 나중엔 제 개인 포트폴리오 사이트를 만들어 보고 싶기도 하구요

이상 피플의 디자이너 이세영이었습니다! 읽어주셔서 감사합니다

React로 개발된 피플 사이트

처음 피플 웹사이트는 일반 typescript기반으로 CSR 방식의 React로 개발되었습니다. 그 당시에는 피플 어플이 우선이기 때문에 어플에서 지정헌혈 사연을 공유하면 보여주는 화면, 피플 소개 화면 을 보여주는 작은 사이트 였기 때문에 비용적인 측면에서도 CSR 방식의 React가 효과적이었습니다.

React의 배포과정

피플팀은 AWS를 이용하여 프론트엔드를 배포하고 있습니다.

1. react 파일을 빌드하여 정적파일을 aws s3에 올린다.
2. route 53을 통해 웹사이트에 사용할 도메인을 구입한다.
3. CDN을 이용하여 보다 사용자들이 빠르게 접속할 수 있도록 cloudFront를 이용한다.
4. cloudFront와 s3를 연결하고 route53까지 연결하면 끝이다.

AWS공식 react 배포 설명

이렇듯 React를 이용한 배포는 참 편리하고 간단해서 좋았습니다. 그럼에도 Next js로 변경한 이유는 뭘까요?

❓❓❔❔❓

React로 개발된 피플사이트의 단점

일반적으로 React는 CSR방식이기 때문에 웹사이트 소스를 사용자가 접속하면 js로 만들어주기 때문에 뼈대는 텅 빈 코드와 마찬가지 입니다. 그러다보니 검색엔진 부분에 있어서 단점이 있었습니다. 물론 네이버와 구글에 피플, 피플헌혈 등으로 검색하면

위와같이 첫 피플에 관한 소개는 검색이 되지만 위 사진처럼 피플에 관한 정보가 아닌 피플 서비스에서 작성된 게시글들이 검색되지는 않았습니다. 이러한 검색엔진 단점이 있어서 피플은 React -> Next js로 개발을 하게 되었습니다.

Next js로 개발을 하면서...

기존의 React로 개발된 사이트는 피플의 소개 페이지와, 공유된 사연의 게시글을 보여주는 기능뿐 이었지만, 피플 어플에 있는 기능들을 웹사이트에서도 할 수 있게끔 많은 기능들을 추가하였습니다. (현재도 어플에 있는 기능 100%를 소화하진 않지만 꾸준히 개발중입니다...) 처음으로 Next js를 이용해서 배포를 하다보니 어려움이 많았지만, 팀원들에게 다들 좋은 경험이라고 생각이 됩니다.

Next js 배포 과정

Next js를 배포할 수 있는 서비스는 아주 많이 있습니다. AWS s3,lambda,elastic beanstalk,amplify Next js를 개발한 vercel 등등.. 여러가지가 있지만 피플팀은 elastic beanstalk를 선택했습니다. 이유는 아래 링크를 참고 했습니다. (사실 제 개인블로그입니다. 많이 사랑해주세요 ❤️) 링크

배포 과정은 아래와 같습니다!

1. Next js를 빌드하여 빌드파일인 .next폴더와 public 폴더 package.json 파일을 묶어서 압축한다.
2. eb 인스턴스에 올린다.

그러면 이렇게 ok표시가 나오게 되는데 그럼 끝입니다! 참 쉽죠??

끝으로

오늘은 피플팀의 프론트엔드에 대해서 이야기 해보았는데요, 개발을 포함하여 피플팀은 아직도 부족하고 가야할 길이 멀다고 생각합니다. 하지만 그럼에도 좋은 팀원분들과 꾸준히 활동하면서 더 큰 가치를 창출해 낼 수 있도록 열심히 운영하고 있습니다. 많은 응원과 관심 가져주시면 감사하겠습니다!

때는 바야흐로.. 학창 시절..

오늘은 저에 대한 이야기를 해보고자 합니다! 고등학교 시절, 우연한 계기로, "사회적가치"에 대해 관심을 가지게 되었는데요, 무려, 2016년도로 돌아가서 이야기를 시작해보고자 합니다.

고등학교 시절, 대학에 진학하기 위해서, 꽤 많은 봉사시간을 채워야했습니다. 그래서 청소하고 봉사시간을 받는 프로그램에 참여했는데요, 반항심이 가득했던 시절이었는지, 조금 특별한 봉사를 하고 싶어, 지역의 어려운 환경의 친구들에게, 교육을 하는 교육봉사를 시작하게 되었습니다. 매주 2시간씩, 하교후에 센터에가서, 봉사를 하였고, 친구들이 과학 실험 같은 것을 매우 재밌어한다는 것을 알 수 있었습니다.

그래서, 함께 센터에서 봉사를 했던 친구들과, "패러데이 과학 봉사단"을 만들어, 노원평생학습관과 함께, "형아들과 함께하는 호기심과학"이라는 프로그램을 개설해 운영했습니다.

형아들과 함께하는 호기심과학 프로그램 보러가기

매주 토요일 노원평생학습관에서, 친구들과, 어린 친구들에게 학교에서 배운 과학 이론을 가르치고, 이를 실습할 수 있는 프로그램을 운영하면서, 반년여동안 472명의 수강생들이 생겼었습니다. 어린친구들이 물로켓을 쏘면서, 로켓과학자가 되고 싶다고 말해준 말이 오래 기억에 남는데, 함께 했던 친구들 모두, 큰 보람을 느꼈었습니다.

그러면서, 이를 더 크게, 더 많은 사람들과 함께 하고픈 마음에, 재능나눔허브라는 아이디어로 기획해, "소셜벤처경연대회"를 출전하게 되었고, 전국대회에서, 우수상을 수상하는 좋은 성과를 거두었습니다. 실제로, 서비스도 만들어서, 배포해 운영해보는것도 제안받았지만, 조금 더, 공부해서, 대학에 진학해 도전해보기로 2보전진을 위한 1보 후퇴를 했습니다.

대회에 출전하며, 정말 사회적기업을 운영하시는 분들을 만나뵈며, 조직과 자본으로, 더 많은 사람들을 도울 수 있고, 더 많은 사회적가치를 창출할 수 있음을 배울 수 있었습니다. 대회 프로그램에서, 창업과 관련된 교육도 받으며, 점점 창업과 사업, 조직운영 등에 대해 관심을 가질 수 있었습니다.

드디어 대학교 진학, 그리고 피플의 과거

어렵사리, 대학에 진학하고, 대학생활을 즐기던 중에, 우연히 학교 커뮤니티(에브리타임)에서, 피가 부족해 7살 어린이가 피가 부족해 수술이 지연되고 있다는 글을 접하게 되었습니다. 평소 헌혈에 대해 무관심하기도 했고, 21세기 대한민국에 피가 부족해서 직접 헌혈자를 구해야한다고? 하는 의아함에 관련해 조사를 해보기로 했습니다.

무작정 대한적십자사 혈액관리본부, 보건복지부 등에 전화해서 헌혈과 관련해 궁금한 점들을 여쭤보고, 수많은 헌혈자분들, 환자분들을 만나뵈었습니다. 피가 부족한 문제는 생각보다, 심각한 문제였고, 아직 수면위에 올라오지 않은 일임을 깨닫게 되었습니다.

그래서, 학교에서 배운 간단한 지식들로, 환자들에게 도움이 되면 좋겠다는 생각에, 피플의 전신인 "Blation"를 만들게 되었습니다. (Blood + Donation)

처음 기획은, 헌혈증 월렛을 제공해, 헌혈증을 온라인상에 저장하고, 필요하다는 글에, 기부나 전송할 수 있는 아이디에이션 이었습니다. 하지만, 헌혈증을 전자화 하는 것은 현재까지도 법제화 되지 않아, 당시에도 실현 불가능한 아이디어 였습니다. 또, 더 많은 환자들을 만나면서, 환자들이 헌혈증을 구하는 것이 아닌, 정말 "피(Blood)"를 구하는 것을 알게 되었습니다. 헌혈증은, 병원에서 혈액값을 공제해주는 용도이고, 혈액을 우선적으로 공급받거나 하는 권리증이 아니었습니다. 이에, 아이디어를 조금 더 보태어, 사람들의 사연을 보고, 헌혈을 선택해서 할 수 있는, "지정헌혈"을 이용한 플랫폼 서비스를 기획하게 되었습니다.

아이디어 기획서

2019년 10월 첫 출시 이후 실제 모습

지정헌혈플랫폼을 운영하면서, 정말 많은 사람들이 도움을 요청했습니다. 이에 이를 사업화하는 것에 고민을 많이 했었고, 여러 투자사님들께 조언도 구하며, 플랫폼화하는 방향으로 도전해보고자 했습니다. 하지만, 주변 어른들의 솔직한 조언으로, 잠시 서비스를 접은 채로 군대를 다녀와서, 더 크게 성장하라는 말씀에, 대한민국 해군 666기로 만기전역을 하게 되었습니다.

군대에 있으면서, 비록 서비스는 잠정중단했지만, 여전히 많은 환자분들께서 도움을 청하셨기에, https://open.kakao.com/o/gOg74umb 피플 오픈카카오톡방은 남겨두었습니다. 기존 피플 회원분들끼리 오픈카톡방에서 나름대로의 규칙을 만들어, 만남도 가지시고, 환자도 돕고, 헌혈도 같이 하는 모습을 보며, 전역후에 이를 다시 살려야겠다는 다짐을 하게 되었습니다.

피플의 현재

짧지도, 길지도 않은 2년후, 새로운 팀원분들과, 피플 정식버전을 오픈하게 되었고, 여전히 정말 많은 환자분들께서 도움을 요청하시고, 정말 많은 헌혈자분들께서 도움을 주시는 모습을 보며, 피플이 선한영향력을 만들어가는 대표적인 플랫폼이 되길 간절한 마음으로 만들어가고 있습니다.

피플 웹사이트

피플 앱 다운로드

특히 최근에는, 국회에서 진행한 "지정헌혈토론회"에 참석해, 지정헌혈이 헌혈부족이, 궁극적인 문제의 해결이 아님을 배우고, 헌혈자들간 소통을 나눌 수 있는 커뮤니티로 나아가고자, 피플 웹,앱에 커뮤니티를 개설해 운영해가고 있습니다! 많은 분들이 헌혈인증을 해주시고, 응원댓글을 달아주시고 계신데, 더 많은 분들과 함께 더 큰 선한영향력을 만들어가고 싶습니다.

온라인 뿐만 아니라, 오프라인에서도, 헌혈자분들과 함께하는 행사도 만들며, 피플이, 온오프라인상에서 헌혈자들간 교류하며, 소통할 수 있는 커뮤니티로 성장하고자 팀원들과 함께 고민하고, 기획하고, 만들어가고 있습니다.

피플의 미래

피플은, 의료기관에서 조차 피가 부족해 고통받는 환자분들께 도움이 되고자 시작했습니다. 처음의 이러한 마음을 잊지 않고, 피플은, 우리 사회에 정말 어려운 사람들에게 희망과 도움이 되는 플랫폼으로 성장해나가고 싶습니다. 헌혈로 시작했지만, 헌혈뿐만 아니라, 봉사, 재능나눔 등, 우리 사회에 선한영향력을 만들어 갈 수 있는 모든 걸 담을 수 있는 진정한, "피플"이 되고자 합니다.

최근에 진행한 첫 헌혈의 밤(헌혈자 오프라인 행사)에서, 헌혈자분들께서, 오프라인활동을 즐겨함을 느낄 수 있었고, 이에 한달에 한번 봉사도 다니는 프로그램등을 기획하고 있습니다. 피플 봉사단을 만들어 운영하고자 하는데요, 사회에 선한영향력 꼭 만들어가겠습니다.

여러분들과 함께 하고 싶습니다! 피플의 따듯한 여정에 함께 해주세요!

긴 글 읽어주셔서 감사합니다! 고맙습니다!

오늘도 즐겁고 행복한 하루 보내세요 :)

#피플 #헌혈 #지정헌혈 #헌혈플랫폼 #헌혈서비스 #대한적십자사 #한마음혈액원 #봉사

안녕하세요. 피플 개발자 김지상 입니다. 피플 개발 블로그를 통해 개발이야기를 소개하게 되어 반갑고 뜻 깊은 것 같습니다.

현재 개발자는 4명으로 백엔드, 프론트엔드 그리고 데브옵스까지… 아직 부족하고 서툴지만 항상 배우는 자세로 서비스를 만들고 있습니다.

지난 여름 v2.0을 준비하고 런칭하면서, 앱 뿐만 아니라 내부적으로 코드 리뷰와 협업하는 방법을 도입하게 되었는데요.

처음에는 많이 불편하기도 하고, 리뷰 없이 머지가 되거나 저장소에 바로 커밋이 올라가는 등 실수도 많았습니다 😭

그럼에도 불구하고, 코드리뷰를 통한 피플 개발자는 소득이 분명 있었습니다, 단순한 오타 정정을 넘어, 로직을 추가하거나 제외시켜야 하는 이유를 같이 공유 할 수 있었고, 스쿼시머지 기능을 이용해 히스토리를 좀 더 일목요연하게 볼 수 있었습니다.

최근에 플러터 디자인 수정 관련하여 PR 과 함께 리뷰를 진행 했었습니다. 리뷰는 개발 이외에도 디자인 또는 기획 등 유관 멤버들과도 확인과 합의 과정을 기록하는 목적으로도 사용하고 있는데요, 한번 더 확인을 위해 코멘트를 남기고 놓쳤던 부분은 없는지 더블 체크 과정도 가능 했습니다. 지금은 피그마 링크를 넣고 있지만, 앞으로는 좀 더 효율적이고 즉시 확인 가능한 프로세스를 생각하고 있습니다.

코드 리뷰는 리뷰어가 많을 수록 더욱 효과를 발휘하는 것 같습니다. 플러터 코드 리뷰는 백엔드 개발자 분도 같이 리뷰를 참여하고 있는데요, 그 덕분에 백엔드 내용을 정확히 전달은 물론 히스토리도 함께 공유한다는 점은 일석이조!

여러분들의 코드 리뷰는 어떠신가요? 당장은 불편하지만, 익숙해지면 적어도 팀프로젝트에서 꼭 필요한 과정이라고 생각하는데요. 피플 개발자는 코드리뷰를 장려하고 있습니다.

그럼 다음에는 또 다른 개발이야기를 갖고 돌아오겠습니다. 감사합니다 ❤️