본문 바로가기

이야기/SI

 (16)
SI식 개발 프로세스 정리하기 ============================== * 윗선 1. 요구사항 확인 2. 화면설계서 작성 3. 조율 & 컨펌 ============================== * 개발자 1. 요구사항 확인 2. 화면 설계서 확인 3. 인터페이스 정의서 확인 3-1. 없다면 소스 파악하는 시간이 필요 ** 4. 개발서버가 존재하는 고객사인지 확인 ** 4-1. 개발서버가 존재하지 않으면 운영서버에서 어떻게 테스트를 진행할 수 있는지 검토 5. 서비스 구현 5-1. 서비스 테스트 6. 화면 구현 6-1. 서비스 호출 테스트 6-2. 실제로 의도한대로 작동하는지 확인 7. 소스 반영 8. 고객사에서 확인 9. 피드백 있다면 수용 후 5~6 단계 반복 10. 고객사에서 컨펌했다면 비용 청구 11. 받았다면..
개발환경은 반드시 알아둬야 한다 개발을 하다보면 반드시 개발환경 단계에 대해서 알아야만 한다. 그래야 남이 무슨 말을 하는지 이해를 할 수 있다... "김 개발자님. 개발 서버에서 개발자님이 담당하신 서비스가 정상적으로 작동하지 않아요!" "제 컴퓨터에서는 잘 되는데요?" ==> 여기서 동일한 코드를 가지고 한쪽은 잘되고, 한쪽은 안된다고 한다. 둘 다 옳은 말을 하고 있다. 단지, 개발자는 개발환경이 로컬일 뿐이고, 검수자는 개발서버, 혹은 테스팅 환경에서 검수한 것이다. 여기서 "나는 되는데 왜 안된다고 하는 거야!?" 라고 화를 내면 자신의 부족함을 내세우는 것 외에는 아무것도 아니다... 확실하게 알아두고 가자. 1. Local 작동환경을 개인 컴퓨터에 설치해서 고정된 환경 내에서 프로그램을 개발하는 경우다. 일단 하나의 프로그..
SI에서 연봉협상이란? 너무나 무섭고 설렜던 첫 연봉협상이 끝을 보이고 있다. 2월부터 최대한 다양한 회사에 접촉해보고 여러 사람에게서 실제로 얼마를 받는지, 연차에 따른 연봉 테이블은 어떤지 알아보느라 거의 모든 시간을 쏟았다. 내가 얻은 정보가 신뢰할 수 있는 수준인지, 신뢰할 수 있다고 믿은 정보를 바탕으로 내가 회사에 내 연봉 인상을 위해서 제안을 할 수 있는지 많이 따져보았다. 핵심은 회사의 수입구조라고 판단을 내렸다. 기업별 연봉테이블이란 결국 그 회사의 수입구조에 직접적으로 영향을 받는다. 회사에 사장 혹은 임원급이 있다 (이하 경영진). 경영진은 특정한 기업과 다양한 조건을 걸고 계약을 맺는다. 계약을 수행할 사람을 뽑는다. 이런 조건 하에 모인 사람들이 직원이다. 직원은 회사가 맺은 계약을 실질적으로 수행하며 ..
분석 업무라는 것이 별도로 있더라. 개발, 설계 외에도 AS-IS의 로직 흐름을 파악하는 분석이라는 업무가 별도로 있다는 것을 알았다. 규모가 있는 프로젝트에서는 분석을 담당하는 개발자가 별도로 있다고 한다. 하지만, 소규모거나 망한(?) 프로젝트에는 그런 것은 없고 개발자가 분석 및 개발을 모두 담당한다고 한다. 그러려니 했는데, 이게 의외로 분쟁의 영역이 되기도 한다고 한다. 개발 외에도 분석까지 같이 진행하면 추가적인 비용을 요구하거나, 업무 자체를 거부하는 경우도 심심찮게 있다고 한다. 이 파트는 신규 프로젝트를 개발하는 단계에는 없는 단계였다. 현실적으로 차세대 프로젝트에서 기존에 사용되는 업무가 왜 그렇게 사용되는지 정확히 알 수가 없으니 추가된 단계라고 보인다. 작업을 하다보니, 이렇게 실질적인 업무 별로 추가되는 절차가 존재..
기존 업무 외 추가 업무 요청이 들어오면 어떻게 해야하는가? 기존 업무를 진행 중, 일정에는 안 잡혀있고 소요되는 시간은 상당히 길 것으로 예상되는 업무에 대한 협조 요청이 들어온다면 어떻게 대처해야할까? 이미 작성한 서비스에 대한 수정 요구사항이 들어왔다. 단순하게 조금만 손 보면 되는 것이 아니라, 참조하는 테이블을 수정하고 업무구분에 따른 별도의 쿼리를 작성해달라는 요구였다. 그런데 문제는 해당 서비스는 이것저것 총괄하여 보여주는 통합형 서비스라서 들어있는 쿼리가 상당히 많았다. 대략 서비스 개발에만 2주일이 넘게 걸렸다. 해당 서비스 쿼리 수정은 작성에 비하면 규모는 적으나 최소한 일주일 이상은 잡아야 할 문제였다. 서비스 뿐 아니라 화면에 요구하는 전문또한 변경해야 했기 때문에 화면 - 서비스 - DB를 모두 변경해야 하는 작업이다. 문제는 해당 업무는 ..
갑자기 데이터의 흐름이 보인다...!? 평소처럼 작업을 하는데 어느정도 문법이나 툴에 익숙해졌기 때문일까? 보다 효율적으로 일하려고 이미 작업한 것은 복사하고, 비슷한 부분은 수정하고 하면서 진행을 해봤다. 여태까지는 최대한 익숙해지려고 복붙 보다는 생각하면서 조금이라도 적어보려고 했지만, 이제는 딱 보면 어떤 데이터가 어디에 담겨있는지 상상이 갔다. 상당히 놀랐다. 여태까지는 이 경우에는 데이터가 어느 라인에 있겠지 이런 것은 머리가 아팠는데 자연스럽게 그런 것이 보였다. 그래도 자만은 금물! 이런 생각에 최대한 작업을 마무리하고 테스트까지 만들어서 돌려봤다. 놀랍게도... 한 방에 통과한 테스트가 8개 중 6개였다. 나머지 2개도 연관된 객체를 잘못 설정해서 그런 것이어서 그런 것이었다. 바로 수정하니 완성! 그리고 그 작업을 하고 살짝 ..
드디어 암복호화 기능을 사용해봤다 프로젝트에서 여태까지 암복호화 기능을 적용하지 않았다. 그러다가 최근 표준이 정립됐는지 암복호화 기능을 추가하라는 공지가 내려와서 적용을 해봤다. 내가 생각했던 방식은 spring security에서 적용한 것처럼 인터셉터가 도중에 값을 가져가서 암복호화를 진행해서 로직 파트에서는 신경쓰지 않는 방식이었다. 프로젝트에서 적용한 방식은 다소 달랐다. 실제로 controller에 해당하는 영역에 암호화, 복호화에 관련된 코드를 작성했다. 퇴근하고 검색해보니 알았는데, SHA256.java, BCrypt.java를 활용하는 방식과 매우 흡사한 것 같다. 참고한 블로그는 다음과 같다. 패스워드 암호화하기 - MyBatis 이용하기 [SPRING] 패스워드 암호화하기 -Mybatis 이용하기 0. SHA256.j..
SQL을 표현하는 방식은 통일해야 하는가? SQL은 오랫동안 쓰인 기술치고는 표준화된 표현 방식이 없는 요상한 기술이다. 표현 방식이라는 건, 기술적인 이야기가 아니라 말 그대로 SQL 문체(?)를 이야기하는 것이다. SELECT 뒤에 오는 컬럼을 아래에 적느냐 옆에 적느냐 이런 차이도 있고, 쉼표를 끝에 적느냐 맨앞에 적느냐, 쉼표를 맨 위 컬럼의 바로 아래에 적느냐 아니면 컬럼의 두 칸 앞에 적느냐, 이런 자잘한 문체들 말이다. 이 문제에 대해서 깊이 생각한 적은 없었다. 일반적으로 DB Tool에서 제공하는 자동완성 기능을 최대한 활용했다. 그런데 오늘 DB Tool에서 제공하는 문체는 지양하라는 말을 들었다. 회사에서 SQL을 작성하는 방식으로 작성하라는 말이었다. 쉼표는 컬럼 앞쪽 두 칸, 소괄호는 윗 컬럼과 맞추고, SELECT 부터 ..
낯선 프레임워크를 접하며 든 생각 비주류 프레임워크는 다양하다. 대부분 특정한 목적을 달성하기 위하여 대중성을 포기한 대가로 목적을 달성하는 것에 초점을 둔 프레임워크다. 한국에는 특히 이런 프레임워크가 상당히 많다. HTML, CSS 대신 컴포넌트 단위로 드래그 & 드롭 형식으로 화면을 꾸미는 프레임워크가 특히 상당히 많다. 아마도 디자인이라는, 개발자에게는 낯설 수밖에 없는 영역을, 디자이너에게 의존하지 않고 해결하기 위한 도구로 보인다. 더불어 숙련도 낮은 개발자 혹은 유지보수 관리자가 특정한 화면을 개발하기 위한 목적도 있다고 본다. 이런 프레임워크는 깊이 파고들 이유가 전혀 없다. 하나의 제품에 불과하며 보편성을 갖추고자 노력하지도 않는다. 단지 자신의 제품을 소모하는 물주 몇몇을 붙잡고 그들의 입맛에 맞는 제품을 유지할 뿐인 ..
개발자에게 의사소통은 두 번째로 중요하다 개발자에게 의사소통은 필수다. 개발자에게 가장 중요한 것은 일단 개발 실력이다. 다른 모든 것을 잘해도 개발을 못한다면 일단 개발자라고 말할 자격이 없다. 개발자라는 사람이, 주식을 너무 잘해서 주식으로 돈을 벌고, 강의를 너무 잘해서 강사로 유명하다면... 애당초 개발자라고 말할 이유가 없다. 증권맨이거나 유명강사라고 하겠지. 그렇다면 해당 요소를 제외한다면, 실질적으로 [개발자]에게 있어서 가장 중요한 것은 무엇일까? 나는 의사소통이라고 생각한다. 철학적인 의미나 이상적인 개발자의 모습을 말하는 것이 아니다. 실질적으로 의사소통이 안되면 개발이 너무 힘들고 실질적으로 내가 무엇을 했는지 남에게 인지시킬 방법이 없다는 것을 서서히 느끼고 있기 때문이다. 1. 외부인과 의사소통 혼자서 기반을 다지고 완성..

티스토리툴바