Common Service의 문제점...
임성현
KSUG에 무슨 글을 올려야 할지. 망설여져서
구경만 하다가, 최근 답답한 현상들을 보면서 다른 분들의 생각을 들어보려 합니다.
이슈:
- 화면중에서 단순 CRUD를 사용하는 경우, Service는 CommonService하나 만들어 놓고,
QueryID를 통해서 DB의 결과만 제공하는 형태에 대한 불만.
- 개발하는 공수는 줄겠으나(화면-Service-SQL 대비 1/3 절감 효과)
설계 시점에서 메소드가 도출되지 않는다.
- 또한, CommonService를 활용하는 개발자가 학습을 통해서
설계 되어 있는 클래스를 제거 하고 비즈니스 로직을 화면 또는 SQL에 담는다.
--> 설계 준수성이 떨어진다.
그래서도,
단순 화면 구현하는데 모두 다 만들어야 하냐.는 것은 아니라도,
단순한 화면의 기준은 무엇이냐. SQL은 어느정도 복잡도 또는 분기를 담고 있어야 할지
이 부분에 대한 고민이나 감안 없이...
결국 모든 시스템은 화면 -SQL으로 만들어지는 과거 4GL의 형태로 돌아가겠습니다.
개발 생산성이 장땡이다. 라고 하시겠지만.
프로젝트 막바지에 통상 밀려오는 요구변경의 파도에 에러가 더 증가하겠죠.
다른분들의 의견은 어떠신지요?
참조로... 제가 이야기드리는 규모는
동시 개발자 120명, 화면 8,000개 이상, 개발 기간 6개월 미만 수준 들에서 겪는
상황입니다.
Sanghyuk Jung
뭐 쉽지는 않을듯하네요 ^^;
박성철
제 경험상 경직된 아키텍쳐를 개발자들에게 주면 개발자들은 예외상황에도 항의하지 않고 묵묵히 일을 처리하더군요. 별별 희안한 창의
적인 방법으로 엉터리 코드를 만들어 내면서 말이죠. ㅎㅎ
전에 MiPlatform을 쓰신다고 하셨던 것 같은데 제가 이번에 접해보니 정말 2-Tier 환경에서 개발하던 방식 그대로 쓰
기 좋게 만들었더군요. 비지니스 로직을 넣기 좋은 곳도 마련되어 있고... 경력있는 개발자들은 무지 좋아하던데요? 막 VB랑
완전 똑같다고 감탄하면서... 제가 보기에도 한국 상황(?)을 잘 반영한 것 같습니다.
전 CommonService 자체를 반대하지 않습니다. 하지만 역할이 명확해야하고 예외 상황이 있으면 쉽게 확장할 수 있도록 해
야지 이거 하나가 이것 저것 처리하는 SuperCommonService가 되면 문제가 된다고 봅니다. 이름이 물론
CommonService는 아니겠지만 좀 제한적인 이름이면 도움이 될 것 같고요.
도메인 모델 없이 단순히 Service를 만드는 것만으로는 프로젝트 막판 변경 요청에 대응하기에 역부족이라고 생각합니다.
Service를 만든다고 해도 대부분 로직은 어짜피 SQL에 들어가거나 분산, 중복되기 때문이죠
사실 120명이 8,000개 이상 화면을 6개월이라는 단기간에 만든다는 상황 자체가 엽기적이네요.
안영회
- 화면중에서 단순 CRUD를 사용하는 경우, Service는 CommonService하나 만들어 놓고,
QueryID를 통해서 DB의 결과만 제공하는 형태에 대한 불만.
- 개발하는 공수는 줄겠으나(화면-Service-SQL 대비 1/3 절감 효과)
설계 시점에서 메소드가 도출되지 않는다.
- 또한, CommonService를 활용하는 개발자가 학습을 통해서
설계 되어 있는 클래스를 제거 하고 비즈니스 로직을 화면 또는 SQL에 담는다.
--> 설계 준수성이 떨어진다
매개변수는 크게 네 가지 종류입니다.
- CRUD 중 무엇이냐 하는 태그(멀티 CUD를 지원하는 Save 포함)
- iBatis Statment id (사실 비즈니스 로직이 오직 SQL이나 화면 스크립트에만 있는 경우죠)
- 입력 데이터 셋 (Ajax Grid나 X-internet/ActiveX Grid 지원)
- 조회 조건 등
성현님 사례처럼 4GL과 유사한 개발 방식이죠. 서버 로직은 아예 사라집니다. 보통 이런 식으로 개발하는 곳은 개발자가 화면과 서버를 같이 개발하는 경우인데, 컨택스트 스위칭 비용도 발생하지 않으니 공수는 줄죠.
인당 절대적인 개발 본수가 큰 경우는 나쁜 방법이라고만 말할 수는 없습니다. 문제점을 아래와 같이 지적하셨는데요.
그래서도,
단순 화면 구현하는데 모두 다 만들어야 하냐.는 것은 아니라도,
단순한 화면의 기준은 무엇이냐. SQL은 어느정도 복잡도 또는 분기를 담고 있어야 할지
이 부분에 대한 고민이나 감안 없이...
개발 생산성이 장땡이다. 라고 하시겠지만.
프로젝트 막바지에 통상 밀려오는 요구변경의 파도에 에러가 더 증가하겠죠.
그렇다면 어떻게 개선을 할 수 있을까요?
제가 지금 참여하는 사이트에서 문제를 어떻게 해결했는지 말씀드리죠. 여기서는 서버 로직을 구현합니다만, 비정형성을 갖은 업무는 아직 개발이 시작되지 않아 현재까지는 매우 정형화된 프로그램만 있습니다. 그래서, 화면을 제외하면 거의 서버 코드의 90%는 자동생성을 합니다. 자동생성은 이클립스에서 하지만 코드 템플릿은 프리마커 템플릿 형태의 텍스트를 생성시점에 파싱하기 때문에 언제든 생성하는 구문을 바꿀 수도 있죠.
그러다 보니 (예상대로) 자기가 짠 코드가 뭔지 모르는 현상이 발생했습니다. (당연하게도) 대부분의 코드가 자동으로 만들어지니 굳이 왜 그런 코드가 만들어지는지에는 관심이 없더군요. 그래서 개발자 테스트를 강제할 수 있었습니다. 개발자 테스트가 주는 이점은 당연히 품질 향상이지만, 그 이면에는 다음과 같은 효과가 있었습니다.
- 변화에 대한 적응력 향상: 테스트 케이스 구현 과정에서 경계값(null value, 예외 상황 등)이나 다양한 사례를 수용하는 상황을 반영하다 보면 기존 코드를 반복해서 고치는 일을 수용합니다. 한번 만들고 나서 고쳐달라면 짜증을 내던 태도가 점차 완화되고... 몇 달 후 마치 다른 사람처럼 중복 없애라거나 Validation 코드를 고치라고 하면... 안한다는 말 대신 어렵다면 도움을 요구하죠. :)
근데 전제 조건이 있죠
- 물리적인 시간 확보(개발자 테스트란 것이 대충 해치우는 습관을 버리는 일이라 마치 제조물 생산자 책임제랑 비슷할만큼 초기 진입장벽이 있죠.)
- 개발자 테스트가 갖는 권위 확보: 보통 기업에서 뭔가 성공하려면 최고 결정권자의 의지가 중요하단 말을 하죠. PM이 무게를 실어주지 않으면 100% 실패죠. PM을 설득하려면 그들에게 무기(?)를 줘야 합니다. 제 경우는 코드 진척도/품질에 대한 투명성 제고로 해결했습니다.
더 구체적으로 쓰고 싶지만 일과중이라 어렵군요.. 쓰레드가 이어지면 나중에라도 덧붙이겠습니다.
임성현
뭐... 제가 지금 상황에서는 할 일이 별로 없습니다.
여기는 아니고, 다른 곳에서는..
PM님. 설계한 클래스가 어느날 UML에서 사라졌습니다.
개발자님. 왜 여기에 이런 것을 넣으셨나요.. 라는
소스 레벨에서의 투명한 설명을 덧붙이면서
그나마 세워 놓은 아키텍처를 마지막까지라도 지키려고 노력 합니다.
다만,
다음엔 그래서도 프로젝트 초기에 들어가서 *개발시간*도 확보하고 *현실적*이면서도 구체적인 *지킬 수 있는*
아키텍처 표준을 고민하려 합니다.
지금 제가 어떻게 해야할지.. 라는 부분에 대해서 말씀하신 내용들 정말 감사합니다.
그렇다면, 다시...추후 새로운 프로젝트가 시작될때
공통 서비스를 어떻게 바라보면 좋을까요?
다시 더 구체적으로,
유스케이스에 도출 되어 있으나, 클래스 명세서에서는 공통으로 묶여지는,
다시 구현 단계에서는 SQL로 나타나는데, 그 내용은 이리저리 복잡하게 얽히는
그 것을 어떻게 통제 해야 할까요?.
On 9월11일, 오후5시39분, 안영회 <ahnyoung...@gmail.com> wrote:
> 여러가지 이야기를 해볼 수 있겠네요. 성현님과 오프에서 두어 차례 들었던 이야기인 터라... 글로 쓰지 않은 맥락까지 읽어 보면 말이죠.
>
> - 화면중에서 단순 CRUD를 사용하는 경우, Service는 CommonService하나 만들어 놓고,
>
> > QueryID를 통해서 DB의 결과만 제공하는 형태에 대한 불만.
> > - 개발하는 공수는 줄겠으나(화면-Service-SQL 대비 1/3 절감 효과)
> > 설계 시점에서 메소드가 도출되지 않는다.
> > - 또한, CommonService를 활용하는 개발자가 학습을 통해서
> > 설계 되어 있는 클래스를 제거 하고 비즈니스 로직을 화면 또는 SQL에 담는다.
> > --> 설계 준수성이 떨어진다
>
> CommonService 하나만 둔니 결국 서비스는 하나이고, 화면에 보여지는 데이터와 UI 요소만 가변성을 부여한 경우네요. H모사에서
> 프레임워크를 만들 때도 4GL이나 SP 위주로 개발하는 분들을 위해 'SQL 기반 프로그래밍'이라는 프로그래밍 작성 방식에 대한 모형을
> 만들었습니다. 내부적으로는 GenericController > GenericService > GenericDao 를 부르죠. 화면은
> X-internet과 JSON 기반 Ajax를 지원하는데 처리 유형과 데이터세트를 HTTP 요청 시점에 보내죠.
>
> 매개변수는 크게 네 가지 종류입니다.
>
> - CRUD 중 무엇이냐 하는 태그(멀티 CUD를 지원하는 Save 포함)
> - iBatis Statment id (사실 비즈니스 로직이 오직 SQL이나 화면 스크립트에만 있는 경우죠)
> - 입력 데이터 셋 (Ajax Grid나 X-internet/ActiveX Grid 지원)
> - 조회 조건 등
>
> 실행 이미지는 스프링 기반 웹 애플리케이션이지만, 개발자는 SQL을 XML에 보관한다는 사실만 기억하면 X-internet 개발툴로 화면
> 스크립팅만 하거나 JSP로 Ajax 로직만 짜죠.
>
> 성현님 사례처럼 4GL과 유사한 개발 방식이죠. 서버 로직은 아예 사라집니다. 보통 이런 식으로 개발하는 곳은 개발자가 화면과 서버를
> 같이 개발하는 경우인데,* 컨택스트 스위칭 비용*도 발생하지 않으니 공수는 줄죠.
>
> 인당 절대적인 개발 본수가 큰 경우는 나쁜 방법이라고만 말할 수는 없습니다. 문제점을 아래와 같이 지적하셨는데요.
>
> 그래서도,
>
> > 단순 화면 구현하는데 모두 다 만들어야 하냐.는 것은 아니라도,
> > 단순한 화면의 기준은 무엇이냐. SQL은 어느정도 복잡도 또는 분기를 담고 있어야 할지
> > 이 부분에 대한 고민이나 감안 없이...
>
> > 개발 생산성이 장땡이다. 라고 하시겠지만.
> > 프로젝트 막바지에 통상 밀려오는 요구변경의 파도에 에러가 더 증가하겠죠.
>
> 그렇다면 어떻게 개선을 할 수 있을까요?
>
> 제가 지금 참여하는 사이트에서 문제를 어떻게 해결했는지 말씀드리죠. 여기서는 서버 로직을 구현합니다만, 비정형성을 갖은 업무는 아직
> 개발이 시작되지 않아 현재까지는 매우 정형화된 프로그램만 있습니다. 그래서, 화면을 제외하면 거의 서버 코드의 90%는 자동생성을
> 합니다. 자동생성은 이클립스에서 하지만 코드 템플릿은 프리마커 템플릿 형태의 텍스트를 생성시점에 파싱하기 때문에 언제든 생성하는 구문을
> 바꿀 수도 있죠.
>
> 그러다 보니 (예상대로) 자기가 짠 코드가 뭔지 모르는 현상이 발생했습니다. (당연하게도) 대부분의 코드가 자동으로 만들어지니 굳이 왜
> 그런 코드가 만들어지는지에는 관심이 없더군요. 그래서 *개발자 테스트*를 강제할 수 있었습니다. 개발자 테스트가 주는 이점은 당연히 품질
> 향상이지만, 그 이면에는 다음과 같은 효과가 있었습니다.
>
> - 변화에 대한 적응력 향상: 테스트 케이스 구현 과정에서 경계값(null value, 예외 상황 등)이나 다양한 사례를 수용하는
> 상황을 반영하다 보면 기존 코드를 반복해서 고치는 일을 수용합니다. 한번 만들고 나서 고쳐달라면 짜증을 내던 태도가 점차 완화되고...
> 몇 달 후 마치 다른 사람처럼 중복 없애라거나 Validation 코드를 고치라고 하면... 안한다는 말 대신 어렵다면 도움을 요구하죠.
> :)
>
> 근데 전제 조건이 있죠
>
> - 물리적인 시간 확보(개발자 테스트란 것이 대충 해치우는 습관을 버리는 일이라 마치 제조물 생산자 책임제랑 비슷할만큼 초기
> 진입장벽이 있죠.)
> - 개발자 테스트가 갖는 권위 확보: 보통 기업에서 뭔가 성공하려면 최고 결정권자의 의지가 중요하단 말을 하죠. PM이 무게를
> 실어주지 않으면 100% 실패죠. PM을 설득하려면 그들에게 무기(?)를 줘야 합니다. 제 경우는 코드 진척도/품질에 대한 투명성 제고로
> 해결했습니다.
>
> Spring의 JUnit 확장 기반 테스트에 모두 생소하지만,* 심리적 장벽*만 넘으면 성철님 말대로 2주면 초급 개발자도 잘 적응해서
igooo
service에 interface만 정의하고 interface에 메소드가 ibatis에 id와 맵핑되어 쿼리를 날리는 구조였습니
다.
Read에 대해서는 DB에서 가져오는 일 말고는 따로 할일이 없다는 생각으로 시작했던거 같습니다. DAO 만들기 귀찮아서 그런
건지..
아무튼 전 중간에 들어가서... 그렇게 만든 의도는 모르겠네요.
Service 구현체와 dao가 없다 보니 점점 Controller에 로직이 늘어나고 중복 코드가 생기고 Controller에
로직이 추가되어 재사용성이 떨어졌습니다.
처음에는 DAO가 필요없으니 생산성을 늘었을지 몰라도, 유지보수와 요구사항이 변경되면서 코드는 점점 나빠졌습니다.
정확히 아래와 같은 상황은 아니지만 위와 같이 했을 때도 생산성은 높아지 않았습니다...
On 9월11일, 오후3시37분, 임성현 <sunghyun....@gmail.com> wrote:
안영회
다음엔 그래서도 프로젝트 초기에 들어가서 *개발시간*도 확보하고 *현실적*이면서도 구체적인 *지킬 수 있는*
아키텍처 표준을 고민하려 합니다.
대형 SI 업체 입장에서 1순위는 사업 관리입니다.
한국에서는 그마나 손가락 안에 드는 회사만 성공을 하죠.
유명 외쿡계 회사도 손해를 보는 마당이니.
레벨 2는 인재 양성입니다.
프로젝트는 시궁창이라도 함께 할 자사 인력에 대해선 엄격하죠.
레벨 3이 비로소 세부 기술에 대해 직접 다루는 일이 아닌가 싶습니다.
그런 곳(회사는 아니고 회사 내 특수 조직)이 있다고는 들었지만
실전에는 저희 회사나 비슷한 부류의 회사에서 책임을 지고 수행합니다.
수익을 남기는데 최고로 알려진 업체지만, 위험을 안고 일하는 이에게는 합당한 보상을 합니다.
주제 넘은 추측이지만 지금 있는 조직에서는 만족스런 결과를 내긴 힘들다 생각합니다.
안정적인 지위와 동시에 도전적인 목표를 성취할 수 있는 기회를 함께 하는 일을 지나친 욕심이 아닐까요?
솔직히 저도 둘 다 거머쥐려고 하다가...
드디어 요즘에야 세상을 배우고... 둘 중 하나를 찾아 방향을 선회했습니다.
앞으로 함께 하시죠.. 일의 내용이나 공간은 달라도.. 지향점은.. :)
박성철
>> 다시 구현 단계에서는 SQL로 나타나는데,
CRUD를 자동으로 처리하는 코드 뭉치를 꼭 service 레이어에 두어야 할까요? 전 서비스는 유즈케이스를 반영한다고 생각합니다. 구현 단계에서 공통으로 처리할 수 있는 요소가 있더라도 이것이 서비스의 설계에 영향을 주어서는 안 되지 않나 싶습니다. CRUD를 공통화 한다 해도 서비스 인터페이스는 유즈케이스에서 도출된 설계를 유지하고 서비스 뒤 계층에서 공통 모듈을 만들어 처리하는 것이 좋겠다는 거죠.
하지만 이건 원칙인 것이고 우리가 처한 현실은 또 그렇지 않습니다. 실무에서 멀티 티어를 쓰기 시작한 게 얼추 10년은 되가는 것 같지만 그건 영업사원들이 미들웨어 팔아 먹으려고 열심히 고객을 설득해서 그렇게 된 것이지 정작 개발 현실은 2-tier 때와 큰 차이가 없습니다. presentation tier에 비지니스 로직이 들어가는 일도 많고 대부분의 중요 로직은 data tier에 복잡한 SQL이나 SP, Trigger 형태로 들어가는...
더구나 최근 x-internet이 시장에서 성공하면서 마치 잃어버린 10년을 되찾기라도 하려는 듯 2-tier식 개발 방식이 다시 자리잡고 있습니다. MiPlatform 교육을 받으면서 가장 먼저 드는 생각은 "Web 기술이라고 말은 하지만 Presentation Tool 치고는 너무 기능이 많군..." 이었습니다. 한국에서 성공하려면 어쩔 수 없었겠지만 제 입장에서는 아쉽더군요. 결국 Client와 Server에 로직이 분산되는 예전 2-Tier의 단점이 이제는 Presentation-Logic-Data의 3-Tier에 골고루 나눠지는 상황이 되었습니다.
극단적으로 단순화 하면 세가지 선택이 가능할 듯 합니다.
먼저 Presentation에 절대로 로직을 두지 않고 Logic-Data Tier로 로직을 밀어내는 것만으로 만족하는 것. 이 방식은 MiPlatform을 쓰는 한 어려울 것 같습니다. 불가능하지는 않겠지만 비용이 너무 많이 들어가고 MiPlatform의 좋은 기능들이 이겨내기 어려운 유혹을 합니다. 바쁜 일정이 유혹에 넘어가도록 부추기고 말이죠.
또 하나는 자동화하거나 역할을 최소화해서 Logic Tier가 단순히 Presentation과 Data를 이어주는 기능만 하도록 해 사실상 2-Tier로 만드는 것... 이 선택이 지금 성현님이 얘기하신 CommonService가 하는 일이라고 생각합니다.
마지막으로 3-Tier 원칙을 준수하는 것... 우리가 통일 다음으로 소망하는 것이지만 갈 길이 너무 멉니다.
SI 현실에서 우리는 최선을 추구하기 보다는 최악을 피하는 것에 대부분 에너지를 소비하는 것 같습니다. 결국 두번째 방식이 그나마 최악을 피할 수 있을 것 아닐까요?
>> 내용은 이리저리 복잡하게 얽히는 그 것을 어떻게 통제 해야 할까요?.
저는 개발을 쉽게할 수 있게 해주는 도구를 지원하는 건 좋지만 그 도구 때문에 개발자가 책임져야 할 부분에서 책임감을 느끼지 못하게 된다면 그 도구는 차라리 없는 게 낫다고 생각하게 되었습니다. 복잡한 도구보다 간단한 체크 리스트가 더 유용할 수도 있는 거죠.
프로젝트에서 관리자와 개발자가 자기 책임을 인식하고 그것을 수행하도록 도움으로서 문제를 해결하도록 하는 것이 더 좋은 길 같습니다.
임성현 쓴 글:
임성현
생산성을 높이기 위해서 화면 개발 도구를 활용하고,
화면 개발 도구는 또한 그 목적에 충실하고자,
우리나라 고객의 입맞에 맞도록 다양한 화면 Form과
기능을 제공하는 현실상.
^^ 쉽게 요약하자면
Mip*. Fle*,Silver*등의 화면 구현 제품은
화면을 뚝딱하고 쉽게 만들기 위해 쓰는 툴이니까.
좀 더 추상적인 원칙 보다는
현실적인 이유와 사례를 가지고 대응해야 하겠다는 생각이 듭니다.
**이 부분은 차근차근 준비해서 기회가 되면 공유하겠습니다.
지난 주엔, 개발만 하시다가 처음 SA를 맡은 친구를 만나봤습니다.
고민하는 것이...
Layer를 3개로 나눌지, 4개로 나눌지 망설여진다고 하네요.
SA로써는 4개의 Layer로 나누고 싶지만,
개발 기간과 개발자 성향을 감안하면.
3개의 Layer로 가야 할 것 같고.
이번주에는 최선의 결정을 내렸길. 바라고 지켜보고 도와주렵니다.
그럼.. 모두 즐거운 한주 되세요.
임성현 드립니다.