본문 바로가기

이야기

 (41)
드디어 암복호화 기능을 사용해봤다 프로젝트에서 여태까지 암복호화 기능을 적용하지 않았다. 그러다가 최근 표준이 정립됐는지 암복호화 기능을 추가하라는 공지가 내려와서 적용을 해봤다. 내가 생각했던 방식은 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. 외부인과 의사소통 혼자서 기반을 다지고 완성..
체계적인 코드 네이밍의 장단점과 요약 가독성만을 위한 코드네임을 짓는 것이 아니라, 보안까지 신경쓰면서, 대규모 인원이 공통적인 작명법을 짓게 하려면 체계적인 코드 분류 방법이 필수적이다. 체계적인 코드 네임 작명법을 규정한다면 장점은 다음과 같다. 누가 작성해도 균일한 코드 네임을 산출한다. 코드를 보지 않고도 규칙에 의거하여 내용물을 유추할 수 있다. 규칙에 의한 관리가 가능해져서 하나의 업무로 분류할 수 있다. 반면에, 단점도 분명하게 존재한다. 단어만 보면 아무런 의미가 없으므로 이해하기 힘들다. 관계자도 분류표를 확인하며 읽지 않는 이상 이해할 수 없다. 코드 체계가 변경되어야 한다면 기존에 작성한 코드를 마이그레이션하는 것이 큰 비용으로 다가온다. 즉, 간단하게 이야기하자면 이것이다. 소수의 관리자가 대규모 인원을 관리해야 할 때..
친구랑 술을 마셨다 편의점에서 술과 안주를 사니 친구와 이야기 할 거리가 생긴다. 편하게 생각나는 대로 말을 해도 내가 이렇게 할 말이 많았나 싶다. 생각보다 나는 잡생각과 걱정이 많은 성격이었던 것이었네. 초등학교에서 만난 친구를 아직까지 만난다. 그리고 가장 편하다. 왜 사회에서, 대학에서 만난 친구는 오래 못 갈까? 잡다한 의문이 드는 밤이다.
Delphi가 무엇인고? 프로젝트에 사용하는 언어가 무엇인고 찾아보니 델파이라고 한다. 처음 듣는 언어다. 대체 무엇인고? 찾아보면 객체 지향의 파스칼 기반 프로그램 언어를 사용하는 개발 환경. 데이터베이스 응용 프로그램 개발에 사용된다. 라고 하는데... 말만 봐서는 뭔지 하나도 알 수가 없다. 어차피 주로 사용되는 언어도 아닐 것이고 미래가치가 뛰어난 것도 아니니 간단하게만 알아봤다. 데이터베이스 중심 개발언어다. 속도가 상당히 빠르다 이미 금융권에서 상당한 부분이 델파이로 구축되어 있어서 그 분야에서 사용한다. 즉, 금융권에서 코어 파트를 담당했던 구식 언어라는 뜻이다. 지금 프로젝트에서는 델파이를 걷어내고 자바로 바꾸려는 작업이 진행되는 것 같다. 문법을 보면 무엇인가 알쏭달쏭하다. JSTL 느낌이 나면서, DB 툴에서나..
SI에서 개발자를 영입하는 방법론 (내 생각) SI 프로젝트에 세 번 참여해봤다. 프로젝트 별 특징을 간략하게나마 적어보려고 한다. 1. 유산형(?) 개발자가 도중에 나가서 막바지에 개발자를 투입하는 경우다. 개발자가 도중에 퇴사했는데, 프로젝트가 막바지인 경우 정규 보안 절차에 따라서 개발자 투입을 하는 것은 말이 안된다. 인증 절차가 긴 회사인 경우에는 절차를 진행하다가 프로젝트 기간이 끝날 수도 있다. 그 경우에는 이전 개발자가 남긴 유산(?)을 활용하여 개발을 한다. 퇴사한 개발자에게 할당된 계정, 노트북 등을 새로 투입한 개발자가 사용하는 것이다. 근 3일 정도는 소스 파악 및 필요한 설정을 진행한다. 그리고 4~5일 차에 간단한 업무를 할당받고 일단 진행해본다. 숙련된 개발자가 아니라면 당연히 속도가 저조할 것이니 빠르게 산출물이 나올 것..
야근하기 업무가 어떻게 돌아가는지 체감하니까 왜 야근이 당연하게 여겨지는지 알게됐다. 핵심은 산출물과 협상과정이다. 일단 산출물에 대한 압박이 강하다. 개발자가 아닌 사람이 개발자에 대한 성과관리를 하려면 코드가 아닌 문서가 필요하다. 수없이 많이 작성해야 하는 문서는 결국 그런 문서다. 저것 외에도 개발자 사이에 의사소통을 위해서 반드시 필요한 문서가 존재한다. 어떤 방식으로 개발을 해야하는지. 어떤 형태로 개발된 기능을 호출할 수 있는지. 하다보면 결국 개발이 절반, 문서가 절반이다. 이런 문서 작업을 줄이려면 연관된 사람이 개발자 비율이 높아야 하고, 의사소통을 원활하게 할 수 있는 구조가 필수적이다. 하지만 구조라는 단어 자체가 하나의 가치, 상품이다. 아파트를 설계하는 설계사는 시멘트를 한 번도 안 발라..
프로그래머는 뭐하는 직업인가? 프로그래머는 도구를 사용하여 컴퓨터에게 명령을 내리는 작업을 하는 사람들을 일컫는다. 파고 들어서 코어 엔진을 설계하고 제작하는 사람을 프로그래머라고 말하는 사람도 있고, 프로그래밍 언어를 사용해서 프로그램을 제작할 수 있는 사람만 프로그래머라고 부르는 사람도 있다.

티스토리툴바