TIL 47 [ Spring 심화 프로젝트 ( D-day ) - 발표/마무리, 트러블 슈팅 ]

오늘 부로 심화 프로젝트가 막을 내렸다.

 

발표도 실수 없이 잘 해낸것 같고, 우리 조 뿐만아니라 다른 조 분들도 잘 마무리한 것에 대해 박수를 보내고 싶다.🙌

 

기초 프로젝트에서 팀 협업을 처음 했을 때 보완해야 했었던 점들을 이번 프로젝트에 적용할 수 있게되어서 굉장히 홀가분 한 기분이며, 하지만 역시 이번 심화 프로젝트를 하면서도 보완해 나가야할 점이 생긴 것 같았다.

 

역시 팀 협업에서는 소통의 중요성이 아주 강한것 같았다.

 

각자의 개성대로 코드를 작성하거나 스타일의 차이 등등 성격 차이로 인해 의견이 오가는 방법도 다를 수 가 있다.

 

프로젝트가 끝나고, 남은 저녁시간에는 KPT 회고를 작성하였다. 

 

2025.04.29 - [[내일배움캠프-Sparta]/KPT 회고] - 아웃소싱 심화 프로젝트 KPT 회고록

아웃소싱 심화 프로젝트 KPT 회고록

작성 한후, 이제 남은 시간동안 여유가 있으니 소통좀 하면서 쉬어가는 시간을 가졌다. 내일 부터는 다시 강의 주차로 돌아가고 팀 구성원이 또 다시 변경될 것이다. 

 

그래서 오늘은 팀 프로젝트를 하면서 내가 겪었었던 트러블 슈팅 2가지에 대하여 작성하면서 마무리를 하려고 한다. 

 

💥 트러블 슈팅 1

배경 :

비밀번호 수정 요청을 시도하는데 똑같은 비밀번호를 입력해도 기존 비밀번호와 일치하지 않다고 예외처리가 발생함.

발단

문제가 발생한 코드는 if (!oldPassword.equals(findUser.getPassword())) 부분이었습니다. 이 부분은 비밀번호가 일치하는지 확인하는 로직이었고, 여기서 oldPassword와 findUser.getPassword()의 값이 서로 다르다는 결과가 나왔습니다. 두 값이 일치하지 않다고 판단되었기 때문입니다.

전개

하지만 문제를 깊이 파고들어 보니, findUser.getPassword()는 암호화된 비밀번호를 반환하고 있었습니다. 반면 oldPassword는 평문 비밀번호로 입력되고 있었습니다. 암호화된 비밀번호를 평문 비밀번호와 비교하려고 했기 때문에 값이 일치하지 않았습니다. 이를 해결하기 위해 PasswordEncoder 클래스의 matches 메소드를 사용해야 했습니다.

위기

그럼에도 불구하고, matches() 메소드의 사용 방법을 잘못 이해한 경우에도 여전히 문제가 발생할 수 있었습니다. 예를 들어, 암호화 방식이 다르거나 PasswordEncoder의 설정이 잘못되었을 때는 여전히 오류가 발생할 수 있습니다. 이 경우 matches() 메소드를 사용하는 것만으로는 문제가 해결되지 않았을 수 있습니다.

절정

실제로 matches() 메소드를 적용한 후, 평문 비밀번호와 암호화된 비밀번호를 비교하는 과정이 정상적으로 이루어지며, oldPassword와 findUser.getPassword()가 이제 일치하는지 정확히 확인할 수 있게 됨. 이후, 예외 처리가 정상적으로 이루어졌고, 비밀번호 변경 요청이 성공적으로 처리됨.

결말

비밀번호 변경 기능이 정상적으로 작동하게 되었고, 사용자는 동일한 비밀번호를 입력해도 기존 비밀번호와 비교할 수 있게 됨. PasswordEncoder 클래스의 사용법에 대해 정확히 이해하고, 암호화된 비밀번호와 평문 비밀번호를 비교할 때는 반드시 matches() 메소드를 사용해야 한다는 점을 명확히 알게됨.

💥 트러블 슈팅 2

배경

회원 정보를 수정하는 과정에서 updateAt 필드가 수정되지 않는 현상이 발생했습니다. updateAt은 회원 정보 수정 시, 수정 시간을 기록하는 필드인데, 이 필드가 데이터베이스에 반영되지 않았습니다. 처음에는 문제를 해결하지 못한 채, 수정된 데이터가 조회되지 않는 현상 ( Reponse에 응답에는 반영되지 않으나, 조회 할때는 반영이 되어있음 )

발단

회원 정보를 수정하는 메소드에서 updateAt 필드를 갱신하려고 했으나, 변경사항이 DB에 반영되지 않는 현상이 발생했습니다. 수정된 후 바로 조회를 하였을 때, updateAt이 여전히 갱신되지 않은 상태로 나왔습니다. 즉, updateAt 값이 변하지 않았고, 이는 데이터베이스에 적용되지 않은 상태라는 것을 의미했습니다.

전개

처음에는 수정된 값이 메모리 상에만 반영되고, DB에 커밋되지 않았다는 사실을 몰랐습니다. 이를 해결하기 위해 flush() 메소드를 사용하는 방법을 찾아냈습니다. flush() 메소드는 트랜잭션 커밋 전이라도, 변경된 내용을 DB에 반영하는 역할을 합니다. 하지만 트랜잭션이 커밋되기 전까지는 영속성 컨텍스트에서의 변경 사항이 실제 DB에 반영되지 않는 점을 간과했기 때문에, updateAt 필드가 갱신되지 않았습니다.

위기

문제를 해결하기 위해 트랜잭션을 수동으로 커밋하거나, 데이터베이스와 영속성 컨텍스트의 동기화 문제를 이해하려 했습니다. 그러나, flush()를 호출하지 않으면 영속성 컨텍스트에서의 변경 사항이 DB에 반영되지 않음을 깨달은 순간, 해결의 실마리가 보였습니다. 또한, flush()는 트랜잭션이 커밋되기 전에 강제로 DB에 반영하도록 하므로, 트랜잭션 커밋 이전에 데이터를 정확히 반영할 수 있다는 점에서 중요한 역할을 한다는 사실을 이해했습니다.

절정

튜터님에게 이 문제에 대해 상담을 했고, flush() 메소드를 호출하면 트랜잭션 커밋 전에 DB에 변경 사항을 반영할 수 있다는 점을 알게 되었습니다. 그 후, updateAt 필드를 갱신한 후 flush()를 호출하여 DB에 바로 반영하도록 수정하였습니다. 이제 회원 정보를 수정한 후, 조회 시에 updateAt 필드가 정상적으로 갱신된 것을 확인할 수 있었습니다.

결말

flush() 메소드를 적절하게 사용하여, 트랜잭션 커밋 이전에 DB에 변경 사항을 반영하는 방법을 알게 되었습니다. 이제 updateAt 필드가 수정된 시간으로 정상적으로 갱신되고, 수정된 데이터가 바로 반영되는 것을 확인했습니다. 이 경험을 통해, 영속성 컨텍스트와 데이터베이스 간의 동기화 문제를 해결할 수 있었습니다. 향후에는 데이터베이스의 트랜잭션 처리와 flush() 메소드의 역할을 충분히 이해하고, 적절히 사용하여 비슷한 문제를 예방할 수 있을 것임.