1. 요구공학(Requirements Engineering)에 대한 설명으로 옳지 않은것
- 무엇을 개발해야 하는지 요구사항을 정의하고, 분석 및 관리하는 프로세스를 연구하는 학문
- 사용자 요구사항이 더욱 복잡해지고 잦은 변경이 발생하자 이를 적절하게 관리하기 위해 등장
- 요구사항 개발의 한 요소
- 품질 개선과 프로젝트 실패의 최소화를 목적으로 함
요구공학(Requirements Engineering)이란?
소프트웨어를 만들기 전에
**“무엇을 만들지, 왜 필요한지, 어떤 기능이 있어야 하는지”**를
정확하게 정의하고 정리하는 학문 및 과정이에요.
🔍 보기 하나씩 검토해볼게요
보기 내용설명맞는지?
| ✅ 무엇을 개발해야 하는지 요구사항을 정의하고, 분석 및 관리하는 프로세스를 연구하는 학문 | ✔ 요구공학의 기본 정의 | ✅ 옳음 |
| ✅ 사용자 요구사항이 더욱 복잡해지고 잦은 변경이 발생하자 이를 적절하게 관리하기 위해 등장 | ✔ 실제 등장 배경 설명 | ✅ 옳음 |
| ❌ 요구사항 개발의 한 요소 | ❌ 요구공학이 "요구사항 개발"을 포함하는 상위 개념이지, 그 반대가 아님 | ❌ 틀림 (정답) |
| ✅ 품질 개선과 프로젝트 실패의 최소화를 목적으로 함 | ✔ 요구공학의 주요 목적 중 하나 | ✅ 옳음 |
✅ 왜 “요구사항 개발의 한 요소”가 틀렸을까?
- 요구공학은 다음과 같은 구성 요소를 포함함:
- 요구사항 개발
- 요구사항 분석
- 요구사항 추적 및 변경 관리
- 요구사항 검증 및 확인 등
👉 즉, "요구사항 개발"은 요구공학의 일부이고,
"요구공학이 요구사항 개발의 한 요소다"라는 말은 거꾸로 말한 것이기 때문에 틀린 설명이에요.
2. XP(eXtreme Programming)에 대한 설명으로 옳지 않은 것은
- 릴리즈 기간을 짧게 반복하여 고객의 요구 변화에 빠르게 대응한다.
- 코드들은 하나의 작업이 마무리될 때마다 지속적으로 통합한다
- 테스트가 지속적으로 진행될 수 있도록 테스트 자동화 도구를 사용한다
- 개발 책임자가 모든 책임을 가지므로 팀원들은 책임 없이 자유로운 개발이 가능
XP(eXtreme Programming)란?
애자일(Agile) 방식의 한 종류로,
변화에 빠르게 대응하면서 지속적 통합, 자동 테스트, 짧은 반복 개발 주기를 강조하는 현장 중심 개발 방법론이에요.
✅ 보기 검토
보기 내용설명옳은 설명인지?
| ✅ 릴리즈 기간을 짧게 반복하여 고객의 요구 변화에 빠르게 대응한다 | ✔ XP는 1~3주 단위의 짧은 반복 개발을 통해 고객 요구 반영 | ✅ |
| ✅ 코드들은 하나의 작업이 마무리될 때마다 지속적으로 통합한다 | ✔ 지속적 통합(Continuous Integration)은 XP의 핵심 | ✅ |
| ✅ 테스트가 지속적으로 진행될 수 있도록 테스트 자동화 도구를 사용한다 | ✔ 테스트 주도 개발(TDD)과 자동화 테스트는 XP의 주요 기법 | ✅ |
| ❌ 개발 책임자가 모든 책임을 가지므로 팀원들은 책임 없이 자유로운 개발이 가능 | ❌ 완전히 틀린 설명. XP는 팀원 모두가 공동 책임을 가지며, 협업과 책임 분담을 중요시함 | ❌ (정답) |
📌 XP의 핵심 가치
- 의사소통 (Communication)
- 단순성 (Simplicity)
- 피드백 (Feedback)
- 용기 (Courage)
- 존중 (Respect)
👉 특히 모든 팀원이 협업하고 공동 책임을 지는 문화가 중요해요.
3. UML에서 활용되는 다이어그램의 이름과 설명의 연결
- 클래스 다이어그램: 시퀀스 다이어그램과 같이 동작에 참여하는 객체들이 주고 받는 메시지를 표현하는데, 메시지뿐만 아니라 객체들 간의 연관까지 표현한다
- 배치 다이어그램 : 결과물,프로세스,컴포넌트 등 물리적 요소들의 위치를 표현
- 유스케이스 다이어그램 : 사용자의 요구를 분석하는 것으로, 기능 모델링 작업에 사용
- 활동 다이어그램 : 시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현한다
UML 다이어그램 올바른 연결 정리
다이어그램 이름올바른 설명맞는지 여부
| 클래스 다이어그램 | 시스템의 **클래스(객체 설계도)**와 **관계(상속, 연관 등)**를 표현 | ❌ 보기 설명이 잘못됨 |
| 배치 다이어그램 | 시스템 구성 요소(서버, 컴포넌트 등)의 물리적 배치 구조를 표현 | ✅ 맞음 |
| 유스케이스 다이어그램 | **사용자와 시스템이 상호작용하는 기능(요구사항)**을 시각화 | ✅ 맞음 |
| 활동 다이어그램 | **조건에 따라 작업이 어떻게 흐르는지(처리 흐름)**를 표현 | ✅ 맞음 |
❌ 왜 클래스 다이어그램 설명이 틀렸을까?
- 문제 보기에서는 “메시지를 주고받는 동작”이라고 했는데,
👉 이건 시퀀스 다이어그램이나 커뮤니케이션 다이어그램의 역할입니다. - **클래스 다이어그램은 구조(정적 구조)**만 표현하고,
메시지 주고받기나 순차 흐름은 표현하지 않아요.
4. 다음 설명에 해당하는 도표는
- 시스템의 기능을 여러 개의 고유 모듈들로 분할하여 이들간의 인터페이스를 계층 구조로 표현한 것으로, 가시적도표(Visual Table of Contents), 총체적 도표(Overview Diagram),세부적 도표(Detail Diagram)가 있다
- Flow Chart
- Burn-down Chart
- Visual Diagram
- HIPO Chart
문제 핵심 요약
- 시스템의 기능을 여러 개의 모듈로 나누고
- 이들 간의 계층 구조와 인터페이스를 보여줌
- 가시적 도표(Visual Table of Contents),
총체적 도표(Overview Diagram),
세부적 도표(Detail Diagram) 포함
👉 이런 특징을 가진 도표는 바로 HIPO Chart예요!
🧠 HIPO란?
HIPO = Hierarchy + Input + Process + Output
👉 입력(Input), 처리(Process), 출력(Output)을 계층적으로 표현한 도표예요.
✅ HIPO Chart의 구성 요소
구성설명
| 가시적 도표 (Visual Table of Contents) | 전체 시스템의 구조와 흐름을 한눈에 볼 수 있는 도표 |
| 총체적 도표 (Overview Diagram) | 상위 수준에서 각 기능이 어떤 하위 모듈을 포함하는지 설명 |
| 세부적 도표 (Detail Diagram) | 각 모듈이 실제로 어떻게 작동하는지 상세 설명 (입력 → 처리 → 출력) |
❌ 다른 보기 설명
보기설명틀린 이유
| Flow Chart | 순서도. 로직 흐름을 도형으로 표현 | 계층 구조 중심이 아님 |
| Burn-down Chart | 애자일 개발에서 작업 남은 양을 그래프로 표현 | 개발 일정 관리용이지, 기능 구조 도표 아님 |
| Visual Diagram | 일반적인 시각화 도표 의미, 공식 용어가 아님 | ❌ HIPO의 구성과 무관 |
5. 불필요한 메모리의 낭비를 최소화하기 위해 여러 프로세스가 동시에 참조할 수는 없지만 어디서든 참조할 수 있는 객체를 생성하는 디자인 패턴
- 싱글톤 패턴
- 옵서버 패턴
- 프로토타입 패턴
- 상태 패턴
문제 요약
- 불필요한 메모리 낭비를 막기 위해
- 하나의 객체만 생성하고,
- 여러 곳에서 공유해서 참조할 수 있게 하는 패턴은?
👉 바로 싱글톤(Singleton) 패턴입니다.
✅ 싱글톤 패턴이란?
프로그램 전체에서 단 하나의 인스턴스(객체)만 생성되도록 보장하고,
그 객체를 어디서든 공유해서 사용할 수 있도록 만드는 디자인 패턴이에요.
🎯 쉽게 예를 들어보면:
- 게임에서 설정(옵션) 창은 하나만 존재해야 함
- 프린터 스풀러, DB 연결 클래스, 로그 기록 클래스 등
→ 여러 객체가 생성되면 자원 낭비가 생기므로 단 하나만 유지해야 함
✅ 싱글톤 패턴의 특징
항목설명
| 객체 수 | 딱 하나만 생성됨 |
| 접근 방법 | 어디서든 접근 가능 (전역처럼 사용) |
| 메모리 절약 | 반복 생성 X → 메모리 낭비 줄임 |
| 예시 | 설정 관리자, 로깅 시스템, DB 커넥션 풀 등 |
❌ 다른 보기 설명
패턴설명틀린 이유
| 옵서버 패턴 | 어떤 객체의 상태 변화가 있을 때 자동으로 연결된 객체들에게 알림을 보내는 패턴 | 여러 객체가 연결됨. 메모리 낭비 절감과 무관 |
| 프로토타입 패턴 | 기존 객체를 복사해서 새 객체 생성 | 오히려 객체를 여러 개 만듦 |
| 상태 패턴 | 객체의 상태에 따라 행동이 바뀌도록 구성 | 객체 수 제어와는 관련 없음 |
6. 객체지향 기법에서 객체가 메세지를 받아 실행해야 할 객체의 구체적인 연산을 정의한것은?
- Entity
- Method
- instance
- Class
객체지향 기법에서는 **객체(object)**가 뭔가 일을 하게 만들기 위해 **메시지(명령)**를 보내요.
이때, 그 메시지를 받았을 때 실제로 어떤 일을 할지 정해놓은 것이 바로 메서드예요.
예시로 설명해볼게요!
🧸 곰인형(객체)이 있다고 해봐요.
우리가 곰인형한테 “춤춰!”(메시지)를 말하면,
곰인형이 실제로 “양손을 흔들면서 좌우로 흔들기” 같은 동작을 하게 되죠.
이 동작이 바로 메서드예요.
🧠 용어들 추가로 간단 정리
용어뜻예시 (곰인형 예시로)
| Class (클래스) | 객체의 설계도 | 곰인형을 만들기 위한 도면 |
| Object / Instance (객체 / 인스턴스) | 클래스를 바탕으로 실제 만들어진 물건 | 곰인형 1개 |
| Entity (엔티티) | 현실 세계의 ‘대상’ (정보를 담는 단위) – 보통 데이터베이스 용어에서 자주 씀 | "곰인형", "학생", "책" 같은 정보 단위 |
| Method (메서드) | 객체가 어떤 일을 할지 정해 놓은 기능 | "춤추기", "말하기" 기능 |
💡 추가로 알면 좋은 것
- 메서드는 **함수(function)**랑 비슷하지만, 객체에 소속된 함수예요. 그래서 “곰인형이 춤추기”처럼 주인이 있는 행동이라고 보면 돼요.
- 하나의 클래스 안에는 여러 개의 메서드가 있을 수 있어요.
- 메서드를 통해 캡슐화(중요한 내용을 숨기고 필요한 기능만 외부에 공개)를 할 수 있어요.
**엔티티(Entity)**는
"정보를 담을 수 있는 실제 또는 개념적인 대상"
을 말해요.
말이 어려우니까 예시로 설명할게요.
🧸 예시: 학교를 만든다고 할 때
학교 시스템에서 생각해볼 수 있는 것들:
- 학생
- 선생님
- 교실
- 시험
이런 것들이 다 엔티티예요.
즉, 학생이라는 엔티티는 이름, 나이, 학년, 반 같은 정보를 가지고 있어요.
학생 (엔티티)
| 이름: 김민수 |
| 나이: 14 |
| 학년: 2 |
| 반: 3 |
이렇게 정보를 저장할 수 있는 대상이 엔티티야!
📦 다시 정리하면
- 엔티티 = 정보를 저장할 수 있는 주제(대상)
- 프로그램이나 데이터베이스에서 중요해서 관리해야 하는 대상
💡 추가로 알면 좋은 것
- 엔티티는 보통 클래스랑 연결돼요.
예: class Student처럼 "학생"이라는 클래스가 하나의 엔티티 역할을 함. - 실제 데이터베이스(DB)에서는 엔티티 = 테이블이라고 생각해도 거의 맞아요.
- 속성 (Attribute)
- 관계 (Relationship)
📌 1. 속성 (Attribute)
속성은 **엔티티가 가지고 있는 정보(특성)**이에요.
예시:
**학생(엔티티)**의 속성은
- 이름
- 나이
- 학년
- 반
- 번호
📦 비유하자면:
학생 = 하나의 폴더,
그 안에 적힌 정보 = 속성
학생
| 이름: 김민수 |
| 나이: 14 |
| 학년: 2 |
| 반: 3반 |
📌 2. 관계 (Relationship)
관계는 엔티티끼리의 연결이에요.
예시:
- 학생 ↔ 수업:
학생은 여러 수업을 듣고,
한 수업에 여러 학생이 참여해요.
이걸 “학생과 수업은 관계가 있다”고 해요.
📦 비유하자면:
엔티티 = 인물들
관계 = 이들이 맺고 있는 친구, 선생님, 가족 같은 연결선
🎓 전체 그림 정리
개념설명예시
| 엔티티 (Entity) | 정보를 담을 수 있는 대상 | 학생, 선생님, 수업 |
| 속성 (Attribute) | 엔티티가 가진 구체적인 정보 | 이름, 나이, 반 |
| 관계 (Relationship) | 엔티티끼리의 연결 | 학생이 수업을 듣는다 |
7. 바람직한 소프트웨어 설계 지침이 아닌것 4
- 결합도를 최소화하고 응집도를 최대화한다
- 복잡도와 중복성을 줄이고 일관성을 유지시킨다
- 하나의 입구와 하나의 출구를 갖도록 해야한다
- 모듈의 크기를 가낭한 작게 구성하여 병행성 수준을 높여야한다
왜 이게 바람직하지 않은 소프트웨어 설계 지침일까?
표현이 일부분만 맞고, 전체적으로는 오해 소지가 있어요.
- 모듈을 너무 작게 만들면?
- 오히려 관리하기 어려워지고,
- 모듈 간 의존성이 많아져서 결합도가 높아질 수 있어요.
- **병행성(동시 처리)**과도 직접적인 관련이 없어요.
즉, 작게 쪼갠다고 무조건 좋은 건 아니고, 적절하게 역할 단위로 나누는 것이 핵심이에요.
✅ 나머지 선택지는 모두 바람직한 설계 지침
지침설명
| 결합도를 최소화하고 응집도를 최대화 | 모듈 간 연결은 줄이고, 각 모듈의 기능은 하나로 집중시키기 |
| 복잡도와 중복성 줄이고 일관성 유지 | 코드가 읽기 쉽고 유지보수도 쉬워짐 |
| 하나의 입구와 하나의 출구 | 함수나 모듈은 명확한 흐름을 가지게 해서 오류 줄이기 |
| 원칙 이름 | 전체 이름 | 핵심 의미 | 예시 | 지키지 않았을 때 문제 |
| S - SRP | 단일 책임 원칙(Single Responsibility Principle) | 하나의 클래스(또는 함수)는 한 가지 책임만 가져야 함 | 게시글 클래스는 글만 다루고, 댓글은 별도 클래스에서 처리 | 여러 기능이 얽히면 수정 시 연쇄 오류 발생 |
| O - OCP | 개방-폐쇄 원칙(Open-Closed Principle) | 코드는 확장에는 열려있고, 변경에는 닫혀 있어야 함 | 새 기능을 추가할 때 기존 코드를 수정하지 않고 확장 | 기존 코드까지 수정하게 되어 버그 발생 가능성 증가 |
| L - LSP | 리스코프 치환 원칙(Liskov Substitution Principle) | 부모 클래스를 사용하는 곳에 자식 클래스를 넣어도 문제 없어야 함 | Bird → Penguin, 하지만 fly()가 있다면 오류 | 자식 클래스가 부모의 기능을 깨뜨리는 경우 |
| I - ISP | 인터페이스 분리 원칙(Interface Segregation Principle) | 사용하지 않는 큰 인터페이스보다 작은 여러 인터페이스가 낫다 | 프린터: 인쇄, 스캔, 팩스를 분리된 인터페이스로 나눔 | 사용하지 않는 기능까지 구현해야 하는 낭비 발생 |
| D - DIP | 의존 역전 원칙(Dependency Inversion Principle) | 고수준 모듈이 저수준 모듈에 직접 의존하지 않도록 추상화 | NotificationService가 Email, SMS 대신 인터페이스에 의존 | 구현에 직접 의존하면 유지보수 어렵고 확장 어려움 |
| DRY | Don't Repeat Yourself | 중복을 피하라. 같은 코드는 함수나 모듈로 분리 | 비슷한 로직을 함수로 만들어 재사용 | 복사-붙여넣기로 코드가 많아지고 버그 관리 어려움 |
| KISS | Keep It Simple, Stupid | 코드는 단순하고 명료하게 작성해야 한다 | 복잡한 로직보다 if-else로 직관적인 처리 | 쓸데없이 복잡해지면 이해와 유지가 어려움 |
| YAGNI | You Aren’t Gonna Need It | 필요하지 않은 기능은 미리 만들지 마라 | 나중에 쓸 것 같아 만드는 설정, 기능들 | 사용도 안 하는 코드에 시간 낭비, 복잡성 증가 |
| 구조 설계 | SOLID | 유연하고 유지보수 쉬운 구조 만들기 |
| 코딩 습관 | DRY, KISS, YAGNI | 깔끔하고 효율적인 코드 작성 습관 만들기 |
8. 객체지향 설계 원칙에 대한 설명 중 틀린 것은? 4
- OCP : 기존의 코드를 변경하지 않고 기능을 추가할 수 있도록 설계해야 한다는 원칙
- LSP : 자식 클래스는 최소한 자신의 부모 클래스에서 가능한 행위는 수행할 수 있어야 한다는 설계원칙
- DIP : 각 객체들 간의 의존 관계가 성립될 때, 추상성이 낮은 클래스보다 추상성이 높은 클래스와 의존 관계를 맺어야 한다는 원칙
- ISP : 객체는 단 하나의 책임만 가져야 한다는 원칙
9. 객체지향 분석 방법론 중 미시적(Micro) 개발 프로세스와 거시적 (Macro)개발 프로세스를 모두 사용하는 분석 방법으로, 클래스와 객체들을 분석 및 식별하고 클래스의 속성과 연산을 정의하는 것은?
- Coad와 Yourdon
- Booch
- Jacobson
- Wirfs-Brocks
객체지향 분석 방법론 비교표
분석 방법론제안자분석 관점개발 프로세스주요 특징사용 다이어그램설명 방식
| Booch | Grady Booch | 클래스 중심 | Micro + Macro | 분석과 설계 모두 포함 객체 식별, 속성·연산 정의 |
클래스, 객체, 상태, 상호작용 등 | 정적/동적 구조 모두 강조 |
| Coad & Yourdon | Peter Coad, Edward Yourdon | 기능 중심 + 객체 식별 | 분석 중심 | 객체를 5단계로 식별 (주제-객체-속성-연산-관계) | 객체 모델, 동작 모델 등 | 객체-기능-구조 분석 위주 |
| Jacobson (OOSE) | Ivar Jacobson | 유스케이스 중심 | 분석 중심 | 유스케이스(Use Case)를 통해 사용자 시나리오 분석 | 유스케이스, 클래스, 상호작용 등 | 사용자 행위에서 시작 |
| Wirfs-Brock | Rebecca Wirfs-Brock | 책임 중심 | 설계 중심 | 책임-협력 기반의 객체 설계 객체 간 메시지 중심 |
CRC 카드, 협력 다이어그램 | 책임-역할-협력 관점 강조 |
🧠 특징 요약
방법론강점약점
| Booch | 전체적 분석+설계, 다양한 다이어그램 활용 | 복잡하고 학습 곡선 있음 |
| Coad & Yourdon | 객체 식별 중심, 분석에 충실 | 설계 요소 반영이 약함 |
| Jacobson | 실제 사용 시나리오 기반 분석 가능 | 유스케이스에만 치중할 수 있음 |
| Wirfs-Brock | 책임 중심으로 설계에 매우 유용 | 분석 관점이 부족할 수 있음 |
📌 기억 꿀팁
- Booch: 분석 + 설계 전체, 다이어그램 많음 (UML 기반 원조)
- Coad & Yourdon: 분석 위주, 식별 단계 명확
- Jacobson: 유스케이스 시나리오 분석하면 얘!
- Wirfs-Brock: 객체가 무슨 책임을 지는지에 집중
10. HIPO Chart 에 대한 설명으로 틀린것은?
- HIPO 차트 종류에는 가시적 도표, 총체적 도표, 세부적 도표가 있다
- 충분한 사전 지식과 학습이 없으면 이해하기 어렵다
- 기능과 자료의 의존관계를 동시에 표현할 수 있다
- 하향식 소프트웨어 개발을 위한 문서화 도구
HIPO(히포) 차트란?
HIPO (Hierarchy plus Input Process Output) 차트는
하향식(Top-down) 설계 방식을 지원하는 문서화 도구로,
시스템을 기능 중심으로 계층화해서 표현합니다.
✅ 보기별 설명
보기 문장옳은지 여부설명
| HIPO 차트 종류에는 가시적 도표, 총체적 도표, 세부적 도표가 있다 | ✅ 맞음 | HIPO는 시스템 구조를 여러 단계로 나누어 표현함 |
| 충분한 사전 지식과 학습이 없으면 이해하기 어렵다 | ✅ 맞음 | 구조화 문서 기반이므로 초보자에겐 다소 복잡할 수 있음 |
| 기능과 자료의 의존관계를 동시에 표현할 수 있다 | ❌ 틀림 | HIPO는 기능 중심으로만 표현하며, **자료 흐름(데이터 간 의존)**은 표현하기 어려움 |
| 하향식 소프트웨어 개발을 위한 문서화 도구 | ✅ 맞음 | 시스템을 위에서 아래로 나누며 설계하는 방식과 잘 맞음 |
🔍 HIPO와 혼동 주의
- HIPO는 구조적(기능 중심) 표현 도구임
- **자료 흐름도(DFD)**는 기능 + 데이터 흐름 표현 가능
- 따라서 "기능과 자료의 의존관계를 동시에 표현한다"는 설명은 DFD에 가까운 설명
도구 이름 전체 이름 중심 개념 특징 장점 단점
| HIPO | Hierarchy plus Input-Process-Output | 기능(처리 절차) 중심 | 하향식(top-down)으로 시스템 기능을 계층 구조로 표현 | 설계 문서화에 적합, 구조적 시스템 설계 강조 | 데이터 흐름 표현 불가, 초보자에겐 어려움 |
| DFD | Data Flow Diagram | 데이터 흐름 중심 | 시스템 내의 데이터 이동 경로와 처리 과정을 시각화 | 데이터 중심 분석에 강함, 사용자 이해 쉬움 | 제어 흐름 표현 어려움, 순차 처리 표현 부적절 |
| NS 차트 | Nassi-Shneiderman Chart | 제어 흐름 중심 | 순차, 선택, 반복을 블록 형태로 표현 | 프로그램 논리 표현에 직관적, 구조적 프로그래밍에 적합 | 복잡한 로직 표현 시 가독성 떨어짐 |
| PAD | Problem Analysis Diagram | 처리 절차(논리) 중심 | 처리 흐름을 블록으로 표현하여 절차를 쉽게 분석 | 알고리즘 설명과 디버깅에 용이 | 구조화 설계와는 조금 거리가 있음 |
| 순서도 (Flowchart) | Flowchart | 처리 흐름 중심 | 조건 분기, 반복 등을 도형으로 표현 | 이해 쉽고 문서화 간편 | 복잡한 프로그램일수록 혼잡해짐, 유지보수 어려움 |
핵심 기준별 정리
| 기준 | 해당 도구 |
| 기능 중심 (처리 단계 위주) | HIPO, PAD |
| 데이터 흐름 중심 | DFD |
| 제어 흐름 중심 (선택·반복) | NS 차트, 순서도 |
| 계층 구조 표현 | HIPO |
| 사용자와 커뮤니케이션 용이 | DFD, 순서도 |
✅ 1. HIPO 차트 (기능 중심, 계층적 설계)
복사편집
📄 총체적 도표 └─ 학생 성적 처리 시스템 📄 세부 도표 ├─ 성적 입력 ├─ 평균 계산 └─ 결과 출력
입력 → 처리 → 출력 과정을 기능 단위로 계층적으로 표현
(입력/계산/출력 각각이 모듈로 구분)
✅ 2. DFD (데이터 흐름도)
scss
복사편집
[사용자] → (성적 입력) → [성적 처리 시스템] → (평균) → [출력] ↑ ↓ [성적 데이터 저장소]
데이터가 어떻게 흐르는지 시각화
사용자 → 시스템 → 저장소 → 출력 방향이 강조됨
✅ 3. NS 차트 (제어 흐름 블록 형태)
css
복사편집
[성적 입력] ↓ [평균 계산] ↓ [출력]
블록 구조로 순차 흐름을 단순하고 직관적으로 표현
조건 분기나 반복이 있다면, 그에 맞는 블록으로 확장 가능
✅ 4. PAD (문제분석도, 처리 절차)
css
복사편집
[시작] ↓ [성적 입력] ↓ [합계 계산 반복문] ↓ [평균 계산] ↓ [결과 출력] ↓ [종료]
실제 처리 절차를 단계별로 도식화하여 문제해결 흐름 분석에 초점
✅ 5. 순서도 (Flowchart)
css
복사편집
[시작] ↓ [성적 입력] ↓ [총합 계산 반복] ↓ [평균 = 총합 / 인원수] ↓ [결과 출력] ↓ [종료]
도형(사각형, 마름모 등)으로 논리 흐름을 도식화
조건 분기에는 마름모 사용, 반복과 분기 표현에 용이
11. 코드 설계에서 코드화 대상 항목의 성질, 즉 길이, 넓이, 부피, 지름, 높이 등의 물리적 수치를 그대로 코드에 적용시키는 방식의 코드는?
- 연상 코드
- 블록 코드
- 순차 코드
- 표의 숫자 코드
코드 종류 설명 예시
| 순차 코드 | 단순히 순서대로 번호 부여 | 제품 생산 순서: 1, 2, 3, 4...의자 1호, 2호, 3호 |
| 블록 코드 | 번호를 덩어리(블록)로 나눠 그룹을 구분 | 100 |
| 연상 코드 | 뜻을 쉽게 떠올릴 수 있게 만든 코드 | 원형 = CIR (circle), 사각형 = SQR (square) |
| 표의 숫자 코드 | 사전에 정의된 수치별 대응 표를 보고 부여 | 길이 10cm = 01, 20cm = 02, 30cm = 03 등※ 코드에 수치가 아닌 대응된 번호가 들어감 |
| 계층 코드 | 큰 분류 → 중간 → 작은 항목 계층적으로 표현 | 1-2-3: 가구-의자-회전의자(카테고리 구조 표현) |
| 조합 코드 | 여러 속성 값을 조합해서 만든 코드 | A01-B02-C03: (종류)-(색상)-(사이즈)예: 책상-검정-L사이즈 |
12. 에자일 소프트웨어 개발 기법의 가치가 아닌것은?
- 계획을 따르기 보다는 변화에 대응하는 것에 더 가치를 둔다
- 실제 작동하는 소프트웨어보다는 이해하기 좋은 문서에 더 가치를 둔다
- 계약 협상보다는 고객과의 협업에 더 가치를 둔다
- 프로세스의 도구보다는 개인과 상호작용에 더 가치를 둔다
비교 항목 에자일이 더 중요하게 여기는 것 덜 중요하게 여기는 것
| 개인과의 상호작용 | ✅ 개인과 상호작용 | ❌ 프로세스와 도구 |
| 작동하는 소프트웨어 | ✅ 작동하는 소프트웨어 | ❌ 문서화된 문서 |
| 고객과의 협업 | ✅ 고객과의 협업 | ❌ 계약 협상 |
| 변화에 대응 | ✅ 변화에 대응 | ❌ 계획을 따르는 것 |
| 1. | 고객이 원하는 기능을 자주 제공해서 만족시키는 것이 가장 중요하다. |
| 2. | 요구사항이 변해도 유연하게 받아들인다. 오히려 변화는 좋은 것이다. |
| 3. | **짧은 주기(보통 1~4주)**로 동작하는 소프트웨어를 반복해서 자주 만든다. |
| 4. | 개발자와 고객은 매일 같이 협업하며 소통한다. |
| 5. | 의욕 있는 사람들에게 일을 맡기고, 믿고 지원해준다. |
| 6. | 가장 효과적인 방법은 직접 얼굴을 보고 이야기하는 것이다. |
| 7. | 소프트웨어가 잘 작동하는 것이 성공의 핵심 지표이다. |
| 8. | 지속 가능한 개발을 한다. 개발자는 지치지 않도록 일정하게 일한다. |
| 9. | 기술적인 완성도와 좋은 설계에 계속 신경 쓴다. |
| 10. | 단순함이 최고다. 불필요한 일은 줄이자. |
| 11. | 최고의 결과는 스스로 조직된 팀에서 나온다. (팀원들이 자율적으로 움직임) |
| 12. | 정기적으로 팀은 어떻게 더 잘할 수 있을지 돌아보고, 개선해 나간다. |
13. Rayleigh-Norden 곡선의 노력 분포도를 이용한 프로젝트 비용 산정 기법은?
- Putnam 모형
- 델파이 모형
- COCOMO 모형
- 기능 점수 모형
① Putnam 모형 (Rayleigh-Norden 곡선 기반)
- 개념: 프로젝트에 투입되는 노력 분포가 Rayleigh 곡선을 따른다는 전제 하에, 개발 기간, 규모, 인력의 관계를 수식으로 표현한 비용 산정 모형
- 주요 특징:
- 시간에 따라 인력 투입이 점점 증가했다가 줄어드는 형태 (종 모양 곡선)
- 대규모 프로젝트에 적합
- 대표 공식:
② 델파이 모형 (Delphi Model)
- 개념: 여러 전문가들에게 익명으로 추정치를 받고, 여러 차례 반복 설문을 통해 합의된 예측값을 도출하는 방식
- 주요 특징:
- 직관에 의존하는 경험 기반 방법
- 통계적 평균보다는 전문가들의 지속적인 피드백을 통한 조율
- 수치보다는 의견 조율에 적합
③ COCOMO 모형 (Constructive Cost Model)
- 개념: **개발 규모(LOC: 코드 라인 수)**에 따라 노력, 비용, 개발 기간을 계산하는 알고리즘적 모델
- 주요 특징:
- Boehm 박사가 제안
- 프로젝트 유형(Organic, Semi-detached, Embedded)에 따라 다른 계수 사용
- 세 가지 단계:
- 기본형(Basic)
- 중간형(Intermediate)
- 상세형(Detailed)
④ 기능 점수 모형 (Function Point Model)
- 개념: 프로그램의 기능 수와 복잡도 등을 고려하여 점수화(Function Point) 하고, 이를 기반으로 비용을 산정
- 주요 특징:
- LOC보다 기능 중심 평가
- 사용자 입장에서 본 입력, 출력, 질의, 파일, 인터페이스 등의 수치를 바탕으로 계산
- 언어에 독립적이며 유지보수 예측에도 유용
| 구분 | Putnam 모형 | 델파이 모형 | COCOMO 모형 | 기능 점수 모형 |
| 기반 | Rayleigh 곡선 (인력 노력 분포) | 전문가의 경험과 직관 | LOC (코드 라인 수) | 기능 점수 (Function Point) |
| 특징 | 노력-기간 관계 수식화 | 반복 피드백으로 합의 도출 | 프로젝트 유형별 계수로 계산 | 사용자 기능 중심 분석 |
| 산정 방식 | 수학적 모델 사용 | 정성적 추정, 합의 기반 | 수학적 공식 + 경험 계수 | 기능 수치에 가중치 곱 |
| 장점 | 대규모 프로젝트에 적합 | 다양한 전문가 의견 반영 | 구조적이고 반복 가능 | 언어 독립, 유지보수 예측에 강함 |
| 단점 | 초기 파라미터 결정이 어렵다 | 주관적, 신뢰도 차이 있음 | LOC 추정이 필요, 변경에 민감 | 기능 정의 어려우면 정확도 낮음 |
| 적용 사례 | 정부기관 대형 개발 | 일정 예측, 초기견적 | 일반 개발 프로젝트 | 사용자 중심의 분석 필요 시 |
14. 객체지향의 주요 개념에 대한 설명으로 틀린 것은?
- 상속은 상위 클래스에서 속성이나 연산을 전달받아 새로운 형태의 클래스로 확장하여 사용하는 것을 의미
- 객체는 실세계에 존재하거나 생각할 수 있는 것을 의미한다
- 캡슐화는 두개 이상의 객체(클래스)들이 상호 참조하는 관계이다
- 다형성은 상속받은 여러 개의 하위 객체들이 다른 형태의 특성을 갖는 객체로 이용될 수 있는 성질이다
보기 맞는 설명인지 이유
| ① 상속은 상위 클래스에서 속성이나 연산을 전달받아 새로운 형태의 클래스로 확장하여 사용하는 것을 의미 | ✅ 맞음 | 상속(Inheritance)은 기존 클래스(부모)의 특성을 물려받아 새로운 클래스를 만드는 것 |
| ② 객체는 실세계에 존재하거나 생각할 수 있는 것을 의미한다 | ✅ 맞음 | 객체(Object)는 사람, 책상, 개념 등 구체적 또는 추상적 대상을 의미 |
| ③ 캡슐화는 두개 이상의 객체(클래스)들이 상호 참조하는 관계이다 | ❌ 틀림 | 캡슐화(Encapsulation)는 데이터와 메서드를 하나로 묶고, 외부에서 직접 접근 못하게 숨기는 것 |
| ④ 다형성은 상속받은 여러 개의 하위 객체들이 다른 형태의 특성을 갖는 객체로 이용될 수 있는 성질이다 | ✅ 맞음 | 다형성(Polymorphism)은 같은 이름의 메서드가 객체에 따라 다르게 동작하는 특성 |
| 캡슐화 (Encapsulation) | 데이터(속성)와 기능(메서드)을 클래스 내부에 숨기고, 필요한 기능만 외부에 공개 | 보안, 모듈화, 유지보수 용이 | 게임 캐릭터의 체력(HP)은 get_hp()로만 확인하고, 외부에서 직접 바꿀 수 없음 |
| 상속 (Inheritance) | 기존 클래스의 속성과 기능을 자식 클래스가 물려받음 | 재사용성, 유지보수 효율 | Animal 클래스를 상속받아 Dog, Cat 클래스 생성 |
| 다형성 (Polymorphism) | 같은 이름의 메서드가 클래스에 따라 다르게 동작 | 확장성, 유연성 | speak() 함수가 Dog에선 "멍멍", Cat에선 "야옹" |
| 추상화 (Abstraction) | 불필요한 세부 구현은 감추고, 필요한 기능만 보여줌 | 복잡도 감소, 사용 편의성 | 자동차 객체는 내부 엔진 작동은 몰라도 start()만 호출하면 됨 |
| 상호 참조(Mutual Reference) | 두 객체가 서로를 참조(가지고 있음) 하는 구조 |
| 순환 참조(Circular Reference) | 객체 A → B, 그리고 B → A처럼 참조가 순환되는 구조 |
15. 웹 애플리케이션 서버 (WAS;Web Application Server)에 대한 설명으로 틀린것은
- 정적인 콘텐츠를 처리하기 위해 사용되는 미들웨어이다
- 클라이언트/서버 환경보다는 웹 환경을 구현하기 위한 미들웨어이다
- 미션-크리티컬한 기업 업무도 JAVA,EJB 컴포넌트 기반으로 구현이 가능하다
- 대표적인 WAS의 종류에는 오라클의 WebLogic, IBM의 WebSphere 등이 있다
먼저, **WAS(Web Application Server)**가 뭔지부터 설명할게요.
개념쉬운 설명
| 웹 서버 (Web Server) | HTML, 이미지 같은 정적인(고정된) 파일을 전달해주는 서버 |
| WAS (웹 애플리케이션 서버) | 로그인, 게시판, 주문 같은 **동적인 기능(계산, DB처리)**을 담당하는 프로그램 서버 |
✅ 보기 분석
보기맞는지?쉬운 설명
| ❌ 정적인 콘텐츠를 처리하기 위해 사용되는 미들웨어이다 | 틀림 | 정적인 파일은 **웹 서버(Apache, Nginx 등)**가 처리하고, WAS는 동적인 기능을 담당해요 |
| ✅ 클라이언트/서버 환경보다는 웹 환경을 구현하기 위한 미들웨어이다 | 맞음 | WAS는 웹 환경(브라우저에서 접속하는 환경)에서 동작하는 서버예요 |
| ✅ 미션-크리티컬한 기업 업무도 JAVA, EJB 컴포넌트 기반으로 구현이 가능하다 | 맞음 | WAS는 중요한 은행/공공 시스템도 Java와 EJB 기술로 구현할 수 있어요 |
| ✅ 대표적인 WAS의 종류에는 오라클의 WebLogic, IBM의 WebSphere 등이 있다 | 맞음 | 둘 다 유명한 상용 WAS입니다 |
✅ WAS, Web Server 차이 그림으로 비유
마치 웹 서버는 문지기, WAS는 요리사라고 볼 수 있어요
[사용자] → [웹 서버] → [WAS] → [DB] 요청: "김민수의 게시판 보여줘!" 웹 서버: "이건 동적이네, WAS야 네가 처리해줘!" WAS: "알겠어, DB에서 민수 글 꺼내서 HTML로 만들어줄게"
✅ 추가 개념: 미들웨어(Middleware)
용어쉬운 정의
| 미들웨어 | 클라이언트와 서버 사이에서 연결을 도와주는 중간 소프트웨어 |
| 예시 | WAS, 메시지 큐, API 게이트웨이 등 |
✅ 마무리 요약
| 구분 | 웹 서버 | WAS |
| 처리 대상 | 정적 파일 (HTML, 이미지) | 동적 처리 (로그인, 게시판, DB연동) |
| 예시 | Apache, Nginx | Tomcat, WebLogic, WebSphere |
| 역할 | 클라이언트에게 파일 제공 | 비즈니스 로직 처리, 데이터베이스 연결 |
| 구성 요소 | 설명 | 역할 |
| Django | 웹 애플리케이션 코드 (Python) | 비즈니스 로직 |
| Gunicorn | WSGI 서버, 동기 처리 | 🧠 WAS 역할 (표준) |
| Uvicorn | ASGI 서버, 비동기 처리 | 🧠 WAS 역할 (비동기 Django 앱용) |
| Daphne | Django Channels용 서버 | 🧠 WebSocket 지원 WAS |
| Nginx | 웹 서버 | 클라이언트 요청 정리, 정적 파일 처리 |
| 항목 | Java 생태계 | Python Django 생태계 |
| 웹 서버 | Apache | Nginx |
| WAS | Tomcat | Gunicorn / Uvicorn / Daphne |
| 앱 | JSP, Servlet | Django App |
| 실행 방식 | Java 클래스 | Python 함수(WGSI/ASGI callable) |
1. 미션 크리티컬 시스템 아키텍처 예시
🏦 예: 은행의 실시간 계좌 이체 시스템
[사용자]
↓ [Nginx 웹 서버 (이중화)]
↓ [WAS 서버군 (멀티 인스턴스)]
↓ [DB 클러스터 (마스터-슬레이브)]
↓ [트랜잭션 로그 + 백업 시스템]
계층구성특징
| 프론트 | Nginx 2대 이상 | 리버스 프록시 + 로드밸런싱 |
| 애플리케이션 | WAS 여러 개 (Tomcat/Gunicorn) | 여러 인스턴스가 같은 로직 처리 |
| 데이터베이스 | DB 이중화 (예: PostgreSQL Master-Slave) | 장애 발생 시 자동 Failover |
| 보조 시스템 | 백업, 로깅, 모니터링 시스템 | 장애 감지 및 자동 복구 |
✅ 2. 미션 크리티컬 시스템을 위한 필수 설계 개념
용어의미쉽게 설명
| HA (High Availability) | 고가용성, 24시간 끊김 없이 작동하도록 설계 | 중단 없이 계속 돌아가는 시스템 |
| 이중화 (Redundancy) | 하드웨어나 소프트웨어를 예비로 하나 더 준비 | A 서버가 죽으면 B 서버가 대신 |
| 로드 밸런싱 | 요청을 여러 서버로 분산 | 트래픽 쏠림 방지, 성능 향상 |
| Failover | 시스템 장애 시 자동으로 예비 시스템으로 전환 | A 서버가 멈추면 B가 자동 동작 |
| Heartbeat | 시스템이 살아 있는지 주기적으로 확인하는 신호 | 감시 시스템에서 ‘살아 있나?’ 체크 |
| Disaster Recovery (DR) | 재해 복구 시스템 (지진, 화재 등 대비) | 데이터센터 통째로 날아가도 복구 가능 |
| Backup & Restore | 주기적 데이터 백업 및 복원 계획 | 실시간 또는 일정 주기 백업 필요 |
| 모니터링/알림 | 시스템의 상태를 실시간 체크하고 장애 발생 시 경고 | 예: Grafana + Prometheus, Zabbix 등 |
✅ 미션 크리티컬 시스템은 어떻게 구성해야 할까?
구성 요소설계 전략
| 서버 | Active-Standby, Active-Active 구성 |
| DB | 마스터-슬레이브 또는 클러스터링 (예: PostgreSQL + Patroni) |
| 네트워크 | 이중 네트워크 경로 + 로드밸런서 (예: AWS ELB, HAProxy) |
| 배포 | 무중단 배포 (Blue-Green 또는 Canary 방식) |
| 클라우드 | AZ/Region 분산 구성 (AWS, Azure 등에서 지리적 이중화) |
✅ 실제 예시: AWS에서의 구성
[Route 53 (DNS)] ↓
[ALB (로드 밸런서)]
↓ ↓
[EC2-A] [EC2-B] ← WAS 이중화
↓ ↓
[RDS Multi-AZ (마스터-슬레이브)] ← DB 이중화
✅ 마무리 요약
핵심설명
| 미션 크리티컬 시스템 | 반드시 멈추면 안 되는 시스템 (은행, 의료, 항공 등) |
| 설계 방식 | 이중화, 고가용성, 로드밸런싱, 장애 자동 복구 |
| 사용 기술 | Nginx, Gunicorn, PostgreSQL Replication, AWS ELB, Heartbeat, DR 센터 등 |
16. 유스케이스 다이어그램(Use Case Diagram)의 구성요소가 아닌것
- System
- Actor
- Operation
- UseCase
✅ UML 다이어그램 종류 정리표
분류다이어그램 이름설명주요 목적 / 예시
| 1. 구조 다이어그램 (정적 구조) |
클래스 다이어그램 | 클래스 간 관계, 속성, 메서드 등을 표현 | 설계 구조, 상속 관계, 인터페이스 정의 등 |
| 객체 다이어그램 | 실제 객체들의 상태와 관계를 표현 | 클래스 다이어그램의 인스턴스 예시 | |
| 컴포넌트 다이어그램 | 시스템의 컴포넌트 구성 표현 | 모듈, 라이브러리 등 소프트웨어 구성요소 설계 | |
| 배치 다이어그램 | 하드웨어/소프트웨어 배치 구조 표현 | 서버, 노드, 실행환경 등 배포 구조 | |
| 패키지 다이어그램 | 클래스나 컴포넌트를 패키지 단위로 묶어서 표현 | 프로젝트 모듈화 구조 | |
| 복합 구조 다이어그램 | 객체 내부 구성과 포트/연결 표현 | 복잡한 객체 내부 동작 표현 | |
| 프로파일 다이어그램 | 커스텀 UML 확장 정의 | DSL 확장 시 사용 (잘 쓰이지 않음) |
분류다이어그램 이름설명주요 목적 / 예시
| 2. 행위 다이어그램 (동작 흐름) |
유스케이스 다이어그램 | 사용자와 시스템 간 상호작용 표현 | 로그인, 회원가입 등 시스템 기능 목록 |
| 활동 다이어그램 | 조건 흐름 + 작업 순서 표현 | 업무 흐름, 조건 분기, 알고리즘 시각화 | |
| 상태 다이어그램 | 객체 상태 변화와 이벤트 반응 표현 | 게임 캐릭터 상태: Idle → Run → Attack | |
| 시퀀스 다이어그램 | 객체 간 메시지 전달 시간 순서대로 표현 | 클라이언트 ↔ 서버 요청/응답 흐름 | |
| 커뮤니케이션 다이어그램 | 객체 간 메시지 흐름 + 연결 구조 표현 | 시퀀스 다이어그램과 유사, 관계 중심 | |
| 상호작용 개요 다이어그램 | 여러 시퀀스 다이어그램을 묶어 표현 | 복잡한 시나리오 요약 | |
| 타이밍 다이어그램 | 시간에 따른 객체 상태 변화 표현 | 실시간 시스템의 시간 기반 상태 변화 |
✅ 정리 요약표 (간단 버전)
그룹목적대표 다이어그램
| 구조 다이어그램 | 시스템 구조와 관계 표현 | 클래스, 객체, 컴포넌트, 배치 |
| 행위 다이어그램 | 시스템 기능과 흐름 표현 | 유스케이스, 활동, 상태 |
| 상호작용 다이어그램 (행위의 하위) |
객체 간 메시지 흐름 중심 | 시퀀스, 커뮤니케이션, 타이밍 |
Operation은 클래스 다이어그램에서 메서드를 뜻함
17. 폭포수 모형의 특징으로 거리가 먼 것은? 2
- 순차적인 접근방법을 이용한다
- 나선형 모형의 단점을 보완하기 위한 모형이다
- 단계적 정의와 산출물이 명확하다
- 모형의 적용 경험과 성공사례가 많다
18. 송수신 데이터의 처리 방식 중 대량의 데이터를 처리할 때 사용하는 방식은 3
- 실시간 방식
- 분산 처리 방식
- 배치 방식
- 지연 처리 방식
| ❌ 실시간 방식 | 요청이 들어오면 즉시 응답/처리 | 온라인 결제, 게임 서버, 실시간 센서 데이터 |
| ❌ 분산 처리 방식 | 데이터를 여러 컴퓨터에 나눠서 동시에 처리 | 대규모 데이터 분석 (Hadoop, Spark 등) |
| ✅ 배치 방식 | 데이터를 일정량 모아서 한 번에 일괄 처리 | 월말 급여 계산, 야간 로그 분석 |
| ❌ 지연 처리 방식 | 요청 후 일정 시간 지연 후 처리 | 예약 발송, 알림 딜레이 처리 등 |
19. 결합도(Coupling)에 대한 설명으로 틀린 것은
- 데이터 결합도(Data Coupling)는 두 모듈이 매개 변수로 자료를 전달할 때 자료 구조 형태로 전달되어 이용될때 데이터가 결합되어 있다고 한다
- 내용 결합도(Content Coupling)는 하나의 모듈이 직접적으로 다른 모듈의 내용을 참조할 때 두 모듈은 내용적으로 결합되어 있다고 한다
- 공통 결합도(Common Coupling)는 두 모듈이 동일한 전역 데이터를 접근한다면 공통 결합되어 있다고 한다
- 결합도(Coupling)는 두 모듈 간의 상호작용, 또는 의존도 정도를 나타내는 것이다
결합도 종류 설명 예시 결합 강도
| 1. 데이터 결합도 (Data Coupling) | 단순 데이터 값만 인수로 전달함 | func(int a, int b) | ✅ 가장 낮음 (좋음) |
| 2. 스탬프 결합도 (Stamp Coupling)또는 구조 결합도 | 구조체나 배열 같은 자료구조 전체를 전달함 | func(Student s) | ⚠️ 일부만 쓸 거면 과한 전달 |
| 3. 제어 결합도 (Control Coupling) | 제어 플래그를 전달해서 흐름 제어에 영향 줌 | func(mode=1) → 함수 내부 if문 | ❌ 모듈 독립성 저하 |
| 4. 외부 결합도 (External Coupling) | 외부 파일, DB, 하드웨어 등 공유 | 두 모듈이 같은 설정 파일 참조 | ❌ 테스트 어려움 |
| 5. 공통 결합도 (Common Coupling) | 전역 변수나 공통 메모리 공간 사용 | 전역 리스트를 두 함수가 공유 | ❌ 데이터 충돌 위험 |
| 6. 내용 결합도 (Content Coupling) | 한 모듈이 다른 모듈 내부 직접 참조 | A 모듈이 B의 변수/함수 강제 접근 | ❌❌ 가장 나쁨 |
결합도는 “낮을수록 좋다”
→ 데이터 → 스탬프 → 제어 → 외부 → 공통 → 내용
✏️ "데스제외공내" (데-스-제-외-공-내)
20. CASE(Computer Aided Software Engineering)의 주요기능으로 옳지 않은 것은
- S/W 라이프 사이클 전 단계의 연결
- 그래픽 지원
- 다양한 소프트웨어 개발 모형 지원
- 언어 번역
CASE란? (쉽게 말해서)
소프트웨어를 만들 때, 사람이 손으로 일일이 하지 않고,
컴퓨터가 도와주거나 자동으로 해주는 도구예요.
📦 CASE를 진짜 생활 예로 바꿔보면?
일반 상황CASE와 비교
| 건축가가 손으로 설계도를 그림 | 소프트웨어 개발자가 종이에 요구사항 정리함 |
| 그런데 요즘은 CAD 프로그램으로 자동 설계 | 개발자도 CASE 도구로 설계, 분석을 자동화 |
| 문서를 자동으로 만들어주는 워드 템플릿 | 개발 문서도 자동 생성됨 |
| 건물 구조가 잘못됐는지 CAD에서 자동 체크 | 설계 오류도 CASE가 자동 체크해줌 |
✅ CASE가 하는 일 (쉽게 정리)
CASE가 도와주는 것설명 (예시)
| 📋 요구사항 정리 | 어떤 기능이 필요한지 목록으로 정리함 |
| 📐 설계 다이어그램 그리기 | 클래스 다이어그램, 유스케이스 다이어그램 등 자동 그리기 |
| 🧪 오류 확인 | 설계에 빠진 부분이나 오류 자동으로 검사해줌 |
| 📄 문서 자동 생성 | 명세서, 설계서 등 필요한 문서를 자동으로 만들어줌 |
| 🔁 테스트 코드 생성 | 테스트를 자동화하거나 부분적으로 생성해줌 (하위 CASE 도구) |
✅ CASE 도구 예시
도구 이름설명
| StarUML | UML 설계 도구 (클래스, 시퀀스 다이어그램 그리기) |
| Enterprise Architect | 대기업에서도 쓰는 복합 설계 도구 |
| Visual Paradigm | 요구사항 관리 + 설계 + 코드 생성까지 |
| Rational Rose | IBM의 대표적 CASE 도구 (지금은 구식) |
✅ CASE는 어디에 쓰일까?
- 시스템 분석가 → 요구사항 다이어그램 그릴 때
- 개발자 → 설계한 구조를 코드로 자동 생성할 때
- QA팀 → 테스트 케이스 문서를 자동으로 뽑을 때
구분 이름 뜻 하는 일
| 🟢 Upper CASE | "상위 CASE" | 분석 & 설계 단계 자동화 | 요구사항 정리, 다이어그램 그리기 |
| 🔵 Lower CASE | "하위 CASE" | 구현 & 테스트 단계 자동화 | 코드 생성, 테스트, 배포 도우미 |
| 🟣 Integrated CASE (I-CASE) | 통합 CASE | 전체 개발 단계 통합 | 분석 ~ 구현 ~ 테스트까지 한 번에 |
❗ 하지만 한계도 분명해요
항목설명
| 🔧 비즈니스 로직은 사람이 직접 작성해야 함 | 자동 생성은 뼈대만 만들고, 핵심 알고리즘은 개발자가 직접 작성 |
| 🧩 복잡한 로직/조건/비동기 흐름 표현은 어려움 | 설계 다이어그램으로는 로직 전체를 표현하기 어려움 |
| 🚧 실무에선 자동 코드보다 코드 품질/설계 유연성 중시 | 자동 생성 코드는 너무 정형적이라 커스터마이징 어려움 |
| ⚠️ 협업 중 충돌 발생 가능 | 도구 중심 개발은 유연성이 떨어지고 충돌 관리 어려움 |
✅ 그래서 요즘 추세는?
완전 자동 코딩보다 AI 보조 코딩 + 사람 중심 설계로 넘어가고 있어요.
과거현재
| CASE 도구로 설계 후 자동 생성 | Copilot, GPT 등 AI가 코드 추천 |
| 설계도 위주 개발 | 설계 + 테스트 + 실시간 수정 중심 |
| 자동 코드 생성 = 핵심 | 자동화는 "보조 수단"으로 자리 |
✅ 마무리 요약
- 맞아요! 설계만으로 코드가 생성되면 바이브 코딩처럼 보일 수 있어요.
- 하지만:
- 뼈대만 생성됨 (진짜 핵심은 여전히 사람이 해야 함)
- 실무에서는 자동 생성 코드보다 품질과 유지보수성이 더 중요
- 오늘날엔 CASE + AI 보조 코딩이 조화롭게 사용되는 시대