이스트소프트 부트캠프 1차 프로젝트 회고

회고

이스트소프트 부트캠프 1차 프로젝트 회고

시르베어 2025. 3. 1. 22:58

이스트소프트 프론티어 iOS 1기의 첫프로젝트를 진행했다. 전체 기간중 3번의 프로젝트를 진행한다고 하는데 벌써 하나의 프로젝트가 종료된 것이다. 기간은 짧았지만 배운것도 많았고 아쉬운 점도 많았던 프로젝트라서 회고를 진행해 볼까한다. (개발자 인생 중 첫 회고...) 물론 남은 2번의 프로젝트도 마찬가지로 회고를 진행할 생각이다.

회고를 처음 작성하니 막히는 부분들이 있어서 어떻게 적어야하지? 하는 물음에 찾아보니 회고를 작성하는 방법이 있다는걸 알았다. 회고에는 KPT, 5F, 4L 등 많은 방법이 있는데 이번에는 5F 방법으로 해볼까한다. (다음엔 KPT 나 4L도 해봐야지)

Facts(사실)

프로젝트의 기간은 15,16일 ~ 23일인데 주말동안 기획을 생각하고 월요일 기획 발표후가 정해진 시작(본격적인?)이었다. 우리 팀의 경우 토요일, 일요일 오전 각자 기획을 정리하고 일요일 저녁에 생각을 나누고 방향을 정하였다.

프로젝트 깃허브!

https://github.com/ESTSOFT-iOS-01/PomoTodo

GitHub - ESTSOFT-iOS-01/PomoTodo: ⏳ Pomodoro와 To-Do 리스트를 결합하여 효율적인 시간 관리와 목표 달성을

⏳ Pomodoro와 To-Do 리스트를 결합하여 효율적인 시간 관리와 목표 달성을 돕는 앱입니다! - ESTSOFT-iOS-01/PomoTodo

github.com

1주일 간의 일정

16일(일) - 기획안 정리

17일(월) - 기획발표, Entity정리, 디자인 확정, 깃허브 설정, 컨벤션 작성, 할일 분배

18일(화), 19일(수) - 프로그램 개발

20일(목) - 데이터 연결 + 개발/수정

21일(금) - 테스트, 이슈 사항 수정 및 리팩토링

22일(토), 23일(일) - 발표 자료 준비

협업 과정에서 지키기로 한것

작업을 시작하기 전에 깃허브 프로젝트에서 아이템 생성으로 이슈와 브랜치를 생성한다
이슈를 만들거나 브랜치를 생성하고 PR 요청할 때는 컨벤션 지키기
최소한 9시~6시 (부트캠프 시간)에는 작업에 집중한다! - 코어 타임 설정
코어타임의 마무리가 되는 5시~5시 30분에는 스크럼을 진행한다

Findings(발견)

이번 프로젝트로 새롭게 경험한 것이 너무 많았다. 처음 피그마를 사용해 디자인을 해보고 제작된 디자인을 보고 개발을 하였고 깃허브를 제대로 사용해 프로젝트를 관리했다. 컨벤션을 처음 지켜보았고 나의 코드를 리뷰를 통해 발전시킬 수 있었다. 또한 다양한 의견을 나누면서 처음알게된 내용이 너무나 많았다.

그중에서 이번에 자세하게 말해보고자 하는 것은 아래의 코드에 대한 내용이다

다수의 텍스트 필드

프로젝트의 Todo 파트를 개발하면서 경험한 내용이었다. 사용자가 텍스트 필드를 사용할때는 내용 작성후 완료(엔터)를 터치하거나 화면을 터치하는데 이때 화면을 터치하면 키보드가 내려가야한다. 그래서 아래의 코드를 사용했다.

extension UIApplication: @retroactive UIGestureRecognizerDelegate {
  public func gestureRecognizer(_ gestureRecognizer: UIGestureRecognizer, shouldRecognizeSimultaneouslyWith otherGestureRecognizer: UIGestureRecognizer) -> Bool {
    return false
  }
}

extension UIApplication {
  func hideKeyboard() {
    let scenes = UIApplication.shared.connectedScenes
    let windowScene = scenes.first as? UIWindowScene
    guard let window = windowScene?.windows.first else { return }
    let tapRecognizer = UITapGestureRecognizer(target: window, action: #selector(UIView.endEditing))
    tapRecognizer.cancelsTouchesInView = false
    tapRecognizer.delegate = self
    window.addGestureRecognizer(tapRecognizer)
  }

여기에서 봐야할 내용은 위의 shouldRecognizeSimultaneouslyWith 부분이다. 해당 함수는 화면의 제스처를 동시에 입력 받을 것인가? 하는 함수이며 true를 반환하면 받겠다. false를 반환하면 받지 않겠다는 의미이다. 처음엔 단순히 터치를 하면 키보드를 내리기 위해 찾아온 코드였지만 뜻하지 않게 유용하게 사용하였다.

검색을 했을때 찾은 내용은 주로 스크롤 뷰 같은 상황에서 세로 스크롤과 가로 스크롤의 다중 지원에 관한 내용이었다. 그럼 다수의 텍스트 필드에서는 어떻게 사용이 되었을까?

동시 제스처를 받아온다는 것은 텍스트 필드 진행중인 상황에서 다른 텍스트 필드를 클릭시 여기 텍스트필드가 터치됐어!! 라는 반응을 받아들인다는 것이니 키보드는 밑에서 다시 위로 등장한다.
반면 false를 반환하면 터치중일때 텍스트 필드 터치에 대한 동시 제스처를 받아오지 않아 키보드는 다시 뜨지 않는다. 이러면 텍스트 필드가 터치가 안되는거 아니냐고 할 수 있지만 커서는 다행히 다른 텍스트 필드로 넘어간다. 또한 텍스트 필드 사용중 버튼을 눌러서 특정 행동이 일어날 경우에도 원래라면 키보드가 내려가야하지만 false를 반환하면 작성중인 화면을 유지 할 수 있다. (예를 들면 작성중 + 버튼을 눌러서 Todo Row가 추가되어도 계속해서 작성할 수있다! true를 반환하면 + 버튼을 누를 시 키보드가 내려간다)

이는 아마도 터치에 대한 시스템의 반응을 제한하는 것으로 보인다. 버튼을 터치하면 발생하는 반응을 보기위해 화면이 보여야하고 텍스트 필드를 터치하면 작성하기 위해 키보드가 등장해야한다. 라는 시스템의 반응이 동시에 일어나지 못하게 막아 기존에 진행중이던 반응을 계속보이는게 아닌가 한다

Feedback(피드백)

프로젝트를 종료하고 진행한 팀 회고에서 피드백을 받았다

우선 나의 팀원들이 말해준 나의 강점은 스스로의 페이스를 유지하는 것과 논리적으로 생각을 표현하는 것이라고 해주셨다. 아직은 많이 부족하지만 먼 훗날에 거목같은 사람이 되고 싶다고 평소에도 생각해서 매우 뿌듯했다.

다음은 부족한 부분, 고쳤으면 좋겠는 모습인데 두분 다 질문을 두괄식으로 해주는 것이 좋다는 것이다. 프로젝트 중에 항상 질문 있습니다! 라고 운을 땐것에서 기인한것인데 이는 프로젝트가 온라인으로 진행되었기 때문이다.. 온라인 수업 자체가 처음이고 디스코드와 같은 통화 앱을 쓴것이 정말 오랜만이어서 질문 있습니다!로 운을 땐것이었다. 현재는 어색해하는 부분은 많이 나아졌고, 스스로 질문의 내용이 정리가 잘 안되어있다는 느낌을 받는 경우가 많았는데 이것도 영향을 준것같아 질문을 하기전에 한번 더 질문을 정리하는 습관을 가져야 할 것 같다

마지막으로는 "앞으로 해보면 좋을 것 같다". 프로젝트 초반에 디자인, 개발환경 파트를 둘로 나누었을때, 같이 디자인 파트를 진행한 팀원분께서 남겨주셨다.

피그마를 이번 프로젝트로 처음 써보게되었는데 매우 신기한 경험을 많이 하면서 즐거워했던거 같다. 아마 팀원분께서 그러한 모습을 보고 칭찬을 해주시면서 디자인 부분을 조금 더 다뤄보면 나중에 다른 프로젝트에서 디자이너와 소통이나 나의 아이디어를 표현 하는데 있어서 더 도움이 될 것 같다고 말씀해주신거 같다. 평소 무지에서 비롯된 생각을 표현하지 못하는 상황을 달가워 하지 않기때문에 정말 도움이 되는 말씀이었다. 그래서 개발자에게 도움이 될 만한 디자인파트는 공부해보기로 했다.(다만,,, 아직 개발도 많이많이 부족하기에 개발을 진행하면서 접하게 되는 파트부터 조금씩 공부해 나아가는걸로! 이번 프로젝트로 알게된 디자인파트 내용은 여기에서확인이 가능하다)

Future Actions(향후 행동)

다수의 텍스트필드에서의 함수에 대한 내용은 사용하면서 내가 느낀!? 그런 정리라 좀 더 세부적인 내용을 찾아보고 따로 정리를 해야겠다!
SwiftUI를 시작한지 몇주가 안되었기 때문에 점차 더 많은 프로젝트를 진행하면서 실력을 쌓을 것이다(너무 당연한 얘기...)
피드백 받은 부분에서 강점은 더 키우고 부족하고 고쳐야하는 부분은 고치고 해보면 좋겠는건 해보는게 너무나도 당연한 것이다. 이에 대한 행동은! 때때로 블로그를 통해서 과정? 결과? 같은걸 보여줄 생각이다 물론 다음에 올라온 회고에서는 좀 더 성숙해진 실수는 덜하고 더 나은 사람이 되었다는 얘기를 작성하고 싶다!

Feelings(느낌)

대학교 재학중 교내 개발팀 활동을 하긴했지만 그땐 같이 작업이 가능한 iOS 개발자가 없었기 때문에 iOS 개발자와 협업은 처음이었다.

처음으로 컨벤션을 지켜가며 작업하고, 깃허브로 공유하고 일을 나눠서 진행했다 첫날에 개발을 할때는 규칙도 어색하고 생각해야할 것이 많아서 우왕좌왕하며 실수를 많이 했는데 점차 나아졌다고 생각한다. 신기한 경험은 규칙과 컨벤션이 많이 불편할거라 생각했는데 익숙해져가니 정해진대로 실행하면되니 오히려 편했다는 것이다.

함께 개발을 진행하고 리뷰를 통해서 각자의 소스를 공유하니 혼자서 개발을 진행할때는 몰랐던 방법을 알게되고 좀 더 나은 코드가 무엇인지 고민하는 과정에서 많은 성장을 한것같다. (첫날에 내가 작성한 코드를 보면 고개가 절레절레 한다)

가장 크게 느낀건 개발이 너무 재밌다. 물론 팀을 너무 잘 만난게 8할 이상이 아닐까 한다!