정보처리기사 실기시험 내용 정리

서버프로그램 구현 출제 순서

한줄 tip! 그냥 소프트웨어 개발한다고 생각하고 순서를 이해하기기

  1. 개발환경 구축하기
  2. 공통모듈 구현하기
  3. 서버프로그램 구현하기
  4. 배치프로그램 구현하기

서버의 종류

  • 웹 서버: 웹 상의 정적 콘텐츠 처리. HTTP 요청과 응답 처리
  • 웹 애플리케이션 서버(WAS): 동적 콘텐츠, 데이터베이스 연결 처리
  • 데이터베이스 서버
  • 파일 서버: 파일 서빙

모듈을 개발했을 때 응집도와 결합도

모듈개발 = 프로그래밍 언어로 구현

1) 응집도(강할수록 좋음)

기순교절시논우
앞글자외우는법: [기]씨가 [순][교]=종교적죽음 하셨는데 [절]대 [시]도 (하지마세요)[논]노[우]

기능적 → 순차적 → 교환적 → 절차적 → 시간적 → 논리적 → 우연적

자주 틀리는… 순차적 vs 절차적!?

  • 순차적 응집도: 모듈의 출력(리턴값)이 다른 모듈의 입력으로 들어감 (훨씬 좋음!!) 
    def readFile(fileName):
   # 파일을 읽어들임
   return data

def processData(data):
   # 데이터를 처리함
   return processedData

def writeFile(fileName, data):
   # 파일에 데이터를 씀
   pass

data = readFile("input.txt")
processedData = processData(data)
writeFile("output.txt", processedData)
  • 절차적 응집도: 관련된 기능이 특정 순서로 실행되는 것 
    def initializeSystem():
   # 시스템 초기화
   pass

def startService():
   # 서비스 시작
   pass

def shutdownService():
   # 서비스 종료
   pass

2) 결합도(강할수록 안좋음)

모듈간에 결합되면 연관관계가 강해지면 유지보수 어렵고 오류 찾기 어렵습니다.

내용 → 공통 → 외부 → 제어 → 스탬프 → 자료

내공외제스자
앞글자외우는법: ([내][공]이 좋은 [외][제]품 (쓰)[스][자] ^^..)

공통모듈 구현 절차

DTO/VO → SQL → DAO → Service → Controller → View

  • DTO/VO: Data Transfer Object, Value Object(read-only)
    • 정의: 데이터를 전송하고 저장을 위한 객체를 설계합니다.
    • 객체를 정의해주는 것입니다.
    • 데이터의 전송이나 저장을 위한 객체를 설계하는 과정입니다.
  • SQL: 데이터베이스 접근을 위한 쿼리를 작성합니다.

    데이터베이스에 접근하기 위한 것입니다.
    서버나 컨트롤러에서 RDBMS를 사용하여 데이터에 접근합니다.
    접근 방법을 설계하는 과정입니다.

  • DAO: 데이터베이스와의 상호작용을 담당하는 객체를 설계합니다.

    실제로 데이터베이스와 상호작용하는 객체가 필요합니다.
    Data Access Object의 약자입니다.

  • 서비스: DAO를 호출하여 데이터 처리 후에 DTO/VO를 사용하여 데이터를 주고 받습니다.

    서비스 계층에서는 DAO를 호출하고, 호출 결과로부터 Data Transfer Object나 Value Object를 활용하여 데이터를 주고받는 역할을 합니다.

  • 컨트롤러: View와 서비스의 중간 단계의 다리 역할을 합니다. (HTTP 요청/응답 등)

    비즈니스 로직을 관리하며, 소프트웨어의 메인 로직을 처리합니다. 뷰와 서비스 사이의 중간 로직을 담당하는 것이 컨트롤러입니다.

  • 뷰: 사용자(고객)에게 보이는 화면을 구현합니다.

    HTML, JavaScript 등을 활용하여 사용자 인터페이스를 구현하는 부분이 뷰입니다.

TIP: 다음과 같은 순서로 기억하시면 좋습니다.

  1. 데이터를 표현할 객체를 먼저 설계합니다(DTO/VO)
  2. 데이터베이스 접근을 위한 쿼리를 작성합니다(SQL)
  3. 데이터베이스와 상호작용하는 객체를 설계합니다(DAO)
  4. 비즈니스 로직을 처리하는 서비스를 구현합니다(Service)
  5. 사용자 요청을 처리하는 컨트롤러를 개발합니다(Controller)
  6. 사용자 인터페이스를 구현합니다(View)

Fan-In / Fan-Out — 짧게 짚고 가기

모듈 설계가 커지면 “이 모듈을 누가 부르고, 이 모듈은 누구를 부르는가”를 관리하는 게 중요해지는데, 이를 정량화한 게 Fan-In/Fan-Out이다.

  • Fan-In: 특정 모듈을 호출하는 상위 모듈의 수. Fan-In이 너무 높으면 그 모듈에 여러 흐름이 몰려 있다는 뜻이라 재사용성은 좋지만 변경 시 영향 범위가 커진다.
  • Fan-Out: 특정 모듈이 호출하는 하위 모듈의 수. Fan-Out이 너무 높으면 그 모듈이 너무 많은 일을 떠맡고 있다는 신호로, 책임을 쪼개야 할 후보다.

좋은 설계는 대체로 Fan-In은 높고 Fan-Out은 낮은 모듈(공통으로 널리 쓰이지만 자기 자신은 단순한 모듈)을 지향한다.

핵심 정리

  • 응집도는 “모듈 안이 얼마나 하나의 목적에 집중돼 있는가”(높을수록 좋음), 결합도는 “모듈 사이가 얼마나 얽혀 있는가”(낮을수록 좋음)로 정반대 방향의 지표라는 점을 기억하면 두 개념이 헷갈리지 않는다.
  • DTO/VO→SQL→DAO→Service→Controller→View 순서는 “데이터를 어떻게 표현할지 정하고(DTO) → 어떻게 가져올지 정하고(SQL/DAO) → 어떻게 가공할지 정하고(Service) → 어떻게 요청받을지 정하고(Controller) → 어떻게 보여줄지 정한다(View)”는 흐름으로 외우면 자연스럽다.