sinequanon

[우아한테크코스] 8기 BE 최종 합격 후기(+자소서)

sinequanon — Sat, 4 Jul 2026 15:54:11 +0900

우테코에 최종합격하고 후기 작성하겠다고 마음을 먹었었지만, 미루고 미루다 드디어..? 글을 쓴다

레벨2가 끝나고 2주 간 방학이 시작됐다.

내가 어떤 마음으로 우테코를 준비했는지 돌아보면서 앞으로 남은 우테코 생활도 화이팅해야겠다는 마음을 먹었다.

1. 우테코 준비 시작

난 우아한테크코스가 어떤 곳인지 몰랐다.

대학생 시절 막연하게 내가 어떤 개발자가 되고 싶은지 고민없이 1학년부터 학부 연구생 활동과 학교 공부만 했다.

그렇게 4학년 됐고 늦게, 개발자로 취업하고 싶은데 뭘 해야는지 고민하기 시작했다.

많은 방향이 있겠지만 그 당시 백엔드 개발자를 해야겠다는 걸 느꼈다.

운 좋게 지인 중에 우아한테크 캠프 출신 개발자셨는데 내가 백엔드 개발자가 너무 되고 싶다고 하니 우아한테크코스에 지원하라고 추천해주셨다. 그렇게 우테코 준비를 시작했다. 그 때가 접수 마감 3주 전이었다.

준비하면서 했던 것들

자바 공부하기(자바 버전 중요하다고 생각해서 문의드렸다)
자바 코딩 컨벤션 공부 https://naver.github.io/hackday-conventions-java/
오브젝트 책 읽기(객체지향 공부하기)
https://www.youtube.com/watch?v=dJ5C4qRqAgA 영상 보기
자동차 경주, 로또, 숫자 야구 풀어보기
마크다운 사용법 공부: https://gist.github.com/ihoneymon/652be052a0727ad59601
깃 커밋 컨벤션 공부
참고 했던 블로그 중 : https://velog.io/@pengoose_dev/%ED%94%84%EB%A6%AC%EC%BD%94%EC%8A%A4-%EA%B8%80%EC%93%B0%EA%B8%B0-1-%EA%B8%B0%EB%8A%A5%EB%AA%85%EC%84%B8%EC%84%9C

(준비하면서 적었던 것 중에 이런 게 있네...;;)

2. 자소서 작성하기

올해 자소서 양식은 작년과 많이 달랐다. 자소서 문항은 1개(10,000자)였다.

가장 깊이 몰입했던 도전 경험이 무엇인가?
왜 그걸 했고, 어떤 어려움이 있었고, 어떤 실패와 좌절이 있었고, 어떻게 극복했고, 나를 어떻게 변화시켰는가?

자소서가 매우 중요하다는 소문??을 듣고 엄청 공들여서 작성했다.

지금 생각해봐도 자소서가 매우 중요한 것 같다.

누군가 나에게 우테코 준비할건데 뭐 할지 물어본다고 일주일동안 아무것도 안 하고 자소서쓰는데 집중하라고 할 것 같다!!

나의 몰입 경험은 "1년간 영어 공부 몰입"이었다.

내가 몰입했던 경험을 하나의 스토리로 만들면 좋을 것 같아서 노션을 켜고 도전을 시작했을 때부터 끝날때까지 모든 과정, 그 당시 감정들을 모두 작성했다. 그러고나니깐 4개의 큰 틀을 만들 수 있었다.

공백 포함해서 5000자 정도 나왔는데, 주변 크루들 자소서 들어보면 글자 수는 상관없고, 자신의 경험을 얼마나 진실되게 쓰는지가 중요한 것 같다.

[ 공허함 속에서 시작한 첫 번째 도전 ]
어떤 마음에 그 도전을 했는지...

[ 나를 변화시킨 1년의 기록 ]
어떤 어려움이 있고, 어떤 실패 좌절이 있고, 어떻게 극복했는지..

[ 성장 후의 팀프로젝트 ]
극복 후 어떤 일을 했는지...

[ 긍정적 사고와 배우는 마음 ]
나를 어떻게 변화시켰고, 어떤 마음 가짐을 살아가는 지 등등

증빙 자료는 노션 페이지를 만들어서 제출했다.

3. 프리코스

1주차: https://sinequanon.tistory.com/5

[BE 8기] 우테코 프리코스 1주차 회고

1주차 미션문자열 덧셈 계산기 구현이다 이번 회차의 목표1. 객체 지향적으로 코드 작성하기 2. 코드 컨벤션과 커밋 컨벤션 익숙해지기 3. **AI 툴 사용하지 않고, 문제 해결하기요구사항을 분석하

sinequanon.tistory.com

2주차: https://sinequanon.tistory.com/6

[BE 8기] 우테코 프리코스 2주차 회고

디스코스에서 포비님의 글을 보고 많은 생각을 하게 되었다.잘할 수 있을까? 잘 모르는 데 어떡하지?라는 걱정만 가득했다. 스스로 잘해야 된다는 생각에만 빠져있었고, 잘하는 사람들과 비교하

sinequanon.tistory.com

3주차: https://sinequanon.tistory.com/7

[BE 8기] 우테코 프리코스 3주차 회고

벌써 3주차 미션이 끝났다. 4,5주차는 새로운 형태로 미션이 진행된다고 하는데 벌써 기대가 된다.3주차 미션: 로또 발매기미션을 시작하기 전,이번 주부터 프로그래밍 요구 사항이 많아지기 시

sinequanon.tistory.com

오픈미션: https://sinequanon.tistory.com/8

[BE 8기] 우테코 프리코스 오픈미션 회고

1. 목표 정하기저는 오픈미션 목표를 크게 두 가지 세웠습니다.첫째, 동물병원 환자 관리 시스템 개발하기둘째, 환자 관리 시스템 기반으로 진료 소견서 자동 생성 기능 개발하기Q. 어떻게 이 주

sinequanon.tistory.com

4. 최종 코테 준비

프리코스 마치고, 잊혀질 때쯤 이메일이 왔다!

최종 코테 준비는 합격 문자를 받고 나서 시작했다. 약 2주 남았었는데, 모든 일정을 취소하고 최종 코테에만 몰두했다.

최종 코테 준비하면서 했던 것

하루종일 독서실에 박혀있기
코드 템플릿 만들기
프리코스 복습하기
이전 기수 최종 코테 기출 문제 풀기
모르는 것들 정리하기
한 줄 회고하기

5. 최종 합격

최종 코테 끝나고 2주 뒤 합격 발표였는데, 군대 시절보다 느리게 갔다...

아무튼 합격 이메일 받고 너무 행복했다ㅠㅠ

6. 잡담

우테코 준비하면서 이런 생각을 많이했다.

객체지향 아무것도 모르는데 어떡하지
TDD가 뭔지 모르는데 어떡하지
요구사항 정의 어떻게 하고 코딩 컨벤션 어떻게 지키고, 회고는 어떻게 하며, 코드 리뷰는 할 줄 모르는데 어떡하지

나는 너무 못하고, 다른 사람들은 다 잘하는 것 같았다.

아이러니한 게 우테코에 들어와서 보니 모든 사람들이 그렇게 생각했다는 것이다.

음.. 모두가 스스로 못한다고 생각하면... 잘하는 사람은 어디있지??

포비가 이런 말씀을 하셨다.

"이미 잘한다면 더 좋은 곳에 가있지 않을까요? 우테코에 올 이유가 없잖아요"

우테코는 잘하는 사람을 원하는 게 아니라 발전 가능성이 있는 사람을 원하는 게 아닐까?

[BE 8기] 우테코 프리코스 오픈미션 회고

sinequanon — Sun, 25 Jan 2026 17:55:22 +0900

1. 목표 정하기

저는 오픈미션 목표를 크게 두 가지 세웠습니다.
첫째, 동물병원 환자 관리 시스템 개발하기
둘째, 환자 관리 시스템 기반으로 진료 소견서 자동 생성 기능 개발하기

Q. 어떻게 이 주제를 선정하게 되었는가?

동물병원와 함께하는 프로젝트에서 진료 소견서 자동 생성 시스템을 개발한 경험이 있습니다. 본 프로그램은 수의시가 진료를 마친 환자에 대한 상태를 작성하는 “진료 소견서”를 자동으로 만들어줍니다. 프로그램을 요약하자면 아래와 같이 동작을 합니다.

PDF 형식인 환자 진료 차트에서 카테고리별로 데이터를 추출
LLM과 이미지 모델을 활용해서 데이터를 요약
요약된 데이터를 pptx 형식의 진료 소견서 템플릿에 삽입

시스템을 개발할 당시에 동물병원 내의 환자 정보 시스템에 접근할 수 없었고 백엔드 지식이 전무했습니다. 그래서 웹이나 애플리케이션으로 제작하지 못했고, CLI 프로그램으로 제작을 했습니다. 로컬 파일 경로에 PDF가 들어오는 지 모니터링하고, 새로운 환자 차트 PDF가 디렉토리에 들어왔을 때 CLI 프로그램을 실행해 진료소견서(pptx)를 만들어주도록 제작했습니다. python monitory.py로 실행하는 콘솔 프로그램이다 보니 많은 아쉬움이 있었습니다. PDF에서 데이터를 추출해서 사용하는 것이 아니라 환자 정보 시스템에 저장된 데이터를 바로 사용하는 것은 어떨까?, 단순 콘솔 프로그램이 아니라 진료 소견 요약 시스템을 웹 서비스로 제작하면 어떨까?라는 호기심으로 해당 주제를 선정하게 되었습니다. 그리고 아직 웹 서버 개발 경험이 아예 없었기 때문에 이번 기회를 통해 경험하면서 배우는 시간으로 만들 수 있겠다고 생각했습니다.

개발했던 진료 소견서 자동 생성 시스템

https://github.com/SineQunNon/PerfectS

GitHub - SineQunNon/PerfectS: 진료 소견서 자동생성 프로그램

진료 소견서 자동생성 프로그램. Contribute to SineQunNon/PerfectS development by creating an account on GitHub.

github.com

2. 계획 세우기 - 11월 5일(수)

목표를 세웠으니, 구체적으로 어떤 과정으로 목표를 달성하지에 대한 일정을 세웠습니다.

수의사 도메인 정리하기
요구사항 분석하기
DB 테이블 정의서 작성하기
기능 명세서 작성하기
에러 코드 정의하기
API 명세서 작성하기
1차 기능 구현하기(MVP) → 기본적인 CRUD 연산 구현하기
중간 점검하기(리팩토링)
2차 기능 구현하기 → AI 기능 추가하기!
회고 작성하기

3. 수의사 도메인 정리하기 - 11월 5일(수)

실제로 진료 차트 데이터에는 엄청나게 많은 종류의 데이터를 포함합니다. 실제 동물병원에서 사용하는 데이터를 모두 시스템에 적용하고 싶지만 일정상 모두 적용한다면 2주간 설계만 하다고 끝날 것 같다고 판단했습니다. 그래서 최대한 구체적인 내용은 빼고, 기본적인 내용만 간추려서 환자 정보 시스템을 제작하기로 했습니다.

4. 요구사항 분석하기 - 11월 5일(수)

유비쿼터스 언어라는 개념을 접했습니다. 환자 정보 시스템을 개발할 때 도메인 전문가 관점으로 작성하고, 개발자 관점에서도 작성하면서 두 개의 개념을 점차 맞춰지는 과정을 만들어보고 싶었습니다. 하지만 이미 제 머릿속은 개발자 입장이어서 그런지 도메인 전문가 관점으로 요구사항을 만드는 데는 한계가 있었습니다. 그래도 “~한 기능들이 있어야 해!” 느낌으로 작성을 했고, 그 다음에는 “만약에 이런 기능이 동작 안했을 때는 어떻게 해야 하지?”라는 접근 방식으로 요구사항 명세서를 작성해봤습니다.

[DDD] 유비쿼터스 언어(Ubiquitous Language)의 중요성

[수의사 관리]

수의사 등록
1. 수의사 정보를 등록할 수 있다.
2. 수의사명을 입력받는다.
수의사 조희
1. 등록된 수의사 목록을 조회할 수 있다.

[환자(동물) 정보 관리]

환자 등록
1. 환자 정보를 등록할 수 있다.
2. 환자는 고유한 동물 번호를 가진다.
3. 동물 이름, 보호자명, 품종, 체중, 생일을 입력 받는다.
4. 환자 정보는 모두 포함되어야 한다
환자 조회
1. 등록된 전체 환자 목록을 조회할 수 있다.
환자 정보 수정
1. 동물 번호로 환자를 찾아서 정보를 수정할 수 있다.
2. 동물 번호는 수정할 수 없다.
환자 정보 삭제
1. 환자 정보를 삭제할 수 있다.

[진료 기록 관리]

진료 기록 작성
1. 수의사는 환자에 대한 진료 기록을 작성할 수 있다.
2. 진료 기록에는 날짜를 입력한다.
3. SOAP 형식으로 진료 내용을 기록한다.
  1. S(Subjective): 주관적 판단
  2. O(Objective): 객관적 판단
  3. A(Assessment): 확정 진단명
  4. P(Plan): 추후 계획(치료 계획, 처방)
진료 기록 조회
1. 특정 환자의 모든 진료 기록을 조회할 수 있다.
진료 기록 수정
1. 작성된 진료 기록의 내용을 수정할 수 있다.
2. 진료 날짜도 수정 가능하다.
진료 기록 삭제
1. 특정 진료 기록을 삭제할 수 있다.

[진료 소견서 작성]

진료 소견서 작성
1. 수의사는 특정 환자에 대한 진료 소견서를 작성할 수 있다.
2. 환자 정보가 있는 환자에 대해서 작성이 가능하다.
3. 다음 항목을 입력한다.
  1. Cheif Complaint(주요 증상)
  2. Assessment(확정 진단)
  3. Plan(치료 계획)
  4. Postoperative Care(추후 관리)
진료 소견서 조회
1. 특정 환자의 진료 소견서를 조회할 수 있다.
진료 소견서 수정
1. 작성된 진료 소견서의 내용을 수정할 수 있다.

5. DB 테이블 정의서 작성하기 - 11월 5일(수)

학부생 수업 이후로 오랜만에 DB 테이블을 정의하려다보니 많이 어색했습니다. DB 테이블 정의 방법을 여러 블로그를 활용해서 복습한 뒤에 정의서를 작성했습니다.

[참고 링크]

테이블 정의서 작성 가이드

개발자인데? 테이블 정의서 작성법 모르신다구요?

vet(수의사)

필드명	데이터 타입	길이	제약 조건	설명	null여부
vet_id	INT		PK,AUTO_INCREMENT	기본 키	NOT NULL
vet_name	VARCHAR	20		수의사명	NOT NULL

pet(환자)

필드명	데이터 타입	길이	제약 조건	설명	null여부
pet_id	INT		PK,AUTO_INCREMENT	환자 번호(기본 키)	NOT NULL
pet_name	VARCHAR	20		환자 이름	NOT NULL
ower_name	VARCHAR	20		반려인명	NOT NULL
breed	VARCHAR	20		품종	NOT NULL
weight	DECIMAL	(5, 2)		체중	NOT NULL
birthdate	DATE			생일	NOT NULL

medical_record(진료 기록)

필드명	데이터 타입	길이	제약 조건	설명	null여부
record_id	INT		PK,AUTO_INCREMENT	기본 키	NOT NULL
pet_id	INT		FK	환자 번호	NOT NULL
vet_id	INT		FK	수의사 ID	NOT NULL
record_date	DATE			진료 날짜	NOT NULL
subjective	VARCHAR	500		주관적 판단	NOT NULL
objective	VARCHAR	500		객관적 판단	NOT NULL
assessment	VARCHAR	200		확정 진단명	NOT NULL
plan	VARCHAR	500		추후 계획	NOT NULL

medical_report(진료 소견서)

필드명	데이터 타입	길이	제약 조건	설명	null여부
report_id	INT		PK,AUTO_INCREMENT	기본 키	NOT NULL
pet_id	INT		FK	수의사 ID	NOT NULL
vet_id	INT		FK	환자 번호	NOT NULL
report_date	DATE			작성 날짜	NOT NULL
chief_complaint	VARCHAR	500		주요 증상	NOT NULL
assessment	VARCHAR	200		확정 진단	NOT NULL
plan	VARCHAR	500		치료 계획	NOT NULL
postoperative_care	VARCHAR	500		추후 관리	NOT NULL

수의사, 환자, 진료 기록, 진료 소견서가 있다.
진료 기록의 하나의 수의사를 가질 수 있다.
진료 기록의 하나의 환자를 가질 수 있다.

[ERD 다이어그램]

6. 기능 명세서 작성하기 - 11월 5일(수)

환자 정보 시스템이 가지는 주요 기능이랑 상세 동작들을 구체적으로 작성해보았습니다.

7. 에러 코드 정의하기 - 11월 5일(목)

에러 응답 형식

{
    "errorCode": "PET-001",
    "message": "환자 이름은 1자 이상 20자 이하여야 합니다.",
}

8. API 명세서 작성하기 - 11월 5일(수)~11월6일(목)

API 명세서 작성법을 블로그와 유튜브를 찾아보면서 공부했습니다.

API 명세서는 API의 기능, 동작, 사용법을 나타낸 문서입니다. 이름 및 설명, 기본 정보, 요청(request), 응답(respnose), 예시 정보가 포함됩니다. 기본 정보에서 Host 주소, endpoint, http method가 포함됩니다. 요청(request)에는 header정보, parameter, body가 포함됩니다. 응답(response) 정보에는 Header, body가 있습니다. API 명세서를 작성할 때 가장 중요한 것은 API 명세서만 보고도 사용할 수 있도록 만드는 것입니다. API 명세서 도구는 swagger, postman, rest docs, Notion 등이 있는데 현재 단계에서는 Notion이 제일 편한 것 같아 Notion으로 작성하기로 했습니다.

[10분 테코톡] 체인저의 API 명세서와 협업

API 명세서

9. 1차 기능 개발하기

도메인 정리부터 API 명세서 작성까지 마쳤습니다. 이제 스프링으로 구현을 시작하려 했지만, 어디서부터 손을 대야 할지 막막했습니다. 올해 초 3월에 스프링과 JPA 강의를 들었지만, 실제로 프로젝트를 만들어 본 경험이 없어서 시작점을 찾기가 어려웠습니다. 게다가 스프링과 JPA 개념도 시간이 많이 지나서 많이 흐릿해진 상태였습니다. 그래서 금요일부터 일요일까지 3일간 개념을 복습하는 시간을 가졌습니다. 더불어 일정을 조정했습니다.

11월 10일(월) - 도메인 구현하기

Q. 왜 스프링으로 구현하는 것을 선택했나요

스프링을 조금이나마 공부한 경험은 있지만, 실제로 제 손으로 서비스를 처음부터 끝까지 만들어 본적이 없었습니다. 이번 기회에 작은 프로젝트라도 전체 개발 과정을 경험해보고 싶었습니다. 또한 이전 진료 소견서 생성 시스템에서는 LangChain을 사용했는데, 이번에는 SpringAI를 활용해 구현해보고 싶은 생각도 들었습니다. 이러한 이유로 스프링을 선택하게 되었습니다.

오픈 미션 진행 방식 중에서 프리코스 경험을 기반으로 관련된 분야의 미션 설계하고 구현한다는 조건이 있었기 때문에, 내가 프리코스를 하면서 배운 내용을 적용해보고자 했습니다.

첫째, READMD.md를 상세히 작성하려고 했습니다. 구현해야 할 기능 목록을 중심으로 먼저 작성했고, 예외 상황도 함께 정리했습니다. 그리고 기능을 구현하면서 꾸준히 READMD.md를 업데이트하기로 했습니다.

둘째, 프리코스 기간 중에 테스트를 작성하는 법을 배웠기 때문에, 테스트를 작성하고 기능을 구현하는 방법을 배웠기 때문에 이를 적용해보기로 했습니다.

그래서 테스트 작성 → 기능 구현 → README.md 업데이트 → 커밋 과정을 반복했습니다. (지금 생각해보면 과할 정도로 많은 커밋을 한 것 같다.)

어디서부터 테스트 코드 작성을 시작해야 할 지 고민을 했습니다. API 명세서 한 개 당 하나씩 기능을 구현해야 하나..? 그렇다기엔 하나의 API 안에는 여러 개의 도메인이 섞여있는 경우가 있어서 작은 테스트를 수행하기는 무리가 있는 것 같았습니다. 여기서 가장 작은 단위는 도메인이니깐, 도메인 하나에 대한 테스트를 작성하고 도메인 하나를 구현하기로 했습니다.

[ 익힌 개념 ]

@Entity 애노테이션을 사용했을 때, protected 생성자와 public 생성자를 동시에 선언해야 했다. 이를 통해 의미 없는 객체를 만들어 버그가 발생하는 것을 방지할 수 있습니다.

@Entity
public class Vet {
        protected Vet() {}

        public Vet(String vetName) {
                this.vetName = vetName;
        }
}

//또는

@Entity
@NoArgsConstructor(access = AccessLevel.protected)
public class Vet {
        public Vet(String vetName) {
                this.vetName = vetName;
        }
}

@GeneratedValue 애노테이션은 기본 키 값을 자동으로 생성하도록 도와준다.

생성전략

IDENTITY: DB의 AUTO_INCREMENT 기능 사용
AUTO: Hibernate가 알아서 선택하도록 함

이렇게 일주일이 지났습니다...

11월 11일(화) - Repository 구현하기

도메인 구현을 마쳤습니다.

https://github.com/sinequanonn/veterinary-clinic/pull/1

도메인 구현 완료 by sinequanonn · Pull Request #1 · sinequanonn/veterinary-clinic

도메인 Vet 엔티티 구현 수의사명 유효성 검증 Pet 엔티티 구현 환자명 유효성 검증 보호자명 유효성 검증 품종 유효성 검증 체중 유효성 검증 생년월일 유효성 검증 MedicalRecord 엔티티 구현 진료

github.com

구현을 마친 뒤 다시 돌아보면서 느낀 점은

첫째, 도메인 계층에서 할 필요 없는 테스트를 작성했다는 생각이 들었습니다. 예를 들어 “수의사명이 20자를 초과하면 예외가 발생한다”는 책임은 도메인 계층에서 담당하는 것이 아니라, 서비스 계층에서 수행돼야 하는 게 적절해보였습니다. 그래서 전체적으로 대부분 테스트 코드가 서비스 쪽에서 테스트를 수행하는 것이 적절해보였습니다.

둘째, 엔티티를 구현할 때 @Entity 애노테이션을 사용했지만 JPA 테스트를 작성하지 않고, POJO 방식으로 테스트를 진행했습니다. 즉, POJO 클래스에 아직은 필요하지 않은 @Enttiy를 일단 붙이고 테스트를 진행했던 것이었습니다. 여기서 든 의문점이 “POJO 클래스에 @Entity를 붙인다고 해서 왜 테스트가 깨지지 않을까?”였습니다. 더 나아가서 어떤 규칙을 가졌길래 테스트가 깨지지 않았을까? 그리고 만약 깨진다면 어떤 부분을 준수하지 않았기에 테스트가 깨지는 문제가 발생할까?라는 질문을 던지게 되었습니다.

JPA 엔티티를 POJO 클래스처럼 테스트할 수 있는 이유는 POJO 클래스가 담당하는 로직이 JPA 영역에 침법하지 않기 때문이라고 생각했습니다. @Entity 애노테이션을 붙이기 전까지는 POJO 클래스에 아무런 영향이 없다가, @Entity를 붙이는 순간 부가 기능이 추가되는 것입니다. 사실상 위임자가 생기는 것이고, 그 위임자가 자신의 역할을 수행하는 데 그 범위를 벗어나지 않았기 때문에 오류가 나지 않은 것입니다. 즉, 관심사 분리 원칙을 잘 지키고 있었던 것입니다. 다르게 말하면 테스트 범위를 잘 제한했기 때문에 오류 없이 테스트할 수 있었습니다.

더 나아가서 만약, JPA에서 대포적인 오류 형태가 바로 Lazy 로딩인데, POJO 형태에서는 절대로 테스트가 불가능한 형태이다. 이렇게 테스트가 가능한 범위와 불가능한 범위를 생각하면서 코드를 구현하면, 각 계층의 책임을 분명히 이해하고 적절한 테스트를 할 수 있을 것이라 생각했습니다.

도메인 구현을 마치고 나서 h2 데이터베이스를 설치하고, 의존성도 추가하였습니다.

Service 계층을 구현하면서 도메인 계층을 구현할 때처럼 단위테스트를 작성하려고 했습니다. 하지만 Service는 VetRepository에 직접 의존하고 있었고, 이 Repository는 JpaRepository를 상속받고 있었습니다.

public class VetService {
    private final VetRepository vetRepository;

    public VetService(VetRepository vetRepository) {
        this.vetRepository = vetRepository;
    }
}

여기서 의문이 들었습니다.

“Repository에 직접 의존하고 있는 상태에서 단위 테스트를 작성하는 게 맞을까”

처음에는 @SpringBootTest를 사용하면 이미 구현된 JpaRepository를 그대로 사용할 수 있어서 편하다고 생각했습니다. 하지만 아니었습니다.

조사해보니 @SpringBootTest는 전체 애플리케이션을 띄우고 실제 DB연결하면서 외부 의존성이 포함되기 때문에 통합 테스트용 애노테이션이었습니다. 그렇기 때문에 단위 테스트를 작성하기 위해서 외부 의존성을 제거해야 했습니다.

더 알아보니 Mocking을 사용하면 실제 JpaRepository 구현체 없이 테스트가 가능하다는 것을 알게 되었습니다. 여기서 더 나아가 새로운 의문이 들었습니다. Repository 자체는 테스트 하지 않아도 되나?

제가 생각한 정답은 “해야 한다”였습니다. 그리고 여기서 중요한 점은 어디까지 테스트해야 하는가에 대한 기준이었습니다. 기준은 생각보다 쉽게 세울 수 있었습니다. 제가 프리코스 기간동안 도메인과 서비스에 대한 기준을 고민한 적이 있었습니다. “하나만 처리할 때는 도메인, 두 개 이상을 처리하면 서비스”입니다.

Repository는 도메인 계층에 포함된다고 생각했기에, Repository에 대한 테스트는 저장, 조회, 수정, 삭제를 하고, Service 계층에서는 두 개 이상의 도메인을 활용한 로직에 대한 테스트를 작성하면 되겠다고 생각했습니다.

JpaRepository는 @DataJpaTest 애노테이션을 활용해 단위 테스트를 진행할 수 있다고 알게 되었습니다.

https://github.com/sinequanonn/veterinary-clinic/pull/2

도메인 Repository 구현 완료 by sinequanonn · Pull Request #2 · sinequanonn/veterinary-clinic

github.com

11월 12일(수) - Service 구현

Repository 계층 구현 및 테스트 작성이 끝나서 Service 계층 구현을 시작했습니다.

구현을 시작하기 전에 Mock 사용법을 공부했습니다.

Mock 사용법 익히기

VetService를 작성하면서, 현재 서비스 기능 요구사항은 대부분 Repository 게층에서 수행하는 작은 단위이므로 서비스 계층에서 한 번 더 테스트할 필요가 없다고 판단했습니다. 즉, 하나의 도메인에 대한 기능 테스트 담당은 Repository에서 이미 하고 있기 때문에 서비스 계층에서 한 번 더 할 필요가 없다고 생각했습니다. 그렇기 때문에 Repository를 활용한 Service 게층 코드를 구현했습니다.

https://github.com/sinequanonn/veterinary-clinic/pull/3

251112 morning by sinequanonn · Pull Request #3 · sinequanonn/veterinary-clinic

Mock 테스트 작성법 공부 VetServiceTest, VetService 작성

github.com

서비스 계층까지 모두 구현을 마치고 컨트롤러를 구현할 차례가 되었습니다. 이 때 “컨트롤러를 단위테스트로 작성해야 할까, 통합 테스트로 작성해야 할까?”라는 고민이 생겼습니다.

제 상황은 이미 하위 계층들이 모두 구현되어 있고 테스트도 완료된 상태였습니다. 저는 이미 바텀업 방식으로 구현하고 있었기에 이미 테스트가 완료된 계층을 활용하는 것이 더 적합하다고 판단했습니다.

만약 탑다운 방식으로 개발했다면, 서비스가 아직 구현되지 않은 상태이므로 @WebMvcTest를 사용해서 컨트롤러에 대해서만 단위 테스트를 했을 것입니다. 하지만 현재 상황은 모든 계층이 준비되어 있기 때문에 @SpringBootTest를 사용한 통합 테스트가 더 적합하다고 판단했습니다.

이 경험을 기반으로 통합 테스트를 선택하는 경우와 단위 테스트를 선택하는 기준을 세울 수 있었습니다.

통합 테스트(@SpringBootTest)를 선택하는 경우
- 바텀업 방식이고 하위 계층이 이미 구현돼 있을 때
- 전체 플로우가 제대로 연동되는지 확인하고 싶을 때
단위 테스트(@WebMvcTest)를 선택하는 경우
- 탑다운 방식으로 아직 하위 계층이 구현되지 않았을 때

[ 익힌 개념 ]

@AutoConfigureMockMvc

: MockMvc 빈을 자동으로 구성한다. 톰캣 같은 외부 서버를 띄우지 않고, HTTP 요청/응답을 시뮬레이션 할 수 있게 해준다.

mockMvc.perform(…)

: 실제 컨트롤러에 요청을 하는 것과 동일한 흐름을 검증할 수 있게 해준다.

11월 13일(목) - Controller 구현

컨트롤러를 구현할 때 브랜치를 안 만들고, 제 다른 계정으로 커밋하는 실수를 범했습니다.

Comparing ed28471...727bc8c · sinequanonn/veterinary-clinic

여기까지 1차 기능 구현이었고, 기능 구현을 마친 뒤 제가 했던 과정에 대해 돌아보는 시간을 가졌습니다.

그리고 여기서 과제가 17일까지 제출인 줄 알고 17일까지로 계획을 세웠다가, 과제 제출 마감이 25일이라는 것을 알게 되었습니다.

여기서 저의 고민은 다음과 같습니다.

추가적인 요구사항을 나열해서, 기존 코드 위에서 복잡한 비즈니스 로직을 추가 개발해야 하는가
1. 스스로 왜 추가해야 하는가?라는 질문에 1차 기능 요구사항에는 단순 CRUD 연산만 포함했고, 복잡한 비즈니스 로직이 포함되지 않았습니다. 그래서 복잡한 비즈니스 로직을 다루는 서비스 계층을 구현해보고 싶은 생각이 들었습니다.
기존 코드에서 보완할 부분을 찾고 리팩토링을 진행하는가
1. 코드를 구현하는 과정에서, 도메인 계층에서 서비스 계층의 책임을 담당하고 있었고, POJO 방식으로 구현했으며, JPA를 제대로 활용하지 못했다고 생각을 했습니다. 그리고 특히 엔티티에서 Getter를 사용하고 있는 것에 대한 찝찝함이 게속 있었습니다.
2. 예외 처리도 새롭게 정의해서 구현을 시작하기 전에 만들엇던 에러 코드를 사용하고 싶다는 생각을 했습니다.
3. 서버 구현한 경험이 없다보니, response body에 정확히 어떤 데이터가 들어있어야 하는지 판단하기 힘들었습니다. 다시 정확하게 공부하고 적용해보고 싶은 생각이 들었습니다.
지금 바로 SpringAI를 추가 해야 하는가?

결론은 현재 코드가 깔끔하지 않다고 판단했고, 이 상태로 추가 기능을 구현한다면 마지막에 리팩토링 하는 과정이 더 부담된다고 판단했습니다. 그래서 리팩토링을 먼저 하기로 선택했습니다.

리팩토링 대상

검증을 API 앞에서 처리하는 로직 추가하기
controller와 Service 계층에서 dto의 정적 팩토리 메서드 사용하도록 변경하기

더불어 테스트 작성을 postman으로 해보기로 했습니다.

그래서 먼저 다음 일정을 조정했습니다.

날짜	활동	산출물
11/5(수) ~ 11/6(목)	기존 도메인 정리요구사항 분석기능사항 정의DB 테이블 정의서 작성에러코드 정의API 명세서 작성	요구사항명세기능명세서에러코드 정의서DB테이블 정의서API 명세서
11/7(금) ~ 11/9(일)	스프링, JPA 복습	-
11/10(월)~11/12(수)	1차 기능 개발	핵심 기능 코드
11/13(목)	중간 점검	진행률 표?
11/13(목)~11/15(토)	리팩토링	리팩토링 적용 코드
11/15(토)~11/16(일)	에러 처리 로직 추가하기	에러 처리 추가 코드
11/17(월)~11/18(화)	Spring AI를 활용한 진료소견서 요약 기능 추가	ai 추가 코드
11/19(수)~11/24(월)	회고 작성하기
제출	회고글
최종 산출물(코드)

10. 리팩토링 - 11월 14일(금)~11월 15(토)

https://github.com/sinequanonn/veterinary-clinic/pull/4

리팩토링 by sinequanonn · Pull Request #4 · sinequanonn/veterinary-clinic

DTO 계층 재구조화 DTO에 Bean Validation을 통한 검증 추가 정적 팩토리 메서드 및 Builder 패턴 적용 서비스/컨트롤러 책임 명확히 분배

github.com

DTO 계층을 재구조화을 했고, 책임을 분리했습니다.

단일 DTO를 용도별로 분리했습니다(예: VetRequest → VetCreateRequest)
생성, 수정, 조회와 같이 목적에 맞는 DTO를 각각 정의했습니다.

직관적인 네이밍을 사용하도록 수정했습니다.
Bean Validation을 통한 검증 로직을 추가했습니다.
Builder 패턴을 적용했습니다.
계층 간 책임을 명확하게 분배했습니다.
1. 원래는 서비스 계층에서 엔티티를 직접 받고 반환했지만
2. Request DTO를 받아 Response DTO를 반환하도록 수정했습니다.
3. 컨트롤러가 DTO를 엔티티로 직접 변환하던 로직을 서비스에게 위임했습니다.
4. → 이로써 컨트롤러는 HTTP 요청/응답 처리하는 책임에만 집중할 수 있게 했습니다.

리팩토링을 마무리하고 나니, 그동안 무분별하게 사용했던 Lombok 애노테이션들에 의문이 생겼습니다. @Builder, @AllArgsConstructor, @NoArgsConstructor 같은 애노테이션들을 명확한 기준 없이 "일단 편하니까" 사용하는 경향이 있었습니다. 이제는 각 애노테이션을 언제, 왜 사용해야 하는지 기준을 명확히 하고 다시 적용해야겠다고 생각했습니다.

Lombok 애노테이션 사용 기준 정리

데이터 수정 기능을 구현하면서 JPA의 변경 감지를 사용했습니다. 그런데 update 로직을 어디에 위치시켜야 할지 고민이 되었습니다.

DTO 내부에서 엔티티의 update 메서드를 호출해야 하는가?
Service 계층에서 udpate 메서드를 호출해야 하는가?

해당 고민은 빠르게 해결할 수 있었습니다.

프리코스를 진행할 때 “객체 생성을 컨트롤러에서 해야 하는가 아니면 서비스에서 생성해야 하는가”에 대한 고민을 한 적이 었었습니다. 그 때 제가 내린 결론은 “생성하는 것은 비즈니스 로직이므로 서비스 계층이 담당해야 한다”였습니다. “로또를 발행한다”가 비즈니스 로직이듯이 “이름을 변경한다”도 비즈니스 로직이므로 서비스 계층에 있는 것이 적절하다고 판단했습니다.

11. 에러 로직 추가 - 11월 16일(일)

기존에 정의했던 에러 코드를 적용하기로 했습니다. 그전에 스프링에서 에러 처리 동작 방식을 먼저 학습했습니다.

스프링에서 API 예외 처리 학습

https://github.com/sinequanonn/veterinary-clinic/pull/5

구현 과정에서..

처음에는 기존에 정의했던 에러 코드를 모든 예외 상황에 적용하려고 했습니다. 하지만 구현하다 보니 너무 too much라는 것을 깨달았습니다.

특히 DTO 검증 로직에 에러 코드를 적용하는 것이 매우 부담스러웠습니다. 그래서 굳이 DTO 검증 로직에 대해서 에러 코드를 적용하는 건 오버 엔지니어링이라고 판단했습니다. Bean Validation의 기본 메시지만으로도 충분히 명확하게 어떤 오류인지 판단 가능하다고 생각했습니다.

결론은 비즈니스 로직에만 에러 코드를 적용하기로 했습니다.

에러 로직을 추가하고 postman으로 테스트도 진행했습니다.

12. Spring AI 추가 - 11월 17일(월)~11월 18일(화)

드디어 Spring AI를 활용해서 환자 진료 데이터를 기반으로 진료 소견서를 자동으로 생성하는 기능을 추가하기로 했습니다.

기존 시스템은 PDF 파일에서 카테고리 별로 데이터를 추출하는 방식이었습니다. 하지만 현재는 환자 진료 기록이 환자 시스템에 저장돼 있는 상황입니다.

기존에는 환자 정보, 동물병원 정보, 코드, 항목명, 수량, 일투, 일수, 총투, 확정 진단명, 구분, 코드, 과목, vital check, lab 표 데이터 등 어마어마하게 많은 데이터가 존재합니다. 하지만 현재는 축약된 데이터를 기반으로 진료 소견서에 들어갈 내용을 자동으로 생성하도록 구현하는 것이 목표입니다.

더불어 RAG 프로세스를 적용하고 싶었지만, 실제 동물 병원의 데이터를 기반으로 VectorDB를 구축하는 데 무리가 있다고 판단했습니다. 그렇기 때문에 에시 프롬프트를 주어서 진료 소견서를 생성하도록 구현하기로 했습니다.

다음과 같은 프로세스로 진행됩니다.

petId와 recordId를 활용해서 진료 기록을 조회합니다.
진료 기록을 LLM에 입력 가능한 컨텍스트로 변환합니다.
컨텍스트 + 지시사항을 LLM에게 주입합니다.
OutputConverter에 따라 진료 소견서 카테고리에 데이터를 자동으로 삽입합니다.

LangChain을 활용한 경험은 있지만 Spring AI를 활용한 경험이 없기 때문에 기본적인 Spring AI에 대해 학습했습니다.

Spring AI 학습하기

https://github.com/sinequanonn/veterinary-clinic/pull/6

프리코스를 마치면서

전체적으로 돌이켜보면, 이번 오픈 미션은 저에게 “시스템 구현 했다”라는 사실 그 이상이었던 것 같습니다. 도메인을 정의하는 과정, 테스트의 기준을 세우는 과정, 검증과 예외 처리를 분리하는 과정, 리팩토링을 통해 구조를 다듬는 과정, 그리고 AI 기능을 서비스와 연결하는 과정까지, 모든 과정이 배움이었습니다. 설계부터 개발, 테스트, 리팩토링까지 한 번의 사이클을 직접 온전하게 경험해본 것이 저에게 가장 큰 수확이었던 것 같습니다.

이렇게 5주 프리코스 기간 전체가 마무리되었을 때 정말 후련한 마음이 들었습니다. 동시에 정말 멋진 개발자가 되고 싶다는 마음이 들었습니다. 저는 원래 무언가를 배우고 나서 정리하는 성격이 아니었습니다. 그냥 이해하면 넘기고, 필요하면 다시 찾는 식이었습니다. 그런데 프리코스에서는 매주 제가 배운 것을 글로 남기고, 다른 사람의 생각도 보고 제 생각을 비교한 뒤에 다시 정리해서 공유해야 했습니다. 이 과정은 처음에는 정말 어색했고 시간도 많이 걸려서 힘들었습니다. 하지만 하루하루 하다 보니 많은 것을 깨닫게 되었습니다. 결국 개발자는 혼자 컴퓨터 앞에 앉아서 코드만 치는 사람이 아니라 문제를 해결해야 하는 사람인 것을 다시 느꼈습니다. 제 생각을 동료들에게 설명할 수 있어야 하고, 동료들의 생각을 이해하는 것이 중요하다는 사실을 배웠습니다. 이런 경험이 쌓이면서, 단순히 기술을 아는 개발자가 아니라 함께 일하고 함께 성정할 수 있는 개발자가 되고 싶다는 목표가 생겼습니다.

** 미션하면서 노션에 정리했던 거...

https://www.notion.so/2af8273095b180b1bac6c77f8d96c372?source=copy_link

오픈 미션 | Notion

동물병원 환자 시스템 with 진료 소견서 자동 생성

www.notion.so

**블로그 새로 만들어서 프리코스 기간 때 작성했던 내용을 다시 옮겨 적었습니다.

https://velog.io/@sinequanonn/BE-8%EA%B8%B0-%EC%9A%B0%ED%85%8C%EC%BD%94-%ED%94%84%EB%A6%AC%EC%BD%94%EC%8A%A4-4%EC%A3%BC%EC%B0%A8-%ED%9A%8C%EA%B3%A0

https://velog.io/@sinequanonn/BE-8%EA%B8%B0-%EC%9A%B0%ED%85%8C%EC%BD%94-%ED%94%84%EB%A6%AC%EC%BD%94%EC%8A%A4-5%EC%A3%BC%EC%B0%A8-%ED%9A%8C%EA%B3%A0

[BE 8기] 우테코 프리코스 3주차 회고

sinequanon — Sun, 25 Jan 2026 17:48:01 +0900

벌써 3주차 미션이 끝났다. 4,5주차는 새로운 형태로 미션이 진행된다고 하는데 벌써 기대가 된다.

3주차 미션: 로또 발매기

미션을 시작하기 전,

이번 주부터 프로그래밍 요구 사항이 많아지기 시작했다.

기능을 구현하기 전에 README.md에 구현할 기능 목록을 정리해 추가하기
indent depth 3 넘지 않기
3항 연산자 쓰지 않기
함수 최대한 작게 만들기
함수의 길이가 15라인 넘지 않도록 구현
else 예약어 쓰지 않기
Enum 사용하기
구현한 기능에 대한 단위 테스트 작성하기

2주차 미션을 얻은 피드백

Controller에는 흐름 제어 코드만 작성하자
네이밍을 명확하게 하자(테스트명, 상수명, 클래스명 등)
에러 처리 할 때 메시지를 추가하자
DRY 원칙을 준수하자

미션을 진행하면서,

1. 작은 단위로 테스트하고 커밋하기

이번 미션에서 작은 단위로 테스트 코드를 작성하고 기능을 구현한 뒤 바로 커밋하는 것이었다.
먼저 READMD.md에 정리한 체크리스트를 따라가면서 하나씩 구현하니 무엇을 해야 할 지 명확했고, 진행 상황도 한 눈에 파악할 수 있었다.

하지만 문제는 리팩토링 단게였다. 첫 구현을 마치고 구조를 변경하거나, 새로운 도메인을 추가할 때 문서를 어떻게 업데이트해야 할지 막막했다. 그래서 리팩토링 할 때는 문서를 먼저 작성한 것이 아니라 먼저 리팩토링하고 다시 문서를 작성하는 방향으로 했다.

2. MVC 패턴과 계층 분리 이해하기

저번 주에 이어 이번 주도 MVC 패턴을 적용했다. 저번 주에는 Controller의 역할이 애매모호했고, mdoel의 domain과 service 계층에 대한 이해가 부족했다.

가장 고민했던 질문들:

Controller에서 도메인 객체를 생성해도 되는가?

처음 코드를 작성할 때 가장 큰 고민은 new LottoCoin(), new WinningLotto()처럼 도메인 객체를 직접 Controller에서 생성해도 되는가였다

여기서 나는 도메인 객체를 생성하는 것도 비즈니스 로직의 일부라고 판단했다.
왜냐면 Controller는 흐름 제어 역할만 담당해야 하고, "무엇을 할지만 결정"해야 한다고 판단했다. 그리고 로또 코인을 구매한다와 당첨 로또를 만든다는 행위들이 비즈니스 의미를 가진 행동처럼 느껴졌기 때문이다.

Service는 어떤 책임을 가져야 하는가?

저번 주에는 비즈니스 로직은 Servie가 책임을 가져야 한다는 사실만 알고 있었지, 구체적으로는 알지 못했다. 더불어 domain과 service의 경계도 애매모호했다. 이번 미션을 통해 다음과 같은 기준을 세울 수 있었다.

domain은 하나의 객체 규칙을 정의하는 곳
service는 이러한 객체들을 활용하는 곳

마무리하면서

이번 주에 공부하고 익힌 것들

MVC 패턴 좀 더 명확하게
enum 사용법
단위 테스트 작성하는 이유
에러 메시지 관리

https://github.com/sinequanonn/java-lotto-8/tree/sinequanonn

GitHub - sinequanonn/java-lotto-8

Contribute to sinequanonn/java-lotto-8 development by creating an account on GitHub.

github.com

**블로그 새로 만들어서 프리코스 기간 때 작성했던 내용을 다시 옮겨 적었습니다

https://velog.io/@sinequanonn/BE-8%EA%B8%B0-%EC%9A%B0%ED%85%8C%EC%BD%94-%ED%94%84%EB%A6%AC%EC%BD%94%EC%8A%A4-3%EC%A3%BC%EC%B0%A8-%ED%9A%8C%EA%B3%A0

[BE 8기] 우테코 프리코스 2주차 회고

sinequanon — Sun, 25 Jan 2026 17:43:25 +0900

디스코스에서 포비님의 글을 보고 많은 생각을 하게 되었다.

잘할 수 있을까? 잘 모르는 데 어떡하지?라는 걱정만 가득했다. 스스로 잘해야 된다는 생각에만 빠져있었고, 잘하는 사람들과 비교하면서 나의 위치를 판단하고 좌절만 했다.
피드백을 듣고나서 생각을 다시 정리했다. 지금 모르는 것이 당연하다. 내가 모르는 것을 인지하고, 하루하루 채워나가는 것이 도전인 것이다. 완벽하게 해내는 것에 집착하지 않겠다. 새로운 시도를 멈추지 않는 자세로 최종 목적지까지 달려 가보겠다.

그래서 이번 주의 목표는 내가 모르는 것을 확인하고, 배우고, 미션에 적용해보는 시간으로 만들어보려고 한다.

2주차 미션: 자동차 경주

2주차 미션을 시작하기 전,

1주차 미션 코드 리뷰와 공통 피드백을 보면서 내가 공부해서 적용할 수 있는 내용을 정리해보았다.

큰 함수를 단일 역할을 수행하는 작은 함수로 분리(단일 책임 원칙 준수하기)
테스트 도구 사용하는 방법 배우기
커밋 메시지 의미있게 작성하기
코드 포맷팅 사용하기
MVC 패턴 적용하기
상태가 없는 객체에 static 사용하기
요구사항 분석 잘하기

코드 리뷰를 하는 과정에서 많은 동료들이 MVC 패턴을 사용한 것을 파악할 수 있었다. 나의 코드와 비교했을 때 확실히 패키지가 분리되어 있어, 어디서 어떤 기능을 하는지 한 눈에 파악할 수 있어서 좋았다. 그래서 나도 2주차에는 MVC 패턴을 공부하고 적용하기로 마음 먹었다.

요구사항을 분석하면서

이번 주에는 요구사항 분석을 잘해야지라는 마음으로 시작했지만 역시나 잘하는 것 자체가 쉽지 않았다.

그래서 요구사항을 어떻게 하면 잘할 수 있을지 고민하다가 커뮤니티에서 기능 요구사항을 기능 단위로 나누는 기준에 대해 토론 보았다. 그래서 나도 요구사항 분석에 대한 기준을 세우는 시간을 가졌다. 1,2주차 미션 과정을 돌아봤을 때 나는 입력 -> 처리 -> 출력흐름 중심으로 기능을 쪼개고, 이후 책임에 따라 객체를 나누는 것이 편했 던 것 같다.

행동 중심으로 나누기
구현 단계에서 '누가 이 일을 맡을까?' 고민하면서 책임 중심으로 전환

처음부터 완벽한 구조를 세우는 것이 좋겠지만, 이렇게 단계적으로 전환하는 게 초보자에게 가장 현실적인 접근인 것 같다. 처음엔 행동으로 시작해도, 리팩토링 단계에서 책임 중심으로 다듬어가는 과정이 결국 객체 지향 설계 연습으로 자연스럽게 이어지는 것 같다.

미션을 진행하면서

MVC 패턴 적용하기

코드 리뷰를 하면서 많은 동료들이 MVC 패턴을 사용한 걸 알 수 있었다. 나의 코드와 비교했을 때 확실히 한 눈에 파악하기 좋았다. 그래서 나도 2주차에는 MVC 패턴을 공부하고 적용해보기로 마음 먹었다.

MVC패턴이 정리된 블로그들을 찾아보고, 우테코 제리 선배님의 영상을 참고했다.

https://www.youtube.com/watch?v=ogaXW6KPc8I&t=331s

개념적으로 Model은 데이터를 처리를 담당하고, View는 화면 처리 담당, Controller는 View와 Model의 상호작용 담당이라는 사실을 쉽게 이해할 수 있었다. 해당 영상에서 제공하는 기준을 바탕으로 내 코드에 MVC 패턴이 적용되었는지 확인하면서 리팩토링을 반복했다.

Model은 Controller와 View에 의존하지 않아야 함
View는 Model에만 의존해야 하고, Controller에는 의존하면 안됨
View가 Model로부터 데이터를 받을 때, 사용자에게 보여질 데이터에 대해서만 받아야 함
Controller는 Model과 View에 의존해도 된다.
View가 Model로부터 데이터를 받을 때, 반드시 Controller를 통해서만 받아야 함

하지만 실제로 코드에 적용하려다보니 어떤 코드를 어디에 넣어야 할지 선택하기가 힘들었다. 특히 Controller 영역에 들어갈지, Model에 들어갈지에 대한 기준을 세우기 힘들었다. 예를 들어 "경주를 N번 진행한다"는 반복 로직을 어디에 둬야 할지 애매했다. Controller가 직접 반복문을 돌면서 Model의 메서드를 호출해야 하는지, 아니면 Model에 "N번 진행하라"는 메서드를 만들어야 하는지 헷갈렸다. 이번 주 과제를 수행하면서 Controller는 '무엇을 할지만 결정하기'로 이해하고 적용했다. 즉, Controller는 '입력받기->검증하기->게임진행하기->결과출력하기'와 같은 흐름만 제어하고, 실제로 어떻게 검증하고 어떻게 게임을 진행하는지는 Model이 담당해야 한다는 것을 깨달았다. 하지만 여전히 경계가 명확하지 않아 더 많은 연습이 필요하다고 느꼈다.
그리고 동료들의 1주차 코드를 보면서 service라는 패키지를 보았다. Controller랑 뭐가 다르지?라는 궁금증이 생생겼고, "비즈니스 로직을 담당한다"는 설명을 봤지만 아직 개념을 완전히 이해하지 못해 미션에 적용하지 못했다.
다음 주차에는 Service 계층의 역할과 필요성에 대해 더 공부하고, MVC 패턴 내에서 각 계층이 어떤 책임을 가져야 하는 지 더 명확하게 이해해야겠다고 느꼈다.

Static 메서드 사용 기준

코드 리뷰에서 상태를 가지지 않는 객체에 대해서 static 메서드를 사용하면 좋겠다는 의견이 있었다.
그래서 util 클래스뿐만 아니라 InputView와 OutputView 클래스도 static으로 생성할까?라는 고민을 했다.

고민 끝에 나는 외부 의존성과 확장 가능성을 기준으로 판단하기로 했다. util 클래스처럼 외부 의존성 없이 순수하게 특정 기능 처리만 하는 메서드는 static으로 만드는 것이 적합하다고 생각했다.
InputView와 OutputView는 Console이나 System.out같은 의존성을 가지고 있고, 콘솔 입력이 아닌 파일 입력으로 변경해야 할 수도 있다는 확장 가능성도 고려했다. 따라서 View와 같은 클래스는 인스턴스로 생성했다.

상태를 가지지 않음
외부 의존성이 없음
확장 가능성이 없음

마무리하면서

완벽하게 해내는 것보다 새로운 시도를 멈추지 않는 것

이번 주 배우고 시도한 것

MVC 패턴 공부 및 적용
일급 컬렉션 공부 및 적용
private 생성자 + static 메서드 적용
요구사항 분석 기준 세우기

기준 세우기

MVC에서 Controller의 기준
정적 메서드 사용 기준

다음 주에는 더 많은 동료들과 코드 리뷰를 해서 공부할 수 있는 부분을 찾아 볼 것이다. 그리고 MVC 패턴을 더 완벽하게 이해해야겠다.

과제 제출 링크: https://github.com/sinequanonn/java-racingcar-8/tree/sinequanonn

GitHub - sinequanonn/java-racingcar-8

Contribute to sinequanonn/java-racingcar-8 development by creating an account on GitHub.

github.com

**블로그 새로 만들어서 프리코스 기간 때 작성했던 내용을 다시 옮겨 적었습니다.

2주차 회고

[BE 8기] 우테코 프리코스 1주차 회고

sinequanon — Sun, 25 Jan 2026 17:31:14 +0900

1주차 미션

문자열 덧셈 계산기 구현이다

이번 회차의 목표
1. 객체 지향적으로 코드 작성하기
2. 코드 컨벤션과 커밋 컨벤션 익숙해지기
3. **AI 툴 사용하지 않고, 문제 해결하기

요구사항을 분석하면서

제시된 요구 사항을 바탕으로 나만의 언어로 README에 다시 작성을 했다.

그리고 문자열 덧셈 계산기에는 어떤 책임들이 있을지 고민했다.
1. 더하기 연산을 수행하는 책임
2. 문자열에 포함된 양수를 얻어내는 책임
3. 사용자로부터 문자열 입력받는 책임
4. 사용자에게 결과를 출력하는 책임

구현하면서

'객체 지향적으로 작성하자'는 마음으로 수행했다.
단일 책임 원칙을 생각하면서 하나의 객체가 더하기 연산을 수행하는 책임을 같도록 했고, 문자열로부터 양수를 추출하는 책임을 같도록 했다. 하지만 여러 의문점이 존재했다.

1. 검증 로직은 어디서 하지?
2. 예외 처리는 어디서 하지?
3. 만약 요구사항이 바꼈을 때, 변경에 자유로운가?

3번의 경우 구현하면서 문제가 발생했다. 요구 사항 분석을 할 때 양수를 '정수'로만 한정지어서 Integer 타입을 사용했다. 구현 도중 '실수'도 가능하다는 걸 깨닫고 코드 수정을 했는데, `PositiveNumberExtractor`를 수정하니, `Calculator` 클래스도 수정해야 했고, `Computer`, `OutputView` 모두 다 수정해야 했다. 객체지향적으로 작성한다는 것은 변경 시 코드 수정이 없어야하고, 즉 변경에 자유로워야 하는데 그렇지 않았다.

다시 작성을 해서 변경이 용이하도록 하려고 했지만 어떻게 해야 할지 몰라 실패했다.
OOP를 공부해서 변경에 용이한 코드를 작성하는지 공부해야겠다.
그리고 다른 의문점들은 커뮤니티를 통해 생각을 나눠봐야겠다.

배운 점

1. 요구사항 분석의 중요성
2. 변경에 자유로운 코드 작성의 중요성

https://github.com/sinequanonn/java-calculator-8

GitHub - sinequanonn/java-calculator-8: 1주차 미션

1주차 미션. Contribute to sinequanonn/java-calculator-8 development by creating an account on GitHub.

github.com

**블로그 새로 만들어서 프리코스 기간 때 작성했던 내용을 다시 옮겨 적었습니다.
1주차 회고