요즘 내 머리 속에는 FE용 스레드, BE용 스레드, 발표용 스레드, 그리고 일상용 스레드 이렇게 4개가 돌아가고 있는거 같다. 밥먹으면서도 자꾸 아이디어가 떠오르고 끊임없이 고민하고 있는데, 의식해서 하는게 아니라 그냥 온 정신이 거기에 쏠려있다. 농구 생각이 거의 나지 않는다는게 내 인생에서 가능한 일인가 싶었는데 요즘이 딱 그렇다.
나만의 무기 만들기
오늘은 최종발표 전까진 포스터나 피피티 등을 수정하며 발표 준비를 함께하고, 장장 2시간에 걸친 최종발표 이후에는 협력사 설명회까지 있어서 작업은 많이 하지 못했다. 그래도 굵직굵직한 것들을 해결했다.
정글에서의 마지막 발표
오늘은 정글에서 진행하는 최종발표가 있었는데, 한 줄 요약하자면 썩 좋진 않았다. 우선 발표 관련하여 처음으로 좋지 않은 피드백이 나왔다. PPT는 그대로인 상태에서 스크립트는 2분가량 늘어났고, 그러다보니 한 페이지마다 말하는 양이 상당히 늘어났다. PPT 양 대비해서 너무 장황하다는 류의 피드백을 받고, 우리 팀은 그냥 발표 자체를 새로 구성하기로 했다.
또한 실시간으로 메세지를 주고받는 시연을 했는데, 갑자기 거기서 제대로 답장이 도착하지 않았다. 대화방을 나갔다가 다시 접속하니 주고받은 메세지가 나타는거로 봐선 양쪽 다 소켓에 잘 연결되었단 것인데... 지금은 이유를 파악했지만(아래에서 설명할 것임) 시연 당시엔 정말 혼란스러웠다. 그런 와중에 '채팅 기능은 그냥 하면 되는 것'이라는 류의 피드백이 돌아와서 속상하고 어이없기도 했다. 단순히 존재하는 패키지만 갖다붙이면 해결되는, 겉보기에만 어려운 '기술적' 챌린지보다, 어떻게 해야 실제 채팅 서비스를 만들 수 있을지 고민하고 하나하나 짜는 것이 우리 수준에서는 진정한 챌린지가 아닐까?
밀린 글도 쓰고.. 속상하지만 털어내고 남은 기간에 할 수 있는 것에 집중하기로 했다. 의장님이 직접 말씀하셨지만 내 인생은 내 것이니까. 나는 규모가 큰 기업에서 일하든 작은 기업에서 일하든 전체적인 흐름을 보면서 일할 것이다. 고객에게 전달되기까지의 전반적인 흐름을 파악하고 있고, 거기다 비즈니스 인사이트까지 갖춘 그런 개발자. 그래서 다른 개발자는 알 수 없는 디테일을 콕 짚어내는 대체불가능한 개발자가 될 것이다.
발표자도 아니고, 피피티도 이제 넘겨서 남은 기간 동안에는 온전히 개발에만 집중할 수 있게 되었다. 발표날까지 수정이 필요한 핵심기능들을 작업하면서, 가능하다면 '어플리케이션이라면' 당연히 있어야 한다고 생각한 기능들을 추가해 볼 생각이다.
메세지 기능 수정 - 이미지 경로 수정
사진이 제대로 전달되지 않는 문제가 있었는데, 이로 인해서 어플리케이션이 실행 중에 자꾸 꺼지는 버그가 발생했다. 살펴보니 기존에 샘플 데이터로 작업할 때와 달리, DB에서 가져오는 이미지를 제대로 처리해내지 못했기 때문이다.
처음엔 이유를 밝혀내지 못하다가, debugPrint를 찍어가며 정리해본 결과 채팅화면까지 들어가는 4가지 루트의 이미지를 argument로 전달하는 방식이 달랐다.
- 명함첩에서 친구 프로필을 조회 후 DM 버튼 눌러 들어가기
- 채팅목록에서 선택해서 들어가기
- 명함교환 직후 DM 버튼 눌러 들어가기
- 구글맵에서 친구 프로필을 조회 후 DM 버튼 눌러 들어가기
넷 중에 내가 작업한 1,2번 루트는 가장 첫 번째 단계인 명함첩 혹은 채팅목록에서 파일명 앞에 'http://주소:3000/static/' 을 붙여서 전달해주었다. 반면 3,4번 루트의 경우 오직 파일명만 전달해주고 있었다. 그러다보니 단순히 최종단계인 '채팅화면'에서 'http://주소:3000/static/' 을 적용하고 말고만으로는 해결이 되지 않고 있었다.
이를 파악하고, 3,4번 루트도 최초에 전달하는 '명함교환 직후 친구 프로필'에서 파일명 앞에 주소를 잘 붙이고 전달해주도록 변경했다.
추가적으론, '명함교환 직후 친구 프로필'이나 '구글맵에서 들어가는 친구 프로필'이 일반적인 친구 프로필과 크게 다름이 없음에도 별도의 파일로 분리해놨길래 하나로 합치는 작업을 해주었다. appBar에 나타나는 아이콘이나, 전체적으로 '뒤로가기'를 못하도록 하는 WillScope를 삼항연산자를 이용해서 처리하도록 변경했더니, 모든 친구 프로필은 하나의 dart 파일에서 관리할 수 있게 되었다. 이렇게 하여 코드 자체도 1000줄 가까이 줄지만, 이미지나 채팅 기능에서 필요한 디버깅 양도 1/3으로 줄어들었다.
메세지 기능 수정 - 소켓 방 오류
오늘 시연의 실패이유기도 한데... 위에서 언급한 '루트'와 관련이 있다.
시연에 실패한 직후에 분해서 DB를 확인해보았다.분명 DB에는 양쪽에서 업데이트를 잘 해주고 있는데, 이상하게도 동시에 서로 채팅이 뜨는 것만 안되고 있었다.
그래서 뭐지....? 하고 머리를 싸매고 고민해보았다. 갑자기 어제 구글 맵에서 발생했던 문제가 떠올랐다. 구글맵에서 친구프로필을 접속한 후, 메세지 버튼을 누르면 실시간 채팅이 안되거나 어플이 꺼지는 것이었다. 보니까 구글맵을 작업한 팀원이 int여야 하는 friendId를 String으로 넘겨서 그런 것이었다. 앗 설마...? 하고 친구 프로필에서 채팅방으로 넘어가는 루트를 찍어보니, 여기도 String이었다. 나도 같은 실수를 😙
그래서 채팅목록에서 채팅방에 들어간 사용자 A와 친구프로필에서 채팅방에 들어간 사용자 B가 같은 채팅방에서 서로 메세지는 잘 보내고 있는데, 실시간 소통이 안된 것이다. B가 메세지를 보내면 Node.js에서 SQL문을 처리해 DB에 넣을때는 String이 int화되면서 정상적으로 꽂히는데, socket에서 join을 시킬때는 String 타입의 방번호로 입장을 시킨 것이었다. 같은 24번 방에 대해 DB를 업데이트하지만, 한 명은 24 라는 방에 있고 다른 한 명은 '24' 라는 방에 있으니 서버가 상대방이 보낸 메세지를 emit해줘도 수신이 안된 것....!
...
ProfilePage(friendId: int.parse(friendId))
...그래서 얼른 수정해주었다. 이제는 어느 루트를 통해 들어가도 실시간 채팅도 잘 된다. 혹여나 서버 상태로 인해 소켓 연결이 끊어지는 경우도 대비해서, 소켓 연결이 되어있지 않으면 채팅 입력을 할 수 없도록 hintMessage를 조정하는 작업도 해주었다.
// chat_detail_page.dart
String hintmsg = 'Loading...'; // 최초 접속시 Loading으로
socket.on('connect', (data) {
debugPrint('socket connected');
// debugPrint(socket.connected);
socket.emit('join', widget.chatroomID);
setState(() {
socketFlag = true;
hintmsg = 'Write message...'; // 연결되면 hintmsg 변경
});
debugPrint('연결완료');
});
socket.on('disconnect', (data) {
debugPrint('socket disconnected');
setState(() {
socketFlag = false;
hintmsg = 'Disconnected...'; // 끊어지면 hintmsg 변경
});
socket.disconnect();
});
....
이렇게 hintmsg를 설정해주고, 또한 소켓 연결상태에 따라 아예 TextField를 enable - disable 해주도록 추가해주었다.
enabled: socketFlag ? true : false // 연결된 상태여야 입력 가능
디테일에 집착하는 성격 덕분에 자료형 실수는 거의 안하다보니 지금까진 대수롭게 생각하지 않았는데, 이번 기회에 많이 반성하고 배웠다. 가끔 놓치는 1% 마저도 발생하지 않도록... 항상 경각심을 가지고 코딩해야겠다 :)
