그땐 그게 최선의 방법이었어_ 오라클 프로젝트 회고(1)

요구분석 : 처음은 늘 막막하다

​ 오라클을 활용한 프로젝트를 시작했다. 화면 구현이나 서버 처리는 하지 않았지만, 실제 기능을 구현하는 것은 처음이라 걱정과 기대가 공존했다.

​ 우리는 요구분석 방법에 대한 논의를 진행했다. 파트를 나눠 조사해 취합하는 방법과 화면 공유를 통해 함께 분석하는 방법 등 여러 의견이 나왔고, 각 방법의 장단점은 분명했다. 기능을 실제로 구현하기 위해서는 전체 사이트에 대한 이해가 필요했기 때문에 파트를 나눠 작업하면 자신이 맡은 부분 외에는 이해가 부족할 수밖에 없으며, 이로 인해 구현에 결함이 생길 가능성도 있었다. 그러나 사이트 전체를 하나하나 보는 것은 시간이 많이 소요될 것이었고, 진행이 더욱 원활하지 않을 것으로 예상되었다. 그래서 우리는 각자가 ‘요구분석 명세서’라는 문서로 사이트 전체를 정리한 후, 이를 바탕으로 회의를 진행하기로 결정했다. 각자가 어느 정도 파악한 상태라면 논의 과정이 보다 부드러울 것이며, 문서로 작성하는 것이 강제성을 부여하므로 목적과도 잘 부합했다.

​ 그러나 회의를 마치고 실제로 작업을 시작해보니 전체 업무 프로세스를 파악하는 것이 예상보다 훨씬 시간이 많이 소요되는 작업임을 깨달았다. 단 하루만에 모든 것을 파악할 수 있는 팀원은 없을 것으로 판단되었다. 그래서 나는 다른 팀원들이 먼저 로그인, 회원 가입과 같은 ‘회원’ 기능을 제외하고 ‘호스트’ 액터의 기능을 우선 조사한 후, 전체 업무 프로세스의 구조도를 설계했다.

​ 회의가 시작될 때, 모든 온라인 회의와 마찬가지로 누구도 선뜻 시작하지 못하는 모습이었다. 이런 상황에서는 누군가 냅다 시작하면 그것을 기반으로 피드백을 주고 받으며 논의할 수 있다. 따라서 나는 간단히 정리한 회원, 게스트, 호스트를 각각 큰 객체로 보는 설계를 화면 공유로 설명했다. 이런 큰 구조에 대한 논의를 통해 각자 조사한 부분을 자연스럽게 나누어 얘기하게 되었고, 이전 프로젝트에서 유용하게 사용한 공유 문서를 만들어 정보를 취합했다. 예상대로 모든 팀원이 사이트의 반 정도만을 조사했고, 호스트 기능을 조사한 팀원은 없었다. 따라서 나는 내가 조사한 내용을 기반으로 호스트 기능을 분석하고 진행하게 되었다. 단독으로 진행하면서도 부족한 부분이 생겨, 시간을 들여 다른 팀원들도 호스트 분석을 진행했다면, 이후 과정에서 효율적이고 정확한 진행이 가능했을 것이 아쉬웠다. 마지막으로 최종 요구분석서를 작성한 후에는 해야 할 일을 정리하고 대략적인 프로젝트 일정을 구성했다.

DB 설계: 그땐 그게 최선의 선택이었어

개념적 모델링 단계로 진입하게 되었다. 일반적으로는 단순히 개체와 속성을 정의하는 단계지만, 우리는 시간 제한으로 인해 개념적 모델링과 병행하여 물리적 모델링을 진행하였다. 이로 인해 각 객체를 순차적으로 검토하며 필요한 칼럼과 그렇지 않은 칼럼을 분류하고, 기본키(PK)와 외래키(FK)를 정의하는 작업을 동시에 진행했다. 이해하기 쉬운 부분은 빠르게 결정하여 작업 속도를 높였으며, 이해하기 어려운 부분이나 의견이 모호한 부분은 오프라인으로 모여 논의하는 방식을 채택했다.

물리적 모델링까지 신속하게 진행되었지만, 초기 요구분석의 시간 부족으로 인해 이후 큰 수정이 필요한 상황이 발생했다. 당시에는 더 많은 시간을 투자하여 요구분석을 철저히 진행했어야 했다는 후회가 있었지만, 당시엔 요구분석 단계에서 어떤 측면을 조사해야 하는지, 어떤 내용을 정리하고 파악해야 하는지에 대한 정확한 방법을 알지 못했고, 오히려 DB 설계를 진행하며 이러한 부분을 더욱 잘 파악할 수 있어 최선이었던 것 같다. 이러한 경험을 토대로, 더 꼼꼼하게, 어떤 방식으로 정리하면 더 효과적일지를 고려하며 다음 프로젝트를 진행할 수 있었다.

요구분석과 모델링을 병행하다 보니 프로젝트 진행이 지연되었고, 계속해서 설계를 수정해야 하는 상황에서 팀원들은 심리적으로나 신체적으로 어려운 시간을 보냈다. 설계를 반복하면서 진도가 더딜 뿐만 아니라, 학원이 종료된 후 곧바로 온라인 회의를 진행해야 했기 때문에 휴식 시간이 거의 없었다. 다양한 어려움을 겪었던 시기였다. 요구분석은 어쩔 수 없이 시간을 할애해야 하는 작업이지만, 개념적 모델링에 더 많은 시간을 투자하며 천천히 진행했다면 물리적 모델링 단계에서 훨씬 더 정확하고 효율적인 결과를 얻을 수 있었을 것 같다.

쿼리작업: 이런건 빠르게, 저런건 천천히

프로젝트를 시작하면서 빠른 쿼리 작업이 필요했기에 회원, 호스트, 게스트로 액터를 나누어 데이터 기능을 구현하도록 제안했다. 모델링 속도가 느려서 다른 팀에 비해 시간적 여유가 없었지만, 꼼꼼하게 DB 설계를 마친 결과, 구현 중에 수정이 필요하지 않아서 오히려 시간을 절약할 수 있었다. 초기에 프로시저를 거의 사용해보지 않았던 점이 걱정이었지만, 쿼리 작업에 익숙해지면서 작업 속도가 빨라졌다. 반면, 다른 팀은 데이터 처리 과정 중에 DB를 엎어야 할 상황이 발생해 많은 시간이 소요되었다. 이를 통해 기초 작업인 DB 설계의 중요성을 깨달았으며 어떤 작업은 빠른 진행이 중요하고, 어떤 작업은 정확한 세부사항이 중요한지를 알게 되었다.

결과적으로 우리 조는 시작이 늦었지만 가장 많은 기능을 구현할 수 있었다. 이번 프로젝트에서는 이전 자바 프로젝트의 교훈을 기억하며 일을 진행했다. 항상 내가 틀릴 수 있음을 인지하고, 의견을 더 객관적으로 바라보기 위해 노력했다. 이렇게 되니 다른 사람의 피드백과 의견을 빠르게 수용하며 내 방식을 수정하는 것이 수월해졌다.

‘이과식 사고방식’에 대한 개념은 처음에는 적용하기 어려웠다. 계획과 기획은 수립했지만 실제 구현과 해결방법을 크게 염두하지 않았다. 그러나 팀원들의 도움으로 이 부분을 보완했다. 팀원들은 설계의 구현 가능성과 복잡도를 솔직하게 제시해주었고, 이를 고려하여 쿼리 복잡도를 결정했다. 이로써 “문제-해결” 마인드를 강화하고 자신의 한계와 시간을 명확히 깨달을 수 있었다.