SI, Agency 에서 첫 시작을 하고 있는 개발자들을 위하여
서론
SI, Agency 회사에서 2년간 근무하면서 경험한 다양한 내용들을 공유하고자 합니다. SI, Agency 에서 첫 시작을 하고 있는 개발자들(혹은 시작 예정인 개발자들)이 웹 애플리케이션을 개발하거나 배포할 때 꼭 지켜야할 것들과 조언을 드리고자 글을 작성하게 되었습니다.
반드시 따라야할 지침
SI, Agency 회사 뿐만 아니라 대부분의 회사에서도 마찬가지로 꼭 지켜야할 사항들일 수도 있습니다.
회사 내 개발 컨벤션 규칙 지키기
회사 내에 개발 컨벤션 규칙 이 있다면 기본적으로 지키는 것이 당연합니다. 예를 들어, Reservation 이라는 단어는 rsrv 라고 약어로 사용하는 컨벤션 규칙이 있다고 가정하면, 약어 사용으로 인한 코드 가독성 저하 등 여러 단점들을 본인이 알고있다 하더라도 일단은 지키고 나중에 개선하는 방향 으로 가야 합니다. 컨벤션 규칙을 지키지 않았을때는 다른 사람들이 본인이 작성한 코드를 분석하느라 많은 시간을 소비하게 될 것입니다.
네이밍에 대한 고민하기
제가 2년간 SI, Agency 회사에 근무하면서 다양한 개발자 분들을 봐왔는데 거의 대부분의 개발자분들이 네이밍에 대한 고민을 하지 않는다는 것입니다. 예를들어 년,월,일에서 ‘일’ 을 나타내기 위해서 변수명을 day 로 선택한다던지, 약어를 무분별하게 사용하여 코드의 가독성을 떨어트린다던지 혹은 신조어를 만든다던지 등 이러한 악습관들은 결국 유지보수성을 떨어트리게 만듭니다. 변수명, 함수명을 읽었을때 무슨 의미인지 알기 어려운 약어를 사용한다면 해당 변수명, 함수명이 어떠한 역할을 하는지 알기 위해 각종 문서, 데이터베이스 스키마 등을 열어볼 수 밖에 없습니다.
사용자의 입장에서 생각하기
웹 개발자는 사용자가 원하는 웹 애플리케이션을 만들어야 하는 직업 입니다. 즉, 사용자가 이용하기 편한 애플리케이션을 만드는 것이 중요하다고 생각합니다.
사용자의 입장을 생각한 예는 다음과 같습니다.
- 등록하고나면 “등록 되었습니다.” 라는 문구를 띄워주는 것.
- 년월일, 혹은 사업자번호를 입력받는 프로그램의경우 사용자가 ‘-(하이픈)’ 없이 입력하는지, ‘-(하이픈)’ 을 사용하여 입력해야하는지 헷갈릴 수 있는데, 헷갈리지 않게 하기 위해 placeholder 속성을 사용.
개발을 하다보면 “어 ? 이렇게 해주면 사용자가 더 편할 것같은데” 혹은 “이렇게 개발하면 사용자가 불편할 것 같은데?” 라는 생각이 드실겁니다. 보통 저는 생각을 바로 개발에 옮기진 않고, 나의 생각을 결정권자나 상급자께 공유를 한 다음, 더 좋은 방법이 있는지 확인하고, 개발에 옮겨도 되는지를 결정 하는 편입니다.
사용자가 웹 애플리케이션을 이용하는데 편하거나 불편할 것 같다고해서 자기 마음대로 기능을 마음대로 추가하고 빼라는 얘기는 아닙니다. 물론 경험이 쌓이다보면 보고가 필요한 부분인지 아닌지에 대한 감이 올 것 입니다. 당연히 해줘야 하는 것들인데 기획자가 깜빡한 경우나, 너무 간단해서 바로바로 적용해도 무방한 것들이 존재하긴 합니다.
JSP 사용 시 C : OUT 필수
회사에서 JSP 를 사용하고 있다면 Model 에 담긴 데이터를 JSP 에서 출력할때 꼭 c:out 으로 감싸서 사용해야 합니다. 그 이유는 XSS(Cross-site Scripting) 방지를 위해서입니다. 만약에 c:out 없이 다음과 같이 ${dto.content} 출력 한다면 content 에 악의적인 스크립트가 삽입되어 있는 경우 웹 애플리케이션에 악영향을 끼치게 됩니다.
컨트롤러 RequestMethod 설정하기
간혹가다 @RequestMapping 어노테이션을 사용하는 경우 GET 의 경우는 무방한데, 등록이나 수정, 삭제 등을 수행해야 하는 핸들러 메서드의 경우에는 RequestMethod.POST 설정을 해줘야 합니다.
필요에 의한 중복이 아니면 제거
중복은 코드의 확장성과 유지보수성을 떨어뜨립니다. 하지만 중복이 필요한 경우도 있습니다.
예를 들어, 하나의 프로그램에 대해서 관리자와 사용자가 둘 다 등록할 수 있는 경우 관리자의 등록 검증 로직과 사용자의 등록 검증 로직이 필요할 것입니다. 기본적으로 두 검증 로직이 상당히 유사한 경우가 많습니다. 하지만 관리자와 사용자에서 하는 검증 로직은 나중에 충분히 달라질 가능성이 있습니다. 예를 들면, 사용자가 본인인증을 하고 등록하는 경우라면 DI 값이 필요할 것이고, 관리자가 등록하는 경우라면 DI 값이 필요가 없을 것입니다.
위 처럼 중복이 꼭 필요한 경우가 아니라면 중복 코드는 최대한 제거하는 편이 좋습니다.
검증은 서버와 클라이언트 둘 다 하기
기본적으로 검증은 서버와 클라이언트 두 곳에서 다 해줘야 합니다.
클라이언트에서 검증을 하는 이유는 서버를 거치지 않기 때문에 사용자에게 빠른 속도로 검증 결과를 알려줄 수 있습니다. 클라이언트 검증을 하지 않고 서버 검증만 하게 된다면 100 만명의 사용자가 등록에 실패할 수 밖에 없는 입력값을 넣고 등록 버튼을 누르게 되면 서버를 100만 번 거쳐 성능상 문제가 발생할 수 있습니다.
서버 검증을 하는 이유는 클라이언트 검증은 개발자 도구를 이용해서 쉽게 통과할 수 있습니다. 그 외에도 다양한 방법으로 클라이언트 검증을 우회할 수 있습니다. 예를들어, 예약 시스템에서 서버검증이 되어있지 않다고하면 악의적인 사용자가 자신의 사전 예약일이 아님에도 불구하고 예약을 뚫는다던지, 예약이 꽉차있는데도 등록이 된다던지 다양한 버그가 발생할 수 있습니다.
커밋 메시지는 의미있게
커밋 메시지를 작성하지 않는 개발자나, 혹은 의미 없는 기호나 문구를 넣어 커밋을 하는 개발자들이 꽤 많습니다. 커밋 메시지는 개발 히스토리 관리에 있어서 꼭 필요한 부분이며, 커밋 메시지만 잘 작성되어 있어도 유지보수가 편해질 것입니다. 한 회사는 어떤 커밋메시지를 입력할 지를 먼저 생각하고 개발하는 프로세스를 사용하고 있다고도 합니다.
운영 서버에 파일 반영 시 두 번 더 확인하기
운영 서버에 파일 반영할 때에는 항상 조심해야 합니다. 내가 반영하고자 하는 파일이 제대로 컴파일은 되었는지, 파일 개수는 일치하는 지 혹은 다른 사람이 작업한 내용을(같은 파일을 작업하는 경우) 내 로컬 소스에 받지 않은 상태로 내가 작업한 부분만 반영하는 것은 아닌지 등, 문제가 발생할 만한 상황들을 미리미리 두 번, 세 번 확인해야 합니다.
운영 서버에 파일 반영 시 백업 필수
운영 서버에 파일 반영할 때에는 기존에 반영 되어있던 파일을 꼭 백업해야 합니다. FileZilla 의 경우 F2 (이름 편집) 단축키를 눌러 파일명 뒤에 ‘.년월일’을 붙여 백업하면 됩니다. (Ex. reservation.class.20210909)
개발/운영 서버 재시작 시 로그 보기
서버 재시작을 하기 전에 항상 로그를 띄워 놓고 같이 봐야 합니다. 본인 생각에 버그 발생할 이유가 없다고 판단 하더라도, 실수를 했을 수도 있고 수정한 파일로 인해 다른 곳에서 부가적인 문제가 생겼을 수도 있고 다양한 상황이 존재하기 때문에 꼭 로그를 띄워놓고 같이 봐야 합니다.
조언
한 가지 조언을 드리겠습니다.
유지보수성과 확장성을 고려하여 프로그램을 어떻게 개발할 것인지에 대한 고민하기
저는 아직도 하고 있는 고민이고 개발자를 직업으로 갖는 한 앞으로도 계속 할 고민이라고 생각합니다.
유지보수성과 확장성을 고려하여 프로그램을 어떻게 개발할 것인지에 대한 고민을 하게 되면 자연스럽게 다음과 같은 내용들을 찾아보게되고 고민하게 됩니다.
- 가독성 좋은 코드가 주는 이점
- 객체지향 프로그래밍이 주는 이점
- 객체지향 프로그래밍을 잘 하기 위해서 어떻게 해야 하는 지 ?
- 비지니스로직은 어느 Layer 에 두는게 맞는 지?
- 디자인패턴과 리팩터링
- 도메인 주도 설계
- JPA 를 사용했을 때와 Mybatis 를 사용했을 때의 차이 점
- 기타 등등
위와 같은 내용을 공부하고 고민함으로써 한 층 성장한다고 생각합니다. 내가 무엇을 공부해야할지 모르겠다고 하면 위와 같은 고민을 함으로써 무엇을 공부해야할 지도 알 수 있습니다.
정리
제가 제시한 반드시 따라야할 지침과, 조언이 이 글을 읽어주신 분들께 도움이 되길 바랍니다.
