[학습 일기 #15] 반복문, 함수, 클래스

Ariel_Jeong·2026년 1월 7일

[학습 일기 시리즈]

목록 보기
15/44

부트캠프 과제를 진행하면서 느끼고 있는 가장 큰 변화
“코드를 쓰는 것”에서 “구조를 설계하는 것”으로
문제를 해결하는 방식이 점점 바뀌고 있다는 점이었다.

처음에는

“정해진 목표 출력값을 동일하게 얻기 위해 주목”했다면,

지금은

“이 코드는 어디에 두는 게 맞을까?”
“이 로직은 반복돼도 괜찮은가?”
를 먼저 생각하게 됐다.

이번 글에서는 반복문 → 함수 → 클래스 과제를 풀면서
사고가 어떻게 정리되고 확장됐는지를 서술해보려 한다.


* 모든 과제의 출처는 오즈코딩스쿨에 있음.




1️⃣ 반복문 과제

1.1. 과제의 요구사항 및 출력 템플릿

[캡쳐 1-1. 반복문 과제의 요구사항 및 출력 형식]

해당 과제에서 요구하는 사항은 다음과 같았다.

  • 반복문을 돌며 혈압 분류 기준에 맞춰 각 환자별 분류 및 권고사항 정리하기
  • 응급 처치가 필요한 환자를 발견하면 즉시 감지하여 반복문 중단하고 목표 출력 형태로 출력하기
  • 혈압 등급별 통계 분석하여 출력하기
  • 전체 현황 요약하여 출력하기

위의 요구 사항들을 처리하는 코드를 작성하고 나면
아래의 테스트 데이터를 사용하여 코드의 결과를 확인하게 된다.

[캡쳐 1-2. 기본 데이터]


1.2. 1, 2번 미션 분석

[캡쳐 1-3. 1, 2번 미션에서 내가 작성한 코드와 정답 코드의 비교]

우선 눈에 띄게 다른 점은
나는 미션2에 대한 if문을 들여쓰기를 통해 미션1의 for문에 속해있도록 하여 한 번만 작성하였고,
정답 코드는 따로 분리를 시켜주었다는 것이다.

내가 이렇게 작성해야겠다고 생각했던건
반복문을 돌며 혈압 분류 기준에 맞춰 각 환자별 분류 및 권고사항을 출력하되 --- (1)
응급 처치가 필요한 환자를 발견하면 즉시 감지하여 반복문 중단하고 목표 출력 형태로 출력 --- (2)
하라는 의미로 요구사항을 해석했기 때문이며 (2번 기능이 더 중요하다고 판단)
추가로 반복문을 두 번 도는 것보다 한 번에 두 기능을 처리하는 것이 효율적이라고 생각했기 때문이다.

다만, 이렇게 작성했을 시 문제가 되는건
지금 데이터에서는 응급 환자가 맨 마지막에 있어서 미션1의 결과가 정답 코드와 다르지 않은데
만약 중간에 존재했다면 미션1의 결과에도 영향을 끼쳐 다른 결과를 확인하였을 것이다.

이렇듯 관심사 분리, 유지보수 및 확장성의 측면에서는 정답코드가 더 좋은 코드일 것이며
가독성 측면에서도 좋아 실무 코드 기준에서는 정답 코드가 더 선호되는 형태일 것으로 예상된다.

또한 내가 생각지 못했던 점이
응급 처치 대상이 없는 경우도 출력될 문구를 작성해주면 더 좋았을 것이라는 점이다.


1.3. 3, 4번 미션 분석

[캡쳐 1-4. 3, 4번 미션에서 내가 작성한 코드와 정답 코드의 비교]

3, 4번 미션에서 내가 작성한 코드와 정답 코드를 비교하며 느낀 점은
내가 아직 리스트 컴프리헨션을 활용하는 데 익숙하지 않아 활용을 제대로 하고 있지 못하다는 점이었다.
더욱더 많이 반복해서 작성해 보며 몸에 익히는 연습을 해야 할 것 같다.


1.4. 반복문 과제 출력 결과 비교

결과적으로 출력물은 동일하게 얻었지만, 아직 개념 정리 및 체화가 더 필요하다는 것을 느꼈다.




2️⃣ 함수 과제

2.1. 함수 과제 요구사항 및 템플릿


[캡쳐 2-1. 함수 과제의 요구사항 및 출력 형식]


[캡쳐 2-2. 기본 데이터 및 테스트 데이터]

이번 과제에서는 총 3개의 함수를 정의하고 출력해보는 내용이었다.

  • parameterhour로 두고 예약 가능 여부를 확인하여 결과를 tuple반환하는 함수 --- (1)
  • 함수(1)을 사용하여 반환된 값을 가지고 예약이 가능하면 예약 리스트에 딕셔너리 형태로 추가, 불가능하면 구체적인 실패 이유를 반환하여 결과 메세지를 문자열로 반환하는 함수 --- (2)
  • 예약 현황시간 순으로 출력하는 함수 --- (3)

그럼 이번에는 어떤 점들이 달랐는지 확인해 보자.


2.2. 1번 함수 코드 비교


[캡쳐 2-3. 1번 미션에서 내가 작성한 코드와 정답 코드의 비교]

1번 함수에서는 변수명을 다르게 설정했다는 점을 빼면 거의 동일한데,
튜플을 표현할 때 괄호() 사용 여부만 달랐다.
파이썬에서는 괄호를 쓰지 않고 콤마,만 사용해도 튜플로 인식한다는 것을 잊지 말자!


2.3. 2번 함수 코드 비교


[캡쳐 2-4. 2번 미션에서 내가 작성한 코드와 정답 코드의 비교]

2번 함수를 정의하는 코드에서 달랐던 점은
정답코드에서는 먼저 예약 가능 여부와 상태를 담고 있는 튜플(1번 함수의 반환값)을 언패킹하여
예약 가능한 경우와 불가능한 경우를 먼저 크게 나누고,
불가능한 경우 안에서 다시 if-elif로 나눠줬다는 점이다.

가독성 측면에서도 정답 코드가 깔끔하지만, 이후 가장 큰 것을 깨달았다.

나는 if문을 돌 때마다 계속 1번 함수를 호출하도록 만들고 말았다.

그렇게 효율성 있는 코드를 중요하게 생각했던 내가
정말 비효율적인 방식으로 코드를 사용하고 있었던 것이다.

잊지 말자, 함수의 장점은 재사용성에 있다.


2.4. 3번 함수 코드 비교


[캡쳐 2-5. 3번 미션에서 내가 작성한 코드와 정답 코드의 비교]

3번 미션에서 가장 중요한 점예약 현황을 시간 순으로 출력해야한다는 점이다.
그렇기에 가장 먼저 예약 리스트를 시간을 기준으로 오름차순 정렬해야한다.
key값을 기준으로 리스트를 정렬하는 문법이 바로 떠오르지 않았기 때문에
좀 더 반복해서 체화시켜야할 필요성을 느꼈다.


2.5. 출력 결과 비교


[캡쳐 2-6. 출력 결과 비교]

코드가 달랐어도 출력은 동일하게 나왔음을 확인할 수 있다.
하지만 항상 더 좋은 코드란 어떤 것인지 고민하자!




3️⃣ 클래스 과제

클래스는 내가 부트캠프를 시작하기 전 혼자 예습했을 때에도 가장 어려워했던 개념이었는데
역시 과제를 풀면서도 코드 작성이 쉽지 않았다.
계속 반복해서 작성해서 감을 잃지 않도록 해야할 것 같다.

3.1. 과제 요구사항 및 템플릿


[캡쳐 3-1. MedicalStaff 클래스에 대한 속성 및 메서드 요구사항]


[캡쳐 3-2. Nurse 클래스에 대한 속성 및 메서드 요구사항]


[캡쳐 3-3. Doctor 클래스에 대한 속성 및 메서드 요구사항]

MedicalStaff 클래스부모 클래스로서 존재하고,
Nurse, Doctor 클래스MedicalStaff 클래스의 속성 및 메서드를 상속받는 자식 클래스의 형태로
코드를 작성하는 것이 이 과제의 큰 틀이었다.


[캡쳐 3-4. 해당 과제의 목표 출력 형식]

위의 목표 출력 형식에 사용된 문구를 참고하여 각 상황에 따른 반환값을 입력해 주었다.


3.2. 코드 작성 비교


[캡쳐 3-5. 내가 작성한 코드와 정답 코드 비교]

여기서는 Nurse 클래스의 환자 배정 메소드를 정의하는 코드에서 다른 점이 발견되었는데,

나는 환자 이름이 담당 리스트 안에 이미 존재하는지 여부를 bool타입으로 받는 변수명을 만들어주었고
해당 변수명을 사용하여 환자가 배정이 되는 조건과 배정이 되지 않는 조건으로 나누어 코드를 작성하였다.

정답 코드에서는 나와는 다르게 근무중인 경우와 근무중이 아닌 경우로 우선 나누고
중복 여부를 판단하여 배정되는 경우와 배정이 되지 않는 경우를 나누어 주었다.


🧩 내 방식의 경우(중복 여부를 has_patient 변수로 bool 저장 후 조건 분기)

장점

  • “중복 여부”를 변수명으로 직관적으로 보여줌(가독성 측면에서 좋아보임)
  • 복잡한 조건식에서 patient_name in self.patients를 여러 번 쓰는 것보다 깔끔해질 수 있음

단점

  • “근무 상태 + 중복 여부”를 한 번에 묶어 처리하면서, 조건이 늘어나면 중첩이 깊어질 위험이 있음(유지 보수 측면에서 떨어짐)
  • has_patient = True if ... else False
    사실 has_patient = patient_name in self.patients로 더 간단히 쓸 수 있음

📘 정답 방식(먼저 근무 상태를 가드로 쳐내고 → 그 다음 중복 체크)

장점

  • 실패 조건을 먼저 제거(중첩도 얕아지고, 코드를 빠르게 이해 가능)
  • 가독성 · 유지보수에 유리(조건이 늘어나도 위에서부터 하나씩 차단 가능, 실무에서 협업 시 선호)

단점

  • 조건 간의 ‘관계’가 분산된다
    (근무 상태와 중복 여부가 서로 어떤 의미적 관계를 가지는지 한눈에 파악하기는 힘듦)


3.3. 출력 결과 비교

요구 사항대로 잘 출력되는 것을 확인할 수 있다.
다만, 앞으로 코드를 작성할 때 유지, 보수의 측면에 좀 더 좋은 코드를 고민하면서 작성해야할 것 같다.

profile
R&D 분야의 경험을 토대로 커리어 확장에 도전중인 개발꿈나무입니다.

0개의 댓글