.webp)
돌이켜보면..
작업 중 가장 많이 했던 질문은 아래 세개 였다.
- 이 기능은 어디 들어가는 부분인가요?
- 이 기능의 기획 의도가 무엇인가요?
- 이후에 확장되거나 수정될 계획이 있나요?
위의 질문을 가장 중요하게 생각한다.
위의 내용을 모르는 상태에서 작업하면 구현한 기능의 구조를 엎어야 하거나, 확장성을 고려하지 않은 코드로 인해 새로운 기능 추가가 힘든 경우가 생길 수 있다.
반대로, 오히려 추가 개발이 필요하지 않거나 약간의 수정만으로 기능 구현을 끝낼 수도 있다.
어떠한 기술을 사용하느냐도 중요하지만, 문제를 반드시 기술에서 찾을 필요는 없다.
문제의 시작
인턴 기간 중 가장 많은 시간을 투자한 작업은 리뉴얼 홈페이지 API 개발이었다.
가장 애를 먹었던 부분은 회원가입 없이 서비스의 일부분을 경험하게 해주는 기능이었다.
회사는 제조업체와 제조를 원하는 업체를 연결해주는 서비스를 제공하고, 유저의 대부분은 주로 연령대가 높은 경우가 많았다.
별도의 회원가입 없이 전화번호만 입력하면 대략적인 발생 금액을 보여주는 흐름의 기능이 필요했다.
그러나 이 기능은 하나가 아니라 최소 4개 이상의 기능이 합쳐져 만들어져야 했고
이 기능들을 하나의 흐름으로 만들어내기 위해 몇가지 문제를 해결해야했다.
그 중 하나는 아래와 같았다.
전화번호를 사용자의 아이디로 사용한다면, 부가적인 사용자 정보는 어떻게 입력해줄 것이며 나중에 로그인은 어떻게 진행할 것인가?
추가 개발이 필요 없겠는걸요..?
첫번 째 문제 "전화번호를 사용자의 아이디로 사용한다면, 부가적인 사용자 정보는 어떻게 입력해줄 것이며 나중에 로그인은 어떻게 진행할 것인가?"의 해결점은 해당 전화번호로 자동으로 생성한 비밀번호를 보내주는 것으로 결론 내려졌었다.
이미 기능은 구현되어 있었고 사용자들에게서 간편하다는 긍정적인 반응을 받아왔었다.
그러나 구현 방식이 문제였다.
단방향 암호화를 사용하고 있기 때문에, 한번 암호화된 사용자의 비밀번호를 평문으로 바꿀 수 없었고, 사용자에게 비밀번호를 다시 보내주기 위해 평문으로 데이터베이스에 저장하고 있었던 것이었다. 이를 발견하여 보고했고, 개발팀에서는 충격을 금치못하며 양방향 암호화를 사용해야하는 것인가 심각하게 고민하기 시작했다.
"그런데... 처음 방문하는 사용자를 위한 비밀번호라면 굳이 매번 같은 비밀번호일 필요가 있을까요?" 라는 질문을 하게 되었다. 그렇다, 사실 첫 방문시 임시 생성된 비밀번호라면 사용자가 입력한 것이 아니기에 항상 같은 필요도 없다.
기획 의도에도 크게 벗어나지 않았다.
이미 메시지 전송 기능은 구현 되어 있기에, 전송되는 메시지의 내용만 랜덤한 비밀번호로 바꾸어서 기능 개발을 몇 분만에 끝낼 수 있었다.
어떠한 기술을 사용하느냐도 중요하지만, 문제를 반드시 기술에서 찾을 필요는 없다.
