신청했던 제 1회 PyAI 심포지움 연사로 좋은 기회가 되어 세션을 맡게 되었다. MLOps 플랫폼을 개발하며 느꼈던 생각들과 경험들이 공유하고자 하였고, 조금 더 유쾌하게 풀어보고자 하여 세션명부터 장난끼 가득하도록 지었다.

제목은 "고등학생인 내가 MLOps라니 무리무리!! (무리가 아니었다?!)" 처음 하게 된 발표이기도 하고, 대단하신 분들도 많을 거 같아 내가 감히 발표를 할 수 있을지 많이 떨려 지원을 고민했지만 좋은 경험으로 삼고자 지원했다.

발표한 내용을 짧게 소개하자면, k8s 기반으로 FastAPI를 사용해서 개발한 MLOps 플랫폼 개발 경험 공유로,

• FastAPI + Pydantic 기반 Restful API를 설계하며 느낀 타입 안정성과 데이터 유효성
• MLFlow로 k8s 내 학습 재현하기
• PyTorch와 Tensorflow로 CNN부터 구현하기
• LLMOps 파이프라인 구축하기

총 4가지 주제를 전달하고자 하였다.

빠르게 Keynote로 발표 자료를 만들고, 대본을 짜는 데 총 하루밖에 안 걸렸다. 하지만 준비할 시간이 많지 않았고 대본도 다 못 외운 채로 발표를 시작하게 되어 땀이 줄줄 나는 걸 느낄 수 있었다.

그렇지만 많은 분들이 주의 깊게 들어주셨고, 운영진 분들도 열심히 잘 챙겨주셔서 좋은 기억으로 남았다.

특히 발표에 대한 질문을 해주시는 게 내 발표를 열심히 들어주신 거 같아 너무나도 감사했다.

뒷풀이로 치킨집으로 이동하여 운영진분들과 식사를 하였는데, 그곳에서도 즐거운 대화를 나눌 수 있었다.

좋은 경험이었고 더욱 성장하여 더 많은 자리에서 발표를 하고 싶다.

문제 링크 난이도 : Lv. 3 카테고리 : String, Date

중고 거래 게시물을 3건 이상 등록한 사용자의 사용자 ID, 닉네임, 전체주소, 전화번호를 조회하는 SQL문을 작성해야 한다. 이때, 전체 주소는 시, 도로명 주소, 상세 주소가 함께 출력하고, 전화번호의 경우 xxx-xxxx-xxxx 같은 형태로 하이픈 문자열(-)을 삽입하여 출력해야 하며 회원 ID를 기준으로 내림차순 정렬한다.

SELECT 
U.USER_ID, U.NICKNAME, U.CITY || ' ' || U.STREET_ADDRESS1 || ' ' || U.STREET_ADDRESS2 as 전체주소,
REGEXP_REPLACE(U.TLNO, '(.{3})(.+)(.{4})', '\1-\2-\3') 전화번호 
FROM USED_GOODS_USER U,
(SELECT B.WRITER_ID FROM USED_GOODS_BOARD B GROUP BY B.WRITER_ID HAVING COUNT(B.WRITER_ID) >= 3) NEW_B
WHERE U.USER_ID = NEW_B.WRITER_ID
ORDER BY U.USER_ID DESC

REGEXP_REPLACE 함수를 사용해 전화번호를 정규화하였다. Group By와 Having 절을 사용해 USED_GOODS_BOARD 에서 WRITER_ID를 그룹화하여 COUNT한 컬럼의 값이 3 이상인 테이블을 SUBQUERY 로 조회하였고, 만들어진 테이블을 USED_GOODS_USER 테이블과 JOIN하고 USER_ID 기준으로 내림차순 정렬하였다.

문제 링크 난이도 : Lv. 2 카테고리 : String, Date

해당 문제는 중고거래 게시물의 게시글 ID, 작성자 ID, 게시글 제목, 가격, 거래상태를 조회하는 문제이다. 단, 2022년 10월 5일 에 작성된 게시글만 조회한다.

문제의 조건에 맞도록 DECODE 함수를 사용해 거래상태가 SALE 이면 판매중, RESERVED이면 예약중, DONE이면 거래완료 분류하여 출력하고, 게시글 ID를 기준으로 내림차순 정렬하도록 쿼리를 작성했다.

SELECT BOARD_ID, WRITER_ID, TITLE, PRICE, DECODE(STATUS,'SALE','판매중','RESERVED','예약중','DONE','거래완료') STATUS FROM USED_GOODS_BOARD
WHERE TO_CHAR(CREATED_DATE, 'YYYY-MM-DD') LIKE '2022-10-05' ORDER BY BOARD_ID DESC

문제 링크 난이도 : Lv. 1 카테고리 : SELECT

해당 문제는 22년 10월에 작성된 글, 댓글 작성일 기준 오름차 정렬, 댓글 작성일이 같다면 제목 기준 오름차 정렬 라는 조건을 만족하며 게시글 제목, 게시글 ID, 댓글 ID, 댓글 작성자 ID, 댓글 내용, 댓글 작성일을 검색하는 문제이다.

TO_CHAR 을 통해 Date 형식을 Format 하였고, BOARD_ID 기준으로 Join 하여 Where 절에서 조건에 맞추어 쿼리를 작성하였다.

SELECT B.TITLE TITLE, B.BOARD_ID BOARD_ID, R.REPLY_ID REPLY_ID, R.WRITER_ID WRITER_ID, R.CONTENTS CONTENTS, TO_CHAR(R.CREATED_DATE, 'YYYY-MM-DD') CREATED_DATE
FROM USED_GOODS_BOARD B, USED_GOODS_REPLY R
WHERE B.BOARD_ID = R.BOARD_ID and TO_CHAR(B.CREATED_DATE, 'YYYY-MM') LIKE '2022-10%' ORDER BY R.CREATED_DATE, B.TITLE

사용성 테스트 계획하기

사용자 인터페이스 ( User Interface , UI )

사용자 인터페이스 는 사용자와 시스템 간의 상호작용이 원활하게 이뤄지도록 도와주는 장치나 소프트웨어를 의미한다

인터페이스의 종류

• 하드웨어 인터페이스
• 소프트웨어 인터페이스
• 사용자 인터페이스

UI ( User Interface ) / UX ( User Experience )

UI : 사람들이 제품과 상호작용할 때 무엇을 사용하는가? ( 기술적인 것 ) UX : 사람들이 제품을 사용할 때 무엇을 느끼는가? ( 감성적인 것 )

사용자 인터페이스의 세가지 분야

1. ** 정보 제공과 전달 ** 을 위한 물리적 제어에 관한 분야
2. 콘텐츠의 ** 상세적인 표현, 전체적인 구성 ** 에 관한 분야
3. 모든 사용자가 ** 편리하고 간편하게 사용 ** 하도록 하는 기능에 관한 분야

사용자 인터페이스의 구분

• CLI ( Command Line Interface ) : 명령과 출력이 텍스트 형태로 이뤄지는 인터페이스
• GUI ( Graphical User Interface ) : 아이콘이나 메뉴를 마우스로 선택하여 작업을 수행하도록 하는 그래픽 환경의 인터페이스
• NUI ( Natural User Interface ) : 사용자의 말이나 행동으로 기기를 조작하는 인터페이스
• OUI ( Organic User Interface ) : 자연 그대로의 상태 특성을 반영한 장치 제어 인터페이스

사용자 인터페이스의 발전 과정

CLI 와 GUI 비교

사용자 인터페이스의 기본 원칙

UI 테스트 ( 사용성 테스트, Usability Test )

** 사용성 ** : 사용자와 컴퓨터 사이에 발생하는 어떠한 행위에 대하여 사용자가 쉽게 배우고 사용할 수 있으며, 향후 다시 사용하고 싶은 정도를 나타냄

UI 테스트 : 시스템에 구현된 UI를 일반 사용자가 사용하면서 ** 문제점이나 개선점을 도출해내는 방식의 테스트 **

사용성 테스트의 목적

• 제품의 완성도, 효율성 등을 확인하고, 향상시키기 위해 수행
• 요구사항의 반영 여부를 점검
• 새로운 요구사항을 소프트웨어 구현 과정에 반영

사용성 테스트 기법 선정

휴리스틱 평가 ( Heuristic evaluation )

• 최소 3명 이상의 디자인 전문가가 ** 사전에 작성한 원칙에 따라 제품을 평가 ** 하는 기법
• ** 전문가의 능력 ** 에 따라 ** 평가 시간이나 수준 ** 이 달라짐
• ** UI 구현 정도에 관계없이 평가가 가능함 **

페이퍼 프로토타입 ( Paper Prototype )

• 종이나 ** 해당 서비스를 간단하게 만들어 실제 구현되는 경험을 표현** 하고, 이를 이용하여 테스트하는 평가 방법
• 프로토타입 작성 시 포함되어야 할 ** 중요사항을 체크리스트 ** 로 작성함
• 프로토타입의 가장 빠른 방법으로 ** 제품의 전반적인 컨셉과 흐름 ** 을 잘 보여줌

선호도 ( Preference ) 평가

• "A보다 B가 더 좋다" 와 같은 선호도에 따른 영향을 주는 속성을 파악하여 예측하기 위한 기법

성능 ( Performance ) 평가

• 개발의 마지막 단계에서 제품의 학습성, 효율성, 기억 용이성, 오류, 만족도에 대한 평가

1. 학습성 : 쉽게 학습할 수 있는가?
2. 효율성 : 일단 학습하면 매번 신속하게 사용할 수 있는가?
3. 기억용이성 : 사용한 기능을 능숙하게 다시 수행할 수 있는가?
4. 오류 : 오류가 적고, 사용자가 상황을 쉽게 극복할 수 있는가?
5. 만족도 : 사용하는 것이 즐겁고 만족스러운가?

테스트 환경 구축

사용자 테스트 기법 선정하기 수행 절차

1.** UI 테스트 인식 공유** : UI 테스트의 목적, 필요성, 중요성에 대해서 이해 관계자들 간 인식 공유 2. UI 테스트 내용 파악 : 테스트 대상의 계획, 요구분석, 콘셉트 기획 등 단계별 세부내용 파악 3. UI 테스트 기법 이해 : 다양한 UI 테스트 기법에 대한 조사 및 이해 4. UI 테스트 기법 선정 : 구현된 UI를 테스트하기에 가장 적절한 기법을 선정

테스트 환경 구축 수행 절차

1. ** 테스트 목표 설정 **
   1. 구현된 UI의 사용성 테스트의 주요 과제와 목표를 설정하고, 테스트 환경 구축의 필요성 및 중요성에 대해서 인식을 공유하고, 중요 테스트 항목을 정리
2. ** 테스트 항목 정의 **
   1. 구현된 UI의 사용성 테스트에 대해서 일반적으로 검증해야 하는 주요 항목 검증과 테스트 환경 구축 시 고려해야 할 사항에 대해서 정리
3. ** 테스트 참여자 확보 **
   1. 구현된 UI의 사용성 테스트에 참여할 테스트 참여자를 확보
4. ** 테스트 룸 설정 **
   1. 사용성 테스트를 실시하기 위한 물품 준비할 때 고려해야 할 사항을 정리
5. ** 테스트 환경 설정 **
   1. 사용성 테스트 실시 시 사용하는 서류, 장비 및 비품 등을 준비
   2. UI 사용성 테스트를 위한 장비 및 비품 등을 준비하기 위해 체크 리스트를 작성
6. ** 테스트 인원 구성 **
   1. 구현된 UI의 사용성 검증을 위한 사용성 테스트 진행 인원을 구성
   2. 사용성 테스트에 참여하여 테스트를 진행하는 인원 선정 기준, 운영 기준을 마련
   3. 테스트 진행자, 기록 담당자, 시간 기록 담당자, 비디오 녹화 담당자, 테스트 관찰자 선정

사용성 테스트 절차

1. 계획과 준비
   • 테스트 목표의 설정
   • 테스크의 작성
   • 테스트 참여자 확보
   • 테스트 장비/재료 준비
   • 테스트 룸의 환경 설정
2. 테스트
   • 테스트 목적 설명
   • 테스크 방법의 설정
   • 테스트 ( 테스크 ) 실시
   • 테스트 참여자 질문
   • 설문조사 실시
3. 분석
   • 테스트 결과의 분석
   • 개선 제안서의 제출

사용성 테스트 계획서의 구성안

1. 사용성 테스트 개요
   • 사용성 테스트에 대한 개요에 대해서 작성함
2. 사용성 테스트 목적
   • 과제에 포함되어야 하는 주요 이슈를 정리하여 작성함
3. 사용자 프로파일
   • 어떠한 사용자를 사용성 테스트에 참여시킬지에 대해서 작성함
4. 사용성 테스트 디자인
   • 사용성 테스트를 어떻게 실시할 것인지에 대한 방법론을 작성함
5. 사용성 테스트 진행 순서
   • 오리엔테이션 => 배경 => 과제 시작 => 테스트 체험 설문조사 => 참가자 면담
6. 결과 요약
   • 어떻게 결과를 취합할 것인지, 어떠한 결과 데이터를 수집할 것인지 기술
7. 개선안 보고
   • 개선안을 무엇을 기초로 작성할 것인지, 어떠한 내용들을 포함할 것인지 기술

사용성 테스트 계획서 주요 항목

사용성 테스트 수행하기

사용성 테스트 수행

사용성 테스트 기법 선정 수행 절차

1. 파일럿 테스트 실시 파일럿 테스트 수행 절차 마련 파일럿 테스트 통한, 실제 테스트 소요시간 예측 문제점 파악 및 유형별 정리, 이해 관계자 공유

2. 사용자 프로필 정의 사용성 테스트 위한, 사용자 프로필의 기준 정의 사용성 테스트 참여 후보자 선정을 위한 인터뷰

3. 사용성 테스트 환경 점검 사용성 테스트 진행 인력의 구성 점검 사용성 테스트에 필요한 장비 및 비품 점검 사용성 테스트에 참여자의 인텨뷰

4. 사용성 테스트 설명 사용성 테스트의 취지, 목적에 대한 설명 사용성 테스트의 일생과 방법에 대한 설명

5. 사용성 테스트 수행 테스트 과제의 순차적 실시 테스트 중 문제점 및 이슈사항 기록 테스트 참여자에 상세 내용 인터뷰 테스트 참여자의 질의응답 테스트 결과 보고 작성

평가 분석서 작성 및 이슈 도출

사용성 평가 분석서

• 사용성 테스트의 결과 데이터를 취합하고 분석하여 문서화한 것
• 분석된 데이터는 가이드 자료로 활용하거나, UI의 수정, 보완 등의 향후 적용 계획에 반영
• 사용성 평가 분석서로 인해 변경된 설계가 UI 테스트에 적용되어야 함
• 사용성 평가 분석서에 사용되는 분석 기법

사용성 평가 분석서에 사용되는 분석 기법

사용성 평가 분석서 작성하기 수행 절차

테스트 결과 보고하기

UI 개선방안 및 수정계획 수립

테스트 결과 보고

사용성 및 UI 테스트를 통해 도출된 결과에 대해 개선 방안을 마련하고 이를 토대로 수정 계획을 수립하여 수행한 후 작성된 결과 보고서를 관련 부서와 공유하기까지의 과정을 의미

UI 개선 방안 수립하기 수행 절차

1. 도출된 이슈사항의 이해 도출된 이슈사항이 발생한 근본적인 원인에 대해서 파악하고, 관련 자료들을 확보하여 정리

   • 사용성 테스트를 수행하는 과정에서 도출된 이슈사항의 원인에 대해서 분석
   • 이슈사항이 단기적으로 해결이 가능한 것인지 장기적인 시간이 소요되는 문제인지 파악하고 해결을 위한 방안을 수립

   도출된 이슈사항들 사이에 밀접한 연관성이 존재하는지에 대한 여부를 우선적으로 파악하여 정리

2. 개선 방안 수립 준비 UI 개선 방안을 수립하게 된 배경 및 목적에 대해서 정의

   • 수립 배경 : 사용성 테스트를 통해 도출된 사용자들의 UI 관련 이슈사항을 분석하여, 사용자에게 보다 나은 UI를 제공하기 위해

   • 수립 목적 : 보완사항은 보완하고, 필요없는 사항은 삭제하고, 추가로 필요한 항목은 추가하는 등의 UI 수정 계획의 기반 자료로 활용하기 위해

     UI 개선 방안 수립을 위해, 사내외의 UI 관련 전문성과 경험이 있는 인원을 구성

3. 개선 방안 수립

4. 수정 계획 수립

UI 개선 결과 보고서 공유

• 애플리케이션 테스트 수행하기

• 테스트 수행
  • 애플리케이션 테스트의 기본 원리
  • 애플리케이션 테스트의 개념
  • 테스트의 개요
    • 단위 테스트
    • 통합 테스트
    • 시스템 테스트
    • 인수 테스트
  • 테스트 기반에 따른 테스트 종류
  • 테스트 자동화 도구
    • 배경
    • 테스트 자동화의 개념
    • 테스트 도구의 장점
    • 테스트 도구의 단점
    • 테스트 자동화 수행 시 고려사항
    • 테스트 도구 평가방법 및 요소
    • 테스트 단계를 지원하는 도구의 종류
    • 테스트 수행 절차
• 결함 관리
  • 결함의 정의
  • 결함 관리 프로세스
    • 1. 결함 관리 계획
    • 2. 결함 기록
    • 3. 결함 검토
    • 4. 결함 수정
    • 5. 결함 재확인
    • 6. 결함 상태 추적 및 모니터링 활동
    • 7. 최종 결함 분석 및 보고서 작성
  • 결함의 상태 및 추적
    • 1. 결함 등록 (Open)
    • 2. 결함 검토 (Reviewed)
    • 3. 결함 할당 (Assigned)
    • 4. 결함 수정 (Resolved)
    • 5. 결함 조치 보류 (Deferred)
      • 6. 결함 종료 (Closed)
      • 7. 결함 해제 (Clarified)
  • 결함 분류
    • 시스템 결함
      • 비정상적인 종료/중단
      • 응답 시간 지연
      • 데이터베이스 에러
    • 기능 결함
      • 요구사항 미반영/불일치
      • 부정확한 비즈니스 프로세스
      • 스크립트 에러
      • 타 시스템 연동 시 오류
    • GUI 결함
      • 응용 프로그램 UI 비일관성
      • 부정확한 커서/메시지
      • 데이터 타입의 표시 오류
    • 문서 결함
  • 결함 심각도
    • High
    • Medium
    • Low
  • 결함에 대한 원인과 개선 방안 도출
    • 1. 발생한 결함에 대하여 결함 원인을 분석
    • 2. 분석한 원인을 근거로 개선 방안을 도출
  • 애플리케이션 결함 조치하기
• 조치 우선순위 결정
  • 소프트웨어 테스트 기법
    • 단위 테스트 기법
    • 통합 테스트 기법
      • 1. 테스트 설계 기법
      • 2. 테스트 설계 방법
    • 시스템 테스트 기법
      • 부하 및 성능테스트
      • 장애 복구 테스트
      • 보안 테스트
    • 인수 테스트 기법
  • 결함 관리의 이해
    • 결함 관련 용어
      • 결함의 판단 기준
• 결함 조치 관리
  • 프로그램 코드 검토 기법
    • 소프트웨어 인스펙션 ( Software Inspection ) 의 개요
    • 코드 인스펙션의 프로세스와 수행 내용
    • 인스펙션과 워크스루 비교
• 형상 관리 및 구성 요소
  • 소프트웨어 형상 관리의 정의
  • 기준선과 소프트웨어 형상 항목
    • 기준선
    • 소프트웨어 형상 항목 ( SCI )
  • 형상 관리의 주요 활동
    • 형상 관리 기능
    • 형상 식별
    • 버전 관리
    • 변경 통제에 대한 업무별 활동

테스트 수행

애플리케이션 테스트의 기본 원리

1. 완벽한 테스트 불가능

2. 결함 집중 ( 파레토 법칙 ): 애플리케이션의 20% 에 전체 결함의 80% 가 집중되어 있다.

3. 살충제 패러독스 : 동일한 테스트케이스로 동일한 테스트를 반복하면 더 이상 결함이 반복되지 않는 현상

4. 테스팅 정황 의존 : 소프트웨어의 특징, 테스트 환경, 테스터의 역랑 등의 정황에 따라 테스트 결과가 달라질 수 있다.

5. 오류-부재의 궤변 : 소프트웨어의 결함을 모두 제거해도 사용자의 요구 사항을 만족시킬 수 없으면 소프트웨어의 품질이 높다고 할 수 없다.

6. 테스트와 위험은 반비례한다.

7. 테스트의 점진적 확대

8. 테스트의 별도 팀 수행

애플리케이션 테스트의 개념

• Validation : 사용자 입장 에서 개발한 소프트웨어가 고객의 요구사항에 맞게 구현되었는지를 확인하는 것
• Verification : 개발자 입장에서 개발한 소프트웨어 명세서에 맞게 만들어졌는지 점검하는 것

테스트의 개요

테스트 과정에 필요한 역할은 소프트웨어 아키텍트 와 테스트 매니저 이다.

단위 테스트

컴포넌트 또는 모듈 테스트, 개발자가 개발 과정 중 수행 테스트 가능한 단위로 작게 분리된 소프트웨어 내에서 결함을 찾고 기능을 점검하는 행동 구조적 테스트, 기능성 테스트, 리소스 관련 테스트, 강건성 테스트 등 특정 비기능성 테스트 포함 컴포넌트 명세, 소프트웨어 상세 설계, 데이터 모델 명세 등을 이용하여 테스트

통합 테스트

모듈 사이의 인터페이스, 통합된 컴포넌트 간의 상호작용을 테스트, 하나의 프로세스가 완성된 경우 부분적으로 통합 테스트 수행 컴포넌트 간 인터페이스 테스트를 하고 운영체제, 파일 시스템, 하드웨어 또는 시스템 간 인터페이스와 같은 각각 다른 부분과 상호 연동이 정상적으로 작동하는지 여부를 테스트

• 빅뱅 방식 ( Big Bang ) : 모듈을 한 번에 결합하여 수행, 소규모 프로그램이나 프로그램의 일부를 테스트하는데 적합하다.
• 상향 방식 ( Bottom up ) : 시스템 모듈의 계층 구조의 하위 모델부터 시작하여 상향 모듈로 통합하는 방법, 각각의 기능이 정밀하게 수행되는지 테스트할 때 적합하다. 드라이버가 필요
• 하향 방식 ( Top down ) : 상위 모듈부터 시작하여 점차 하위 모듈 방향으로 통합하는 방법, 모델 간의 인터페이스와 시스템의 동작이 정상적으로 동작되는지 빠르게 파악할 때 적합하다. 스텁이 필요
• 샌드위치 방식 : 상향식과 하향식의 장점을 이용하는 방식, 대규모 프로젝트에 적합, 병렬 테스트가 가능하고 시간이 절약, 스텁과 드라이버 모두 필요
• Central, Collaboration, 레이어 통합 등

스텁 ( Stub ) : 테스트 중인 모듈이 호출하는 다른 모듈을 일시적으로 대체하는 모듈 드라이버 ( Driver ) : 모듈이나 시스템을 제어하거나 호출하는 모듈을 대체하는 모듈

시스템 테스트

통합된 단위 시스템의 기능이 시스템적으로 정상적으로 수행되는지 테스트, 성능 테스트 및 장애 테스트 포함 시스템을 완벽하게 검사하기 위한 목적 또는 성능 목표를 가지고 테스트한다. 실제의 사용자 환경과 유사하게 시스템 성능, 관련된 고객의 기능, 비기능적인 요구 사항 등이 완벽하게 수행되는지 테스트

테스트 기반에 따른 테스트 종류

테스트 자동화 도구

배경

테스트의 정확성을 유지하면서 시간과 비용을 줄일 수 있는 자동화 도구가 매우 중요

테스트 자동화의 개념

사람이 하던 반복적인 테스트 절차를 자동화 도구를 활용하여 준비, 구현, 수행, 분석 등을 스크립트 형태로 구현함으로써, 시간과 인력 투입의 부담을 최소화하면서 운영 중인 시스템의 모니터링 또는 UI가 없는 서비스의 경우 정밀한 테스트가 가능하도록 하는 것

테스트 도구의 장점

1. 테스트 인력과 시간을 최소화

2. 향상된 요구사항 정의, 성능 및 스트레스 테스트, 품질 측정을 최적화

3. 빌드확인, 회귀, 다중 플랫폼 호환성, 소프트웨어 구성, 기본 테스트의 향상된 테스트 품질을 보장

   테스트 도구의 단점

4. 도입 후 테스트 도구 전문가를 양성 또는 고용이 필요, 초기 프로세스 적용에 대한 시간, 비용, 노력에 대한 추가 투자가 필요

5. 비공개 상용 소프트웨어의 경우 고가이며, 인력과 교육에 대한 유지관리 비용이 높음

   테스트 자동화 수행 시 고려사항

6. 테스트 절차를 고려하여 재사용 및 측정이 불가능한 테스트 프로그램은 제외

7. 설계기준을 고려하여 반복적인 빌드에서 스크립트 재사용성이 가능해야 한다.

8. 도구의 한계성으로 모든 수동 테스트 과정을 자동화할 수 있는 도구는 없다. 따라서 용도에 맞는 적절한 도구 사용이 필요하다.

9. 도구 환경 설정과 도구 습득 기간을 고려하여 프로젝트 지연을 방지해야 한다.

10. 테스트 엔지니어의 적절한 투입 시기와 계획을 프로젝트 초기에 수립해야 한다.

    테스트 도구 평가방법 및 요소

11. 테스트 도구 평가방법 테스트 도구가 지원하는 모든 사항에 대해 종류별로 나열하고 기록해야 한다. 또한, 테스트에 해당하는 요소에 대한 목표 또는 평균값을 설정하고 설정된 기준 으로 평가한다. 비용을 최소화하기 위해 필수적인 몇 가지 요소만을 고려해야 할 경우 최소한의 요구사항을 만족하는 도구를 선정

12. 테스트 도구 평가요소 테스트 도구의 사용 편의성, 다중 사용자 접속, 결함 추적, 도구 기능성, 보고 능력, 성능 및 스트레스 테스트, 버전 제어, 테스트 계획과 관리, 가격, 테스트 도구 제조사의 지원 능력 등의 객관적이고 수치화되는 항목을 이용하여 평가

테스트 단계를 지원하는 도구의 종류

간트차트 : 프로젝트 일정관리를 위한 바(bar)형태의 도구

테스트 수행 절차

1. 테스트 계획서 확인

1. 테스트 목적과 범위 확인.

   테스트 목적은 정보시스템 개발 중에 프로그램 기능의 정확성 및 완전성을 검증하고, 예외 상황 처리의 적절성, UI 및 개발 표준 준수 여부를 확인하여 시스템 품질을 확보하기 위함

   테스트 전략 문서: 정렬(Align)된 테스트의 목적이 상세하게 기술되어 있다. 테스트 전략 문서가 없는 경우에는 프로젝트의 품질 목표 가운데 테스트를 통해 달성 여부를 평가할 수 있는 항목을 기술하고, 그 외에 사용자 요구사항에 대한 테스트를 통해 특별히 요구되는 목적을 확인한다.

2. 테스트 실행 계획을 확인

   시작 기준과 종료 기준을 확인한다
   테스트 수행 절차를 확인한다

   
3. 테스트 케이스를 확인

   테스트 시나리오를 확인하고, 테스트 케이스를 확인

4. 테스트 케이스 데이터를 확인

5. 테스트 환경을 확인

2. 기능 단위 테스트 수행

1. 서버모듈, 화면 모듈, 데이터입출력, 인터페이스 등의 연계를 통해 업무별 기능을 정의한다.

   1. 서버 모듈 정의 : 화면 모듈과 인터페이스에서 받은 데이터를 이용하여 업무 처리를 수행한다
   2. 화면 모듈 정의 : 화면 설계서와 사용자의 요구사항에 따라 화면에서 등록, 수정, 삭제, 조회된 내용 확인
   3. 데이터 입출력 정의 : 화면 모듈, 인터페이스, 서버 모듈에서 전달받은 데이터를 가공 및 저장 등
   4. 인터페이스 : 타 시스템 인터페이스에 따른 데이터 및 엔티티 변환의 정확성 확인
2. 기능 단위 테스트를 통합하여 테스트 항목을 정의
3. 단위테스트 수행
   1. 테스트 환경 관련 사항 준비
   2. 입출력 확인
   3. 산술식 또는 단순 계산 결과 확인
   4. 연동 시스템 확인
   5. 배치처리와 인터페이스 확인
   6. 인쇄 및 보고서 확인
4. 통합테스트 수행
   1. 통합 테스트 환경 구성
   2. 테스트 실행 및 결과 기록
   3. 통합 테스트 종료 여부 평가
5. 성능 테스트 수행
   1. 성능 테스트 계획서 확인
   2. 성능 테스트 수행 후 결과 보고서 작성

결함 관리

결함의 정의

1. 프로그램과 명세서의 차이, 업무 내용 불일치
2. 기대 결과와 실제 관찰 결과 간의 차이
3. 시스템이 사용자가 기대하는 타당한 기대치를 만족시키지 못할 때 변경이 필요한 모든 것

결함 관리 프로세스

1. 결함 관리 계획

전체 프로세스에서 결함관리에 대한 일정, 인력, 업무 프로세스를 확보하여 계획을 수립한다

2. 결함 기록

테스터는 발견된 결함에 대한 정보를 결함관리 DB에 기록한다.

3. 결함 검토

등록된 결함에 있어서 주요 내용을 검토하고 결함을 수정할 개발자에게 전달한다.

4. 결함 수정

개발자는 할당된 결함의 프로그램을 수정한다.

5. 결함 재확인

테스터는 개발자가 수정한 내용을 확인하고 다시 테스트를 수행한다.

6. 결함 상태 추적 및 모니터링 활동

결함관리 팀장은 결함관리 데이터베이스를 이용하여 대시보드 또는 게시판 형태의 서비스를 제공한다.

7. 최종 결함 분석 및 보고서 작성

발견된 결함에 대한 내용과 이해관계자들의 의견이 반영된 보고서를 작성하고 결함 관리를 종료한다.

결함의 상태 및 추적

1. 결함 등록 (Open)

테스터와 QA(품질관리) 담당자에 의해 결함이 처음 발견되어 등록되었지만, 아직 분석이 되지 않은 상태

2. 결함 검토 (Reviewed)

등록된 결함을 담당 모듈 개발자, 테스터, 프로그램 리더, 품질 관리(QA) 담당자와 검토하는 상태

3. 결함 할당 (Assigned)

결함의 영향 분석 및 수정을 위해 개발자와 문제 해결 담당자에게 할당된 상태

4. 결함 수정 (Resolved)

개발자에 의해 결함의 수정이 완료된 상태

5. 결함 조치 보류 (Deferred)

수정이 필요한 결함이지만 현재 수정이 불가능해서 연기된 상태, 우선순위, 일정 등을 고려하여 재오픈을 준비하는 상태

6. 결함 종료 (Closed)

발견된 결함이 해결되고 테스터와 품질관리(QA) 담당자에 의해 종료 승인을 한 상태

7. 결함 해제 (Clarified)

테스터, 프로그램 리더, 품질관리(QA) 담당자가 결함을 검토한 결과, 결함이 아니라고 판명된 경우

결함 분류

시스템 결함

비정상적인 종료/중단, 응답시간 지연, 데이터베이스 에러 등 주로 애플리케이션 환경과 데이터베잇 처리에서 발생하는 결함

비정상적인 종료/중단

특정 기능 실행 시 응용 프로그램의 작동 정지, 종료, 시스템 다운이 되는 경우

응답 시간 지연

응용 프로그램 작동 후 조회 또는 보고서 출력 시 지연되는 경우와 메모리 부족, 하드웨어와 소프트웨어의 비일관성으로 발생되는 경우

데이터베이스 에러

응용 프로그램 작동 후 사용자 데이터의 등록, 수정, 삭제, 조회가 정상적으로 작동하는 않은 경우

기능 결함

사용자의 요구사항 미반영/불일치, 부정확한 비즈니스 프로세스, 스크립트 에러, 타 시스템 연동 시 오류 등 기획, 설계, 업무 시나리오 단계에서 발생된 결함

요구사항 미반영/불일치

요구사항에 명시된 기능이 응용 프로그램에 구현되지 않은 경우와, 다르게 구현되어 작동하는 경우

부정확한 비즈니스 프로세스

기능 자체는 수행되나 내부 프로세스 로직의 문제로 부정확한 결과를 내는 경우

스크립트 에러

특정 기능 실행 시 웹 브라우저에서 스크립트 오류가 발생하는 경우

타 시스템 연동 시 오류

기존 시스템과의 연동을 통해 데이터를 주고받는 과정에서 오류가 발생하는 경우

GUI 결함

응용 프로그램의 UI 비일관성, 부정확한 커서/메시지, 데이터 타입의 표시 오류 등으로 사용자 화면 설계에서 발생된 결함

응용 프로그램 UI 비일관성

프로젝트에서 정의한 UI 표준과 상이하게 구현된 경우

부정확한 커서/메시지

커서의 위치가 입력 대상의 첫 번재 필드에 위치해 있지 않거나, 탭 시퀀스가 순차적으로 동작하지 않는 경우, 각 기능에서 제공하는 메시지 내용이 부정확한 내용을 보여주는 경우

데이터 타입의 표시 오류

입력 필드에 지정된 형식과 다르기 입력해도 저장이 되는 경우와 입력 필드에 유효하지 않은 데이터를 입력했을 때 오류가 나는 경우

문서 결함

사용자의 온라인/오프라인 매뉴얼의 불일치, 요구사항 분석서와 기능 요구사항의 불일치로 인한 불완전한 상태의 문서의 경우

결함 심각도

High

시스템이 중단되어 더 이상 프로세스를 진행할 수 없게 만드는 결함

• 시스템 핵심 요구사항 미구현
• 시스템 다운
• 장시간 시스템 응답 지연
• 시스템 복구 후 데이터 왜곡

Medium

시스템의 흐름에 영향을 미치는 결함

• 부정확한 기능
• 부정확한 업무 프로세스
• 데이터 필드 형식의 오류
• 데이터베이스 에러
• 보안 관련 오류

Low

시스템의 흐름에는 영향을 미치지 않는 결함이나 상황에 맞지 않는 용도와 화면 구성 결함

• 부정확한 GUI 및 메시지
• 에러 시 메시지 미출력
• 화면 상의 문법 / 철자 오류

결함에 대한 원인과 개선 방안 도출

테스트 수행 시 발견된 결함에 대한 원인을 유형별로 통합하고 분류 분류된 결함에 대해 통계적 분석 기법을 적용하여 분석하고 개선 방안을 도출

1. 발생한 결함에 대하여 결함 원인을 분석

1. 테스트 종류 후 결함 데이터 통합
2. 통합된 결함 데이터를 분석하여 유사한 결함 상태로 정리
3. 프로젝트 영역별로 결함 원인을 정의

4. 결함 종류를 식별하기 위한 원인 분석 도구 사용

파레토 다이어그램

1) 결함의 모든 요소를 목록으로 작성한다. 2) 결함과 관련된 요소들을 측정한다. 3) 결함 수가 가장 높은 순에서 낮은 순으로 작성한다. 4) 결함 항목에 대한 백분율을 계산한다. 5) 자료 값을 이용하여 각 범주를 나타내는 막대를 그린다. 6) 누적 백분율을 파레토 차트에 표시한다.

피시본 다이어그램

1) 결함의 주요 원인을 확인한다. 2) 결함의 잠재적 원인을 팀원들과 브레인스토밍한다. 3) 결함의 범주를 나누고 항목에 따라 잠재적 원인을 추가한다. 4) 팀원들과 질문을 계속하여 내용을 검증하고, 추가적인 내용을 더 제시하도록 한다. 5) 결함 항목을 검토하고 항목 중에서 가장 가능성이 높은 원인을 팀원들과 브레인스토밍 등의 방법으로 도출하여 작성한다.

5. 원인 분석 보고서 작성

   2. 분석한 원인을 근거로 개선 방안을 도출

6. 프로젝트 진행에 영향을 주는 항목에 대해 결함 예방 조치 계획을 수립
7. 결함 예방 조치 수립
8. 모든 항목이 종결될 때까지 추적 관리를 수행
9. QA의 검토를 거쳐 제시된 의견을 전사 품질 관리 조직에게 전달

애플리케이션 결함 조치하기

조치 우선순위 결정

소프트웨어 테스트 기법

단위 테스트 기법

1. JUnit을 활용한 테스트

   Java 환경이라면 대부분 JUnit이라는 단위 테스트 프레임워크를 통해 단위 테스트를 할 수 있어야 한다.

2. Mock 테스트

• 단위 테스트 시 Mock 객체를 사용하여 테스트하는 기법
• 특정 기능 또는 모듈에 대한 응답 결과를 미리 정의해놓고 테스트
• 특정 모듈이나 기능이 완벽히 개발 완료되지 않은 상태에서도 진행 가능
• 테스트 더블 : 테스트 전용 객체, 테스트를 위해 실제 객체를 대신해서 사용되는 용어

  통합 테스트 기법

  주요 목적 : 전체 시스템이 통합 완료될 때까지 단위 시스템 간의 연계성 및 기능 요구사항들을 확인하고, 하드웨어와 소프트웨어 구성 요소 간의 상호 작용을 테스트하는 것

1. 테스트 설계 기법

테스트 설계 : 개발된 소프트웨어나 시스템의 요구사항, 요구사항 명세서, 업무 구조, 시스템 구조 등을 기반으로 소프트웨어의 어떤 부분을 어떻게 접근하여 테스트할지에 대한 테스트 상황과 방법을 파악하는 것 테스트 구현 : 테스트 설계를 체계적으로 구체화시켜 테스트 케이스를 도출하고 작성하는 것 테스트 설계 방법 : 테스트 상황과 방법을 구체화시키기 위한 수단 및 도구

2. 테스트 설계 방법

시스템 테스트 기법

부하 및 성능테스트

동시접속으로 시스템에 많은 요청이 발생될 때 어떻게 가동되는지 확인하는 테스트

• 동시 이용자 수 : TPS * 호출간격(응답시간(Sec)) * 대기시간(Sec)
• 동시 단말 이용자 : PC 앞에 앉아서 시스템을 이용하는 이용자
• 액티브 이용자 : 동시에 같은 서비스나 업무를 실행하고 나서 응답을 기다리고 있는 이용자
• 처리량 : 단위 시간 당 처리하는 건수, 단위는 tps, tpm, tph 를 사용하고, 관점에 따라 두 가지 유형이 있으며 요청을 받는 입장에서 단위 시간 단 요청 건수와 단위 시간당 처리 건수로 구분되어 표현한다.
• 대기 시간 : 응답을 받은 직후부터 다음 명령 또는 호출할 때까지 사용자가 대기하는 시간

장애 복구 테스트

보안 테스트

인수 테스트 기법

최종 사용자가 요구한 기능이 제대로 반영되었는지, 인수 조건에 만족하는지를 테스트하는 기법

결함 관리의 이해

결함 관련 용어

• 에러 ( Error ) : 소프트웨어 개발 또는 유지 보수 수행 중에 발생한 부정호가한 결과, 개발자의 실수로 발생한 오타, 개발 명세서의 잘못된 이해, 서브루틴의 기능 오해 등

• 오류 ( Fault ) : 프로그램 코드 상에 존재하는 것, 비정상적인 프로그램과 정상적인 프로그램 버전 간의 차이로 인하여 발생한다.

• 실패 ( Failure ) : 정상적인 프로그램과 비정상적인 프로그램의 실행 결과의 차이를 의미, 프로그램 실행 중에 프로그램 실제 실행 결과를 개발 명세서에 정의된 예상 결과와 비교함으로써 발견한다.

• 결합 ( Defect ) : 버그, 에러, 오류, 실패, 프로그램 실행에 대한 문제점, 프로그램 개선 사항 등의 전체를 포괄하는 용어

  결함의 판단 기준

• 기능 명세서에 가능하다고 명시된 동작을 수행하지 않는 경우

• 기능 명세서에 불가능하다고 명시된 동작을 수행하는 경우

• 기능 명세서에 명시되어 있지 않은 동작을 수행하는 경우

• 기능 명세서에 명시되어 있지 않지만 수행해야 할 동작을 수행하지 않는 경우

• 테스터의 시각에서 볼 때 문제가 있다고 판단되는 경우

  결함 조치 관리

  프로그램 코드 검토 기법

  소프트웨어 인스펙션 ( Software Inspection ) 의 개요

  코드 인스펙션 ( Code Inspection ) 외에도 설계 및 설계 산출물까지 포괄하여 소프트웨어 인스펙션으로 부르기도 한다.

코드 인스펙션은 매우 효과적인 테스트 방법으로서 어떠한 다른 테스트 방법으로 대체할 수 없다. 상당히 시간이 필요한 작업이며, 통계에 따르면 인스펙션을 적절히 잘 수행하면 포함된 에러의 90%까지 찾아낼 수 있다.

코드 인스펙션의 프로세스와 수행 내용

(1) 코드 인스펙션 프로세스

(2) 코드 인스펙션 테스크별 수행 내용

인스펙션과 워크스루 비교

형상 관리 및 구성 요소

소프트웨어 형상 관리의 정의

1. 소프트웨어 프로세스의 모든 출력물 정보
2. 컴퓨터 프로그램, 컴퓨터 프로그램 설명 문서, 데이터 등
3. 소프트웨어 프로세스 전반에 걸쳐 소프트웨어 형상의 변경 요인에 대해 소프트웨어 형상을 보호하는 활동

기준선과 소프트웨어 형상 항목

기준선

변경을 통제하게 도와주는 기준선은 정식으로 검토 및 합의된 명세서나 제품 개발의 바탕으로서, 정식의 변경 통제 절차를 통해서만 변경 가능하다

소프트웨어 형상 항목 ( SCI )

소프트웨어 형상과 개발 도구의 합성으로서, SCI는 개발 단계별로 기준선으로 기준으로 형상 항목을 관리한다.

형상 관리의 주요 활동

형상 관리 기능

형상 식별

소프트웨어 형상 항목에 대해 식별하고 고유한 이름을 부여하는 활동

버전 관리

변경 통제에 대한 업무별 활동

💻 브라우저의 구성 요소

1. 사용자 인터페이스 ( User Interface )
   • 사용자 인터페이스는 브라우저에서 웹 페이지를 검색하고 표시하는데 필요한 모든 요소를 포함한다.
   • 대표적인 예로는 url 표시줄, 북마크, 즐겨찾기 등이 있다. 뒤로/앞으로 가기 버튼

2. 브라우저 엔진 ( Browser Engine )
   • 브라우저 엔진은 렌더링 엔진과 사용자 인터페이스 사이의 상호작용을 처리한다.

3. 렌더링 엔진 ( Rendering Engine )
   • 랜더링 엔진은 HTML, CSS 코드를 해석하고, 페이지를 렌더링하여 화면에 표시한다.
   • 대표적인 렌더링 엔진으로는 Gecko ( 파이어 폭스 ), Webkit ( 사파리 ), Blink ( 크롬, 엣지 ) 등이 있다.

4. 통신 ( Networking )
   • 통신은 HTTP 요청 등을 통해 인터넷에서 리소스를 가져오는데 사용된다.
   • 대표적인 통신 모듈로는 XMLHttpRequest, fetch 등이 있다.

5. UI 백엔드 ( UI Backend )
   • 콤보 박스와 창 같은 기본적인 장치를 그린다.
   • 플랫폼에서 명시하지 않은 일반적인 인터페이스로, OS 사용자 인터페이스 체계를 사용한다.

6. 자바스크립트 해석기 ( JavaScript Interpreter )
   • 자바스크립트 해석기는 자바스크립트 코드를 해석하고 실행하는데 사용된다.

7. 데이터 저장소 ( Data Storage )
   • 데이터 저장소는 브라우저 내부에 데이터를 저장하거나 웹 사이트와 상호작용할 때 사용된다.
   • 로컬 스토리지 타입과 쿠키 타입으로 나눌 수 있다.

💻 브라우저 렌더링 과정

렌더링 엔진이 HTML, CSS, JavaScript로 렌더링할 때 CRP (Critical Rendering Path, 중요 렌더링 경로 ) 프로세스를 사용하며 다음 단계들로 이루어진다.

1. HTML을 파싱 후, DOM 트리를 구축한다.

2. CSS를 파싱 후, CSSOM 트리를 구축한다.

3. JavaScript를 실행한다.

   • HTML 중간에 스크립트가 있다면 HTML 파싱이 중단된다.

4. DOM과 CSSOM을 조합하여 렌더트리를 구축한다.

   • display:none 속성과 같이 화면에서 보이지 않고 공간을 차지하지 않는 것을 렌더트리로 구축되지 않는다.

5. 뷰포트 기반으로 렌더트리의 각 노드가 가지는 정확한 위치와 크기를 계산한다. ( Layout 단계 )

6. 계산한 위치 / 크기를 기반으로 화면에 그린다. ( Paint 단계 )

📕 용어 정리

1. CRP : 브라우저가 HTML, CSS, JavaScript를 화면에 픽셀로 변화하는 일련의 단계를 말한다. CRP는 DOM, CSSOM, 렌더 트리와 레이아웃을 포함한다.

2. DOM ( Document Object Model ) : 웹 페이지를 이루는 태그들을 자바스크립트가 이용할 수 있게끔 브라우저가 트리 구조로 만든 객체 모델

3. CSSOM ( CSS Object Model ) : CSS 내용을 파싱하여 자료를 구조화한 것

4. 렌더트리 ( Render Tree ) : CSSOM과 DOM 트리의 결합으로 만들어진 트리, 웹 페이지에 나타낼 각 요소들의 위치 ( Layout, 레이아웃 )을 계산하는데 사용되고 픽셀을 화면에 렌더링하는 페인트 ( Paint ) 프로세스를 위해 존재한다.

5. Layout 단계 : 뷰포트 내에서 노드의 정확한 위치와 크기를 게산하는 단계. Reflow라고도 부름

6. Paint 단계 : 렌더링 트리의 각 노드를 화면의 실제 픽셀로 변환하는 마지막 단계. 페인팅 혹은 래스터화라고 부름

그렇다면 px, em, rem, %, vw, vh는 어떤 차이가 있을까?

📏 px ( pixel )

px은 절대값을 사용하는 단위이다. 고정된 물리적 크기에 해당한다.

상대적인 단위가 아니므로 화면의 크기나 해상도에 관계없이 크기가 일정하게 유지된다.

화면의 크기나 해상도에 관계없이 동일한 크기를 유지해야 하는 요소에는 px를 사용할 수 있다.

⚠️ px 사용의 문제점

모든 브라우저는 사용자가 font-size 설정이 가능하다. 따로 font-size를 지정하지 않은 경우에는 일반적으로 16px로 표시되는데 개발자가 만약 font-size를 px로 고정하면, 사용자가 브라우저 설정에서 font-size를 변경하려고 해도 개발자가 정해둔 font-size에서 변경이 되지 않는다.

📐 em

em은 해당 단위가 사용되고 있는 요소의 font-size를 기준으로 px로 바뀌어 화면에 표시된다. 같은 엘리먼트에 설정된 포트 크기 값이 없을 경우에는 상위 요소의 폰트 사이즈가 기준이 된다.

html {
    font-size: 16px;
}

div {
    font-size: 20px;
    width: 10em;   /* 200px */
}

✏️ 중첩인 경우

<style>
  .container {
    font-size: 14px;
  }

  .container.title {
    font-size: 2em; // 28px
  }

  .container.subtitle {
    font-size: 1.5em; // 21px
  }

  .container.subtitle.leading {
    font-size: 0.5em; 
  }
</style>  

<body>
  <div class="container">
    <div class="title"></div>
    <div class="subtitle"></div>
  </div>  
</body>

leading의 글꼴의 크기는 container > subtitle 안에 있기 때문에, 14 x 1.5 x 0.5 = 10.5px이 된다

✏️ 넓이 ( width )와 높이 ( height )속성의 값은?

<style>
  .container {
    font-size: 14px;
  }

  .container.title {
    font-size: 2em; // 28px
  }

  .container.subtitle {
    font-size: 1.5em; // 21px
  }

  .container.subtitle.leading {
    font-size: 0.5em; // 10.5px
    width: 0.3em;
    height: 0.4em;
  }
</style>  

<body>
  <div class="container">
    <div class="title"></div>
    <div class="subtitle"></div>
  </div>  
</body>

width는 10.5 x 0.3 = 3.15px height는 10.5 x 0.4 = 4.2px

📐 rem

최상위 엘리먼트에서 지정된 font-size의 값을 기준으로 변환된다. HTML에서 최상위 요소는 html 태그이므로 rem의 경우, html 요소의 font-size 속성값이 기준이 된다. 별도의 font-size를 설정하지 않았을 경우에는 각 브라우저에서 기본적으로 설정된 값을 상속받는다.

html {
  font-size: 16px;
}

div {
  font-size: 20px;
  width: 10rem; /* 160px */
}

✏️ 넓이 ( width )와 높이 ( height )속성의 값은?

<style>
  .container {
    font-size: 14px;
  }

  .container.title {
    font-size: 2rem; // 28px
  }

  .container.subtitle {
    font-size: 1.5rem; // 21px
  }

  .container.subtitle.leading {
    font-size: 0.5rem; // 7px
    width: 0.3rem;
    height: 0.4rem;
  }
</style>  

<body>
  <div class="container">
    <div class="title"></div>
    <div class="subtitle"></div>
  </div>  
</body>

width는 14 x 0.3 = 4.2px height는 14 x 0.4 = 5.6px

많은 CSS 가이드들이 em을 사용해야만 하는 타당한 이유가 없는 경우라면 가급적 rem을 우선적으로 쓰도록 권고한다. em의 경우 실제 몇 px로 변환될지에 영향을 주는 변수가 많아지기 때문에 em을 사용해서 스타일된 요소의 경우 재사용이 어렵고 유지보수가 힘들어지는 경향이 있기 때문이다. 하지만 rem과 em도 용도에 맞게 적절히 혼용해서 사용할 수 있다. 어느 페이지에서든 고정된 사이즈를 사용해야 한다면 rem을, 부모 요소에 따라 유동적으로 변해야 하는 곳에는 em을 사용할 수 있다.

📐 %

상위 요소의 크기를 기반으로 하는 상대적인 측정 단위. 상위 요소의 너비가 500px이고 하위 요소의 너비가 50%로 지정된 경우 하위 요소의 너비는 250 픽셀이 된다.

📐 VW ( Viewport Width ) & VH ( Viewport Height )

VW와 VH는 각각 웹 페이지의 보이는 부분 (뷰포트) 의 너비와 높이를 기준으로 하는 상대적인 측정 단위로 1VW는 뷰포트 너비의 1%, 1VH는 뷰포트 높이의 1%에 해당한다.

@RestController

Spring Framework 4 버전부터 사용가능한 어노테이션

@Controller에 @ResponseBody가 결합된 어노테이션

컨트롤러 클래스 하위 메소드에 @ResponseBody 어노테이션을 붙이지 않아도 문자열과 JSON 등을 전송할 수 있음.

View를 거치지 않고 HTTP ResponseBody에 직접 Return 값을 보내게 됨.

Annotation ( 어노테이션, @ ) 이란 코드 사이에 주석처럼 쓰이며 특별한 기능을 수행하도록 하는 기술이다. 즉, 프로그램에게 추가적인 정보를 제공하는 메타데이터라고 할 수 있다.

@RequestMapping

MVC의 핸들러 매핑 ( Handler Mapping ) 을 위해서 DefaultAnnotationHandlerMapping을 사용.

특정 uri로 요청을 보내면 Controller에서 어떠한 방식으로 처리할지 정의를 한다. 이때 들어온 요청을 특정 메서드와 매핑하기 위해 사용하는 것이 @RequestMapping이다.

DefaultAnnotationHandlerMapping 매핑 정보로 @RequestMapping 어노테이션을 활용.

클래스와 메소드의 RequestMapping을 통해 URL을 매핑하여 경로를 설정하여 해당 메소드에서 처리

• value : url 설정
• method : GET, POST, DELETE, PUT, PATCH 등

@RequestMapping(value = "/hello", method = RequestMethod.GET)

/hello 라는 url로 GET, POST, PUT, DELETE를 만들기 위해선 아래와 같이 작성한다.

@RestController
public class HelloController {

    @RequestMapping(value = "/hello", method = RequestMethod.GET)
    public String helloGet(...) {
        ...
    }

    @RequestMapping(value = "/hello", method = RequestMethod.POST)
    public String helloPost(...) {
        ...
    }

    @RequestMapping(value = "/hello", method = RequestMethod.PUT)
    public String helloPut(...) {
        ...
    }

    @RequestMapping(value = "/hello", method = RequestMethod.DELETE)
    public String helloDelete(...) {
        ...
    }
}

스프링 4.3버전부터 메소드를 지정하는 방식보다 간단하게 사용할 수 있는 어노테이션을 사용할 수 있음.

• @GetMapping
• @PostMapping
• @DeleteMapping
• @PutMapping
• @PatchMapping

@RequestMapping(value = "/hello")
public class HelloController {

    @GetMapping()
    public String helloGet(...) {
        ...
    }

    @PostMapping()
    public String helloPost(...) {
        ...
    }

    @PutMapping()
    public String helloPut(...) {
        ...
    }

    @DeleteMapping()
    public String helloDelete(...) {
        ...
    }
}

공통 url은 class에 @RequestMapping으로 설정을 해주고 @GetMapping, @PostMapping, @PutMapping, @DeleteMapping으로 간단하게 생략이 가능해졌다.

MVC 패턴

디자인 패턴 중 하나인 MVC 패턴은 Model, View, Controller의 줄임말로 어플리케이션을 구성할 때 그 구성요소를 세가지 역할로 구분한 패턴이다.

사용자 인터페이스로부터 비즈니스 로직을 분리하여 서로 영향 없이 쉽게 고칠 수 있는 설계가 가능하다.

컨트롤러 ( Controller )

모델 ( Model )과 뷰 ( View ) 사이의 브릿지 역할을 수행

앱의 사용자로부터 입력에 대한 응답으로 모델 및 뷰를 업데이트하는 로직을 포함한다.

사용자의 요청은 모두 컨트롤러를 통해 진행되어야 한다.

컨트롤러에 들어온 요청은 어떻게 처리할지 결정하여 모델로 요청을 전달함.

Ex) 쇼핑몰에서 상품을 검색하면 그 키워드를 컨트롤러가 받아 모델과 뷰에 적절하게 입력을 처리하여 전달함.

모델 ( Model )

데이터를 처리하는 영역

데이터베이스와 연동을 위한 DAO ( Data Access Object )와 데이터의 구조를 표현하는 DO ( Data Object )로 구성됨.

Ex) 검색을 위한 키워드가 넘어오면 데이터베이스에서 관련된 상품의 데이터를 받아 뷰에 전달

뷰 ( View )

데이터를 보여주는 화면 자체의 영역

사용자 인터페이스 ( UI ) 요소들이 포함되며, 데이터를 각 요소에 배치함.

뷰에서는 별도의 데이터를 보관하지 않음.

Ex) 검색 결과를 보여주기 위해 모델에서 결과 상품 리스트 데이터를 받음.

MVC 패턴의 특징

어플리케이션의 역할을 세 구간으로 나누어 설계함으로써 서로 간의 의존성이 낮아짐.

각 영역이 독립적으로 구성되어 개발자 간 분업 및 협업이 원할해짐

한 영역을 업데이트하더라도 다른 곳에 영향을 주지 않음.

Maven 프로젝트를 생성하면 루트 디렉토리에 생성되는 파일

Project Object Model 정보를 담고 있음

주요 설정 정보

• 프로젝트 정보 : 프로젝트의 이름, 개발자 목록, 라이센스 등

• 빌드 설정 정보 : 소스, 리소스, 라이플 사이클 등 실행할 플러그인 등

• POM 연관 정보 : 의존 프로젝트 ( 모듈 ), 상위 프로젝트, 하위 모듈 등

프로젝트 기본 정보

pom 파일에서 프로젝트의 정보와 관련된 태그는 아래와 같음

1. <name> : 프로젝트명

2. <url> : 프로젝트 사이트 url

3. <description> : 프로젝트에 대한 간단한 설명

4. <organization> : 프로젝트를 관리하는 단체 설명

프로젝트 연관 정보

pom 파일에서 프로젝트의 정보와 관련된 태그는 아래와 같음.

1. <groupId> : 프로젝트의 그룹 ID 설정

2. <artifactId> : 프로젝트 아티팩트 ID 설정

3. <version> : 프로젝트의 버전

4. <packaging> : 패키징 타입 설정

   • jar : 자바 프로젝트 압축 파일
   • war : 웹 어플리케이션을 위한 압축 파일

프로젝트 의존 설정

프로젝트에서 사용하는 라이브러리에 대한 의존성 설정과 관련된 태그는 아래와 같음.

1. <dependencies> : 라이브러리 의존성 정보를 가지고 있는 dependency 태그를 묶은 태그

2. <dependency> : 라이브러리의 정보를 담는 태그

3. <groupId> : 의존성 라이브러리의 그룹 ID

4. <artifactId> : 의존성 라이브러리의 아티팩트 ID

5. <version> : 의존성 라이브러리의 버전

6. <scope> : 해당 라이브러리의 이용 범위를 지정

   • compile ( detault ) : 아무것도 지정되지 않았을 때의 설정값, 모든 클래스 경로에서 사용할 수 있음.

   • provided : compile과 유사하지만 JDK 혹은 Container가 런타임 시에만 제공, 컴파일 혹은 테스트 경로에서만 사용, 배포 시에는 빠짐

   • runtime : 컴파일 시에는 사용하지 않고, 실행 상황에서만 사용됨, 컴파일 클래스 경로에서는 존재하지 않음

   • test : 테스트 상황에서만 사용되는 라이브러리를 의미, 종속된 다른 프로젝트에 영향을 미치지 않음. 실 가동상황에서는 필요없는 라이브러리를 사용할 경우에 설정

   • system : provided와 유사하지만 저장소에서 관리되지 않고 직접 관리하는 JAR를 추가, systemPath를 추가 작성해야 함.

7. <optional> : 다른 프로젝트에서 이 프로젝트를 의존성 설정을 할 경우 사용할지 결정

자주 사용하는 라이브러리 설명

1. Spring Boot Stater Parent : 프로젝트에서 사용하는 다양한 라이브러리 간의 버전 충돌 문제가 발생할 수 있는 것을 방지, 의존성 조합 간 충돌 문제가 없는 검증된 버전 정보 조합을 제공

2. Spring Boot Stater Web : Spring MVC를 사용한 REST 서비스를 개발하는데 사용

3. Spring Boot Stater Test : JUnit, Hamcrest, Mockito를 포함한 스프링 어플리케이션의 테스트 기능을 제공

Application Programming Interface의 줄임말

응용 프로그램에서 사용할 수 있도록 다른 응용 프로그램에서 제어할 수 있게 만든 인터페이스를 뜻함.

API를 사용하면 내부 구현 로직을 알지 못해도 정의되어 있는 기능을 쉽게 사용할 수 있음.

여기에서 인터페이스(Interface)는 어떤 장치 간 정보를 교환하기 위한 수단이나 방법을 의미함. Ex) 마우스, 키보드, 터치패드 등

API의 역할

• 서버와 데이터베이스에 대한 출입구 역할

• 애플리케이션과 기기가 원할하게 통신 가능하도록 한다.

• 모든 접속을 표준화한다.

API의 유형

• private API : 내부 API, 회사 개발자가 자체 제품과 서비스를 개선하기 위해 내부적으로 발행합니다. 따라서 제 3자에게 노출되지 않는다.

• partner API : 기업이 데이터 공유에 동의하는 특정인들만 사용할 수 있다. 비즈니스 관계에서 사용되는 편이며, 종종 파트너 회사 간에 소프트웨어를 통합하기 위해 사용된다.

• public API : 개방형 API로, 모두에게 공개된다. 누구나 제한 없이 API를 사용할 수 있는 게 특징

REST

Representational State Transfer의 줄임말

자원 ( 데이터 )의 이름으로 구분하여 해당 자원의 상태를 교환하는 것을 의미한다.

REST는 서버와 클라이언트의 통신 방법 중 하나로 아키텍쳐에 가깝다.

HTTP URI(Uniform Resource Identifier)를 통해 자원을 명시하고 HTTP Method를 통해 자원을 교환한다.

HTTP Method : Create, Read, Update, Delete ( CRUD )

REST의 특징 ( 규칙 )

• Server - Client 구조 : 자원이 있는 쪽이 Server, 요청하는 쪽이 _Client_이며 _Client_와 _Server_는 독립적으로 분리되어 있어야 한다.

• Stateless : 요청 간에 클라이언트 정보가 서버에 저장되지 않는다. 서버는 각각의 요청을 완전히 다른 요청으로 별개의 것으로 인식하고 처리한다.

• Cacheable : _HTTP 프로토콜_을 그대로 사용하기 때문에 HTTP의 특징인 캐시 기능을 적용, 대량의 요청을 효율적으로 처리하기 위해 캐시를 사용한다.

• 계층화 ( Layered System ) : 클라이언트는 서버의 구성과 상관없이 REST API 서버로 요청, 서버는 _다중 계층_으로 구성될 수 있음. ( 로드밸런싱, 보안 요소, 캐시 등)

• Code on Demand ( Optional ) : 요청을 받으면 서버에서 클라이언트로 코드 또는 스크립트(로직)을 전달하여 클라이언트 기능을 확장 ( Javascript 개념 쪽에서 자주 사용 )

• 인터페이스 일관성 ( Uniform Interface ) : 자원이 표준 형식으로 전송되기 위해 구성 요소간 통합 인터페이스를 제공, HTTP 프로토콜을 따르는 모든 플랫폼에서 사용 가능하게끔 설계한다.

REST의 장점

• HTTP 표준 프로토콜을 사용하는 모든 플랫폼에서 호환 가능

• 서버와 클라이언트의 역할을 명확하게 분리

• 여러 서비스 설계에서 생길 수 있는 문제 최소화

REST API

REST 아키텍쳐를 따르는 API를 뜻함. 일반적으로 REST 아키텍쳐를 구현하는 웹 서비스를 RESTful하다고 한다.

REST API의 특징

• REST 기반으로 시스템을 분산하여 확장성과 재사용성을 높임

• HTTP 표준을 따르고 있어 여러 프로그래밍 언어를 구현 가능하다.

REST API 설계 규칙

• 웹 기반의 REST API를 설계할 경우에는 URI를 통하여 자원을 표현해야 함

• 자원에 대한 조작은 HTTP Method ( CRUD )를 통하여 표현해야 함 : URI에 행위가 들어가면 안됨, HEADER를 통해 CRUD를 표현하여 동작을 요청해야 함

• 메세지를 통한 자원 리소스 조작 : HEADER를 통한 content-type을 지정하여 데이터를 전달, 대표적인 형식으론 HTML, XML, JSON, TEXT가 있음

• URI에는 소문자를 사용

• Resource의 이름이나 URI가 길어질 경우 하이픈(-)을 통해 처리

• 언더바(_)는 사용하지 않음

• 파일 확장자를 표현하지 않음

SOAP

Simple Object Access Protocol의 줄임말

그 자체로 프로토콜이며 보안이나 메세지 전송 등에 있어 엄격한 규약을 가짐.

성공/반복 실행 로직이 규정되어 있기 때문에 SOAP API를 통해서 통신할 때 처음부터 끝까지 신뢰성을 제공한다.

SOAP 표준에는 ACID 준수에 관한 사항이 있다. ACID를 준수하기 때문에 데이터의 변형을 줄여주고, 데이터베이스와의 상호작용에 대해서 사전에 정확하게 정하기 때문에 데이터의 무결성을 지켜줌.

ACID( 원자성, 일관성, 고립성, 지속성 )는 데이터 일관성을 위한 다른 방식들보다도 더 보수적이기 때문에, 금융 정보 등의 민감한 데이터를 주고받을 때 일반적으로 많이 사용된다.

• 데이터 포맷으로 오직 XML만 사용한다.

ctrl + s (저장)을 하면 해결된다.

• 코드는 다른 사람이 그것을 이해하는데 들이는 시간을 최소화하는 방식으로 작성되어야 한다.
• 적은 분량으로 코드를 작성하는 것보다 이해를 위한 시간을 최소화하는 것이 중요하다.

2. 이름에 정보를 담아내기

1. 특정한 단어 고르기
2. 보편적인 이름 피하기
3. 구체적인 이름 사용하기
4. 이름에 추가적인 정보 붙이기
5. 이름의 길이 결정하기
6. 추가적인 정보를 담을 수 있는 이름 구성하기

####1. 특정한 단어 고르기

get, size, stop 등은 지나치게 보편적인 단어이므로 사용하지 않는다. get보단 fetch 혹은 download, size보단 height, number of nodes 등이 더 의미있는 이름일 것이다.

####2. 보편적인 이름 피하기

tmp, retval 같은 이름보단 개체의 값이나 목적을 정확하게 설명하는 이름을 골라야 한다. 좋은 이름은 변수의 목적이나 담고 있는 값을 설명해주어야 한다. 이러한 이름은 변수의 목적을 직접적으로 나타내므로 나중에 버그를 잡는 데 도움이 될 수 있다.

tmp라는 이름은 대상이 짧게 임시적으로만 존재하고, 임시전 존재 자체가 변수의 가장 중요한 용도일 때에 한해서 사용해야 한다.

####3. 구체적인 이름 사용하기

변수나 함수 혹은 다름 요소에 이름을 붙일 때 추상적인 방식이 아니라 구체적인 방식으로 묘사하라. 이름을 선택하는 이유가 모호하고 간접적이라면 좋은 이름이라 볼 수 없다.

####4. 이름에 추가적인 정보 붙이기

변수나 함수의 이름은 작은 설명문이다. 따라서 사용자가 반드시 알아야 하는 변수와 관련한 중요한 정보를 추가적인 단어로 만들어서 이름에 붙이는 게 좋다.

####5. 이름의 길이 결정하기 좁은 범위에서의 이름은 짧을 수록 좋으나 사용 범위가 넓으면 긴 이름이 좋다.

####6. 추가적인 정보를 담을 수 있는 이름 구성하기 밑줄과 대시, 대문자를 잘 활용하면 이름에 더 많은 정보를 담을 수 있다.

예를 들어 클래스 멤버 변수는 로컬 변수와 구분하기 위해 뒤에 '_'를 붙일 수 있다.

3. 오해할 수 없는 이름들

본인이 지은 이름을 다른 사람들이 다른 의미로 해석할 수 있는지 철저하게 확인해야 한다.

• 한계를 설정하는 이름을 가장 명확하게 만드는 방법은 제한받는 대상의 이름 앞에 max나 min을 붙이는 것이다.

• 경계를 포함하는 범위엔 first와 last를 사용하라.

• 경계를 포함하고/ 배제하는 범위에는 begin과 end를 사용하라.

• 불리언 변수에 이름을 붙일 때는 is, has, can, should 와 같은 단어를 사용하고, 부정적인 용어는 피하는 것이 좋다.

• 대개 get으로 시작되는 이름의 메소드는 가벼운 접근자로서 단순히 내부 멤버를 반환한다고 관행적으로 생각한다. 이처럼 특정 관행에 어긋나는 방식으로 이름을 짓는 것보다 일반적인 의미를 갖도록 하는 것이 좋다.

4. 미학

• 일관성 있는 레이아웃을 사용하라.

  • 서로 연관된 코드는 하나의 블록으로 묶어라.

  • 비슷한 코드는 서로 비슷해 보이게 만들어라.

• 코드 곳곳을 '열'로 만들어서 줄을 맞추면 코드를 한 눈에 훑어보기 편하다.

• 코드의 한 곳에서 A, B, C가 순서대로 언급되고 있으면 다른 곳에서 또한 그 순서를 지켜라.

• 빈 줄을 이용하여 커다란 블록을 논리적인 '문단'으로 나누어라

• 코드를 ‘보기 예쁘게' 만드는 작업은 표면적인 개선 이상의 결과를 가져온다 (코드의 구조 자체를 개선시킨다)