본문 바로가기

분류 전체보기356

맨 처음 작성하는 코드는 신중해야 해 서로 의존 관계가 정말이지 아주쪼끔 만큼만 거의 포인터 급 정도로 약한 관계를 이뤄야 하며복붙은 절대 하면 안되고되도록이면 노출 범위가 적어야 한다.여러 프로젝트를 해봤지만굴러가게 하는것보다 어려운게 유지보수다.(시간 많이 들게 됨. 기존 코드 동작 해치지 않게 분석하고 수정하고..)시즌제 프로젝트를 만들어서 분기마다 업데이트를 한다고 했을 때, 수정해야 하는 범위가 많을수록 품이 더 많이 들어간다.노출 범위도 마찬가진데, 함수가 의도치 않은 동작을 하게되는 것을 줄여야 하고..그러기 위해서는 노출되는 범위를 어떻게 설계할지 생각해야 하고그리고 그 가끔은 폴더구조 라든지 아니면 함수 내부를 한번은 재정리 할필요도 있는 것 같다 .가끔은.. 그렇지 않고 방치해두면..그냥 한 줄 정도 이상한 코드가 있어도 .. 2025. 10. 13.
잘 말하기 위해서는 무엇을 가장 먼저 말하는지가 중요한 것 같다. 회사에서 잘 말한다는 건의사소통을 잘 한다는 건말을 막힘없이, "내 생각에 최선을 다해서 전달했어"가 아니라상대방이 잘 따라오고 있나?같다.아 음 여러가지 상황이 있지만 이게 정말 어려운데나는 이제 무엇을 설명할 거에요.라고 말하는게 상대방을 안심시키고(덜 불안하게 하고)팔로우업 하는데 가장 나은 수단이 아닌가?싶다.설명에도 여러 단계가 있는데예를들어운전하는 상황이라고 하자.초보다. 아니 초행길이라고 생각했을 때.이제 곧 (이제?곧? 너무 추상적)좌회전 아 어어어 아니 다음다음(다음? 아니면 다음의 다음? .. 줄곧 긴장상태)아아 오른쪽으로 차선바꿔야돼 (왜?)보다는우리는 어디로 갈거고그중에는 어떤어떤 변수가 있을거야그리고 그때가 되면 내가 알려줄게이렇게 대화하는게 듣는 사람 맘편하다고 해야하나..이렇게.. 2025. 10. 13.
AS-IS와 TO-BE 중 더 중요한 것? 1. 내가 도움이 필요한 상황일 때2. 누군가에게 현재 상황을 단순 보고드릴 때3. 요청 드릴 때각각 AS-IS와 TO-BE에 대한 중요도가 다를 수 있음.1번의 내가 도움이 필요한 상황은 특히 주의해서 질문드려야 하는데,TO BE가 먼저 나오면 일이 꼬일수도 있다. 아니면 또 묻게되거나.. 내가 정말 필요한게 아닐수도 있다.문제를 마주치면 내 머릿속에서는 어떤 프로세스가 진행되는데..문제상황>어..이걸 해결하려면 이게 필요한것 같아>그러면 이걸 요청드려야지>요청함여기서 문제는 "이걸 요청드려야지" 결론내는게 문제가 되는 포인트임.한 예로, 에어컨좀 꺼주세요 같은게 있다. 좀 과장되게 말하면.그러면 안된다는 답변을 받을 가능성이 큼..나는 에어컨 직빵이어서 너무 추운데.. 좀 온도만 해결하면 되는데..에.. 2025. 9. 27.
질문을 더 잘하기 위해? 답변을 더 구체적으로 얻기 위해 질문 범위 좁히기 상대방에게 듣고싶은 내용이 있다면범위를 제한하여 질문하는게 도움이 될 수 있다.가장 단순하게는 지시대명사 대신 구체적으로 말할 것.그거, 저거.. 대신 지난 9/7일 오전에 진행한 ㅇㅇ프로젝트 회의 안건 ㅁㅁ. 이건 경우에 따라 너무 구체적이어서 정보량이 많을 수 있지만 이런 느낌.그래야 상대방이 무슨말을 하는지 찰떡같이 알아들을 수 있음대표적인 예시. Q:그거 알아?A:그게 뭔데?이다.음 면접 상황에서 보면 나에게 뭘 묻고싶으신건지, 어떤 대답을 바라시는지 질문이 명확한 분이 있는데,반대되는 예를 들면 ㅇㅇ해봤어요? 라는건 네 아니오 다음에 해야할 말의 방향성이 무수하다. 해봤다고만 하면 되나? 관련 경험을 말해야 하나? 그러면 어떤걸 말하지? (보통은 면접용 필살기ㅡ면접왕 이형 참고.를 얘기하면 된다.. 2025. 9. 27.
의사소통 잘하는 방법/질문 잘 하려고 노력하기(생각의 진입점 전달하기) 질문할때에도 궁금한걸 물어보는 걸로 시작하면 또 이게 무슨말인지 ... 해석해야 하느라 답답할 수 있다.이건 발표할 때 많이 체감했던 건데대화할 때 상대방에게 생각의 시작점을 열어주면 대화가 편하게 흘러갈 수 있다.아주 단순한 예를 몇가지 들어보면김ㅇㅇ님 있어요?라고 질문하면 간단히 대답 할수있을거라 생각하는데대답은 할수있지만 곧바로 도움드리기는 어려울 수 있다.내 기준으로 생각하면 우리 팀에 그런사람 있나 없나 존재유무만 대답할수도 있고같은 사무실이더라도 이름을 모를수도 있다. 수백명을 다 알수가 있나? (일단 얼굴은 안다. 같은 건물에 있으신 분들 익숙하게 많이 보면)음 그러니까 생각하는데 버퍼링이 걸린다.상대방의 생각의 시작점이라면, 여기 예시에서는 ㅇㅇ부서/팀의 김ㅇㅇ님 있으세요? 라고 하면 일.. 2025. 9. 27.
자소서 잘 작성하는 건 곧 일을 잘하는 것 과 같다(는 생각이 들고 있다) 왜냐추상적으로 표현하지 않고 구체적으로 설명하고자소서를 읽는 이가기본적인 내용에 대한 궁금한 점을 다 작성하여(스무고개를 하지 않아도 되고) 추가적인 정보로 깊이있는 대화를 시작할 수 있다.그리고 이건 보고할 때 뿐만 아니라 문서를 작성할때도 마찬가지인데,구체적으로 숫자로 말하고 왜/언제/누가/무엇/어떻게 등에 대한 내용들 그리고 AS-IS와 TO-BE, STAR..모두 업무 과정에서 함께 말하면 좋은 내용 들이다.추가적으로내가 필요한 것에 대해 말을 하려고 하는게 좋은 방법이 될수도 있다. 예를 들어 보통은 확인/질문하는 형식으로 말하게 되는데(내 현재 상황/현상은 이러니까 이런걸 물어봐야 할 것 같아)ㅇㅇ되나요?하면 질문자는 맥락을 모르고 된다 안된다만 답하게 될 수 있다. (매번 손님들이 질문하면 .. 2025. 9. 27.
소프트웨어 엔지니어가 되기 위해 (코더가 아닌) 단순하게 이렇게 코딩해주세요. 로 업무를 받아서 일처리를 하지 않기 위해 노력하기일을받아서 일을 하면거기에 그칠수밖에 없는데도메인에 대한 이해를 하며 작업을 하려고 생각하는 훈련을 해야한다고 알려주셨다.개발자인데 이런 것 까지 해야 하나? 하는 생각이 든다면 위의 말씀이 좋은 계기가 될 수 있는데내 경우에는 데이터 분석 업무였는데, 단순히 입력과 출력이 이렇게 된다를 설명하면 안되고입력데이터의 의미와 출력 데이터의 의미 그리고 왜 그런 로직으로 작성해야 하는지설명할 수 있을 정도면 된다.당연한거 아니야? 할수있는데.. 당연한거 아니다.왜냐?!?! 나는 그 코드를 작성한 사람이 아님.그래서 기존 코드를 수정하거나 새로 기능을 추가하기 전에 수천줄의 기존 코드를 분석해야 하는 업무를 진행하는 중.그래서 분석.. 2025. 9. 27.
기술면접을 보는 이유도 의사소통을 위해서가 아닐까 요새는 AI가 있으니, 기술 질문이 필요할까?더 어려운 내용의 질문을 하지 않을까?글쎄...일단 업무하는 동안 의사소통을 위해서라면 지식이 있으면 서로 명확한 방향으로 시행착오를 줄일 수 있겠다는 생각이 들었다.상대방의 말을 이해하는 범위가 넓어지고, 보다 정확하게 이해할수있게 되는데어떤거냐면...'칸반'이라고 했을 때 알아듣는 사람은 그것을 활용하는 방법까지도 알고있을 가능성이 높지만그렇지 않으면 일단 어떤 문서/URL을 봐야 하는지, 왜 쓰는지(필요한지), 무엇을 해야 하는지 등에 대한 설명이 필요한데 그에 대한 정확한 설명이 되는지도 미묘 하달까? (스무고개 시작이고 캐치마인드다...)그런 것처럼 기술 질문도 마찬가지다.지식에 대해 서로 공유하는 맥락 수준이 비슷하거나 최소한 어떤 말인지 알게 되면.. 2025. 9. 27.
작업을 할 때 수정해야 하는 범위가 적을수록 좋다 하나를 바꿀 때 다른걸 바꿔야 하면 수정사항이 너무 많아짐가장 이해하기 쉬운 예시로 설명해보면노션에서 페이지 내에 폰트 크기를 제목으로 설정하면노션 기능 중에 목차를 만들 수 있다.소제목을 작성하면 해당 문장이 목차와 연동된다는 의미.이건 다시 말하면초안을 작성한 이후로 수정사항이 많아지게 되는데 일일히 목차를 수정하지 않아도 된다는 것임소제목이 10개 20개 되면 그냥 할수도 있는거 아닌가 싶을 수 있는데.. 그냥 하면 될수도 있긴 한데그 일이 우선순위에서 밀리면 혹은 잊어버리면 목차와 소제목이 달라지는 상황이 발생하게 된다. 또는 페이지를 넘기는 데에도 시간에 소요되거나 ctrl f 로도 안나오면.. 커넥션 해제..마치 프로그래밍 할 때 A라는 기능을 함수화 하지 않고 그대로 기능 자체를 복붙하면 ... 2025. 9. 27.

티스토리툴바