API를 개발할때 REQ객체에 DB 컬렴명을 동일하게 사용하는것과 userNm이면 name으로 변경해서 사용하는것 중 어느것이 더 적합한가?

Question

스프링개발중, mybatis mapper를 사용해서 개발중입니다.API를 개발할때 REQ객체에 DB 컬렴명을 동일하게 사용하는것과attendeeName을 name으로 변환해서 사용하는 것을 팀에서 고민중입니다. 각 장단점은 아래와 같습니다. DB 컬럼명을 동일하게 사용하는 경우장점:1.일관성: DB 컬럼명과 객체 필드명이 동일하면, 데이터의 흐름을 이해하고 추적하기가 더 쉽습니다. 이는 개발과 디버깅 과정을 간소화 할 수 있습니다.2.개발 효율성: 변환 로직이나 매핑 로직을 추가로 작성할 필요가 없기 때문에, 개발 속도를 높일 수 있습니다.단점:1.유연성 부족: DB 스키마가 변경되면, 해당 변경사항이 직접적으로 API와 연결된 객체에 영향을 미칩니다. 이는 유지보수에 더 많은 노력을 요구할 수 있습니다.2.보안 문제: 내부 DB 컬럼명을 그대로 노출하는 것은 보안상 좋지 않을 수 있습니다. 특히, 외부에 공개되는 API의 경우 더욱 주의가 필요합니다.attendeeName을 name으로 변환해서 사용하는 경우장점:1.추상화 및 캡슐화: DB 스키마의 변경이 API와 연결된 객체에 미치는 영향을 최소화 할 수 있습니다. 이는 시스템의 유연성을 증가시킵니다.2.보안 강화: 내부 DB 구조에 대한 정보를 숨길 수 있으므로, 보안성이 향상됩니다.13API 사용성 개선: 사용자 친화적인 필드명을 사용할 수 있어, API의 사용성을 높일 수 있습니다.단점:1.개발 복잡도 증가: 매핑 로직을 추가해야 하므로, 개발 과정이 더 복잡해질 수 있습니다.2.성능 이슈: 매핑 과정에서 추가적인 처리가 필요하므로, 성능에 미세한 영향을 줄 수 있습니다.결국 선택은 프로젝트의 요구사항, 보안 정책, 유지보수성, 그리고 개발 팀의 선호도에 따라 달라질 수 있습니다. 보안과 유연성을 중시한다면 매핑을 통한 변환 방식을, 개발의 신속성과 단순성을 우선시한다면 DB 컬럼명과 동일하게 사용하는 방식을 선택할 수 있습니다. 오키 회원 선배님들의 조언을 듣고 싶습니다.감사합니다. 1번예제(DB 컬럼명을 동일하게 사용하는 경우){ &#34;eattendeeTmModelList&#34;: { &#34;*eventsNo&#34;: 1, &#34;*attendeeNo&#34;: 98, &#34;clientNo&#34;: 331, &#34;*userNo&#34;: 202, &#34;eattdTmDate&#34;: &#34;2023-12-07 14:32&#34;, &#34;*eattdReqStatus&#34;: &#34;Progress&#34;, &#34;*eattdRegStatus&#34;: &#34;Attend&#34;, &#34;*eattdTranStatus&#34;: &#34;Y&#34;, &#34;*eattdAccomStatus&#34;: &#34;Y&#34;, &#34;*eattdMealStatus&#34;: &#34;Y&#34;, &#34;*eattdTouristStatus&#34;: &#34;N&#34;, &#34;eattdEsection&#34;: &#34;1&#34;, &#34;eattdTmDesc&#34;: &#34;TM 진행 사항&#34;, &#34;*eattdRegType&#34;: &#34;참석자&#34;, &#34;*eattdRegMethod&#34;: &#34;1&#34; }, &#34;eattendeeTranModelList&#34;: { &#34;*eventsNo&#34;: 1, &#34;*attendeeNo&#34;: 98, &#34;eattdTranAdult&#34;: 1, &#34;eattdTranCate&#34;: &#34;Ktx&#34;, &#34;eattdTranChild&#34;: 1, &#34;eattdTranReq&#34;: &#34;예약 부가 정보&#34;, &#34;eattdTranTypeList&#34;: [ { &#34;eattdTranDate&#34;: &#34;2023-02-04&#34;, &#34;*eattdTranType&#34;: &#34;출발편&#34;, &#34;eattdTranSection&#34;: &#34;출발 교통 구간 여수->용산&#34;, &#34;eattdTranStime&#34;: &#34;10:10&#34;, &#34;commFilesList&#34;: [ { &#34;commFilesNo&#34;: 253, &#34;commFilesCol&#34;: &#34;eattd_tran_type_no&#34;, &#34;commFilesKey&#34;: 23, &#34;commFilesNm&#34;: &#34;240665e0-cec5-417e-b2eb-a3c8a77a232e.png&#34;, &#34;commFilesOrg&#34;: &#34;조식1.png&#34;, &#34;commFilesType&#34;: &#34;image/jpeg&#34;, &#34;commFilesPath&#34;: &#34;2024/03/26&#34;, &#34;commFilesSize&#34;: 48141, &#34;commFilesUrl&#34;: &#34;&#34; } ] }, { &#34;eattdTranDate&#34;: &#34;2023-02-05&#34;, &#34;*eattdTranType&#34;: &#34;귀가편&#34;, &#34;eattdTranSection&#34;: &#34;출발 교통 구간 용산->여수&#34;, &#34;eattdTranStime&#34;: &#34;12:30&#34;, &#34;commFilesList&#34;: [ { &#34;commFilesNo&#34;: 254, &#34;commFilesCol&#34;: &#34;eattd_tran_type_no&#34;, &#34;commFilesKey&#34;: 24, &#34;commFilesNm&#34;: &#34;240665e0-cec5-417e-b2eb-a3c8a77a232e.png&#34;, &#34;commFilesOrg&#34;: &#34;석식1.png&#34;, &#34;commFilesType&#34;: &#34;image/jpeg&#34;, &#34;commFilesPath&#34;: &#34;2024/03/26&#34;, &#34;commFilesSize&#34;: 48141, &#34;commFilesUrl&#34;: &#34;&#34; } ] } ] }, }2번예제 (attendeeName을 name으로 변환해서 사용하는 경우){ &#34;eventName&#34;: &#34;리리카&#34;, &#34;eventPlace&#34;: &#34;string&#34;, &#34;eventStartDate&#34;: &#34;string&#34;, &#34;eventEndDate&#34;: &#34;string&#34;, &#34;notice&#34;: { &#34;notice&#34;: &#34;string&#34;, &#34;mealNotice&#34;: &#34;string&#34;, &#34;accomNotice&#34;: &#34;string&#34;, &#34;tranNotice&#34;: &#34;string&#34; }, &#34;attendee&#34;: { &#34;name&#34;: &#34;이인컴&#34;, &#34;hospital&#34;: &#34;인컴세브란스병원&#34;, &#34;mobileTel&#34;: &#34;010-2222-3333&#34; }, &#34;tran&#34;: { &#34;adult&#34;: 1, &#34;child&#34;: 1, &#34;cate&#34;: &#34;KTX&#34;, &#34;additionalInfo&#34;: &#34;예약부가정보&#34;, &#34;departure&#34;: { &#34;section&#34;: &#34;부산->인천&#34;, &#34;date&#34;: &#34;string&#34;, &#34;startTime&#34;: &#34;string&#34;, &#34;arrivalTime&#34;: &#34;string&#34;, &#34;images&#34;: [ { &#34;commFilesNo&#34;: 253, &#34;commFilesCol&#34;: &#34;erefund_no&#34;, &#34;commFilesKey&#34;: 1, &#34;commFilesNm&#34;: &#34;240665e0-cec5-417e-b2eb-a3c8a77a232e.png&#34;, &#34;commFilesOrg&#34;: &#34;조식1.png&#34;, &#34;commFilesType&#34;: &#34;image/jpeg&#34;, &#34;commFilesPath&#34;: &#34;2024/03/26&#34;, &#34;commFilesSize&#34;: 48141, &#34;commFilesUrl&#34;: &#34;&#34; } ] }, &#34;returnTran&#34;: { &#34;section&#34;: &#34;부산->인천&#34;, &#34;date&#34;: &#34;string&#34;, &#34;startTime&#34;: &#34;string&#34;, &#34;arrivalTime&#34;: &#34;string&#34;, &#34;images&#34;: [ { &#34;commFilesNo&#34;: 253, &#34;commFilesCol&#34;: &#34;erefund_no&#34;, &#34;commFilesKey&#34;: 1, &#34;commFilesNm&#34;: &#34;240665e0-cec5-417e-b2eb-a3c8a77a232e.png&#34;, &#34;commFilesOrg&#34;: &#34;조식1.png&#34;, &#34;commFilesType&#34;: &#34;image/jpeg&#34;, &#34;commFilesPath&#34;: &#34;2024/03/26&#34;, &#34;commFilesSize&#34;: 48141, &#34;commFilesUrl&#34;: &#34;&#34; } ] } }, &#34;accom&#34;: { &#34;place&#34;: &#34;파크하얏트 부산&#34;, &#34;type&#34;: &#34;스탠다드&#34;, &#34;mealType&#34;: &#34;조식, 중식, 석식&#34;, &#34;requestDetails&#34;: &#34;string&#34;, &#34;chkInDate&#34;: &#34;2023-12-19&#34;, &#34;chkOutDate&#34;: &#34;2023-12-20&#34;, &#34;description&#34;: &#34;체크인은 1층 심포지업 데스크에서 체크아웃은 호텔 프런트 데스크에서 하시면 됩니다.&#34;, &#34;roomImages&#34;: [ { &#34;commFilesNo&#34;: 253, &#34;commFilesCol&#34;: &#34;erefund_no&#34;, &#34;commFilesKey&#34;: 1, &#34;commFilesNm&#34;: &#34;240665e0-cec5-417e-b2eb-a3c8a77a232e.png&#34;, &#34;commFilesOrg&#34;: &#34;조식1.png&#34;, &#34;commFilesType&#34;: &#34;image/jpeg&#34;, &#34;commFilesPath&#34;: &#34;2024/03/26&#34;, &#34;commFilesSize&#34;: 48141, &#34;commFilesUrl&#34;: &#34;&#34; } ] },

슈퍼복붙러 · Answer

후자로 하더라도 개발 퍼포먼스에 특별히 영향을 주진 않습니다.

아직초보입니당 · Answer

개발 과정에서 의미가 명확한 변수명을 사용하는 건 매우 중요한데요.데이터베이스 컬럼명 그대로 명세서에 작성하면 축약된 이름이 들어가게 될텐데축약된 이름은 코드를 처음 접하는 사람이나 나중에 코드를 유지 보수할 때 혼란을 줄 수 있습니다.따라서 축약된 이름, 객체 구조에서의 중복은 피해 간결하고 명확하게 표현하는 게 바람직 합니다.이러한 방식은 코드의 가독성, 팀원 간의 의사 소통을 원할하게 하며 유지 보수의 효율성을 증가시킵니다.2개의 자체 서비스 기업을 거치면서 1번 코드는 본적이 없습니다.

wharup · Answer

API는 공개되는 스키마와 내부 스키마는 분리하는게 정석입니다. 공개된 API를 다른 팀이나 다름 회사가 사용하는 것을 전제로 하니까말씀하신 사용성 개선, 캡슐화, 보안강화를 우선적으로 고려하는게 맞습니다.거기에 개발 복잡도, 성능 등의 단점은 재사용성을 위해 감수해야 하는 포인트죠.그런데 API가 목표가 아니고우연히 기술 스택을 SPA + REST API로 선택한 경우도 있을텐데요그렇다면 DB 컬럼명을 그대로 반영하는 것도 허용할 수 있다고 생각합니다.한 사람이 프론트/백을 같이 담당하고 남이 API를 볼 일도 없다면생산성을 위해 레이어도 줄이고, Swagger도 스킵할 수 있겠지요.

API를 개발할때 REQ객체에 DB 컬렴명을 동일하게 사용하는것과 userNm이면 name으로 변경해서 사용하는것 중 어느것이 더 적합한가?

3개의 답변

Q&A 목록