CH2 팀프로젝트 KPT 회고록

2026. 1. 7. 19:13언리얼 7기 본캠프

3가지 주제에 대해서 KPT를 진행하였습니다

 

주제 1 : 객체지향 설계와 메모리 관리의 효율성

 


홍승표
K : Item, Monster, Character 등 주요 객체를 클래스 단위로 분리하면서, 명확하게 객체간 역할 분리가 잘 되었다고 생각한다.
P : 메모리 관리에 대한 개념보다는 클래스 내부 코드를 짜는데에만 집중했었다. 메모리까지 고려하면서 코드를 짜야할듯하다.
T :  이번에 작성한 팀 코드를 계속 다시 보면서, 어떤 식으로 좀 더 효율화할 수 있는지 확인해보면 좋은 경험이 될 것 같다.

신효정
keep:코드 응집도가 높고 결합도가 비교적 원활하게 낮아질 수 있도록 코드를 짤 수 있게 된 것 같다. 계속 이렇게만!
problem:아직 어떻게 코드를 짰을 때 메모리 누수가 일어나는지 파악하는게 느려, 그런 것에 대해 문제 해결 능력이 떨어지는 듯 하다.
try:코드스니펫 등을 반복해서 입력하며 더욱 심도있게 모르는 부분을 파고들어야겠다.

 

이용호

K: Event(부모 추상 클래스) -> EventList(자녀 클래스) 의 구조를 통해서 자녀 클래스에서 상속받은 함수를 정의하는 구조로 객체 지향적 설계를 함
P: EventManager 클래스에서 new와 delete 를 사용해 메모리를 관리했는데 스마트 포인터를 사용해서 작성해보려고 했으나 사용법을 제대로 알지 못해서 실패했다.
T: 다음에 비슷한 구조의 코드를 작성할 때는 스마트 포인터를 사용해서 동적 할당을 관리해봐야겠다 

 

주철민

Keep : GameManager, Inventory, UIManager등 각자의 역할에 맞는 클래스를 분리하여 단일 책임 원칙을 지킴
클래스의 소멸자에서 남은 메모리들을 확실하게 지우게 처리하여 메모리 누수를 방지하려고 노력함
Problem : RemoveItemFromPointer, RemoveItemFromIndex에서 아이템 삭제의 모호함으로 인해 여러번 발생했던 메모리 누수 문제
아이템 사용 관련해서 이미 사용한 아이템을 가리키는것을 몇번 발생시킨 댕글링포인터 문제
Try : 다음부턴 겁먹지말고 스마트포인터(shared_ptr 또는 unique_ptr)를 적극 도입하여 따로 관리하지 않아도 메모리가 알아서 해제될 수 있게 시도할 것

 

문인우

K:  객체자향 설계를 통해 불필요한 코드를 줄이는 형태로 로직이 설계되는 형식이 되어 코드가 깔끔해져서 좋았습니다.
P: 초기 설계단계에서 안나온 문제들이 많아 후반에 클래스가 두배가 되는 형태가 만들어져서 설계에 중요성을 깨닫게 되었습니다.
T: 필요한 부분을 빠르게 체크해서 어떻게 설계를 해야될지 먼저 작성해보고 작업에 들어가야겠습니다.

 

이영웅

K : 클래스
(Character,Potion,Inventory)분리로 여러 파일에서 책임분리가 잘 되있는거 같고 캡슐화와 자동화의 기능으로 유지보수성과 확장성을 높여 코드가 커져도 구조가 무너지지않고 팀 협업에도 도움을 많이줄거같다
P: manageEquipment의 장비 장착/헤제 로직이 중복적으로 들어가 있어서 유지보수가 어렵고 경험치와 레벨업쪽에 하드코딩이 있어 유연성이 부족하다.
T: 스마트포인터로 메모리를 자동으로 관리할수있게 하는것이 좋을것같다.

주제 2 : 상속과 다향성으로 클래스 관리 및 활용

 

홍승표
K : Monster → MidBoss/ FinalBoss 구조를 통해 공통 로직은 재사용하고, 오버라이드하는 구조를 활용해봤다.
P : 공통적인 함수는 추가 상속 필요해서, 다시 체크하는 과정이 발생했다.
T : 클래스의 기준을 좀 더 구체화해서 시작했으면 수정 작업이 줄어들었을듯하다.

 

신효정
keep:하나의 참조 변수로 여러 자식 클래스를 가리킬 수 있고, 객체를 다루는 것에도 조금 익숙해짐을 느꼈다.
problem:조금 익숙해졌다 뿐이지 아직까지는 자신있게 응용해서 쓸 수 있다고는 할 수 없다..
try:이것도 마찬가지로 반복학습이 제일이고, 미니 프로젝트를 제작해보는 것도 방법일 듯 하다.

 

이용호

K: Event(추상 클래스)->EventList(실제 이벤트 목록) 의 구조를 통해 EventEffect를 자녀 클래스에서 각각 다르게 정의해 사용함
P: 새로운 이벤트를 만들 때마다 클래스를 새로 만들고 정의해야해서 길이가 길어짐.
T: 클래스의 멤버가 하나 밖에 없어서 다른 함수나 변수를 추가해 여러 기능 추가하기

 

문인우

K: 객체지향 설계를 기반으로 GameManager, Character 등 필요한 클래스를 명확히 분리하고, 이를 이벤트 클래스에서 참조하여 활용할 수 있었던 점이 매우 좋았습니다.
P: 이벤트 클래스의 수가 많아지면서 경우의 수도 함께 증가했고, 그로 인해 특정 구간마다 예외 처리가 필요해지는 문제가 발생했습니다. 앞으로는 이러한 부분을 사전에 체크하는 습관을 길러야겠습니다.
T: 다음 과제에서는 이벤트에서 공통으로 사용하는 로직을 빠르게 파악해 이벤트 함수에 조금더 간결하고 깔끔한 코드를 사용할수있도록 시도해보겠습니다.

 

주철민

Keep : PrintInfo를 가상함수로 설계하고 이를 통해 오버라이딩을 해서 자식 클래스의 정보를 제대로 출력할 수 있게끔 설계함
Problem : LSP 위반 -> 일부 아이템들이 장착과 사용을 동시에 하는 구조로 되어있어서 Item* 단일로 처리하기가 애매한 일이 있었음
Try : 이후에는 아이템별로 역할을 단일로 만들고, '장착' 과 '사용'을 따로 분리하기를 시도할 것

 

이영웅

K: 포션이나  무기등으로 공통속성을 재사용하였고 포션 사용 함수에서 버프포션과 힐 포션을 동일한 인터페이스로 처리하여 다형성을 적용했다.
P:포션사용 로직이 비슷해서 유지보수성이 저하될수있고 dynamic_Cast에서 안전장치가 부족하다.
T: 포션사용 로직을 공통화하고 세부효과를 하위클래스에서 오버라이드하는게 좋을거같다

 

 

주제 3 : Github로 협력하여 코드 작성

 

홍승표

K : 기능 단위로 파일을 나누어 작업했고, 각자 브랜치에서 수정한 점, 머지 작업은 팀장 체크 후 진행했던 점이 오류를 최소화할 수 있었다. 팀원으로선 팀 프로젝트를 수행하기에 매우 좋은 프로세스였다. (팀장은 확인 및 작업이 많이 필요했지만..)
P : 커밋할 때, 수정된 내용을 구체적으로 작성했어야 했는데 조금 단순화해서 작성했다. (수정된 경우가 많은 경우)
T : 나중엔.. AI의 도움을 받아 리퀘스트 내용에 수정된 점/ 코드 를 구체적으로 작성해봐야겠다.

 

신효정

keep:commit하고 pull하는 등의 기본 사용법을 익혔고, merge도 실수하지 않게끔 할 수 있다.
problem:코드가 겹쳐 conflict가 발생하면 고치는 법을 아직 모른다.
try:개인적으로 git 사용법을 좀 더 공부하는 방식으로 진행해야겠다

 

이용호

K: 팀 단위의 깃허브 사용을 할 때 개인 브랜치의 활용과 pull request, merge 등 여러 기능을 사용해보고 익숙해졌다.
P: 여러 사람의 코드가 합쳐지는 과정에서  conflict 가 발생했을 때 어떤 부분에서 문제가 생겼는지 어떻게 해결해야 하는지 등을 파악하기 힘들었다.
T: GitHub 의 여러 가지 기능이 어떤 기능이고 어떤 상황에서 사용하는지 인터넷 서칭과 튜터님의 강의 영상, 자료를 보면서 더 익혀야 할 것 같다.

 

주철민

Keep : 팀원분들에게 각자의 역할을 확실히 정해주고 병합하게 하여 충돌율을 줄이려고 함
공통 유틸리티 클래스를 만들어 다같이 활용할 수 있게 만듬
Problem : GameManager와 main이 너무 많은 헤더를 include하고 있어서 컴파일이 오래걸리고 충돌 가능성이 자주 생김
Github 사용이 처음이라 커밋 단위를 조절하지 못해 대부분 큰 단위로 머지를 해서 버그 발생시 백업이 어렵고 직접 해결해야 했음
Try : 체계적으로 브랜치 나눔 및 커밋 기준을 확실하게 정하고, PR시 코드 리뷰를 하는 시간을 가져서 확실하게 머지할 수 있게 시도
헤더간 의존성을 줄이기 위해 전방선언을 좀 더 많이 시도해볼 것

 

문인우

k : 깃 허브를 통해 협업시 문제가 되는부분을 빠르게 체크할수 있는 형태가 매우 좋았습니다.
p: 초기에 작성되지 않은 코드를 통해 서로 혼선이 많아지면서 조금 혼란스러웠던거 같습니다. 다음에는 필요한상황에 맞춰서 우선 순위를 두고 기획하는 방법으로 개선하는 방법도 좋을것 같습니다.
T: 아직 코딩 실력이 부족하여 어떻 코드가 내가 작업하는데 필요한지 인지를 못하여 팀원들에게 재대로 물어보지 못한게 아쉬웠습니다.

 

이영웅

K: 깃허브로 협업하여 바뀐 변수 이름이나 추가된 변수등을 확인하여 빠르게 적용할수있는게 좋았습니다.
P:동시에 영향을 주는 파일을 수정할경우 오류사항이나 혼란을 줄수있어 소통을하며 뭐부터 해야하는지 정해두는게 좋을것같음
T:깃허브를 사용하는데 더 익숙해져서 조금 더 편하게 활용할수있게 되고싶다