전환 및 고도화 개발 방향 개발자 의견 정리

총 4명에게 의견을 확인한 결과, 신규 개발 방향 3명, 기존 구조 유지 후 전환 방향 1명으로 정리됩니다.

1. 결론 요약

구분	인원	요지
신규 개발 또는 테이블 재정비 후 개발	3명	기존 테이블과 로직이 오래되어 초기에 정리하는 편이 낫다는 의견
기존 구조 유지 후 전환	1명	개발 기간이 짧다면 기존 SQL, 출력물, XML을 재사용해 개발 부담을 줄이는 편이 현실적이라는 의견

의견의 다수는 신규 개발 방향이었습니다. 다만 단순히 “새로 만드는 것이 무조건 좋다”는 의미보다는, 고도화 범위가 실제로 테이블 구조와 화면 로직을 건드릴 가능성이 크다면 기존 구조를 그대로 가져가는 것이 나중에 더 큰 수정 비용으로 돌아올 수 있다는 판단에 가깝습니다.

반대로 기존 구조 유지 의견은 품질보다 일정과 인력 부담을 우선 고려한 현실적인 의견입니다. 전환 기간이 짧고 초반 실 개발 인원이 제한적이라면, 기존 쿼리와 출력물을 재사용하는 장점이 크다는 점을 강조했습니다.

2. 대표 의견

신규 개발 방향 의견

1. 기존 테이블의 PK 구성이 과도하게 복잡한 경우가 많아 조인과 수정 작업이 불편합니다.
2. 조직, 교과목, 개설강좌 같은 기준 정보가 단일 코드로 연결되지 않고 여러 컬럼 조합으로 연결되어 있어 개발 생산성이 떨어집니다.
3. 기존 로직 중 실제로 사용하지 않거나 정리해야 할 부분이 많아, 화면을 분석하고 불필요한 로직을 걷어내는 데 시간이 들어 전환 자체도 오래 걸릴 수 있습니다.
4. 넥사크로와 EZWORKS 기준으로 화면을 다시 맞추는 과정에서 기존 로직을 그대로 재현하는 것도 생각보다 시간이 걸립니다.
5. 전환 후 다시 테이블과 화면을 바꾸면 동일 업무를 두 번 손대는 구조가 될 수 있습니다.

기존 구조 유지 후 전환 의견

1. 개발 기간이 짧고 실 개발 인원이 적다면 신규 개발은 일정 부담이 큽니다.
2. 기존 구조를 유지하면 SQL, MyBatis XML, RD 출력물을 상당 부분 재사용할 수 있습니다.
3. 출력물과 쿼리를 거의 새로 보지 않아도 되는 부분은 전환 개발에서 큰 시간 절감 요소입니다.
4. 테이블 구조를 바꾸면 기존 쿼리와 출력물 재사용이 어려워져 초반 개발량이 크게 늘어날 수 있습니다.

3. 상세 의견 정리

의견 1: 기존 구조 유지 후 전환

기존 설계와 코드가 오래되어 개발할 때 불편한 부분은 분명히 있습니다. PK가 많은 테이블도 있고, 현재 개발 기준과 맞지 않는 구조도 있어 고도화가 포함된다면 구조를 정리하는 것이 이상적으로는 맞아 보입니다.

다만 프로젝트 투입 시점과 오픈 일정, 초반 실 개발 인원을 고려하면 신규 개발은 부담이 클 수 있습니다. 기존 구조를 유지하면 SQL과 출력물을 상당 부분 그대로 사용할 수 있어 개발 시간을 크게 줄일 수 있습니다.

따라서 개발자 부담과 일정 리스크를 줄이는 관점에서는 기존 구조를 유지해 먼저 전환하고, 이후 고도화 요구에 맞춰 필요한 부분을 수정하는 방향이 더 현실적이라는 의견입니다.

의견 2: 테이블 재정비 후 신규 개발

기존 테이블 구조를 그대로 사용하면 데이터 관리가 불편하고, 구조상 맞지 않거나 애매한 데이터가 들어가 있는 경우도 있어 보인다는 의견입니다. PK와 FK 관계를 사용하는 과정도 번거롭다고 보았습니다.

특히 조직 정보를 연결할 때 단일 조직코드가 아니라 대학코드, 학과코드, 전공코드처럼 여러 컬럼이 함께 PK에 포함되는 구조가 있어 조인 조건이 길어집니다. 교과목이나 개설강좌도 단순 코드로 연결할 수 있을 것 같은데 여러 컬럼을 조합해 연결해야 하는 경우가 있어, 화면과 쿼리를 만들 때 복잡도가 커집니다.

고도화가 포함된다면 이런 구조를 계속 끌고 가기보다, 바꿀 수 있는 부분은 초기에 바꾸고 개발하는 편이 낫다는 의견입니다.

의견 3: 기존 로직 참고 후 우리 기준으로 재구현

현재 수행 중인 프로젝트에서는 테이블을 그대로 두고 먼저 전환한 뒤 고도화하기로 했지만, 실제 개발 과정에서는 마이그레이션이 생각보다 빠르지 않다는 의견입니다.

기존 화면을 그대로 맞추려면 내부 로직을 계속 확인해야 하고, 그 로직이 어떤 흐름으로 실행되는지도 분석해야 합니다. 넥사크로와 EZWORKS 기준에 맞춰 다시 구현하는 과정에서는 결국 기존 로직을 참고하되 우리 방식으로 재구현하는 부분이 많아집니다.

따라서 단순 전환처럼 보여도 실제 개발 시간은 적지 않으며, 나중에 고도화하면서 다시 바꿔야 한다면 처음부터 우리 기준으로 정리하는 편이 나을 수 있다는 의견입니다.

의견 4: 신규 개발 방향

화면 자체가 복잡하고, 사용하지 않는 로직이나 정리해야 할 쿼리가 많아 보인다는 의견입니다. 기존 구조는 PK가 많아 작업 시 고려해야 할 항목이 많고, 고도화 단계에서도 계속 신경 써야 할 가능성이 큽니다.

기존 출력물이나 SQL을 그대로 사용할 수 있다는 장점은 인정하지만, 그 장점을 감안하더라도 고도화까지 고려하면 신규 개발 방향이 더 낫다는 의견입니다.

4. 종합 의견

이번 의견 수렴만 놓고 보면 개발자 관점에서는 신규 개발 또는 테이블 재정비 후 개발 의견이 더 많았습니다. 이유는 기존 구조의 복잡도, 과도한 복합키, 불필요한 로직, 고도화 시 재수정 가능성 때문입니다.

다만 일정과 인력이 촉박한 경우에는 기존 구조 유지 후 전환이 현실적인 대안입니다. 특히 RD 출력물, SQL, MyBatis XML 재사용 비중이 큰 업무는 기존 구조를 유지하는 편이 초반 오픈 리스크를 줄일 수 있습니다.