IT뉴스 스크랩

Firebase

• 구글이 소유하고 있는 모바일 애플리케이션 개발 플랫폼
• 앱을 개발, 개선, 키워갈 수 있는 도구 모음
• 서비스가 클라우드에 호스팅되면 분석/인증/데이터베이스/구성설정/파일저장/푸시메시지 등으로 앱의 규모를 키울 수 있음
• firebase가 제공하는 client SDK가 직접 백엔드 구성요소들과 직접 상호작용함. 이는 앱과 서버 사이에 미들웨어 구축할 필요 없이 클라이언트에서 백엔드 쪽의 작업을 건너뛰고 client 단말로 넘길 수 있음. -> 파이어베이스의 콘솔 창을 통해서 수행함
• 서비스로서의 플랫폼 PaaS, 서비스로서의 백엔드 SaaS라고도 불림.

—

앱 개발하기: “내장 기관”을 만드는 것

1. 인증: 사용자 로그인 ID 및 관리
2. 클라우드 함수: 서버 없이 이벤트 위주로 동작하는 이벤트
3. 클라우드 파이어스토어: 클라우드에 호스팅 된 실시간의 nosql 데이터베이스
4. 클라우드 스토리지: 거대하게 확장할 수 있는 파일 스토리지
5. 파이어베이스 호스팅: 전 세계를 대상으로 한 웹 호스팅
6. 머신러닝 키트: 일반적인 머신러닝 작업을 위한 SDK
7. 실시간 데이터베이스: 클라우드에 호스팅 된 실시간의 nosql 데이터베이스

SI 프로젝트의 문서는 왜 만들까?

📝 핵심 요약: “코딩보다 더 중요한 것은 ‘무엇을 만들지’ 정의하는 것”

1. 개발 프로젝트의 시간은 어디에 쓰이는가? (CERN 연구 인용)

개발자가 코드를 치는 시간은 생각보다 적습니다. 전체 프로젝트 시간 중:

• 업무 파악 및 요구사항 분석: 51% (업무 파악 27% + 분석 24%)
• 설계: 18%
• 구현(코딩): 18%
• 테스트: 13%
• 재작업(Rework): 전체의 33%가 “잘못 만들어서 다시 만드는 시간”입니다.

💡 Insight: AI(Copilot, GPT 등)가 도와줄 수 있는 영역은 ‘구현’과 ‘테스트’ 뿐

전체 업무의 약 70%에 달하는 ‘업무 파악’과 ‘설계’는 여전히 인간의 몫이며, 여기서 오판하면 재작업 비용이 급증합니다.

2. 문서의 진짜 목적: “보이지 않는 것을 보이게 만드는 것”

소프트웨어 개발은 건물을 짓는 것과 달리 결과물이 눈에 보이지 않습니다. 다 만들어 놓고 “이게 아닌데요?”라는 말을 듣는 순간, 프로젝트는 실패로 향합니다. 문서는 머릿속에 있는 추상적인 생각(요구사항)을 시각화(텍스트, 도표)하여, 코드를 짜기 전에 “이게 맞나요?”라고 검증하기 위해 존재합니다.

3. SI 프로젝트의 현실적인 문제점 (Dead Documents)

문제: 문서를 만들어도 아무도 안 봅니다. 고객도, 동료 개발자도 “문서 볼 시간에 그냥 말로 물어보는 게 빠르다”고 생각합니다.

결과: 검증되지 않은 문서는 ‘쓰레기 데이터’가 되고, 결국 나중에 코드를 다 뜯어고치는 재작업으로 이어집니다.

악순환: 시간이 없어서 문서를 대충 만듦 → 신뢰도 하락 → 안 봄 → 구전(입)으로 개발 → 히스토리 증발 → 유지보수 헬(Hell).

SI 프로젝트/ 대규모 개발에서 알아야 할 구성도 정리

소프트웨어라는 추상적인 존재를 하드웨어, 논리적 연결, 코드 구조, 데이터라는 서로 다른 4가지 관점(View)에서 시각화한 지도

1. 물리적 시스템 구성도 (Physical Architecture)

“내 코드가 실제로 돌아가는 ‘땅’과 ‘건물’은 어디인가?”

소프트웨어가 설치되고 실행될 하드웨어(서버)와 네트워크 인프라를 그린 도면입니다. 보통 TA(Technical Architect)나 인프라 담당자가 작성하지만, 개발자도 내 코드가 어디서 병목을 일으킬지 알기 위해 반드시 이해해야 합니다.

주요 포함 내용:

• 서버 구성: WEB 서버(정적 처리), WAS(동적 처리/애플리케이션), DB 서버의 분리.
• 네트워크 장비: L4 스위치(로드밸런싱), 방화벽(Firewall), VPN.
• 이중화(HA): 서버가 죽었을 때를 대비해 Active-Standby로 구성되어 있는지.
• 클라우드/온프레미: AWS/Azure의 존(Zone) 구분이나 내부 망 구성.

개발자 포인트: “내 API가 느리다면 코드 문제인가, 아니면 L4 스위치 설정 문제인가?”, “파일 업로드 경로는 NAS인가 S3인가?”를 판단할 때 이 지도를 봅니다.

2. 시스템 구성도 (System Architecture)

“전체 시스템의 ‘큰 그림’은 어떻게 생겼는가?”

하드웨어가 아닌, 기능 단위(논리적 단위)의 시스템들이 서로 어떻게 연결되는지를 보여줍니다. 프로젝트의 범위(Scope)를 한눈에 파악하기 가장 좋은 문서입니다.

주요 포함 내용:

• 내부 시스템: 인사 시스템, 회계 시스템, 쇼핑몰 모듈 등 주요 모듈.
• 외부 인터페이스(EAI/FEP): 결제 대행사(PG), 문자 발송 업체, 공공 데이터 포털 등 우리 시스템과 통신하는 외부 존재들.
• 사용자 채널: PC 웹, 모바일 앱, 관리자(Admin), 키오스크 등 접속 경로.

개발자 포인트: “내가 개발하는 ‘주문 모듈’은 ‘재고 시스템’과 데이터를 주고받아야 하고, ‘PG사’와 통신해야 하는구나”를 파악하여 인터페이스 개발 목록을 식별합니다.

3. 애플리케이션 구성도 (Application Architecture)

“코드를 어떤 구조와 기술로 짤 것인가?”

개발자가 가장 많이 참고해야 할 소프트웨어 설계도입니다. 흔히 말하는 ‘Tech Stack’과 ‘Layer 구조’가 여기에 정의됩니다. AA(Application Architect)가 주로 설계합니다.

주요 포함 내용:

• 계층 구조(Layer): Presentation(화면) - Business(로직) - Data Access(DB접근) 계층의 분리.
• 기술 스택: 프레임워크(Spring Boot, React, Vue), 라이브러리(JPA, Mybatis), 언어 버전(Java 17, Python 3.9).
• 공통 모듈: 로깅, 보안, 인증(SSO), 예외 처리 등 모든 개발자가 공통으로 써야 할 기능.

개발자 포인트: “아, 이 프로젝트는 Controller에서 바로 DB를 부르면 안 되고 Service를 거쳐야 하는구나”, “로그는 Log4j2를 써야 하는구나” 같은 개발 표준(Rule)을 익히는 기준이 됩니다.

4. 데이터 구성도 (Data Architecture)

“데이터는 어떻게 저장되고 흐르는가?”

시스템의 혈액인 데이터의 구조와 흐름을 정의합니다. DA(Data Architect)가 작성하며, 흔히 보는 ERD(Entity Relationship Diagram)가 핵심 산출물입니다.

주요 포함 내용:

• ERD (논리/물리): 테이블 간의 관계(1:1, 1:N), 키(PK/FK), 데이터 타입.
• 데이터 흐름도: 원천 데이터가 어떤 배치(Batch) 작업을 통해 집계 테이블로 이동하는지(ETL).
• DB 종류: RDBMS(Oracle, MySQL)와 NoSQL(Redis, MongoDB)의 사용처 구분.

개발자 포인트: “회원 테이블과 주문 테이블은 user_id로 연결되어 있구나”, “이 컬럼은 Not Null이니까 코드에서 반드시 유효성 검사를 해야겠네”와 같이 쿼리 작성과 데이터 검증 로직의 근거가 됩니다.

참고 사이트 https://yozm.wishket.com/magazine/detail/522/ https://yozm.wishket.com/magazine/detail/523/ https://yozm.wishket.com/magazine/detail/2971/