brunch

You can make anything
by writing

C.S.Lewis

by 가치 Aug 19. 2023

기획 같은 설계 업무를 하면서

feat. 개발자도 아니고 기획도 아닌 어딘가의 영역에서

앞으로의 이야기는 지극히 제 개인의 경험에 기반한 이야기이므로 틀린 내용이 있거나 다른 의견이 있을 수 있습니다. 너그러이 개인의 넋두리로 봐주시면 감사하겠습니다!


먼저, 간단히 제 소개를 하자면 IT 업계에서 개발자로 발을 내디딘 후 어언 만 8년이 넘는 경력을 가지고 있는 평범한 IT 관련 업무를 하는 회사원입니다.  소프트웨어 개발 업무(6년) 기획 같은 설계 or 설계 같은 기획 업무(2년)를 경험했습니다. 


짧은 경험을 가지고 개발자에서 설계자로 역할이 변경되면서 느꼈던 그리고 제가 생각하는 기획. 설계에 대해서 말해볼게요. ( 좀 더 부드럽게 ~요 형식으로 말할게요!)


결론부터 말하자면, 기획자 그리고 설계자는 아래의 역할에 중점이 있다고 생각해요.


기획자

 고객의 요구 사항 분석, 정의하여 현재의 문제를 도출하여 문제해결을 위한 솔루션을 계획하는 사람


설계자

문제 해결을 위한 솔루션을 토대로 소프트웨어 관점에서 구현에 대해 고민하는 사람


위와 같은 생각을 갖게 된 제 설계 경험을 말해볼게요. 설계 업무의 첫 시작은 현재 회사 내 부서 이동이었어요. 그렇게 설계 업무를 담당하게 되었을 때 처음에는 개발을 하면서도 코드 작성을 위한 밑그림이라던지 로직에 대한 설계는 했었기 때문에 뭐 별거 있겠어라는 가벼운 마음이 컸었어요. 그런데 어떻게 코드를 작성할지를 고민하는 것을 넘어서 제가 담당해야 할 영역이 너무 많았어요. 대략 말하자면 아래 항목들이에요


요구사항 분석

요건정의

화면 설계

데이터 베이스 설계

소프트 상세 설계

기능 테스트

성능 테스트

인수 테스트


나한테 주어진 업무니까 처음에는 어떻게든 다 해내려고 꾸역꾸역 했어요. 근데 하면 할수록 이상하다는 느낌이 드는 거예요. 설계자라는 역할은 정말 이 많은 것을 다해야 하는 건가??라는 생각과 너무 많은 것을 담당하다 보니 미래에 대한 불안감도 자리 잡았어요. 그러다 보니 이 불안감을 해소하기 위해서 나 자신의 업무에 대한 정의가 필요한 시점 같았어요. 어떻게 해야 하나 고민하다 chatGPT한테 물어도 보고 직접 서점에 가서 소프트웨어 공학, 시스템 설계, 서비스 기획, UML 등 IT 관련 서적도 봤어요. 그러다 서비스 기획 책을 봤는데 제가 하고 있는 일이랑 많은 부분이 겹치더라고요. UML 책을 보면서는 설계 방법에 대한 부분이 겹치고요.

그래서 든 생각이 기획 + 설계가 합쳐진 업무를 하고 있구나라는 걸 깨닫고, 위에 말한 것처럼 저만의 정의를 내릴 수 있었어요.


한번쯤 자기가 하고 있는 업무에 대한 고민을 해보는 건 어떨까요?



작가의 이전글 인생의 기획을 왜 안했을까?
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari